Lessons on starting game development

Over the last couple of days, I went back over John Sonmez’s FANTASTIC walk-through of XNA/MonoGame development on Pluralsight. I followed along and made my own extremely crude game, which actually works!


Again, very very crude, I know – but this covers several very important concepts (and some specific to “shooting” games):

  • Managing the player
  • Managing the enemies
  • Managing input from: keyboard, mouse, controller, and touch
  • Managing the shots
  • Managing the collisions of the shots (shot hits player / shot hits enemy)
  • Managing the lifecycle of explosions, from things being shot
  • Dealing with background, sounds, and animations of the player, shot, and enemies
  • Managing score and “lives”
  • Managing the state and lifecycle of the game (title->playing->paused->playing->game over)

Now that I have a working game, I’ve been refactoring this code to see if I can make something more modular out of it. Again, managing shots, collisions, enemies, etc – would be common to several types of games. If you can establish a “game framework”, then you’d really just need graphics to come up with a new game or a new level.


One thing I’m realizing is that I’ve run across a new kind of software development. I was surprised when I first starting doing .NET Micro framework development, because that flies in the face of OO and reusable code. You write everything as efficiently as possible and everything is a one-off custom class. Likewise, in business applications, it’s often about managing your external dependencies – like databases, web services, external files, etc. External dependencies are your main concern.

With game development, it’s about managing the interdependencies in a proper OO way. What I mean is, the CollisionManager needs to interact with enemies from the EnemyManager, explosions from the ExplosionManager, and the player. That’s just ONE of the managers. Many of these other “manager” classes also have cross interdependencies. So, creating this code in a sane way, which manages the dependencies properly is turning out to be challenging (but fun!)

Lastly, why XNA or MonoGame? First, Microsoft has officially given up on the XNA framework. Meanwhile, MonoGame (the open-source, cross-platform equivalent) has decided to take the reigns. MonoGame is very compelling because you write the code once, and you can recompile and distribute on many platforms:


In other words, write the game logic one time and run it on:

  • Windows (as an executable)
  • Windows Phone
  • Windows 8 app (they support MonoGame, but NOT XNA)
  • Android
  • iOS
  • MacOS
  • Linux
  • Playstation Mobile
  • Ouya

That is a lot of platforms for your game!

I’ll continue to pass on what I learn, but so far this has been pretty fun getting this app working, and now trying to set up this reusable “game framework”. We’ll see how that goes.

Posted in Uncategorized, XNA and MonoGame

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Enter your email address to follow this blog and receive notifications of new posts by email.

Join 9 other followers

%d bloggers like this: