Today we’d like to give a little update on the progress of GR2; an in-testing update for GR1; and some information about clarifying our expectations and plans for updates going forward. With that said, we’ll go through that list in reverse order.

Updates Going Forward

First of all: sorry. Those of you who’ve commented about how this is an unacceptably long period of time without an update are right. We don’t necessarily agree that we “owe” any updates to anyone, but we’ll admit we’ve somewhat shot ourselves in the foot with this and waited for something we’d consider interesting enough to blog about, rather than something you’d consider interesting enough for us to blog about.

Whilst we’ve tried to convey in the past that progress on GR2 is both inconsistent and slow, we’re aware that large periods of time where nothing is said is less-than-helpful. To be honest with you, the previous blog post was somewhat out of frustration at all the negativity and constant questioning of our characters over what is, ultimately, a video game. Of course, the Internet affords people the anonymity to be pretty hurtful with little-to-no recourse, but at the end of the day, sat at the other end of your comments, are two human beings who, above all, just want to make a fun racing game. There’s a lot more we could say about this, but we’re not sure it’d do much good – ultimately, all we’re asking on this point is that you, by all means, stay critical of our development process, time between updates, speed of development – but try not to turn those things into character judgements: as those are, for us, incredibly demotivating.

We’re going to try and post a bit more frequently regarding what’s going on (disclaimer: there are lots of valid intervals between “daily” and “once every 1.5 years”). For starters, we’re rarely working in parallel at this stage of the project, as much of what we’re working on is dependent upon other features and implementations provided by the other person. For a recent example, I (James) recently rewrote our track loading to provide some improved fidelity on our height maps and to reduce the memory footprint, as well as ported our entire project across to Unity 5 – these tasks had to be completed before Markku was able to implement his suspension and AI updates to improve handling and provide AI that can also race well off-road, as the change in height map fidelity significantly affected the way the cars behaved. (On the plus side, the car physics feel better now than they ever have done, and most of the little annoyances folks reported from the KS demo are well and truly gone.)

Something that exaggerates this development time yet further is simply the time we each, individually have available to commit to the project. If I have a few hours a week, but a rewrite of a major system takes 30 hours, it’s going to be at least 2-3 months before I’m done, and Markku can pick up work again. Whilst this is very much a completely-inefficient way to develop on a broader scale, given how little free time we have available on exactly the same dates, and exactly the same times, makes it a far more viable approach than attempting to pick the odd days we can work together in parallel. Features that, in a full-time work environment might take a couple of weeks are taking us 6-8 months – but I think we’re approaching the end of the list of things we need to accomplish in this way, after which we’ll be able to move on working on things that aren’t dependent upon each other, which will help us to work a lot more quickly. Of course, some will be thinking at this point: “but project X took only Y months and that was much more straightforward” – and that’s no-doubt true, but we’re only able to work to the time-scale afforded to us by our own available time.

For those hoping for a commitment to a testing phase, release date or otherwise for GR2: we simply can’t commit to those at this point in time – but we are getting closer (see below).

Going forward, we can’t promise that development updates will be large, or even particularly interesting, but we will attempt to keep you updated to some degree or other on what’s going on. In between work and family, it’s often hard for us to find the motivation to spend what little development time we have on making a blog post instead, but as many of you have pointed out, they don’t all need to be essays…

GeneRally 1 Update

I know, I know, we said we’d not be putting out another update to GR1 – but we simply couldn’t resist trying to solve a bunch of issues with timed races, and a few of the outstanding bugs that we really weren’t happy with being in the game if v1.2c was to be it’s “final” state. The update is currently undergoing testing, but a preliminarly list of fixes are as follows:

Updated to the VS2015 runtimes, to fix a few minor issues with Windows 10 support. The minimum requirements for the 2015 runtimes vs. the 2010 runtimes are identical (according to Microsoft), so this shouldn’t cause any issues for anyone who can currently run the GR1.2 branch of updates.

Fix: Timed races now resume properly after a save (resulting in a small change to the save-game format, we’ll aim to update relevant tool creators before launch, so they can have updates ready as appropriate).

Timed races now resume properly after a save (resulting in a small change to the save-game format, we’ll aim to update relevant tool creators before launch, so they can have updates ready as appropriate). Fix: Autosaves no longer crash on load.

Autosaves no longer crash on load. Fix: Game no longer crashes after races that have no laps under 60 seconds.

Game no longer crashes after races that have no laps under 60 seconds. Fix: Various small timing issues with timed races (caveat: due to the timer precision being used, there will still be a very, very small variation in displayed times when saving/resuming, but the actual length of races will not be affected – it’s ultimately not possible to fix this without altering the laws of space and time, and we can’t even get a blog post update out inside a year…).

Various small timing issues with timed races (caveat: due to the timer precision being used, there will still be a very, very small variation in displayed times when saving/resuming, but the actual length of races will not be affected – it’s ultimately not possible to fix this without altering the laws of space and time, and we can’t even get a blog post update out inside a year…). Fix: Hopefully fixed the “no supported resolutions” problem on certain GPU and monitor combinations (for those interested, turns out nVidia/AMD decided that on some cards it was no longer relevant to report supported 8-bit modes from the driver on certain cards… so a bunch of cards that do support those modes just overnight stopped reporting them to the game… we’ve had to make a few assumptions in our work-around, but we were able to reproduce the issue before, and it’s at least fixed on the machines we’re able to test on).

We’re not yet sure what else will go on to the fix list, but this is what’s currently in testing (on this point, appropriately for his username, Crono has been immensely helpful in tracking down the timed race issues). We’re hoping we can have this out to you within a few weeks – but that’s dependent upon what testing turns up. We’re also hoping to find a reasonable solution to the limiter issue to include in this release, but that’s still up in the air. It’s possible we’ll release this to a few of our frequent bug-reporters, to try and ensure it’s as bug-free as possible before release, but so far, testing is going well.

GeneRally 2 Update

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!

In Conclusion

Ultimately, we hope that this post has been at least a little helpful in setting the record straight regarding GR – and we will very much endeavour to make our next blog post a sooner than Q1 2018

– James & Markku