Slashdot Mirror
A Look At the Tech Behind Burnout Paradise
Eurogamer sat down with Richard Parr and Alex Fry of Criterion Games about the evolution of the technology behind Burnout Paradise , and how they engineered a complex, open world across multiple platforms. "Criterion's method of exacting the most performance from the new architecture isn't so much about threading as such, it's all about parallelization. Rather than lump different game aspects onto different threads (where massive latencies can build as each processor waits for the other to finish its work), game code is highly optimized to make use of what processors are available at any given moment on whatever target hardware, and by choosing the all-important balance points, the experience is like-for-like on all platforms. High-level management code that is unique to each platform then processes the game code according to the hardware that is available." The first part of their Q&A session has also been posted.
This is more like an ad for their new DLC. TFA is very light on technical details.
The interview (as opposed to the article) is at least a little more interesting.
There is nothing fancy here but he is trying to explain about the distinction between between running five tasks at once (a classic "threading" model), and splitting one task into five work units.
Many common threading models in video-game engines do not reduce latency; eg, "render thread", "audio thread", etc. You get a big win from doing two or three threads, but after that your physics takes an entire frame, or your rendering takes an entire frame, and you bottleneck. No matter how many more CPU cores you throw at it, those fixed number of threads are not getting any faster.
Nine women can't deliver a baby in one month, etc etc.
Hardly groundbreaking, but still a nice achievement given the state of most video game engines out there today. Burnout Paradise runs at 60hz with very low latency between input and screen. That's worth some kudos.
Bailout Paradise? ;-)
No. There is some distance between "parallelism" and "threads". For example, SIMD instructions, are parallel, and have nothing to do with threads. On the other hand it is perfectly possible to have multiple threads that are not running in parallel (on a single processor for example).
See also: Threading/Concurrency vs. Parallelism.
i dunno what it actually means except from what little was stated above but anyway.
It means they've found a way to affect a paradigm shift by developing synergy and fostering a team environment.
SJW: Someone who has run out of real oppression, and has to fake it.
No...they can be in your house. They just need another system + TV + Network Connection.
Unstable Apps: Our Android Apps Don't Suck
I agree with Edgewize, and while it's a little less "on topic", I'd also add that this game was one of the best values for the dollar in games for my PS3, to date.
Unlike most new release titles, they didn't hit me for upwards of $50 as retail price, for starters. The game turned out to be more fun and playable than some of those $50+ titles, too. And after that, the value kept building because they regularly released updates to the game (such as adding motorcycles to it, a couple months after I owned it).
This is the way a console title SHOULD be, IMHO. The fact it was coded intelligently doesn't surprise me.
From article you link to:
There are different types of parallelism, and you and the blog article you link to define parallelism as strictly speeding up processes using multiple processors.
This is a false dichotomy. Parallelism at a process level allows a single program to run multiple bits of code in parallel of each other (instead of sequentially). Parallelism at the OS level allows processes to (seemingly) run at the same time, in parallel. Parallelism at the CPU-level or network/cluster-level allows you to speed up a task that would take longer sequentially. I fail to see why you'd want to restrict parallelism to only these last levels.
Threads, processes and clusters are (in my book) all means to achieve parallelism (simply doing stuff in parallel at a certain level), regardless of goal or the number of cores you're running on. But I guess it's all down to semantics.
This sig is intentionally left blank
The lack of splitscreen is, sadly, a design tradeoff for having a huge open world where you can drive anywhere.
In most level-based games, like past Burnouts, the whole level is loaded ahead of time. Splitscreen just means having more players in the same amount of space. Every new player in splitscreen comes with a small, fixed overhead cost. The whole level has already been put into memory so there is nothing extra to be loaded.
But in an open-world game like Burnout Paradise, the players could be anywhere. The world is too big to fit into memory, so the game loads as much as possible and then intelligently loads "ahead" of where the player is, so that the world appears to be seemless.
But splitscreen players could be in totally different places on the map, driving at full speed in opposite directions. So the game would have to load twice as much data in the same amount of time. The second player doubles the cost of everything - twice as much memory, twice as much disk bandwidth to load ahead of each player, etc.
There are hardware limitations about how fast textures can be loaded from disk, how much memory is available, etc. Splitscreen is very hard for open-world games. It can be done, but it would take significant resources - making it work would probably tie up their best programmers for months.
Game development is all about allocating your resources as best you can. Ultimately someone decided that it was acceptable to drop split-screen in favor of making sure that the single-player and online experiences were as good as possible, and getting the game out the door on time.
The removal of split-screen still stings, of course :( But maybe you can understand why it's missing.