Entity Construction

Last week, I wrote about an animation tool I had just begun developing. I’ve continued to iterate on this tool over the past week, extending its scope to encompass not only animation, but entity construction at large. Currently, it is capable of exporting animation and collision data, and I plan to continue adding specialized editor tools to handle component data as necessary throughout development.

In order to better understand my needs here, I wrote a tool to analyze every piece of entity markup from Super Win the Game and output a spreadsheet to help me identify problem areas. The best contenders for promotion to full-fledged editor features would be components that appeared very frequently or contained large amounts of markup text. I knew intuitively that animation and dialog components would meet both of these criteria, but I was curious which other elements I might have overlooked. Collision showed up very high in this profile, as did general scripting. Collision seemed closely related to animation, so it felt like an appropriate thing to tackle first. I will likely take on dialog and scripting around the same time, as those two are frequently intertwined as well. Another element I hadn’t considered prior to seeing these results was AI — in Super Win, AI was extremely simple to the point of being essentially non-existent, but what was there still showed up fairly high in the profile. My ambitions for AI in Gunmetal Arcadia are higher, so it’s likely I’ll want some custom tools for that, too.

The other half of tools work is getting the output hooked up and functioning correctly in the game. Once the editor features came online, I built a set of placeholder content to test these features and began implementing them on the game side. This included some fairly simple changes such as checking flags to indicate that an animation is intended to play not only by time but by velocity, as for a walk cycle or jump. A larger change came in the form of allowing multiple prioritized animations to run at once, where the highest priority one is seen on the screen. My hope is that this functionality will allow for more robust, expressive animations without the need for large sets of hardcoded cases and conditions.

As an example, consider the case where the player runs forward, jumps, attacks while in the air, then lands and stands still. In this case, I would loop a low priority idle animation throughout the entire process, but it would initially be trumped by a higher priority walk cycle. Upon jumping, the walk cycle would end and a jump animation would be played which would also trump the idle. The attack animation would take priority over the jump. (As an aside, the attack animation would also trigger code related to combat such as testing collision between the weapon and enemy entities. This will likely be one of my next tasks.) Finally, after the player lands and comes to a standstill, all other animations would cease and the idle loop would become the topmost item, making it visible at last.

Screenshot 2014-11-24 18.09.48

In fact, this example is exactly how my placeholder test content is working at the moment. This is exciting because it means I’m able to author animations for the player character in the editor and quickly see them in action. Historically, I’ve handled player animation separately from all other entities, because it has typically been a little more expressive, and my tools were not sufficient to meet my needs. In the Win the Game series, player animations were hardcoded (literally, in C++ code) based on a number of conditions. With the improvements I’ve been making to my tools, I’m much closer to being able to recreate that same behavior without having to write any specialized code, and that is a huge win.

Animation Tools

Now that I’m more or less moved out of my old place, I’ve commenced regular development on Gunmetal Arcadia, starting with some of the things I perceived as particular weaknesses on Super Win the Game.

In You Have to Win the Game, I had some fairly limited rules for authoring the hazards and powerups that appear in the world. These were written in XML markup, often using hardcoded tags that the code could interpret in a few known ways. These looked something like this:

<entity name="cash" type="treasure"
texfile="cash.bmp" texname="Texture_Cash"
width="8" height="8"
boxwidth="8" boxheight="8"
x="4" y="4" z="4"

When I began working on Super Win, I wanted to move away from hardcoded rules and towards a more full-fledged method of authoring every component that describes an entity. This took the form of an entity composition tool in my editor. This tool still relied heavily on XML markup, but it gave me greater access to each component, which allowed me to create a richer set of game entities.


This was sufficient for shipping Super Win, but it came with its own set of difficulties. Animations in particular required some esoteric knowledge of how sprite sheets were intended to be laid out. For instance, the below example illustrates how the animation for the heart beacons that appear inside the Hollow King were written.


These beacons have two states (off and on), each accompanied by a looping animation, and there is also a transitional animation to go from the off state to the on state. The markup only specifies a single frame of animation for each of these sequences, but each <frame> tag contains a “dx” attribute that indicates an additional number of frames are to be added under the hood. This is convenient in that it required me to write less error-prone copy/paste markup, but it’s not exactly clear at a glance how it’s supposed to work.

Super Win also enforced a few restrictions on animated sprites that were especially annoying when I was animating the player character. The sprite’s quad were allowed to be a different size and shape than its collision box, but neither were allowed to change at runtime, and they were also required to be centered about the same point. In the below picture, the dark magenta around the sprite is the excess image data required to fill the entire quad, and the white box in the center is the collision box. Each frame of the player’s animation contains blank space beneath the feet because of this requirement.


Lastly, I had no support for mirroring sprites in Super Win, so characters who could face either left or right required twice as much sprite sheet data.

I’m attempting to address all of these problems in Gunmetal Arcadia with the introduction of an animation tool. This tool allows me to visually select the region for each frame, adjust its location relative to the origin and the collision box, and preview the sequence.


Under the hood, this tool will produce the same sort of XML markup that Super Win utilized (plus some new elements to specify offsets and such), but ideally, I should never have to think about that side of things once I start producing game content.

I’m hoping to continue improving my tools in this way across the entire development process. Animation felt like a natural place to start insofar as it would push me to break some hardcoded assumptions I’ve been making for years, but it’s easy to imagine applying the same mentality to other systems, from dialog scripting (a nightmarishly error-prone system on Super Win) to random level prefabs for Gunmetal Arcadia.

Grab Bag

Just a quick update today, as I’m in the process of cleaning my old apartment, but I did find a little time this week to poke at some Gunmetal Arcadia tasks.

Building off the collision work I discussed a few weeks ago, I’ve made some improvements to how collision surfaces are generated from tiles. I now have the capability to insert “hint walls” at the edges of platforms. These are invisible surfaces which the player does not collide against, but which serve to notify enemies or NPCs that they’ve reached the end of a walkable space and should turn around. This is a huge improvement over Super Win the Game, which required me to place these invisible blockers by hand.

I’ve been prototyping some visual improvements for players who prefer to disable the CRT effects. There’s very little reason from a technical standpoint why the visible viewing area should be limited to a 4:3 aspect ratio in this mode. I’ve made a local change which extends the viewing space to fill the screen when CRT effects are disabled. It’s not shippable yet, but it’s feeling fairly promising. It does raise some interesting design questions, however. How should rooms that do not fill the complete horizontal space be displayed? Is it acceptable to leave blank space on the sides of the screen in these cases? What happens when you reach the edge of the room and transition to the next one? Does the adjacent room suddenly pop into existence? These are questions that I’ll have to answer before this can be a real shipping feature.

I made some changes to my Windows build process shortly after launching Super Win the Game to facilitate side-by-side Steam and non-Steam builds, and I’ve continued improving this process in order to automate it as much as I can. The dream would be to have a one-button process that can build and deploy all configurations on all platforms (six at this point: Steam and non-Steam builds on Windows, Mac, and Linux), but I’m not there yet, and I likely won’t put too much effort into solving that problem for Gunmetal Arcadia.

That’s all for this week. Next Monday’s entry may be another conceptual high-level design one depending on how much work I’m able to get done over the next few days. If you’re just seeing this blog for the first time, I’d encourage you to check it out from the start. I’ll have more specific development details to share once I begin working on this game in earnest, of course, but I’ll probably continue sharing abstract design thoughts throughout the duration of the project, as well. Those are fun to write, and, I suspect, often more interesting to read.

Rogue Souls

I’ve been in the process of moving to a new apartment over the last couple of weeks, and my development PCs have been unplugged for the last few days in particular, so I haven’t made any tangible progress on Gunmetal Arcadia this week. (That is to say, no checkins.) But I’ve been playing a lot of Spelunky and Isaac recently, among other 2D platformers and roguelikes, and I’ve been looking for things I can borrow and places where I can do something different and unique. I’m trying to figure out what it is, beyond the surface level bullet point features, that makes the idea of developing a roguelike seem so appealing to me right now.

See, I wasn’t always a fan of roguelikes. If we jump back in time ten years to my undergrad days, I was fairly averse to the genre. David had recently discovered NetHack, and despite my best efforts, I couldn’t bring myself to play it more than once or twice. Death was too punishing, too final. When I died, it felt like my time had been wasted. I remember saying that if I ever made a game like that, I’d find a way to make permadeath less frustrating.

Fast forward ten years and roguelikes are now the genre du jour among indie games. Not only that, but the genre has grown, tacking on a “-like” or two and reaching far beyond the top-down ASCII dungeon crawls from which it originated. In the same way that “X but with RPG elements” has become shorthand for “the player can earn experience points and level up,” “X but with roguelike elements” now indicates the presence of features such as permadeath and randomly generated levels.

With the explosion of roguelikes, it’s not surprising that others have attempted to temper the frustration of permadeath, often with the addition of unlockables which can improve your odds of survival. I’ll be honest, ten years ago, I probably would have thought this was a great idea, but having seen it in practice across a number of games, I’m not a fan of this solution. In some cases, I feel like it ruins the feasibility of “vanilla” runs (or cheapens their purity, perhaps), and it can force the player to grind in order to be realistically capable of finishing the game. This solution serves to mitigate beginners’ frustrations, sure, but it does so at the expense of long-time players. There has to be a better way.

Dark Souls isn’t a roguelike, but it handles death in a similarly unforgiving manner. When you die, you lose all the unspent souls you’ve collected, souls being the game’s primary currency, used both for buying goods and for leveling up. Dark Souls offers a silver lining, however: if you can reach the place where you died without dying again, you can recover these souls, effectively eliminating any punishment. This is often not as easy as it sounds, as enemies respawn each time, while items are not replenished and weapons continue to degrade. This “one shot at redemption” model works so well because it is both a carrot and a stick. The game first deprives the player of something they’ve earned, then it offers them a chance to reclaim that loss, with the caveat that one false move may cost them not only their earnings from the last round, but potentially the ones from this round too. This creates a wondefully tense dynamic. “Maybe I made a mistake, but I can still salvage this.” I love that.

So that’s how I’m approaching permadeath in Gunmetal Arcadia. Not wholly irreversible, still recoverable in some way, but not so forgiving as to be exploitable or without tension. What exactly that means is still up for grabs. Procedural level generation means that stealing Dark Souls‘s mechanic verbatim is out of the question, as retreading the same ground to find the place where you died will be impossible. (Not that I’d want to do that, right? I’m a professional game developer fully capable of inventing his own designs! Yeah!) But I’d like to find a solution that creates the same sort of dynamic, where losses incurred by a previous failure effectively raise the stakes on the next run.

In fact, I think the notion of each run being informed by its predecessor is likely going to be a consistent high-level theme throughout much of Gunmetal Arcadia. I like the idea that choices you make during one session could influence the next in subtle ways. Maybe you eschewed technology in favor of magic, so on the next go-round, warlocks are friendlier and apothecaries offer discounts on spells. Balancing this in a way that preserves the viability of vanilla runs will be important, of course. I would liken this concept more to Demon’s Souls‘s world tendency system than a grindable series of unlockable upgrades in that regard.

Historically, I’ve always a little wary of making design thoughts public too early, not because I’m afraid they’ll be stolen (ideas are cheap), but because I don’t like to run the risk of overpromising and underdelivering. (An early design for Super Win included coffee cup powerups that would make you temporarily run faster and jump higher. It didn’t fit that game’s Metroidvania nature, so I cut it.) It should go without saying, but everything on this blog should be taken with a grain of salt, especially at this early of a stage.