Saturday, 16 March 2013
Sn4ke / Grazer (PC)
Games that use procedural generation, either random or from a seed value, have always fascinated me. Ever since first playing Elite as a child and wondering how on earth a eight galaxies could fit on a single disk, the concept of a game world or design structure unfolding itself from an algorithm into memory seems like the ultimate solution to the limitations imposed by the time consuming, manually-crafted alternative. By using procedural generation, games can be huge (even endless) yet developed and delivered by small teams with minimal assets. The lack of bulky level data means that huge games can also be tiny.
Now, before you get excited about the prospect of n.h.k.'s Sn4ke and Grazer featuring gigantic, expansive worlds, let me set the record straight. They are not huge at all. In fact, they are incredibly simplistic, so much so that if judged on the playing experience alone it could be argued that they don't really deserve feature space at RGCD at all. Yet, nonetheless they are special little games, with 'little' being the key word here; combined, Grazer and Sn4ke take up less than 8KB of disk space.
In the retro scene, mini-games like these are common (thanks in part to the popularity of 1KB, 2KB and 4KB game development competitions for 8-Bit machines), but they are somewhat of a rarity on the PC. Or at least they are outside of the demoscene, from which Sn4ke and Grazer originate (released as 'wild' competition entries at ToykoDemoFest 2011 and 2012).
In contrast to development on 8-Bit machines, where coders can access the (standard) hardware directly via machine language, on a modern PC a huge variety of hardware and peripherals needs to be catered for, so common practice is to use API calls to DirectX or OpenGL, acting as an interface layer between the code and the hardware to ensure compatibility. The hardcore few may consider this cheating ("What? No software rendered graphics?") but even so, 4KB doesn't exactly leave a lot of room to play with for game logic and presentation.
Intrigued by these two ludicrously tiny games, I wrote to their Japanese based developer Hole (h013) to discuss their development.
"Both games were written in 99% C code and 1% assembler. SDL1.2 and OpenGL 2.0 were used to render the graphics, although I didn't use any OpenGL extensions. To decrease the total size of the programs, I omitted the standard library and then I had to write some math functions in assembler."
"I created these programs for the TokyoDemoFest demoparty place in Japan, and in order to qualify for the 4KB category I compressed the them using the executable file compressor Crinkler. After compression, the size of the game logic in Grazer is 2.5KB, and 3.5KB in Sn4ke. The rest of the space is taken up by the music and sound - all the graphics and level layouts are generated procedurally from code. In fact, the background objects and the foreground objects in Grazer are the almost same logic, and tricks like this help to keep the code small."
Out of the two games, Sn4ke is most certainly the more impressive accomplishment. Grazer is a very basic (yet gorgeous looking) cave flier, whereas Sn4ke is a more ambitious three-dimensional Nibbler clone, with your snake traversing a rotating globe, avoiding red spikes and eating blue orbs (each of which predictably adds an extra segment onto your body). It's a really neat effect - and surprisingly enjoyable to play, especially considering the minuscule file size. Hole/h013 went on to explain how the 3D globe was achieved;
"In Sn4ke, the vertices of the globe are generated at run time. I used a spherical coordinates system for appropriately generating each position of the vertex, and the globe is rotated by using rotation matrix from axis. It was a complicated to code, but the most complex part was the moving snake logic."
Also impressive is the fact that both games feature sound and music. Tracker format is the obvious choice for such a tiny executable, but even so, you still have to include a playback system in your code;
"In Grazer, BGM is synthesized by '4klang' (very small software synthesizer for 4KB programs) and I used the Renoise tool to make the music because 4klang supports it. In sn4ke, at first I used 4klang but the size became larger than 5KB! Then, I wrote a software synthesizer myself and composed the music directly in the source code. My software synthesizer is very limited and supports only square wave, sine wave and sawtooth wave."
In conclusion, neither game will keep you entertained for long, but I'd still recommend that both should be at least experienced once as modern day curios. As such, it's impossible to give them a traditional RGCD 'Atari joysticks' score, as what would you base it on? The technical accomplishment or the gameplay?
With today's gaming shift from the PC and super-console to less powerful handhelds and phones, there are valuable and seemingly forgotten lessons to be re-learnt here. Efficient code and game design using procedural generation saves on disk space and download times, and although the algorithms can be initially more complex and time consuming to program, the end result can be either endless gameplay with a unique play experience every time - or simply a seed-based design that saves the developer from time-consuming level and world creation.
Download the games here (from Hole's web site).
Download the games here (from the RGCD server).