We're Not Ride To Hell
By Ian Fisch:
Recently a game called Ride To Hell:Retribution was released, and it shares some similarities in theme and concept with Road Redemption. Fortunately, that’s where the similarities end.
Ride To Hell has been hailed by many publications as one of the worst games ever made, and a shoe-in for worst game of 2013. It scored a 1/10 in eurogamer.net, the site I usually trust to give the most accurate review scores.
So the big question is ‘what went wrong’? Perhaps a follow-up question to any game studio is ‘how can we make sure we don’t make the same mistake(s)’?
Fortunately, Road Redemption team members have been involved in quite a few big studio projects, and can spot the signs of poor planning, poor scheduling and unfocused design, just by looking at the end product.
What Went Wrong?
It seems pretty clear that the original vision behind Ride To Hell was to make a very large game. It was set to have an open world, a complex story involving many cinematic sequences, cover-based 3rd person shooter combat, and vehicle-to-vehicle motorcycle combat. This last element is something it has in common with Road Redemption and the Road Rash series that served as one of our main inspirations.
The final Ride to Hell product contains what seems to be remnants of each of these components. Pieces of the open world environment show up as small, discrete areas. Cinematics are there, but they’re glitchy and poorly-executed. The 3rd person cover-based shooting is essentially broken. Finally, the motorcycle combat is little more than a disengaging series of quick-time events.
So how’d it all fall apart?Having worked on similar projects, I have a strong sense that the Ride to Hell production team scheduled different people to work on each of these components, all at the same time, rather than focusing on one component until it was polished and then moving on to the next one.
This is not how you should schedule the production of a game, unless you’re making a sequel that’s very similar to the previous game in the series (think Madden Football or Assassin’s Creed).
Developing your game via many separate pieces that you plan to bring together in the end puts you in the very risky position of having none of them finished in time.
Putting many people to work on many different tasks creates a lot of waste, and puts a lot of unnecessary stress on the people that are doing the most important thing at the time: finding the fun.
How Things Go Wrong
A concrete example of what I’m talking about is a game I made for Pyro Studios (makers of the Commandos series and Planet 51). They had recently finished a big console release and immediately started on their next game – a 3rd person action game that was never released.
The studio had grown to 100 employees at this time, all of whom were necessary to complete the game they had just released. They had the choice of laying off a large number of those or trying to put all of them (tools programmers, physics programmers, AI programmers, level designers, 3d artists, 2d artists, animators, etc) to work on this new project.
They decided on the latter – working all 100 into the new game’s schedule rather than firing them. This decision ultimately doomed the project.
The decision resulted in making it so the people finding the fun were constantly distracted with tasks whose sole purpose was to ensure that other team members weren’t being paid to sit at their desk and wait for something to do.
For example, as I was programming the game’s gun aiming controls (joystick dynamic sensitivity algorithms), I was taken off of the task to implement animation triggers (bits of code that tell specific animations to play).
The first task, pinning down how aiming a gun feels to the player, is absolutely crucial to finding the game’s fun. The second task – the animation triggers – was not. We could analyze the gameplay just fine using placeholder code that changed the player’s avatar color when he pulled the trigger on the gun.
So I spent about a week implementing animation triggers solely so the game’s animators had something to do. Finding the fun would have to wait a week.
Later on in the project, I was scripting the basic enemy AI for the game’s vertical slice (basically a very early game demo) that we were going to present at E3. Again, I would argue that good enemy AI in a 3rd person shooter game is a fundamental component of the game’s fun.
Since 3rd person AI is intricately tied to the environment that AI lives in, I was constantly changing the demo’s level geometry as I perfected the AI: making a chest-high slightly higher, making a corridor slightly wider, etc.
At this time, the level consisted of only basic geometric shapes. The level’s furniture was represented by cubes. The level’s corridors lacked wallpaper, light fixtures, wooden moldings, etc. This was fine for me, because none of those aesthetic details affected the AI or the gameplay.
Then one morning my producer walked in, and told me that I was to make no more changes to the level’s geometry. The art team needed something to do, so they were going to add all those little details to the level.
After explaining my task, I was granted permission to make changes to the geometry, but now instead of just moving a cube that represented a desk, I had to move the cube colliser, the desk 3d model, and all of the 3d models on top of the desk (bottles, lamps, etc).
If I wanted to actually change the dimensions of the desk, I’d get an exasperated look from the artist who had to respace the desk’s legs in 3d studio max. He’d also have to adjust the game’s lightsources to get the proper shadowing for the adjusted desk.
This ended up making my task of developing a fun AI take 4x longer, as I was accustomed to making hundreds of tweaks to the level’s geometry each day.
These same distractions also came from programmers working on other components.
For instance, my ex-worker was fine tuning the player’s on-foot locomotion (running speed, acceleration, etc). This is absolutely essential to finding the game’s fun. He was taken off the task by a request from the programming team that was working on the game’s inventory system.
Ultimately the game progressed to the point where world builders were making whole levels, sound people were recording audio for cutscenes, and animators were creating in-game cinematics. Yet still the fun had not been found.
When we presented our fun-deficient game to publishers, no one was interested in bringing the game to market. After more than two years, the project was mercifully cancelled.
The Road Redemption Difference
Our strategy for developing Road Redemption is simple. We find the fun and then expand out from there.
In practice, this meant that everyone on the team worked to implement the core mechanics of driving a motorcycle on a track, allowed them to polish it until it was fun to simply drive around an empty level, and then moved onto the next element.
The next most important element was the melee combat (bats, pipes, chains, etc). Once again, we all worked together to make this great and fun and polished. Same went for gun combat and so forth.
Not everyone on the team was needed for these tasks. Those that weren’t needed were usually put on other projects, so not to be a drain on the studio’s resources when the project wasn’t ready for them.
Once we have a fun, balanced play experience, with a smooth difficulty curve, good pacing, and tight level designs, will we move onto stuff like cinematics, and wish list features (driving an 18 wheeler against a herd of enemy cycles, for example).
In the event that we run out of time and/or money, as most projects do, we’ll still be ready to release a fun, polished experience that’s sure to make people happy.
Then we’ll put the release profits into implementing more features and making the game even better.
Don’t Blame Ride to Hell’s Developers
Ride to Hell was nowhere close to finding the fun when they ran out of time/money. Rather than concentrating on 3rd person shooter combat, motorcycle battles, an atmospheric open world, or great cinematics, they tried to do all four and the project collapsed.
So whose fault was it?
I wouldn’t hold any of the programmers, artists, scripters, designers, or QA people who worked on Ride to Hellaccountable. Most of them probably knew the game was terrible as they were making it.
Most people in the game industry have worked on bad games. It’s just a fact of life. When you’re just one developer on a team of 50 or 100, there’s not much you can do to change a game’s overall direction.
Even the people ostensibly in charge (the producers, team leads, and creative directors) often have their hands tied too. When the email comes down the pipes from an unseen corporate studio boss, you either make the game that they want, in the way they want it, or you argue with them until you’re fired.
It’s nice to be indie and have an opportunity to do it the right way.
