In making mobile and video games, there are two main challenges. One is getting the game done. It just takes a sheer amount of effort and focus to finish a game. Because mobile game development is hard, I’d say the majority of people never actually complete their games. The second challenge is getting feedback to know if your game is any good. Sure, you may like your game, but does that translate into others liking it and buying it?
Jeff and I have decided we are going to tackle this challenge by doing a very simple prototype of every game idea we start. We got this idea from learning how a very popular game, Plants -vs- Zombies was made. In that game, an early version was made and changes were made over and over again based on the feedback of other people. We like this idea, so with our upcoming game, code-named “Grow Em,” we are working on doing just that.
What to Prototype With
So the question is, how do we do it? Well, we made our very first game together, Math Asteroids using the XNA framework. (Jeff has made 6 other iPhone games and apps by himself). We released the game for Windows, Windows Phone, and XBox. It was built using the XNA game framework. Jeff and I know C# pretty well and over the course of the month of December 2011, we made Math Asteroids. We learned a lot and figured out how to make cool things happen. Because XNA was so fast for us to develop our game in, we’ve decided we will prototype with it.
When Jeff and I first started developing Math Asteroids, we were able to get a very basic version done on the first day. In it, the space ship would answer the same math equation on an asteroid over and over. We got one asteroid to appear on the screen and answer its equation. This was instant feedback for us and we were able to adjust and add features based on our experience with the first prototype.
What we do lack is more people to give us feedback on our prototype. But we have at least the both of us to talk and share ideas, so if you are making a game by yourself, or with a very small team, don’t discount that feedback. Either way, we’ve found a platform, XNA, which we can make games very fast in and we will continue to use that for the foreseeable future.
Your goal should be one of two things. If you don’t know programming very well, start learning. There’s plenty of XNA and game tutorials on the web. Start reading/watching them and get started with your first very basic version of a game. If you do know programming well, pick a coding platform and run with it. Maybe that’s XNA. Maybe it’s C++. You’ll know your prototyping platform of choice when you can get your first game version up in a day.
What Does a Prototype Look Like?
A prototype is the most basic first version of a game. It is not perfect. It is not pretty. It has only the most basic game play elements. If it’s a first person shooter, you probably have a screen to move around in. Maybe you can even walk on a path or something. But that’s it. Then you take the game and add features from there. Maybe a gun is added to carry and shoot. Maybe you decide you don’t want a first person shooter, but the exploration of a maze instead. This is why it is so important to keep your prototypes basic, small, and simple. You want to be able to adapt them quickly. This is difficult if you spend weeks coding up a game and then later realize it’s not what you or the market wants.
The very top image of this article shows a very old game, Pong. This is a good example for what your prototype should be. Just a basic screen and one or two game play elements. No fancy graphics and no fancy sounds. Just enough to try the game out. In the case of Pong, the paddles move back and forth and hit the balls, and score is kept. That’s it. You could make Super Pong and add new features now, such as aliens interfering with the game, or power ups that the ball can hit to make your paddle grow wider.
Here’s a list of principles to follow when making a prototype for your video game:
- The first version should be basic, small, and simple. No fancy graphics or sound! Those can come later.
- Add one or two game play elements to the prototype. These should be simple, like walking, clicking one thing, or testing one simple idea.
- Find a coding framework that works for you where you can get a first version done in a day. Jeff and I like XNA.
- If you don’t know how to code and really want to make games, get online and start learning. Plenty of people have written articles and tutorials on the web.
- Get feedback as quickly as possible on your first prototype. If you have just yourself, ask yourself what should be next. If you have a team, consult them. If you’re at a game company, consider yourself lucky that you have so many people to get feedback from.
- Enjoy making the prototype. If you’re not having fun, chances are you’re doing a game that isn’t interesting to you, or you really don’t want to make video games. Change course as needed.
- If you’re ever stuck, use Pong as a reference for how simple your prototype should be. Just the basics.
- If you don’t know what game to start with, read, “What Game Should I Make?“
Moving Beyond the Prototype
Eventually, you’ll want to move beyond prototyping your video games. You might even want to, you know, finish your game. In a future article, I’ll write about how Jeff and I finished our first game and released it for Windows, Windows Phone, and XBox. We know we’ve got a long ways to go still, but completion of your first game is a great milestone. Look for a future article on completing your first game.
Prototyping your video games is an essential step to making a high quality video game. If you do it right and get the game done on the first day, you can immediately get feedback from anyone who will listen and make adjustments as necessary. Choose your prototyping coding language and just get started. When you finish your first game, give yourself a pat on the back – this is by no means a small and simple feat and you’re in elite company if you do so and Jeff and I salute you.