Game development is a complex process. It involves many disciplines, but it can’t take much from their standard working methods.
In terms of art, creative people (artists, musicians, writers) usually create a basic concept for their creation first and work out the details later, adding depth to it. In game development, on the other hand, your initial implementation of gameplay doesn’t work by default, and requires several iterations to improve. In many situations, it’s simply impossible to make the game work, and then it can be very difficult to abandon it in favor of another project.
On the technical side, however, the methods learned at university are mostly not used in game development. Software engineers, on the basis of the received terms of reference, develop so-called use cases. Once these scenarios are created, all interactions with the user become strictly formalized. This doesn’t work in game programming because you are more focused on the experience of the player than on what they will do.
If you’re writing a game, just write code as fast and as simple as you can. Don’t worry about design. Don’t use design patterns and encapsulation for their own sake. Make the game code quick and dirty and just make it work. If the code becomes difficult to work with later on, make it cleaner. If not, don’t touch the code.
The standard argument for writing licked code is teamwork and lots of programmers working on the game. The main programmers demand neat and organized code, which is the reason for very slow development. The rationale is, “We have to be able to replace the programmers at any time, so the code has to be readable and maintainable.” In reality, this way takes much more development time, and it’s hardly cheaper in the long run.
Make sure that each programmer on the team has a specific role and area of responsibility. Let them work as they like, fast and dirty, just make sure they create clear APIs to communicate with other programmers. What you lose in organization, you gain by an order of magnitude in development speed.
Is development commercially viable?
Wait, you have to make a prototype first! Once you have a good idea, the natural inclination is to prototype it…
Not really. This is where 99.9％ indie developers make their biggest and most fatal mistake.
And no, it’s not the scale of the project that determines its viability. A lot of articles on developing a successful game that you’ll read will recommend keeping the scale of the game small to reduce the risks. This is bad and unprofessional advice. Do not follow it. There is no profit in this world without risk. The key should be to understand how to manage risk.
Just make the game as big as you want it to be. It will be a self-regulating development process in which your strengths and limitations, will reveal the limits of your capabilities. Ambition is necessary for success, don’t clip your wings in the beginning.
Before prototyping, you should be able to answer the following questions:
- Your target audience?
- How will you reach your target audience?
- How will the development be funded?
- What makes your game unique?
If your game is not different enough from its counterparts it will fail. People won’t play it, it won’t interest publishers, and no community will form around it.
What is the value of your game? You should be able to easily convey this difference with a single phrase, a picture or a short video. If you can’t pull it off, the game is likely to fail. If it’s too similar to other games, the game is likely to fail. It needs to be different.
Different can be an innovative gameplay concept, or an unprecedented visual style. Unique character designs are also of interest. For RPGs and adventure games, story and illustration are key.