Special Edition= $70

Immediate access to the alpha version (Windows PC only - we're working on the other versions!)
​
Access to all future versions, including Steam Early Access

Steam key upon release on Steam (officially greenlit October 2013)

Name a character in the game​
​
Digital copy of the Road Redemption concept art book
​
DRM-free copy of the Road Redemption official soundtrack

Your name engraved in the Gang's Clubhouse wall

In The Final Version

Take your gang on an epic journey across the United States

Seamless, procedurally generated world, that's different every time you play

Tons of weapons including swords, chains, cattle prods, grenades, shotguns, and many many more

Earn money, new gear, and equipment to improve your character

Battle enemy gangs, cops, and the military, all with state of the art AI

Local splitscreen and online multiplayer play

Motorcycle Physics In Road Redemption

By Ian Fisch:

I thought I’d share a little bit about motorcycle physics in Road Redemption.Even if you’ve never taken a physics course, you still might find this interesting.

Have you ever wondered why leaning, while riding on a motorcycle, makes it turn? Clearly turning the handlebars, which rotate the motorcycle’s front tire, should change the motorcycle’s heading. But why does tilting the bike frame have the same effect? This had me puzzled for a while. If I’m leaning left, but both tires are still facing forward, why should the bike TURN to the left? Shouldn’t it just keep moving forward in a straight line? What’s going on?

It’s actually quite simple and is due to the shape of a motorcycle’s tire. We tend to think of motorcycle tires as having the shape of a thick slice of a cucumber, with the edges being completely flat. Indeed, if this were the case, you would NOT be able to turn that bike by leaning.

In reality, motorcycle tires are shaped like the image above. As you can see, the tire is tapered. Its circumference is larger in the center (red line) and smaller on the sides (blue line). This is important.

Imagine we’re riding our motorcycle and we lean to the left. This has the effect of making the left edge of the tire come in contact with the road. So every time the tire makes a rotation, its center (large circumference) covers more ground than its left edge (small circumference).

Hence, the entire bike actually ends up turning to the left even though both tires are still facing forward.

So that’s why you turn left when you lean left.

So how does this affect Road Redemption?

Basically it doesn’t. We’re using the Unity engine wheel colliders for our tires, which are shaped more like the cucumber slice tire. Of course, these colliders are invisible so the tires you see in the game still LOOK like actual motorcycle tires.

We chose to go this route, rather than create our own custom wheel collider, because the Unity wheel collider is great for so many other things, and honestly, it wouldn’t be worth the added strain on the CPU to simulate this kind of thing realistically anyway.

I can’t imagine that any videogame bothers to accurately simulate the physics of a motorcycle tire, since you can achieve the exact same result from faking it, with less work on the CPU.

So in Road Redemption, when your biker leans left, his bike turns left, but it’s the rotation of the handlebars/front tire that actually make this happen.

This is just one of the many physics manipulations we do to make driving in Road Redemption feel “right”, which I’ll talk about in future posts.

The Road Rash Series does this all the time. Don’t believe me? Well, in the most popular iterations of the Road Rash series (Sega Genesis/Megadrive, Sega CD, 3dO, and the first title on PS1) you can’t actually TURN your bike at all!

You can only strafe, right and left, along the bottom of the screen. The game gives you the illusion that you’re turning. In fact, if you hold the accelerator, and let go of the steering controls, the game world will actually turn, on its own, under your tires!

Funny how what’s fun and what’s realistic can often be at such odds.
Sumber Dev Blog

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.
Sumber Dev Blog