Monthly Archives: November 2014


Things have been a bit chaotic with the holidays, but I have the inter-entity collisions basically working. I say basically because they detect each other properly and they block each other properly, but some issues have come to light regarding how they interact which I’m still figuring out.

When I designed the entity update system, I made one big dumb assumption, which was that entities would not change except by their own code during their update loop. Obviously, any kind of entity interaction breaks this assumption badly. If I’d realized that I was making this assumption in the first place I probably would have seen that coming, but it didn’t occur to me. We can probably chalk that one up to a lack of experience. Anyway, as a consequence of this misplaced assumption, the player entity’s info, after being modified in the inter-entity collisions, isn’t visible to the player until she goes through another complete update loop, by which time a lot of that info has been reinitialized. Thus, even if I tell her she’s standing on a floating platform, she can’t hear me because by the time she checks to see whether she’s on a platform another behavior has written over that with info telling her that no, actually, she’s still falling, because no platform has been found yet.

Today’s work time was spent half figuring out that this was what was going on and half trying to ponder some kind of a solution that didn’t break anything else, and I think I’ve arrived at one. Basically, I’m going to flag each behavior as either unsynced or synced − unsynced behaviors work exactly as behaviors do now, where I iterate through each entity and iterate through each behavior of that entity through until I reach the last behavior of the last entity. Synced behaviors, however, will stop after updating, then iterate through all of the other entities that possess the same behavior until they reach that behavior and update it before proceeding as normal.

This may cause some issues and may be a bit tricky, particularly in instances where a synced behavior is encountered while updating to sync with another behavior, but it seems like the most logical solution and shouldn’t require me to tear up a lot of existing code, just get this one bit of logic working. Once I get this working, I can then settle in on the more specific applications of this work, such as moving platforms, destructable walls, and melee attacks.


Not a bad week. Created an inter-entity collision behavior and a system whereby entities can interact with each other, both of which will be necessary to get attacks working. I actually ended up using the same kind of stacked enum faux-assembler that I had been playing with for my Color class, so that time may not have been entirely wasted — though, in point of fact, I looked up a haxe real-time script parser that I could also potentially use today, which probably would be a more flexible solution, so who knows? That’s not important at this point anyway: What’s important for now is that the entity collision behavior is in place.

The question is, does it actually work? And, uh, for various reasons the answer to that is a little bit slow in coming. There were bugs in the entity editor I had to fix. Then there were bugs in the level save code I had to fix. Then there were bugs in the game initialization code I had to fix… And so forth.  It was an experience rather like building a working airplane in your garage and then opening the door to find that you’d absentmindedly left a pile of rocks in your driveway. Well, I think most of the obstacles have been taken care of now, and there’s just one problem left before I can give this behavior code a proper test run: Getting the level to actually recognize when it’s fully loaded and place all of its entities.

It’s a rather tedious problem, just a sequencing error. Right now the initial level is made active as soon as the file is loaded but before all of its secondary data (details, entities, background) is fully loaded. The challenge is making sure it knows when it’s finished loading, which is actually surprisingly tricky since there are so many little moving parts. I suppose an easy solution would be for it to just check periodically, but that would be messy and inelegant — and, moreover, doing this the right way from the bottom up will make any future changes and improvements that much easier to manage.

Well, it shouldn’t be that much trouble, but it’s somewhere in between amusing and exasperating that I keep getting blocked trying to do the simplest things by hiccups in the code. Still, each time I fix something like this it feels deeply rewarding, like sanding a wooden surface until it’s perfectly, pristinely smooth.


Since I’ve been kind of in-between major components of the game, I’ve been spending time just looking through my code, figuring out things that need doing, pursuing components which are, perhaps, not particularly vital to the project but are personally interesting, and just generally dicking about. Somewhere in between procrastination and vital work, smooshing bugs where I find them, noting down things to pursue when I get a chance, and thinking probably way more than is actually practical about fancy expansions to my color class.

I’m about ready to settle down to my task list, though.

By far the most pressing thing on the list is getting melee attack registration working. It’s a bit odd that I’ve put it off for this long, but I kept being unsure exactly how I wanted to proceed and tabling it for later. Given the experience I’ve had over the past week looking through the byzantine horror show that is some of my old code, I suspect I may in fact be better off for this delay. The two big questions that have stalled me are a) how do I make a system for precise collisions that aren’t tedious pixel-by-pixel affairs that bog down the code, and b) how do these collisions interact with entities?

Today I think I’ve arrived at some satisfactory answers.

To the first, It occurs to me that rather than going through pixel-by-pixel, I can easily skip through and, in the case of any objects that aren’t weird lattices or anything, have detection that’s still pretty accurate while expending 1/16th or less the processing time. Since only a few of these are likely to be processed per frame, that should be entirely satisfactory. To the second, I think it makes sense for each attack to be its own entity, even if it only exists for one frame, and to then apply its damage to any enemy entities that it can detect collision against. This is a particularly appealing approach because it means that projectile attacks should be able to be implemented in a fundamentally similar way, just replacing an instantly-disappearing attack entity that collides with everything in its range with a fast-moving attack entity that destroys itself after the first object it collides with.

I’ll be working on these behaviors over the next week, as well as keeping an eye on what modifications will need to be done for other kinds of entity collisions such as for moving platforms and destructable walls. Once I have that stuff working, I can see about building a test level with enemies and tuning up the basic gameplay, as well as adding any additional animations that will need to be created for the new interactions. I’ll probably be bouncing back and forth between that stuff and adding the remaining features to the code base for at least the rest of the the year, but once I hit that point I should have a rock-solid base to expand upon.




The first thing I did this week was throw together a rough list of the programming tasks remaining to be done:

  • Game-state changes (recording defeated enemies, found items, triggered events, etc)
  • Attack registration and collision with entities
  • Dialogue management
    • Text captions
  • Animation registration points and derived effects
  • Improvements to Tile Editor:
    • Option to automatically link tile appearance to tile shape
    • Fix alignment issues w/ menus and dropper
    • Add ability to invert collision mesh within selected area
  • Manage loading levels better (consistent & simple) – currently is inconsistent and unreliable
  • Manage loaded level assets (particles etc) better – figure out when the best time to pre-load is
  • Main menu
    • Load game
    • Multiple profiles
  • Improvements to Particle System
    • Can be spawned by entity events
    • Can play sound
    • Collision with defined shapes (must be efficient)
    • Spawn masking
  • Dynamic zoom?
  • Graphics post-processing? (offload to C++ sub-program?)
  • Special effects
    • Reflective floors
    • Water reflections/rippling
    • Screen shake
    • Basic lighting
      • Lighting editor?

The second thing I did this week was tenuously start working on one of these and get completely sidetracked onto something else that I thought was interesting. I ended up spending several days in a row developing a class for working with colors, one which I kept coming up with ideas for, new features and optimizations and improved interface tweaks and so forth. I actually still have several ideas for additions which I may revisit at some point, but for now I’m moving on.

So, first up I’m going to be tidying up and adding a couple of features to my tile editor, then I’m probably going to start figuring out attack registration since that’s the only missing component of the core gameplay. Maybe it’s kind of weird to get sidetracked for a week on making a fancy color class, and it may be a long time before that work ends up paying dividends if ever, but I’m still happy I spent that time on it. It was good practice, and it added another tool to my growing toolbox – one I will probably find many uses for in the future.


Detail editor is done. Finally.


it’s not perfect, but it works reasonably well. I’m sure that when it comes time to actually build levels and stuff using it I’ll find tons of issues that need fixing, both in the editor and in the particle systems themselves, but there’s no point in investing a bunch of work now in uncovering problems that will make themselves obvious later.

So what’s next?

I’m going to spend a day or two going through and building a task list of improvements and polish to make on all of the other editors, and then go back to the overall programming task list I made so long ago and flesh it out with what still needs to be done and cross off what no longer needs to be done. The biggest thing left is attacking and hit detection, which I’m going to have to start seriously pondering how I’m going to implement.

This is a bit of an awkward time. A moment of reflection. Getting close to two years of regular updates, I feel simultaneously like I’ve come incredibly far and done nothing at all, and I think those are both justifiable impressions. I think I’m getting closer, though… even if slowly, I’m getting closer.