My story is not so different from any kid who found themselves in the middle of the 1980s as a ten year old, seeking new ways of quenching endless imagination and curiosity via movies, invented real-world games, drawing, arcade games, and eventually the home entertainment experience via the Commodore64. Each new game purchase, since usually spaced out by a
few months (in most households), seemed to bring very big technological advances with graphics and sound as the magical people making these games in the UK and Europe gathered more and more knowledge in regards to squeezing more wizardry out of the sound chip (SID) and also the graphics hardware (VIC).
For the last ten years or more I have gradually managed to get back into the nitty gritty of making graphics and music on the Commodore64. During its actual peak phase I had an enormous interest in music and sound on the machine (1984 to 1989) but never managed to delve deeply enough to get into the music tracking software that slowly emerged enabling hands on composition with the SID chip.
As with most kids of that era, the allure of the machine was the other-worldly sounds that emanated from the ever expanding range of games that were appearing on the machine. Andrew Braybrook’s metallic bas-relief suite of games (Uridium, Paradroid, Morpheus) managed to express a great mechanical and technical aura of sophistication amongst a plethora of comparatively ordinary games on the machine. Eventually SID composers such as Rob Hubbard, David Whittaker and Martin Galway managed to squeeze an unfathomable amount of detail out of a relatively simple sound chip. Eventually the focus shifted around 1987 to the enormous game catalogue that developed for Commodore’s AMIGA range of computers, however a soft-spot always existed for the purity and sheer cottage-industry dynamics of the Commodore64.
In an ever-growing network of friends that I had made via the demoscene I managed to inflict my obsession with both abstracted character / text art and the isometric viewpoint. After years of sharing all of my experiments, I occasionally joked to Brandon Williamson (Eryngi) that we should attempt a small game of sorts incorporating some of the graphical ideas I had been amassing. A few times he expressed an interest but time constraints meant that it was tricky to think of a way to implement actual gameplay code and elements. When the ACMI microgame commission appeared I thought it would be an ideal opportunity to pitch the concept of a game that is very much built on a legacy / retro system but that could still manage to have some modern appeal and accessibility.
Once ACMI had green-lit the pitch I made using some completed screens and a narrative that I had developed quite some time ago, we set about configuring some first steps to make this game actually happen. My approach was that the large isometric map would act as a touchpoint from which everything else branched.
The lore of the game itself was born of a want for a game mechanic that avoided “shooting bad guys” tropes and focused more on altering the playfield with the use of colour.
Both myself and Brandon have always been drawn to unusual and original game interfaces both with historic and modern games. In the 1980s the cottage-industry nature of programming and game development resulted in both some supremely ordinary concepts as well as some highly original and innovative gameplay mechanics. In stark comparison to modern game development, often from concept to final product - the games of this era were shaped solely by the imagination and curiosity of one imagination (usually the programmer).
Additionally in the case of near-ploymath coders such as Andy Braybrook (Paradroid, Uridium), Jeff Minter (Return of the Mutant Camels, Iridis Alpha), Stavros Fasoulas (Sanxion, Delta), Anthony Crowther (Loco, Gryphon, Suicide Express), Martin Walker (Hunter’s Moon, Chameleon), and Manfred Trenz (Turrican, Denaris) they were capable of generating all the graphical content of the game - often just needing sound effects and music at a later stage of production.
I think in this vein, we knew that our gameplay would be dictated by the style of the large map that I had partially already completed, so what followed was a series of decisions that were shaped upon restrictions of memory and code.
Games such as Cycle Knight, Realm of Impossibility, The Sentinel, Zig Zag, amongst others were absolutely direct influences in that they all have unusually original concepts and gameplay.
◌┈┉ T H E P I T C H ┉┈◌
The map itself for the game incorporates elements of a series of different pieces that I have made over the years. Luckily the individual styles of the isometric themes were fairly close in dynamics and feel, so the next step was to stitch it all together with some more simple textural aspects and combinations of characters. With admittedly a nod toward the eBoy aesthetics of the 90s, the isometric/axonometric viewpoint allows much more scope for complexity of detail and design. This however presents the dilemma of how this relatively complex landscape can be interacted with on a machine that is not renowned for complex physics or tactile interaction between graphical elements. Colour was always going to be an integral factor of the game with the initial concept revolving around individual colours being used in place of weapons/shooting dynamics in favour of painting/colourising the landscape.
Both the character set design and level design were all made possible for Salix8 Sunset via James Reid’s amazing LVLLVL text art editor that I helped to beta test and design. James passed away before the game was finished but I thought it fitting to dedicate it to his memory.
Can a static terrain / cityscape evoke narrative? Perhaps not actively, but it can passively and visibly communicate perhaps a history of sorts of the environment that you find yourself placed in as the player - in terms of gameplay. We discussed quite a few dynamics and mechanics that could work from within a single large map. Branching of secondary gameplay elements from tangential “portals” that act as sub-games, but still hold a mechanical purpose that brings elements back into the gameplay of the main map. Ultimately we had to settle with each “portal” granting your spacecraft the ability to permanently colour the maps as you shoot your paint bombs, and the consecutive portal visits allowing your paint bombs to coerce the large “vandergraaf” blobs off the map (as their presence allows them to negate your efforts to colour in the map).
◌┈┉ C H A R A C T E R S E T S ┉┈◌
The way in which graphics are set up on a Commodore64 dictates that pixels can be displayed via character sets or via bitmap images. There are many colour restrictions that differ between graphics modes. The entirety of the map in Salix8 is constructed of singular tiles from a tile set of 256 characters that I designed to mimic an isometric viewpoint. The character set in yellow below is the set of tiles from which the entire game map is drawn. Some variations in character sets were used for the “portal” cut-scene sections as well as the narrative and title screens. We chose to use the standard graphics mode that allows a full 256 characters of any colour from the full palette - however this means that each tile or character must all have the same background colour (in this case black - or transparent).
The Commodore64 allows a maximum of eight hardware sprites to be displayed at any time as an overlay of sorts over all other graphical data / background graphics. The majority of game mechanics consist of sprite interactions (bullets, objects, explosions, main characters, enemies, game elements etc.) and there are a number of tricks that can be used to squeeze even more value out of these hardware sprites. Initially we had hoped to have a main spacecraft that could have a more varied dynamic of delivering “colour bombs” to the landscape but time constraints only allowed a simple directional “splatter” of colour bobs.
The Commodore64 as with any micro-computer of the era (early 80s) suffers from a distinct lack of available ram and resources. As the cycle of development progressed from cassette-load game to floppy disks, more graphics and assets were made possible with the development of disk-loading tools that could stream new music and graphics whilst the game was “live” as opposed to single-pass loading from cumbersome cassette mechanisms. Eventually cartridges became a more dynamic tool for game development with the evolution of the “Ocean framework” cartridge in the later stages of the 1980s. We chose a more obscure cartridge format that was pioneered by Commodore themselves called “Magic Desk Cartridge”,
The primary issue with a scrolling isometric game on such a limited system is dealing with a memory buffer to give the illusion of a large map (there is no way the entire map could be held in C64 memory at any one time). Other issues present were whether another graphics mode than standard single-colour background per tile could be used (ultimately alternate graphics modes were only achievable on the cut-scene graphics). Over to Brandon in regard to his journey coding for the C64:
Brandon: I've been learning Commodore 64 assembly language for a couple years, so I was excited to put it to use to make Salix8. I usually draw all the artwork myself for games I make. Being able to work with Tim and his rich work history of original C64 art was great! Though a bit of a steep learning curve, incorporating existing art in various formats into my code.. Here's how it went:
It became apparent early on that because of the high detail level and large size of the maps, we'd have to use a cartridge format for this game - The main map alone is so large - around 50kb - it takes up most of the C64's RAM. And because of the colour painting mechanic of the game, we needed two copies of each map (one greyscale, one coloured - these could be stored in cartridge ROM as they only need to be read-only), plus a third copy (the "live" painted map containing a mix of the coloured and greyscale versions, needs to be read-write and persistent, so must stay in RAM for the whole lifespan of the game). So we went with a 512kb cartridge format, storing all the map data in ROM as well as much of the code.
Because of the way C64 cartridges work, you can only access 8kb of ROM at a time - you switch ROM banks in and out as needed, to access the 64 possible different 8kb banks in a 512kb cart. Since the main map is much larger than 8kb I had to cut it up into unnaturally sized slices and spread these over many ROM banks, and then continually bank switch as the player scrolls around, to load the required bits of map data.. This made the map drawing routines take a few more CPU cycles than they ordinarily would, which made it impossible (for me at least - an experienced C64 coder could do it I bet!) to have music playing at full speed simultaneously with scrolling the map. It took a few weeks of messing around but I eventually got all this working nicely.
Salix8 is planned to be expanded to have some more gameplay mechanics and scope in regards to gameplay with more expansive maps or variation in the landscape and gameplay mechanics. Music is something that was just a little too difficult to squeeze into memory / rastertime so hopefully each “oracle” will have its own SID tune in the future. Since the implementation of the Magic Cartridge format was purely digital with the ACMI version of the game, it would be apt to do a physical build of the game on an aesthetically pleasing cartridge that could also include other functionality such as reset switches, LEDs that alter according to gameplay events etc.
Salix8 at ACMI
Official Salix8 poster
Sydney Morning Herald article
Article at C64 Universe
