Saturday!

Jaybird

Jaybird is Birdmojo on Xbox Live and Jaybirdmojo on Playstation's network. He's been playing consoles since the Atari 2600 and it was Zork that taught him how to touch-type. If you've got a song for Wednesday, a commercial for Saturday, a recommendation for Tuesday, an essay for Monday, or, heck, just a handful a questions, fire off an email to AskJaybird-at-gmail.com

Related Post Roulette

17 Responses

  1. DavidTC says:

    For example, three years ago I talked about trees growing as time past. The team did code this but it took so much processor time (15%) that the feature was not worth leaving in. That 15 % was much better spent on effects and combat.

    Ah, Peter Molyneux. Even when he’s telling the truth, he’s lying.

    There is no possible way that ‘tree growing’ could take up *any* processor time. At all. It’s nonsense.

    Things do not ‘happen’ generally when they are not on screen, and you certainly wouldn’t have a *tree* do anything.

    What actually happens is the player gets close enough the game has to draw the tree, so it would look at the time the tree was planted, and select the correct object, the ‘tree object that is the correct age’, to render.

    Even if they were trying to do some insane thing with fractals and have the tree actually grow leaf by leaf, you still don’t run it when the tree is offscreen…or onscreen, for that matter. You generate exactly *one* new fractal every time the tree comes in range, which is a matter of milliseconds. Maybe you update it once a minute or something.

    Might I remind people that video games, even back when Fable was made, had *dozens* of people all wandering around and changing their position and what they were doing dozens of times a second? Hell, has anyone ever seen SimCity, where *thousands* of transit paths are calculated at once?

    There is no possible tree simulator that takes up *any* noticeable amount of CPU unless the thing is coded by drunken lemurs. Because you can’t possibly need to *run it* often enough.Report

    • Jaybird in reply to DavidTC says:

      The problem with something like “each tree is unique!” is that we all know some variant of the “every snowflake is unique” canard and even as we can look at a couple dozen snowflakes and see that each is, in fact, somewhat different from the others (based on some procedurally generated algorithm!), everyone who looks at any given one of these items will be able to say “yep, that there is a snowflake”.

      So even if he weren’t lying (which you demonstrated he could well have been), the thing that he was hyping as if it were awesome turned out to be something that, no matter how unique it would have been from every single other tree that anyone else might have planted in any other Fable game (and all their trees unique from each others’), they still would have been nothing more than “yep… that there is a tree”.

      Friggin’ Peter Molyneux.

      Though I still wish we had more of those like him.Report

    • Morat20 in reply to DavidTC says:

      There is no possible tree simulator that takes up *any* noticeable amount of CPU unless the thing is coded by drunken lemurs. Because you can’t possibly need to *run it* often enough.

      He was probably referring to the same type of problem that plagued Star Wars Galaxies, only he was referring to it badly (possibly because he didn’t grasp the reason himself, he was just repeating what the dev team said).

      In SWG, every item you could buy, use or equip was player generated. And by “player generated” I mean they gathered materials, built subsystems, and assembled finished items. A gun might contain two or three parts, each generated from two or three materials.

      And here’s the kicker — it was all unique. The materials? Randomly spawned with unique properties. The sub-systems? Their attributes were set based on materials used and a bit of random chance, so two attempts at “Pistol Barrel 1A” using the same materials wasn’t always going to be identical. (of course, the better your materials the better the outcome).

      And the final assembly was the same way.

      So any item worn by any character was utterly unique, had it’s own DB entry complete with attributes, and was built from 10 or 12 other bits all with their own attributes. That really killed their database times, because when you ran into someone (or god forbid, their house filled with stuff) you had to download a LOT of unique data really quickly.

      I’m not sure how much they optimized it over the course of the game — i mean, to be honest, furniture and decoration all turned out identical so there was no need for a unique ID (but I wouldn’t be surprised if they had them anyways) and you could do factory runs of a 1000 or so guns (you had to feed it identical parts for the gun) so you really only needed 1 ID for up to 1000 items, but I wouldn’t be surprised if they still made 1000 unique IDs. (The game had a lot of issues).

      Anyways, I suspect that the “growing tree” thing wasn’t rendering the tree. Or even keeping track of the tree. There was probably a huge subsystem devoted to change over time stuff and anything unique you could do that took up a ton of disk access and coding time that they killed. Everytime you loaded a view it’d have to see if you’d done anything unique (planted a tree, chopped down a tree, built a house or whatever else he promised you could do), add in the render, and keep constantly checking this ever expanding list of “Things you did that require the game to alter the basic landscape/view/whatever”.

      I suspect it was killing disk access as the list of unique things you did got longer and longer.Report

      • DavidTC in reply to Morat20 says:

        So any item worn by any character was utterly unique, had it’s own DB entry complete with attributes, and was built from 10 or 12 other bits all with their own attributes. That really killed their database times, because when you ran into someone (or god forbid, their house filled with stuff) you had to download a LOT of unique data really quickly.

        No you didn’t. You had to download a list of what their equipment looked like…which you would have to do no matter what.

        You don’t need to know *information* about their equipment at all. Your game copy is not determining how much damage a weapon does during an attack. (If it is, *that* was their problem.)

        Everytime you loaded a view it’d have to see if you’d done anything unique (planted a tree, chopped down a tree, built a house or whatever else he promised you could do), add in the render, and keep constantly checking this ever expanding list of “Things you did that require the game to alter the basic landscape/view/whatever”.

        Like…literally every other game does?

        Elder Scrolls IV: Oblivion was released 18 months after the first Fable.

        Oblivion had an open, changeable world. You could, for a major example, just leave things laying around, and they’d stay around forever. Note this was a world with *physics*, where every little book and flowerpot were objects *resting* on the game world, and you could move them.

        Every single object in that game was kept track of independently. You glance around an area, the game has to figure out where *hundreds* of objects are (The game groups by ‘cell’, blocks of space, so it at most has to pay attention to four at a time.), and a couple of NPCs, and the time of day, and if there are any blood splashes or combat damage to the scenery, etc, etc.

        You could build an entire crazy piles out of random junk in the world. These things would stay there when you left and came back.

        Over the *entire world*. 60 frames a second.

        Granted, they’d ‘reset’ cells if you stayed away for too long, but that was more ‘Let’s not have crazy huge save files’ and ‘All these corpses are a bit distracting’ than anything to do with processing power.

        Keeping track of ‘things you changed’ is half of the entire point of a game engine.

        Fable was *not* an open world. The idea it couldn’t keep track of *some trees* is insane.Report

        • Morat20 in reply to DavidTC says:

          No you didn’t. You had to download a list of what their equipment looked like…which you would have to do no matter what.

          Although let me rephrase: You didn’t HAVE to, but you did anyways. I mentioned it was a mess, right? Rubber-banding was awful because you’d load every bit of data on any character or house you’d pass, not just what you’d see, not just model data. I’m fairly certain they resolved combat server side, at least. (I have no idea WHY they did this, other than it was 15 years ago and MMORPGs were still pretty new — UO and Everquest was it, and SWG was definitely aiming at UO 2.0)

          All done in 2000 or so, and nobody really thought it through. (EVE, for instance, does a better job of ‘everything made by players’ but they don’t do unique, and you should see the DB stuff they have to run. They’re single-shard though, which is a whole ‘nother thing).

          Anyways, part of the problem here is you’re assuming optimum (or at least efficient) game engine — and particular one efficient at this thing in question.

          It doesn’t surprise me at ALL, as a developer, that a feature some other engine can handle trivially would eat up insane resources on another engine. Why it would might be anything from lack of skill from programmers, immature engine, engine optimization (you can’t be good at everything, and optimizing one thing can often have drawbacks elsewhere), to simply the first-pass being incredibly inefficient and it being cut rather than improved as deadlines drew near.

          I have no doubt that Oblivion’s engine (and Fallout 3s, and Skyrim’s) poured a TON of money and time into making that work and not bringing the game to it’s knees. Of course once they had it in place, they could take the core of it and continuing improving it and moving forward.Report

          • Morat20 in reply to Morat20 says:

            As for SWG’s inefficiencies — I have no doubt there was a reason they couldn’t fix it, as I don’t doubt they realized their problems quite clearly.

            Same with Fable and why whatever mechanism was also used for trees was eating up the processor.

            It was undoubtedly more a question of ‘How expensive is this to fix and is it worth it?”. Which every game ever relies on.

            Like I said, I don’t think he was lying — I have no doubt that whatever part of the game also handled the tree stuff was just crappy, buggy, and ate resources like a hog. But PR wise, saying “It was just too difficult for the engine” sounds a lot better than “It turned out to be a huge PITA, didn’t work well, and we don’t want to spend the money or time making it work”.

            His big problem was always promising “We’d like” features as “Must Have” features.

            Every software project EVER starts with a big list of features which gets pared down over the developmental process, some of them getting cut very late in the day. You shouldn’t pitch a game to fans based on your feature list six months into a three year cycle.Report

          • Brandon Berg in reply to Morat20 says:

            Combat is resolved server side to prevent cheating, isn’t it? I think that’s still standard today. They only trust the client software with cosmetic stuff.Report

            • Morat20 in reply to Brandon Berg says:

              Oh yeah. Always has been, way back to the original FPS. Otherwise, rampant cheating. 🙂

              I loved the crafting system of SWG, but the implementation was….problematic. And apparently integrated so heavily into combat (they’d originally designed it with the idea that if you made a pistol, and that pistol was used to kill a monster that generated XP, the crafter got some XP from it) that it had all this giant overhead they couldn’t take out easily.

              And clearly nobody min-maxed the outputs. Nobody thought “Okay, assume perfect materials at every stage, how powerful will this gun/armor/buff be?”.Report

  2. Morat20 says:

    I tried to play both Vampire: Bloodlines and Rollercoaster Tycoon 3, only to stop as I couldn’t remember how to play either.

    And didn’t feel like dealing with the tutorial. So I went back to Civ 5 and will try again this weekend.Report