Jam Development Overview

CGA Jam is over - huge thanks to @DavitMasia for running it - and my entry is finished. This devlog is to explain the process that went into creating my entry, Tiny Frontier Saga. The game itself is a side-scrolling coffee-break roguelike set in the Wild West, with cute pixelart graphics and three original chiptunes in the soundtrack by Robert Keder ( twitter.com/@kedercrea... ). It plays on mobile and desktop, directly in the browser, and was written in Construct 2.

DESIGN

I suppose like a lot of jam entries, Tiny Frontier Saga wasn't necessarily designed. I conceived of maybe a dozen games over the course of the jam, but didn't enjoy any of the prototypes I'd made. It wasn't until there were 48 hours left in the jam that I pivotted what was a gritty top-down cover-shooter into a roguelike. I conceived of a simple system whereby the player had no inventory concerns except switching active weapon, and a basic arcade-style health bar would serve for player status. Restricting the action to only moving along the X-axis made it a side-scroller, further firming up its retro credentials and simplifying the rogue formula. Finally, it needed a setting - and of the available themes in the jam ('Always Faster', 'History Repeats', 'Gravity' and 'Wild West'), there was a clear winner.

SOFTWARE

I exclusively use Construct 2 - I don't have a line of code in my head, other than a few bits and bobs of bash. So my choice of development environment was restricted to just that - which is lucky, because it suits the purpose just fine. It can happily handle thousands of objects, large tilemaps, and a few systems like line-of-sight were gimmes thanks to included plugins. Its in-built sprite editor is more than a match for the simple pixel aesthetic. I used SFXR ( www.drpetter.se/project_sfxr.h... ) for creating my sound effects. Robert, who kindly wrote the music for this game, combined the NES sound-font and some drum samples he had lying around on a digital audio workstation.

DEVELOPMENT

I'm a fan of roguelike games and, although I've never made one before, I've made a lot of prototypes for similar designs. I started with what I knew best - the procedural generation. I knew I wanted the play area to be new every time, like a roguelike should. Thankfully, this is my favourite area of game dev - I've even got a toolkit ( chilly-durango.itch.io... ) for expressly that purpose! I pressed it to work to create the environment I needed - a long street with houses coming off it. It identifies all the different parts of the map for function and decoration on start - then I added a few events to vomit this out into the game-space. Enemies, loot, hazards and shops are all created in this stage, rather than in the generation stage.

Once I had an environment it needed artwork. My GBA Jam entry, Tiny Town Saga ( chilly-durango.itch.io... ) , was really well-received for its art style, so I thought I'd start by revisiting that. I cribbed elements of the tile- and sprite-sheet and converted them to work with the CGA palette. It was at this point I realised that I despise the CGA palette, and that I would do better with any three of those colours than with all four. I'm not too shocked to see quite a few other contestants in the jam came to the same conclusion! I eliminated green, leaving black, pale-yellow and pale-red. This made some art jobs easier, and others a lot harder. In the end I recycled the running animation and some tiles from TTS, and the rest of the art came from scratch.

After introducing a simple animation stage and testing it with a player character, I added enemies which moved randomly. When the player moves, a decision is made for all other enemies as to their actions. This is a simple process - a list of options is made for each enemy (Can they see the player? If so add the option 'shoot'. Is there a wall to their left? If not at the options 'left' - and so-on), and a random selection made from that options list. If an entity decides to fire, their ID and their targets ID is added to a 'shots fired' list, which is then read in sequence during the animation stage that follows, to ensure everyone fires at a separate moment. The player always fires first.

After scattering loot everywhere and making it effective, I spent a while on trying to make sure the game felt 'fair'. Making sure the ratio of gold/bullet/health drops was good, the distribution of enemies seemed acceptable, and so-on. Ultimately a LOT of the game hinges on random chance - so this was not an easy or a definite task. I'd often have to re-run generation a few dozen times between changes just to ensure a change had actually taken place. Once I tired of this and the game felt playable, I shared a link on /r/roguelikedev looking for some feedback and suggestions from other developers, which was very valuable at the time.

After that session I added the dynamite barrels and whiskey pickup, which changed the nature of the game again. Your run could now hinge on one bad barrel cluster, or one surfeit of whiskey - so again I had to re-factor. Before doing so, I let the game get to breaking point on bugs by adding an upgrade shop. A comma-separated value string variable attached to the player tracks active perks, and a graphical overlay handles the shop itself. I only left it this late to add the shop as I was intent on providing a dedicated space to transact within the game - like the shops in the old Zelda games. Ultimately I don't think handling the shop with an overlay is the worst compromise and is, if nothing else, clean. It also made it easier to integrate other vendors (a Craps table was added post-jam).

It was also around this time (24 hours remaining in the jam!) that I realised I didn't have any music. I reached out via Twitter, and met Robert Keder. We had a two-tweet discussion, and the next I heard from him was an email with a song file attached. I love game-jams for this - artists, musicians and developers can end up collaborating at such short notice. I can only thank the bout of flu that gave Robert the free time to work on these songs! Anyway, the fact that this game even has music at all is a testament to the power of reaching out to people and asking nicely!

I happily left Robert to continue making songs at his leisure, and I would find them places within the game. I performed a final re-factor, and added as many items to the shop as I could think of. Some have back-ends in, but didn't make it into the game - for the usual reasons: too overpowered, too pointless, or too complex. With time left in the jam, I revisited player feedback and attacked the most-mentioned issues (that wouldn't require another refactor!). Although I had uploaded a safety earlier in the day, I submitted the game with eleven minutes remaining in the jam.