Slashdot Mirror
Patience, Grasshopper - On Long Load Times For Games
Thanks to GamerDad for its editorial discussing the thorny, still present problem of long videogame loading times. Although the author points out "It used to be worse than it is now. I do count some of my blessings", he still argues: "I know that optimizing load times is probably low on the list of priorities when developing a game... [but] if you load the game so quickly that no one knows it's happening, or keep it streaming in chunks to not interrupt the flow of play, the player will be far more immersed in what's happening in your game and less likely to ever put it down until forced to do so." In conclusion, it's even suggested that a return to game cartridges might be a good thing: "You just can't beat that instantaneous gratification of playing games you just plug in, turn on and play. When the capacity is there for today's games, a return to carts would make me one happy gamer."
Have people here played Jak'n' Daxter (or Jak II) on the PS2 ?
It features an enormous world, with many levels. And no loading time
between them. Roaming around the world, and among diffrent levels etc. is totally smooth.
Developers got a thing or two to learn from it.
We are so spoilt with all the multi-gigabyte data that fits on modern media like DVD's. If we would go back to cartridge based games we would have to sacrifice all that FMV goodness and the orchestrated multi-track soundtracks that are able to fit on a DVD. Producing a cartridge is a lot more expensive that producing a DVD. You will have to manufacture large quantities of ROM chips to imprint with the game information to equal the storage capacity of a DVD. I don't think people are willing to pay that much more for a cartridge based game.
What i do like about the cartridge is the fact that they will stand the test of time much better than our slowly corroding DVD and CD media. I think all my old Atari 2600 carts will still boot. Something i can't say about some of my older Sierra cd-rom games on my PC.
Loading times always were Nintendo's advantage: in the elder days of NES and SNES, were all other console makers used modules as well this they were doing as well as all others, but later on this changed.
I remember when the N64 came out that a lot of discussion went on as to why Nintendo held on to modules, instead of using discs like the Dreamcast and Playstation did which can hold MUCH more data than ROMs for a way smaller production costs.
Surely one reason for using modules were the almost non-existent load times, another was better copy protection. (Also, modules allow to extend the hardware of the main console, late SNES games sometimes feature coprocessors that were faster than the main processor... you can't do that with a disc).
Then with the GameCube Nintendo had to use discs as well, simply because of the way bigger capacity. But they did it good, IMHO: they are using their own propietary disc format which makes copying way harder than Sony's discs. And when you're playing games like Zelda: The Wild Wanker ;-) you'll also notice they managed to keep load times quite low compared to the Playstation 1/2. I was really impressed.
But not only the hardware is important here, good programming is well: I played Puzzle Bobble: Bust-A-Move yesterday (PS2) and was really annoyed how long this simple game loads. The way more complex Final Fantasy X and X-2 loads quite fast.
I guess I'm imagining the fact that new N64 games were always an average of $20 more expensive than new PSX games, then.
Rob
I have heard that the official GC devkit uses a media that behaves like GC discs which makes load time bottlenecks blatantly obvious to developers. Any truth to this?
This was back when Pentiums and Windows 98 were the norm, so that was our target. We were mostly loading 2D graphics and sound effects. Enough that it could take anything from 20 to 60 seconds to load the next level -- quite unacceptable.
We did two things to improve loading time. The first was to reduce the perceived loading time -- instead of just a static picture, we changed the screen to be a rendered animation of the main character walking towards the next level. The animation frames were driven by the internal loading progress, so he walked rather haltingly, but it was effective.
The second was to use memory-mapped files. We put each level's files into a single, uncompressed, indexed file (a simple idea used, at the time, by Id's games) -- each a hundred megs or so -- and I then modified the code to map the level file into memory, and let each object (sound effect, animation frame, etc.) merely set its internal pointer to somewhere within the mapped region. In short: We handed the entire task of loading to the operating system. The load time was now near-instantaneous.
What really surprised me was how little impact this had on overall performance -- we had hundreds of animation objects on screen and lots of layered sound effects, and the frame rate hardly budged. For the first second or two, as each object access triggered a page fault, the frame rate would crawl a little, but we quickly solved that by pre-loading the largest and most commonly used objects.
The speed of memory mapping was particularly surprising considering it was Windows 98, not particularly well known for its sturdy virtual memory manager.
I'm sure memory mapping is a popular technology among game developers. More recent 3D games probably have their own, specialized VM systems. Far Cry, in particular, is impressive in the way it leads the player through huge (by current standards) landscapes, with no perceptible loading pauses.
For comparison, the average N64 cart was either 128 or 256Mbit. That was 1998-2001. The Neo-Geo could only address 330Mbit of cart space, but when SNK figured out how to bankswitch, cart sizes went up like crazy. The largest Neo-Geo cartridge was a whopping 807Mbit, nearly 3 times as big as the average N64 cart.
503 Sig Unavailable
The Signature could not be accessed. Please try again later or contact the administrator
Perhaps you're thinking about Ridge Racer, whose loading sequence contains a miniature Galaxian game.
Lastly, I think we need to think about other aspects of the game that are annoying - for example, saving. Usually a manual thing, and in some games horribly obnoxious to do, requiring much digging through menus and confirming overwriting of our previous saved game. Hello?!? Most of the time, yes, I want to overwrite the previous saved game. Is the problem avoiding overwriting your kid brother's saved game?
Speaking as a developer who's recently coded up this sort of thing for a console game, it's done that way because someone, in one of the console owning companies, decided that nothing irreversible should be done without confirmation. It probably sounds good in a meeting, then it gets written up in a somewhat ambiguous standards document. Because the wording is a bit ambiguous, when developing that part of the game, you have to err on the side of caution, and make it really confirm *everything*. Failing the Sony/MS/Nintendo submission process will set back your entire release schedule by a month or more, and cost you sales and money, so you really have to get it right first time. That means, you go overboard, just in case the person in charge of reviewing your game for submission happens to be particularly anal. (And I've heard of some games getting rejected for incredibly stupid reasons that no sane game player would consider a problem for a second.)
What about the corporate logos at the beginning of the game that can't be skipped? While I realize that there's almost no chance that they'll go away, what ifthe game instantly loaded your previous saved game and showed you the logos when you enter the game? (This would also mean missing out on neato main menus and title music, so maybe this wouldn't go far).
There's standards on this stuff too, mostly based on the idea that everything has to be 'accessible' to the non-gamer, while still fulfilling legal requirements on acknowledging the owners of the IP related to the game.
There's certainly a lot of room for improvement in all this area of games, I have a few ideas for how to do things differently on my next project. But resources on developing a game are limited. Early in the project, we have to decide if it's worth dropping that extra creature or graphical effect to free up the programmer time to make the loading system more transparent. Sometimes we make the wrong choice.