Mountain Bike Adrenaline is a Playstation2 sports game developped by Fresh3d (our company) and published by Nobilis in 2007.
How it all started
Yet another sports game
After the release of Wild Water Adrenaline, and its relative local success (given the smallness of the publisher), we started working on the second sports game, this time about mountain biking. Indeed, the initial contract stated we were going to provide four action game titles, using the Salomon branding. Because mountain biking is a much more popular sport than rafting, and because other competing product existed, the pressure was much higher and despite a similar budget (250 K Euros) Mountain Bike Adrenaline was going to be a larger and more difficult project to make for our small company.
It's no secret the game had terrible reviews. But when I read comments, I often see people wondering why someone can make crappy games like this. Let me get this straight. The average PS2 game budget at the time stood at about 2 millions, having only 1/8 th of that budget you realise we had to cut corners and that inevitably led to an unpolished, sloppy game. Add to that time pressure and virtually no support from a small publisher with thin pockets and you have a recipe for failure. Not everyone's failure. The game paid the wages, but it could have been so much better with a little more love, money and above all, time. These were called budget titles for a reason.
The game features a simulation of the physics of a bike, with separate front and rear breaks, torque strength controlled through manual or automatic gears change and the ability to jump while holding your bike. But if you've played this game, chances are that you do feel the physics sucks big time :P
When we started working on the design, we choose not to follow the arcade orientation most of the competitors were going, specifically we wanted open levels to explore, we wanted to reflect the freedom of free riding, as opposed levels designed as linear tracks. We didn't have the budget and genre experience to compete with those other games and had to be outsiders.
To provide that sense of freedom, we chose the path of simulation, and that required the use of a physics engine. At the time, the only commerically available physics engine for PS2 and other platforms was Havok. It was already a very capable physics engine, even back then, but just licencing it would have swallowed most of our tiny development budget. So we picked ODE, a free open-source dynamics engine and recompiled it for PS2. It was slow and buggy, and Yann and his team did their best to make it work in our engine, and try not suck up all the performances, by optimizing some of its parts.
In the end, we had a physics engine that unfortunately had some inhenrent flaws, such as some very irritating sticky collisions (most notably in trees) that many people complained (laughed) about. On top of that, my mistake was to put too much effort into trying to emulate real obstacle behavior by putting too many physical collisions on smaller objects you could have gone through without noticing. It would have been less realistic, but a lot more fun, this is a videogame after all. Lesson learned.
Another problem was related to character animation most people find wacky and sometimes broken. Actually the characters on the bike are fully physics driven, they are basically dolls with real-time inverse kinematics on both arms and legs. This is again an example of a bad good idea. It was a fairly advanced technology for the time, but since we had no tools nor time for an artist to tweak it to make it look good, we were left with bad looking animations. Even when the tech under the hood is fairly advanced, nobody cares, only the results count.
If you can go past those limitations however, I think it's fair to say the game can be quite enjoyable at times. Most journalist however seemed to think that it was a show-stopper and awarded the game with abysmal reviews. Some people however, moslty those who are actual mountain bikers, played the game enough to go past the sticky collision problems and funny animation and seemed to rather enjoy the game's open tracks and the bike's physics.
On a personnal note, I think if you make the decision to do a game based on physics and the physics is broken, then you innevitably get a crappy game, end of story. For all the good stuf there is to say about the making of this game, and all the nice stuff I learned along its making, I feel it as a big failure, whatever the complex reasons leading to that result, as mentionned above.
Like it was the case for our previous game, we chose four countries, each with a specific set of interesting spots and style. Then I started designing the levels by looking at video footage from all those countries, I grabbed some images as reference for designing the maps. I then laid out huge images in Photoshop with tracks, obstacles, forests and whatnot that were basically 2d templates for the 3d levels.
Here's a reduced version of a levels template design, you can see the full versions in the galleries section below.
One of the challenge of this project was to create large enough levels so that we would be able to include several tracks into them to expand gample play while keeping development within budget. We also wanted to have some free ride modes were the player would have been able to explore the map freely.
For our previous game, we were using instanciation of 3d tiles to create a level. This limited the shape of the terrain as the tiles had to match to create a continuous surface, and were painful to edit.
For this game, we went for a quad mesh that would be tesselated in realtime to provide smooth surface and level of detail. Dynamic tesselation was a very advanced feature for the time.
Above: The terrain is modeled using quads.
Right: Tileable textures are applied to each quad. Quads are then tesselated dynamically at runtime to create smooth surfaces.
However, smooth surfaces were not enought to create convincing rocks and bumps, so by leveraging the power of the PS2's vector units, we included vector displacement mapping in the form of tiny 32x32 sculpted grids to produce displacement values. This was an incredibly advanced feature, only made popular years later with the advent of DX11 capable hardware. Looking back at it however, I think it was a mistake to put so much effort into a specific rendering technology. I think ressources should have been placed on the physics and gameplay code first.
Because the performance was limited, we had to reduce tesselation with a steep curve according to distance, and that also created a lot of ugly poping in the geometry.
Left: Tesselated quads are displaced using a vector map to create more detailed shapes.
In order to produce the most possible realistic terrain textures within our constraints I chose to start with photographs of various ground materials and assemble images as tiles to map to our quad terrain system.
After looking through the internet for ground picture material, it became quickly evident I would have to do it myself as there was no quality source material available. Indeed, to create ground textures, you need to be way above ground level in order to cancel perspective, otherwise your resulting texture is distorded. Ideally you should place your camera at an infinite height with an infinite zoom to flatten the image. Not very practical, but in general, let's say the higher the better.
This creates two major challenges that need to be overcome. Lifting the camera at an ideal height, and triggering the image capture. This, I suspect, is the reason why such images are so rare, even today.
First I had to devise how to trigger a camera from a great distance. Some camera provide IR remote control, but the range is small, and it doesn't work well outdoors under bright light conditions.
I picked a garage door RF remote circuit with up to 100m range, and built my own remote control system for a small (back then) compact camera.
Above left: hacking a Pentax camera to add HF remote control.
Above right: the final remote controlled camera packaged and ready to fly.
Lifting a ~600g camera system (camera + remote control system) into the air requires some traction that not many technologies could provide at the time. I looked first at kite, but the need for regular wind made it a no go.
It came to me that a blimp was the better solution, so I ordered one with enough volume (4 cubic meters) to lift 1 Kg. This one is made of NASA-grade material to retain the ultra fine molecules of industrial-grade 99.999% pure Helium, a rare and VERY expensive lighter-than-air inert gaz. Call me crazy and all, but this was as much fun to build than it was to use :P
Above: the remote controlled camera attached to the flying blimp
Right: me with the blimp attached to a security 2KG weight at the end of the line. The blimp can go as high as 100m (300 feet).
After some rather successful shooting sessions, I had to stop using the blimp because it was quite impractical to transport, very expensive to refill, and the day had to be clear with no wind at all, or the blimp would start to oscillate and make blurry pictures. I kept the remote control system and attached the camera to a 5m telescopic mast. A much more efficient and transportable system that I'm still using to this day.
Above: two examples of textures captured with the blimp remote controlled camera at about 20m high (60 ft)
Ugly graphics ?
The first time I heard people saying the graphics for the game were ugly, I was rather shocked to be honest. I tought my environment textures were pretty good, and the models and environments quite detailed for a budget PS2 title.
But then I realized they were not talking about the content, they were talking about the rendering quality. Ugly pixelated rendering. Indeed, we had the game running in interlace mode which made the game flicker, and sometimes losing half the resolution when there was the smallest slowdown.
On top of that, we didn't have any textures mip-maps at all ! Which meant 90% of the pixels on-screen were getting ugly aliasing (not to mention lost cache performance). And it showed. I really don't understand why we didn't put some effort into a decent texture pipeline at the time.
Have a look at these WIP of each of the levels. You can see the rendering exhibits a lot of disturbing aliasing and geometry poping.
The musics for the game would be provided by the publishers, but we had to make all sound effects, a task I usually like to handle when the budget doesn't allow for outsourcing.
For all the stock sound effects I have in commercial libraries, specific sounds such as the one made by a bike had to be created from scratch. So I took my Marantz solid state recorder and a stereo condenser microphone and went for some sound capture sessions.
I captured tons of sound material while riding my mountain bike, only a small portion of which features in the game. I also had an old rusted bike in my garage that I sent several times at full speed into a wall for that perfect crash sound. That was a lot of fun.
Right: me getting ready for a sound effect capture session
Bikes and characters
Salomon provided us with a lot of reference material for the bikes and for the garments and accessories. Three internship artists worked on modeling the various bikes while Francois Debue took care of the character modeling, rigging and animation. Cedric Storm also helped with additionnal modeling and texturing.
Left: some of the source materials from salomon included 360 degrees shots for garments, accessories and bikes.
Map design gallery
Reviews and articles
Probably the most interesting, in-depth, and honest review available: Let's play Mountain Bike Adrenaline.
Here's part 1:
And here's the last part, I leave it to you to check all the parts in-between, if really you don't have better things to do :P
- After the release of the game, we had troubles to get royalties reports from the publisher (sounds familiar?). The game was being quite succesfull in the US through a local distributor there (Valcon), and we were not seeing any return from those sales (we estimate global sales standing at about 450k units). We required an audit and discovered what we claim were hidden profits. We went to court and the case is still running as of today, although because Nobilis went bankrupt since, chances for us to see our money back are very thin.
- The year after the initial PS2 release, we were asked to make a PC version of the game, moslty for eastern markets. Unfortunately as the budget was even more ridiculous, the programming team ended up packaging pretty much the PC prototype that was used during development. It featured an earlier version of the engine without dynamic shadow, LOD nor tesselation which makes the game stutter even on decent configurations and makes it moslty unplayable.
Engine programming : Yann Robert, Gregory Leblond, Cedric Guillemet
Game programming : Stephane Menardais, Yann Robert
Physics programming : Guillaume Raffy , Yann Robert
Additionnal programming : Flavien Lefebvre
Game Design : Christophe Bauvir, Stephane Menardais
Level design and environment art : Franck Sauer
Characters modeling, rigging and animation : Francois Debue
Additionnal modeling and texturing : Cedric Storm, Michael Geimer, David Lecrinier
Bikes modeling and texturing : Michael Geimer, David Lecrinier, Christophe Forton
Sound design : Franck Sauer
How to play the game today
You can probably get a copy off e-bay these days. Also it is quite cheap on Amazon.