So today was Academic Day, in particular, for faculty members, who had been invited to hear about what students want, directly from students. (That was the theme)

A couple of weeks previously, Andrew Parsons (@MrAndyPuppy), the local Academic Developer Evangelist asked me to do a presentation on Windows Phone 7, with a split between the experience promised by Microsoft, and developing for the phone. After I learned that I really cannot do a reasonable phone demo in 10 minutes, I cut it down to a demo of pre-made code.

Either way, some big highlights arose today. I managed to get Andy to let me see and use a developer phone, and I must say, awesome, however I cannot go into specifics, nor can I take photos unfortunately.

The other highlight was the awesome keynote presented by Michael Kordahi (@delic8genius) with a special appearance by August De Los Reyos (@augustdlr) presenting his experiences developing User experiences on the Surface, and even the Windows key on the keyboard. Some awesome demos for a theoretical Foxtel experience (Cable TV in Australia) that uses all devices, including a Surface table (jeez they love that thing). They then showed off the big devices for this year, Kinect and Windows Phone 7, and seeing this in person was really awesome. I cannot wait for next week when I will get to try out a device. (Unfortunately they took the device back to Sydney right after the keynote.)

Photos will follow as I can sort them out, and maybe videos depending on what I’m allowed to post, and what connection I can get.

Exciting days remain ahead, I have to present Windows Phone 7 to students on Thursday, and of course I must experience the great TechEd sessions.

I suggest you have a read through it if you are interested in the kinds of things I post on this blog, especially the Light Pre Pass technique.

One of the key parts of Shawn’s article are the changes that will be made to Render Targets, and the bucketing of the RenderTarget/Texture formats into the Reach and HiDef profiles.

It would be safe to say that future articles here will require the HiDef feature set. I make use of some of the Render Targets that do not exist in Reach, and while there may be a way to use a Reach Render Target, for the purposes of conveying the technique, I will not be adding extra code to support it. I may however note where alternatives can be used, and hint or mention how to use them.

I know I have previously used BGRA formats in my sample, and in future this will become RGBA, no big deal. I won’t change the 3.1 sample for now, but if I need to change other things to upgrade it to 4.0, then that will be “fixed”.

This shouldn’t be much of a problem, if you are going to be using the articles I plan to write, then you’ll have a computer that works with HiDef, or an XBOX.

As a side note, I no longer have a valid Creators Club subscription, so I have not tested the recent Light Pre-Pass article on the XBOX. If anyone has any issues let me know and I will try and look into it. I plan to get a premium subscription soon and test future articles on the XBOX.

For any readers who are in Sydney, this would be a great event to attend. E&D covers everything from the XBOX to the Surface, even Keyboards + Mice from MS hardware.

Hopefully there will be a Natal unit on display, and maybe a demo, although no confirmation yet.

RSVP by emailing kumarman[at]microsoft.com

This time around I will cover Point, Ambient and Directional lights in the same post, as well as including information about an alternate light buffer format that allows for improved specular + per-material specular.

Expect this either during the weekend of 20-21st Dec, or shortly after that.

Unfortunately I could not test the code on the XBOX the first time around due to subscription issues, however everything is fine now, and I can and will test on both XBOX and my desktop PC beforehand. (Perhaps also other PC configs depending on who I can find online at the time, and what other machines I have on hand )

In this part I will cover how to implement the basic form of the Light Pre Pass renderer, with support for point lights, and the basic Blinn-Phong shader, including Albedo texture support.

As this article is fairly advanced in nature, I have to make certain assumptions about my audience, so that I do not spend half my time explaining basics. Firstly, you should have an understanding of basic concepts such as Cameras, Fullscreen Quads (including how to render one) and rendering a mesh with custom effects.

This pretty much means that as long as you have done some 3D work before, you should be fine. It would be best if you also knew XNA, as I will be using that to write this implementation, however as long as you can translate from C# and get the basic idea, that should be enough.

As you can see from these requirements, this article is not aimed at beginners, and if you are looking for tutorials on how to get started with XNA for 3D development, I would recommend you visit some great sites such as:

• http://creators.xna.com
• http://www.thehazymind.com
• http://xna-uk.net/blogs/randomchaos/

Those sites will help you get started with XNA, and once you are familiar and comfortable with the concepts behind 3D graphics, you can return here to learn an advanced renderer implementation.

My focus in this article will be on the implementation of the renderer, as a result, I will not be referring to the implementation of cameras or scene graphs.

Now that the housekeeping is out of the way, we can begin.

The Renderer in C#

Light Pre Pass (LPP), or Deferred Lighting, operates in 3 stages.

1. Depth + Normals Rendering
2. Light Rendering
3. Materials Rendering

These 3 stages accumulate information into render targets, which are used by the next stage, until the Materials stage produces the final image. So the first thing we must do, is set up at least the following Render Targets:

• Depth (SurfaceFormat.Single)
• Normals (SurfaceFormat.Bgra1010102)
• Lights (SurfaceFormat.Color)

depth = new RenderTarget2D(gfx, width, height, 1, SurfaceFormat.Single, RenderTargetUsage.DiscardContents);
normals = new RenderTarget2D(gfx, width, height, 1, SurfaceFormat.Bgra1010102, RenderTargetUsage.DiscardContents);
light = new RenderTarget2D(gfx, width, height, 1, SurfaceFormat.Color, RenderTargetUsage.DiscardContents);
final = new RenderTarget2D(gfx, width, height, 1, SurfaceFormat.Color, RenderTargetUsage.DiscardContents);

We use Bgra1010102 for storage of normals because we want maximum precision for the 3 channels we are using. The closest format that provides 32bits of depth and 3 channels is 1010102, where there are 10 bits for the 3 channels we care about, giving greater precision over the 8 bits in a normal A8R8G8B8 (or Color) surface format.

The Materials, or final pass can be rendered directly to the Backbuffer, or to a Render Target, this depends on your needs, and is completely up to you. I have provided suggested SurfaceFormats above, however you can feel free to use your own, however note that the shaders I provide may not work [correctly] with your chosen format.

Depth + Normals

The first stage of the renderer, requires you to render the Depth and Normal values for each pixel to the screen. You can optionally render the position directly, however many post processing techniques use depth information, so why not render it now to re-use later.

First we must setup the render targets on our device, easily done with two lines of code:

gfx.SetRenderTarget(0, depth);
gfx.SetRenderTarget(1, normals);

For those who have not worked with multiple render targets before, the number in the above code indicates the render target index, and allows you to un-set and resolve the render target later.

Now you must first clear the render targets. As we are using multiple render targets, a simple call to GraphicsDevice.Clear will not suffice, instead we simply render a fullscreen quad using a cheap shader to write out the clear colours to the render targets.

struct VS_OUT
{
    float4 Position        : POSITION;
};

VS_OUT vs_main(float3 position : POSITION)
{
    VS_OUT output = (VS_OUT)0;
    output.Position = float4(position, 1);

    return output;
}

struct PS_OUT
{
    float4 Depth : COLOR0;
    float4 Normals : COLOR1;
};

PS_OUT ps_main()
{
    PS_OUT output = (PS_OUT)0;

    output.Depth = 1.0f;

    output.Normals = float4(0, 0, 0, 1);

    return output;
}

Next you render the objects, using a special shader that writes the Depth and Normals to the two render targets. If you intend to implement Normal Mapping, or a similar technique, this is where you would calculate and combine the Normals. For the purposes of this article, only the basic per-vertex normals will be stored here.

One thing I had to do, was ensure a couple of render states were set correctly, specifically DepthBufferEnable and DepthBufferWriteEnable. Ensure both of these are set to true before continuing.

The Depth and Normals shader is quite simple. First the object is transformed as it would normally be when rendering, and then the Z and W values from the transformed position are passed to the pixel shader, alongside the Normal.

struct VS_IN
{
    float4 Position   : POSITION;
    float4 Normal     : NORMAL0;
};

struct VS_OUT
{
    float4 Position   : POSITION;
    float4 Depth      : TEXCOORD0;
    float4 Normal     : TEXCOORD1;
};

VS_OUT depthNorm_VS(VS_IN input)
{
    VS_OUT output = (VS_OUT)0;

    float4x4 wvp = mul(World, ViewProjection);

    output.Position = mul(input.Position, wvp);

    output.Depth.xy = output.Position.zw;

    output.Normal = mul(World, input.Normal);

    return output;
}

If you look at your render targets, you may see a white image for the depth buffer, this is normal, as the differences in depth between most points on an object are miniscule, and close to 1. Your normals buffer however should look something like this:

Inside the pixel shader, the Z value is divided by the W value to get the depth, and that is written to the first render target. Then the Normal is normalised and shifted from a range of [-1, 1] to [0, 1].

struct PS_OUT
{
    float4 Depth : COLOR0;
    float4 Normals : COLOR1;
};

PS_OUT depthNorm_PS(float4 depth : TEXCOORD0, float4 normal : TEXCOORD1)
{
    PS_OUT output = (PS_OUT)0;

    output.Depth = depth.x / depth.y;

    output.Normals.rgb = 0.5f * (normalize(normal) + 1.0f);

    // Set alpha for both Depth and Normals to 1 (for some reason its required)
    output.Depth.a = 1.0f;
    output.Normals.a = 1.0f;

    return output;
}

Now that we have our Depth and Normal values stored in the render targets, we can resolve and get their respective textures so that the lights can be rendered using this data. This is quite simple in XNA, just set the render targets on the graphics device to either another render target, or null. In this case, we can set RT0 to the light buffer, and set RT1 to null.

gfx.SetRenderTarget(0, light);
gfx.SetRenderTarget(1, null);
depthImage = depth.GetTexture();
normImage = normals.GetTexture();

Be sure to clear the light buffer to TransparentBlack, and then we can move on to rendering the lights.

In this first tutorial, I will implement point lights only. Check back for future tutorials about implementing other types of lights, like Directional Lights, etc.

Rendering the light stage is a little bit more complicated than the Depth + Normals stage. This time around, a number of Render States must be set in the beginning, and even more for each light based on the position of the camera.

Render States

The following render states must be set when drawing the lights, to take advantage of alpha blending for blending multiple overlapping lights.

gfx.RenderState.AlphaBlendEnable = true;
gfx.RenderState.SeparateAlphaBlendEnabled = false;
gfx.RenderState.AlphaBlendOperation = BlendFunction.Add;
gfx.RenderState.SourceBlend = Blend.One;
gfx.RenderState.DestinationBlend = Blend.One;
gfx.RenderState.DepthBufferEnable = false;
gfx.RenderState.DepthBufferWriteEnable = false;

Here we are disabling the Z-culling feature of the graphics card so that overlapping lights can be drawn, as well as enabling Alpha Blending over all channels of the render target so that the process of combining overlapping lights will be handled by hardware automatically. We also ensure that no modifications to the destination or source values are made during the blending stage, and that Additive blending is used. (Remember that lighting equations add multiple lights together)

Now you run through each light and set the CullMode render state based on where the camera frustum is located. If the frustum is inside or overlaps the light bounding volume (in this case a sphere), the CullMode needs to be set to CullClockwiseFace. CullCounterClockwiseFace should be set if the frustum is completely outside the light bounding volume. Remember to also ensure that the CullMode is set to CullCounterClockwiseFace after all of the lights have been rendered.

In the sample code, I use a Mesh to easily load and store the light volume, which for a Point Light, would be a sphere. A scaling matrix allows for the attenuation to be changed, so be sure to update any matrices as needed.

Some notes about the next code sample:

• cmanager is my CameraManager, it is used here to set the ViewProjection and InverseViewProjection matrices, which are required to transform the Depth back into a position for lighting.
• caller is the Renderer class, which coordinates rendering each stage, as well as setting up and resolving the appropriate buffers.

public void DrawLightDeferred(GraphicsDevice gfx, CameraManager cmanager, Renderer caller)
{
    shader.Begin();

    // Set Matrix params
    cmanager.ApplyCameraParameters(ref shader);
    shader.Parameters.GetParameterBySemantic("WORLD").SetValue(world);

    // Set Depth and Normals buffers
    shader.Parameters["Depth_Tex"].SetValue(caller.GetDepthImage());
    shader.Parameters["Normals_Tex"].SetValue(caller.GetNormalsImage());

    // Set lighting params
    shader.Parameters["LightPos"].SetValue(_pos);
    shader.Parameters["Attenuation"].SetValue(_attenuation);
    shader.Parameters["SpecPower"].SetValue(SpecularPower);
    shader.Parameters["LightColor"].SetValue(LightColor.ToVector4());

    for (int j = 0; j < lightMesh.Meshes.Count; j++)
    {
        gfx.Indices = lightMesh.Meshes[j].IndexBuffer;

        for (int k = 0; k < lightMesh.Meshes[j].MeshParts.Count; k++)
        {
            for (int i = 0; i < shader.CurrentTechnique.Passes.Count; i++)
            {
                EffectPass pass = shader.CurrentTechnique.Passes[i];
                pass.Begin();

                gfx.VertexDeclaration = lightMesh.Meshes[j].MeshParts[k].VertexDeclaration;

                gfx.Vertices[0].SetSource(lightMesh.Meshes[j].VertexBuffer,
                    lightMesh.Meshes[j].MeshParts[k].StreamOffset,
                    lightMesh.Meshes[j].MeshParts[k].VertexStride);

                gfx.DrawIndexedPrimitives(PrimitiveType.TriangleList,
                    lightMesh.Meshes[j].MeshParts[k].BaseVertex,
                    lightMesh.Meshes[j].MeshParts[k].StartIndex,
                    lightMesh.Meshes[j].MeshParts[k].NumVertices,
                    lightMesh.Meshes[j].MeshParts[k].StartIndex,
                    lightMesh.Meshes[j].MeshParts[k].PrimitiveCount);

                pass.End();
            }
        }
    }
    shader.End();
}

Now I need to run through some helper methods I use in the upcoming point light shader. These methods handle transforming a position from Post Projection space, to Screen space, as well as calculating the half pixel offset required by DX9.

float2 postProjToScreen(float4 position)
{
    float2 screenPos = position.xy / position.w;
    return (0.5f * (float2(screenPos.x, -screenPos.y) + 1));
}

float2 halfPixel()
{
    return -(0.5f / float2(fViewportWidth, fViewportHeight));
}

These are simple enough, and more importantly, *just work*.

Now for the point light shader. Here the light volume is transformed as needed in a really simple vertex shader:

struct VS_OUT
{
    float4 Position            : POSITION;
    float4 LightPosition    : TEXCOORD0;
};

VS_OUT vs_main(float4 inPos : POSITION)
{
    VS_OUT output = (VS_OUT)0;

    float4x4 wvp = mul(World, ViewProjection);

    output.Position = mul(inPos, wvp);
    output.LightPosition = output.Position;

    return output;
}

The following variables are also passed to the shader for lighting calculations:

float3 LightPos;
float Attenuation;
float SpecPower;
float4 LightColor;
float3 CamPos : VIEWPOSITION;
float3 EyeDepthRay;

The key code comes in the pixel shader. The first thing needed is to transform the position of the pixel from post projection space to screen space. This is handled by the helper method I mentioned earlier. Then the half pixel offset is deducted from the screen space position, so that the values read from the Depth and Normal buffers are correct.

// Transform from post-projection to texcoords
float2 screenPos = postProjToScreen(projPos);
// DX9 half pixel offset
float2 texCoord = screenPos - halfPixel();

float depth = tex2D(depthSampler, texCoord);

Next, read the depth from the Depth buffer, and if the value is not less than 1, we simply write a value of 0 for this pixel, as there is no depth information at that point, and nothing to light. If there is however, the lighting can be calculated for that point.

// Reconstruct position from screen space + depth
float4 position;
position.x = texCoord.x * 2 - 1;
position.y = (1 - texCoord.y) * 2 - 1;
position.z = depth;
position.w = 1.0f;
position = mul(position, InvViewProjection);
position.xyz /= position.w;

For more information on how to reconstruct a position based on a depth value, read this. There are also alternative, and improved methods listed there, which can be used depending on your needs.

Next the normal is acquired from the normal buffer, and restored to the [-1, 1] range so that it can be correctly used in the lighting calculations.

// Restore Normal
float3 normal = tex2D(normSampler, texCoord);
normal = normalize(2.0f * normal - 1.0f);

Now the lighting can begin. There are two key elements that need to be calculated for our light buffer: N.L and Attenuation. N.L is the basic element in every lighting equation, and simply consists of the dot product between the Normal and the Light Direction.

Attenuation is calculated by simply determining the ratio of distance to light over maximum attenuation, this is then flipped so that 0 is the furthest point from the light. Here I also pre-combine the attenuation and the N.L value. You can of course combine these later when writing out the buffer, ultimately it gives the same result.

// Attenuation Calcs
float3 lDir = LightPos - position;
float atten = saturate(1 - dot(lDir/Attenuation, lDir/Attenuation));
lDir = normalize(lDir);

// N.L
float nl = dot(normal, lDir) * atten;

Next we calculate the specular value. As we are using the Blinn-Phong lighting equation later on, the Half Vector is used instead of the reflection Vector, which ends up being a cheaper calculation for us. (Negligible for most modern systems – but visual difference is imperceptible)

For the purposes of this article, I will only include the code from the Blinn-Phong variant, however in the downloadable sample, I provide both methods that can be toggled with a boolean. (Change the technique to change the method)

Remember that this only affects the specular value, so do not worry that this will restrict you to the Blinn-Phong (or just Phong) lighting model.

float3 halfDir = normalize(lDir + camDir);
spec = pow(saturate(dot(normal, halfDir)), SpecPower);

Finally we generate the buffer and this is where we combine the light colour with the calculated N.L and Attenuation values.

return float4(LightColor.r, LightColor.g, LightColor.b, spec) * nl;

You should get something that looks like this: (Note that due to transparency this may look weird, however the essential part to note is the lights making up the shape of the model)

Now we are entering the home stretch. All that is left to render now is the materials for each object. This is simply a matter of rendering each object again, and using the Light buffer to shade the object. Here is also where the material-flexibility of LPP comes into play, as each object uses its own shader.

To prepare for this stage, simple resolve the light buffer by setting either the backbuffer (null) or a “Final Image” render target as RT0. Then you can get the light texture, and provide it so the objects can use it when rendering.

This is the pixel shader:

float2 scrCoord = postProjToScreen(input.ScrCoord) - halfPixel();

float4 light = tex2D(lightSampler, scrCoord);

float3 texCol = tex2D(texSampler, input.TexCoord);

float3 lighting = saturate(AmbientLight + (light.rgb * texCol) + light.aaa);

return float4(lighting, 1);

Here I adjust by the half pixel offset and transform from post projection to screen space inside the vertex shader, so those calculations are as before, however I pass the corrected Texture Coordinate to the pixel shader.

As this material is a Blinn-Phong material, it is a rather simple equation. The “Sum of light colour multiplied by N.L and attenuation” is handled by the Alpha Blending and light shaders, so that simply needs to be multiplied by the texture (Albedo) colour, which is then added to the ambient light term and specular term to complete the lighting equation.

Finally this is done, you now have either a backbuffer, or render target filled with a lit scene.

There are many other materials which can be adapted to use the light buffer, and there is also a modification that can be done to the light buffer and final material shaders to allow for a material specular value, however I will leave those to future articles.

I hope this has been informative, and if you have any questions, please post them in the comments. Also be sure to check back for new tutorials covering different light types, materials, and other additions. I hope to get shadows implemented into the system, and also outline combining this with a forward renderer to allow for transparent objects and particles.

The screenshots in this post use 1000 point lights arranged in a 10x10x10 cube around the model.

We are considering bringing this to PC, there are some things that need to be done before that can happen, but if DapydTheBard is willing it will probably happen.

You can get to the peer review page using this link: http://catalog.xna.com/en-GB/GameDetails.aspx?catalogEntryId=7432580d-50e3-439e-b180-f1ca39df65a3&type=1

Hope you enjoy the game, and let us know what you think on the DOG blog.

Edit: Seems it failed due to a MU issue that should be fixed soon. The DOG blog and other places will have further info when the game goes back into peer review.

Hope you enjoy it!

You can find out more about Nebulon here. We hope to have a game website up shortly with screenshots, videos, and information on both the PC and XBOX 360 versions.

Platform

(This review is based on a release copy of the game graciously provided by MGS)

Halo Wars is the final game to emerge from the venerable Ensemble Studios (Age of Empires series), and the first title from Ensemble to be exclusive to the Xbox 360 console. The game will be released in PAL territories on the 26th February 2009, and in North America on the 3rd March 2009. The title is available in Standard and Limited editions, with the limited edition contained in a plastic covering that holds a Steelbook case for the game, and an extras package for the bonus items, just like Halo 3.

The limited edition contains a code for a Honour Guard Wraith vehicle that can be redeemed on Xbox Live, and a code to download the upcoming Mythic Map pack for Halo 3. It also contains a rubber patch from the Spirit of Fire (the UNSC ship in the game), 6 leader cards that describe the leader powers, and a graphic novel set in the Halo universe.

Gameplay

If you believed that Halo Wars is simply Halo 3 scaled up, you would be right. The gameplay has the feel of its FPS cousin, and the game manages to maintain that feel in the writing, and even in the menus. However the RTS base of the game still shows, for example when air units sit in place to attack a building. Unit feel and movement was obviously emphasised in the game, Warthogs will fishtail, bounce around when they land, and get knocked about when they ram through a group of enemies.

The unit selection is rather extensive,from units you know and love, like the Warthog and Grunts, to some craft previously unseen in Halo games, like the Vulture super unit, which is great for unleashing devastating barrage attacks on the enemy base. Covenant bring the old favourites like the Elites, Jackals and Hunters to the party, and you gain a feeling of satisfaction when you unleash a couple of Scarab super-units on the enemy, knowing what they were like in Halo 3.

The two sides really differ when it comes to leader powers. The UNSC uses a special attack menu which is called up by pressing Up on the D-Pad. The power you have, depends on the leader chosen at the start of the match. However unlike the UNSC, who does not have any units to represent their leaders in skirmish/multiplayer, the Covenant leader is actually a controllable unit on the battlefield. The covenant deploy their leader abilities through the use of the Special Attack that each unit has. Whilst the UNSC can use their powers in any visible area, the Covenant leader must be within range to use its ability. However the Covenant also gain the ability to teleport other units to the leader’s position, creating a great way to reinforce an attack on the enemy.

The “console simplification” can really be seen in the base building mechanic where all buildings are constructed in fixed locations around a central base, (Firebase for the UNSC, Citadel for the Covenant) and supplies (the resource for the game) are collected over time by a specific type of building. Most maps have at least 4 base locations, with the empty ones being held by an AI party that you simply need to crush to gain control of the position.

The control scheme works very nicely with the Xbox 360 controller, however the lack of control groups and more advanced controls will be an issue for those coming from the PC and wanting to try out Ensemble’s final offering on consoles.

Movement is handled with the Left Thumbstick, and camera rotation and zooming is handled with the Right Thumbstick. The ability to select all units, or just all units on screen, as well as being able to cycle through the unit types selected using the Right Trigger will certainly help those who are willing to learn the controls. Moving around the map can be sped up by using the Left Trigger, and without this, the movement controls simply wouldn’t work.

However this console simplification has really worked for Halo Wars. Whilst the game would most likely fail if it appeared in this state on the PC, the game controls, and mechanics work quite well for console, enough to make Halo Wars one of, if not the best RTS games on consoles to date.

Difficulty in the single player campaign ramps up pretty fast, with the jump from Normal to Heroic being much harder than the jump from Easy to Normal. Certain campaign missions also cause a spike in difficulty. You could be progressing nicely through the campaign, and then get stuck for a long time on one mission due to what look like overwhelming odds. One mission has you defending civilian transports for 20 minutes whilst the Covenant mount a full scale attack on you, your Spartan allies, and the Civilians. Combined with the love that AI Spartans have for hijacking vehicles, this can quickly become a painful mission where surviving  through to the end is difficult; especially when the enemy has their full tech tree, and you are limited to just over 1/2 your units.  This can ruin the fun of the game, especially when a reasonably early mission causes a great amount of frustration.

Skirmish has the player fighting alongside AI teammates, or alone, against one or multiple AI foes. The skirmish AI can be challenging, however they are not very “smart”. It is quite possible to take over a base right next to their own, and they will continue to try to send forces to your main base. Recreations of famous maps like Blood Gulch will surely bring fond memories for fans of the previous Halo games, and being able to fight those same battles on a much larger scale is certainly enjoyable. Halo Wars ships with a good number of maps that range from 1v1 to 3v3, and span all of the locale types in the game. More than enough to keep you playing for a while.

Graphics & Audio

Being a console RTS, Halo Wars certainly does not have the detail of Empire Total War, however the game does have a reasonably high quality for its class. Animations are the key point here, with the quality level being close to, if not the same as Halo 3 (I wouldn’t be surprised if the animations were given to Ensemble by Bungie).

Textures are at a pretty good resolution, and the particle effects really add to the scene, and the feeling that this is a Halo game however the game does occasionally slow down at 1080p, although this is very rare and usually only during heavy action.

Halo Wars simply has to be played in High Definition to look good, and due to the detail required and information on screen, players need the extra space afforded by a minimum resolution of 720p to really experience the game.

The pre-rendered cut scenes which break each mission were created by the CG studio Blur and as usual are top notch. The colours in many missions are bright and lush, which looks great as a backdrop to the destruction that is about to occur. However in keeping with the Halo universe, many locales are dull, and Ensemble has put a lot of effort into ensuring that the game looks great in any environment.

The audio in the game is very similar to Halo 3, with many sounds most likely brought over from the FPS title. You cannot fault Halo Wars on the audio, the engine appears to be able to handle the many diverse sounds on screen at once, and the score by Stephen Rippy manages to keep the Halo musical theme alive throughout the game.

Overall

At the end of the day, Halo Wars does not manage to do what Halo did for FPS on the console. If Halo Wars was a PC game, it would be lacking immensely, however for the needs of consoles, the game is executed extremely well. The controls are well designed for the Xbox 360 controller, and this is crucial for the gameplay of an RTS on a console. Difficulty spikes are an issue, and it is never fun repeating the same mission over and over again, especially one running on a timer.

Whilst I am certain that most Ensemble fans would have preferred a PC RTS for their final game, it is nice to see one of the best do justice to a Halo RTS. This is a solid effort by Ensemble to bring RTS to the consoles, and it is certainly above par when compared to other games in the same class. A very fun game to play, and an awesome way to experience the Halo universe. The addition of a timeline will certainly be loved by the Halo universe fans, and provides an easy way for new players to learn about the back story behind the war, as well as the major events leading up until the events on earth in Halo 3.

I did not get a chance to experience the multiplayer, however the skirmish games were good fun, and I can only hope that playing over Live enhances the experience.

If you are a console gamer wanting to experience the wonderful world of RTS games, this is a perfect introduction to the genre in a familiar setting. We can expect DLC and updates for the game to appear down the line from the newly formed Robot Entertainment, which is staffed by ex-Ensemble employees.

If you intend to pick this up, you cannot go wrong by picking up the limited edition, especially if you are a Halo 3 fan. Early access to the Mythic map pack, and a good Halo Graphic Novel is worth the extra price for a fan, however if you do not play Halo 3 on Live, then you should probably just choose the standard edition.

Pros:

• Excellent graphics
• Fitting control scheme
• RTS replay value

Cons:

• Mission difficulty increase is annoying
• Occasional slowdown/stuttering
• Lack of ‘standard’ RTS features (Control groups)

Rating:

8.9/10

Best of luck to the employees of Ensemble in your future endeavours, and great work on your final game as Ensemble studios.