The title of this post says “The Golden Rules” but what I learnt so far is that there are no golden rules to making a successful title. There are no set parameters that you can get right, they vary greatly depending on your game idea, the genre, the platforms you’re targeting, the people you’re targeting and so on. But here is what I did learn, which applies to a variety of games:
Fast Iteration and Pure Design Time
Giving independent design time eliminates the intervention of game engineers. Questions related to how a feature will be implemented and what would be its in-depth details are put off for later, leaving time to focus on deciding the gameplay elements and experience design.
Using tools such as Flash, Game Maker etc. that would require a minimal code, and probably will be usable by a non-programming member of the team can be of help in the prototyping phase. This prototype should be discarded when the programmed mechanic or feature has been finalized. Reusing hasty and inefficient code that was meant as a prototype can cause problems later on in the project.
Once the prototyping phase is done, start closing the game design to changes; making too many changes during the later stages of a project wastes time. Furthermore, don’t reinvent the wheel. If you can get code, plug-ins and assets for a store, assess the cost and get them, quite often you end up saving a lot of time.
Clarity of goal is extremely important. Team members with multiple responsibilities can distract them from the goal of a project because of lack of focus on the bigger picture. Everyone is a designer and its important to embrace that form the start so the whole team can welcome ideas no matter if they come from the engineers, artists or analysts. To keep the goals clear and the priorities straight, planning and review meeting can help the team out.
Have a design and development methodology or framework is important from the very start of the project. The bigger the team, the more important it becomes to maximize productivity.
Lets start with the interface elements; having a single button on the main menu that will take user directly to the game like in temple run is the best thing to happen to game interfaces. Its quite an old rule but its still missed out that the less the number of clicks/ taps, the simpler and easier your interface will be. Use colour highlights and intuitive icons instead of text to keep it simple.
To maximize user retention, its vital to make the user move through the game to get to the fun part. The simpler and quicker that will be, the greater the chance the the user will stay hooked to the game.
Keep it Intuitive
There is a reason why all the FPS games have WASD controls by default. Making sure names and terms are intuitive goes even further than that. For example call the user’s health: power and no explanation will be needed; call it hit points and a portion of your audience new to games will need to be explained what you’re talking about. Using intuitive names plays a part in reduces the learning curve.
An emotional event always sticks with you because it has some value attached to it; its something personal and close to you. Giving the user something to remember while playing the game, something funny, sad, exciting or even frustrating can give that user a story that will be remembered and shared with other people. This is something that will increase word of mouth and replay rate.
With one final objective of the game which could be killing a boss or finding a hidden treasure, there needs to be smaller objective along the way so the little victories can drive you towards the final goal and make the whole experience fun.The journey is is just as important than the end.
Get your game in front of people as often as possible. Having a closed alpha or beta would be even better. Choose the people you will be showing your game to based on your target audience; don’t be worried that someone will steal your idea; its your idea, nobody is going to do it any better than you. Feedback can be noisy which makes it frustrating, so you will need to do a bit of filtering to use what you can.
Start it as early as possible and even if you are absolutely sure you’re not going to do it, keep it in your design anyway. I saw the Dream Chaser (a game by we.R.play)team spend countless hours on it because they had a complete story mode with a lot of textual narration. The team reached out different people, to help them out with the localization which included native speakers and language instructors. They also used the translation feature provided by Google. Google Translation API is a cheap way to do it if you have trouble finding people to do it for you. But it will still be a good idea to have a native language speaker test out the translations because at times metaphors and slang isn’t that straightforward to translate.
All subtitles and texts should be in a simple XML file. Unity packs all the audio files into a binary, so its pretty difficult to swap audio during run time in case your game has a lot of audio narration.
When plugging in another language, flip the text for each subtitle or text. This will make it easier while testing to check which parts are not yet translated. Furthermore, output a warning into the log if a specific field isn’t found for a particular language.
GDC 2014 – Crowdsourcing the Localization of Gone Home by Johnnemann Nordhagen