design – Nuclex Games Blog

MVC in Games

September 13, 2010March 10, 2012 Cygon

In the game I’m currently working on, it appears that I’m slowly drifting towards a design that’s a close resemblance of the Model-View-Controller (MVC) pattern, despite originally rejecting the idea because I believed it would require my game world to expose too much of its internal data just so the view could keep track of things.

Because I originally believed to be building a very simple game with very simple logic, I chose a design that would create a nice, non-fractured interface to the world so I would have an easier time building the AI and player controls on top of it:

UML diagram showing an object tree representing the entire game state

In this design, everything could access everything else – a monolithic world component where the public interface was well encapsulated, but that allowed the implementation to take the most direct path possible.

"Everything could access everything else" doesn’t mean my objects directly modified each other’s state, but it meant, for example, that a building had a reference to the island it was placed on and that it could call an internal method in the Island class to inform it when the building was destroyed or moved.

A full design, in contrast, would give the buildings an interface through which they determined properties about the ground (is it too rough? underwater?) and some events so its owner would know when the building was destroyed.

If I had only taken game logic into account, this all would have worked out very well. But there were some things that added a lot of complexity…

Input Mocking in XNA

September 2, 2010February 22, 2012 Cygon

I have updated my input library to a level where I think I can release it into the Nuclex Framework now. The design was tailored to make the input manager mockable (replaceable with a dummy object for unit testing), but the effort of mocking the entire input manager (versus just one input device) on an ad hoc basis was a bit too high (or too unreadable when using a dynamic mock object library).

So the final revision has mocked input devices and a matching input manager built in:

UML diagram showing the IInputService implemented by a real and a mock manager

To GameComponent or not to GameComponent

August 13, 2010March 12, 2012 Cygon

XNA provides a neat little system for you to organize your game’s different parts in: GameComponents. You can use them to modularize your game’s subsystems, eg. have a GuiComponent, PhysicsComponent, SceneGraphComponent etc. so you avoid having all that code in your Game class, or can use them for your actual game objects in smaller games.

However, the GameComponent and DrawableGameComponent classes provided by XNA force you to reference the Game class. This is unfortunate if you want to use those components in a WinForms-based XNA application and gets in the way when you try to write unit tests for your components because now you have to create a dummy Game instance as well (and better hope that component won’t go shopping for references in the Game‘s Components and Services collections as well).

UML class diagram of the GameComponent and DrawableGameComponent classes

Luckily, the GameComponentCollection used by XNA to store your components manages IGameComponents and updating/drawing are based on the IUpdateable and IDrawable interfaces alone, so there’s nothing preventing you from rolling your own components without referencing the Game class.

Game Architecture Day 2

January 19, 2010February 19, 2012 Cygon

Welcome to day 2 of the XNA Game Architecture series!

I have thought hard about whether I should just assume a certain level of object oriented programming knowledge in this series. People picking up these articles likely already have some knowledge about objects and design, so I settled on a quick run-over of the principles that hopefully won’t bore the seasoned developers and provide a good reference for people just starting out!

If you already know all this, feel free to skip ahead until it becomes interesting again or to the next chapter ;)!

Game Architecture Day 1

December 25, 2009February 19, 2012 Cygon

Welcome to day 1 of the XNA Game Architecture series! We’re about to create a small 3D Shoot ’em Up using the principles of modern software architecture.

If you missed the introduction, this series is about the architecture of games. Instead of focusing on a single concept, we’ll be focusing at how it all comes together and how you can keep your game’s code manageable and clean. You’ll be looking over my shoulder as I write a small game and explain why I do things one way and not the other :)

Today, I will start the project by creating a development tree that contains the actual XNA project and some third-party libraries I’m going to use within the game. Normally, I would add those libraries as I go, but I’ve got a pretty clear idea for this project and it will be easier for you because I can just package them all in a handy zip archive which you’ll find at the end of this article.

Game Architecture Series

December 20, 2009February 20, 2012 Cygon

Series

I’m planning to start a short article series:

There are a lot of XNA tutorials out there that explain the basics – how to display a sprite, how to do collision detection and how to render a bunch of colorful particles with additive blending. But there aren’t many articles that explain to you how you’re supposed to put it all together – how to structure a game so that it is easy to extend and remains manageable when the amount of code begins to grow.

The discipline that deals with this issue is called software architecture. Like programming, or any other creative process, it relies a lot on tacit knowledge – finding a good solution without first running down an alley of dead ends (that you can identify using the Principles of Object-Oriented Design) requires a lot of experience.

What I will do in this series is let you look over my shoulder as I design a small game and try to explain my motivations for choosing one design over another while I do so. This will give you a solid starting point and an understanding of the design process that you can apply to your own game projects.

The Meaning of 100% Test Coverage

December 3, 2009February 26, 2012 Cygon

When I release components, example code or even just helper classes, I often tout 100% test coverage as a feature. Which (as I probably also state often enough :P), means that my unit tests execute 100% of all lines in the source code. But what advantage does this actually bring to a developer, and, just as interesting, what does having complete test coverage not mean?

For people practicing true TDD (test first -> red, green, refactor), 100% coverage is nothing unusual, though even they may decide to not write tests for all invalid inputs possible: if a piece of code satisfies all the tests and the tests cover everything the code should do, it’s enough. If you’re building a library on the other side, the use case of a customer providing invalid inputs will be a valid concern worthy of a test.

I, however, am currently adding unit tests to an existing code base and I decided to go for 100% test coverage. In this short article, I will explain why I see complete test coverage as a worthwhile goal, what effect going for that level of test coverage has on a project and what it says about the code.

Ball Race – Day 12

November 15, 2006February 20, 2012 Cygon

I have found a way to solve the ball-falling-into-hole simulation that I am quite happy with as it won’t let the ball sink into the solid parts of the floor and still looks convincing. As soon as the ball crosses a hole, I remember that hole and start the ball’s downward acceleration. While the ball is falling, I adjust its position towards the holes center as far as needed so it doesn’t intersect with the outline of the hole.

With the gameplay mechanics working well, I spent some more work implementing the actual logic. The gameplay controller now knows the game status and updates it accordingly when the time runs out, the ball falls into a wrong hole or into the exit hole.

Next component to implement was a simple game state management system. Originally I didn’t want to do this, but as I see it now, I would otherwise end up coding all the different states (main menu, level selector, ingame) into several big if or switch statements which would be a very awkward way to handle this.