Archive for the ‘Games’ Category
2013 in games (and a look ahead to 2014)
I didn’t actually play that many games last year. The reason for that is I spent much more of my own time MAKING them, or at least the parts of them that interested me, a state of affairs that I’m perfectly happy with.
Here are games I liked, in no specific order because saying something like Papers Please is “better” or “worse” than GTAV is meaningless.
Walking Dead – 400 Days: A bit light on the actual “game” part but the writing was FANTASTIC.
Ridiculous Fishing: Lives up to the title and is just huge fun. I love Vlambeer.
GTAV: Overblown, terribly written and plotted, took itself too seriously, uncomfortably sexist and misogynistic; but enormously fun to play in the moment, with the best open-world engine ever developed. That said I’m conflicted about putting it on a list like this because it was SO offensively sexist it made me, Mr “Not offended by anything”, squirm.
Papers Please: The game from this list that I most wish I’d come up with myself. The concept is brilliant, the mechanics serve it perfectly, and it makes you think about all kinds of things including your own capacity for causing misery in a mundane, self-serving way. It’s a perfect little snowglobe of a game.
Bioshock Infinite: Really for the story and production values. I actually thought the core gameplay was nice but not very well-balanced and it didn’t evolve at all throughout the game. Infinite would make it into this list for the opening and closing sequences alone though, and the awesome anachronistic music and the reason for it.
Unity of Command: Incredibly good hex-based WW2 wargame. Handles the concept of supply lines better than I’ve ever seen them done before.
Kentucky Route Zero – Stunning to look at with its own unique visual identity and a very original story. Looking forward to more in 2014.
The Last of Us: Didn’t take enough risks with gameplay, so a bit disappointing in that way, but the story and characters were beautifully written and it’s one of the best-looking games of the year by a mile.
XCOM: Enemy Within: Really an excuse just to put Enemy Unknown back on the list for this year. The mechanics have really won me over since my initial “it’s not action points!!!1” reaction and it’s just a great, solid tactical turn-based game with a very strong metagame too.
Candy Box: An utterly brilliant piece of design. Surprising depth and quantity of content. A major reason I play games is “discovery” and Candy Box provided that in spades.
Some others worth mentioning:
“Meh, not bad” awards: Shadowrun Returns, Gone Home, Rogue Legacy, Stanley Parable
The much-talked-about games that did nothing for me awards: Brothers, Proteus, Monaco, Little Inferno, Far Cry Blood Dragon, NFS: Rivals
Games still on my backlog: Assassin’s Creed 4, Tomb Raider, Call of Juarez Gunslinger, The Swapper, Walking Dead s2e1, Saints Row 4, COD Ghosts, Battlefield 4, Assetto Corsa, Max Payne 3, Super Mario 3D World, Zelda ALBW, Wasteland 2 beta, Metro Last Light, Euro Truck Simulator 2 (yes, still)
What I’m looking forward to in 2014:
A significantly-upgraded Oculus Rift (higher res, positional sensor) with a killer app: Not sure what that app will be; my favourite thing on the Rift so far is a virtual cinema so it could be anything. It may be one of the space combat games like Star Citizen or Elite Dangerous.
Darkest Dungeon: Made by some local Vancouver indie developers including a friend I used to work with at Disney, I really believe this one will be something special. It has the unique hook of having to consider the mental state of your constantly-terrified party as you force them to confront the stresses of dungeoneering. There’ll be a Kickstarter soon.
Chaos Reborn: Julian Gollop’s return to one of his best games. Chaos on the Spectrum was an entertaining duel between wizards with some great mechanics, and Reborn looks like a great update.
Fallout 4: Come on, Bethesda. We all know it’s coming; just announce it already.
A 64-bit Unity editor with amazing garbage collection performance improvements and the new UI system: Hey, I can dream.
Unity: Using NGUI with the Oculus Rift
Many Unity developers are using Tasharen Entertainment’s NGUI as a UI solution, and quite sensibly in my opinion; it’s much better than the built-in GUI framework in many ways and I don’t think there’s anything better on the asset store either. I recently got it working with the dual-camera rendering of the Rift; here’s the method I used.
Basic Setup
NGUI uses its own camera to render everything on the UI layer(s) you specify. That’s a pretty convenient approach for Rift development as it turns out, thanks to a built-in Unity feature. We’ll be rendering to a texture and then displaying that rather than allowing the UI to render directly to the screen. If you’ve snooped around the Tuscany demo scene a bit, you might recognize this as the same approach the supplied OVRMainMenu takes.
Create a render texture in your project; you’ll probably want it to be 1024×1024 or 2048×2048 for UI use. Point the NGUI camera’s “Target texture” field at your render texture. You’ll need to create a new material that uses the render texture as a source, so do that – set the shader as “Unlit/Texture” right now. We’ll be coming back to shaders in a moment.
Next, create a plane (if you’re reading this IN THE FUTURE, Unity are supposed to be implementing a two-triangle optimized plane object; if that’s available, use it instead of the standard 400-poly beast we have now). Parent it to the CameraRight camera object inside the OVRCameraController. Note that this will give you a UI which is locked to the player’s view, no matter where they are looking; if you want a non view-locked UI that the user can look around, you might want to attach the plane object to the player object instead of directly to the camera. Position the plane in front of your player object, and orient it so that the top surface is facing the player. The position you choose is relevant, by the way; the Z distance from the player will affect the size of the UI onscreen.
Now set the material on the plane to be the render texture material you created before. If you have widgets set up in your UI, you should see them render in the scene view at this point, though the background of the UI will be a solid colour. Let’s fix that!
Shaders
We need to make a new shader to have things render correctly when using a render texture. We want the NGUI widgets to be rendered with an alpha channel. If you’re not used to shader programming, don’t worry! This is a pretty simple thing to pull off.
NGUI holds its shaders in the folder “Assets/NGUI/Resources/Shaders”. Open this path in Windows Explorer (or Finder or whatever other strange OS you might be using!). Find the “Unlit – Transparent Colored” shader and copy it. We’ll keep the original shader so we can reuse it, of course. Rename the copy to “Unlit – Transparent Colored RTT” (RTT being “Render To Texture” if it’s not obvious). Now open the new shader in your favourite text editor (I like Sublime Text!). First, change the name at the top to “Unlit/Transparent Coloured RTT”. Next, find the line with the text “ColorMask RGB”, and delete it. That’s all there is to it! “ColorMask RGB” tells the renderer to write only RGB values and ignore the alpha channel, and by deleting it the shader will default to writing all the info we need.
Save the shader, and find your NGUI atlas in your project view inside Unity. Specifically, you want the material that it’s using, which is always stored alongside the atlas object and texture with the same name. Edit it, and change the shader to the one we just created. Now, head back to your rendering plane under the CameraRight object, and change the shader on the render texture material you created to be “Unlit/Transparent Colored”. There you go – your widgets should be rendering just how you expect them.
If you don’t see your UI, it’s time to troubleshoot!
- Is the NGUI camera pointing to a valid render texture?
- Is the render plane oriented correctly? Neither the plane nor the material is double-sided so it will be invisible from the wrong viewing angle.
- Is the render plane using the correct material?
- Is the material using the correct shader?
- Is everything on your UI in the correct layer, and the camera culling mask is set up to include that layer?
As you can see there are a few potential points of failure so make sure to double-check everything as you go along.
Dealing With Clipping
One extra feature you might want is the ability for the UI plane to render over the environment, even if it would ordinarily be obscured by it. If you can stand to set up another shader we can fix that too!
In the NGUI shader folder, again copy “Unlit – Transparent Colored.shader” and rename the copy to “Unlit – Transparent Colored NoClip”. Edit the shader, change the name at the top to add the NoClip extension, and now look for the “Queue” line in the “Tags” group.. Change “Transparent” to “Overlay” – this tells the Unity render queue to render this object in the final group, after everything else in the world. Then find the “ZWrite Off” line, and right underneath that add “ZTest Always”. This means to always draw this material regardless of what else happens to be at that point onscreen.
Now change your render texture material (used on the plane object) to use this shader, and your UI will render on top of everything in the world. I suppose you might run into issues if you’re using fullscreen effects as they use the Overlay render queue too; I haven’t tried that out yet. Otherwise, you should have a nice-looking NGUI UI in your Rift!
Unity Planetoid Experiments, Part 2
In the first part of this article, I covered planetoid creation and navigation. Let’s press right on into how we navigate BETWEEN the planets!
Jetpackin’
I actually approached this project as first and foremost a jetpack “simulator” (though that’s a bit of a grand term). Even before the planetoids and multiple gravity sources, the first thing I implemented was my jetpack control method.
The basic idea is that the pack operates via thrust vectoring, with one or more moving nozzles providing lateral as well as vertical thrust. If the player leaves the directional controls alone, the nozzle(s) point downwards giving vertical lift. If they point the stick forwards, they rotate backwards to drive the user in the direction they expect. Of course, you lose lift at the same time, so it becomes a balance to find enough forward speed without dropping yourself out of the sky.
The system I went with is physics-based; the player object has a non-kinematic rigidbody, and the user’s inputs are turned into forces. The first step of that is to turn them into a nozzle orientation, which is nice and simple:
// The maximum amount in degrees the nozzle can rotate on each axis
const float kMaxThrustNozzleRotation = 80.0f;
// Nozzle rotation around the X axis is driven by the left stick Y axis
// (forward/back)
float xRot = controllerAxisLeftY * kMaxThrustNozzleRotation;
// Nozzle rotation around the Z axis is driven by the left stick X axis
// (left/right)
float zRot = controllerAxisLeftX * -kMaxThrustNozzleRotation;
// Build the rotation quaternion
Quaternion rot = Quaternion.Euler(xRot, 0.0f, zRot);
// Our thrust direction becomes the up vector rotated by the
// quaternion, transformed to the player object local space
Vector3 thrustDirection = transform.TransformDirection(rot * Vector3.up);
Then all we need to do is scale thrustDirection by our input value (I use the trigger so we can apply variable amounts of thrust), and apply the thrust as a force with rigidbody.AddForce(jetpackThrust) in the FixedUpdate function.
Orbits
The planets I described in the first article were static. That’s fine, but planets and moons usually orbit others, and it would be cool to have that working.
Luckily it’s simple to do. I just added a rigid body to my planetoids, set all drag to zero, set them up with a system that applies an initial force (for movement) and torque (for spin), and put them around another gravitational body. As long as you get the initial force close to correct, they’ll fall into a nice orbit.
Ah, but what will happen if something bumps into them? Well, even if their rigid body has an extremely high mass, if the other object’s is set to kinematic it will disturb them. The planetoid will probably deorbit, with no doubt tragic consequences for all involved.
The workaround for this is to create another object with which all collisions will take place. It will shadow the planet without actually being parented (as parenting it would impart the results of any collision back to its parent’s rigid body).
Take any collider off the original planet, give one to the shadow object instead, then every update set its transform position and rotation to be the same as its owner. The timing for this operation is important; I tried LateUpdate (collider will lag by a frame) and FixedUpdate (collider won’t update smoothly) first, but Update is the magic bullet which will give you the correct position and orientation.
The effect of this is that any object will now collide with your fake shell and not the planet itself, which will remain blissfully unaffected by the otherwise catastrophic results of innocent kinematic players landing on its surface.
But hang on – why is the player using a kinematic rigid body? Didn’t we just discuss a physics-based jetpack system?
Landing on Planetoids
Those of you paying attention will note that in the last article I cautioned against the use of a force-based movement system for our character when on the ground, and yet here I am using one for my jetpack. Before I get into why I’m doing that, let’s see why using forces for character movement is a bad idea when attaching to planets in the first place.
When landing on an orbiting planetoid, how do we keep our character attached to it as it moves through space? Well, the normal thing to do is to parent our character to the object it’s just landed on. Parenting means that our character’s transformation matrix will be transformed relative to the parent’s matrix and thus all of our movement becomes local to that parent object. In effect, we’re “stuck” to it.
The problem is this: parenting non-kinematic rigid bodies together is a no-no. In fact, you shouldn’t parent non-kinematic rigid bodies to any moving object. It might seem to work most of the time, but you’ll get odd effects when you least expect them; the parent’s transform updates don’t play nice with force-based movement.
So what do we do? We actually have a few options. We could use potentially use a joint, such as a FixedJoint, which is a method of attaching rigid bodies together. However this has some differences to the standard parent-child relationship, and wouldn’t work for our needs here. Another approach would be to go to a completely kinematic solution – replacing the force-based jetpack system with a method of updating the object transform manually, which would involve keeping track of my own accumulated thrust vectors, collisions and so on. However frankly this seemed like a lot of work, and I already had a movement system that felt great which I didn’t want to wreck. So I decided to switch my character’s rigid body from kinematic to non-kinematic depending on whether it was on the ground.
A kinematic rigid body is one which doesn’t respond to forces. If you set one up by checking the Is Kinematic box in the inspector, it’s expected that you control it manually by updating its transform. So what I do is when the player is jetpacking through space, his rigid body is a standard non-kinematic one which responds to gravity and jetpack thrust. As soon as I detect a ground landing though, the rigid body is switched to kinematic and my code changes to use the movement system described in the previous article. If the player applies thrust, or if gravity from another body begins to pull him in a new direction, we switch back to non-kinematic again to allow the forces to take control.
This works great and only has one real drawback – the bouncy, slightly untethered feeling of light gravity vanishes when walking on a low-gravity planetoid. That’s because gravity isn’t actually applied when the player character is on a surface, and we rely purely on the ground-snapping from the movement code to keep us attached. That may sound bad (and it’s definitely not ideal), but it’s not actually that big of a problem for my use case. If it becomes more important, I’ll look for a solution.
One other point about parenting objects – never parent an object to another with non-uniform scale. If your objects are rotated, this will introduce shear into the child object and you’ll get very odd results, usually manifesting as a sudden and gigantic increase in scale. Avoid at all costs!
Alright! So now we can navigate between orbiting planetoids. What’s next, I wonder?
A probably very queasy astronaut goes for a ride in a busy solar system.
Unity Planetoid Experiments, Part 1
Recently I’ve been messing around in Unity with something intended for the Rift, though I don’t yet have my kit (and won’t for several months by the sounds of things). I’ve always been a fan of the innovative and beautiful Super Mario Galaxy, especially the planetoids and other structures that comprised its levels, each providing its own gravity. I wanted to try a first-person version of that concept, in a less fantastical setting. You can see an early version of what I came up with in this Youtube video. Along the way I found and overcame a few problems that I thought it was probably worth sharing the solutions for, so here’s a quick review.
GRAVITY
So the first thing to do is to replace the simple default PhysX-provided gravity source with something a lot more flexible. I wanted to mix my planetoids with a more traditional “flat” terrain, so created two types of gravity source – spheres and infinite planes. A spherical source will pull objects towards its specific position (usually the center of a sphere), whereas the plane sources pull objects to the surface of the plane. If the plane pulled objects towards its position, they would be pulled horizontally inwards to the center of the plane object which is obviously not what we want.
So for a spherical source, the gravity vector applied to a given object is just (object position - gravity source position). The gravity will naturally fall off over distance, so we’ll want the magnitude of that vector to calculate the gravity strength. For an infinite plane the gravity direction is always the local down vector (ie. -transform.up), and for distance we want the shortest distance to the plane, which you could also describe as the vertical component (in the gravity source’s local space) of the same vector. We can get this with the dot product of the vector from an object to the plane’s position, and the local up vector:
float distanceToPlane = Vector3.Dot(objectPos - planeTransform.position,
planeTransform.up);
Then all we need is a gravity manager object which is responsible for calculating the gravity vector at any given point. This is easily done by totaling all forces which act on that point (ie. where the magnitude of the gravity vector returned from a source is > 0) and then dividing the resulting vector by the number of active sources we found. To get an object to be affected by the gravity, add a rigid body to it, turn off “Use gravity” to disable the standard effect, and finally add a script to each object which has the following function:
void FixedUpdate()
{
Vector3 gravityVector = GravityManager.CalculateGravity(transform.position);
rigidbody.AddForce(gravityVector, ForceMode.Acceleration);
}
A couple of things to note there – one, we’re using FixedUpdate, because it occurs right after the physics have been calculated and at a nice predictable steady rate. Always add forces in FixedUpdate. And the second thing is to apply the force as an acceleration to get the right effect.
An interesting note about Super Mario Galaxy – it has all kinds of oddly-shaped landmasses, such as eggs, toruses, Mario’s face etc, which apply gravity to characters in a way which feels natural as you run over and around them. I suspect what they’re doing is using the inverted normal of a base layer of ground polygons that Mario is currently above as the gravity vector. The raycast to find the ground would ignore all other types of objects that would be in the way. This would be easy to add to this system and would be a nice experiment.
MOVEMENT AND ORIENTATION
When moving the player (or any character) around a planetoid, presumably you want it to orient to the surface on which it’s standing. You also want movement to be completely smooth and to feel the same whether you’re on the top or bottom of the sphere. Now I have to break some bad news to you: the CharacterController that Unity provides won’t work for this use case. It doesn’t reorient the capsule it uses – it’s always upright no matter what the player object’s orientation is. In addition it comes with certain assumptions that don’t fit our needs, such as a world-space maximum slope value.
My initial solution to this problem was to take advantage of the rigid body which was already attached to the player object, and use a movement system which pushed the player around with forces. This worked great but ultimately it proved unworkable as the planetoid code moved along to the obvious next step. I’ll keep you in suspense until the next article if you can’t guess why, but for now just take my word for it – a force-based system isn’t going to work for us.
So, we’re going to reinvent a large part of the CharacterController wheel here. First make sure the player object has a capsule collider as well as the rigid body; rigid bodies don’t have any physical presence in the world so you still need the collider. The rigid body needs Is Kinematic set to true – that means we’ll be updating the transform directly rather than using forces to move it. More on this in my next article!
We need to decide on a step height, which will control the maximum height the capsule can “snap” if it finds an obstacle or a drop in the path of movement. Mine is set to 0.5m. My cheap step height shortcut is to pretend the capsule is actually at its height + stepHeight when moving it – the obvious disadvantage here is that you need at least a clearance of stepHeight above the player to move, but that’s not a problem in my case.
To handle possible collisions, each frame we’re going to move the capsule in a number of iterations. I won’t go into too much more detail as this is a large topic that probably requires an article of its own, but the basic pseudocode algorithm is:
while (movementVector.sqrMagnitude > 0.0f)
{
Vector3 movementDirection = movementVector.normalized;
float movementDistance = movementVector.magnitude;
RaycastHit hitInfo;
if (Physics.CapsuleCast(capsuleTop, capsuleBottom,
capsuleRadius, movementDirection, out hitInfo, movementDistance))
{
// Hit something!
Move the capsule to this point (remembering to subtract the radius first,
as we've hit with our edge but the position is the capsule center).
Pick a new movementDirection (maybe a vector reflection or a direction
perpendicular to the normal of the face we've hit).
The length of the new movement vector is movementDistance minus the
distance we've just moved in this iteration.
}
else
{
// Reached our destination (transform.position + movementVector)
Cast a ray (or capsule) downwards from the destination to find the ground
height, using a maximum distance to avoid snapping when the ground is too
far away, eg. when walking off ledges.
Move the capsule to this location at the ground height (plus half the
capsule height to account for the capsule center being our position).
movementVector = Vector3.zero;
}
}
The reason we keep moving once we’ve hit something is that otherwise the character would just hit an obstacle and stick to it. It’s always nicer to slide along it.
That should take care of movement. The ground snapping required while walking along a curved surface is taken care of by the algorithm above. So now we just have orientation to worry about! This can be surprisingly tricky until you hit on the right approach, especially around the poles as you might encounter ugly rotational snapping issues. The key is one of Unity’s math functions; Quaternion.FromToRotation takes two rotations and returns you a quaternion which will transform one to the other. Don’t forget to apply that to your original rotation afterwards.
Quaternion desiredRotation = Quaternion.FromToRotation(transform.up,
-vGravity.normalized) * transform.rotation;
transform.rotation = Quaternion.Slerp(transform.rotation,
desiredRotation, maxGravityOrientationSpeed);
The above code finds the ideal rotation for the current gravity direction, then applies a slerp blend to make sure the transition is smooth.
OK, so now you should be able to set up a planet with spherical gravity and have a player character walk around it. In the next article, I’ll talk about extending the system to support moving and rotating planets, and moving the character between them. Thanks for reading!
Designing Games for the Oculus Rift
If you’ve been following game news for the last few months, you’ve probably heard of the Oculus Rift. An affordable yet advanced stereoscopic head-mounted device, it’s causing something of a resurgence in the seemingly dormant field of virtual reality games.
I’ve been going back and forth on ordering a devkit for a while, and finally took the plunge last week. This is already a cause of much regret, as I find myself at the back of a queue thousands of developers long. If I’m lucky I might see a device this side of the autumn equinox.
Patience never was my strong suit 
Self-pity aside, I’m now turning my thoughts towards what I’m going to do with the thing. I realized pretty quickly that despite my long experience in game development, including working on many first-person shooters dating back to the original PlayStation in the mid-90s, I’ve never actually thought about designing specifically for VR.
On the face of it, you might think that a conventional FPS was well-suited to a device like the Rift. After all, the viewpoint is the same, how much more to it could there be? Well, as it turns out, a lot!
The first issue is the player’s disconnect between their awareness of their own body and the avatar they’re controlling in the game. VR delivers a sense of presence, yet our current control interfaces break that immersion just as it’s getting started. We can’t yet move our avatar by walking or running, we need to move a control stick. We can’t swing our arms around to aim a weapon; again, we need a control stick. When the player looks to the right or left in a VR game, the inclination may be to rotate our elbows or shoulders to try to bring a gun around with our viewpoint. That’s similar to how many people tilt a controller left or right when navigating a corner in a driving game, and just as ineffective.
From this we can see that controls that complement the VR experience will be a thorny issue, at least with current input devices. TeamFortress 2’s Rift integration apparently comes with seven different control schemes offering different methods of aiming and moving. That sounds like a lot, but more choice can only be good as the industry begins to figure out these new problems.
Next up are problems of scale. Speed especially is unrealistic in most games – this PAR article points out that the Scout character in TeamFortress 2 runs at 40mph! That’s incredibly disorienting for a player and may well be a cause of some of the not-infrequent reports of nausea and motion sickness that a device like the Rift can produce.
That Penny Arcade article talks about (and in fact is predicated entirely upon) another surprising fact, one that I’ve seen reiterated many times by many different commentators. That’s the fact that the true joy from a VR game seems to come mainly from immersion and the sense of physical freedom it conveys rather than any combat or competitive element. It’s been compared to lucid dreaming; the wish-fulfillment of finding ourselves a superhero, or journeying to another world.
“I could have easily spent an hour just flying around from rooftop to rooftop in Hawken, without any care for the game’s intended purpose as a mech war simulator.” – The Verge – I played Hawken on the Oculus Rift and it made me a believer
“I didnt race right now, only sitting in AIs car watching and looking around, but i could do that for hours being amazed and not getting bored :)” – vittorio, rFactor 2 forum post
Perhaps this is simply a passing phase, and as we get more used to and comfortable with VR devices we’ll want to get back to the game mechanics we’ve been challenging ourselves with for the last 40 years. Or maybe this really is a sea change in what we want from our games. Either way this development is more exciting to me than almost anything else I’ve ever seen in this industry – and I’ve been doing this a long time!
So what am I thinking about for my first hobbyist VR project? I have a specific design in mind but I’m not letting the cat out of the bag that easily! I’ll go over some of the factors I’m considering though.
In keeping with the articles I reference above, I’m thinking that a game based around exploration and free movement with possibly only some small element of challenge is probably the best idea at this point in time. It’s also been pointed out in several pieces of Rift coverage that vehicles seem to provide a better sense of immersion than controlling a humanoid avatar – the act of sitting in a virtual car or cockpit seems to map much more closely to the probable sitting posture of the player and removes some of the body-disconnect I discussed earlier.
The perfect VR game? Or would it be too much to handle?
I like the idea, suggested by my friend Martin in this thought-provoking article on VR design, of having a reason for the player to look around, to force that immersion provided by low-latency head-tracking to be used to its fullest. Maybe we don’t need a HUD anymore, and can look at our own character or equipment to get all of the state information we need. Maybe the player needs to identify things in the world by hunting them out visually. And maybe we are no longer forced to make important events happen directly in front of the avatar.
And finally, I’m a coder (and closeted designer), not an environment artist. For my one-man side projects, an abstract world is going to be easiest to put together, Unity Asset Store notwithstanding. Style is something I’m not too worried about for now. I imagine a VR environment will be effective with cubes as long as it’s lit reasonably well, and is built with lots of depth and reference points to provide an appropriate sense of speed.
These are only my initial thoughts. As I get stuck into this I expect I’ll change my mind about some things. I’ve likely got a few months before my kit arrives so I have time for some experimentation. If I produce anything interesting I’ll keep you updated!
Rallying on PC, the State of the Art, Part 2: Richard Burns Rally
A triplescreen view of the start of a stage, showing the stretched HUD that occurs at this extreme widescreen resolution.
So yes, this article is titled “The State of the Art” and yes, Richard Burns Rally (hereafter RBR) was released in 2004, making it almost 7 years old at the time of writing. However in many ways it IS the state of the art when it comes to realistic handling, physics, and stage modelling.
Produced by Warthog in Sweden and endorsed by the brilliant British WRC champion Richard Burns, RBR was a vaguely promising-looking title from a mostly unknown studio that surprisingly turned out to be the king of rally sims. Not only did it come out of nowhere, the series was sadly destined to return there due to the tragic and untimely death of Burns in 2005, and the bankruptcy of the developer. So unlike the venerable Colin McRae Rally series, it’s a single, standalone game.
Most game series (and this is especially true of sports games) need to iterate on their base content a few times to really fulfill the promise of their source material. However, in the single game they produced Warthog Sweden managed to include dozens of unique stages, great replays, a championship mode and best of all, an interactive rally school that teaches you the individual maneuvers you need to drive a rally stage and can grade you on your performance. Stages are modeled on real-world events and can be miles long, far outclassing the rally content found in the Dirt series. All that content coupled with the superb handling model resulted in an exceptional sim… in 2004 anyway.
Taking the jump at the famous Mineshaft in Australia, driving Petter Solberg's WRC Subaru from 2009.
In the fast-improving world of PC hardware, a game typically has a very short life. Upgraded CPUs, video hardware, rendering APIs, and even input peripherals limit the effective lifespan. It’s definitely something of an anomaly that a 7 year old game still has an active community, but happily RBR’s fanbase has managed to update the sim to keep it relevant and usable.
The single best mod for RBR is RSRBR 2011. It’s a one-stop solution which adds dozens of new cars and stages, including modern WRC vehicles organized by season and the classic 80’s hugely-overpowered Group B cars. RSRBR even adds online play. RBR can now even support a multi-monitor setup using a program called Camhack (included in RSRBR) which can edit all aspects of the in-game camera views. It’s not perfect – HUD elements are stretched and the game’s UI is very dated – but the game is genuinely playable even when compared to modern sims. A lot of the current graphical polish is missing of course but in every other respect, RBR outclasses all other modern rally sims and is simply the most realistic pure rallying game available.
The game still looks pretty good!
Rallying on PC, The State of the Art, Part 1: Dirt 2 vs Dirt 3
I’ve always loved the sport of rally racing. It’s an incredible spectator sport; unlike normal circuit racing, almost literally every single second of rallying coverage is exciting to watch, as the drivers thread their way along tight stages at unbelievable speeds. Unfortunately in Canada there’s no way to watch WRC (the World Rally Championship, the pinnacle of rallying in the same way that F1 is the pinnacle of open-wheel racing) in any form. So lately, after building a new gaming PC, I’ve been turning to driving sims to get my fix.
Dirt 2
The first rally game I jumped into was Dirt 2. I’d bought it in a Steam sale some time ago and hadn’t tried it out, but managed to get bored enough one weekend to give it a go. And happily, I was blown away! Somehow I’d managed to miss the hype when it was first released, and had no idea of the sheer quality and depth the game has. I love discovering unexpected gems like this.
The physics are great and crashes can be spectacular!
Despite being a couple of years old now, D2 looks phenomenal, and works great on a 3-screen Eyefinity setup. The audio is also amazing, with a good base engine note and details like gravel hitting the underside of the car, suspension squeaks and rattles, turbo blow-off etc. But the best thing about the game is the steering wheel support; the force-feedback is the best I’ve experienced in any game or sim so far, and does an amazing job of communicating the road surface and the amount of grip. It needs to be experienced, writing about it can’t do it any justice so if you have a wheel I highly encourage you to try the game out. As you’ll see in the next part of this series when I cover Richard Burns Rally, Dirt 2 is not really a sim, and the handling is not “realistic” – but that doesn’t mean it’s not satisfying and hugely fun.
The best-looking Pontiac Solstice ever.
It’s not perfect, of course. In addition to basic rallying and trailblazer (hill-climb style cars with no pace notes), Dirt 2 has rallycross (basically circuit racing in rally cars with 7 opponents) and truck events. The rallycross is less successful than the pure rally gameplay – I’ve had to restart many races due to unavoidable hits by the AI – and the truck racing is a big point of contention in the fanbase, with many people complaining about its inclusion and the amount of it in the career mode. I agree with the latter complaint and feel there’s just too much landrush, the truck version of rallycross, especially. In addition, there’s a pretty good variety of locations across the game but there’s a lot of repetition in the actual track layouts, as typically there’s only one track per location that’s re-used in sections for different events. Finally, a big wishlist item for a sequel would have to include a more feature-rich replay mode – the camera selection is superb but you can’t save or edit replays, and there’s no photo mode which is a real shame as the cars and environments look great.
The environments looks great in 3-screen Eyefinity - click for a bigger view.
Dirt 3
Dirt 3 was released just a few weeks ago and I was very hopeful – here was a chance to really improve the core gameplay and fix the problems with Dirt 2. Unfortunately, it’s a disappointing missed opportunity.
Let’s talk about the improvements first. The addition of weather and night driving is very welcome, and adds variety to the stages. The incremental improvements in the rendering, most noticeably better post-processing (motion blur and lighting effects especially) look really good, though they do hit the framerate a bit. And the new environments take advantage of the new capabilities (especially snow in Norway) and offer some nice diversity.
More beautiful environments in Dirt 3.
And so onto the negatives. First of all, the major new feature that Codemasters have been pushing, and what a lot of the game is actually built around – gymkhana. Oh boy. If you thought the truck racing was controversial, you haven’t seen a forum thread on gymkhana go nuclear. Nothing to do with posh girls and horses, gymkhana refers to Ken Block’s “auto playground” videos, where he flings a car around obstacles with ridiculous precision. As a 3-minute Youtube video, and no doubt as a spectator event, it’s spectacular. Actually driving it… I’m not convinced. It requires skill that most people simply don’t possess, and while you could make that argument for racing too, it’s fairly easy for a game to make you FEEL like a good racer, by simply lowering the challenge provided by AI or time limits, or having traction control-style driving aids enabled. With gymkhana, if you have trouble power-sliding a car in smoky circles inside a concrete box, it’s not really possible to make that any easier. There’s a “trick steer” driving aid provided, but with a wheel I couldn’t tell much difference with it activated and it didn’t make my life any easier as far as I could tell. In addition, the tutorials for specific tricks are short and uninteractive and really don’t help you to learn how to perform the more difficult ones.
Unfortunately there’s a good amount of freeform gymkhana in the career, and worse, there are “gymkhana attack” events. These give you tricks to perform in a set order with a strict time limit, and I found them incredibly annoying. They kill the flow of the game far worse than the truck events did in Dirt 2. There are also despicable “drift” challenges that are similarly horrible and feel out of place. Drifting and rallying are two different disciplines; people interested in one are by no means likely to care about the other.
So what about the rallying itself? Well, the good news is that the superb control has been retained, and even improved a bit, with more of the car’s weight felt in sharp turns. Some of the tracks are just awesome fun, especially the snowy Norwegian trails. However, the stages are all very short, even more so than in the first game it seems, with the longest being a few minutes long and the normal length being around 90 seconds or so. And the amount of rally content in the game is not as great as advertised – Codemasters were saying 60% of the game would be rally/trailblazer, and it honestly only feels like half that to me. I should go count the events to back that up but that’s my gut feeling after playing the first half of the career.
Both Dirt 2 and Dirt 3 have superb multiscreen support. This is the hood cam view in 3-screen Eyefinity. Note the HUD is drawn on the center screen, where it should be. Click for more detail.
The main announcer for the game is now a super-annoying Californian-sounding guy that for some reason insists on calling you by Spanish/Mexican male-bonding terms of endearment (amigo, muchacho, compadre…). He’s absolutely obnoxious and seems targeted directly at Mountain Dew commercial audiences. It reads like an attempt to make rallying “extreme” and basically sex it up to get people with more hormones than brain cells interested, but it just ends up insulting everyone involved and honestly lowering the tone of the whole game.
And finally, no improvement has been made to the replay mode at all. The single new feature we got was an “upload to Youtube” option, which allows you to just take a 30-second slice of the replay and upload it (and incidentally provides the hyperactive announcer with some of his most annoying lines). No editing, no photomode – extremely disappointing.
So, while the actual rally driving in Dirt 3 is probably the best yet, the game itself is a step backwards and I’d say that Dirt 2 is probably the better product. It’s not too expensive on Steam, and in fact is likely to be featured in the (hopefully) upcoming summer sale – so jump in and see why I like it so much!
I agree :)
Top 10 Games of 2010
This is the first in a series of posts of 2010 top 10 lists that nobody will care about except me, and I’m fine with that 
For this list, I’ve decided to be slightly controversial and include games that weren’t necessarily released in 2010, but that I’ve played for the first time this year. There were a couple of standout games that I didn’t want to miss discussing and, as we already established, nobody cares anyway.
In the traditional reverse order then…
10 – Alan Wake
Even though I was hoping for much more, this still turned out to be an interesting, great-looking and fun albeit linear action game. The environments and atmosphere were superb, and the flashlight mechanics were at least an attempt to add something new.
9 – Civ V
I’ve seen some strong criticism of Civ V recently, but I enjoyed it more than Civ IV. It has some nice new mechanics and a great interface. On the downside, the AI is a bit ropy. I didn’t try the new patch yet though, which claims to enhance this and many other areas of the game.
8 – God of War 3
An amazing technical achievement and just a great, strong third-person action game. More please!
7 – Gran Turismo 5
Another achievement but wow do I have a love/hate relationship with GT5. The menus and career modes are awful, but the actual driving is sublime. Definitely the best driving sim on a console.
6 – Heavy Rain
Heavy Rain surprised me with its ability to tell a genuinely good story with meaningful branches depending on how you played it (almost everyone I know who played it took a much different path to the one I experienced, which made the post-game conversations really fun).
5 – Minecraft
Everyone’s heard of Minecraft now and deservedly so. Notch just did an amazing job with his sandbox world generator and he deserves all the success he’s had, and the success no doubt still to come.
4 – Batman: Arkham Asylum
The first 2009 game of the list! I didn’t get around to playing it until the start of the year though, but it’s brilliant. Amazing narrative and combat.
3 – Fallout: New Vegas
I almost didn’t play this, thinking that it sounded a lot like an extension rather than a sequel. In a way, I still think that’s sort of the case but that doesn’t change how great it is. A huge map with tons of interesting locations to discover and some excellent writing (though I think some of the best Fallout 3 quests still eclipse the best quests in F:NV). Luckily I started playing after the first patch which GREATLY improved stability, so I think I only had one crash in about 50 hours of gameplay.
2 – Assassin’s Creed 2
I feel like I’m cheating slightly putting this as my #2 as I’m still playing through it, not to mention the fact it’s another 2009 release, but what a game! It gets my vote for being the best-improved sequel in recent memory. I actively disliked AC1, but somehow Ubi managed to fix basically all the issues I had with it and AC2 is just so fun. They even throw in a sort of city-improvement-lite metagame on top of the exploration and combat. Great stuff and I can’t wait to move onto Brotherhood.
1 – Red Dead Redemption
As good as AC2 and the other games are, for me this year RDR is in a class of its own. It probably helps that I love spaghetti western movies and music, but as a cohesive experience this game is on another level. Every part is superb and complements the whole, from the character design, wonderful dialogue, music, and especially the landscape which is almost a character in itself. The technical achievement to bring all these things together in an open world, and not have any streaming or AI issues show it up is notable (compare with Fallout!). And without spoiling the ending, the depth and the commitment to provide a proper conclusion to an epic experience highlight one of the biggest differences between Rockstar and everyone else right now. We’ve all heard the horror stories around RDR’s development and yet despite the circumstances in which it was created, the game has emerged as a nearly perfect classic. Congratulations to everyone who almost died making it!
Honorable mentions:
Mass Effect 2, Amnesia: Dark Descent, Silent Hill: Shattered Memories, No More Heroes 2, Limbo
Games I didn’t get around to playing, some of which will no doubt end up on my 2011 list:
Bayonetta, Halo Reach, Mafia 2, Assassin’s Creed: Brotherhood, Starcraft 2, Darksiders, Back to the Future (Telltale)
Most-anticipated games of 2011:
Dead Space 2, Journey, Elder Scrolls V: Skyrim, Forza 4, Diablo 3, Portal 2, Crysis 2, Rage, Deus Ex 3 (wow… that’s a sequel-heavy list)
Dragon Age: A Counterpoint
It’s the end of the year, and I’ve been seeing Dragon Age pop up on a few best-games-of-2009 lists, like this one. Yet despite being one of my most anticipated games of the year, it turned out to be a huge disappointment for me. I think you can mostly boil my problems with the game down to one thing: a lack of innovation. To me, it represents the taking of the safe path, making no attempt to forge a trail of its own.
DA comes, of course, from Bioware, unquestionably one of the best and most consistent Western developers. Baldur’s Gate and the sequel are two of the best CRPGs of all time, and most of their recent games have hit the mark too. With Dragon Age, I expected that the long development time would have resulted in something really special. Freed from the restrictions of the D&D system and setting, Bioware could set their imaginations free and really push the bar of what we expect in an RPG.
Hoewver, this didn’t really happen. Rather than pushing boundaries, breaking rules and making new ones, Dragon Age conforms to almost every fantasy and RPG stereotype there is. To start with the plot, the kingdom is made up of men, elves, and dwarves, who don’t really get along. There’s a dark force threatening the world. I mean, seriously? They had a blank canvas and couldn’t come up with anything more original than that? I haven’t finished the game yet, but 30 hours in the story hasn’t become any more interesting, with no significant plot twists or even particularly interesting characters (with the exception of Morrigan and Shale, the sarcastic golem who has some great lines).
The big “innovation” with the story that Bioware were pushing was the fact that you can choose from a number of possible races and starting situations for your character, and these origin stories would colour the story throughout the game. In practice, it seems that this just means there are a few different 60-minute or so game intros, and after that there are simply some extra branches in conversation trees as you make your way through the rest of the story.
The gameworld is as uninteresting as the plot. Levels are small, linear, and static, with no use of physics objects or even background details like fauna, weather or environmental effects. Characters are mostly static, standing on the spot and waiting around for you to talk to them and solve their problems. The world map is constricted arbitrarily, with new areas appearing only when a character in the game tells you to go there. There is zero exploration.
If the game itself was fun, balanced and gave you that awesome “if I play just another 10 minutes I’ll unlock the next reward” feeling, none of this would matter particularly. I loved Oblivion, for instance, but that game’s plot is no better, and it has plenty of faults of its own. However, Dragon Age’s mechanics simply aren’t very interesting. Among other things, it suffers from a lack of information and transparency regarding its basic workings. There simply isn’t any information on basic calculations, information that any D&D player has at his fingertips. The interface doesn’t help either; for example, Dragon Age has a huge “codex”, with hundreds of encyclopedia-style entries filled in as you go along; a fine idea. However each entry is presented as a simple NUMBERED SQUARE in the interface and you need to click it to see the content! Some vital game information is conveyed in the codex and the difficulty of finding anything in there is horrendous and completely unnecessary.
Other companies like Bethesda have shown us a different way of doing things lately, Fallout 3 being my favourite game of 2008 and showing everybody what a sprawling open-world RPG with semi-real-time combat could be. Dragon Age, however, simply slavishly follows existing paradigms and doesn’t even tell a good story along the way. Come on, Bioware, I know you can do better than this!
(My friend Justin already wrote his version of this post over at his blog. We bitched about the game together a few times so it’s not surprising we feel the same way!)
Pirates of the Caribbean: Armada of the Damned
Well if this isn’t worth a blog post, I don’t know what is. The game I’m working on has finally been announced!
‘Armada of the Damned’ is an awesome action RPG for consoles set in the Pirates universe. Not much info has been released yet so I can’t add anything to the IGN article, which has an interview with our game director, Alex. Really though, it’s going to be great.
