SteveProXNA

Retrospective III

noreply@blogger.com (SteveProXNA) — Sun, 01 Jan 2012 12:58:00 +0000

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

2011 Achievements

Integrate agile software methodologies into XNA game development
Reference to XNA and Unit Testing by George Clingerman on XNA Notes
Give presentation on System and Unit testing within game development
Build C++ game engine to extend knowledge of DirectX/XNA interaction
Purchase Windows Phone 7 book. Begin WP7 and Xbox game project
Assist over 1,000 Indies in 50 regions plus with XNA and TAX
Publish article on XNA and Breaking into the Games Industry
Write lots more game code as Independent and Professional

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.

XNA and Breaking into the Games Industry

noreply@blogger.com (SteveProXNA) — Thu, 15 Sep 2011 07:41:00 +0000

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,
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 you 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

XNA and Test Driven Development

noreply@blogger.com (SteveProXNA) — Fri, 01 Apr 2011 07:10:00 +0000

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.

XNA and Unit Testing

noreply@blogger.com (SteveProXNA) — Thu, 17 Mar 2011 09:17:00 +0000

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. }
}

[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.

XNA and an IoC Container

noreply@blogger.com (SteveProXNA) — Tue, 01 Mar 2011 08:06:00 +0000

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()
 {
  if (null == kernel)
  {
   INinjectModule staticModule = new StaticModule();
   INinjectModule[] modules = new[] { staticModule };

   kernel = new StandardKernel(modules);
  }

  return kernel.Get();
 }

 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.

XNA and Dependency Injection

noreply@blogger.com (SteveProXNA) — Mon, 14 Feb 2011 08:16:00 +0000

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

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

Dependency Injection
Dependency Injection is a simple pattern to loosely couple objects and break their dependencies.
The resulting design principle, Dependency Inversion, states: Depend upon abstractions.
Do not depend upon concrete classes.

By coupling an object to an interface instead of a specific concrete implementation, you have the ability to use any implementation with minimal change and risk. This concept is important, especially when testing an object in isolation (unit testing).

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

First, isolate the components used throughout the tutorial:

Component
CameraManager
ContentManager
GameObjectManager
GraphicsManager
ScreenManager

Responsibility
manages fixed camera
manages all game content
manages all game objects
manages all graphics
manages all screens

Information
view / projection matrices
currently only 1x model
currently only 1x spaceship
all graphics properties
currently only 1x screen

Next, identify the dependencies between the components:

Component
CameraManager
GameObjectManager
GameObjectManager
ScreenManager
ScreenManager

Dependency
depends on GraphicsManager
depends on CameraManager
depends on ContentManager
depends on GameObjectManager
depends on GraphicsManager

Information
aspect ratio on graphics device
game object view / projection
load game object content
update / draw game objects
clear graphics device

Sample
The following code sample refactors the Going Beyond tutorial to render a 3D model on screen.
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()
 {
  ModelRotation = 0.0f;
  ModelPosition = Vector3.Zero;
  ModelVelocity = Vector3.Zero;
 }

 // Load model and set view/projection matrices.
 public void LoadContent(Model theSpaceShipModel, Matrix viewMatrix, Matrix projectionMatrix)
 {
  spaceShipModel = theSpaceShipModel;
  transforms = new Matrix[spaceShipModel.Bones.Count];
  spaceShipModel.CopyAbsoluteBoneTransformsTo(transforms);

  foreach (BasicEffect effect in spaceShipModel.Meshes.SelectMany(mesh => mesh.Effects.Cast<BasicEffect>()))
  {
   effect.EnableDefaultLighting();
   effect.View = viewMatrix;
   effect.Projection = projectionMatrix;
  }
 }

 // Update angle of rotation.
 public void Update(GameTime gameTime)
 {
  Single temps = MathHelper.ToRadians(0.05f);
  Single delta = (Single)gameTime.ElapsedGameTime.TotalMilliseconds;
  ModelRotation -= delta * temps;
 }

 // Draw model.
 public void Draw()
 {
  foreach (ModelMesh mesh in spaceShipModel.Meshes)
  {
   foreach (BasicEffect effect in mesh.Effects)
   {
    effect.World = transforms[mesh.ParentBone.Index]
     * Matrix.CreateRotationY(ModelRotation)
     * Matrix.CreateTranslation(ModelPosition);
   }

   mesh.Draw();
  }
 }

 public Single ModelRotation { get; private set; }
 public Vector3 ModelPosition { get; private set; }
 public Vector3 ModelVelocity { get; private set; }
}

Next, build the components that do not have any dependencies:
CONTENT MANAGER

using XnaContentManager = Microsoft.Xna.Framework.Content.ContentManager;

public class ContentManager : IContentManager
{
 private XnaContentManager content;

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

  content = xnaContent;
  content.RootDirectory = "Content";
  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

using XnaGraphicsDeviceManager = Microsoft.Xna.Framework.GraphicsDeviceManager;

public class GraphicsManager : IGraphicsManager
{
 private XnaGraphicsDeviceManager graphics;

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

  graphics = xnaGraphics;
  graphics.PreferredBackBufferWidth = 800;
  graphics.PreferredBackBufferHeight = 480;
  graphics.IsFullScreen = false;
  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; }
}

Next, build the the remaining components that do have dependencies; here each dependent component is injected manually using constructor injection technique:

CAMERA MANAGER

public class CameraManager : ICameraManager
{
 // CameraManager has dependency on GraphicsManager.
 private readonly IGraphicsManager graphicsManager;

 public CameraManager(IGraphicsManager graphicsManager)
 {
  this.graphicsManager = graphicsManager;
 }

 // Initialize camera view/projection matrices.
 public void Initialize(Vector3 cameraPosition)
 {
  ViewMatrix = Matrix.CreateLookAt(cameraPosition, Vector3.Zero, Vector3.Up);
  ProjectionMatrix = Matrix.CreatePerspectiveFieldOfView(MathHelper.PiOver4, graphicsManager.AspectRatio, 1.0f, 10000.0f);
 }

 public Matrix ViewMatrix { get; private set; }
 public Matrix ProjectionMatrix { get; private set; }
}

GAME OBJECT MANAGER

public class GameObjectManager : IGameObjectManager
{
 // GameObjectManager has dependency on CameraManager and ContentManager.
 private readonly ICameraManager cameraManager;
 private readonly IContentManager contentManager;
 private readonly SpaceShip spaceShip;

 public GameObjectManager(ICameraManager cameraManager, IContentManager contentManager)
 {
  this.cameraManager = cameraManager;
  this.contentManager = contentManager;
  spaceShip = new 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)
 {
  spaceShip.Update(gameTime);
 }

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

SCREEN MANAGER

public class ScreenManager : IScreenManager
{
 // ScreenManager has dependency on GameObjectManager and GraphicsManager.
 private readonly IGameObjectManager gameObjectManager;
 private readonly IGraphicsManager graphicsManager;

 public ScreenManager(IGameObjectManager gameObjectManager, IGraphicsManager graphicsManager)
 {
  this.gameObjectManager = gameObjectManager;
  this.graphicsManager = graphicsManager;
 }

 // Update each game object using GameObjectManager.
 public void Update(GameTime gameTime)
 {
  gameObjectManager.Update(gameTime);
 }

 // Draw each game object using GameObjectManager.
 public void Draw()
 {
  graphicsManager.GraphicsDevice.Clear(Color.Black);
  gameObjectManager.Draw();
 }
}

Finally, build a GameManager component to manage all interaction between the main game class and each game component listed above. Again, each dependent component is injected manually using constructor injection technique:

GAME MANAGER

public class GameManager : IGameManager
{
 private readonly ICameraManager cameraManager;
 private readonly IContentManager contentManager;
 private readonly IGameObjectManager gameObjectManager;
 private readonly IGraphicsManager graphicsManager;
 private readonly IScreenManager screenManager;

 public GameManager(
  ICameraManager cameraManager,
  IContentManager contentManager,
  IGameObjectManager gameObjectManager,
  IGraphicsManager graphicsManager,
  IScreenManager screenManager
  )
 {
  this.cameraManager = cameraManager;
  this.contentManager = contentManager;
  this.gameObjectManager = gameObjectManager;
  this.graphicsManager = graphicsManager;
  this.screenManager = screenManager;
 }

 // Initialize graphics and camera.
 public void Initialize(GraphicsDeviceManager graphics)
 {
  graphicsManager.Initialize(graphics);
  cameraManager.Initialize(new Vector3(0.0f, 50.0f, 5000.0f));
 }

 // Load all content.
 public void LoadContent(XnaContentManager content)
 {
  contentManager.LoadContent(content);
  gameObjectManager.LoadContent();
 }

 // Unload all content.
 public void UnloadContent()
 {
  contentManager.UnloadContent();
 }

 // Update each screen.
 public void Update(GameTime gameTime)
 {
  screenManager.Update(gameTime);
 }

 // Draw each screen.
 public void Draw()
 {
  screenManager.Draw();
 }
}

For simplicity, build a GameFactory to construct a single instance of the GameMananger component:
GAME FACTORY

public static class GameFactory
{
 private static IGameManager gameManager;

 public static IGameManager GetGameManager()
 {
  if (null == gameManager)
  {
   IContentManager contentManager = new ContentManager();
   IGraphicsManager graphicsManager = new GraphicsManager();
   ICameraManager cameraManager = new CameraManager(graphicsManager);
   IGameObjectManager gameObjectManager = new GameObjectManager(cameraManager, contentManager);
   IScreenManager screenManager = new ScreenManager(gameObjectManager, graphicsManager);

   gameManager = new GameManager(
    cameraManager,
    contentManager,
    gameObjectManager,
    graphicsManager,
    screenManager
    );
  }

  return gameManager;
 }
}

For completeness, here is the main game class; the GameManager now manages all game actions:
GAME

public class MyGame : Game
{
 private readonly GraphicsDeviceManager graphics;
 private readonly IGameManager gameManager;

 public MyGame()
 {
  graphics = new GraphicsDeviceManager(this);
  gameManager = GameFactory.GetGameManager();
 }

 protected override void Initialize()
 {
  gameManager.Initialize(graphics);
  base.Initialize();
 }

 protected override void LoadContent()
 {
  gameManager.LoadContent(Content);
  base.LoadContent();
 }

 protected override void UnloadContent()
 {
  gameManager.UnloadContent();
  base.UnloadContent();
 }

 protected override void Update(GameTime gameTime)
 {
  if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed ||
   Keyboard.GetState().IsKeyDown(Keys.Escape))
  {
   Exit();
  }
  gameManager.Update(gameTime);
  base.Update(gameTime);
 }

 protected override void Draw(GameTime gameTime)
 {
  gameManager.Draw();
  base.Draw(gameTime);
 }
}

Download code sample here.

Summary
The revised Going Beyond example demonstrates how to isolate components using dependency injection:
Game components are able to be tested in isolation as dependencies can be replaced by mock objects.

The biggest drawback from the code sample above, however, is that all dependent components must be constructed manually in the factory before they can be injected.

Fortunately, there is a framework component available to developers that resolves this issue:
The IoC Container. This will be the topic in the next post.

XNA and Agile Software Development

noreply@blogger.com (SteveProXNA) — Tue, 01 Feb 2011 08:06:00 +0000

Agile development is a modern approach to software engineering that provides an iterative incremental framework for managing complex work. Efficiency is key: by minimizing rework and debugging, teams can more rapidly respond to changing business requirements and improve quality at the same time.

Game development, by nature, is complex and has many specialized disciplines:

Core Systems: engine configuration, math library, localization
Resources (Game Assets): audio, fonts, models, textures
Human Input Devices (HID): input detection
Collision & Physics: rigid bodies
Online Multiplayer: networking
Front End: heads-up display, in-game menus, visual effects
Game Play Foundations: event messaging, finite state machine
Game Specific Subsystems: rendering, player mechanics, cameras, AI

Therefore, each game may have many components working together and subsystems interacting with one another, many of which may depend on other components and subsystems too.

Consequently, the task of coding and testing game components in isolation can be very challenging due to the tightly coupled nature of these dependencies.

Example
Asteroids: in this simple game, the player controls a spaceship depending on input from the controller.
In order to test the spaceship's rotate and move methods in isolation, the external dependency on the controller must be broken.

Dependency Injection and Inversion of Control (IoC)
When an object instantiates another object that it depends on then this leads to poor design because it promotes tight coupling between the objects. Tightly coupled code cannot be changed easily without consequences: changes made to one object may cause other objects to break.

A better approach is to break dependencies between objects and promote loose coupling:
Loose coupling leads to better design as the software is less likely to break.

Dependency Injection is a simple pattern to loosely couple objects and break their dependencies.
The resulting design principle, Dependency Inversion, states: Depend upon abstractions.
Do not depend upon concrete classes.

By coupling an object to an interface instead of a specific concrete implementation, you have the ability to use any implementation with minimal change and risk. This concept is important, especially when testing an object in isolation (unit testing).

Inversion of Control (IoC) is a framework characteristic whereby objects, which depend on other objects, do not need to instantiate those objects; instead they get the objects they need from an external source.

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.

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

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:

Extreme Programming
Extreme Programming is a method of agile software development which advocates frequent releases with short development cycles. The focus on delivering business value within each iteration leads to increased quality and lower overall total cost.

Therefore, it seems only relevant to try and integrate agile methodologies into XNA game development. As an exercise, I would like to prototype the following agile techniques accordingly:

In conclusion, it will be interesting to see if agile development has the potential to scale using XNA!

Retrospective II

noreply@blogger.com (SteveProXNA) — Sat, 01 Jan 2011 09:13:00 +0000

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

2010 Achievements

Publish article on XNA and TAX
Receive recommendations on article
Receive ITIN from IRS
Extend knowledge of DirectX using PIX with XNA
Upgrade to XNA 4.0 and revise breaking changes
Receive Henway Xbox LIVE Indie Game payments
Receive Publisher Id from GeoTrust
Buy Windows Phone 7

Note: receiving an ITIN outside United States is an achievement!

2011 Objectives

Deliver game project for Windows Phone 7 and Xbox 360
Complete bank and tax information on the App Hub
Buy Xbox Kinect if / when APIs available
Integrate into game development:
- Test driven development
- Dependency injection
- An IoC Container
- Unit testing

In conclusion, 2010 was a turbulent year for independent game developers: November saw Indie Games hidden under the Specialty Shops as part of the Xbox dashboard update. Consequently, developers reported greatly diminished sales and prompted the campaign to Save XBLIG.

Fortunately, Microsoft restored Indie Games to the Game Marketplace by the end-of-the-month.

In fact, December saw the launch of the Indie Games Winter Uprising, in order to improve the quality of games on the channel. By the end-of-the-year, the Winter Uprising achieved a spotlight on the dashboard to further promote Indie Games on Xbox LIVE Marketplace.

Therefore, year 2011 has the potential to be another significant year for Indie Games.
One final goal, as always: write more game code, write lots more game code J

Show Developers the Money

noreply@blogger.com (SteveProXNA) — Sat, 25 Dec 2010 08:03:00 +0000

In late November 2010, approximately one month after the launch of the App Hub website, two major criticisms were reported by the developer community towards the Windows Phone Marketplace:

No App Hub store analytics
No payouts until Feb 2011

No App Hub store analytics
Initially, the App Hub did not provide developers with store analytics to indicate how many titles they had sold. One potential explanation for the missing functionality related to sales data in the App Hub was:
An intentional effort to avoid any leaks of hard data that may indicate poor sales of Windows Phones 7 devices.

Fortunately, store analytics are now available on the App Hub.
In fact, there are two main types of reports:

Graphical view of daily and cumulative downloads plus raw data break-downs
Payout Reports with aggregated and detailed views of Marketplace payouts

No payouts until Feb 2011
The App Hub supports quarterly payouts for all sales of Xbox LIVE Indie Games. The minimun threshold is $150: if this target is not reached within the quarter then all sales are rolled over into the next quarter.

The App Hub also supported quarterly payouts for all sales of Windows Phone apps upon launch in October 2010. The minimum threshold is $200, however. As Microsoft allows up-to-45 days to payout, this meant there would be no payouts until Feb 2011.

The announcement: no payouts until Feb 2011, prompted much concern from the developer community, categorizing: Windows Phone 7 development as a hobby or a learning experience rather than a source of revenue until the App Hub issues are sorted out.
Hardly the response Microsoft were targeting after spending $500m on the Windows Phone ad campaign!

Fortunately, there has been an update: the first payout will be in Jan 2011 for all sales of Windows Phone apps in Qtr-IV 2010. After Jan 2011, developer payouts will be processed on a monthly basis for all sales of Windows Phone apps that meet the minimum payout threshold limit.

Going forward, there is an opportunity to align monthly payouts for all sales of Xbox LIVE Indie Games. Another option would be to consolidate monthly sales figures for all platforms: if total sales accumulated across all platforms meet the minimum payout threshold limit then payment should be made.

Example
Developer has published two games: one on Windows Phone and one on Xbox LIVE Indie Games:

Monthly sales on WP7 Marketplace = $100
Monthly sales on Xbox Marketplace = $100

Currently, the developer would not be eligible for an end-of-period payout on either platform.
However, if there was an option to consolidate total sales then payment would be made.

In conclusion, the App Hub does have potential. In fact, Microsoft has announced over 15,000 developers have registered for Windows Phone development since the launch. There are also whispers that XNA will eventually provide Kinect API support in the future as well.

Therefore, there are encouraging signs that should hopefully increase the number of applications and the quality of games available for sale on the App Hub, which in turn, generate more revenue for developers.

XNA Creators Club now the App Hub

noreply@blogger.com (SteveProXNA) — Wed, 01 Dec 2010 08:47:00 +0000

In October 2010, Microsoft re-branded the XNA Creators Club website to the App Hub. The new website continues to support Xbox LIVE Indie Games as before, but now includes support for Windows Phone development.

All existing XNA Creators Club memberships have been migrated to App Hub annual subscriptions: they function as before however, independent game developers can now submit "apps", that is, apps and games to the App Hub for sale or free download in the Windows Phone Marketplace.

Therefore, the focus from Microsoft is now clearly on the Windows Phone.

All App Hub subscribers must activate their account and complete the following registration tasks:
Verify your email address
Subscribers new to the App Hub will need to register an account to verify email address. Existing XNA Creators Club members can simply verify email address from the My Apps page.

Publisher Identity Verification
Developers require a process to authenticate their identity. Identification validation is the process to ensure developers within the Windows Phone Marketplace are authentic. This protects from someone assuming their identity while also maintaining end-user trust.

Important: identity validation must be complete before developers can unlock Windows Phone devices, deploy apps to the phone, and submit to the App Hub for certification testing.

Microsoft partners with GeoTrust whom provide identity verification services. On Microsoft's behalf, GeoTrust will contact the developer during the identity validation process. Developers outside the U.S. are required to complete a GeoTrust form that includes a copy of government issued photo identification and the developer's signature. Once identity is confirmed, GeoTrust will issue a unique digital certificate; the App Hub uses the digital certificate to sign all applications published by the developer.

New subscribers to the App Hub should experience smooth transition here: after verifying email address, GeoTrust will contact the developer and begin the Publisher Identity Verification process.

However, existing XNA Creators Club members may find the Publisher Identity Verification process confusing and frustrating: after verifying email address, the App Hub displays the following message:
This message is misleading and incorrect: as existing XNA Creators Club memberships are migrated to App Hub subscriptions, no new details are sent to GeoTrust. Therefore, GeoTrust has no knowledge of existing members, thus no contact is made. Meanwhile, the developer will wait indefinitely for GeoTrust to contact them, as per the App Hub message!

Fortunately, there is a workaround this issue for existing XNA Creators Club members:

Create dummy app
Submit dummy app
Upload capabilities
Follow steps: description, artwork, pricing
Before submitting, uncheck the Automatically Publish to the Marketplace
This will ensure that the dummy app is not published!

Submitting a dummy app should initiate contact from GeoTrust. From there, GeoTrust will request documentation from the developer, as required, in order to complete Publisher Identity Verification.

Unlock your phone
Once publisher identity verification is complete, Windows Phone device(s) can be unlocked:

Download and install the latest Zune software
Connect Windows Phone to the computer
Launch Zune software and synch phone
Start Menu, Programs, Windows Phone Developer Tools, Registration
Enter Windows Live ID, password and click "Register"

Status: Your phone has successfully been registered.
Apps can now be deployed to Windows Phone.

Eligibility for Payout
While this step is not required to unlock the device, developers must provide bank and tax information
to ensure payment is made from the sales of apps on Windows Phone Marketplace.

Navigate to Payee Details. For all subscribers, the App Hub currently displays the following message:
New subscribers to the App Hub must submit the relevant Form W-8 tax form to Microsoft.
Pls read this post for more information.

However, existing XNA Creators Club members may find this message very confusing, especially if they have previously submitted Form W-8 and their Xbox LIVE business information status is as follows:
"W8 Form processed. Ready to be paid."

As of the time of this writing, Microsoft has issued the following statement:

I have confirmed with internal authorities that the commerce mechanisms are now integrated. You only need to set up the W8 once for your account, and then it will work for all the technologies supported in the App Hub.

Also, the bottom of the Payee Details page states:
This assumes the VAT identification number is optional. However, developers are currently unable to save their bank and tax information: when the VAT textbox is left blank, the following error is displayed:

Fortunately, Microsoft has acknowledged this issue and confirmed a fix in the next update release.

In conclusion, the App Hub launch has caused much confusion and frustration for developers:

apps cannot be deployed until Publisher Identity Verification is complete
tax status is inconsistent across Windows Phone and Xbox technologies
bank and tax information cannot currently be saved on the website

Note: to be correct, some developers have reported the ability to hack bogus VAT identification number in order to successfully save their bank and tax information, although this does not seem appropriate.

On a brighter note, there are encouraging signs for games on Windows Phone and paid games are a hit on the device: games occupy the Top 10 slots in the Windows Phone Marketplace; good news for independent game developers whom wish to publish on both Windows Phone and Xbox platforms.

Hopefully the App Hub experience will also improve once these issues have been resolved.

Back in Five Minutes

noreply@blogger.com (SteveProXNA) — Sat, 01 May 2010 15:06:00 +0000

XNA is an exciting technology that allows independent game code to be developed and deployed to Windows, Xbox 360, and Zune.

In 2009, I developed Henway using XNA. The game was approved and published on the Indie Games area of Xbox LIVE Marketplace.

I also setup this blog to highlight some of the issues encountered during XNA game development, potential solutions to these issues, and to provide a general discussion on XNA.

Here is a quick summary of some of the previous discussions on the site:

Design patterns: Abstract Factory, Command, State, Template Method
Performance monitoring and testing
TAX forms to submit to get paid
Henway game publication

XNA is currently at version 3.1, which includes extensions for the Zune HD device. However, version 4.0, scheduled for release later in 2010, will be compatible with Visual Studio 2010 and .NET Framework 4.0.

The big news from Microsoft however, is that XNA 4.0 will target the Windows Phone 7 mobile device: provide full 3D graphics support and tight integration with Xbox LIVE Marketplace.

Therefore, independent game code could now target the same marketplace on both a gaming console and mobile device within a single deployable code base. XNA 4.0 could create some very interesting opportunities, difficult to challenge by competitors in the gaming console and mobile device space.

In conclusion, I would like to take a break from regular monthly blog posts to get more info on XNA 4.0 and begin working on the next game project.

If I'm not back in five minutes, just wait longer J

XNA and TAX

noreply@blogger.com (SteveProXNA) — Thu, 01 Apr 2010 08:09:00 +0000

Once your game has been approved and published on Xbox LIVE Marketplace, it will be available for sale to all regions that can purchase Xbox LIVE Indie Games.

All download history and purchase information can be found in the My Business section of the XNA Creators Club web site. However, in order to get paid, you will need to submit your personal and tax information.

If you are an independent game developer and a non-U.S. based creator then the task of processing your personal and tax information can be very challenging. Therefore, this blog post attempts to shed some light on the process, and ensure payment is made from the sales of Xbox LIVE Indie Games.

Note: I am not a tax advisor; pls do not read the following as defacto or proven advice.

Process
In order to get paid, creators must enter their personal and banking information on the XNA Creators Club web site and submit the relevant Form W-8 tax form to Microsoft.

Note: there are four types of W-8 forms available on the Internal Revenue Service (IRS) web site;
Form W-8BEN is the most frequently submitted form: I will refer to this as Form W-8 from now on.

Independent game developers who are non-U.S. based creators, may be eligible for a reduction or exemption from U.S. income tax on their revenue, provided their country has a tax treaty with the U.S.
If this is the case, then you may be able to take advantage, providing you have a relevant Individual Taxpayer Identification Number (ITIN) and submit a properly completed treaty claim on Form W-8.

It appears this is the most difficult and confusing part of the tax process for independent game developers who are not based in the U.S.:

You must determine if your country has a tax treaty with the U.S., and
You must decide if you would like to take advantage of the tax treaty

Determine if your country has a tax treaty with the U.S.
Navigate to the United States Income Tax Treaties page on the IRS web site. If your country is listed then your country has a tax treaty with the U.S.

Decide if you would like to take advantage of the tax treaty
If your country has a tax treaty with the U.S. then you may like to take advantage in order to claim a reduction in U.S. income tax. Therefore, you must apply for an ITIN and submit a properly completed Form W-7 to the IRS.

Note: an ITIN is not strictly required to get paid, although without it you will be subject to an automatic 30% U.S. tax withholding, even if your country provides a lower rate of U.S. taxation.

Important: the process of applying for an ITIN alone can take weeks / months and it is easy for the ITIN application to be rejected by the IRS if Form W-7 is not completed perfectly.

To summarize, in order to get paid, you must complete the following tasks:

Enter your personal and banking information
Submit the relevant tax form(s)

Enter your personal and banking information

Login to the XNA Creators Club web site
Navigate to the My Business section
Click the link to Personal and Tax Information
Enter all relevant personal information
Enter all relevant banking information
Confirm

When you enter your personal information, you have the option to agree to the 30% U.S. tax withholding:
If your country does not have a tax treaty with the U.S., or you decide not to take advantage of the tax treaty, then leave U.S. Tax Identifier blank and check the box. If / when you have obtained an ITIN, you can enter this as the U.S. Tax Identifier and leave the box unchecked accordingly.

After entering your personal and banking details, a confirmation panel similar to the following will appear:
The panel states you will now need to submit a physical copy of your Form W-8 tax form to Microsoft.
The panel may also state which particular Form W-8 tax form you need to send, e.g. Form W-8BEN.

Submit the relevant tax form(s)
When you submit the relevant tax form(s), you have 3x options available:

Option
- Submit Form W-8 without ITIN
Option
- Submit Form W-7 to obtain ITIN
- Submit Form W-8 with ITIN
Option
- Submit Form W-8 without ITIN
- Submit Form W-7 to obtain ITIN
- Submit Form W-8 with ITIN

Submit Form W-8 without ITIN
Option 1: you cannot claim a tax treaty with the U.S or you choose not to take advantage of the tax treaty because the effort to obtain an ITIN is too time consuming, too difficult, or you cannot wait.

Complete Form W-8 as per the instructions. There is also an informative post on the XNA Creators Club web site:

Simply complete Part I, III and IV
Check 3. Type of beneficial owner as Individual
Leave 6. U.S. taxpayer identification number blank
Do not complete Part II as you are not claiming a tax treaty benefit

Send Form W-8 to:
Microsoft
Attn: Finance Department,
29011 Commerce Center Drive,
Valencia, CA 91355
USA

Submit Form W-7 to obtain ITIN / Submit Form W-8 with ITIN
Option 2: your country has a tax treaty with the U.S. and you would like to take advantage in order to claim a reduction in U.S. income tax.

Download and print the latest Form W-7. Follow the instructions carefully (recommended).
Remember: if Form W-7 is not completed perfectly then your ITIN application will be rejected by the IRS.

Form W-7
As an independent game developer, you will be claiming royalty income from Microsoft. Therefore, a good example on how to complete Form W-7 can be found on Pg. 27 of IRS Publication 1915:
When you check box (a). Nonresident alien required to obtain ITIN to claim tax treaty benefit with a foreign country, also check box (h). Enter "Exception 1(d) – Royalty Income" on the dotted line next to box (h). Also, enter treaty country, which is your country of residence, and treaty article number 12.

Note: to confirm the correct treaty article number:

Navigate to United States Income Tax Treaties
Click your country link e.g. Ireland
Click the Income Tax Treaty link
Search for "Royalties" in the Table of Articles; it should be Article 12

Important: Form W-7 line instructions state "Enter N/A (not applicable) on all lines that do not apply to you. Do not leave any lines blank". Also remember all dates must be month / day / year format.

Documentation: as Microsoft is the withholding agent, you will need to complete and attach the following letter. You will also need to send identification document(s). If you submit an original valid passport (or a notarized or certified copy of a valid passport), then you do not need to submit any other documents.

Send Form W-7, letter from Microsoft, and proof of identity to:
Internal Revenue Service
Austin Service Center
ITIN Operation
P.O.Box 149342
Austin, TX 78714-9342
USA

Once you obtain an ITIN, you can now complete Form W-8 as per option 1. However, this time enter your ITIN on line 6. U.S. taxpayer identification number and check box SSN or ITIN accordingly.

You must also complete Part II Claim of Tax Treaty Benefits: Check box (a). and enter your country on the dotted line. Also, check box (b) as the U.S. taxpayer identification number is stated on line 6.

Finally, on line 10. Special rates and conditions, there is an informative post on the XNA Creators Club web site (excerpt):
The beneficial owner is claiming the provisions of Article 12 of the treaty identified on line 9a above to claim a 0% rate of withholding on (specify type of income): Royalties. Explain the reason the beneficial owner meets the terms of the treaty article: I am a XXXX citizen and resident of XXXX receiving royalties from U.S. source.

Send Form W-8 to:
Microsoft
Attn: Finance Department,
29011 Commerce Center Drive,
Valencia, CA 91355
USA

Submit Form W-8 without ITIN / Submit Form W-7 to obtain ITIN / Submit Form W-8 with ITIN
Option 3: although you can claim a tax treaty benefit, you would like to get paid immediately: Submit Form W-8 without ITIN as per option 1. and ensure payment is made from the sales of Xbox LIVE Indie Games.

Next, submit Form W-7 to obtain ITIN as per option 2. While you ITIN application is being processed, or if your ITIN application is rejected and you need to start over, you will still continue to get paid regardless. When your ITIN is approved, submit Form W-8 with ITIN as per option 2.

Option 4
Finally, if you are new to XNA game development, there may be one other option worth considering: submit Form W-7 immediately. By the time your game is published you would (hopefully) have obtained the ITIN.

Therefore, you could enter your personal and banking information on the XNA Creators Club web site: Enter the ITIN as the U.S. Tax Identifier, leave the 30% U.S. tax withholding box unchecked, and submit Form W-8 with ITIN from the outset.

Remote Performance Monitor II

noreply@blogger.com (SteveProXNA) — Mon, 01 Mar 2010 09:49:00 +0000

In the previous post, we began a discussion on the XNA Framework Remote Performance Monitor. To recap, the Remote Performance Monitor exposes 2x common game code scenarios that unnecessarily generate garbage on the XNA platform:

Unnecessary string object creation
Unnecessary boxed value types

In the previous post, we discussed the first scenario: Unnecessary string object creation. Now, let's complete this discussion with the second scenario: Unnecessary boxed value types.

Unnecessary boxed value types
In a typical game, there are often enemies to kill, obstacles to avoid, gems to collect etc. Usually game code stores, for example, a list of enemy sprites to kill, in one collection variable:

IList<Sprite> Enemies { get; set; }

During game play, game code may need to iterate through the list of enemy sprites every single frame to invoke the Update() and/or Draw() methods accordingly. In .NET, iterating through an IList<T> can typically be done either using the for statement or the foreach.

Code Optimization Demos measure the performance of the for statement compared to the foreach: the for statement is generally more performant although the foreach statement provides better readability in code. However, if used incorrectly, the foreach statement can unnecessarily generate garbage, impact performance and potentially drop frames.

Let's check out an example using the foreach statement in more detail.
Consider the following Sprite class:

public class Sprite()
{
 public Sprite()  {}  // ctor.
 public void Update(GameTime gameTime) {}
 public void Draw(GameTime gameTime) {}
}

As above, game code may store, for example, a list of enemy sprites to kill, in one collection variable and construct the collection accordingly:

IList<Sprite> Enemies { get; set; }
Enemies = new List<Sprite>();

During game play, game code may iterate through the list of enemy sprites and update each sprite accordingly:

public void Update(GameTime gameTime)
{
 foreach (Sprite Enemy in Enemies)
 {
  Enemy.Update();
 }
}

The previous game code snippet may seem harmless enough, however, the Remote Performance Monitor reveals a single managed object allocated on the heap and a single value type is boxed every single frame. When game code executes this Update() method at 60fps then 60x value types are boxed every second:

What happened? Why is this simple game code snippet generating so much garbage?

The problem begins with our collection variable declaration: the collection is declared as an IList<T> but game code actually constructs a new List<T>.

IList<Sprite> Enemies { get; set; }
Enemies = new List<Sprite>();

The problem then manifests itself with the foreach statement: the foreach statement requires an enumerator to iterate through each enemy sprite in the list.

foreach (Sprite Enemy in Enemies)
{
 Enemy.Update();
}

In .NET, both List<T> and IList<T> implement the IEnumerable<T> interface. The IEnumerable<T> interface has one method: GetEnumerator(), which returns the enumerator required to iterate through each object in the list.

However, the implementation of the GetEnumerator() method differs between List<T> and IList<T>: List<T> GetEnumerator() method returns Enumerator<T>, which is a struct: a value type stored on the stack. Whereas IList<T> GetEnumerator() method returns IEnumerator<T>, which is an interface, a reference type stored on the heap.

Therefore the previous game code snippet initially returns an Enumerator<T>, as a value type for the List<T>, but then boxes the enumerator value type to a reference type because the collection is actually declared as an IList<T>!

Therefore, there are 2x potential solutions to resolve this issue with Unnecessary boxed value types:

Update the collection variable declaration to List<T>
Replace foreach with the for statement altogether

The first solution simply updates the collection variable declaration thus no boxing will be necessary:

List<Sprite> Enemies { get; set; }
Enemies = new List<Sprite>();

foreach (Sprite Enemy in Enemies)
{
 Enemy.Update();
}

The second solution simply replaces the foreach with the for statement thus no enumerator will be required:

IList<Sprite> Enemies { get; set; }
Enemies = new List<Sprite>();

for (Int32 index = 0; index < Enemies.Length; index++)
{
 Enemies[index].Update();
}

Either way, the results in the Remote Performance Monitor are the same:

To summarize, when using an object in which Enumerator<T> is a value type, like List<T>, game code can employ either the foreach or for statement and not generate garbage. When using an object in which IEnumerator<T> is a reference type, like IList<T>, the foreach statement may generate garbage whereas the for statement will not.

In conclusion, the XNA Framework Remote Performance Monitor a simple tool to detect if game code is generating garbage on the XNA platform. Typically, there are 3x static statistics that require the most attention during performance testing:

Managed String Objects Allocated
Managed Objects Allocated
Boxed Value Types

However, there is also one final statistic that is important to monitor: "Exceptions Thrown". In a perfect game, the "Delta" column in the Remote Performance Monitor will be zero at all times.

Remote Performance Monitor

noreply@blogger.com (SteveProXNA) — Mon, 01 Feb 2010 08:55:00 +0000

Performance is critical in game development. In XNA, game performance will degrade if you allow garbage to be generated during game play. On Xbox 360, generating too much garbage will force full garbage collection. If garbage collection takes longer than 1/60th of a second then the game will drop frames, and the more frequently full garbage collection occurs, the more frequently the game will drop frames.

The XNA Framework Remote Performance Monitor is a simple tool that can detect if game code is generating too much garbage. Here is a common work flow to game development and performance testing using the Remote Performance Monitor:

Write game code on Windows
Test game play on Windows
Deploy game code to Xbox 360
Launch Remote Performance Monitor
Start game from Remote Performance Monitor
Monitor performance results
Resolve performance issues as necessary
Repeat process

Here is a quick tutorial on how to use the XNA Framework Remote Performance Monitor if you have never used the tool before.

There is a large source of information available on the Internet, in the form of blog posts, audio casts, articles and white papers that gives detailed analysis on all the statistics generated from the Remote Performance Monitor; from Pinned Objects to Platform Invoke Calls.

However, in my experience, there are typically 3x statistics that require the most attention during performance testing:

Managed String Objects Allocated
Managed Objects Allocated
Boxed Value Types

Ideally, the goal is to have the "Delta" column in the Remote Performance Monitor for these 3x statistics consistently set to zero during game play:
This ensures game code does not unnecessarily generate garbage, force full collections and drop frames.

Unfortunately, during game development on the XNA platform, there appears to be 2x common game code scenarios that cause the "Delta" column in the Remote Performance Monitor to be consistently set to values greater than zero during game play:

Unnecessary string object creation
Unnecessary boxed value types

Each scenario reveals game code that consistently generates too much garbage, impacts performance and has the potential to drop frames.

Let's check out each scenario in greater detail:

Unnecessary String Object Creation
In a typical game, there is often a lot of numeric data that must be displayed on screen to the player, for example: score, hi score, level, lives, bonus etc. Consequently, there are numerous game code snippets similar to the following:

public void Draw()
{
 spriteBatch.DrawString(spriteFont, score.ToString(), position, color);
}

Each time game code executes score.ToString(), the .NET Framework will allocate a single managed string object on the heap. When game code executes score.ToString() unconditionally at 60fps then 60x additional managed string objects will be allocated accordingly every second:

However, there is no reason for game code to execute score.ToString() unconditionally every single frame.

A better approach would be to create 2x variables: one variable to store the integer score value and another variable to store the equivalent string representation of the score:

private Int32 scoreValue;
private String scoreText;

Now game code would only be required to execute score.ToString() when the score actually changed:

public void Update()
{
 if (playerKilledSomething)
 {
  scoreValue += 100;
  scoreText = scoreValue.ToString();
 }
}
public void Draw()
{
 spriteBatch.DrawString(spriteFont, scoreText, position, color);
}

During a standard frame, in which the score value will not change, the "Delta" column in the Remote Performance Monitor for Managed String Objects Allocated will now be set to zero as no garbage generation occurs:

This simple approach to avoid unnecessary string creation may seem obvious, but it is surprising how many times the following game code can be found in Production:

public void Draw()
{
 spriteBatch.DrawString(spriteFont1, score.ToString(), position1, color1);
 spriteBatch.DrawString(spriteFont2, hiScore.ToString(), position2, color2);
 spriteBatch.DrawString(spriteFont3, level.ToString(), position3, color3);
 spriteBatch.DrawString(spriteFont4, lives.ToString(), position4, color4);
 spriteBatch.DrawString(spriteFont5, bonus.ToString(), position5, color5);
 // continue draw method...
}

In the next post, we will continue this discussion on the Remote Performance Monitor with unnecessary boxed value types.

Retrospective

noreply@blogger.com (SteveProXNA) — Fri, 01 Jan 2010 08:53:00 +0000

Happy New Year! The company that I currently work for operates an agile software development process and employs SCRUM as an iterative incremental framework for managing complex work.

At the end of each Sprint cycle our team holds a Retrospective to:

make continuous improvements to the development process
reflect on the previous sprint
set goals for the next sprint

Therefore, I thought I would conduct a simple XNA retrospective for 2009 and set goals for 2010.

2009 Achievements

Complete XNA 2.0 book
Complete XNA 3.0 book
Buy Zune 2nd gen. 120 Gb
Buy Zune HD 32Gb Platinum
Upgrade XNA Game Studio 3.1 Zune Extensions
Give XNA presentation
Setup XNA blog with monthly posts
Publish Henway XBox LIVE Indie Game

Note: purchasing and configuring Zune device outside United States is an achievement!

2010 Objectives

XNA general development	XNA 3.1 development	ZUNE development
3D graphics Networking Unit tests Mocking Physics	Avatar personalization Xbox LIVE Party Video support	Accelerometer Touch panel 3D graphics

One final goal is to become more active in the XNA Creators Club: contribute more in the forums and participate more in the playtest and review process.

First Game Publication

noreply@blogger.com (SteveProXNA) — Fri, 25 Dec 2009 17:14:00 +0000

Season's Greetings! This year, I received a nice gift to complete 2009: the game I recently completed, Henway, was approved and published on the Indie Games area of Xbox LIVE Marketplace.

Henway: The goal is to cross the road without being killed; hence this game is based on real life.

During playtest and review, the feedback received on the XNA Creators Club was really positive and there were plenty of great ideas posted by fellow creators on the site.

Note: creators must have a Premium Membership before they can playtest and review Indie Games.

Here is a quick summary of features and updates that could potentially be added in a future release:

add more vehicles: trucks, buses, cyclists, motorcycles, tractors, emergency
add variety of squelching noises when the chicken gets run down
pause game when batteries removed from controller
use Xbox button images for quit and error popups
add exhaust particles for some of the vehicles
disable sign in guide when saving
disable the continue option

Template Method Design Pattern

noreply@blogger.com (SteveProXNA) — Tue, 15 Dec 2009 08:21:00 +0000

In XNA, the Update() and Draw() methods are invoked, by default, 60 frames per second. During each frame, a general algorithm for both the Update() and Draw() methods could be applied in game code as follows:

Update Algorithm	Draw Algorithm
update input update objects update HUD (heads up display)	draw background draw objects draw HUD (heads up display)

Here we have defined a template for both the Update() and Draw() methods. A template is a method that defines an algorithm as a set of steps. One or more of these steps can be implemented by the main game code, or deferred to a subclass where appropriate. This ensures that the structure of the algorithm stays the same, while subclasses can provide some part of the implementation as required.

By definition, the Template Method design pattern defines the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.

Let’s complete the discussion with a simple code sample.

First, create the skeleton of an algorithm for both the Update() and Draw() methods in the main game code:

// Template method for Update.
public void Update(Microsoft.Xna.Framework.GameTime gameTime)
{
 if (IsActive)
 {
  return;
 }

 UpdateInput(gameTime); 
 UpdateObjects(gameTime);
 UpdateHUD(gameTime);
}

// Template method for Draw.
public void Draw(Microsoft.Xna.Framework.GameTime gameTime)
{
 if (IsActive)
 {
  return;
 }

 DrawBackground(); 
 DrawObjects();
 DrawHUD();
}

Next, create the steps to be implemented by the template methods in the main game code:

public virtual void UpdateInput(GameTime gameTime) {}
public virtual void UpdateObjects(GameTime gameTime) {}
public virtual void UpdateHUD(GameTime gameTime) {}

public virtual void DrawBackground() {}
public virtual void DrawObjects() {}
public virtual void DrawHUD() {}

As this is a simple example, none of the steps will be deferred to subclasses; each step would execute the same game code each frame.

However, the Template Method can be used in conjunction with the State design pattern to redefine certain steps of the algorithm without changing the algorithm’s structure.

First, define an interface to be implemented by all game state objects. This interface contains all actions that each game state object will implement. In our example, the 2x actions Update() and Draw(), are now defined as template methods; this ensures that the structure of the Update() and Draw() algorithms stays the same while subclasses can provide some part of the implementation as required:

public class AbstractGameState
{   
 protected readonly Game game;   
  
 protected AbstractGameState(Game game)   
 {   
  this.game = game;   
 }   
 public void Update(GameTime gameTime)
 {
  if (IsActive)
  {
   return;
  }

 UpdateInput(gameTime); 
 UpdateObjects(gameTime);
 UpdateHUD(gameTime);
}

public void Draw(Microsoft.Xna.Framework.GameTime gameTime)
{
 if (IsActive)
 {
  return;
 }

 DrawBackground(); 
 DrawObjects();
 DrawHUD();
}

Next, construct one concrete implementation class for each state in the game. Each step in both the Update() and Draw() template methods can now be deferred to the concrete implementation class as required.

For example, imagine the Splash Screen game state concrete implementation class is responsible for detecting the Start button press and displaying the splash screen only:

public class SplashScreenState : AbstractGameState
{
 public override void UpdateInput(GameTime gameTime)
 {
  // Detect player press Start button.
 }

 public override void DrawHUD (GameTime gameTime)
 {
  // Draw splash screen
 }
}

Note: the remaining steps in both the Update() and Draw() template methods are invoked automatically by the algorithms contained in the base game state class.

To summarize, the Template Method design pattern offers algorithm encapsulation so that subclasses can hook themselves right into a computation anytime they want.

Command Design Pattern

noreply@blogger.com (SteveProXNA) — Tue, 01 Dec 2009 08:58:00 +0000

The Command design pattern encapsulates a command request as an object. In game code, an example of a command request could be a simple move command: e.g. move sprite left, right, up, down.

The Command design pattern is used to express a command request, including the method call and all of its required parameters, into a command object. The command object may then be executed immediately, queued for later use or reused to support undoable actions.

Note: the command object does not contain the functionality that is to be executed; only the information required to perform an action. The functionality is contained within a receiver object. This removes the direct link between the command object and the functionality to promote loose coupling. Finally, neither the command object nor the receiver is responsible for determining the execution of the command request; this is controlled using an invoker.

In our move sprite example above, the move command object encapsulates the method invocation to update the position of the sprite. The receiver object is the sprite itself. The invoker is input detection from the player’s controller to determine the execution of the move command request.

Initially, the thought of using the Command design pattern to move a sprite seems overkill. In game code, this can easily be accomplished using the following excerpt:

protected override void Update(Microsoft.Xna.Framework.GameTime gameTime)
{
 Single velocityX = GamePad.GetState(PlayerIndex.One).ThumbSticks.Left.X;
 Single velocityY = GamePad.GetState(PlayerIndex.One).ThumbSticks.Left.Y;
 if (velocityX == 0 && velocityY == 0)  
 {  
  return;  
 }  

 sprite.Velocity = new Vector2(velocityX, velocityY);
 sprite.Update();
}

However, by implementing the Command design pattern to move a sprite we are now able to record each move command, add to a list of move command objects, and persist to playback at a later time. This can be useful, for example, to implement a demo mode in a game. In fact, this is exactly how the game Henway employs a demo mode in the title screen. Let’s check it out:

First, define an interface to be implemented by each command object. Typically, this interface contains a single Execute() method but can be extended to support Undo() operations:

public interface ICommand
{
 void Execute();
}

Next, construct a concrete implementation class for each command object in the game. In our example there is simply one command object: MoveCommand.

public struct MoveCommand : ICommand
{
 private readonly Sprite sprite;
 private readonly Vector2 velocity;

 public MoveCommand(Sprite sprite, Vector2 velocity): this()
 {
  this.sprite = sprite;
  this.velocity = velocity;
 }

 public void Execute()
 {
  sprite.Velocity = velocity;
  sprite.Update();
 }
}

Next, construct a list of command objects. This list will record each command object as it’s created in game code and will be used to playback at a later time.

public IList<ICommand> CommandsSave { get; set; }

Note: you will also need to construct a list of integers that record the number of frames that elapse between each command object being recorded; this is required for playback mode.

public IList<Int32> CommandsDelta { get; set; }

Next, update the main game class Update() method: replace the simple sprite update above with game code that now:

constructs a new command object;
sets all required parameters;
executes the command;
records the command for later use;

protected override void Update(Microsoft.Xna.Framework.GameTime gameTime)
{
 updateFrame++;
   
 Single velocityX = GamePad.GetState(PlayerIndex.One).ThumbSticks.Left.X;
 Single velocityY = GamePad.GetState(PlayerIndex.One).ThumbSticks.Left.Y;
 if (velocityX == 0 && velocityY == 0)
 {
  return;
 }

 Vector2 velocity = new Vector2(velocityX, velocityY);
 ICommand command = new MoveCommand(sprite, velocity);
 command.Execute();

 CommandsSave.Add(command);
 CommandsDelta.Add(updateFrame);

 updateFrame = 0;
}

Finally, after all command objects have been recorded through the revised Update() method, the list of frame deltas and the list of command objects can be formatted and saved:

private void SaveCommands()
{
 for (Int32 index = 0; index < CommandsSave.Count; index++)
 {
  Int32 frame = CommandsDelta[index];

  MoveCommand command = CommandsSave[index];
  Single velocityX = ((MoveCommand)command).Velocity.X;
  Single velocityY = ((MoveCommand)command).Velocity.Y;

  String format = String.Format("{0},{1},{2}",
   frame,
   velocityX,
   velocityY,
   );

  // Persist command object data.
 }
}

Now the list of frame deltas and the list of command objects can be loaded at a later time, for example, during the title screen:

public ICommand[] Commands;
public Int32[] Frames;

private void LoadCommands()
{
 IList<String> lines = GetCommandData();

 Int32 maxCommand = lines.Count;
 Commands = new ICommand[maxCommand];
 Frames = new Int32[maxCommand];

 for (Int32 index = 0; index < maxCommand; index++)
 {
  String line = lines[index];
  String[] values = line.Split(new[] { ',' });

  Frames [index] = Convert.ToInt32(values[0]);

  Single velocityX = Convert.ToSingle(values[1]);
  Single velocityY = Convert.ToSingle(values[2]);
  Vector2 velocity = new Vector2(velocityX, velocityY);

  Commands[index] = new MoveCommand(sprite, velocity);
 } 
}

And the list of frame deltas and the list of command objects can be played back as a demo mode:

private Int32 frame = 0;
private Int32 index = 0;
private Int32 maxCommand = Commands.GetLength(0);

protected override void Update(Microsoft.Xna.Framework.GameTime gameTime)
{
 frame++;
 if (frame >= Frames[index])
 {
  frame = 0;
  Commands[index].Execute();

  index++;
  if (index >= maxCommand)
  {
   // All commands executed – stop playback.
  }
 }  
}

To summarize, the Command design pattern can be very useful in game development: by encapsulating method invocation, game code can crystallize pieces of computation so that the object invoking the computation doesn’t need to worry about how to do things; it just uses the crystallized method to get its work done.

State Design Pattern

noreply@blogger.com (SteveProXNA) — Sun, 01 Nov 2009 08:56:00 +0000

During its lifecycle, each game will transition through many states, for example: splash screen, title, introduction, menus, instructions, options, game play, level complete, death sequence, game over, hi scores etc

Consequently, there should be an easy mechanism to transition from one game state to another in game code. A typical approach is to construct a custom enum type in game code and set one entry for each game state:

public enum GameState
{
 SplashScreen,
 Title,
 Introduction,
 Menus,
 Instructions,
 Options,
 GamePlay,
 LevelComplete,
 DeathSequence,
 GameOver,
 HiScores
}

Therefore the game can execute state specific code depending on the current state of the custom enum type at each particular frame.

A simple example of this approach can be demonstrated in Microsoft's Mini Game Catapult. This game contains 6x states which are stored in a custom enum type, CatapultState, in game code:

public enum CatapultState 
{ 
    Rolling, 
    Firing, 
    Crash, 
    ProjectileFlying, 
    ProjectileHit,
    Reset
}

Unfortunately, the logic to execute state specific code in the Update() and Draw() methods is wrapped in a long if-elseif-else code block:

private CatapultState currentState;

if (currentState == CatapultState.Rolling)
{
}
else if (currentState == CatapultState.Firing)
{
}
else if (currentState == CatapultState.Crash)
{
}
else if (currentState == CatapultState.ProjectileFlying)
{
}
else if (currentState == CatapultState.ProjectileHit)
{
}
else if (currentState == CatapultState.Reset)
{
}

Game code that contains multiple if-elseif-else statements throughout the code base like this becomes cumbersome and error prone. Also, this approach does not scale: if 7x, 8x, 9x etc states were added to the game then this approach would become unwieldly and difficult to manage.

A cleaner approach would be to implement the State design pattern. The State design pattern allows an object, in this case our game, to alter its behavior when its internal state changes. The object will appear to change its class.

In the Catapult example, we would like to localize the behavior of each state into its own class.

First, define an interface to be implemented by all game state objects. This interface contains all actions that each game state object will implement. In our example there are 2x actions, Update() and Draw():

public abstract class AbstractGameState
{
 protected readonly Game game;

 protected AbstractGameState(Game game)
 {
  this.game = game;
 }
 public virtual void Update(Microsoft.Xna.Framework.GameTime gameTime)
 {
  // Update code common to every state.
 }
 public virtual void Draw(Microsoft.Xna.Framework.GameTime gameTime)
 {
  // Draw code common to every state.
 }
}

Next, construct one concrete implementation class for each state in the game. In our example there are 6x game state objects, thus one for each state:

public class RollingState : AbstractGameState
{
 // Rolling state specific code.
 public RollingState(Game game) : base(game) {}
 public override void Update(Microsoft.Xna.Framework.GameTime gameTime) {}
 public override void Draw(Microsoft.Xna.Framework.GameTime gameTime) {}
}
public class FiringState : AbstractGameState
{
 // Firing state specific code.
 public FiringState(Game game) : base(game) {}
 public override void Update(Microsoft.Xna.Framework.GameTime gameTime) {}
 public override void Draw(Microsoft.Xna.Framework.GameTime gameTime) {}
}
public class CrashState : AbstractGameState
{
 // Crash state specific code.
 public CrashState(Game game) : base(game) {}
 public override void Update(Microsoft.Xna.Framework.GameTime gameTime) {}
 public override void Draw(Microsoft.Xna.Framework.GameTime gameTime) {}
}
public class ProjectileFlyingState : AbstractGameState
{
 // ProjectileFlying state specific code.
 public ProjectileFlyingState(Game game) : base(game) {}
 public override void Update(Microsoft.Xna.Framework.GameTime gameTime) {}
 public override void Draw(Microsoft.Xna.Framework.GameTime gameTime) {}
}
public class ProjectileHitState : AbstractGameState
{
 // ProjectileHit state specific code.
 public ProjectileHitState(Game game) : base(game) {}
 public override void Update(Microsoft.Xna.Framework.GameTime gameTime) {}
 public override void Draw(Microsoft.Xna.Framework.GameTime gameTime) {}
}
public class ResetState : AbstractGameState
{
 // Reset state specific code.
 public ResetState(Game game) : base(game) {}
 public override void Update(Microsoft.Xna.Framework.GameTime gameTime) {}
 public override void Draw(Microsoft.Xna.Framework.GameTime gameTime) {}
}

Note: state specific code is now localized to each game state object instead of being embedded in a long if-elseif-else code block.

Next, we construct a custom enum type as before:

public enum CatapultState 
{ 
    Rolling, 
    Firing, 
    Crash, 
    ProjectileFlying, 
    ProjectileHit,
    Reset
}

But now we store a reference to the current game state in a private variable of this custom enum type in the main game class:

private CatapultState currentState;

Finallly, we create an array of AbstractGameState objects, instantiate one concrete implementation class for each state in the game and add to the array:

private AbstractGameState[] States;

protected override void Initialize()
{
 // Use reflection to determine how many states there are as
 // .NET Compact Framework does not support Enum.GetValues().
 Type type = typeof(CatapultState);
 FieldInfo[] info = type.GetFields(BindingFlags.Static | BindingFlags.Public);
 Int32 numberStates = info.Length;

 // Instantiate each game state.
 States = new AbstractGameState[numberStates];
 States[(Int32)CatapultState.Rolling] = new RollingState(this);
 States[(Int32)CatapultState.Firing] = new FiringState(this);
 States[(Int32)CatapultState.Crash] = new CrashState(this);
 States[(Int32)CatapultState.ProjectileFlying] = new ProjectileFlyingState(this);
 States[(Int32)CatapultState.ProjectileHit] = new ProjectileHitState(this);
 States[(Int32)CatapultState.Reset] = new ResetState(this);

 // Initialize current game state.
 currentState = CatapultState.Rolling;
 base.Initialize();
}

The States array will now be referenced in the main game class Update() and Draw() methods to delegate the corresponding action to the correct game state concrete implementation class:

protected override void Update(GameTime gameTime)
{
 States[(Int32)currentState].Update(gameTime);
 base.Update(gameTime);
}
protected override void Draw(GameTime gameTime)
{
 States[(Int32)currentState].Draw(gameTime);
 base.Draw(gameTime);
}

This solution is scalable: as more states are added to the game, each new game state can be added to the existing custom enum type, then simply add a new game state concrete implementation class to encapsulate all game code specific to that state.

One final note: the State design pattern can also be used in conjunction with the Device Factory. The main game class invokes the Update() and Draw() methods on the Device Factory as before:

// Game.cs
protected override void Update(Microsoft.Xna.Framework.GameTime gameTime)
{
 DeviceFactory.Update(gameTime);
 base.Update(gameTime);
}
protected override void Draw(Microsoft.Xna.Framework.GameTime gameTime)
{
 DeviceFactory.Draw(gameTime);
 base.Draw(gameTime);
}

However, each device factory method would now execute state specific code depending on the state of the game at that particular frame but now for the appropriate device:

// AbstractDeviceFactory.cs
public abstract class AbstractDeviceFactory
{
 protected readonly Game game;

 protected AbstractDeviceFactory(Game game)
 {
  this.game = game;
 }
 public virtual void Update(Microsoft.Xna.Framework.GameTime gameTime)
 {
  game.States[(Int32)game.CurrentState].Update(gameTime);
 }
 public virtual void Draw(Microsoft.Xna.Framework.GameTime gameTime)
 {
  game.States[(Int32)game.CurrentState].Draw(gameTime);
 }
}

Device Factory

noreply@blogger.com (SteveProXNA) — Thu, 01 Oct 2009 09:02:00 +0000

XNA 3.0 allows game development to target 3x independent devices: Windows, Xbox 360 and Zune. Consequently, Microsoft released the Platformer Starter Kit to demonstrate how a single game code base can be deployed and executed on these 3x devices independently.

The ability to target a single game code base to multiple devices creates some interesting challenges: there are elements of a game that are dependent on each target device, for example: screen resolution, input detection, frame rate, content, storage, trial mode, volume, etc.

The Platformer Starter Kit deploys the same game code on Windows and Xbox 360. However, all Zune specific game code is wrapped within the following #if-#else-#endif conditional statement:

#if ZUNE
 // Execute Zune device dependent code.
#else
 // Execute Windows / Xbox 360 code.
#endif

Game code that contains multiple #if-#else#endif conditional statements throughout the code base like this becomes cumbersome and error prone. Also, this approach does not scale: if 4x, 5x, 6x, etc devices were added to target the XNA platform, then this approach would become unwieldy and difficult to manage.

A cleaner solution would be to implement 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.

public abstract class AbstractDeviceFactory
{
 protected readonly Game game;

 protected AbstractDeviceFactory(Game game)
 {
  this.game = game;
 }
 public virtual void Initialize()
 {
  // Initialize code common to every device.
 }
 public virtual void LoadContent()
 {
  // LoadContent code common to every device.
 }
 public virtual void Update(Microsoft.Xna.Framework.GameTime gameTime)
 {
  // Update code common to every device.
 }
 public virtual void Draw(Microsoft.Xna.Framework.GameTime gameTime)
 {
  // Draw code common to every device.
 }

 // Properties common to every device.
}

In our example, there will be 3x device factory concrete implementation classes: Windows, Xbox 360 and Zune. Each concrete implementation class will contain all game code to target that specific device.

public class WorkDeviceFactory : AbstractDeviceFactory
{
 // Windows specific game code implementation.
 public WorkDeviceFactory(Game game) : base(game)
 {
 }

 // Override property and method implementations for Windows.
}
public class XboxDeviceFactory : AbstractDeviceFactory
{
 // Xbox 360 specific game code implementation.
 public XboxDeviceFactory(Game game) : base(game)
 {
 }

 // Override property and method implementations for Xbox 360.
}
public class ZuneDeviceFactory : AbstractDeviceFactory
{
 // Zune specific game code implementation.
 public ZuneDeviceFactory(Game game) : base(game)
 {
 }

 // Override property and method implementations for Zune.
}

The main game constructor is now responsible for creating the device factory concrete implementation for the device the game is deployed to, and this instance will be used throughout the game.

public class MyGame : Microsoft.Xna.Framework.Game
{
 public AbstractDeviceFactory DeviceFactory { get; set; }

 public MyGame()
 {
  DeviceFactory = CreateDeviceFactory();
 }

 private AbstractDeviceFactory CreateDeviceFactory()
 {
  AbstractDeviceFactory deviceFactory;
#if WINDOWS
  deviceFactory = new WorkDeviceFactory(this);
#elif XBOX
  deviceFactory = new XboxDeviceFactory(this);
#elif ZUNE
  deviceFactory = new ZuneDeviceFactory(this);
#else
  throw new NotSupportedException("Device not found");
#endif
  return deviceFactory;
 }
}

Note: there must be at least one #if-#else-#endif conditional statement to determine at runtime what device the game is being executed on.

The standard XNA methods in the main game class will be now very lean as each method will delegate the corresponding action to the device factory.

protected override void Initialize()
{
 DeviceFactory.Initialize();
 base.Initialize();
}
protected override void LoadContent()
{
 DeviceFactory.LoadContent();
 base.LoadContent();
}
protected override void Update(Microsoft.Xna.Framework.GameTime gameTime)
{
 DeviceFactory.Update(gameTime);
 base.Update(gameTime);
}
protected override void Draw(Microsoft.Xna.Framework.GameTime gameTime)
{
 DeviceFactory.Draw(gameTime);
 base.Draw(gameTime);
}

Each device factory concrete implementation will either execute device dependent game code, or simply invoke the base class where the game code is the same for all devices.

Finally, this solution is scalable: if another device is added to target the XNA platform then simply add a new device factory concrete implementation class that contains all game code specific to that device, and extend the CreateDeviceFactory() method in the main game class to target this new device.

First Game Completion

noreply@blogger.com (SteveProXNA) — Tue, 01 Sep 2009 17:35:00 +0000

Recently, I completed a basic 2D game to gain more experience in end-to-end game development on the XNA platform.The game, Henway, is basically a Frogger clone. The goal is to cross the road without being killed; hence this game is based on real life.

Henway is built using content that I purchased in 2003. The game play is simple; which was important in order to concentrate on the end-to-end game development experience in XNA.

The game took about four months to write outside work hours. A further month was spent upgrading game features to comply with XNA's best practices and publishing requirements.

The game is available on Windows, Xbox 360 and Zune.
Click here for more information on this title.

This blog will document some of the design and performance challenges encountered during development on the XNA platform, and game development in general. This information will be available in subsequent posts.

SteveProXNA Introduction

noreply@blogger.com (SteveProXNA) — Sat, 01 Aug 2009 14:55:00 +0000

Hi, I’m Steve @ StevePro Studios. SteveProXNA is my XNA creator name and Xbox gamer tag.

I've been following XNA since 2007. Recently, I completed a basic 2D game to gain more experience in end-to-end game development on the XNA platform.

This blog attempts to highlight some of the issues found during XNA game development, potential solutions to these issues, and provide a general discussion on XNA.