EverEnding DevBlog 152: Conditioner


This was a programming kind of week. Very quickly into trying to implement the throwing animation I created last week, I realized that my current system for creating animation commands wasn’t going to cut it. The system, as it existed then, was that each animation was associated with a list of status flags, the entity behaviors would set and unset those flags, and it would select what animation to play from the list by choosing the highest priority one with valid flags. This required me to do a lot of weird workarounds, like breaking the name of the currently playing animation up into a bunch of tags which were set to status flags so I could properly transition animations, and setting each animation frame as a special status so that I could sync sound effects to a specific frame. It worked, but it was becoming clear that the more different options an entity could choose the more of a clusterfuck all these extra status flags were going to become – and, when it comes time to create a boss enemy who has 5-10 attacks available as well as all the other special animations, it just didn’t seem like a feasible system long term.

So, I created a new system. This system still looks at the entity’s status, but instead of just looking for true/false comparisons it can do a number of basic comparisons with the status value against any arbitrary comparand. Now, rather than breaking the file path into string statuses that I check individually, I can just check if the current animation path value contains or doesn’t contain a string. Instead of setting each frame as a status I can just check if the frame I’m on is equal to 6 or 15 or whatever. Rather than setting a ‘running’ status when my entity’s movement speed exceeds a certain threshold, I can compare against its x velocity directly. It’s pretty handy!

Also, in the process of building this new conditional system I ended up generalizing some of my save/load code, pulling out everything I’d written for my entity template class to convert raw data into xml values. This is also likely to be something which helps a great deal in the long run, since this sort of thing comes up often: Any time now that I don’t know the specific type of data I’m about to save to xml, I have this tool to help. So that’s also a side benefit. Heck, I’ll just throw it up on Pastebin now in case anyone could use something like that.

The throw animation I created last time looks good but I think I need to add new frames to it, so that means I’m probably going to have to import it back into Photoshop so I can recreate it – having, as I mentioned last week, accidentally failed to save this current revision. I’ve also noticed a bunch of funky problems with the entity AI, which were subtle enough to evade my notice for a while but which I’m noticing more and more as I test. Once I address both of these, this version of the enemy should be pretty much up and running. The next version should be trivial, since it’s a fairly natural extension of the first two versions… but, you know, I’m sure there’s something I’m forgetting now which will make it a pain in the ass, because that’s how these things go.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: