Introduction
Last year, a complete novice to UE, I thought it was somehow wise to attempt to write a complex racing game right off the bat. Having coded almost exclusively in traditional C++ using in-house engines throughout the entirety of my career, UE’s development paradigm was a fairly foreign land and this may have seemed like a foolhardy move. But amazingly, it wasn’t. UE has proved to be very adaptable, and very easy to get into, perhaps more than any other engine I’ve ever worked with.
So my partner and I made this little project called GRIP. We hammered a prototype together and proved that the game we both had in our minds was indeed achievable with this technology. Tested the market waters on the internet a few weeks ago and all went well, being greenlit on Steam in just 5 days – we never expected that. Apart from the obligatory bit of self-promotion, I’m actually here to talk about the technical aspects of the project. But first, a brief bit of context about the game …
The Game
So, what is this GRIP? Our marketing spiel says; “Inspired by the Rollcage games of 15 years ago, GRIP is a new IP for a new generation. A return to the hardcore combat racer, bristling with heavy weapons and packing ferocious speed, the game is an intense, sensory feast. Harnessing the awesome potential of Unreal Engine 4, GRIP will take you back to your nostalgic past, while simultaneously propelling you into a kick-*** future.”
Sounds exciting, and actually, working on the game has been. Just as in Rollcage, the cars in GRIP are out of the ordinary. With large wheels that extend not just below the frame but also above it, with GRIP’s cars there is no right way up and they can flip sides whenever they need to and just keep on thrusting forwards. In addition, these cars also develop a tremendous amount of down-force, so much down-force in fact that driving on walls and even ceilings becomes possible.
All of the vehicles in GRIP are heavily armed and this plays a big part in the game – weapons and power-ups are an integral part of the races here. Gatling guns, homing missiles, mines, railguns, energy weapons and even shields and engine boosts are all in there, and we’re also busy thinking of more.
Of course, there will be many tracks to race on over many varied worlds, and we’re hoping UE will make them look as beautiful as some of the other projects around here with its great rendering tech. But these will be destructible scenes too, where you can destroy various elements using your weapons to help scupper your rivals, or to uncover new routes around the track which may well help your lap time. And at least some of these destruction sequences will, we hope, look epic as they come crashing down around your ears. As with all games however, it’s not all fun in the Sun …
Development
Unreal Engine, for all its magnificence, is not without its issues. It’s a monolithic, complex engine, and that Epic has made it accessible at all is testament to their user interface and design strategies. When we say we’ve had issues, it’s not to criticise, it’s to acknowledge that while UE is good for many different kinds of projects if you want to accomplish something reasonably unusual with it, then you’ll need to start getting your hands dirty. And with GRIP, we had to do just that.
It started with the vehicle physics, right back at the beginning of the project. Of course, I downloaded and played with the standard vehicle sample projects that Epic provided with their newly-added vehicle physics components. These worked pretty well at first, with us tinkering with grip and acceleration until the cars felt reasonably controllable. Zipping around a test ground it felt like we were making some real progress really quite quickly. Our problems began however, when we tried to make the cars flippable, in that they can drive either way up.
Of course, this isn’t possible with real cars, as the wheels spinning in a particular direction will need their pitch rate instantaneously reversed for them to give the same traction when the car’s orientation is flipped. And this wasn’t possible with UE’s vehicle setup either.
Another related problem was with the fact that we effectively needed two sets of springs, one set for the bottom side of the car and another set for the top. We would only use one set of springs at a time, depending on which direction the driving surface is located (just determining that can be complicated). However, even with this dynamic switching, we just couldn’t get the vehicle physics to work. Either the car would slide without friction along the driving surface from the moment it flipped or it would just send itself into orbit with some sort of massive physics impulse that we couldn’t control. Our specialist driving model looked like it wasn’t going to fly, things looked grim.
But hey, down but not out, I figured I would just have to code this myself. Not having the wherewithal to get into Epic’s vehicle physics, which in turn is largely implemented within PhysX anyway, if we wanted this kind of driving ability then the only real option left was to create our own driving model and bypass what Epic and PhysX provide in theirs.
I’m not a physics coder. I’ve worked among them, I’ve even dabbled from time to time, but never to the extent that would be required to get this thing working. But luckily, we still had the basic PhysX functionality on our side; with collision, physics assets, masses and forces all at play within the PhysX core. With that, we certainly had a solid foundation on which to build these flippable cars of ours.
And so we did. Taking direction from the thoroughly helpful, if light tutorial video that Space Dust Studios put out at about that time, we saw that it wasn’t terribly difficult to write a simple vehicle model, from a conceptual point of view at least. So we got to work, and right enough, in a few days we had the beginnings of a car. Not just any old car, but a flippable car at that.
Since then we’ve had to write models for suspension, models for friction, front and rear wheel driving, gearing, engine management, braking, drag, power-sliding, down-force and even enhanced gravity. The remarkable thing about all of this though is that the majority of these components were implemented purely with AddForce or AddForceAtLocation. You don’t need to use many facets of the physics system to get realistic physics behaviours.
Some things we had to massage by manually adjusting the rendered position / rotation of the car body with respect to its wheels. In this sense we were adding tilt and lean to portray weight. We also used that same mechanism to stop the suspension allowing the car body to dig into the wheels at extreme compression / extension. All of this was done to enhance the impression of realism without upsetting the already carefully balanced physics handling. It was one of those occasions where faking a couple of aspects was the better route to a final, total vehicle solution.
There is of course a lot of detail missing from the discussion here, but I’m happy to answer questions until my next post. In the meantime you could always check out the KickStarter page (GRIP - An intense futuristic combat racer (Canceled) by Caged Element — Kickstarter) which has a lot more information and some great visuals. We’ve still some way to go before the handling can be considered perfect, and for that I need to get under the hood and compile our own version of the engine. Some details like timing, where forces need to be applied in concert with the constant physics tick, are just not malleable without recompiling the engine. It’s a big step, but an unavoidable one.
The Source
So why GRIP, why all this business with the flippable cars and mental speeds that gives us coders such a belting headache? One word. Rollcage.
I was lucky enough to work on the Rollcage games, pretty much at the birth of my game coding career. The first one at least, was a real joy to work on. A great team dynamic, idyllic working location, exciting game concept to develop but best of all, a fantastic press reception. Getting just one magazine cover back in the day was no mean feat, saved only for the very best games. But to get 3 or 4, well that was just unheard of. We felt proper special and no mistake, even if we were just regular guys having fun, as this fake poster shows quite well …
It’s interesting to compare the development of that game and this, as they’re obviously very similar to each other, but have been developed in very different ways. Rollcage was designed for the original PlayStation, which I’m sure some of you will remember had just a couple of 33MHz processors and meagre 3MB of RAM. We had to work bloody hard to get good performance out of that thing. And strangely, equally as hard to get similar performance out of the PC version with a 200MHz processor and a 3Dfx card, even though both SKUs shared a huge amount of code in common.
Almost every line of code in Rollcage was written with an eye to efficiency to achieve the frame rate we were aiming for (which in fact we didn’t quite hit) – it was a constant concern throughout the entire development. Now of course, with UE, we don’t really have to care about performance in that way at all. It’s all buried within the engine and most of our performance concerns are with how we use it – which lights should cast shadows and that kind of thing.
The like of blueprints were just a pipe-dream back then, and you can forget dynamically reloading game code transparently within an Editor. We almost take these things for granted now, but they’re massive productivity savers compared to the way it was way back when. With a very arcane editor that you could only design with, some build of the game that could often be weeks old that you had to test with, no coding or scripting ability of any kind – the artists and level designers had a very hard time indeed. And coders of course, had the usual edit / compile / run cycle that was equally lengthy and often completely removed from that of the designers, so your test data could be just as old as the designer’s test build. It was another world, and a frustrating one. I much prefer the one we inhabit today.
It’s telling that even in 1998, when code teams were reasonably small compared to those in following years; Rollcage had six coders working full time on the game. While GRIP, the more ambitious game, will require just one and a half (but don’t ask me to define the composition of the half).
Until later fellow devs …