Even today, people still continue to create new games for old consoles. We call them homebrew . Sometimes this is a way to realize a childhood dream of creating a game for a console that a child played on. But in addition, it is also an interesting task for any designer or game developer: retro-iron had many limitations that challenged the creativity of the authors. In the 90s for professional developers, these restrictions were familiar. Today, when we have more advanced tools, the creation of games for such machines has become much more affordable.
Last year I wrote an article about creating a game for Game Boy . Today I will share my experience in creating three games for the SEGA Mega Drive / Genesis home console. Probably, thanks to modern powerful tools, this is the easiest machine to develop a homebrew game. For example, I even managed to create a (very simple) game in just 60 minutes, and it actually runs on the console!
Games
Last year, to mark the 30th anniversary of the release of Genesis / Mega Drive, I created a game called 30 Years of Nintendon't . As the name implies, it is a tribute to the best console games and the aggressive marketing that SEGA used at that time (for example, the slogan “Genesis Does what Nintendon't”).
In this game, we control the SEGA evangelist, who must convince players to forget about their NES and SNES, because Genesis games are better! The game was released free online on the console’s 30th birthday. You can play it here: https://drludos.itch.io/30-years-of-nintendont
Since then, I have also created two (small) arcade games for the console:
"Break An Egg"
"MeteoRain"
All of these 3 games are sold on a cartridge published by Cote Gamers:
http://cotegamers.com/shop/en/genesis-mega-drive/43-test.html
It comes in a beautiful plastic box, like real vintage games, and with a set of postcards.
Can I use Unity, Unreal Engine or Godot?
Sorry, but these engines are not able to export games to SEGA Mega Drive / Genesis (maybe for now?). But don’t worry, there is another tool that is just as useful as these popular modern engines, and at the same time it was developed specifically for Mega Drive / Genesis: SGDK . This is a framework that allows you to write code for this machine in the C language. It is much simpler and faster than learning the assembly language, which was mandatory in the 90s. But that is not all. SGDK also has tools to simplify the creation of graphics and sounds. You can create graphics in your favorite 2D graphics editor (from Photoshop to GIMP or Asesprite) , and it will be converted automatically if you comply with hardware restrictions (more on this below). The same applies to sound: you can create sound effects in .wav files, and use different trackers for music. One last thing: SGDK has a powerful “Sprite Engine” that simplifies most of the technical tasks of displaying moving images on the screen. But how "simple" is it in reality? In the article I will talk about my own work experience.
Blast Processing appears on the scene
As any programmer of old systems will tell you, if you write a program in C instead of assembler, this will reduce the performance of the game. And it is true. But the costs in different retro consoles vary greatly. They depend on the CPU used, as well as on the efficiency of modern compilers that create code for such vintage processors. Fortunately, Mega Drive / Genesis uses the Motorola 68000 processor, which is quite well suited for working with the features of the C language. This is especially true in comparison with other CPUs, for example, with the 65816 SNES console. Although powerful in and of itself, it is difficult for SNES CPUs to execute programs written in C with sufficient speed. That is, when it comes to C homebrew development, “Blast Processing” is not a marketing myth, but a reality!
How fast can C code run?
Here is an example from personal experience - an animated GIF of my MeteoRain game, in which sprites of 45 meteorites move without delay at a frequency of 60fps:
Here is another example of an explosion from Break An Egg, consisting of 40 particles moving at a frequency of 60fps:
If we take old games as an example, then a good example of the power of Mega Drive / Genesis CPUs is Contra Hard Corps. Although the game was developed in assembler rather than C (after all, it was in the 90s) , developers could use tremendous computing power to move many sprites across the screen and create catchy bosses with tons of moving parts and massive explosions.
For comparison, Contra III on SNES was limited by CPU power and instead of moving the heap of sprites Konami used unique graphic effects that only the SNES video chip was capable of, for example, the transparency effect.
Although both games are equally interesting, they perfectly highlight the technical differences between SNES and Mega Drive / Genesis. More information on how Konami created each of the games under the corresponding console can be found in the article “Making of Contra III and Hard Corps” from Retro Gamer No. 176 .
Graphical restrictions
Since computing power is not a problem, the main bottleneck of the Genesis / Mega Drive console for homebrew developers has become its graphics limitations. And more specifically, a limited number of colors displayed by her. Although in general the console can generate 512 unique colors, at the same time there can be no more than 64 colors on the screen. Oops For comparison: SNES could display 256 colors simultaneously from a palette of 32768 unique colors. That is, graphic artists needed great talent to make SEGA games look as good as competitors' consoles. And in many cases they succeeded. Despite color restrictions, many older Mega Drive / Genesis games look beautiful, like Comix Zone, the Story of Thor, Streets of Rage II, Ranger-X, Gunstar Heroes, Sonic 1-2-3, etc.
Comix Zone (1995)
But in other cases, Mega Drive / Genesis games looked rather dull compared to the SNES versions. One of the most famous examples is Street Fighter II, where the color restrictions of the console are very noticeable:
The optimal use of limited palettes (4 palettes of 16 colors for Genesis versus 16 palettes of 16 colors for SNES) was a big challenge for developers who usually had very little time to complete projects. Today, talented members of the SEGA community are able to modify some games to optimize the use of colors. For example, Gabrielle Piron does wonders with games like Castlevania Blood Lines, Golden Ax, Outrun, or the aforementioned Street Fighter II:
(Above is the color palette of the original, below is a modified Gabriel)
With this in mind, you can use your favorite image editor to create images, but be very careful when choosing colors! If you fail to match the 512-color palette flashed in the equipment, then this is not a problem: SGDK automatically converts the image to the Mega Drive / Genesis palette. But when it comes to the total number of colors used and displayed on the screen, then you have to do it yourself!
Making objects move
To display something on the screen, you need to copy the graphic data from the ROM to the video RAM. The GPU does not have direct access to data in ROM, but is able to read data from RAM. Therefore, in order for the background or animation of sprites to change, you need to regularly copy new data from ROM to RAM. And the total number of video RAM (VRAM) is limited: only 64 KB. Compared to the size of gaming ROMs (from 512 KB to 8 MB), this is quite small.
Bottleneck # 1: VRAM Transfer
If you create a very small game with a small number of graphic elements, then you can simply once and for all load them into memory when the game starts. But most games need to regularly refresh the graphics in VRAM to demonstrate various animations. And usually it causes a lot of problems!
The amount of graphic data that can be transferred from ROM to VRAM in each frame (i.e. 60 times per second) is limited. More specifically, these are 7524 bytes per frame, i.e. about 7 KB. When you need to display huge animated sprites plus animated backgrounds, like in Street Fighter II, then this restriction constantly interferes. And this is only the first problem.
Bottleneck # 2: sprite restrictions
For 8/16-bit consoles, another difficulty lies in the total number of sprites that the equipment can display. There are usually two limitations: one for the total number of sprites on the screen, the other for the total number of sprites in one horizontal row. For 8-bit consoles, such as NES and Master System, these restrictions are very severe: no more than 8 sprites per horizontal line, and the total number should not exceed 64 sprites. Does this mean that we can display on the screen 64 times Sonic or Mario? No, I mean "hardware sprites", which are smaller than what is usually called a sprite. Here's an example from Super Mario Bros for NES, where it takes several 8x8 pixels of hardware sprites to display a single Mario sprite.
(Source: https://nesdoug.com/2018/09/05/06-sprites/ )
For 16-bit consoles, sprite restrictions are slightly reduced. Mega Drive / Genesis can display up to 80 hardware sprites. But a separate hardware sprite can have a size of up to 32x32 (previously - only 8x8 pixels). Here are some examples of cutting "hardware sprites" on Mega Drive / Genesis. Did you notice that Sonic draws out of just two hardware sprites, while Mario on NES needs 8 sprites?
(Source: https://www.patreon.com/posts/new-resource-and-26847248 )
Bottleneck # 3: sprite priorities
As if that wasn't complicated enough, Mega Drive / Genesis has one more specific feature: a sprite chain. When superimposing two sprites, the console should find out which one needs to be displayed on top of the other. In the Master System and in most Nintendo consoles (NES, Game Boy, SNES), sprites were set in a large table and their order in the table was used to set the display priority. Needless to say, this is a rather difficult tool to use, because you need to constantly redefine this large table to change the priority of sprites.
At Mega Drive / Genesis, SEGA used a more flexible and simpler system. As in other consoles, all sprites have an index number in a large table, but it is not used to set the priority of the sprite. Instead, each sprite stores a link to the next sprite to be displayed. Ultimately, the console creates a chain of sprites, starting with sprite 0. Each sprite only knows what comes after it. This makes it much easier to change sprite priorities without arranging all the sprites in a large "sprite link table". But frankly, although such a system is easier to use, it is still annoying when creating a game with often changing sprite priority, for example, in beat'em up.
The easy way: SGDK sprite engine
Displaying moving sprites and scrolling backgrounds, taking all these bottlenecks into account, is quite a challenge. All developers of the 90s fought with it, and many homebrew developers continue to do so. For example, Matt Phillips released the magnificent Tanglewood game in 2018, but created it using 90s tools. He programmed the game in assembly language and used the official hardware development kit, designed about 30 years ago. On his part, it was a conscious choice, he wanted to fully experience the technique of developing a vintage game.
(Source: https://www.gamasutra.com/view/news/325040/New_game_classic_hardware_Developing_Tanglewood_on_a_Sega_devkit.php )
But for people not as experienced and patient as Matt, modern tools can reduce the number of problems created by technical hardware limitations. We have already mentioned that C is usually simpler than assembler. It is also worth adding that the use of a high-precision Mega Drive / Genesis emulator like Blast'em in combination with Everdrive Flash Cart for testing on real equipment makes the development of the game almost painless compared to the development using old hardware emulators in combination with a set of DOS tools. But again, the main gift of our time is SGDK.
Record the game on an SD card, insert it into Mega Everdrive, and test the game on real hardware!
Among other things, SGDK also has a powerful "Sprite Engine", greatly facilitating the life of the developer. This is a set of functions for processing the display of sprites similar to how it is done in modern frameworks. First, you no longer need to worry about the number of hardware sprites required for each frame of the animation: SGDK will automatically do this. In addition, when working with sprite priorities, you don’t have to manually set the chain of sprites, because SGDK does this with the simple value “sprite priority”, which can be set for each sprite, as in any modern framework. One last thing: SGDK also processes all transmissions in VRAM automatically! Yes, you got it right, thanks to the Sprite Engine you no longer need to worry about VRAM at all! You can simply tell SGDK to display the "animation of X sprite Y" and it will do all the technically difficult work for you. If you ever had to work with these things manually, then it seems magic - everything is simple and clear!
The SGDK framework’s Sprite Engine alone makes Mega Drive / Genesis the easiest retro console for game development, especially if you have experience working with game frameworks on modern platforms. SGDK is free and open source, but if you want to help its author Stefan Dallongevil in the further development of retro magic, you can do it on Patreon: https://www.patreon.com/SGDK/
Sound
The sound on retro hardware is also a real test in itself, and each console is unique in this regard. Mega Drive / Genesis has a separate Z80 processor for this task, which is directly connected to audio equipment. That is, to create sound and music for the console, you first need to write an “audio driver”: a program for the Z80 processor. In the 90s, each game studio developed its own audio driver and adjusted it for each game. Toward the end of the console’s life, standardized drivers appeared, such as Sega of America’s GEMS, used in about a hundred games by Western developers.
Creating good sound for 8/16-bit consoles is a matter of not only musical, but also programming skills! Some games with good music or sound effects have been corrupted by a bad audio driver. The most famous example is Street Fighter II. The audio driver in this game suffers from bugs that distort all voice samples. Many years later, Stefan Dallongewil ( SGDK author and recognized wizard) reverse-engineered this audio driver and fixed its bugs. As a result, you can now play Street Fighter II with the crystal clear scream “Hadoken!”. Here is a video where you can hear the difference:
But let's get back to homebrew development and the beloved SGDK. He has the ability to select audio drivers that can be selected to suit the requirements of his game. For example, there is a PCM driver that allows you to play one sound effect at a time in very high quality (for example, voice samples) . But there is also an XGM driver that can simultaneously play a music track + 4 sound effects. Best of all, you can switch between audio drivers during the game. For example, in 30 Years of Nintendon't voice samples on the splash screen and the end of the game are played by the PCM driver for high quality. But during the game I needed to play several sound effects at the same time, so I used the XGM driver.
As for the resources themselves, modern tools can be used to create them. As I said above, for sound effects, you can simply take .wav files, which are automatically converted to the desired format. For music, the standard tool is Deflemask - a tracker that can create music for the sound equipment of various 8/16-bit consoles. I do not have much experience in creating music, because the compositions used in my games were written by talented chiptune artists: Minerscale (Break An Egg) and Warlord (MeteoRain). Both of them used Deflemask and exported their creations to VGM format, which SGDK can convert for use with their own audio drivers.
Create a game for Mega Drive / Genesis in 60 minutes? Challenge accepted!
Game jams are an excellent way to apply your game design and game development skills: how much good game can you create from scratch in a limited time (usually 48 or 72 hours)?
In terms of time, the toughest jam is 0h Game Jam . As the name implies, it is held every year during the transition to winter time. You start creating the game at 02:00, on the night of the clock. After working for 60 minutes, you release the game online at the very moment when the clock returns from 03:00 to 02:00. Last year I decided to participate in this jam. Having just completed 30 Years of Nintendon't, I have gained some experience creating a game for Mega Drive / Genesis and was inspired by the simplicity of SGDK. But can SGDK be simple enough so that I can create a 16-bit homebrew in just 60 minutes? Here is the answer :
60 minutes of work
Let's be honest, the result is not at all impressive. The balance of the game is terrible, and there is a huge bug in the random number generator, which is why the game becomes impassable after the fifth egg. In addition, there is no background image, sound, etc. But still, this is a new game for Mega Drive / Genesis, created from scratch in 60 minutes, and launched on a real console. I don’t know how for you, but for me this is already a kind of achievement!
Moreover, since the idea of basic gameplay had a certain potential, I continued to work on the game for many more hours. As a result, I got a pretty interesting arcade game that you can play here . It is also available on the 30 Years of Nintendon't cartridge along with the third game, unique to this release on physical media - MeteoRain.
Many hours of extra work!
From homebrew to indie
Although homebrew is usually a niche for amateurs (like me), some consoles today are a very commercial platform for indie studios. A great example of this is two recently released games. On the one hand, Tanglewood was fully developed in assembler, as in the 90s, which made the final result even more impressive. On the other hand, the equally stunning Xeno Crisis was developed with SGDK and took full advantage of the comfort and simplicity of modern tools.
Tanglewood (2018)
Xeno Crisis (2019)
So, if you like retro games, why not create your first Mega Drive / Genesis game today?
In the end, to get SGDK, just follow the link: https://github.com/Stephane-D/SGDK
Finally
I hope you enjoyed this article about creating three games for SEGA Mega Drive / Genesis using modern technology. If you want to play my games on your own console or just support my work, you can buy a cartridge in a beautiful box with the release of my games from the publisher of Cote Gamers: http://cotegamers.com/shop/en/genesis-mega-drive/ 43-test.html
If you are only interested in a digital release (i.e. ROMs), then all my retro games can be found here: http://drludos.itch.io/
If you liked my work and you can afford it, then support me financially at Patreon . My games are usually released online as freeware, and some are also sold on physical cartridges. By supporting me at Patreon, you will also gain access to the beta versions of my games, as well as to various prototypes I create (including abandoned projects).