Creating an RPG can be a daunting task for an indie game developer. Here at Something Classic, we had to make a conscious effort to balance between ambition and a project that is finishable, all while hopefully delivering a satisfying end product. While we have made our share of bad choices, and still have a ways to go before completion, I would like to go over some project decisions that were crucial in getting the project to the point it is at now. They may not be industry standards, they not even be the best way, but they have definitely worked for us! I hope this helps any aspiring RPG makers.

The Almighty Design Document

The project starts in the design document. The format can be open ended, the content can change, but the design document stays. For Shadows of Adam, the design document established the laws of the project. Violating those laws is a punishable offense. But seriously, any time scope creep rears its ugly head, or we begin losing sight of our goals, the design document is the first place we look.

Time is of the Essence

It’s no secret that games in general are becoming longer. Not only do RPGs follow this rule, they have grown enormously from the 16-bit days. It is not unusual for a modern day RPG to be assessed in terms of hundreds of hours of play time. Naturally, the first decision we made was to keep the game relatively short, with a planned main story of 4-6 hours. This allows for a focused narrative that has some wiggle room for side quests if we exceed our expectations.

Easy on the Nostalgia

Nostalgia can be dangerous. It’s easy to gloss over a lot of warts and imperfections that were always at play in even our fondest memories. The retro aesthetic is a pleasing one, but let’s face it: a lot of classic games had serious flaws. Sometimes we justify this by comparing games to their contemporaries rather than objectively. When it comes to RPGs, however, usability and pacing were huge issues even until fairly recently! For this reason, we wanted to avoid the trap of including mechanics solely because our RPG forefathers had them. No random encounters, clunky menus, or level grinding here!

Focus!

Tying into the above, we wanted to give the project as much focus as possible. By imposing some limitations such as the 4-6 hour game time, we were able to play to our strengths as a small team of specialized members. Any project will have to deal with scope creep or increasing ambition, so the importance of setting a narrow range of parameters cannot be emphasized enough. With our goals clearly set early on, we have been able to refer back to our design doc any time we’ve observed ourselves getting off track.

Version Control, Use It

With the introduction of GitHub a few years ago, version control systems have entered the public consciousness. Well… not quite, but they are certainly more common and accessible than ever. Using Git to manage this project’s code and assets has been crucial for a variety of reasons. First, it allows for true collaboration: everyone can work on asynchronous schedules and Git can resolve any possible merge conflicts. Second, it provides a centralized, authoritative version of the project to be stored online. And third, it makes it easy to revert changes (particularly very bad ones) with minimal effort. There is certainly a learning curve to Git, especially if you are not technically inclined, but the payoff is immense.

Stick With It

The most important thing I’ve learned while being a part of this project is to stick with it. You will always learn cool new ways to solve old problems, or come up with great ideas that seemingly put your current ideas to shame. Ignore it! Keep going forward and try not to look back. Creating a finished game of any magnitude is no small feat, so for me it has been extremely important to not take project completion for granted. While we still have a ways to go, I am confident that these decisions have allowed us to get that much closer.