×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

277 comments

Well, no (5, Funny)

ucblockhead (63650) | more than 6 years ago | (#20122353)

Given that I've only seen videos of someone else playing "Spore", I have to say, no, I don't wonder how it works. I wonder when the hell it'll be done.

Re:Well, no (5, Funny)

zn0k (1082797) | more than 6 years ago | (#20122471)

I wonder when the hell it'll be done.
$ apt-cache showpkg spore
Package: spore
Versions:
1.0
Description Language:
File: /var/lib/apt/lists/spore.maxis.com-i386_Packages
MD5: b7b55c3327e373b0abee0ccb25902a2b
Dependencies:
1.0 - dukenukem3d

Vaporware (2, Insightful)

IdahoEv (195056) | more than 6 years ago | (#20122541)

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:Vaporware (1)

smallfries (601545) | more than 6 years ago | (#20123011)

Nah. Spore will come out sooner or (probably) later. Then it will feel much more like Black and White...

Due date (3, Insightful)

ReallyEvilCanine (991886) | more than 6 years ago | (#20123157)

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:Vaporware (1)

FuturePastNow (836765) | more than 6 years ago | (#20123059)

I can think of one big difference- I've never seen a video of DNF gameplay, while there's a new Spore demo vid every few months.

Re:Vaporware (3, Informative)

MindStalker (22827) | more than 6 years ago | (#20123117)

Oh come on, its only been 2 years. A lot of games have taken 3 years sense their first showing to the public till release. DNF is going on 11 years. No comparison really.

Typo in summary (0)

Man On Pink Corner (1089867) | more than 6 years ago | (#20122383)

"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?"

I think you misspelled "crates."

Re:Typo in summary (4, Funny)

buswolley (591500) | more than 6 years ago | (#20122445)

Yeah who here is sick and tired of crates being everywhere in games. I hardly ever see crates in my day to day.

Re:Typo in summary (2, Insightful)

Anonymous Coward | more than 6 years ago | (#20122653)

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.

Re:Typo in summary (4, Funny)

Anonymous Coward | more than 6 years ago | (#20122747)

I kept jumping up, punching this one crate, just waiting for the gold coins or extra man to come out. Instead, one of the loading dock guys just chased me away.

Re:Typo in summary (2, Insightful)

Anonymous Coward | more than 6 years ago | (#20123181)

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

Re:Typo in summary (1)

freyyr890 (1019088) | more than 6 years ago | (#20123303)

Six triangles, not polygons? Pretty weird looking crate. That'll come out like a malformed pyramid.

Re:Typo in summary (5, Informative)

Anonymous Coward | more than 6 years ago | (#20123375)

Uhh... No. A 3D cube has six faces. At any given time, at most 3 are visible in a 2D projection of a 3D scene. It takes two triangles to represent a square face (many 3D toolkits "really" only using triangles underneath). So, 6 triangles. So, the original poster was correct, you lose, do not pass go, do not collect 200.

Re:Typo in summary (1)

IBBoard (1128019) | more than 6 years ago | (#20123391)

Only six visible triangles...
;)

That assumes you've got standard right-angled triangles, though. e.g. two to make each side, multiplied by three (which is the most number of sides of a box you can see at one time - like in normal isometric projection)

Re:Typo in summary (0)

Anonymous Coward | more than 6 years ago | (#20123427)

Isn't a triangle a polygon?

Anyway, six triangles are enough to draw the *visible* parts of a 3d cube. Think about it.

Three Vee-Dubs for under seventeen thousand! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#20122385)

Your mom taketh me to monster truck show, and we both enjoy watching Grrrrrraaaavvvveeeeddddiiiggggggggggerrrrrrr

Can one use PP (3, Funny)

Anonymous Coward | more than 6 years ago | (#20122393)

to generate one meaningful article about it? since apparently it's good at increasing noise by putting out fluff pieces as this one.

--
captcha: uncouth. Quite.

Attention Procedural Programmers (0)

Anonymous Coward | more than 6 years ago | (#20122403)

Attention Procedural Programmers: You have piqued my interest. Please reply with snippets of example code.

Not really procedural programming (3, Insightful)

markov_chain (202465) | more than 6 years ago | (#20122659)

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

Re:Attention Procedural Programmers (1)

mini me (132455) | more than 6 years ago | (#20122775)

Agreed. It's silly to talk about programming without showing some code.

Eh? (5, Informative)

MrSteveSD (801820) | more than 6 years ago | (#20122427)

I really feel like the person who wrote the article doesn't know what he is talking about.

Ad for Bona Fide Reviews (5, Funny)

thegnu (557446) | more than 6 years ago | (#20122511)

Girl: You got Spaghetti Code in my Perl!
Boy: You got Perl in my Spaghetti Code!
BONA FIDE REVIEWS: our content makes as much sense as our ads.

Re:Eh? (4, Informative)

mmacdona86 (524915) | more than 6 years ago | (#20122567)

Yes, the distinction that they are probably trying to make is that between procedural or algorithmic content generation and the more common situation where content is created individually by artists.

The talk about procedural versus object-oriented programming is moronic bs.

Re:Eh? (3, Insightful)

TheGeneration (228855) | more than 6 years ago | (#20123247)

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:Eh? (3, Interesting)

tundra_man (719419) | more than 6 years ago | (#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.

Re:Eh? (0)

Anonymous Coward | more than 6 years ago | (#20123139)

Funny, I feel the same thing. The author is full of crap (or is clueless about programming or both).
Sounds like real object-oriented programming which we're doing now (though not for games).

If you go to the article and read the comments, looks like it is far from being an isolated opinion.

Crap alert (4, Informative)

VeryProfessional (805174) | more than 6 years ago | (#20122429)

This article reads like pure garbage. Procedural programming [wikipedia.org] simply refers to any form of programming in which procedure calls are made... ie. any mainstream imperative programming language. Does anybody really believe that games fill up multiple DVDs because there are too many IF statements? Editors, wake up please.

Re:Crap alert (1)

Scotland Tom (974094) | more than 6 years ago | (#20122507)

Indeed. The author of this article seems to have only the most rudimentary understanding of procedural programming. The attempts to explain the process in a simplified manner are feeble, lack insight, and are generally not very informative.

Re:Crap alert (1)

jaguth (1067484) | more than 6 years ago | (#20122523)

I agree. For example, the editor says that the PS1 has games with 4 CDs... Lets take FF7 as an example: its not because the code is so huge to fit on one CD, its because the FMV scenes are large files which take up the majority of the space on the CD.

Re:Crap alert (3, Insightful)

el_womble (779715) | more than 6 years ago | (#20122549)

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.

Functional Programming (1)

ucblockhead (63650) | more than 6 years ago | (#20122649)

Which itself is hardly revolutionary given that functional programming has been around for four decades.

The comments about Civilization are particularly annoying.

Re:Crap alert (5, Insightful)

geeknado (1117395) | more than 6 years ago | (#20122605)

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.

Re:Crap alert (0)

Anonymous Coward | more than 6 years ago | (#20123165)

I wondered at first if the article was a joke, but it might really just be a misunderstanding by a neophyte. But I remember being confused when I first got a copy of turbo c++ if the .obj files had anything to do with object oriented programming...

This article reads like the same level of "not getting it" that I displayed in that case.

Re:Crap alert (1)

Lemmy Caution (8378) | more than 6 years ago | (#20123177)

Agreed, the original article is crap.

What is "procedural" about Spore is its game and interface design. Much of it is conceptually procedural. It is comparable to the sort of parameterization that you might find in a 3D design tool (Solidworks, Inventor, etc.)

I'm almost certain that it is implemented mostly in C++ and other modern, mostly OO languages.

Re:Crap alert (1)

kabz (770151) | more than 6 years ago | (#20123467)

It would read a lot better if he had said 'procedural rendering'. In that case, it conveys the idea that code is used to generate what you see, rather than fixed data files.

Here's a Wikipedia linkie [wikipedia.org] . And yup, you've guessed it, there's a picture of Spore.

Re:Crap alert (0)

Anonymous Coward | more than 6 years ago | (#20123301)

I agree whole-heartedly. This guy has NO idea what he's talking about. It was amusing though, and makes me feel slightly more secure in that there's one less person who can't do my job. :-)

Just about anyone could tell you that most of those "2-3 DVD" games were mostly made up of game "assets" like textures, map data, and (too many) cut scenes.

Horrible article (0)

Anonymous Coward | more than 6 years ago | (#20122439)

Please tell me this article is just a joke that I'm not getting.

Horrible, horrible article with no connection to reality.

hype (2, Insightful)

BrandonBlizard (1007055) | more than 6 years ago | (#20122441)

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.

Re:hype (1)

BarneyRubble (180091) | more than 6 years ago | (#20122939)

Yes, I think it might end up being a technically brilliant but maybe just not engaging/fun to play.
Of course like most of the discussion about spore at the moment this is just wild speculation.

Inifinite Creates? (5, Insightful)

eldavojohn (898314) | more than 6 years ago | (#20122461)

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.

Re:Inifinite Creates? (0)

Anonymous Coward | more than 6 years ago | (#20122529)

(said while looking at Slashdot comments)

"My God, it's full of fussy math dorks!"

Re:Inifinite Creates? (1)

splortnik2003 (698008) | more than 6 years ago | (#20122635)

It's a dumb article, but this is also a dumb nitpick.

Pretty much any game without a clock allows an "infinite number of variations in gameplay". "Rock-scissors-paper" allows an an infinite # of possible outcomes (since you could tie an unbounded # of times before someone wins).

Re:Inifinite Creates? (0)

Anonymous Coward | more than 6 years ago | (#20122665)

Pretty much any game without a clock allows an "infinite number of variations in gameplay". "Rock-scissors-paper" allows an an infinite # of possible outcomes (since you could tie an unbounded # of times before someone wins).
Sit down before you hurt yourself, there.

It has three outcomes that change the state of the game. You win, your opponent wins or you tie. Then the game ends and starts over.

Three falls a bit short of infinity. To say that any number of ties could occur does not change the state of the game. It returns you to the beginning state every time you tie. What has changed in the game when you tie?

Re:Inifinite Creates? (1)

splortnik2003 (698008) | more than 6 years ago | (#20122797)

Don't be an ass. If you want to claim a game of ten-thousand ties followed by paper-beats-scissors is identical to one with no ties, you can. To me, in the spirit of the example, this would be a different gameplay experience. Here's another example: flip a coin. Heads, win $1; tails lose $1. Play as often as you like. Outcome is a random variable with an infinite domain. Jackass.

Re:Inifinite Creates? (2, Funny)

nschubach (922175) | more than 6 years ago | (#20123069)

Sure, it's infinite until the computer tracking your winnings hits it's floating point limit, throws an exception and crashes losing all your winnings.

Re:Inifinite Creates? (0)

Anonymous Coward | more than 6 years ago | (#20123363)

Except that rock-paper-scissors is not a computer game. Put it on a computer, and it now has a finite number of different outcomes - even if you make the (silly, in my opinion) assumption that a tie is not an outcome in and of itself - because you have to keep track of the number of ties somewhere. It's easy to define a "game" that has an infinite number of outcomes/possibilities - just use a continuum somewhere. Picking your character's hair color? Pick any color that exists - there are infinitely many of them. When you put this in to computer program form though, you're limited to 2^24 colors (by your monitor), or some absurdly-large-but-still-finite number of colors by your computer's storage.

Re:Inifinite Creates? (0)

Anonymous Coward | more than 6 years ago | (#20122689)

z = z^2 + c

Re:Inifinite Creates? (0)

Anonymous Coward | more than 6 years ago | (#20122845)

Infinite creates:

Theory: Since virtual memory is not infinite, we need to make sure we clean up any object we create. This will give the illusion of infinite creates.

Assumption: Once this program is run it can never be stopped. This way its always approaching infinity. I hope you have Battery Back-ups.

#define EPIC_FAIL 0xFBAD

struct CObject //stupid retarded silly useless object with minimum size sizeof(int).
{
    int some_number;
}

void infinite_creates()
{
    CObject *pobj = 0;
    while(1)
    {
        if(!pobj)
        {
            pobj = new CObject;
            delete pobj;
            pobj = 0;
        }
        else throw("hahahahahaah");
    }
}

int main(int argc, char **argv)
{
    try
    { //the longer this runs, the more we approach infinity:
        infinite_creates();
    }
    catch(char *msg)
    { //nothing to clean up..
    } //include this so that we meat standards, even though we //dont plan on getting here..
    return EPIC_FAIL;
}

Re:Inifinite Creates? (1)

Original Replica (908688) | more than 6 years ago | (#20122911)

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?

Yes. Because for there to be an infinite object that would necessitate that the Universe be infinite. Now I am aware that the infinite object should completely fill the infinite universe.
However infinite + 1 = infinite. So in that "+ 1" there is room for me. It could be argued that there should also be an infinite amount of empty space left over in the infinite universe, but once we get there in the discussion, I start to think that, outside of a philosophical context, any use of infinity is a placeholder for a very high value that we are ignorant of. We need a new term for that, how about: "plenitudinous"

Procedural... (0)

Anonymous Coward | more than 6 years ago | (#20122463)

Maybe the author is not using the right word, because every games (before the wide adoption of object oriented programming), I say every games, were using procedural programming.

The obvious (2, Insightful)

Anonymous Coward | more than 6 years ago | (#20122467)

The article author has no clue.

procedural techniques and boredom (0)

Anonymous Coward | more than 6 years ago | (#20122475)

Despite the hype, spore is far from the first game to use this sort of thing. Back in the 8-bit and 16-bit days, it was, well, not common, but not unheard of. Games like the classic "Sentinel" used fractal landscape generators to have 1000s of levels on a 64k C64, "Frontier" used it to have a galaxy of worlds on the Amiga, etc.

Trouble was, such games tended to begin to look the same after a while, despite "near infinite" variations within the limits of the procedural generation algorithm. Already, I begin see that in spore. Yeah, your creations are unique. Like billions of others are.

Spore does more with the technique certainly. Will spore stave off bordeom longer than a procedurally generated C64 game - undoubtedly. But the boredom begins to set in after the space of possibilities has been delineated, not when the space has been explored exhaustively (this is common in programming itself too, as I think Paul Graham has pointed out when writing about Lisp). The former depends on the complexity of the procedural generation scheme, and spore's doesn't look infinite to me (though maybe it's extensible).

Procedural Generation? (5, Informative)

Asgerix (1035824) | more than 6 years ago | (#20122515)

Perhaps the author is confusing Procedural Programming with Procedural Generation [wikipedia.org] ?

Yeah. IOW, this is a new low. (4, Insightful)

Concern (819622) | more than 6 years ago | (#20123005)

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.

Re:Procedural Generation? (1)

mblase (200735) | more than 6 years ago | (#20123207)

Perhaps the author is confusing Procedural Programming with Procedural Generation?

He is (and he's the submitter, of course), and he amended a note to the bottom of the article saying so.

It's still bloody hard to read, though.

want to be "evolutionary"? (5, Interesting)

SolusSD (680489) | more than 6 years ago | (#20122535)

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.

Re:want to be "evolutionary"? (0)

Anonymous Coward | more than 6 years ago | (#20123017)

>Haskell (a programming language) is a good place to start.

I tried Haskell , but all the output kept complimenting my mother, June and insulting my younger brother, Theodore.

Mark Edwards
--
Proof of Sanity Forged Upon Request

All you need to read is this sentence... (5, Insightful)

Anonymous Coward | more than 6 years ago | (#20122537)

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

That pretty much captures how well the author understands programming.

Re:All you need to read is this sentence... (0)

Anonymous Coward | more than 6 years ago | (#20122663)

Exactly. I thought procedural programming was what we were all using before we started using OO programming. And in the explanation he lists actions in the list of objects. I think the actions would usually be methods available to certain objects.

That is NOT procedural programming (1, Redundant)

Bin Naden (910327) | more than 6 years ago | (#20122571)

What the writer is describing is NOT procedural programming but rather some sort of event-driven programming.

procedural generation anyone? (1, Redundant)

Xavier CMU (829477) | more than 6 years ago | (#20122607)

The article isn't even titled properly, the technique that spore uses is not procedural programming, it's procedural generation, which is a completely different concept http://en.wikipedia.org/wiki/Procedural_generation [wikipedia.org]

Re:procedural generation anyone? (4, Funny)

thefear (1011449) | more than 6 years ago | (#20122867)

From TFA:

So why can't this be used in games like spore? Well in games with so many options, the IF/THEN list becomes so long it becomes scrambled. Several calls to previous points in the list are made and the whole thing gets disorganized
Its not just the title, the entire article is written like that.

Article Sucks (5, Insightful)

jlarocco (851450) | more than 6 years ago | (#20122627)

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

Ever wonder about what? (0)

Anonymous Coward | more than 6 years ago | (#20122677)

Ever wonder what the hell "Spore" is in the first place? Slashdot articles won't help you.

Procedural Programming ? (0, Redundant)

jfclavette (961511) | more than 6 years ago | (#20122695)

Heh. The author probably meant procedural content creation, but even that is a stretch. There's certainly procedural animation too...

Reminds me of Elite... (3, Informative)

tcopeland (32225) | more than 6 years ago | (#20122727)

...that is, this game [mobygames.com] which had an "infinite" universe. The book Infinite Game Universe [amazon.com] has some good discussions of this sort of thing, too.

Re:Reminds me of Elite... (1, Informative)

Anonymous Coward | more than 6 years ago | (#20123163)

Elite had hundreds of systems on something like four galactic maps, but it wasn't infinitely generated. Usually one plied a route between just two or three systems and ground that over and over. It wasn't nearly as mission-oriented as elite 2 which had you running around all over the place. Far as I know, Elite just had the Constrictor mission (and not on all ports of the game), and even that chase was maybe a half-dozen systems.

The first thing I had to think about was: (1)

sveard (1076275) | more than 6 years ago | (#20122895)

How can anyone claim that procedural programming is better at generating dynamic content than object oriented programming? Then I realized this FA was BS.

Not infinite, finite (1, Redundant)

Paralizer (792155) | more than 6 years ago | (#20122969)

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?
It's not possible to have an infinite amount of states in a finite state machine (like our turing machines [wikipedia.org] ).

There will at most be 'a lot' of different combinations.

Re:Not infinite, finite (1)

OrangeTide (124937) | more than 6 years ago | (#20123085)

Exactly. to have an infinite amount of states takes an infinite amount of memory to represent the possible states. you're pretty much limited to less than 2^(2^32) states on a 32-bit machine. and in practice you'd never get anywhere near that.

People don't realize that a computer is just a container for a state. all the abstract layers of software and OS and whatnot are just a mechanism to move it to the next state.

Turing machines aren't finite state machines (0)

Anonymous Coward | more than 6 years ago | (#20123201)

That's why the halting problem [wikipedia.org] is undecidable.

This is ridiculous. (0)

Anonymous Coward | more than 6 years ago | (#20123029)

How the fuck did this make the frontpage?

Procedural Spam Marketing (0)

Anonymous Coward | more than 6 years ago | (#20123031)

Procedural Spam Marketing FTW!

Procedural programming (1)

Z00L00K (682162) | more than 6 years ago | (#20123055)

Is something that has been in use a long time - so it's not new. Anybody familiar with the classic programming languages Basic, Pascal, C and many more can't help that they feel familiar here.

Of course - since many today tend to do object oriented programming (for good and bad) the procedural programming may seem "fresh" for some.

And there are other programming areas that can be considered too;

The review is by communications majors (3, Funny)

whitroth (9367) | more than 6 years ago | (#20123067)

who literally know *zip*. I just dipped my toes in the article, and lines like "procedural programming is ... object oriented..." snapped any suspenders of belief I had in the article.

Of course, it'll be smaller and faster than Objectionably-oriented software....

            mark

I read the Fine Article (1)

ratboy666 (104074) | more than 6 years ago | (#20123115)

3 times, and I still can't make sense of it.

The author can't be talking about procedural programming in the classic sense. On a re-read, I suspect that "procedure" is somehow equivalent to "action". Especially the part about building weapons from components.

The implication is that "Spore" (whatever that is) has a calculus of action. Which (almost) makes sense. I imagine (again, back to the weapon example), that a cartridge contains "x" grams of explosive, that yeilds a force, acting on the ballistic component. That force must be containable by the barrel chosen, or the weapon explodes. Accleration can be computed, influenced by barrel length, and destructive force computed.

What I don't see is how these arbitrary physical limits are enforced. If they aren't, a handgun with the power of a howitzer could be constructed.

Re:I read the Fine Article (1)

doas777 (1138627) | more than 6 years ago | (#20123273)

yep. the misnomers were great. as many others have pointed out, this is not in fact about Procedural programming, but about Procedural Generation of content. it's really just event-driven OOP, using complex object inheritance principals to meld and blend derived objects together into a new thing, with it;s own approaches to finite tasks. this gives you modularity, and an appearance of infinite combinations. amusingly enough, I had to write about genetic algorithms a few weeks ago for school, and I can see how you might go about "evolving" an "organism" (or a binary-serialized object) through selection, crossover, mutation, etc. but no, the components the writer mentions are objects with their own event handlers, formated in such a way that they can be melded together to perform complex actions. fun stuff. hope it comes out soon.

What?! (1)

TheGeneration (228855) | more than 6 years ago | (#20123217)

What the hell is this article talking about? I can tell that the author either doesn't know how to program, or he doesn't know how to break it down into non-tech speak. Either way, the article doesn't make much sense.

As for procedural programming... I'm not sure how it would be possible to write an interactive multi-player procedural program without using the concept of an object. Especially when there is customization at the level that Spore claims to have. I really think perhaps the author of the article doesn't understand the difference between an object's method, and a non-object procedure/function.

Re:What?! (1)

Mr. Picklesworth (931427) | more than 6 years ago | (#20123411)

The article is talking about procedurally generated content [wikipedia.org] , which is what Will Wright was talking about with his very first presentation of Spore.
That is the creation of game content on the fly by the program, instead of previously by human artists. The difference is that procedurally generated content is dynamic and always changing, while the other (more common way) is always the same.

Procedural generation is a great way to achieve cheap content, which means bigger, more dynamic and interesting universes at less cost than with pre-made content.
Think how a text based (or 2D) game can give you a much more interesting world to explore than a 3D game, because the content takes less time and effort to produce. Spore is impressive for having a lot of really cheap content, generated with a really high level of quality to give an exciting experience.

Spore takes that easy content creation a step further by putting the tools in the player's hands, because the system they have designed is so flexible and so easy that anyone can use it!
Most regular game playing folk can not possibly create the type of expensive content as we see in works like Rage, which requires huge, dedicated teams and a lot of time to create. On the other hand, if the time of creating content is instead spent create a content system that anyone can use, the average player can create some really nice stuff.

The unexplored realm of dynamic content... (4, Interesting)

Mr. Picklesworth (931427) | more than 6 years ago | (#20123267)

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 my arbitrary events and "their" arbitrary events is that mine live in harmony with a system that is already flexible. The arbitrary special things are just icing. Having a flexible system beneath those arbitrary specials accepts that icing does not work without a good cake.

On the other hand, with easily generated player content that jumps to life, everything is already completely dynamic, so that over-simplicity and predictability of the game world is dealt with very smoothly, and in a personalized manner. It is like role-playing, but transparent so that the player does not think "I have to role play," but rather he is creating his own unique and exciting presence in the game world because that is the mechanic of the game. That is what Spore is unique in trying to achieve.

Add it to Zork, please!! (0)

Anonymous Coward | more than 6 years ago | (#20123381)

As I read of such procedural wonders as "throw fireball" and "drive your car" or "go to work", I was thinking of the power that this could have in the adventure game Zork.

My god, to think I was trying "open door" or "eat bread", when I could have used "Throw Fireball" or "Evolve self".

Please make my childhood complete by bringing these procedural programming wonders back to Zork. Please. Think of the children.

Just defining their algorithm (1)

ls671 (1122017) | more than 6 years ago | (#20123397)

Author is just defining their algorithm. An algorithm can be implemented in any programming language with any programming techniques. They may have a better algorithm or a better way to do things, but it has nothing to do with the tools and techniques they choose to implement it.

It is kind of like a sale pitch; because our product X uses technique Y, it will do everything automagically, you don't even need to know what you are doing, hence you don't even need an algorithm !

The author seems to be confusing algorithms with tools and techniques.

creates created? (2, Funny)

Afecks (899057) | more than 6 years ago | (#20123435)

A little help please? Does anyone have a slashdot-editor-to-enlgish translator?
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...