Post news RSS BIT RAT - Tasty Can of Worms Part 1

Massive graphical updates, stress testing the cut-scene engine, game-world nuts and bolts, refactoring galore! And, uh, something about juggling responsibilities.

Posted by on

Hey hi! We've been so deep in BIT RAT's code these past few months, we hardly realized we haven't posted any updates. We'll do our best not to let it happen again (coughs, rolls eyes). In the meantime, here's part one of a series covering our recent progress.

Mastering the Ultravision

One of the ongoing quirks of our dev process (an inevitability of our being new at this? or is that self-flattery?) is that we've had to repeatedly rethink our visual approach as our skills evolve and we implement the features we dreamed up in the early days of the game.

Our prototype was full of funny placeholder graphics, some of which got re-designed almost immediately, many of which stuck around until they became glaring, then hideous, then terrifying because they forced us to update core code and grapple with our still-rudimentary level design. A perfect example of this is the in-game MINOS terminal, the hub from which data springs eternal in each puzzle.

Way back at the beginning, MINOS looked like this:

I know, mindblowing, right? The terminal didn't even have a real name, just "COMPUTER". Before long, of course, we realized a static sprite wasn't going to cut it. Our "transfer" mechanic -- the ability to relocate the start room in a puzzle with multiple terminals -- necessitated ON and OFF states for each machine. More importantly, if our AI was going to be a character in the game, we needed to infuse it with a bit more... personality:

Beautiful. So MINOS was born. Not long after, we also decided to scale the whole game down to 640x360. This meant all graphical assets had to be reduced to half-resolution, and in the great majority of cases, redrawn. Never have pixels seemed so precious. As we worked, we also attempted to develop a more coherent palette -- a little cyberpunk, a little EGA, a whole lot of cheating.

When we were finished mashing our sprites into bite-sized grids, we'd made substantial progress, but something still wasn't right. We needed to stop thinking of our game assets as abstract symbols, and start conceiving of each piece as an entity within a fully-realized world. This process of integration stretched over several weeks of false starts and minor revelations.

Finally, we were getting somewhere! As you can see, I did get a little carried away with the rat thing for a while, but in the end we erred on the side of not shoving that metaphor quite so vehemently down peoples' throats. The important thing was, MINOS had gone from looking like a vengeful flying Commodore to something you might actually find rusting in an obsolete server room:

After six months and a dozen iterations, we had a design that honored the story we were crafting. The only problem now was that it was all a bit... boring. The more "realistic" our rooms got, the more they seemed to lack the spark of life we were hoping for.

Pondering a solution, we returned to several long-dormant ideas: animated background assets, modular environments (e.g. room features that could be mixed and matched in the level editor), and passive sprites that responded to player input. All of these features had crossed our minds, but we'd always shelved them in favor of more pressing concerns. Now they seemed more necessary than ever, and the keys to their implementation were buried in some of BIT RAT's oldest and messiest code.

Endless Dithering

Since our earliest prototype, all of our builds had used the same simple image switching to handle grid power states. With the exception of MINOS, generators, and a few other assets, all background content was "baked" into static sprites, each with a single ON and a single OFF option. For any given turn, we displayed the appropriate index from the pair, and that was the extent of the system.

In order to support animated environments, we had to dismantle not only this sprite code, but every single existing room asset. For the next few weeks, we worked to separate desks, server racks, televisions, chemical spills, and laboratory equipment into discrete units, gradually honing our palette and drawing techniques to take full advantage of the new system. From there, we began coding an engine to manage everything, transforming static graphics into dynamic entities with independent behavior and motion patterns. Along the way, we ported our level initialization system from INI files to JSON key/value maps that better support complex visual design.

By the time we were done, we had essentially re-written the game's sprite management functions from the ground up, along with a flurry of bug fixes, refactoring, and trying to make sense of the spaghetti lurking in our codebase. We're feeling pretty pumped about where we've ended up:

Prying Up the Floorboards, Cont'd

Of course, this whole process is only one part of what we've been chipping away at these last few months. In the next installment of this series, I'll delve into another huge project whose development helped lay the groundwork for the new sprite system: our cut-scene engine and editor!

Onwards to Zone 2...

Stay tuned, and thanks as always for following our progress!

-bryan and Nick

Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.