Anyone with more than just a passing interest in computer and video gaming has probably noticed the fervour in May surrounding the yearly Electronic Entertainment Expo, E3. Hardware was the flavour of the day, with announcements by Microsoft and then Sony overshadowing even the announcement that the long awaited FPS Prey was back in development. Amongst this, one of our team was on hand at the NVIDIA stand with Starship Troopers running on one of their systems. Interest was high, and a continuous stream of gamers came by to watch and play.

We got great feedback from people playing the game at the show. Overall everyone loved the game, and we’re really glad to see how well it was received. One issue we discovered was that our navigational aid for players, which we call the objective marker, was sometimes misleading. For example, though we might mark where the player was supposed to be going to, finding the recessed cavern through which the player must travel to get there posed difficulties.

When we first implemented the objective marker system we were undecided how much assistance we should be giving the player in how to navigate to their goal. Many First Person Shooters have level exploration as a primary driving force for the player. I remember spending many late nights rigorously checking the map in Doom I and II for blank areas where secret doors and passageways might be found. However the focus of our game is full on combat action, and though some players will want to fully explore the environment for hidden items, many will just want to turn off their room lights, ramp up the PCs volume, set their mouse to kill, and forge ahead into the jaws of the arachnid horde. So we’ll do our best to let the player know where to go, avoiding pointless hours spent trying to find the exit to corridor 33, and letting them get on with the game at hand.

I recently attended the Paris Launch party for NVIDIA’s Geforce 7800 GTX Graphics Processing Unit (GPU). Starship Troopers was one of the launch titles on display in the demo area of the event, and I’d been asked to give a short talk on how we make maximal use of the features of the new chip. Naturally this was an offer I couldn’t refuse; a free trip to Paris to a launch party combined with getting some good press for our game was a winning combination. I was also really proud of our team for having created a game NVIDIA was keen to use to demo their products.

The event went really well, and the 7800 GTX proved to be fantastic. I was particularly impressed that you could buy the product the day after the launch. Those of us getting the early bus back to the airport looked somewhat worse for wear after a night ‘improving our product knowledge’. Many thanks to all involved for a great evening.

Back here in the UK development is grinding on at a high rate. My talk at the show had pointed out that performance is a key area for a game, as improvements in the performance can be traded against increased quality. So it was pleasing to see that we’re making progress in this area once I got back. There are plenty of ways of approaching performance, and I’ve always been fond of a high level approach than a low level one.

Many moons ago whilst I was still an academic researcher, a PhD student came to me with a problem; the simulation he was running was going to take three years to finish, and he only had two years left to complete his research. We went through the code together, and first I showed him some easy optimisations to make – we split up a piece of code to make use of potential parallelism in the CPU floating point calculations. This sped the program up by three times, so if we ran the full simulation it would take a year. A few more so called low level optimisations like this and we’d made great progress, the simulation time dropping into the months.

It was at this point that I asked the student what the code was actually trying to do. Some time later it became clear that we could avoid doing calculations on much of the data which hadn’t changed. We added code to keep track of the changed data and only make computations on this. We ran the small test simulation – it finished faster than the precision of the basic timer we were using for profiling. Then we tried the full simulation, which finished in three seconds.

Three seconds rather than three years.

By taking a high level approach we’d simply been able to remove the calculations of a large part of the simulation. If we’d re written the entire code in assembly such a large change to the code would have been harder to do, and potentially we’d have not done this change. We follow a similar approach here at Strangelite, using C++ and modern design techniques rather than immediately coding to the metal.

Until next time.

Author: Doug Binks, Head of Studio, Strangelite

Related articles, Click here!