Gamasutra: The Art & Business of Making Gamesspacer
Sponsored: The World of Just Cause 2 - Using Creative Technology to Build Huge Open Landscapes
View All     RSS
August 1, 2014
arrowPress Releases
August 1, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Sponsored: The World of Just Cause 2 - Using Creative Technology to Build Huge Open Landscapes

May 16, 2013 Article Start Page 1 of 6 Next
 

Avalanche Studios was founded over ten years ago out of passion for open world gaming. But for me it actually started back in 1984 when playing Ian Bell's and David Braben's classic game Elite for the BBC Micro Model B. I was astonished by the way they could create a whole universe with 8000 unique planets that you could travel freely between, on a machine with just 32KB of memory and with a CPU running at 2 MHz. It was a completely different experience from all of the platform games and sidescrollers of the time. Mesmerizing.

Bedroom Space Cadets

My two brothers and I built a spaceship cockpit in a closet at home using old discarded machinery that our dad brought home for us from the university at which he was a professor. In the center sat the BBC and a joystick. Being the oldest brother, I was obviously the highest in rank, and in charge of the joystick, while my brothers were commanded to sit with a finger on the countermeasure keys, ready to EMP any incoming enemy missiles, or in worst case, activate the escape pod. Pressing too late often meant instant deportation to the vacuum of space -- the bedroom outside the closet. Luckily for me, that harsh penalty didn't kill their passion for open world games, and we eventually started experimenting in making our own.

We soon discovered fractals and how procedural techniques could be used to achieve experiences far greater than the typically perceived constraints of the hardware would allow -- just like Braben and Bell had done several years earlier. Living in the countryside in the north of Sweden, our interest became trying to replicate the landscape outside of our windows using these techniques. Many years (and much coding) later, a procedural landscape demo attracted the interest of an Eidos producer, and the Just Cause franchise was born.

Space and Beyond

Fundamental to the gameplay of the Just Cause series is the ability to move freely in an enormous world. Long draw distances are vital for the Just Cause experience, since the player's progression and motivation is much guided by visual input. We wanted the player to see things in the horizon and become interested to find out what hides behind that distant mountain range or on that remote island. The Avalanche Engine is developed from the ground up to cater to sandbox gameplay in huge open worlds with large draw distances.

There are many technologies required to achieve this, making it very difficult to retrofit open-world functionality to existing game engines. This article will describe one of those techniques, namely terrain rendering. More specifically it will describe how the terrain mesh is generated in the Just Cause games, and how we were able to draw a 32 by 32 kilometer world with full draw distance. It will describe our geo-morphing technique that made the long draw distance possible while at the same time eliminating level-of-detail "popping." It will also describe the resource management techniques and data compression required to efficiently stream and recreate the large amount of data required to generate the terrain meshes.

The goals for designing the terrain system in the Avalanche Engine were:

Memory efficiency. The original Just Cause was released on PlayStation 2, so we knew that we had to have a very tight memory representation to make a world of that size fit. Data compression and procedural techniques would be required.

High performance. There are a lot of things to render in an open world game so the terrain system cannot consume much of the available processing power. We knew that static vertex buffers would have to be used to achieve this, which ruled out some terrain rendering techniques.

High visual fidelity. Meant high resolution, no level-of-detail popping," large draw distance, etc. Again, especially considering the other two goals, procedural techniques would be crucial to accomplish this.

A typical Just Cause 2 vista

The same scene in wireframe. Note the increased resolution at the shorelines and other complex regions. 


Article Start Page 1 of 6 Next

Related Jobs

Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States
[08.01.14]

DevOps Engineer
Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States
[08.01.14]

Animation Programmer
Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States
[08.01.14]

Server/Backend Programmer
Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States
[08.01.14]

Lead Online Engineer






Comments


Mark DeLoura
profile image
This was a great article, thanks!

Linus Blomberg
profile image
Glad you liked it!

/Linus

Twitter: @BlombergLinus

Chris Birke
profile image
I second Mark's opinion, and I especially liked the bit on storing the x/z z/x pair.

Ferruccio Cinquemani
profile image
I didn't understand most of it and still liked it. :)

Nick Harris
profile image
I very much enjoyed Just Cause 2 and found this article to be invaluable, despite only understanding about half of it. Hopefully, when I eventually come to program my own terrain generation system I won't face the same awkward memory and DVD seek speed constraints that you overcame. I too was amazed by Elite's enormous scope back in '84, but in truth I found it to be too hard and lacking in the ability to colonize other star systems: whether it be building a moonbase, or a home inside an asteroid, or a city on a planet with an atmosphere. Orbiting space stations weren't enough for me and I quickly became frustrated that I couldn't walk around in them, shopping for cheap parts to fix my ship up with. It had Commerce and Combat, but the addition of Colonization would lead to both Culture (Colonization via Commerce) and Conquest (Colonisation via Combat). Anyway, not bad for 20KB.

Indeed, the game that inspired me at this time was Paul Woakes' Mercenary a year later in which you crash land on a planet and then have a number of adventures within that city as you seek a way to escape. This type of open world gameplay was new to me back then and may well have invented the genre - certainly, more so than Grand Theft Auto. The later sequel Damocles had you flying from planet to planet within a star system, giving a sense of enormous empowerment. This predates Frontier: Elite II by several years, which struck me as being too big, dry and purposeless. Flavien Brebion's Infinity (The Quest for Earth) is technically impressive - but ultimately as cold and detached as Space Engine or the Universe Sandbox. At times EVE Online veers too close to being as boring as a spreadsheet with a fancy sit-back-and-watch screensaver attached. The launch of Dust 514 for the PS3 just highlights the lack of cohesion in the game - you really ought to be able to land on a planet in your own ship rather than delegate the fun to some mercs and pay for the priviledge in the process. For a long time space games were out of vogue and it is interesting to see so many get funded through recent Kickstarter appeals, including Elite: Dangerous - which, in later versions, promises to let you land on planets.

However, as someone keen on this genre and finding nothing in the market since the release of Damocles, my yearnings for an adventure game set as much on the surfaces of astral bodies and inside spacecraft as much as between the stars drove me to work on the tools I thought I would need if I were to attempt to write such a big game by myself. Suffice to say I have put decades of research into boosting my productivity. C++ horrifies me: such an awful mish-mash of poorly concieved features wrapped in an error-prone syntax. Substantial use will need to be made of both kitbashing (assembling complex models from phasing the geometry of "prefabs") and the procedural generation of those prefabs. Miguel Cepero's work Procedural World looks a lot better than I need my game 'Universe' to look. Indeed, I would happily accept the rudimentary charm of Damocles if that was all I could manage, after all there are a lot of other aspects to the game that I think are more important than its presentation... I don't like this modern trend of squandering computational resources on special effects that have no impact on gameplay, whilst physics and AI get short-shrift again.

So, finally I wend my way around to my question. How would I apply a terrain solution like yours that depends on square tiles to a spherical planet? I don't think Latitude and Longitude will work as that will stretch stuff too much and result in awkward triangles at the poles. An isocahedron-sphere is nice, but relies on triangles. Is a (bloated) spherified cube the correct approach? What happens to the horizon? Will it appear to curve with more altitude? Should I trust my instincts and just use polar coordinates and a heightmap centred on the core of the planet? Any advice or pointers to research papers would be appreciated. I'd like to read up on this subject now whilst I'm implementing my programming language.

Robert Schmidt
profile image
Reminds me of Thatcher Ulrich's work with Chunked LOD. I was hoping someone would implement something like that. I was never a fan of ambient occlusion. The first open world game I played was Operation Flashpoint and I was a bit disappointed that I could only see about 1km. I wanted to see to the horizon. I'll have to get your game to check it out. Now, could you create something like this for Unity?

Ian Stitzlein
profile image
I am curious how you handled shooting at entities further away on the terrain mesh. Did they exist on the top mesh, a sub mesh, ect? It would seem that it would be possible for the terrain to transition from one mesh to another, possibly causing a shot to miss, ect.


none
 
Comment: