Contemporary Games Can Take Up To Three Years To Develop

Game Developer on Ulitzer

Subscribe to Game Developer on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Game Developer on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Game Developer Authors: Shelly Palmer, William Schmarzo, Steve Mordue, Qamar Qrsh, David Balaban

Related Topics: Game Developer

Game Developer: Article

XNA or Game Development for Everyone - Part 2

Restructuring the game

As we have the available game states defined, the next step is to think about how we are going to implement every single game state. Again, there are a lot of options out there and I’ll show you just one of them. It’s a good idea if every game state is implemented in its own class file. To make all the different class files consistent, every game state class should implement an interface. What should be in the interface? Well, exactly the functions we were discussing in greater detail last month:

  • We need a place where we load our game content (textures, sound, and so on), and the best place to do this is the LoadContent function.
  • Changes in the current game state should be calculated in an Update function.
  • As a game state without drawing won’t be any good in game programming, we need the Draw function.
  • Sometimes we create something that should be destroyed somewhere; this gives us an UnloadContent function.

You can see the interface definition in Listing 4. Not much of a surprise – the LoadContent function takes all the parameters that we would like to keep to do all the drawings and handle the content; the Update function returns the current game state as it’s quite likely that we move from one game state to another within a game state class (consider the game state menu – if the user chooses a menu entry, we will, for example, switch to the options game state or start a local game).

The next step is to create the classes that implement this interface, which means we create the game state classes that implement IGameState to be prepared for the coming months where we implement some of them. We simply give them the same name as in the enumerations. For an example, see the source code in Listing 5, which is the skeleton for our upcoming implementation of the LocalGame game state.

Next, in our Game class we have to keep track of the current game state and call the correct function to the right time on the correct class. For example, if we move from the game state MainMenu to the LocalGame state, we should first call the UnloadContent function on the MainMenu class and then the LoadContent function on the LocalGame class. After these calls the MainMenu state is finished completely and the LocalGame state is fully initialized. This goal can easily be achieved by creating a GameState property, as you can see in Listing 6 – to keep it simple I only show the calls for three game states.

More or less the same thing needs to be done in the Update function and in the Draw function of last month’s Game class. As you may have already guessed, all the code from the existing function (LoadContent, Update and Draw) as well as the supporting functions (BackgroundCollisionDetection, PlayersCollisionDetection) and the instance variables have to go to the newly created LocalGame class and have moved away from the Game class. The Update function in the Game class is now quite simple as it contains just the call to the Update function in the correct game state class and handles the return value (maybe a state change has happened in the class) (see Listing 7). The same is true for the Draw function (except we don’t have any state change to handle) and the LoadContent function. This is quite a lot of work as we have started without game states before (and in fact we don’t really use them now as we move immediately to the LocalGame state in the first call to the Update method), but this will help us a lot in the future when we work on this project further.

Conclusion
We made a big step in the right direction with our game this month. The visible part for our users is also a very important one – collision detection. If this is not done correctly in a game, the whole game will fail. We implemented a quick solution to check for a background collision and for collisions between cars. It’s also important to prevent users from cheating as – in my opinion – this can also ruin the whole game. The second big part this month was the move to game states. The end user doesn’t really see this move, but for the game developer this move is very important. As games become bigger over time, it’s always a good idea to bring some structure into the developed classes. We did this by defining an interface and every game state implements this interface later on. Adding additional features to a game later on is a lot easier this way than it would be without this restructuring of the game. The advantage for our end users is that we can start implementing the additional game states quite quickly next month – where we’ll implement the game menu together and I also promise that we’ll learn other (more) exciting things there to improve our gaming experience. I wish you happy XNA coding time!

More Stories By Berndt Hamboeck

Berndt Hamboeck is a senior consultant for BHITCON (www.bhitcon.net). He's a CSI, SCAPC8, EASAC, SCJP2, and started his Sybase development using PB5. You can reach him under [email protected]

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.