Just like the Game Development Tutorial on the App Hub we’ll start “thinking” about – or as in this case “analysing” – the game.
To get the analysis proses started, let’s begin with answering the question they propose:
- What kind of game is it ?
It’s a puzzle game, puzzle’s are solved when the game objective is reached.
- What is the game objective ?
A player has won, when the house has been destroyed, and all debris is stacked lower than a certain height and the debris hasn’t touched any of the side buildings.
A game is lost if : a side building is touched by debris, or when all debris came to rest and the minimum height is not reached.
- What are the gameplay elements ?
A player places bombs on the blocks that form the building. There are several sort of bombs, those that explode in different directions (like up, left or right) or those that generate different sized explosions.
- What are the engineering elements ?
The blocks fall just like in the real world, that’s what makes the game so much fun. This means that physics are involved… unfortunately we all didn’t really pay attention enough back in school, to remember all rules of physics. But we’re lucky because some clever people did remember everything from their physics course, and implemented those things in what they call a “physics engine”. The most popular for Windows Phone is the open source Box2D implementation called : Farseer Physics Engine.
You will notice that the physics engine is in fact just an “aid”, it’s a bit weird to comprehend this in the beginning – but in fact the physics engine does nothing else than a lot of calculations.
To represent what happens in your game world you need to draw things to the screen… to maintain what happens when, with what object you will set up and use an object model.
- What art assets do you need ?
We will probably have a several art assets in our game, things like the blocks, the bombs, the user interface, buttons, etc…
I prefer not to use the art assets yet, I want to get the basics up and running before adding all the eye candy.
The Farseer Physics Engine contains what they call a “debug view”, this is a project that is included with Farseer physics XNA Samples projects zip file. You can use this project to visualize what’s going on in your World… later on we will “paste” beautiful graphics over every object in the physics World.
We also might need audio assets, no game is much fun without sounds of bombs, falling blocks, etc
Let’s create a flowchart of the game… take a look at the example on the Game Development Tutorial on the App Hub.
You will see that they use ellipses for program states (launch game, exit game, game, game over), rectangles for game loop actions (main menu, check for input, movement input registered, fire bullet, check for collisions, bullet collides with enemy, player collides with enemy, draw), and rectangles with double side lines for sub-actions (initialize …, increase …, draw …, play <sound>, update …, highlight …).
If you start your Meesoft Diagram Designer, you’ll see all these “objects” too on the right hand side. Drag a Terminator ellipse on the drawing surface. To change the text right-click it, and type “Launch game”.
Let’s do the same for our Implode!XL clone.
When the game start, the user will see a main menu, where he can choose to start the game, or change the audio settings (music on/off and sfx on/off). When he chooses to start a game, he’s presented a level selector first, where he chooses the level to play. Then the game will start.
We’ll first check for user input, for our Windows Phone game it’ll mean check if a user touched the screen. If the user touched (and held) the bomb stock we initialize a new bomb of that type, decrement the bomb stock with 1, and start dragging the bomb around. If the bomb touches a block, and the user stops the dragging motion, the bomb should snap to the block.
If the user touched the trigger, we’ll cut the blocks that have bombs on them, and then we’ll explode the bomb, this will give the impression that the bomb cut the block.
In the next step we will do some collision detection… of course the physics engine will take care of the collision detection itself, but we want to do things when collisions are detected, like playing sounds.
Then we’ll check if the level is won or lost. This is probably the most difficult phase of the game. We need to find out what is the highest point of our debris, then we need to verify if that height is lower than our minimum height that is defined by the level. We’ll check if the blocks are still falling/moving, if they still are, then it might be normal that we’re not below the minimum height yet.
A timer will be set, when the blocks are not moving anymore and/or when the debris height is below the level defined minimum height.
Last but not least, we’ll draw everything on the screen.
This is it for today. I think we now have a good idea of how our game will work.
In the next articles we will be talking about how to “write” the game.
Below you’ll find a list of chapters I’m planning to write… Titles might still change, chapters might me added too.
- Getting started
- Designing the game
- Developing the game
- I’m sure here will be several sub-chapters
- things like:
- creating game logic
- creating graphics
- adding sound
- come immediately to mind
- Testing the game
- Also here I see several sub-chapters, like
- the mom/wife test
- or even worse : let the baby play with it
- Publish the game