Lessons learned from rapid game design and prototyping

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.