What if Game Graphics Never Aged?

An anonymous reader writes "If you've heard of Procedural Synthesis, you already think it's amazing. It's been used to create some extraordinary visuals in tiny packages, like .kkrieger, which is less than 96 Kilobytes big but still has graphics that look like like a modern PC title. Beyond that, there's even more that Procedural Synthesis might be able to do; what if your old video games never aged, never looked out-of-date? Imagine putting Halo 2 into your Xbox 360 only to have it automatically upgraded to look like Halo 3 in graphical quality. This article examines the unexpected way that Procedural Synthesis might impact gaming in the generation after the Xbox 360, PS3, and Nintendo Wii."

Disposable Games Vs Design Patterns

[eldavojohn]

When I read this Slashdot article, all the rules of software design came flooding back to me. Low coupling, high cohesion, encapsulated complex structures, all that jazz. Before you even started to program a complex FPS game, you might start by carefully separating the layers and keeping things like two dimensional surfaces rendered to be de-coupled from other things like the AI of the enemies. Separate the garphics from the rest of the gameplay. I completely buy into the possibility that games can be designed well enough to abstract their graphics to a point where the same exact graphics package can be used in even several different types of games.

When I read this article, it sounded like a classic example of someone going nuts with the design patterns [wikipedia.org] that encourage encapsulation and separation of layers to improve modularity. Like someone had actually put in a lot of effort to the game to reduce the amount of effort that will be required later when new platforms and libraries come out for the game. On top of that, the imagery doesn't come from a data file but instead is derived on the fly from a library of procedures--something easily achieved by the strategy pattern [wikipedia.org]. The funny thing is that if other games have abstracted their graphics packages sufficiently, they should be able to rework the libraries to be procedures instead or maybe even build adapters to .kkrieger's procedures.

Why don't we see this more often in all games? Because I think most games today are disposable. They're built for one console or platform with the intent of only running on the current version of Windows or Mac and with no interest in coming out with new releases that support new hardware or software. They do this because games are construed as novelty software that expire as the user tires of them. Games like WoW or other MMOs might bring about a shift in the way game designers spend their efforts. Maybe games will start to take a longer time to develop but last a hell of a lot longer than they traditionally have?

Oblivion is a bad example

[raygundan]

Despite what the article says, everyone sees the same trees in Oblivion. The trees were generated using procedural synthesis (SpeedTree) *once*, and then the whole shebang was saved as a huge map and put on the disk. It's an example of the opposite of something like kkrieger, which puts the math on the disk and lets the end-user's machine to the generation, rather than the developers' machines.

The grass, on the other hand, is randomly placed and might qualify. About all that could happen on better hardware in the future is "more grass," though.

One major reason

[Have Blue]

From talking to artists I'm acquainted with, one major reason procedural rendering is moving so slowly is that it's difficult to exercise real creative control over it. All you have to work with are the inputs, and their linkage to aspects of the output may not be clear. It's very hard to tweak a procedural generator with any kind of strategy; all you can do is poke around at random values until the result looks pretty close to what you originally had in mind. Compared to the precise pixel/texel/vertex-level controls artists are used to, it's a step backwards and won't make game development easier or faster.

.kkrieger download

[in2mind]

For those who want to try the 96 k game kkrieger :
Download here (beta version) :http://kk.kema.at/files/kkrieger-beta.zip [kk.kema.at]

Procedural Paradigm

[GreggBz]

The whole concept of procedural creation in games has not been fleshed out as I would have hoped. Procedural methods can do much more then make great FPS graphics fit on 800K. Way back in 1986, I played a game called Starflight. Starflight used fractal algorithms to create a pretty diverse universe with about 200 star systems and 800 planets. You could land on and explore each planet. Close up. Let me say that again, you could land on each planet, collect it's life, find unique artifacts and rove your little tank around for hours. All of this fit onto two low density 5 1/4" floppies. Now, the CGA graphics and restrictive CPU power did no favors. Things got pretty repetitive, but the enormity of the game went unmatched for about 12 years.

In reflection, and now that I better understand it's design, it seems to me to be a microcosm of the real universe. You have a set of rules and a set of elements and by happenstance, (not by human hands in 3ds max) worlds are born.

For a long time, we've been stuck with with character models, human built maps, plot-lines on rails and worlds confined to the imagination of the story line department. Procedural graphics and world creation could make the universe out of a few megabytes.
There are a few games here and there that use this idea. Here is a game in development using procedural graphics and fractal planet creation: Infinity [fl-tw.com]

Total Annihilation

[Maxo-Texas]

This game... created in the 1990's looks as good as ever. And in fact, recently went to a true 3d environment ("Spring"). All those tiny 1/2" objects were 3d objects from the beginning. As the 3d cards got better, the game got better.

Likewise, the AI engine and other aspects were forward thinking- table based, programmable and over the years the AI for the game and units and maps have all only improved with age.

It is the *only* game that I purchased back then that I still play and enjoy.

Demoscene, anyone?

[seadoo2006]

Procedural synthesis has been around for quite awhile in the demoscene. These demos are computer programs that have been specifically engineeered to impress in both sound and graphics quality?

Check out FR-08, circa 2000, by Farbrausch...this demo goes on for nearly 15 minutes at 1024x768 graphics that certainly blew away anything of that time, and its 64KB.....64KB!!
Download Here [pouet.net][pouet.net]

Also, see FR-025, circa 2003, this "popular" demo absolutely blew my mind when I first watched it.
Download Here [pouet.net][pouet.net]

Heaven Seven, circa 1999, the demo completed by Exceed, is a journey threw time with beautiful textures and graphics. This is also a 64KB demo, so beautiful...
Download Here [pouet.net][pouet.net]

The demoscene is alive and well, publishing the most beautiful and interesting works of art in modern days. Even the largest demos (~50MB), blow away HL2 and any other 4GB+ game. Check these out at http://www.pouet.net [pouet.net]

Re:Disposable Games Vs Design Patterns

[Osty]

Why don't we see this more often in all games? Because I think most games today are disposable. They're built for one console or platform with the intent of only running on the current version of Windows or Mac and with no interest in coming out with new releases that support new hardware or software. They do this because games are construed as novelty software that expire as the user tires of them. Games like WoW or other MMOs might bring about a shift in the way game designers spend their efforts. Maybe games will start to take a longer time to develop but last a hell of a lot longer than they traditionally have?

I don't think you're right. While games may be disposable, engines are not. Good engines are modular, supporting multiple rendering systems (OpenGL, DirectX), input systems (SDL, DirectX), audio systems (OpenAL, DirectX), etc. Game logic is separate from the engine (UnrealScript, Lua, QScript, etc). As an example, the Unreal engine that powers many games is an evolution from the engine that powered the very first Unreal game ~8 years ago (as opposed to id engines, which are rewritten each "generation" -- Doom, Quake, Quake 2, Quake 3, Doom 3/Quake 4). That's right, the same engine that powers next generation titles like Gears of War is ~8 years old. Obviously it's been maintained and updated (anybody remember when Unreal only supported Glide [wikipedia.org] for 3D acceleration?), of course.

I think the real shift will not be games taking longer to develop, but a more radical split between tools/engines and games. That's been happening for quite some time now, with developers like Ubi, Digital Extremes, Raven, Grey Matter, etc focusing on building games based on other's technology (Splinter Cell, Rainbow Six, Unreal 2, Prince of Persia, etc all on the Unreal engine and not done by Epic). We've seen id step back and focus more on technology than games (id didn't write Quake IV), and even before that id's games felt more like tech demos for the new engines than actual games. This split will only become more pronounced as hardware gets more complex (multi-core CPUs, for example), cost to develop games increases, and required time to market decreases or stays the same. It'll not be possible to develop a brand new engine and a good game and still make a profit.

Wil wright talks about this is a recent lecture

[Captain Rotundo]

It is available at www.longnow.org (previous months lectures). Its not the same topic, but it is a talk with brian eno entirely about 'generative content'.

Already Supported by the Xbox 360

[ThinkFr33ly]

I don't know if developers are taking advantage of it, or to what extent it supports it, but I'm fairly sure the Xbox 360 already has [arstechnica.com] Procedural Synthesis capabilities.