Procedural Programming- The Secret Behind Spore

imashoe writes "Ever wonder how Spore works under the hood? The game seems to be insanely huge and how is it that there can be an infinite amount of different creates created in the game? The answer is Procedural Programming."

hype

[BrandonBlizard]

There is no way spore is going to live up to the hype they keep generating. Even if it is a moderate financial success people will view it as a failure because of expectations. as far as procedural programming is all bull, they're franticly animating to fix the impossible procedural animation system. My prediction is that it will be delayed and be a disappointment to anyone who is expecting the greatest game ever.

Inifinite Creates?

[eldavojohn]

The game seems to be insanely huge and how is it that there can be an infinite amount of different creates created in the game?

The word infinite gets abused quite a bit.

I think you meant to say 'seemingly infinite' or 'infinite for all intents and purposes.'

I've tried to think of mental exercises to challenge people with a concept of something being infinite. For example, if you had an object of infinite mass with no gravity, would it be possible for us to exist alongside this infinite object?

Infinity has interesting properties and I challenge the use of 'infinite' in this summary. The article uses cautious words:

Procedural programming essentially shrinks the technological world, allowing us to fit a lot more information in limited space, and allowing this information to interact in near infinite ways.

The basic theory of how one would store infinite states of data instantly disqualifies any device I know of. Computers, game systems, etc. are ultimately storing data in a binary on/off form. You can story many bits of data and come up with many states very quickly. You cannot, however, store an infinite amount of states on a finite amount of bytes. There's just no way to do it. A very large amount of different states? Of course. But not an infinite amount.

For the purposes of speculation, what would be the best way to give a user a seemingly 'infinite' number of states? Well, the obvious choice (and what random number generators on computers seem to favor) is to use time. Time is infinitely divisible (although the representation of that depends on decimal precision) and it is (seemingly) never ending. So one would base the resulting states in the game off of when a user entered input. It is still very easy to show that this is a many-to-one mapping. You can divide time down to a small enough unit that they are technically different moments yet the hardware that captures the analog input cannot discern between them.

I think that this concept of 'infinite' states is desirable to gamers. And it's the states that you find yourself in in a game that were clearly not thought out by the developers that makes a game special. When you have a large freedom of configuration pitted against players with that same freedom, you have the core success behind real time strategy games where players would build cities and armies and pit them against each other.

I don't think this claim can ever be made when a digital machine is being used. I guess you could design a program that would adjust to the size of the machine and extrapolate the amount of precision it used to measure the moment at which the user clicked the remote button and then stamped this number on the create's forehead (or some other form of uniqueness). But, I do not know enough about how the CPU acquires the time stamp. If it's a quartz crystal, this is only accurate to the number of vibration the crystal makes per second with electricity pumped through it. I have good reason to believe you will always encounter some theoretical issue or barrier when trying to achieve truly infinite implementations. Best to leave that word where it belongs: in mathematicl proofs and scientific theories.

The obvious

[Anonymous Coward]

The article author has no clue.

All you need to read is this sentence...

[Anonymous Coward]

"The basics of sequential programming are all object oriented."

That pretty much captures how well the author understands programming.

Vaporware

[IdahoEv]

Someone with a subscription needs to tag this story Vaporware.

I remember first getting excited about in-game videos of spore something like two years ago. It's starting to feel like we're getting nukem'd again.

Re:Crap alert

[el_womble]

I think the author was confused. What they actually meant was functional programming. In fact I know the author was confused. How did they not make the connection that the 4 CD PS1 games had a lot of FMV?

An excellent example of a little knowledge doing a lot of harm. It reads well enough that my non coding tech friends could read it, and then tell me I'm a fuck-gnut for not using a procedural language...

Still, I'm going to assume that the eds know what they're doing and are actually just trying to get an argument blaring on this no news sunday.

Re:Crap alert

[geeknado]

I think that part of the issue here is that they've both confused the concept of procedural programming(and I'd be shocked if most games weren't programmed procedurally) with procedural generation [wikipedia.org] then proceded to give a better description of the first.

It's not that they're wrong that Spore is innovative this way(assuming it's ever more than vaporware), but rather that they do an exceptionally poor job of describing the way it works...The distinction here isn't between gated logic trees and 'actions', it's between static and dynamic content.

Article Sucks

[jlarocco]

That article is terrible. It reads like a 9 year old trying to explain something he doesn't understand.

Re:Typo in summary

[Anonymous Coward]

Really, are you sure your eyes aren't just skipping over them? I don't usually think about it, but a while back I bothered to, and noticed that in real life, at least here, there really are crates and boxes everywhere in my day to day life - stacked up behind, in front, inside, and occasionally on top of shops and other buildings, on trucks, sitting on docks / side of street waiting for collection, etc. Given many games are in an "industrial" setting, where there are even more crates, I think it's fair enough.

Now, if I lived in or was passing through an idyllic rural environment, crates would be quite out of place (hello tomb raider...), but crates are bloody everywhere in an urban or industrial environment (or even on the farm), especially early in the morning and late at night when things are being loaded and unloaded and shipped, and nefarious criminals with guns might well be running about fragging eachother in real life.

Not really procedural programming

[markov_chain]

More like rule-based, event-driven programming. This is what happens when people don't get a proper technical education.

Re:Well, no

[ichigo 2.0]

Duke Nukem 3D [wikipedia.org] was released in 1996.

I guess you meant Duke Nukem Forever. [wikipedia.org] ;)

Yeah. IOW, this is a new low.

[Concern]

Indeed - I'm sure you're exactly right. This looks like a new low for /. novice "tech" "writing" - and for this site for picking it up as a story.

Due date

[ReallyEvilCanine]

Not before April, 2008 [ign.com]. And it may get held up even longer since they want to release simultaneously for PC and DS even though the two versions will be different and incompatible.

Re:Typo in summary

[Anonymous Coward]

Crates are everywhere because they're easy to render. Only six visible triangles...

Re:Eh?

[TheGeneration]

The biggest fault with that article is that the author doesn't take into account who his audience will be. If you are going to write an article on the "breaking news" that the creators of Spore have gone to the future year of 1987 to use Pascal to write a mutliplayer online game, well... chances are the only people who will want to read your article are programmers. So don't bother trying to explain Ryu's fireball to us, we got that back in 1990 when Ryu spit out his first fireball in front of our eyes. Instead give actual details that are worth reading to your potential audience.

Re:Inifinite Creates?

[OpCode42]

Time is infinitely divisible

This may not be as true as you think. Planck time [wikipedia.org] is the shortest amount of time that has any meaning.

Re:Inifinite Creates?

[Fractal Dice]

The word infinite gets abused quite a bit.

I agree ... but you really need a good catchy word for "cannot have all possible states represented even if you harnessed every grain of sand in the universe".

According to one of the talks, a Spore world is about an 80K data structure when compressed. 2^640000 is a really big number. My fuzzy back-of-the-napkin count gives something like 2^240 hydrogen atoms in the universe. I think hard math either needs to learn to share the word infinite or it had better file a trademark :)

Re:Inifinite Creates?

[TheRaven64]

If you're representing money, and doing anything important with it, you should use a binary coded decimal. This will let you maintain a fixed number of decimal significant figures of accuracy, which is generally what is needed. If you're using Java or COBOL, the language / standard library can handle arithmetic for you.

Re:Article Sucks

[pimpimpim]

Congratulations! You just summarized 99% of the internet!

Re:bzzt, wrong.

[fireboy1919]

So, to summarize:
* C is an example of procedural programming.
* Haskell is an example of functional programming.
* L-systems are an example of procedural content generation (content generated by a procedure, in a deterministic fashion).

To continue the summary (and clarify):
* Marshmallows do funny things if you lower the pressure enough.
* Cheeseburgers are often considered delicious
* Like the above comments, programming language type is a red herring. Procedural content generation is a misnomer. It just means that the content is mostly programatically generated on the fly instead of being simply rendered.

It's all about repeated iteration over a particular type of finite automata with a particular string.

And then then string is the content, isn't it? Interesting point here is that this is something of a continuum. You could make your procedures more complex, and then require less content to produce the something. On the other hand, you could go the other way and have absolutely every piece of content actually be written in your programming language.
When you think about it that way, it becomes a lot more obvious.
You're talking about whether most of the work is going into the content creation, or into the rendering engine.

If most of the work is in the engine, it's really easy to make lots of new kinds of content since you don't have to do as much work to make the content. However, making a powerful engine sure requires a lot of work, doesn't it? You have to make your engine handle absolutely every special case that you could ignore if it wasn't normally applicable to a very specific content instance.