Create a game prototype is often an important step in the game design process, it offers you valuable insight into your basic gameplay principles to see what will and what won’t work. It is basically a simplified version of your game that implements the game mechanics but skips creating final graphics, sound, music or menus. It probably won’t even include every feature, just the core mechanics. There’s a great article on prototyping at Gamasutra.com.
When you are starting out in game development, the first game you make will probably not have a separate prototype but in some ways be a more of a prototype of your personal game development process. It’s a chance to play around, try things out without the pressure of creating something with commercial viability. This is why Gamesalad is such an excellent starting point, and why we decided to use it to prototype “The Fleet”. Take a look at this tutorial video to see how easy it is to get started:
For “The Fleet” we started prototyping with our hotseat multiplayer battle mode, so we created an ocean background and threw in some placeholder images of WW2 destroyers. The next step was to add “rules” to our “actors”. Actors are any objects in Gamesalad that do something: like our ships, buttons, explosions, etc… This first part was easy, you create a rule that says “if this actor is touched (or clicked on) then do this…”, so we set up some controls and had our ships moving in no time.
The challenge with Gamesalad was once we started to add more complex rules, we were beginning to go beyond what Gamesalad could accomplish. For example, when our Ship actor had a lot of rules (to control it’s selection, deselection, movement, firing, damage, collision detection, etc.) it would take up to a minute to load the rules editor for that actor. There was also some sort of memory leak bug in the software, so if you tried to open the rules editor more than 2-3 times for the same actor, it would start to slow down and take 2-5 minutes just to load the rules editor. To fix that we would have to restart Gamesalad every 15 minutes to get it back up to speed. To be fair, I think that we probably had more rules on our ship actor than a typical Gamesalad game, so we were pushing the software a bit.
One of the things we learned early on through our prototype was that the combat/battle system of the game was a bit repetitive. There wasn’t much of a sense of strategy to it, you just moved, fired, moved, fired and didn’t have to make many decisions or implement much of a strategy. This is bad, not only for a strategy game, but also for any game. One of the core components of a good game is the giving the player options so that when they make decisions about what they do and where they go, they start to take ownership of the game. The investment of making decisions creates value and a feeling that you are controlling the game, not the other way around. For example, take a simple puzzle game like Tetris: you have a lot of options and have to make decisions quickly on where to place your blocks. If Tetris only had the block rotation aspect (without sliding the blocks left and right), it would get boring really quickly because you won’t need to make decisions about where to place your blocks, you would just rotate them so they fit.
We’ll talk about what we did to overcome our gameplay issue in the next Project ISG update. Stay tuned, and remember to check out the full Project ISG page to see how you can get involved. Extra special thanks to everyone who has donated to the project, thanks for helping us expand the world of iOS strategy games!
- By JJ
