Wednesday, August 1, 2012

XNA and System Testing

In the previous post, we discussed the topic of XNA and Data Driven Design.
Now, let's build on this information to discuss System Testing with XNA.

Note: this post includes complete code sample on CodePlex.
Download code sample here.

System Testing
System Testing is the practice in which complete, end-to-end software is tested to evaluate the system’s compliance with its specified requirements.

Game development that implements data driven design may find system testing effective because it can be used to validate all data before fully integrating into the game.

When experimenting with new ideas, all changes made to game data must be valid, otherwise it may be possible to easily break the system, or have the system behave in an unpredictable fashion.

System testing allows for this feedback quickly, efficiently and without need to execute the entire game.

Here is a common workflow to integrate system testing into game development:
  • Write game code and edit game data
  • Run system tests and validate
  • Launch game with current data
  • Update any game data as necessary
  • Re-run system tests and validate
  • Hot swap updated game data
  • Repeat process: no constant build / deploy
Example
As an example, let’s build a basic snake simulation to demonstrate XNA and System Testing.
First, create a system that can parse text files on demand (not just at start up):
public interface IFileManager
{
 IList<String> LoadTxt(String file);
 T LoadXml<T>(String file);
 XElement LoadXElement(String file);
}
Next, create a component to manage all data that will be loaded into the game:
public interface IDataManager
{
 AllData LoadData(String[] files);
}
Sample
The following code sample builds a simulation to integrate an unlimited number of snakes into a maze using data driven design and validates each snake through system tests.
First, define a simple text file that will store all 3x possible maze sizes: Small, Medium, and Large.
Next, define an XML file that stores an unlimited number of snakes available; each snake defines:
  • Start position in maze and direction
  • Length of the snake tail
  • Time delay on each tile
  • No. tiles before direction change
<?xml version="1.0"?>
<ArrayOfSnakeData>
 <SnakeData>
  <StartPosX>10</StartPosX>
  <StartPosY>5</StartPosY>
  <Direction>Left</Direction>
  <TailLength>20</TailLength>
  <TimeOnTile>50</TimeOnTile>
  <TileToMove>10</TileToMove>
 </SnakeData>
</ArrayOfSnakeData>
Finally, write system tests to validate all data before fully integrating into the game.
Note: an IoC Container will be used to construct all components used throughout.

FILE MANAGER TESTS
[TestFixture]
public class FileManagerTests
{
 // System under test.
 private IFileManager fileManager;
 
 [SetUp]
 public void SetUp()
 {
  fileManager = IoCContainer.Resolve<IFileManager>();
 }

 [Test]
 public void BoardDataTest()
 {
  String boardFile = GetPath("BoardData.txt");

  IList<String> lines = fileManager.LoadTxt(boardFile);
  String line = lines[0];

  GameSize gameSize = (GameSize)Enum.Parse(typeof(GameSize), line, true);
  Assert.AreEqual(GameSize.Small, gameSize);
 }

 [Test]
 public void SnakeDataTest()
 {
  String snakeFile = GetPath("SnakeData.xml");
  SnakeData[] snakeData = fileManager.LoadXml<SnakeData[]>(snakeFile);
  Assert.AreEqual(1, snakeData.Length);

  SnakeData snake = snakeData[0];
  Assert.AreEqual(10, snake.StartPosX);
  Assert.AreEqual(5, snake.StartPosY);
  Assert.AreEqual(Direction.Left, snake.Direction);
  Assert.AreEqual(20, snake.TailLength);
  Assert.AreEqual(50, snake.TimeOnTile);
  Assert.AreEqual(10, snake.TileToMove);
 }
}
DATA MANAGER TESTS
[TestFixture]
public class DataManagerTests
{
 // System under test.
 private IDataManager dataManager;

 [SetUp]
 public void SetUp()
 {
  dataManager = IoCContainer.Resolve<IDataManager>();
 }

 [Test]
 public void AllDataTest()
 {
  String boardFile = GetPath("BoardData.txt");
  String snakeFile = GetPath("SnakeData.xml");

  String[] files = new[] { boardFile, snakeFile };
  AllData data = dataManager.LoadData(files);

  Assert.AreEqual(GameSize.Small, data.GameSize);
  Assert.AreEqual(1, data.SnakeData.Length);
  
 }
}
Download code sample here.

Summary
The snake simulation demonstrates how to integrate an unlimited number of snakes into a maze using data driven design: simply update the XML file to add more snakes without constant need to recompile and validate all data quickly and efficiently through system tests.

In reality, more complex text files will be loaded into a game, for example, to build game levels. Level data may require more complex validation to ensure all data is true and correct, and that all rules are observed before the level is actually loaded into the game.

This will be the topic in the next post.

Wednesday, July 4, 2012

XNA and Data Driven Design

Games are made up of two things: logic and data. The logic defines the core rules and algorithms of the game engine, while the data provides the details of content and behavior.

When logic and data are decoupled from each other, the whole team, including designers and testers,
can experiment with different variations and tune the data to get the exact behavior they desire.

Therefore, game data should, ideally be loaded from text files; not embedded inside the code base.
This concept is essential to putting data driven design to work:
  • Create a system that can parse text files on demand (not just at start up)
  • Put constants in text files so they can be changed easily without recompiling code
  • Don’t hard-code anything; assume that anything can change, and probably will!
Example
Galaga: if the game requires only 3x types of enemy spaceships then you could program a perfectly good system that encompasses all of them. However, if you abstract away the functionality of each spaceship, using data to define its behavior, then you allow for an unlimited number; each with its own personality.

When core design decisions are flexible, the game is allowed to evolve to its full potential. In fact, the process of abstracting a game to its core helps tremendously in the design; this forces recognition of
what should be built, instead of the limited behavior outlined in the design document.

System Testing
System Testing is the practice in which complete, end-to-end software is tested to evaluate the system’s compliance with its specified requirements.

Game development that implements data driven design may find system testing effective because it can be used to validate all data before fully integrating into the game.

When experimenting with new ideas, all changes made to game data must be valid, otherwise it may be possible to easily break the system, or have the system behave in an unpredictable fashion.

System testing allows for this feedback quickly, efficiently and without need to execute the entire game.

Here is a common workflow to integrate system testing into game development:
  • Write game code and edit game data
  • Run system tests and validate
  • Launch game with current data
  • Update any game data as necessary
  • Re-run system tests and validate
  • Hot swap updated game data
  • Repeat process: no constant build / deploy
Two examples in which game data can be verified through system tests include:
Level Validation and Component Based Design.

Level Validation
In game development, level data is most often stored in text files. For example, the Platformer starter kit contains 3x levels, although an unlimited number of levels could be added using data driven design.

Level data can then be validated through system tests to ensure all data is true and correct, and that all rules are observed before the level is actually loaded into the game.

Component Based Design
Component Based Design is a common approach to build game objects that are flexible, maintainable and scalable: each component encapsulates a set of related functions, or data, so that additional game objects can be created without any extra code.

In game development, component based object data is typically stored in XML files. The logic used to parse XML and build game objects can be complex and error prone; consequently, system tests can
be used to validate all game objects before fully integrating into the game.

Therefore, it seems only relevant to try and integrate data driven design into XNA game development.
As an exercise, I would like to prototype data driven design using the following examples:
In conclusion, it will be interesting to see if data driven design has the potential to scale using XNA!

Sunday, January 1, 2012

Retrospective III

Last year, I conducted a simple retrospective for 2010. Therefore, here is a retrospective for 2011.

2011 Achievements
Note: receiving acknowledgement by George Clingerman on XNA Notes is an achievement!

2012 Objectives
  • Promote quality in game development using agile software methodologies
  • Incorporate three dimensional graphics into game development projects
  • Monitor the future of XNA, XBLIG, and the Microsoft Indie gaming scene
  • Explore alternative Indie game development distribution channels

In 2010, there was much concern from the developer community as Indie Games were hidden under Specialty Shops as part of the Xbox dashboard update.

In 2011, independent game developers responded angrily to the latest Xbox 360 dashboard update:
many feel that the marketplace is again hidden as Indie Games are now presented as a single list.

Also in 2011, the announcement: No XNA support for Metro applications in Windows 8 has prompted much speculation over the future of XNA.

Quote: It is correct that XNA is not supported for developing new style Metro applications in Windows 8. But XNA remains fully supported and recommended for developing on Xbox and Windows Phone, not to mention for creating classic Windows applications (run on XP, Vista, Win7, and Win8 in classic mode).

This report appears reminiscent to the XNA Game Studio 4.0 upgrade: Not for Zune HD.

Fortunately, there is some positive news for Independent game development, especially now as digital distribution is becoming more prevalent in the games industry; various portals such as Big Fish Games and Steam currently distribute the majority of Indie Games on PC and Mac.

There are also independent games distribution websites, such as IndieCity, built to cater exclusively for Indie Games and end discoverability woes for the community.

Therefore, year 2012 appeals to the future of the Microsoft Indie gaming scene compared to alternative Indie Games distribution channels.

Thursday, September 15, 2011

XNA and Breaking into the Games Industry

The video games industry is a multi-billion dollar business. A recent analyst report suggests that the worldwide market for video games will exceed $60 billion in 2011. The report also expects the video games industry to generate more than $80 billion in 2014.

The video games industry is dynamic, innovative and exciting. Consequently, game development itself has diversified: capitalizing on digital distribution, mobile devices, new free-to-play business models, cloud gaming, next-generation game consoles and social networking sites.

Expected growth in the video games industry creates demand for talent, particularly as video games become more complex and require larger development teams. So, this all sounds great, therefore...

How do you break into the games industry?

One common theme to help break into the games industry is simple: Just do it. Go. Make Games.
Quote: if you want to make games for a living, start making them for fun now.

Making your own game shows initiative. It showcases your talent and demonstrates commitment:
That you can produce a complete game! This is where technologies like XNA can help.

XNA is an exciting technology that allows independent game code to be developed and deployed to the Windows PC, Windows Phone 7 and Xbox 360. The App Hub provides tools, information and assistance
to help create games for these devices.

Completing your own game is a rewarding achievement. Plus you create opportunities to blog about your experience and take advantage of social networking sites to: promote your work, share information and build reputation as a bone fide game developer.

In my experience, the transition from independent to professional is difficult, but not impossible.
Here are some further recommendations on how to break into the games industry:

Learn C++:
Play video games:
Focus on skillset:
Subscribe to job sites:
Follow the industry:
Join associations:
Prepare to relocate:
Recommended reading:
C++ is currently the dominant language for game development.
Play tons of games and really get to know the hardware / software.
Target your core strengths and search for jobs with the best fit.
Receive daily emails to guage trends in games skillset requirements.
Keep up-to-date with industry events and read online magazines.
E.g. IDGA / TIGA. Attend conferences and network with professionals.
Consider moving closer to games studios / games related companies.
Game Engine Architecture, Game Programming Gems, Effective C++, Game Scripting Mastery, 3D Math for Graphics / Game Development.

In conclusion, the video games industry seems poised for a bright future. New education policy, company grants and improved Research & Development tax breaks are significant for continued industry growth.

Therefore, if breaking into the games industry appeals to you then just do it. Go. Make Games.
And, of course, the best of luck to you J

Friday, April 1, 2011

XNA and Test Driven Development

In the previous post, we discussed the topic of XNA and Unit Testing.
Now, let's discuss the topic of Test Driven Development with XNA.

Note: this post includes complete code sample on CodePlex.
Download code sample here.

Test Driven Development (TDD)
Test driven development (TDD) is similar to unit testing except the unit tests are written before the objects they test. TDD is gaining as a development best practice because objects are designed with testability in mind: an object and its dependencies must be loosely coupled from the outset.

TDD practitioners follow these three laws:
First Law:
Second Law:
Third Law:
You may not write production code unless you’ve first written a failing unit test
You may not write more of a unit test than is sufficient to fail
You may not write more production code than is sufficient to make the failing unit test pass

Instead of designing a module, coding then testing, you turn the process around and do the testing first.
To put it another way, you don't write a single line of production code until you have a test that fails.

The typical programming sequence is something like this:
 1. Write a test.
 2. Run the test. It fails to compile because the code you're trying to test doesn't even exist yet!
     This is the same thing as failing.
 3. Write a bare-bones stub to make the test compile.
 4. Run the test. It should fail.  If it doesn't, then the test wasn't very good.
 5. Implement the code to make the test pass.
 6. Run the test. It should pass.  If it doesn't, back up one step and try again.
 7. Start over with a new test!

Example
As an example, let's revise the Going Beyond tutorial to demonstrate XNA and Test Driven Development.

Sample
The following code sample refactors the tutorial to move a 3D model using input from the controller.
In order to test the model's rotate and move methods in isolation, the external dependency on the controller must be broken.

Download the code sample from XNA and IoC Container post; Unit Tests will be added to this code.
However, this time the unit tests will be written before the objects they test.

First, identify the System Under Test: the component that will drive the unit tests: Game Object Manager
The Game Object Manager is responsible for managing all objects in the game: currently 1x spaceship.

Therefore, all unit tests will involve the interaction between the SpaceShip and input from the controller:
Action
Rotate Left
Rotate Right
Move Forward
Warp Center
Windows PC
Press left key
Press right key
Press space key
Press enter key
Windows Phone 7
Tap screen bottom left
Tap screen bottom right
Tap screen top right
Tap screen top left
Xbox 360
Move controller left
Move controller right
Press right trigger
Press A button

Unit Tests
Write the unit tests, one for each action: Rotate Left, Rotate Right, Move Forward and Warp Center.

First, add New Windows Game Library project to the solution; this project will contain the unit tests.
Next, add references to the following managed libraries: NUnit Framework and Rhino Mocks.

Next, add one test fixture for the system under test: Game Object Manager
Note: external dependencies are broken and replaced by mock objects:
[TestFixture]
public class GameObjectManagerTests
{
 // System under test.
 private IGameObjectManager gameObjectManager;

 private ICameraManager cameraManager;
 private IContentManager contentManager;
 private IInputManager inputManager;
 private SpaceShip spaceShip;
 private readonly GameTime gameTime = new GameTime();

 [SetUp]
 public void SetUp()
 {
  cameraManager = MockRepository.GenerateStub<ICameraManager>();
  contentManager = MockRepository.GenerateStub<IContentManager>();
  inputManager = MockRepository.GenerateStub<IInputManager>();
  spaceShip = new SpaceShip();

  gameObjectManager = new GameObjectManager(
   cameraManager,
   contentManager,
   inputManager,
   spaceShip);
 }
}
Test #1: Warp Center
  • Simulate input from the controller to return the Warp Center action
  • Update the Game Object Manager which updates the SpaceShip
  • Assert the position of the SpaceShip updates correctly
 1. Write a test.
[Test]
public void Warp()
{
 // Arrange.
 Vector3 modelPostion = new Vector3(10, 20, 30);
 spaceShip = new SpaceShip(modelPostion);

 gameObjectManager = new GameObjectManager(
  cameraManager,
  contentManager,
  inputManager,
  spaceShip);

 inputManager.Stub(im => im.Warp()).Return(true);

 // Act.
 gameObjectManager.Update(gameTime);

 // Assert.
 Assert.AreEqual(Vector3.Zero, gameObjectManager.SpaceShip.ModelPosition);
}
 2. Run the test. It fails to compile because the code you're trying to test doesn't even exist yet!
 3. Write a bare-bones stub to make the test compile.

SPACE SHIP
public class SpaceShip
{
 private Model spaceShipModel;
 private Matrix[] transforms;

 public SpaceShip() : this(Vector3.Zero)
 {
 }

 public SpaceShip(Vector3 modelPosition)
 {
  ModelRotation = 0.0f;
  ModelPosition = modelPosition;
  ModelVelocity = Vector3.Zero;
 }

 // Same code as previous post.
}
INPUT MANAGER
public class InputManager : IInputManager
{
 // InputManager has dependency on InputFactory.
 private readonly AInputFactory inputFactory;

 public InputManager(AInputFactory inputFactory)
 {
  this.inputFactory = inputFactory;
 }

 public Boolean Warp() { return inputFactory.Warp(); }
}
INPUT FACTORY
public abstract class AInputFactory
{
 public abstract Boolean Warp();
}

public class PhoneInputFactory : AInputFactory
{
 public override Boolean Warp() { // Logic goes here. }
}

public class WorkInputFactory : AInputFactory
{
 public override Boolean Warp() { // Logic goes here. }
}

public class XboxInputFactory : AInputFactory
{
 public override Boolean Warp() { // Logic goes here. }
}
GAME OBJECT MANAGER
public class GameObjectManager : IGameObjectManager
{
 // GameObjectManager has dependency on CameraManager, ContentManager, InputManager and SpaceShip.
 private readonly ICameraManager cameraManager;
 private readonly IContentManager contentManager;
 private readonly IInputManager inputManager;
 private readonly SpaceShip spaceShip;

 public GameObjectManager(ICameraManager cameraManager, IContentManager contentManager, IInputManager inputManager, SpaceShip spaceShip)
 {
  this.cameraManager = cameraManager;
  this.contentManager = contentManager;
  this.inputManager = inputManager;
  this.spaceShip = spaceShip;
 }

 // Same code as previous post.

 public SpaceShip SpaceShip { get { return spaceShip; } }
}
 4. Run the test. It should fail.
 5. Implement the code to make the test pass.

GAME OBJECT MANAGER
public class GameObjectManager : IGameObjectManager
{
 // Same code as previous post.

 // Update each game object.
 public void Update(GameTime gameTime)
 {
  Boolean warp = inputManager.Warp();
  spaceShip.Update(warp);
 }
}
SPACE SHIP
public class SpaceShip
{
 // Same code as previous post.

 // Update warp if action is invoked.
 public void Update(Boolean warp)
 {
  // Warp.
  if (warp)
  {
   ModelPosition = Vector3.Zero;
   ModelVelocity = Vector3.Zero;
   ModelRotation = 0.0f;
  }
 }
}
 6. Run the test. It should pass.
 7. Start over with a new test!

Test #2: Rotate Left
  • Simulate input from the controller to return the Rotate Left action
  • Update the Game Object Manager which updates the SpaceShip
  • Assert the rotation of the SpaceShip updates correctly
 1. Write a test.
[Test]
public void Left()
{
 // Arrange.
 inputManager.Stub(im => im.Rotate()).Return(-1);

 // Act.
 gameObjectManager.Update(gameTime);

 // Assert.
 Assert.AreEqual(0.1f, gameObjectManager.SpaceShip.ModelRotation);
}
 2. Run the test. It fails to compile because the code you're trying to test doesn't even exist yet!
 3. Write a bare-bones stub to make the test compile.

INPUT MANAGER
public class InputManager : IInputManager
{
 // InputManager has dependency on InputFactory.
 private readonly AInputFactory inputFactory;

 public InputManager(AInputFactory inputFactory)
 {
  this.inputFactory = inputFactory;
 }

 public Single Rotate() { return inputFactory.Rotate(); }
 public Boolean Warp() { return inputFactory.Warp(); }
}
INPUT FACTORY
public abstract class AInputFactory
{
 public abstract Single Rotate();
 public abstract Boolean Warp();
}

public class PhoneInputFactory : AInputFactory
{
 public override Single Rotate() { // Logic goes here. }
 public override Boolean Warp() { // Logic goes here. }
}

public class WorkInputFactory : AInputFactory
{
 public override Single Rotate() { // Logic goes here. }
 public override Boolean Warp() { // Logic goes here. }
}

public class XboxInputFactory : AInputFactory
{
 public override Single Rotate() { // Logic goes here. }
 public override Boolean Warp() { // Logic goes here. }
}
 4. Run the test. It should fail.
 5. Implement the code to make the test pass.

GAME OBJECT MANAGER
public class GameObjectManager : IGameObjectManager
{
 // Same code as previous post.

 // Update each game object.
 public void Update(GameTime gameTime)
 {
  Single rotate = inputManager.Rotate();
  Boolean warp = inputManager.Warp();

  spaceShip.Update(rotate, warp);
 }
}
SPACE SHIP
public class SpaceShip
{
 // Same code as previous post.

 // Update rotate and warp if actions are invoked.
 public void Update(Single rotate, Boolean warp)
 {
  // Rotate.
  if (rotate != 0)
  {
   const Single scale = 0.10f;
   ModelRotation -= rotate * scale;
  }

  // Warp.
  if (warp)
  {
   ModelPosition = Vector3.Zero;
   ModelVelocity = Vector3.Zero;
   ModelRotation = 0.0f;
  }
 }
}
 6. Run the test. It should pass.
 7. Start over with a new test!

Test #3: Rotate Right
  • Simulate input from the controller to return the Rotate Right action
  • Update the Game Object Manager which updates the SpaceShip
  • Assert the rotation of the SpaceShip updates correctly
 1. Write a test.
[Test]
public void Right()
{
 // Arrange.
 inputManager.Stub(im => im.Rotate()).Return(1);

 // Act.
 gameObjectManager.Update(gameTime);

 // Assert.
 Assert.AreEqual(-0.1f, gameObjectManager.SpaceShip.ModelRotation);
}
 2. Run the test. It fails to compile because the code you're trying to test doesn't even exist yet!
 3. Write a bare-bones stub to make the test compile.
 4. Run the test. It should fail.
 5. Implement the code to make the test pass.
 6. Run the test. It should pass.
 7. Start over with a new test!

Test #4: Move Forward
  • Simulate input from the controller to return the Move Forward action
  • Update the Game Object Manager which updates the SpaceShip
  • Assert the position of the SpaceShip updates correctly
 1. Write a test.
[Test]
public void Move()
{
 // Arrange.
 inputManager.Stub(im => im.Move()).Return(1);

 // Act.
 gameObjectManager.Update(gameTime);

 // Assert.
 Assert.AreEqual(-1.0f, gameObjectManager.SpaceShip.ModelPosition.Z);
}
 2. Run the test. It fails to compile because the code you're trying to test doesn't even exist yet!
 3. Write a bare-bones stub to make the test compile.

INPUT MANAGER
public class InputManager : IInputManager
{
 // InputManager has dependency on InputFactory.
 private readonly AInputFactory inputFactory;

 public InputManager(AInputFactory inputFactory)
 {
  this.inputFactory = inputFactory;
 }

 public Single Rotate() { return inputFactory.Rotate(); }
 public Single Move() { return inputFactory.Move(); }
 public Boolean Warp() { return inputFactory.Warp(); }
}
INPUT FACTORY
public abstract class AInputFactory
{
 public abstract Single Rotate();
 public abstract Single Move();
 public abstract Boolean Warp();
}

public class PhoneInputFactory : AInputFactory
{
 public override Single Rotate() { // Logic goes here. }
 public override Single Move() { // Logic goes here. }
 public override Boolean Warp() { // Logic goes here. }
}

public class WorkInputFactory : AInputFactory
{
 public override Single Rotate() { // Logic goes here. }
 public override Single Move() { // Logic goes here. }
 public override Boolean Warp() { // Logic goes here. }
}

public class XboxInputFactory : AInputFactory
{
 public override Single Rotate() { // Logic goes here. }
 public override Single Move() { // Logic goes here. }
 public override Boolean Warp() { // Logic goes here. }
}
 4. Run the test. It should fail.
 5. Implement the code to make the test pass.

GAME OBJECT MANAGER
public class GameObjectManager : IGameObjectManager
{
 // Same code as previous post.

 // Update each game object.
 public void Update(GameTime gameTime)
 {
  Single rotate = inputManager.Rotate();
  Single move = inputManager.Move();
  Boolean warp = inputManager.Warp();

  spaceShip.Update(rotate, move, warp);
 }
}
SPACE SHIP
public class SpaceShip
{
 // Same code as previous post.

 // Update rotate, move and warp if actions are invoked.
 public void Update(Single rotate, Single move, Boolean warp)
 {
  // Rotate.
  if (rotate != 0)
  {
   const Single scale = 0.10f;
   ModelRotation -= rotate * scale;
  }

  // Move.
  if (move != 0)
  {
   // Create some velocity if move action invoked.
   Vector3 modelVelocityAdd = Vector3.Zero;

   // Find out thrust direction using rotation.
   Single sin = -(Single)Math.Sin(ModelRotation);
   Single cos = -(Single)Math.Cos(ModelRotation);

   modelVelocityAdd.X = sin;
   modelVelocityAdd.Z = cos;

   // Scale direction by the amount of movement.
   modelVelocityAdd *= move;

   // Finally, add this vector to our velocity.
   ModelVelocity += modelVelocityAdd;
  }

  // Warp.
  if (warp)
  {
   ModelPosition = Vector3.Zero;
   ModelVelocity = Vector3.Zero;
   ModelRotation = 0.0f;
  }

  // Add velocity to position and bleed off velocity over time.
  ModelPosition += ModelVelocity;
  ModelVelocity *= 0.97f;
 }
}
 6. Run the test. It should pass.
 7. All tests complete!

Download code sample here.

Summary
The revised Going Beyond tutorial demonstrates how to integrate Unit Tests into an existing code base.
However, writing the unit tests before the code helps drive development of the systems under test.

In conclusion, agile software development does seem to have the potential to scale using XNA:
However, in it's current form, dependency injection may be susceptible to circular references:
  • ComponentA depends on ComponentB
  • ComponentB depends on ComponentA
A better implementation may be to construct a base class component that all subsystems inherit from;
Extract the GameManager into the base to manage interaction between all subsystems in the game:
public abstract class BaseComponent
{
 public GameManager GameManager
 {
  get { return gameManager; }
  set { if (null == gameManager) { gameManager = value;  }}
 }

 private GameManager gameManager;
}

public class ComponentA : BaseComponent
{
 public ComponentA()
 {
  PropertyA = "Hello";
 }
 public void Print()
 {
  PropertyA = GameManager.ComponentB.PropertyB;
 }

 public String PropertyA { get; private set; }
}

public class ComponentB : BaseComponent
{
 public ComponentB()
 {
  PropertyB = "World";
 }
 public void Print()
 {
  PropertyB = GameManager.ComponentA.PropertyA;
 }

 public String PropertyB { get; private set; }
}

public class GameManager
{
 public GameManager(ComponentA componentA, ComponentB componentB)
 {
  ComponentA = componentA;
  ComponentB = componentB;
 }

 public ComponentA ComponentA { get; private set; }
 public ComponentB ComponentB { get; private set; }
}
Once issues such as circular references have been resolved, then there is an opportunity to integrate more complex game code using XNA and agile software development techniques.

Thursday, March 17, 2011

XNA and Unit Testing

In the previous post, we discussed the topic of XNA and an IoC Container.
Now, let's build on this information to discuss Unit Testing with XNA.

Note: this post includes complete code sample on CodePlex.
Download code sample here.

Unit Testing
Unit testing is the practice in which individual units of source code are tested in isolation. Consequently, unit tests do not measure how objects interact with dependent objects; these are integration tests.

In order to successfully unit test an individual game component, external dependencies are broken, and replaced by mock objects: fake objects that emulate real classes and help test expectations about how that class should function.

Therefore, clean unit tests should be written F.I.R.S.T:
Fast
Independent
Repeatable
Self-validating
Timely
Tests should be fast
Tests should not depend on each other
Tests should be repeatable in any environment
Tests should have a Boolean output: either they pass or fail
Tests should be written in a timely fashion

Example
As an example, let's revise the Going Beyond tutorial to demonstrate XNA and Unit Testing.

Sample
The following code sample refactors the tutorial to move a 3D model using input from the controller.
In order to test the model's rotate and move methods in isolation, the external dependency on the controller must be broken.

Download the code sample from XNA and IoC Container post; Unit Tests will be added to this code.
Write all code changes first then add unit tests afterwards to assert the correct behavior.

First, identify the System Under Test: the component that will drive the unit tests: Game Object Manager
The Game Object Manager is responsible for managing all objects in the game: currently 1x spaceship.

Therefore, all unit tests will involve the interaction between the SpaceShip and input from the controller:
Action
Rotate Left
Rotate Right
Move Forward
Warp Center
Windows PC
Press left key
Press right key
Press space key
Press enter key
Windows Phone 7
Tap screen bottom left
Tap screen bottom right
Tap screen top right
Tap screen top left
Xbox 360
Move controller left
Move controller right
Press right trigger
Press A button

All logic to load, update and draw the model can be encapsulated into a single game object:
SPACE SHIP
public class SpaceShip
{
 private Model spaceShipModel;
 private Matrix[] transforms;

 public SpaceShip() : this(Vector3.Zero)
 {
 }

 public SpaceShip(Vector3 modelPosition)
 {
  ModelRotation = 0.0f;
  ModelPosition = modelPosition;
  ModelVelocity = Vector3.Zero;
 }

 // Load model and set view/projection matrices.
 public void LoadContent(Model theSpaceShipModel, Matrix viewMatrix, Matrix projectionMatrix)
 {
  // Same code as previous post.
 }

 // Update rotate, move and warp if actions are invoked.
 public void Update(Single rotate, Single move, Boolean warp)
 {
  // Rotate.
  if (rotate != 0)
  {
   const Single scale = 0.10f;
   ModelRotation -= rotate * scale;
  }

  // Move.
  if (move != 0)
  {
   // Create some velocity if move action invoked.
   Vector3 modelVelocityAdd = Vector3.Zero;

   // Find out thrust direction using rotation.
   Single sin = -(Single)Math.Sin(ModelRotation);
   Single cos = -(Single)Math.Cos(ModelRotation);

   modelVelocityAdd.X = sin;
   modelVelocityAdd.Z = cos;

   // Scale direction by the amount of movement.
   modelVelocityAdd *= move;

   // Finally, add this vector to our velocity.
   ModelVelocity += modelVelocityAdd;
  }

  // Warp.
  if (warp)
  {
   ModelPosition = Vector3.Zero;
   ModelVelocity = Vector3.Zero;
   ModelRotation = 0.0f;
  }

  // Add velocity to position and bleed off velocity over time.
  ModelPosition += ModelVelocity;
  ModelVelocity *= 0.97f;
 }

 // Draw model.
 public void Draw()
 {
  // Same code as previous post.
 }

 public Single ModelRotation { get; private set; }
 public virtual Vector3 ModelPosition { get; private set; }
 public Vector3 ModelVelocity { get; private set; }
}
Next, update the Game Object Manager: detect input and set the rotate, move and warp values:
GAME OBJECT MANAGER
public class GameObjectManager : IGameObjectManager
{
 // GameObjectManager has dependency on CameraManager, ContentManager, InputManager and SpaceShip.
 private readonly ICameraManager cameraManager;
 private readonly IContentManager contentManager;
 private readonly IInputManager inputManager;
 private readonly SpaceShip spaceShip;

 public GameObjectManager(ICameraManager cameraManager, IContentManager contentManager, IInputManager inputManager, SpaceShip spaceShip)
 {
  this.cameraManager = cameraManager;
  this.contentManager = contentManager;
  this.inputManager = inputManager;
  this.spaceShip = spaceShip;
 }

 // Load content for each game object.
 public void LoadContent()
 {
  spaceShip.LoadContent(contentManager.SpaceShipModel, cameraManager.ViewMatrix, cameraManager.ProjectionMatrix);
 }

 // Update each game object.
 public void Update(GameTime gameTime)
 {
  Single rotate = inputManager.Rotate();
  Single move = inputManager.Move();
  Boolean warp = inputManager.Warp();

  spaceShip.Update(rotate, move, warp);
 }

 // Draw each game object.
 public void Draw()
 {
  spaceShip.Draw();
 }

 public SpaceShip SpaceShip { get { return spaceShip; } }
}
Finally, input detection: each device will have its own rotate, move and warp implementation:
INPUT MANAGER
public class InputManager : IInputManager
{
 // InputManager has dependency on InputFactory.
 private readonly AInputFactory inputFactory;

 public InputManager(AInputFactory inputFactory)
 {
  this.inputFactory = inputFactory;
 }

 public Single Rotate() { return inputFactory.Rotate(); }
 public Single Move() { return inputFactory.Move(); }
 public Boolean Warp() { return inputFactory.Warp(); }
}
INPUT FACTORY
public abstract class AInputFactory
{
 public abstract Single Rotate();
 public abstract Single Move();
 public abstract Boolean Warp();
}

public class PhoneInputFactory : AInputFactory
{
 public override Single Rotate() { // Logic goes here. }
 public override Single Move() { // Logic goes here. }
 public override Boolean Warp() { // Logic goes here. }
}

public class WorkInputFactory : AInputFactory
{
 public override Single Rotate() { // Logic goes here. }
 public override Single Move() { // Logic goes here. }
 public override Boolean Warp() { // Logic goes here. }
}

public class XboxInputFactory : AInputFactory
{
 public override Single Rotate() { // Logic goes here. }
 public override Single Move() { // Logic goes here. }
 public override Boolean Warp() { // Logic goes here. }
}

Unit Tests
Write the unit tests, one for each action: Rotate Left, Rotate Right, Move Forward and Warp Center.

First, add New Windows Game Library project to the solution; this project will contain the unit tests.
Next, add references to the following managed libraries: NUnit Framework and Rhino Mocks.

Next, add one test fixture for the system under test: Game Object Manager
Note: external dependencies are broken and replaced by mock objects:
[TestFixture]
public class GameObjectManagerTests
{
 // System under test.
 private IGameObjectManager gameObjectManager;

 private ICameraManager cameraManager;
 private IContentManager contentManager;
 private IInputManager inputManager;
 private SpaceShip spaceShip;
 private readonly GameTime gameTime = new GameTime();

 [SetUp]
 public void SetUp()
 {
  cameraManager = MockRepository.GenerateStub<ICameraManager>();
  contentManager = MockRepository.GenerateStub<IContentManager>();
  inputManager = MockRepository.GenerateStub<IInputManager>();
  spaceShip = new SpaceShip();

  gameObjectManager = new GameObjectManager(
   cameraManager,
   contentManager,
   inputManager,
   spaceShip);
 }
}
Test #1: Rotate Left
  • Simulate input from the controller to return the Rotate Left action
  • Update the Game Object Manager which updates the SpaceShip
  • Assert the rotation of the SpaceShip updates correctly
[Test]
public void Left()
{
 // Arrange.
 inputManager.Stub(im => im.Rotate()).Return(-1);

 // Act.
 gameObjectManager.Update(gameTime);

 // Assert.
 Assert.AreEqual(0.1f, gameObjectManager.SpaceShip.ModelRotation);
}
Test #2: Rotate Right
  • Simulate input from the controller to return the Rotate Right action
  • Update the Game Object Manager which updates the SpaceShip
  • Assert the rotation of the SpaceShip updates correctly
[Test]
public void Right()
{
 // Arrange.
 inputManager.Stub(im => im.Rotate()).Return(1);

 // Act.
 gameObjectManager.Update(gameTime);

 // Assert.
 Assert.AreEqual(-0.1f, gameObjectManager.SpaceShip.ModelRotation);
}
Test #3: Move Forward
  • Simulate input from the controller to return the Move Forward action
  • Update the Game Object Manager which updates the SpaceShip
  • Assert the position of the SpaceShip updates correctly
[Test]
public void Move()
{
 // Arrange.
 inputManager.Stub(im => im.Move()).Return(1);

 // Act.
 gameObjectManager.Update(gameTime);

 // Assert.
 Assert.AreEqual(-1.0f, gameObjectManager.SpaceShip.ModelPosition.Z);
}
Test #4: Warp Center
  • Simulate input from the controller to return the Warp Center action
  • Update the Game Object Manager which updates the SpaceShip
  • Assert the position of the SpaceShip updates correctly
[Test]
public void Warp()
{
 // Arrange.
 Vector3 modelPostion = new Vector3(10, 20, 30);
 spaceShip = new SpaceShip(modelPostion);

 gameObjectManager = new GameObjectManager(
  cameraManager,
  contentManager,
  inputManager,
  spaceShip);

 inputManager.Stub(im => im.Warp()).Return(true);

 // Act.
 gameObjectManager.Update(gameTime);

 // Assert.
 Assert.AreEqual(Vector3.Zero, gameObjectManager.SpaceShip.ModelPosition);
}
Download code sample here.

Summary
The revised Going Beyond tutorial demonstrates how to integrate Unit Tests into an existing code base.
However, simply adding unit tests after the code is written does not guarantee bug free code!

For example: subtle bugs may be introduced in code that are not caught when tested in isolation simply because the tests may return false positive results.

Unit tests state what you expect the code to do. Therefore, a better approach is to write the tests first: Writing the test before the code should uncover issues quicker because assertions in the test can fail.

The practice of writing unit tests before the objects they test is called: Test Driven Development.
This will be the topic in the next post.

Tuesday, March 1, 2011

XNA and an IoC Container

In the previous post, we discussed the topic of XNA and Dependency Injection.
Now, let's build on this information to discuss an IoC Container with XNA.

Note: this post includes complete code sample on CodePlex.
Download code sample here.

IoC Container
An IoC Container is a framework component that automatically resolves all dependent references for an object: when an object is constructed, the container will instantiate all dependent objects automatically and injects them into the source object accordingly.

There are many IoC containers available to .NET developers:
However, Ninject is currently the only IoC container that is compatible with the .NET Compact Framework and will work on Windows Phone 7 and Xbox 360.

Example
As an example, let's revise the Going Beyond tutorial to demonstrate XNA and an IoC Container.

Sample
Download the code sample from the previous post; the IoC Container will be added to this code.
All logic to resolve dependent component references can be encapulated into a single object:

IOC CONTAINER
public static class IoCContainer
{
 private static IKernel kernel;

 public static T Resolve<T>()
 {
  if (null == kernel)
  {
   INinjectModule staticModule = new StaticModule();
   INinjectModule[] modules = new[] { staticModule };

   kernel = new StandardKernel(modules);
  }

  return kernel.Get<T>();
 }

 public static void Release()
 {
  if (null == kernel)
  {
   return;
  }

  kernel.Dispose();
  kernel = null;
 }
}
Next, build a module to configure the bindings and manage the lifetime of all component references:
STATIC MODULE
public class StaticModule : NinjectModule
{
 public override void Load()
 {
  Bind<IGameManager>().To<GameManager>().InSingletonScope();
  Bind<ICameraManager>().To<CameraManager>().InSingletonScope();
  Bind<IContentManager>().To<ContentManager>().InSingletonScope();
  Bind<IGameObjectManager>().To<GameObjectManager>().InSingletonScope();
  Bind<IGraphicsManager>().To<GraphicsManager>().InSingletonScope();
  Bind<IScreenManager>().To<ScreenManager>().InSingletonScope();
 }
}
Next, invoke the IoC Container to construct a single instance of the GameManager component:
GAME FACTORY
public static class GameFactory
{
 private static IGameManager gameManager;

 public static IGameManager GetGameManager()
 {
  return gameManager ?? (gameManager = IoCContainer.Resolve<IGameManager>());
 }

 public static void Release()
 {
  IoCContainer.Release();
 }
}
Finally, dispose of the IoC Container when the game exits:
GAME MANAGER
public class GameManager : IGameManager
{
 // Same code as previous post.

 // Exit game.
 public void Exit()
 {
  GameFactory.Release();
 }
}
GAME
public class MyGame : Game
{
 // Same code as previous post.

 protected override void OnExiting(object sender, EventArgs args)
 {
  gameManager.Exit();
  base.OnExiting(sender, args);
 }
}
Execute the updated game code: the output should be identical to the previous post.

Device Factory
In an older post, we discussed the topic of a Device Factory. Essentially, the Device Factory is an abstract base class that contains all game code common to every device, but allows device specific game code to be overridden in the concrete implementation class through polymorphism.

Let's complete the sample by extending the current code base to target all devices currently available in
XNA 4.0: Windows PC, Windows Phone 7 and Xbox 360.

First, build the Device Factory abstract base class and all concrete implementation classes:
DEVICE FACTORY
public abstract class ADeviceFactory
{
 // GraphicsManager.
 public Int32 PreferredBackBufferWidth { get; protected set; }
 public Int32 PreferredBackBufferHeight { get; protected set; }
 public Boolean IsFullScreen { get; protected set; }

 // ContentManager.
 public String RootDirectory { get; protected set; }
}

public class PhoneDeviceFactory : ADeviceFactory
{
 public PhoneDeviceFactory()
 {
  PreferredBackBufferWidth = 800;
  PreferredBackBufferHeight = 480;
  IsFullScreen = true;
  RootDirectory = "Content";
 }
}

public class WorkDeviceFactory : ADeviceFactory
{
 public WorkDeviceFactory()
 {
  PreferredBackBufferWidth = 1280;
  PreferredBackBufferHeight = 720;
  IsFullScreen = false;
  RootDirectory = "Content";
 }
}

public class XboxDeviceFactory : ADeviceFactory
{
 public XboxDeviceFactory()
 {
  PreferredBackBufferWidth = 1280;
  PreferredBackBufferHeight = 720;
  IsFullScreen = false;
  RootDirectory = "Content";
 }
}
Next, build a Device Manager to delegate all work to the Device Factory:
DEVICE MANAGER
public class DeviceManager : IDeviceManager
{
 // DeviceManager has dependency on DeviceFactory.
 private readonly ADeviceFactory deviceFactory;

 public DeviceManager(ADeviceFactory deviceFactory)
 {
  this.deviceFactory = deviceFactory;
 }

 public ADeviceFactory DeviceFactory
 {
  get { return deviceFactory; }
 }
}
Note: build an Input Factory and Input Manager; these will be placeholders available for future posts:
INPUT FACTORY
public abstract class AInputFactory
{
}
public class PhoneInputFactory : AInputFactory
{
}
public class WorkInputFactory : AInputFactory
{
}
public class XboxInputFactory : AInputFactory
{
}
INPUT MANAGER
public class InputManager : IInputManager
{
}
Next, build a module to configure the bindings and manage the lifetime of all device specific components:
DYNAMIC MODULE
 public class DynamicModule : NinjectModule
 {
  public override void Load()
  {
#if WINDOWS_PHONE
   Bind<ADeviceFactory>().To<PhoneDeviceFactory>().InSingletonScope();
   Bind<AInputFactory>().To<PhoneInputFactory>().InSingletonScope();
#elif WINDOWS
   Bind<ADeviceFactory>().To<WorkDeviceFactory>().InSingletonScope();
   Bind<AInputFactory>().To<WorkInputFactory>().InSingletonScope();
#elif XBOX
   Bind<ADeviceFactory>().To<XboxDeviceFactory>().InSingletonScope();
   Bind<AInputFactory>().To<XboxInputFactory>().InSingletonScope();
#else
   throw new ArgumentOutOfRangeException("DynamicModule");
#endif
  }
 }
Next, update the IoC Container:
IOC CONTAINER
public static class IoCContainer
{
 private static IKernel kernel;

 public static T Resolve()
 {
  if (null == kernel)
  {
   INinjectModule staticModule = new StaticModule();
   INinjectModule dynamicModule = new DynamicModule();

   INinjectModule[] modules = new[] { staticModule, dynamicModule };
   kernel = new StandardKernel(modules);
  }

  return kernel.Get();
 }

 public static void Release()
 {
  if (null == kernel)
  {
   return;
  }

  kernel.Dispose();
  kernel = null;
 }
}
Finally, inject all device specific components using constructor injection technique:
CONTENT MANAGER
public class ContentManager : IContentManager
{
 // ContentManager has dependency on DeviceManager.
 private readonly IDeviceManager deviceManager;
 private XnaContentManager content;

 public ContentManager(IDeviceManager deviceManager)
 {
  this.deviceManager = deviceManager;
 }

 // Load all content.
 public void LoadContent(XnaContentManager xnaContent)
 {
  if (null != content)
  {
   return;
  }

  content = xnaContent;
  content.RootDirectory = deviceManager.DeviceFactory.RootDirectory;
  SpaceShipModel = content.Load<Model>("Models/p1_wedge");
 }

 // Unload all content.
 public void UnloadContent()
 {
  if (null == content)
  {
   return;
  }

  content.Unload();
 }

 public Model SpaceShipModel { get; private set; }
}
GRAPHICS MANAGER
public class GraphicsManager : IGraphicsManager
{
 // GraphicsManager has dependency on DeviceManager.
 private readonly IDeviceManager deviceManager;
 private XnaGraphicsDeviceManager graphics;

 public GraphicsManager(IDeviceManager deviceManager)
 {
  this.deviceManager = deviceManager;
 }

 // Initialize all graphics properties.
 public void Initialize(XnaGraphicsDeviceManager xnaGraphics)
 {
  if (null != graphics)
  {
   return;
  }

  graphics = xnaGraphics;
  graphics.PreferredBackBufferWidth = deviceManager.DeviceFactory.PreferredBackBufferWidth;
  graphics.PreferredBackBufferHeight = deviceManager.DeviceFactory.PreferredBackBufferHeight;
  graphics.IsFullScreen = deviceManager.DeviceFactory.IsFullScreen;
  graphics.ApplyChanges();

  GraphicsDevice = graphics.GraphicsDevice;
  SpriteBatch = new SpriteBatch(GraphicsDevice);
 }

 public GraphicsDevice GraphicsDevice { get; private set; }
 public Single AspectRatio { get { return GraphicsDevice.Viewport.AspectRatio; } }
 public SpriteBatch SpriteBatch { get; private set; }
}
Download code sample here.

Summary
The revised Going Beyond example demonstrates how to add an IoC Container to an existing code base. Once the bindings for each game component have been configured, the IoC Container will automatically resolve all dependent references for an object.

Therefore, the code base is now in a testable state: each game component is now able to be tested in isolation: Unit Testing. This will be the topic in the next post.