Become a fan of Slashdot on Facebook


Forgot your password?

Procedural Programming- The Secret Behind Spore 277

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."
This discussion has been archived. No new comments can be posted.

Procedural Programming- The Secret Behind Spore

Comments Filter:
  • by SolusSD ( 680489 ) on Sunday August 05, 2007 @12:49PM (#20122535) Homepage
    use a functional programming language. prove mathematically that your functions are correct. and technically, it should be fairly easy to write compilers that automatically thread the program due to the nature functions are written in a functional programming language. i encourage everyone, especially the writer of this article, to read up on it. Haskell (a programming language) is a good place to start.
  • Functional (Score:5, Interesting)

    by hey ( 83763 ) on Sunday August 05, 2007 @01:06PM (#20122737) Journal
    *Functional* programming sometimes seems like magic. Maybe that's what they are talking about.
    Its not new but still cool. g []
  • Re:Eh? (Score:3, Interesting)

    by tundra_man ( 719419 ) on Sunday August 05, 2007 @01:12PM (#20122789)
    Yes I would have to agree. The method of programming being discussed is more akin to a Finite State Machine (FSM) in which you describe various states, events which cause state transitions and of course the define what all happens during the transition. It is a valid programming methodology and is used in telephony and other places. One popular application for working with such code was Rational ObjecTime which became part of the Rational Rose product before Rational was bought by IBM. Where FSM has troubles is with switch statements as they become quite complex (switch is the same as many IF and IF ELSE in many ways) which may be why the author was so negative to IF statements. As for games size, yes games have gotten bigger, this is however more to do with all the artwork and sounds that accompany the games and not the software driving them. As for the developer's of comment "nearly everything is created procedurally" this would explain the smaller size not because of "procedural programming" but because rather then grabbing an image or sound from artwork on a CD they are creating it in code. For example I can write some code to render a sphere, with the API allowing for color, material, lighting and others to be defined, now I can write small bits of code to call the API and create a thousand spheres all with unique characteristics, all with minimal amount of CD space being used (lets say 1K for the API definition and 100bytes per sphere = 1K+(100B*1000) = 98.6Kb). Now if I was to have 1000 unique spheres using artwork you would have 1000 unique images saved on CD plus a smaller API to load them (0.2Kb API, 100Kb per image = 0.2Kb + 100Kb *100 = 12.2Mb). Even if you were to do some optimization, which you would, the difference is clearly visible.
  • by Mr. Picklesworth ( 931427 ) on Sunday August 05, 2007 @02:02PM (#20123267) Homepage
    Ah, this reminds me of my favourite thing to be annoyed by in games; the basis of all evil in game design!
    Arbitrary bits of advanced player interacton placed by the game developers, instead of the game dynamically (via smooth code) allowing you to do what you want within a believable universe.

    For example "special abilities" that are meant to be challenging, interesting and dynamic. (Climb up two walls facing each-other, for example). Sounds good? Unfortunately, the designers just place arbitrary 'two wall climb' points in the maps themselves, and to make things extra lame, any place where you can use a special ability stands out like a sore thumb, just to rub in the fact that it is arbitrary. Artificial limitations appear because you find a place where you should be able to use a special ability, but the designers just didn't make it possible on that wall because it could be used as an exploit. They sell the game as having a realistic world, but these arbitrary abilities make that world completely unbelievable: This is a world where the laws of physics change based on where you stand.

    It's like that plot-hole movie, where at one point they have a big laser cannon that can fight off alien invasions, but in the next scene they have no defences because it would be "bad form" to use the laser cannon in two scenes.

    Sadly, this sort of junk happens everywhere:
    • "Explore strange new worlds!" - The catch is that exploring consists of being teleported to very small segments of these worlds consisting of a hedge maze and a bunch of enemies. The only thing you get to explore is your weapon.
    • "Build your own ____" - In other words, arrange blocks into a predetermined pattern to create the same thing as everyone else. (Maybe you'll get to choose from a list of 12 colours. Exciting).
    • "Fashion your own tools and equipment!" - ...from a list of about six buildable items. Good luck sticking together the "right" ones. (No, you can't poison an arrow or a sword, you can only poison a dagger!)
    • "We have precisely 100 things you can do!" - The stupidity speaks for itself. They are admitting that the experience is a cookie-cutter experience, in the sense that what you are about to play is a duplicate of what everyone else is going to play. Thus, it is pointless.
    • "Become a hero" - Become an arbitrary number. Hero #1241148. Level 70, just like all the other heros. Every "skill" has 100% beside it. Great.

    Every game on the face of the earth advertises dynamic content in one form or another, and almost all of them fail miserably. Why?

    With games I design, I strive to avoid this by doing what those games won't dare to do. Flexibility is key here, and it is really not that hard to achieve! It is the difference between designing your game around the dynamic content, or designing the dynamic content around the game. (It may also be the reason I have yet to release anything).

    Arbitrary things are fun, but only when coupled with 100% user controllable variables. Two of my projects rely on a system where everything in the game world is created dynamically around a small number of settings that blend together in every aspect of the presentation. These variables procedurally control appearance, audio presentation and actual gameplay behaviour in a weighted manner, where each value has unique properties. This means everything is unique, but at the same time tied to a consistent set of rules.

    What I found rather quickly just by pondering it was that this made for an experience that was too predictable in the sense that the player could really easily figure out the dynamics of the actual game. The world becomes reliable and believable, which is good for that exploration mechanic (where the player can actually learn 'the world' instead of 'the game'), but it is too simple to figure out. Thus, I throw in some fun little arbitrary events that happen with certain magical combinations, and it's much more exciting! The difference between m

  • bzzt, wrong. (Score:5, Interesting)

    by Inoshiro ( 71693 ) on Sunday August 05, 2007 @02:55PM (#20123781) Homepage
    They meant procedural content generation, like L systems [], used to make believable looking plants that grow and change over time.

    It's all about repeated iteration over a particular type of finite automata with a particular string.. Easily done if you've taken your 3xx/4xx graphics an theory classes, but perhaps past what most technology reporters are capable of.

    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).

  • by Krilomir ( 29904 ) on Sunday August 05, 2007 @03:08PM (#20123883)
    Wasn't the Firehose supposed to weed out stuff like this? What went wrong?
  • Re:Vaporware (Score:3, Interesting)

    by Movi ( 1005625 ) on Sunday August 05, 2007 @04:49PM (#20124613)
    Wrong. Duke Nukem Forever was first started using a heavily modified Quake 2 Engine(much like in spirit of Half-Life which used a heavily modified Quake 1 Engine), then near the end of development cycle a switch to the Unreal Engine was decided, with most of the work done scrapped.
    By the time they were anywhere close to beeing done UT2k3 was out, so they decided to use Unreal Engine 2. As far as i know they either use the updated Unreal 2 Engine (and inherited the fixes from UT2k4) or are working with Unreal Engine 3. But then again, this is Duke Nukem Forever and Ever, so who knows? Maybe they're waiting for ID Tech 5 to switch? ;]
  • Re:Starflight? (Score:3, Interesting)

    by GreggBz ( 777373 ) on Sunday August 05, 2007 @08:48PM (#20126125) Homepage
    They used fractal algorithms to generate terrain lifeforms, minerals, and in fact the whole universe.
    Starflight I and II were written in Forth, using a custom compiler. Here is some old design documentation [] from Starflight.
    It's interesting stuff.

    I am in fact recreating the game (or, rather a game much like it using entirely original content) using many similar algorithms.
    Check out my webpage. []

May all your PUSHes be POPped.