Will Wright Presents Spore... and a New Way to Think About Games

So here's what he did: he recruited an elite strike team of coders (who, if you were to believe his slideshow, dressed like ninjas) and put them in a "hidden facility" to experiment with new ways of giving the user powerful tools and generating tons of dynamic content without armies of content creators.

From time to time it's good to remember that we live in The Age of Programmability.

To all employers out there: It is us, who know most about programmability and programming models. If you don't want to stay behind, hire programming language mavens...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

How Long to Develop?

I was disappointed that the article said nothing about how long it took them to develop that game (perhaps because Wright didn't say exactly). From what it sounds like, they got a couple guys together, locked them in a closet with laptops and Mountain Dew for a week, and out came Spore.

In any case, the level of dynamisism in that game is simply stunning. I had some ideas along a similar line for an RTS game, but Spore is far more ambitious than anything I thought up. More ambitious than I thought possible, in fact.

8 days? More like 8 years...

The game had already won 4 Game Critics Awards at E3 2005; it's due to be released in September 2008. Actually, I think I've read somewhere that development began in 2000.

Anyway, it's pretty safe to say this wasn't a one week project. ;)

Edit: Ignore this post... I missed the fact that the thread had been resurrected by a spammer.

Karl Sims, I love you!

Reading this got me really excited. Not because I am dying to play this game, but because it reminded me of the work of Karl Sims:

I have had the desire to recreate his experiments on my own machines for years now, but every time I've tried, its turned out to be significantly harder than I had hoped.

Putting content in the hands of your users is a great thing; but for it to work, you need to choose the right core representation to ensure that your users can express what they want (while still remaining in the bounds of what your system can interpret).

To me, the hardest part about choosing that core representation is that I wouldn't be happy unless it took the form of an actual language that I could read and understand. (When I say language, I don't necessarily mean strings of english text; I'd be happy with pairs of graphs as the core representation, like Sims did with Evolving Virtual Creatures.)

The point here is that it seems like Spore is taking the route of hiding the representation from the user, and only allowing them to interact with it via their specially programmed operators installed in the UI for the game (such as putting down a collection of spears). Maybe they expose more to their users underneath the surface; its not clear. Anyway, its wonderful to see these ideas got some attention by people willing to invest in them.

Right

To me, the hardest part about choosing that core representation is that I wouldn't be happy unless it took the form of an actual language that I could read and understand.

Well, that's why I posted this thread here on LtU. These are issues we should discuss.

Related to some of the classic themes like end-user programming, DSLs, PBD etc.

DSL perspective

It can be said that "content creation" always had its own DSLs, but they were pretty much limited to literals (such as bitmaps, 3D meshes, MIDI sequences, etc.).

I see procedural content creation as extending these DSLs with higher-order constructs: functions(maybe even HOFs), data structures, possibly (but unlikely) types.

It does not mean that literals completely go away, it just means it becomes easier to express their structure, improving reuse (even between content for different media types, e.g., 3D geometry and sound), flexibility, and, well, ROI.

I still don't see how it will work employment-wise - whether it means hiring more programmers and less artists, or just blurring distinction between the roles.

I guess an educated analysis is due from LtU's (un)real game developers.

TANSTAAFL

I see procedural content creation as extending these DSLs with higher-order constructs: functions(maybe even HOFs), data structures, possibly (but unlikely) types.

My impression is that what people want from procedural content creation is aesthetic and "believable" content generated from bits up by an algorithm.

I think what they usually get is Mr. Potatohead.

I still don't see how it will work employment-wise - whether it means hiring more programmers and less artists, or just blurring distinction between the roles.

I don't think it will ACTUALLY make a difference in employment levels. I'm explaining the hype surrounding Will Wright's talk at GDC.

It is like the advocates of MDA (and other perennial SD automation schemes). One of the not-so-secret appeals of such things is the idea that they will allow IT projects to reduce/relegate/eliminate those pesky programmers that cost too much, and get too much attention.

I don't think those will work the way people want either.

Procedural?

I am intrigued, whether all this procedural content ("meshes, textures, animations, and behaviors") is really "procedural" (as opposed to functional) and why?

Or is it just a conventional word to use for everything that does not require manual definition down to pixel (or triangle) level?

"Procedural Manifesto"

Or is it just a conventional word to use for everything that does not require manual definition down to pixel (or triangle) level?

This definition seems nearer. “Core Techniques and Algorithms in Game Programming” by Daniel Sánchez-Crespo Dalmau, has a section about the "Procedural Manifesto", which says:

“A procedural model is a description of a system (graphics, audio, AI) using algorithms rather than explicit, precomputed data.”

Kolmogorov again?

“A procedural model is a description of a system (graphics, audio, AI) using algorithms rather than explicit, precomputed data.”

Um, what is the difference between data and algorithms? The degree of conceptual compression?

Artists vs. Programmers Round 2

Um, what is the difference between data and algorithms? The degree of conceptual compression?

In this context, the difference is all about whether you have to hire artists or not.

Increasingly, game development is more about art "properties" than programming. Procedural methods are partly about resetting the balance in favour of programming again, which is why Will Wright got such an enthusiastic response from games programmers.

Human factor?

In this context, the difference is all about whether you have to hire artists or not.
Does it mean that "procedural methods" require less creativity? Or just less bit-shifting (pixel-shifting?)?

When I am using an editor for procdurally-enabledTM runtime - am I not an artist anymore? Am I a mix of an artist and a programmer just because I operate with functions and complex structures in addition to plain layers of pixels and vectors?

Does it matter in which stage the transition from "procedures" to "data" is done? Are we talking about multi-stage creative processes with dependent types? :-)

PS: from my years of obsession with amateur game development, I remember that Turing was the first to propose something like procedural textures (and published that in "Philosophical Transactions of the Royal Society of London" :-) ). I think the keyword was "reaction-diffusion".

Employment factor

Does it mean that "procedural methods" require less creativity?

No, just less artists.

My statement is about the sociology of the game industry, not about the philosophy of creativity. ;-)

Artists vs. Programmers Given "Procedural X"

I think there's some confusion about the balance of artists vs. programmers given things like, e.g. "procedural textures," but really given "procedural anything." All of the "procedural X" technologies that I'm familiar with are parameterizable: you have something like the Perlin noise function and you twiddle with the parameters until the results look like you want them to: 2 dimensions with this set of parameters makes a nice water effect; 2 dimensions with that set of parameters makes a nice fire effect; 3 dimensions with the other set of parameters make a nice cloud effect...

This is totally something that artists can, and do, do without programmers, whether it's in games or in special-effects shops for television and movies. Just watch the credits for your favorite special-effects or animated film sometime and see how many names there are in "software development" vs. any other category. Yes, there will be some more names in "shaders" than in software development, but it's still a tiny number compared to the other artistic categories.

When the "procedural X" is actually functional, it becomes even easier to make life easy for the artists: often visual tools can be constructed to allow the composition of these "procedural" elements. Check out the preview movies for the Unreal 3 technology: Tim's commentaries make very clear that they're empowering their level designers and artists, who are building shaders that exhibit, e.g. parallax, or near ray-tracing quality refraction and reflection, without writing a single line of code.

"Procedural X" doesn't mandate more programmers in game development. Quite the contrary.