Intro

So you’re a programmer, designer, artist, or musician, and you want to make a retro game. You will work together with other programmers, designers, artists, and musicians on a game developed for the NES or SNES or Genesis - or probably some other 8 or 16-bit platform. Undoubtedly there will be stumbling blocks, problems, and edge cases that arise are slow development or, worse yet, bring the project to halt. In this blog, we hope to provide some advice on working through these issues, based on how we have solved them with our own projects.

Working within Retro Limitations

When designing a game for retro consoles, it is helpful to have some idea of the limitations of these platforms but to not feel enslaved to them. Yes, there are many things you cannot do on these consoles. However, if you think only in terms of their restrictions, you will never try new, exciting things to push these consoles to (or over) their limits.

It’s best to aim high, then pare down your ideas to something that can be managed on the console. Oftentimes, you’d be surprised at what the NES, SNES, or Sega Genesis/Mega Drive are capable of. Many modern mechanics, like achievements or procedurally generated content, are possible on old systems.

The limitations can also be used to guide, rather than restrict, creativity, and design. For example, NES chips can only store so much graphical data. If you felt trapped by the limitations, you might focus on creating a small number of enemies. If you learn about the limitations, however, you begin to think differently and seek solutions to fit more content into the game. For example, many different enemy types can share tiles (using the same artwork for legs, perhaps) while still having other tiles that make them unique (like varied torsos and attacks).

Another example of this occurs with background art. Typically, there is only so much space for background tiles, and some of these are used for user interface elements (like the player HUD), so we design games with this limitation in mind.

Our desire for more, however, lead us to a trick that uses rastering to create a hard on-screen break and to pull art from different graphical pages in the memory, for each level. This allows us to devote more assets to both the background and the UI. In essence, our desire to squeeze the most out of these consoles, rather than feel restrained by their limitations, lead us to an innovative technical solution.

Working as a Team

Teams can always accomplish more than a single person or solo designer. However, working together, managing egos, and staying on course can be more difficult with a group. Teams work best when there is a leader.

This doesn’t mean that the leader will be a tyrant, dictating every facet of the game. Rather, leaders should drive the momentum of the project, and help everyone work smoothly together. Leaders should assist team members in finding resources or making decisions if they get stuck.

This role is especially useful in retro dev, where they aren’t many established professionals anymore. Most of the people coming to work on the project will be strangers to the platforms and rules, and they will need someone to guide them and motivate them through the hurdles.

Game Documentation

Another important part of being a designer is documentation. A good design document will keep team members organized, chart a course for a finished game, and help convey what the finished product should look like. It is an essential starting point.

Artists and programmers should be involved as much as possible. A good piece of concept art can set the tone for the game, and early input from designers can help avoid problems down the road. They can also provide feedback for anything that can make their lives easier. It is an iterative process of back-and-forth but everyone should agree at the end (possibly after just a few changes) of how to go on.

However, it is nigh impossible to provide the level of necessary detail in a single document. Designers should be prepared to create separate documents and to explain the same features each time, with pertinent information for each team member. It’s important to provide documentation that gives them what they need and cuts out extraneous information.

Documentation should also be actionable. It should have clear goals and objectives for the reader. So, for enemies, providing an artist with just a description is not as helpful as providing a list of animations needed for the enemy. On the other hand, always be open to team members that want to take some creative autonomy with their work, and are capable of doing so in a way that benefits the team and the game.

Note that you all want to finish the game, and to do that you first must start it!

Asset Creation

The programmer and artist will have to work together to get the artwork finished and in the specification. The programmer should be as specific as possible what dimensions, color depth, and format are needed. The artist may not know all about the platform either, so plan on helping them understand its limits. Artists, for their part, should not assume when making the graphics and should ask the programmer for as much detail as possible.

All platforms from this era have tile-based graphics. They have strong limitations not only on the colors to be used but how and when those colors can be placed. Sprites are even more limited, especially on the NES. Metasprites and metatiles can help free up some space, but these need to be taken into consideration when creating art.

Programmers, even those familiar with Photoshop or Gimp, should try to keep their fixes and modifications to the minimum. They should be programmers first, not artists. Artists will typically be able to fix things about 5 times faster.

Similarly, artists should not expect the programmer to understand all of the visual and design aspects. Providing a screenshot and pointing out the issue with arrows and circles is helpful - a picture is worth a thousand words.

Programmers should help musicians and sound engineers to understand the limitations of the platform. Often the limited capacity of older systems will prevent musicians from being as liberal as they are used to. Again, however, these restrictions will force the musician to be creative and expressive in new ways.

Musicians also should not expect the programmer to hear if their work sounds good in the game. Ask for a test build. Unless it’s way off, the programmer will think it’s fine while it could be completely off-key, the wrong speed, or even full of pops and crackles. Conversely, there may be situations when the programmer has to use a sound system that doesn’t have support for any of the musician’s tools. This is unfortunate, but sometimes it is the only way to get music and sound effects into the game.

There are certain elements everyone wants to see in the artwork and music, and sometimes these assets will go through a few iterations. However, just keep in mind the game has to be finished at some point.

Development

Programming the code on these platforms is not necessarily elegant or pretty. Programmers can make their life easier by using a lot of comments. Revisiting old code can be a nightmare unless you’ve left yourself clues to follow to help you understand the foundation of spaghetti you’ve created.

Programmers, early optimization is the root of all evil. You know this already. Don’t worry if the game starts stuttering or dropping frames, you can always optimize later. Do optimize when needed, not when it looks better in the code, or because it just feels more elegant.

When in doubt, programmers should not be afraid to ask for help in seeking solutions. There are other programmers who may have done this before. Try to avoid the “it can’t be done” or “I can’t do it” cards. Game development is not easy, but there are often communities you can pull support from. However, always be respectful and never steal or use copyrighted code.

When the Code Meets Hardware

Games that are under development will most frequently be created and tested on emulators. However, the ultimate test is putting the code on a physical cartridge and testing it on hardware. Oftentimes games will run completely different on hardware than on an emulator. Using multiple emulators can help eliminate some issues, but programmers should be prepared to make adjustments when necessary.

Game testers are often the last piece of the puzzle, and frequently spell bad news for programmers. They will endlessly playtest the game, and create bug reports for the programmer. We’ve found that creating videos to document bugs, as well as detailed explanations for how the bug was generated or encountered, can help the programmer diagnose and rectify the problem. Fortunately, many emulators have robust recording tools.

Be Retro in a Good Way

There’s a reason you would want to create new games for classic consoles. Maybe it’s the nostalgia and fond memories you have of enjoying these great platforms. Maybe it’s the challenge of developing for 20-year-old machines. Maybe it’s to create pixel art on the systems that first popularized and solidified this style as synonymous with video games.

Designing games for these old consoles is, in many cases, a childhood dream come true. However, it’s important to remember to combine the best of the new with the best of the old. As long as you focus on fun new mechanics or doing things that haven’t been done yet, you’ll be on the right track.