Lessons learned from rapid game design and prototyping
After an intense month of game design and prototyping, there are a few lessons I took away from the process that can be helpful to you in the future.
![](https://eu-images.contentstack.com/v3/assets/blt740a130ae3c5d529/bltba62518415cda0e2/652fe6ddbc479f8697ef691f/default-cubic.png?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
January was a very busy month for me. I had a one-month game design class at school and I participated in the Global Game Jam 2015.
The game design class required my team to come up with an idea for a game. Such idea had to be intensively polished and refined during the month. After the first week of design and writing documentation we had two weeks to develop a basic prototype for the game. The last week of the month was all about getting people from outside to playtest our game, and making modifications to it based on the feedback we got from the tests subjects. We managed to get everything done by the deadline but, of course, we ran into a few problems during the process and I'd like to talk about them and how we approached them to find a solution.
Alongside with my school class, in the last week of the prototype development I also had to spend a full weekend working in a game for the Global Game Jam. For those who don't know, the GGJ is an annual event where hundreds of developers get together in many different locations around the world to make a game in 48 hours, so even though it is super fun, it can also be stressing and exhausting, especially when the deadline is coming close.
Here are some of the most important lessons I learned about game development during this month:
Don't fall in love with your ideas. You probably think that the big idea you have in your mind is great. It might be, but be prepared to suddenly realize that it's not. Not all games are the same and the way your game ends up being may (and probably will) be very different from what you originally thought. That great idea you had for a gameplay mechanic may not be suitable for your game anymore. If there is not a really good reason to include that idea in the game, the best you can do is let it go.
But don't throw them away. Discarded ideas and mechanics may be useful for a future game. Or maybe after some time you can come up with a mind-blowing way to tie that mechanic to the game. It is a good idea to keep an archive of discarded stuff and take a look to it once in a while.
Interface is not equals HUD. A lot of people think about interface and they think only about the HUD. Health bars, timers, counters, etc. But the user interface of a game includes not only visual elements like the HUD, but also audio, controls, and anything that helps the player understand what is going on in the game. Audio is often underestimated when making game prototypes, and that is a big mistake. A HUGE mistake. Audio is as important as graphics, and it should always be considered a priority during development, even in a prototype.
Testing, testing, testing. Man, this is by far the most important thing I learned. I can't stress enough how mind-blowing it was to see other people play your game and find out where they struggled to get through the levels, seeing them learning how to play for you to check how effective or ineffective the tutorial and instructions screen is, or watch them beating a level in a way you didn't even think it was possible. It is the only way to really know if your game is going in the direction you want and, if not, recognize those red flags to start fixing things. You'll find both design and technical deficiencies that otherwise you would have never seen. It is really important to have a lot of people testing your game in every iteration or version. The more people test it, the better. Make your mom and your dog play it. It is a good idea to have a questionnaire or survey for people to fill at the end of the testing session, and make sure you also get verbal feedback. Ask for comments, suggestions, and any kind of criticism you can get. Every word they say will be gold to you, so don't try to explain why something in the game didn't work or how you plan on fixing that bug later. Just listen to them and try to take notes about what they say. After a few testing cycles you'll see how people understand your game a lot better, it is so satisfying.
Game jams: #GGJ15 was my first game jam ever. All of these things that I just talked about also work for game jams, but of course they need to be applied in such a way that you can do all you need to do in just 48 hours. I guess my only big advice for game jams like this would be please get some sleep. I saw a lot of people drowning themselves in Red Bull cans to stay awake but they couldn't get anything done for a while because they were more busy trying to make their eyes stay open than actually doing work. I strongly recommend at least two naps during the 48 periods, it is really important to get some rest, coding like crazy or drawing like crazy are activities that need fresh brains, so don't forget about that.
This design experience was really valuable to me. As a programmer I think that having design skills do nothing but helping a lot when designing the code architecture for a game. It takes a lot of patience and creativity to obtain a decent product, but the process is so intense and full of feedback that at the end you end up with a million things to think about, and most of those things are great knowledge and new skills, which is, of course, pretty amazing.
About the Author
You May Also Like