Building a Game - Straight From Our XNA Contest Winner
- select the contributor at the end of the page -
I asked the winner of the XNA contest that I held to promote my Pluralsight course on game programming with XNA to write up a guest post about his experience making the game.
Joshua Burchat was the first place winner of an iPad, and he graciously agreed to do a write up of his experience.
So congratulations again and thanks you Joshua.
Here is Joshua's post:
After winning the XNA contest John asked me to write a guest post about my experiences with the course and developing the game. So here it goes.
My name is Joshua Burchat and I'm from Oakville Ontario. I work as a developer designing and supporting business applications to support reporting within warehouse operations. My language of choice is C# but I enjoy trying other languages and technologies.
When I saw John's post I was instantly excited about the course. The only experience I have making games was doing a small Cocoa2d chess game app. I had yet to do anything with animations and moving sprites. Writing code for a game seemed like a daunting task. I decided that I needed a new project to work on, and this would be a challenging and worthwhile task.
After starting the course, building a game seemed so much more simplistic from a coding perspective than I originally thought. John has a great layout to the course. Upon completion, you end up with a fully functioning basic space shooter game.
When doing any sort of tutorial I tend to want to write a different application than the example being presented. I do this to enjoy writing the application because it's one of my choosing, and to run into different scenarios which need to be solved. I use a similar practice when learning a new language; except I usually pick a program I have already written and port it.
Wanting to do something different, I decided to go with a side scrolling platformer. The plan was to make it like Mario but with punches, a health bar and an energy bar. The course got me started with how to display graphics and create boundaries for game entities in a very simple and reusable way. The course also teaches you how to implement sounds and game states (pause, next level etc.). There were quite a few things that you need to tweak to make a more advanced game. However the structure you are given from the course is very extensible.
One of the things that I needed to add to the game that was not in the course is the concept of gravity. The player, as well as some of the enemies needed to be able to jump and fall. Entities needed to be able to transition to different animations as well as be prevented from doing certain actions while the animation has yet to finish. I ended up using a similar method that John used for the game states; I made sprite states. When a sprite had a specific state it would determine what the sprite is currently doing and what it could do next.
The current state would have an update method that the sprite would call from its update method in the game loop. The state was responsible for setting the animation for the sprite and whether or not the state should change. For example, when the up arrow was pressed the standing and walking action would lead to the jumping action for the player sprite. Enemy sprites had actions that they used to make them attack and move around.
Here is an example of the player sprites states:

Once implementing the ability for sprites to change state, I needed to make use of them. I had five types of sprites in the game:
Player: Controlled by user input. The player sprite has an energy level that is used to preform jumps and punches. The energy recharges over time. This sprite also has health, the player has to restart the level when the health hits zero or if it falls off a ledge.
Enemy: Controlled by its surrounding. If they hit the edge of a platform, turn around. If it hits the player, change the player state to ‘stunned' and takes some of the players health away.
Terrain: Represents the bounds for that prevent the player and enemies to go past.
Background: Elements that do not have any effect on the other sprite types, and are simply for visual effects. Some background effects move, such as clouds or snow.
Item: Created from an enemy sprite when it is killed. Adjusts the players stats such as health or energy.
Here is a video of the game play:
http://www.youtube.com/watch?v=Avm7CogsWA4
After completing the course you will definitely be able to make a basic game and in time and with a good amount of effort you should be able to make an excellent game. There are a few things besides coding that go along with game design that I find to be the hardest aspect of the craft. These are things that I will need to improve in my game.
Physics/Feel: The way entities interact, timing, controls. The physics of the game help to allow the user to feel the game. If the characters move too slow or don't jump in a logical way then the user feels it and the game becomes unappealing.
Story: Games should have a story, it can be simple or complicated but it needs to exist. While making this game I did not really start off with a story, I just wanted to learn the programming aspect. Now that I have learned enough to make a more robust game, the next one will definitely have a story.
Graphics: I have no skill at creating graphics myself; I needed a bit of help from my girlfriend to make some decent sprites. Graphics are hard; the game needs to have a good style that helps keep the user's attention and make the experience more enjoyable. When I say good graphics I don't necessarily mean high end rendered images, I simply mean they need to be appealing and click with your game. A good example of this is Minecraft, it looks silly but it is very fun to play and has a large following. It is also important to keep in mind what John states in the course, don't worry about the graphics when learning to make a game. At the beginning of this game's development I used boxes for sprites, it looked silly but it got me through the tunnel.
Since working on this project, I have recommended this course to a few of my fellow developers at work. Not because they enjoy video games but because I believe making a game helps strengthen your OO skills. I was surprised at how bad I was at doing something that consists purely of writing objects; it really put my skills to the test.
I ended up rewriting some the application a few times before I had my base designed in a manageable way. I am a strong believer in writing a program more than once, learning from the mistakes of the first pass through and coming out with something more refined. I would recommend this course; it is definitely worth your two hundred free minutes of PluralSight if you have not signed up yet.
Now that I have made a platformer game I would like to try something different. I am going to try to make an adventure RPG, attempting a classic Zelda feel perhaps. Another thing I am going to attempt is to port the game over to iOS and Andriod either manually or using Mono.
Making games is something that I could see taking whole bunch of effort and failures to get right. I want to try various types of games so that one day I can make one that I consider distributable to the public. I am not releasing this game on any application market, it is still a half cooked and there are quite a few improvements I would need to make.
I am glad that I had entered this contest, and I believe that it was a building block for a great hobby and maybe one day a career. Thanks John for this fun project, many a nights were spent with key clatters. I hope everyone else had a great time making their games as well.

So congratulations again and thanks you Joshua.
Here is Joshua's post:
After winning the XNA contest John asked me to write a guest post about my experiences with the course and developing the game. So here it goes.
My name is Joshua Burchat and I'm from Oakville Ontario. I work as a developer designing and supporting business applications to support reporting within warehouse operations. My language of choice is C# but I enjoy trying other languages and technologies.
What appears to be a daunting task
When I saw John's post I was instantly excited about the course. The only experience I have making games was doing a small Cocoa2d chess game app. I had yet to do anything with animations and moving sprites. Writing code for a game seemed like a daunting task. I decided that I needed a new project to work on, and this would be a challenging and worthwhile task.
After starting the course, building a game seemed so much more simplistic from a coding perspective than I originally thought. John has a great layout to the course. Upon completion, you end up with a fully functioning basic space shooter game.
Doing something a little different
When doing any sort of tutorial I tend to want to write a different application than the example being presented. I do this to enjoy writing the application because it's one of my choosing, and to run into different scenarios which need to be solved. I use a similar practice when learning a new language; except I usually pick a program I have already written and port it.
Wanting to do something different, I decided to go with a side scrolling platformer. The plan was to make it like Mario but with punches, a health bar and an energy bar. The course got me started with how to display graphics and create boundaries for game entities in a very simple and reusable way. The course also teaches you how to implement sounds and game states (pause, next level etc.). There were quite a few things that you need to tweak to make a more advanced game. However the structure you are given from the course is very extensible.
One of the things that I needed to add to the game that was not in the course is the concept of gravity. The player, as well as some of the enemies needed to be able to jump and fall. Entities needed to be able to transition to different animations as well as be prevented from doing certain actions while the animation has yet to finish. I ended up using a similar method that John used for the game states; I made sprite states. When a sprite had a specific state it would determine what the sprite is currently doing and what it could do next.
The current state would have an update method that the sprite would call from its update method in the game loop. The state was responsible for setting the animation for the sprite and whether or not the state should change. For example, when the up arrow was pressed the standing and walking action would lead to the jumping action for the player sprite. Enemy sprites had actions that they used to make them attack and move around.
Here is an example of the player sprites states:

Once implementing the ability for sprites to change state, I needed to make use of them. I had five types of sprites in the game:
Player: Controlled by user input. The player sprite has an energy level that is used to preform jumps and punches. The energy recharges over time. This sprite also has health, the player has to restart the level when the health hits zero or if it falls off a ledge.
Enemy: Controlled by its surrounding. If they hit the edge of a platform, turn around. If it hits the player, change the player state to ‘stunned' and takes some of the players health away.
Terrain: Represents the bounds for that prevent the player and enemies to go past.
Background: Elements that do not have any effect on the other sprite types, and are simply for visual effects. Some background effects move, such as clouds or snow.
Item: Created from an enemy sprite when it is killed. Adjusts the players stats such as health or energy.
Here is a video of the game play:
http://www.youtube.com/watch?v=Avm7CogsWA4
Lessons Learned
After completing the course you will definitely be able to make a basic game and in time and with a good amount of effort you should be able to make an excellent game. There are a few things besides coding that go along with game design that I find to be the hardest aspect of the craft. These are things that I will need to improve in my game.
Physics/Feel: The way entities interact, timing, controls. The physics of the game help to allow the user to feel the game. If the characters move too slow or don't jump in a logical way then the user feels it and the game becomes unappealing.
Story: Games should have a story, it can be simple or complicated but it needs to exist. While making this game I did not really start off with a story, I just wanted to learn the programming aspect. Now that I have learned enough to make a more robust game, the next one will definitely have a story.
Graphics: I have no skill at creating graphics myself; I needed a bit of help from my girlfriend to make some decent sprites. Graphics are hard; the game needs to have a good style that helps keep the user's attention and make the experience more enjoyable. When I say good graphics I don't necessarily mean high end rendered images, I simply mean they need to be appealing and click with your game. A good example of this is Minecraft, it looks silly but it is very fun to play and has a large following. It is also important to keep in mind what John states in the course, don't worry about the graphics when learning to make a game. At the beginning of this game's development I used boxes for sprites, it looked silly but it got me through the tunnel.
Since working on this project, I have recommended this course to a few of my fellow developers at work. Not because they enjoy video games but because I believe making a game helps strengthen your OO skills. I was surprised at how bad I was at doing something that consists purely of writing objects; it really put my skills to the test.
I ended up rewriting some the application a few times before I had my base designed in a manageable way. I am a strong believer in writing a program more than once, learning from the mistakes of the first pass through and coming out with something more refined. I would recommend this course; it is definitely worth your two hundred free minutes of PluralSight if you have not signed up yet.
Where to next
Now that I have made a platformer game I would like to try something different. I am going to try to make an adventure RPG, attempting a classic Zelda feel perhaps. Another thing I am going to attempt is to port the game over to iOS and Andriod either manually or using Mono.
Making games is something that I could see taking whole bunch of effort and failures to get right. I want to try various types of games so that one day I can make one that I consider distributable to the public. I am not releasing this game on any application market, it is still a half cooked and there are quite a few improvements I would need to make.
I am glad that I had entered this contest, and I believe that it was a building block for a great hobby and maybe one day a career. Thanks John for this fun project, many a nights were spent with key clatters. I hope everyone else had a great time making their games as well.