Animations Work Continuing

This week has been rather hectic in things outside of Torn Realms for me, so my ability to keep the development going at a good pace has been somewhat diminished, but that's not to say I'm not squeezing in a few minutes here and there. I have been ongoing with the animations editor code, slowly putting in all the functionality I'll need to both cater for simple single run animations (plants in the world for example, or animated water rippling about) as well as complex animation models that will be creatures and party members etc with multiple directional animations and actions that require more exact control.

The last things I've been working on have been the interfaces for all the extra little details that are needed for the code to run properly in the background of the app - things like what layers to render to, whether animations are looped or synced to other things and so on. So basically boring stuff that makes cool little things later on - but it's all got to be done, validated, saved to the database neatly and all that.

Hopefully this week I'll be able to round out some more of this in the evenings this week. What I will admit though, is that I'm getting super excited about seeing all the lovely assets starting to animate in the editor and just looking forward to seeing the world built up and looking amazing with all these things moving about and changing things from a static flat works to one where it's starting to feel like more of a real world.

Animation Tools Coming Along Nicely

I had a great night in the editor code today. I've had ideas bouncing about my head since yesterday about what I want to implement and how it might look - and now, having had the time to nicely process things in the background, I got into build-mode which was a lot of fun.

The editor now handles a lot more of the images more efficiently, I can isolate frames, set actions, set animation times, and generally do all the things I need it to be able to do. I do need to work out the object model on the page, so that I can start to save data to it, and then transfer that to the database, and finally load that all into the game - but I did have a very smug moment as I started to look through the tables I'd made for animations in the database well over a year ago now. I really, don't think I need to modify what I've got in there. I think I have it covered. Which.... made me feel delighted and proud/confident/something that I'd managed to get that right all the way back then.

Anyhow, enough of that. Tomorrow I am hoping to get into the object model on the editor page and with a bit of luck, perhaps starting to save it (bits of it) to the database. I do also need to write the code to reprocess the uploaded spritesheet into just the frames that were used so that I can output an image to import into the app directly. 

Oh yeah, I'll also need to tweak the tools I'm working on at the moment to be able to import multiple input spritesheets and process the final output from multiple files into one output. Cause some of my asset files are in that sort of format, and I think it's easier to just bite the bullet, write the code to handle it than to try to modify the input spritesheets each time, aligning things properly and all that.

I am still mulling over the decision to keep entire animations all in a single x,y resolution, optimising each particular animation element, or optimising each individual frame. I think there's a lot of memory to potentially claw back by doing a more thorough optimisation, cleaning out unused pixels and limiting the size of each frame if possible, but that means there's also going to be a lot more work in rendering them just right. If I hadn't just tweaked the rendering engine to scale and size things on the fly, this would be much easier, but again, I think I'm likely going to lean into the "just do it...." camp. Just not yet. I'll put some of that off a little bit yet without committing to that yet. The extra work would be doing my head in right now.

Sprite Animator Editor Code Progressing

So, it might not look like a  whole lot yet, and it's not, not going to lie on that. There's a lot more work to get done on the editor side to be able to completely do all the handling I want around spritesheets and animations, and loading them all into the app - but I've gotten a good ways into new code this weekend that I had no idea about beforehand, so I'm counting that as a win.

What I've got currently processes, then animates nicely what's in the complete spritesheet. Next steps will be to be able to isolate individual frames from that, tie them back to specific facings and actions and finally output a new spritesheet with the animations used, and an associated metadata dump that I can use in the app to tie it all together into number of frames per action, the time it should take to render that entire action and all that other really really important stuff that the app cares about, that almost no gamer will ever know exists or care about (and nor should they!).

I'm currently doing a mental game of "should I?.... should I not?..." with a further optimisation of each frame of animation, or animation action - so that unused areas of the frame are cropped, and then that frame is rendered to a specific place in the overall screen, so that it all looks correct - but it uses less memory to store the bitmaps. I'm not on either side of the fence yet entirely, but certainly taking a good look at perhaps each action/facing might get an individual frame size.

First Part of the Itch Scratched - Animation Scaling works on the Fly

First off, sorry for the ghastly screenshot used, but I needed a blank and unfinished section of the world that was really open, so I could see the things that I'm about to talk about without trees and things getting in the way.

So, based on my update from last night, the first part of the code to change was to modify the Graphics Rendering Engine to see if I could modify the code so that animations for Monster Encounters were no longer locked to the native game tile size of 64 pixels. I also wanted to at the same time see if I could also grow/shrink the canvas size. This would give me a two-fold benefit. 

First, by unlocking the rendering engine from a 64 pixel monster, I could have monsters that are large, larger and really large. Not doing that from the start was probably lazy, but that feels like a long time ago now.

Second, ideally I'd love to have monsters rendered at different sizes. At a most basic level, that allows me to use the same sprite, that's already stored in the engine as a bitmap as varying sizes - ie, multiple monster types. Re-using the same animation pack for two different things. Goblin? Sure. Lets make you tiny. Some Hobgobnlin? Sure. Same animation, but now you're quite large. All that while storing the same original bitmaps in memory. I was however concerned about framerate - would I be able to get away with scaling the rendering aspect on the fly, or would I need to create new bitmaps stored natively in the smaller/larger resolutions? Turns out, scaling on the fly works without any noticeable framerate impact, but in the emulator and a physical device. So, I get to write some code now that can scale models to re-use things at completely different scales, but also be able to subtly apply a small scaling to a particular monster in an encounter if it's a bit tougher and stronger than it's peers. Or weaker. There's always a runt I guess.

Head-scratching time with Monster Spritesheets

So tonight was a bit of an evening of code that sat me right down and told me I'm a little fish in a damned big pond. I am still working on the code for monster encounters, focusing on trying to somehow refactor all the little things that are currently working in place-holders into something more cohesive and functional. At the same time, I'd ideally like to write the code in a way that is going to work nicely with the editor interface that I will have to write to create all the assets with.

So, I started looking through a number of sprite sheets that I have bought over time to use, saw that they are by many authors (there's not really a go-to artist that has ALL the stuff you want) which is fine, but that leads to inconsistencies in things. Obviously they are in different scales, different resolutions, but here's where it starts getting tricky. They're in different quantities of facings, often with different possible actions (and with different quantities of those even). So one model might have facings in eight directions, with three different attack animations, a walk, a run and a death animation. Cool. But the next author did his animations with four facings, one attack - but there's a special animation to fly - and it comes with a launch, then a looping fly, then a land animation. Oh, and there's an attack animation for flying attack - and an attack animation for landed attack.

You can see why I'm basically sitting in the corner of the shower weeping on this one. There's going to have to be a bunch of changes to the way the engine renders models to handle the different pixel sizes (which is the easy part) but I'd ideally like to have some sort of interface to be able to handle giving monsters multiple animations for different actions, potentially link each animation to a specific action (use this for spell-casting, these THREE for melee,  this for defending). Oh, and here's the kicker. The sprite-sheets are all in different formats, so.... I'd also like to build the editor interface in such a way that I can upload a full sprite-sheet, tell the interface what pixel size the sheet is in, then be able to input a facing, an action name and a animation frame count and have it build up not only a new sprite-sheet to use in the game itself, but also the associated metadata to build those objects in the app itself.

Good brain-make-thinkings and honestly, these sorts of things are half the reason I'm coding the damned thing in the first place, but yeah, tonight was a night I thought I'd have it easy and instead I got a bloody nose and little to show for it.

Monsters are starting to really work

Yesterday evening, I continued from what I'd been building on the weekend, adding some smarts (not really smart, but not dumb either now) to the monsters and how they interact with one another. A lot of the code is still in placeholders at the moment, so there's still a good bit of work to get done in this phase, but monsters now have the ability to apply effects to one another if they want to (they probably normally will want to) and these effects are shown nicely on screen after I dove back into the rendering code to give that a little bit of an update too.

Like I said, a lot of the code is still placeholders, so it's neither balanced in any way, or truly built up from it's parts - the goblin encounter has 10 health, while the Knight encounter has 25, not a future state where an encounter will potentially be built up of multiple individuals and the final encounter stats are then built from those parts. But... you know what, that's going to be easy enough to do, even if there's a good bit of code to write to make that all work. I just figure there's no point in doing all that until I actually know what all the parts need to store, know, and how they will function with one another properly. That's what this part is for.

In this little snippet, there are some Goblin encounters on the screen, and as I move about a bit, it spawns another Knight encounter - and the two sides that hate each other get to fighting right away. Another one or two are spawned, quickly killed off by the Goblins, and finally all the Goblins return to where they started off after having dealt with those pesky Knights.

Monsters, Logic and Movement (and non-Monsters too!)

I got into some code on Encounters in the game, finally looking through my old place-holder code that had been semi-adequate for a long time and sorting out the part of the code that were acceptable, and starting to flag things that needed improving.

First thing off the bat was making the creatures have some sort of logic to guide them. I've started to split things up into different logic flows. For example, in the screen above, things are "territorial" meaning they will wander about near where they spawn, but if they get too far from that point, they'll rush back to it. There's logic for Aggressive and Passive creatures in early stages too - but what this is letting me do, is slowly develop more interaction types and consider how they might allow me to make the game more interesting. One certain thought is that one monster could alert others nearby if being attacked or attacking. I might set up monsters to have affiliations - so they might even fight one another in some cases.

I've also fixed up the code so that monsters follow the same rules as a player when they walk about the place - so no more place-holder monsters that could walk over anything they wanted. I'll keep adding and tweaking until I am happy with where this part is, then I'll solidify that into an editor interface to make this part of the encounters/monsters and shift to make the true combat aspect.

Buffs, Debuffs and Effects

Gross stuff to start with. This week has been a bit of a write-off. I had surgery on and part of the recovery process is to have stents up my nose for about a week while things heal. It means things have been going much much slower than normal, but while I've been basically going nuts with this, I've been trying to keep my minds off it as best I can.

The good news therefore is that in little spits and spurts, I've been tapping at the code around effects in game, managing them and displaying them appropriately. I also spent some time on the editor to make an interface where I can create them nicely now.

I've still got a bunch of things to do to round out the full functionality of these, but having the game randomly spam my characters with various effects while in testing to see how things work, is really making me feel like this is starting to look and feel like a real game!