insomniac-isotope

[insomniac-isotope]

I ended up hand-laying-out the skill trees for legibility. Internally these all look like this:

and I had to do some additional coding to properly convert the - and = symbols into the right sprites; you can see some of the issues in that middle screenshot. Now that I have all the layout more-or-less working, I need to focus on interactivity, and this is a little more complex/interactive than prior UI elements -- here there's stuff like, click-and-drag or scroll on window edge functionality, maybe smoothly scroll per-frame and cursor snap to the nodes, which requires some thinking about the UI feel for any snap effects, etc etc etc.

(The actual gameplay idea here would be that most characters would be humans, who would have a fixed, maybe lightly procedural skill tree based on certain characteristics, and then there'd be the equivalent of summoned beasts/espers, who'd have their own skill trees that would end up partially overlapping or merging with their summoner's skill tree. Maybe there's disconnected parts of certain trees that could only be bridged by certain summons or certain character types. Certain summoned beasts would have conflicting trees and couldn't be used together... all of this implies a fair amount of mix-and-match with these trees, and anyway this is a good test for UI robustness, so I might be picking away at these for a while. I still don't have a firm grasp on what exactly the real game skills would be, though, so it'll continue to be FF8 dummy data for a while. ty Kasket Darkfyre on gamefaqs for writing down all the GF info back in 1999)

[insomniac-isotope]

Adding text labels. I'm debating between having more complex auto-label (or just hiding labels unless you're over a specific node) vs. laying out all these upgrade trees so the simple autolabels are actually all legible and non-overlapping. (Still using FF8 dummy data here; this is Quetzlcoatl's skill tree.)

[insomniac-isotope]

I ended up revising my code a little to permit an 'editor' instead of doing this mostly-procedurally. Theoretically I'd be able to 'draw' a little custom node tree for each specific thing and even tie the nodes to a skill key so they actually represent, you know, anything specific. I'm still mostly trying to get the hang of the UI itself, though.

[insomniac-isotope]

I wanted to have a little structure for these things, so I changed them to outline a simple shape and place 'skill nodes' at regular intervals.

[insomniac-isotope]

Working on UI again! I wanted to put together some kind of big upgrade/skill tree situation. This first involved manually drawing out a big halftone pattern as a border for the fullscreen UI. (For the record, I did get sprite-flipping & sliced-up spritesheets working right, it's just I didn't get any good screenshots of it yet)

[insomniac-isotope]

Sprite flipping is working. This condenses the sprite sheets a bunch, so now it's feasible to fit 32 on a single sprite page. That number will go down as I add in more frames for characters, though, or if I start to add sprites that are bigger than a 1x1 sprite section.

[insomniac-isotope]

That's not what this should look like.

[insomniac-isotope]

Working on adding sprite x-flipping to simplify some of the character (and maybe tile) sprite sheets. There's a lot that can go wrong!

[insomniac-isotope]

Finally got some more good glitch screenshots. I'm currently digging in to how I'd need to change the sprite-rendering setup to accommodate layered sprites -- instead of characters being a single sprite, they'd be a bunch of partial sprites (legs, torso, arms, head, hair, clothes, equipped gear, etc) layered on top of each other with separate palette modifiers. This would add a lot of flexibility to mixing and matching various sprites.

But due to the convolutions of how rendering works, this meant that I needed to go into my shader code and fully divorce the "sprite to draw" value from the "sprite rotation" value. Previously they were just added together and all the sprite sheets were laid out with the rotation-suitable sprites in sequence, but for the sake of compactness (just drawing some sprites flipped) that's no longer the case. Which means adjusting the draw data for everything that gets drawn, not just the player sprites.

Sometimes you miss a value or two and you end up with something like this. It's fine.

[insomniac-isotope]

I missed taking roughly a billion screenshots of this while it was all busted, which kind of goes against the ethos of this blog, but I updated the forms code to handle the new 16px, variable-width fontsheet.

So, I'm returning to character creation because I wanted to finally get that working for-real, since that requires solving a few tricky questions about how to represent palettes and characters while being rendered. I've drawn some more involved character sprites, but I haven't been able to use them in-game yet, in part because I didn't have the level of palette support I would want. Right now I'm weighing my choices between having a palette key for certain sprites vs. decomposing all the sprites into one-color keyed sections; there are still several technical decisions about just how to handle this that I have to make and commit to. But at least now I can finally have those little color selectors in the character creator actually write palette information for the PC sprite and have that reflected in-game, even if I still have a lot of sprite chopping and layering to do before I have full support for PC sprite variants.

[insomniac-isotope]

"Variable-width font" support. There's still some positional stuff I haven't adjusted yet, and I'm not super satisfied with the font itself, but it works as a proof of concept for now.

Since this is all drawn using webgl2, when I actually 'release' the game it'll likely involve some kind of electron wrapper or something, which means I'll be able to render text by just drawing a html element over the textbox. This is probably gonna be necessary for visibility and accessibility reasons, but it's a little funny to think about given the amount of time I've sunk into drawing & coding up text display.

[insomniac-isotope]

I wanted to work on some NPC dialog stuff, which meant pinning down a little bit more about the 'real' UI proportions (so I could be sure what the actual resolution for NPC portraits would be), which meant finally moving on from the 8x8 pixel font I drew back in the day. All the UI is now 2x size, which means I now have a 16x16 pixel font. I ended up hardcoding a bunch of those sizes across the various UI functions, so now I'm fixing those up. I'm also preparing to add variable-width font support to this thing, since monospaced fonts don't really look... great.

[insomniac-isotope]

Added in some "actual" NPCs. Deciding how I want to store and surface NPC dialog is gonna be a big thing, as is figuring out what all exactly I want to have them say. But at the very least I should be able to make some characters you can talk to, and place them down in the various little 'houses' that are generated.

[insomniac-isotope]

Also I drew stairs sprites. Internally these are just a ramp you move smoothly up.

[insomniac-isotope]

I have accomplished 'walking up stairs'.

Nearly all the weird floor-related collision issues have been fixed, so I'm ready to try, you know, making slightly more complex buildings and landscapes. The cutaway effect is still kind of goofy in places, but overall it's comprehensible even if it's a little annoying that you can't, you know, see the entire floor you're standing on when you're inside a building. I have some ideas for how to change the overall shader to add more vertex data for things like "building floors" or "walls", which is ultimately gonna be necessary for, at least, comprehensible walking around inside caves, but it's not a top priority right now.

(The one remaining issue is that if you're in a building and you jump and hit the floor above, instead of bonking on the ceiling you instead get instantly upwarped to the floor above. That's goofy. Maybe I'll just make all buildings have very tall ceilings.)

[insomniac-isotope]

This is the 'final' culling algorithm for now. It's tweaked a little to try to limit the amount it culls things behind the PC that wouldn't be colliding with the view anyway, but it's still kinda weird and limited, since it turns out what I'm asking for is a very particular kind of effect.

Also, there are multi-story buildings now! There's currently some collision problems that make ascending stairs very treacherous (it's very easy to fall into the seam between floors) but it works well enough for testing purposes.

[insomniac-isotope]

This is a somewhat-better culling algorithm.