Update

GeneRally 2 Update

• GeneRally 2

Finally, the update you’ve been waiting for…

There are two major things that have been going on recently in the development process: rewriting the track loading and optimising processes; and improving the car physics and AI. I’ll leave Markku to update you on the physics and AI in, probably, another blog post, but will cover the other bit myself, now. On top of this, we did make a move across to Unity 5, but as those familiar with the process will know, it was a relatively painless process, but has had some significant performance and visual gains.

Firstly though, we’ve finally enlisted the help of someone to work on our 3D art assets again. After Kimmo moved on, we were missing a fairly significant skill in any modern game development process: that of someone who doesn’t make a complete hash of things every time they open a 3D modelling tool! We’re just working through all our 3D assets again, redoing them and improving them according to feedback we had from you guys over the past few years, and this will enable us to show off some visuals again at some point in the future.

I mentioned a bit about the rewrite of our track-loading process above, and whilst this may not seem massively important to some, this really is something we really needed to get right once-and-for-all if we wanted the car physics to be reliable, regardless of future track-maker’s decisions. One thing we really want to shy away from is constantly changing physics and AI implementations when things are already in your hands, because that leads to people feeling like the skills they’ve built up, and the knowledge of AI decision-making, is worthless. One of the crowning glories of GR, at least from our perspective, is that you can drive it with confidence, knowing how other drivers are going to react, where the limit of grip is for an individual car, etc. Ultimately, we just weren’t happy with the fidelity of the track importing and underlying representation in the KS demo, so we went back to the drawing board.

The reason this makes a difference to drivability is all to do with how we handle the difference in physical size of the terrain (broadly can be thought about as the land-map size) and the size of the height data (i.e. the height map size). As many of you will be aware, the land map in GR1 is eight times larger than the height map – this is done largely as a shortcut to ensure that there are no major changes in height that could cause physics oddities, and also to ensure that there’s minimal distortion of the land textures across any slope (as there are no truly vertical slopes). GR1 height maps are gently smoothed out during this process to provide the terrain you see in-game – and we’re doing the same in GR2 (but with slightly higher resolutions for both land and height). Broadly, the rewrite of our loading mechanism makes the terrain smoother and more predictible for the physics engine to handle and, thus, makes Markku’s job a lot easier when it comes to developing a consistently-performing physics solution. Some of the problems we’d been experiencing with the KS demo were exaggerated by a series of very, very small bumps in the terrain upsetting car handling. Markku’s attention-to-detail in modelling a real, working suspension in GR2 means that we have to pay attention to all the small things that can upset that finely-tuned balance. We’re hopeful that as we implement some more cars, with different handling characteristics, that the suspension model will really begin to shine.

Along with this, we’ve implemented a feature we’ve had a number of requests for: height-map scaling. This allows the track maker to specify (within a given range) how high the highest point of his track is, and how low the lowest point of his track is – resulting in a very vertical track with lower fidelity, or a much more detailed but less vertical track. As an example, here’s a comparison screenshot of the same track (shown in the terrain-only view used for previewing in our editor), just with a different height-scaling property (one at the very highest end and one within a more normal range) – furthermore, we’ve also included the corresponding terrains with minimal smoothing applied to them:

As a side-effect of this necessary update, and because I can’t resist a bit of optimising, we also slashed loading times to (potentially) quicker than GR1… even with a much greater level of detail associated with each individual track. We do still technically have a loading screen… but at this point, I’m not sure you’d ever see it in every-day use (though I’m sure we can find a way to sub-optimally load something, somewhere down the line…) – last I checked, it wasn’t even up long enough to render for a single frame during track loading.

Next on the agenda is to implement a new feature we have with regards to object placement: curve-based placement. We’ll be allowing walls to be dynamically created along quadratic Bezier curves, and placement of individual objects, similarly, with a given spacing. This should hopefully give a few more options to track makers, as well as reducing the amount of time that needs to be spent carefully placing individual walls!