Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

The future is seamless, but it's not the near future

QuizzicalQuizzical Member LegendaryPosts: 25,564

Some people on this site dislike zoning and loading screens.  Actually, I think basically everyone dislikes it to some degree, and the only difference is that some really, really, really hate it, while others don't particularly care.  But even those in the latter camp would probably still prefer to do away with loading screens and just have everything load instantly.  In this thread, I'd like to explain why such loading screens are nearly essential today, but also why they won't be in the future.

There are a variety of technical limitations involved.  One is the difference between 32-bit and 64-bit programs.  The major limitation of 32-bit programs is that they can only address 2 GB of system memory.  Furthermore, it is unwise for a game to come close to using the full 2 GB available.  Memory usage bounces around a lot as players move to different parts of the world and there are more or fewer other players or mobs in the area.  If a game uses 1.5 GB on average, but some corner cases of having a bunch of players in the area briefly push memory usage up to 2.000000001 GB, the game crashes.  Players don't like crashing.  People can live with a bit of hitching if you have to use virtual memory now and then, but not crash to desktop.

So why not use 64-bit programs?  The problem here is that a 64-bit program will not run on a 32-bit operating system.  Not merely won't run that well.  Won't run, period.  Full stop.  If your game is 64-bit, then no one with a 32-bit OS can play it.  That includes nearly everyone running Windows XP, a large fraction of Vista users, and even more than a few Windows 7 users.  If you have both 32-bit and 64-bit versions, then the 32-bit version has to respect the 2 GB memory cap.  If you try to let the 64-bit version use a lot more, then you're basically developing the same game twice.  That's cost++;  So essentially all games are 32-bit programs.

So our first major technical limitation is that a game can only address 2 GB of system memory.  Pick your favorite MMORPG and find where it is stored on your hard drive.  See how much space the folder takes.  A lot more than 2 GB, isn't it?  Some games are smaller, but most newer MMORPGs will use a lot more than 2 GB.  Furthermore, that's probably compressed considerably, in order to save hard drive space.  The computer will have to do a fair bit of work to process the stored information to get it into the form needed during gameplay.  Even if the entire game can cram everything into 2 GB on your hard drive, loading everything into memory in the form needed during gameplay will take a lot more than 2 GB.  Thus, a game can't load everything into memory at once.

So why not load things into memory as they're needed?  Because it takes too long.  For a processor to get data out of L1 cache typically takes about 4 CPU cyles.  For L2 cache, about 20.  For L3 cache, about 50.  For system memory, about 200.  These numbers depend on the processor architecture, and other than for cache, a lot of other factors, too, but they're decent enough ballpark approximations.  The problem is that having to wait 200 processor cycles every time you want to grab some data is way too long, and will kill your performance.  Modern processors try to combat this by often allocating more die space to processor cache than they do to the processor cores themselves.  Without even cache available, performance will be terrible, because having to wait about 200 clock cycles to access data is way too long.

But what if the data you need isn't in memory?  What if you have to wait for it to come from a solid state drive?  Then you're looking at waiting for about 300,000 processor cycles.  That's right.  Not three hundred.  Not three thousand.  Three hundred thousand.  Having to do that once in a great while is fine.  If one data access in ten thousand needs to come off of an SSD, the game isn't going to be playable.

That makes SSDs sound really slow, doesn't it?  And compared to DRAM, they are.  But didn't you hear that SSDs were amazingly fast?  Well, compared to hard drives, they are.  Try to access information off of a hard drive and you're going to wait about 30,000,000 processor cycles.  That's right:  thirty million.  In the time a processor has to wait for data to come from a hard drive, it could have not merely multiplied two 64-bit integers.  It could have done so about thirty million times.  You really, really, really don't want to have to wait for that very often unless you absolutely have to.  When stated as 10 ms, it doesn't sound very long, but compared to how fast processors go, it's an eternity.

So the moral of the story is, everything that a game needs in order to play the game has to be already sitting there in system memory when it's needed.  Having to wait to get something off of a hard drive while you're playing the game is a no-go.  10 ms might not sound like long, but when you have to grab 20 things at once, now you're looking at the game completely stopping for a very noticeable amount of time before it can continue.

So you have to have everything in memory when you need it.  But you can't load everything at once.  This is a dilemma, isn't it?  The way out of it is to say, we'll figure out what we need far before we need it, and load it well ahead of time.  But how can you predict what you're going to need with 100% certainty?  That's what zones are for.  A game breaks up its map into a large number of zones, and keeps track of exactly what is needed for each particular zone.  Anytime you need to load a particular zone, the game knows, I need to load this exact list of stuff for this zone, and nothing else.

There are some things that aren't entirely predictable.  A game doesn't know which particular players will be in a zone.  But you can handle that by tricks like not displaying a player until you've loaded the graphics that you need for that particular player.  So long as players show up one at a time, it more or less works.  But as long as what you need stays well below 2 GB, no matter what zone you're in, the system works.

So why do games have loading screens?  The basic problem is that loading everything for a particular zone takes a while.  10 ms doesn't sound like much, but multiply it by 1000 textures to load for a given zone and you're at 10 seconds.  Rather than having the game simply freeze for a while Vanguard-style every time you cross a zone line, it's less jarring to show a loading screen.  Loading screens also let you use some simple placeholder graphics while in one zone to show what is in neighboring zones, rather than having to load a ton of extra stuff.

So how can you make a game seamless?  While players are in one zone, you can load the next zone in the background as the player moves around.  That way, by the time the player reaches the boundary to cross into the next zone, it's already loaded.  There's no need for a loading screen.

The problem with this is, how do you know which zone will be the next zone?  In a completely linear game such as Super Mario Bros., it is almost completely predictable that after a player is here, he must next go there.  If Mario chooses to go down a pipe rather than continuing to the right, the delay as Mario goes down the pipe function as a loading screen of sorts.

But you can't do this in an MMORPG very well.  That would make for far more linear gameplay than even having every single bit of content in the game squeezed into a single supremely long quest line.  You need to allow players some freedom to go where they want to go.  Knowing that a player is in one particular zone now could leave several options as to which zone he'll be in next.  If the game tries to guess and loads one particular zone, then what happens if the game guesses wrong and he goes to a different zone instead?

You can try to fix this by loading a zone as a player gets close to its boundary.  But what about when a player gets close to an intersection of three zones?  What then?  You can put up a ton of zone walls to make sure that that can't happen.  WoW does this, for example.  Even if flight paths go over zone walls, once you start a flight path, it's completely predictable where you're going for a while, so the game can load what you need on the flight path--and also load what you need in the zone where you're going to land.

Why not just load three zones at once, or four?  There are several problems.  First, remember the 2 GB memory cap?  With a loading screen every time you cross zones, you only have to fit one zone at a time.  If the way you're going to make a game seamless is to sometimes have four zones loaded at once, then all of those zones together have to fit inside the 2 GB memory cap.  That means you have a lot less memory available for each zone, so your graphics won't be nearly as good.

Second, it takes a while to load zones.  Time how long a loading screen takes.  Multiply that by the number of zones that you could conceivably enter next from a given zone.  Furthermore, a loading screen has the advantage that the computer isn't otherwise busy, so it can focus purely on loading things into memory.  If it's trying to load things in the background while playing the game, it might take a lot longer.  Think it can still always have everything loaded by the time you get to the next zone, no matter which zone you go to next?  Even if you're on your super speed mount?  Think that the other guy in your party with the nearly full and horribly fragmented hard drive that makes everything take several times as long can do so, too?

Third, loading the next zone isn't just a matter of copying things into memory.  Data needs to be decompressed and otherwise processed.  That means a lot of work for the processor to do.  While you're at a loading screen, the processor may not have anything better to do.  If you try to load things in the background while playing the game, then the processor is otherwise busy with rendering the game.  That could kill your game performance.

So why do I say that the future is seamless, if it has all of these problems?  Because all of these barriers are going away, but for different reasons.

The third problem is the simplest one:  get more processor cores.  If a game really only needs two processor cores to render the game well and you have four, then one of the spare processor cores can be devoted to loading things in the background.  The reason it's hard to make games scale to more cores is that different threads running on different cores can't depend on each other very much or else it just doesn't work.

But loading things in the background has a very light dependence on anything else that is going on.  If it takes hundreds of processor cycles to get the information on which zone to load next to the core that is handling zone loading, it doesn't matter.  If it takes a few billion processor cycles to get the information over there, it doesn't particularly matter.  It's very easy to put zone loading into a separate thread running on a separate processor core.  Or rather, that's a simplification of how things work; the game could easily put it into a separate thread, and then Windows allocates threads to cores as it sees fit, sometimes putting a number of completely unrelated threads on the same core.

The first problem of running out of memory requires two fixes.  First, the game needs to be 64-bit.  Second, the game needs to have a lot more than 2 GB of physical system memory available to it.  So we could see system requirements along the lines of 8 GB of system memory and a 64-bit OS.  Right now, a large fraction of gaming systems don't have that.  But some do, and more will as time passes.  A decade ago, a game that required 1 GB of system memory would basically have no audience.  Today, nearly all recent computers have at least that, and 1 GB of DDR3 only costs about a pro-rated $5 or so.  Give it several years and it will be okay to require 8 GB of system memory and a 64-bit OS to play the game.

The second problem is the most difficult.  Loading things off of hard drives is just too slow, and hard drives don't get meaningfully faster as time passes.  Sequential transfer rates do get faster, but sequential transfer rates aren't the problem.  The problem is that having to load a zillion small files and having to wait 10 ms for the hard drive to physically move to the right position before it can do anything for every single file simply takes a long time.  That's what makes loading screens take so long now, and as games get more complex, the time it takes is going to go up, not down.

The solution is solid state drives, which are nowhere near fast enough to replace system memory, but are plenty fast enough to make loading the next zone in the background completely viable.  But games are going to need not merely to require that players have a solid state drive, but to require that the game is running off of a solid state drive.  We could be in for a long wait before that becomes sufficiently ubiquitous for games to be comfortable with putting it in their system requirements.

Many gaming computers already have an SSD, of course.  But the problem isn't what enthusiasts buy.  It's what people who are clueless about hardware buy.  And they largely buy what companies like Dell and HP sell.  Such companies tend to sell what they think people who are clueless about hardware can be convinced to overpay for.  The easiest way that they've found to do this is big numbers in the technical specs.  For example, vastly more hard drive space or system memory than you'll ever plausibly need.  Those that really want to be disreputable will sometimes offer cheap junk power supplies with high nominal wattages.

On the bright side, this speeds the adoption of 64-bit operating systems and lots of system memory.  The problem is that they haven't figured out how to make people who are clueless about computers overpay for SSDs yet.  The impressively high numbers that SSDs can post are IOPS.  The problem is that people who are clueless about computers might know the difference between 1 TB and 120 GB, but they don't know the difference between 20000 IOPS and 200 IOPS.  SSDs are so far ahead of hard drives as to make the numbers sound fake.  They more often try listing things like 500 MB/s sequential transfer speeds.  But then people will look at this hard drive using SATA 6 Gb/s, and that sure sounds awfully fast, too.

Once SSDs become ubiquitous, we can have our seamless MMORPGs.  And I think that eventually they will.  If people who are clueless about computers can still understand that 8 GB of system memory might be better than 4 GB, then surely they can eventually learn that very high IOPS numbers are a good thing, too.  But it's going to take a while.  As the title of the thread says, seamless is the future, but not the near future.

«134

Comments

  • LarsaLarsa Member Posts: 990

    Older games with older technology managed to do seamless worlds just fine. An occasional stutter and otherwise you're fine.

    It's not a question of technology, it's a matter of game design. Current game design demands loading screens for these cutscenes, story-modes, battle arenas and other private instances. Do away with those and you can have a seamless world - keep those and you'll have loading screens.

    I maintain this List of Sandbox MMORPGs. Please post or send PM for corrections and suggestions.

  • QuizzicalQuizzical Member LegendaryPosts: 25,564

    Originally posted by Larsa

    Older games with older technology managed to do seamless worlds just fine. An occasional stutter and otherwise you're fine.

    It's not a question of technology, it's a matter of game design. Current game design demands loading screens for these cutscenes, story-modes, battle arenas and other private instances. Do away with those and you can have a seamless world - keep those and you'll have loading screens.

    You could still make games seamless the way that the old games did.  And the graphics would look like those of the old games, too.  A 2 GB cap on 32-bit programs isn't meaningful if a zone only takes 10 MB.  Needing 10 ms to load each texture is a lot easier if you have to load a hundred of them for a zone than a thousand.

  • EronakisEronakis Member UncommonPosts: 2,249

    I would agree with this. I would add that the future is single shard and seamless.

  • xDayxxDayx Member Posts: 712

    Mortal online is attempting to add a 64-bit client in their next expansion without building the same game twice. Of course there is still node-lines/chunk-lines.

    http://www.mortalonline.com/forums/74207-focus-group-community-update-week-2-a.html 

    http://www.mortalonline.com/forums/74952-away-while.html 

    I guess we will find out if its makes it to the live server.

  • VolkonVolkon Member UncommonPosts: 3,748

    I'm inclined to think the future will be zoned to be honest as content itself becomes more dynamic and complex. Dynamic events in GW2 are just the beginning. Rather than only having to know what's happening where people are, servers now will need to keep track of where events are whether or not people are there at all. They'll have to have events ongoing regardless of population, and as event density grows they'll need to consume more and more resources to do so. As such, I don't expect things to reduce to a single server or shard, or a zoneless world. I expect content to become much more intensive and dynamic, using the resources as they become available as the industry begins to grow in new directions.

    Oderint, dum metuant.

  • IAmMMOIAmMMO Member UncommonPosts: 1,462

    The solution to all future computer demands will be met by quantum computers, they can do the 1 and the 0 at the same time.

  • maplestonemaplestone Member UncommonPosts: 3,099

    2 GB is not enough?  It feels like only yesterday when needing more than 640K of memory was unthinkable.  So I'm not convinced you can outrun memory consumption.  I think you have to put your foot down at some point and say "this feature is important to us". 

    Google maps has solved this problem (caching, although costly relative to the size of what's displayed).  Minecraft has solved this problem (chunk management, give or take flipping through dimensional portals).  Spore has solved this problem (procedural generation of worlds from small data files).

    My feeling (right or wrong) is that as long as you say "graphics trump structure", the graphics will always expand to consume all available resources.  If so, unless seemlessness is made an axiom of the design, there will always be some new bottleneck that forces the use of loading screens.

  • QuizzicalQuizzical Member LegendaryPosts: 25,564

    Originally posted by Volkon

    I'm inclined to think the future will be zoned to be honest as content itself becomes more dynamic and complex. Dynamic events in GW2 are just the beginning. Rather than only having to know what's happening where people are, servers now will need to keep track of where events are whether or not people are there at all. They'll have to have events ongoing regardless of population, and as event density grows they'll need to consume more and more resources to do so. As such, I don't expect things to reduce to a single server or shard, or a zoneless world. I expect content to become much more intensive and dynamic, using the resources as they become available as the industry begins to grow in new directions.

    That's all server-side, and irrelevant to the topic at hand.  Servers moved to 64-bit and tons of memory a long time ago.  Servers don't care how long it takes to load stuff off of a client's hard drive.

  • maplestonemaplestone Member UncommonPosts: 3,099

    Originally posted by Eronakis

    I would agree with this. I would add that the future is single shard and seamless.

    The problem with a single shard is the speed of light.  There is a hard physical limit on how fast you can send a packet from one side of the world to the other no matter how good networks become and it's actually within the threshold of human perception. 

    Games like EvE can get away with a single shard because the mechanics are not twitch-based - you don't need to know the exact position of other objects in the game nor exactly what they are doing, the game can fake it a little with inertia.  In other games, this comes out as rubberbanding, speed-skipping, turboboosting, etc as clients fail to predict what the other clients actually did during that split-second of lag and have to make jarring corrections when they get updated information.

    I guess what I should say is that it's not impossible to do a single shard, but it does put some restrictions on how twitch/reaction-based you can make the mechanics of your game.

  • QuizzicalQuizzical Member LegendaryPosts: 25,564

    Originally posted by maplestone

    2 GB is not enough?  It feels like only yesterday when needing more than 640K of memory was unthinkable.  So I'm not convinced you can outrun memory consumption.  I think you have to put your foot down at some point and say "this feature is important to us". 

    Google maps has solved this problem (caching, although costly relative to the size of what's displayed).  Minecraft has solved this problem (chunk management, give or take flipping through dimensional portals).  Spore has solved this problem (procedural generation of worlds from small data files).

    My feeling (right or wrong) is that as long as you say "graphics trump structure", the graphics will always expand to consume all available resources.  If so, unless seemlessness is made an axiom of the design, there will always be some new bottleneck that forces the use of loading screens.

    That is a real concern.  But it's not just the memory limit.

    Years ago, when the 2 GB limit was completely irrelevant, people didn't commonly have extra processor cores just sitting there idle.  Now you can get a quad core processor in a cell phone or tablet.

    And we haven't gotten to see what game designers would do without the bottleneck of glacially slow hard drives since before you installed games on your hard drive.  That was a different era entirely, as few games were any semblance of 3D yet.  The last of it was probably the Nintendo 64 (which did move games to 3D), but that used cartridges that limited games to perhaps 8 MB or 16 MB of capacity.

    SSDs are going to be a huge deal, because being able to load the next zone quickly means that you can have more, smaller zones.  That will ease memory usage somewhat, too.  But if you design a game under the assumption that the client has an SSD, it might be unplayable on a hard drive.

  • VolkonVolkon Member UncommonPosts: 3,748

    Originally posted by Quizzical

    Originally posted by Volkon

    I'm inclined to think the future will be zoned to be honest as content itself becomes more dynamic and complex. Dynamic events in GW2 are just the beginning. Rather than only having to know what's happening where people are, servers now will need to keep track of where events are whether or not people are there at all. They'll have to have events ongoing regardless of population, and as event density grows they'll need to consume more and more resources to do so. As such, I don't expect things to reduce to a single server or shard, or a zoneless world. I expect content to become much more intensive and dynamic, using the resources as they become available as the industry begins to grow in new directions.

    That's all server-side, and irrelevant to the topic at hand.  Servers moved to 64-bit and tons of memory a long time ago.  Servers don't care how long it takes to load stuff off of a client's hard drive.

    Don't the servers still need to be able to send what's happening to your computer however? A static world, less info to send, less is going on. A dynamic world, a lot more going on, a lot more info to share. There has to be a line somewhere where either content is throttled back by zoning or by not existing, doesn't there?

    Oderint, dum metuant.

  • HomituHomitu Member UncommonPosts: 2,030

    Great informative post!  Bookmarking for future reference. 

    An obvious question does come to mind, however: how is a game like WoW, which has (aesthetic style aside) done a great job of updating its graphics with each expansion, able to create full continents with no loading screens?  It would seem there is just as much, or nearly as much data to load in WoW as in other MMOs.  Moreover, WoW is known as one of the most highly performing, low-spec friendly MMOs on the market.  What exactly does this game do that others do not?

    I would seem plausible (to someone with no knowledge of this stuff, like myself) that each geographic zone could be subdivided into several, much smaller "data zones" that could be loaded in the background as the player approaches them, as you suggested could occur with entire zones.  At any given time, the player could have 8 or so of these smaller data zones loaded and ready to go, the sum of which would be no greater than one full zone.  Something like this could add a lot of flexibility to the system you suggest, and allow the player to freely roam anywhere without encountering loading screens or pauses, even across geographical zone boundaries. 

    -------------------------

    As a closing comment, it occured to me that another thing that will likely impede the immediate ubiquity of SSDs, even among gamers, is simple knowledge of the fact that many games won't be making meaningful use of them in the near future.  It's a rather vicious circle of complacency.  Developers won't produce for upgraded parts because the majority of players don't own PCs with those parts; and players won't purchase PCs with those upgraded parts because immediate games aren't being produced that require them. 

  • killion81killion81 Member UncommonPosts: 995

    Originally posted by Homitu

    As a closing comment, it occured to me that another thing that will likely impede the immediate ubiquity of SSDs, even among gamers, is simple knowledge of the fact that many games won't be making meaningful use of them in the near future.  It's a rather vicious circle of complacency.  Developers won't produce for upgraded parts because the majority of players don't own PCs with those parts; and players won't purchase PCs with those upgraded parts because immediate games aren't being produced that require them. 

     

    All games makes use of them.  Buy an SSD, install a game or two on it and play.  Something like Skyrim suddenly has an extremely short loading screen.  Even older games will load from disk more quickly.

  • QuizzicalQuizzical Member LegendaryPosts: 25,564

    Originally posted by Volkon

    Originally posted by Quizzical


    Originally posted by Volkon

    I'm inclined to think the future will be zoned to be honest as content itself becomes more dynamic and complex. Dynamic events in GW2 are just the beginning. Rather than only having to know what's happening where people are, servers now will need to keep track of where events are whether or not people are there at all. They'll have to have events ongoing regardless of population, and as event density grows they'll need to consume more and more resources to do so. As such, I don't expect things to reduce to a single server or shard, or a zoneless world. I expect content to become much more intensive and dynamic, using the resources as they become available as the industry begins to grow in new directions.

    That's all server-side, and irrelevant to the topic at hand.  Servers moved to 64-bit and tons of memory a long time ago.  Servers don't care how long it takes to load stuff off of a client's hard drive.

    Don't the servers still need to be able to send what's happening to your computer however? A static world, less info to send, less is going on. A dynamic world, a lot more going on, a lot more info to share. There has to be a line somewhere where either content is throttled back by zoning or by not existing, doesn't there?

    Yes, but that isn't zoned.  A server can't tell you everything that is going on in an entire zone all at once, as that would overwhelm your bandwidth.  Rather, it picks out what is going on near you and only sends you that.

    The difficult data to send is the stuff that changes rapidly.  The precise location of characters is one such thing, as you can't just send that once per second.  You have to send data on what characters are doing (current position, direction facing, using a skill or item, etc.) a bunch of times per second, and you have to do that for every single character near a player.  That's the big bandwidth problem.

    Sending information about whether a dynamic event is underway or not, and how far it has progressed, is trivial by comparison.  The data on how a dynamic event works is already on the client, as part of installing the game.  All that the server needs to send for a particular event is whether the event is underway or not (which can be a single bit) and how far the event has progressed (maybe a few bytes).

  • MMOman101MMOman101 Member UncommonPosts: 1,787

    64-bit OS, more ram, and not paging data can all help.  There is a switch you can put in your bot.ini file to allow applications to access 3g of ram.  Obviously games can alter that though.

    The better graphics get the harder it is for a world to seem seemless.  It would be great if a company would build an OS specifically for gaming.  MS products tend to be very bad for it by their very nature.  I just don't know if the market would support it and if the game developers would trust it. 

    “It's unwise to pay too much, but it's worse to pay too little. When you pay too much, you lose a little money - that's all. When you pay too little, you sometimes lose everything, because the thing you bought was incapable of doing the thing it was bought to do. The common law of business balance prohibits paying a little and getting a lot - it can't be done. If you deal with the lowest bidder, it is well to add something for the risk you run, and if you do that you will have enough to pay for something better.”

    --John Ruskin







  • QuizzicalQuizzical Member LegendaryPosts: 25,564

    Originally posted by Homitu

    An obvious question does come to mind, however: how is a game like WoW, which has (aesthetic style aside) done a great job of updating its graphics with each expansion, able to create full continents with no loading screens?  It would seem there is just as much, or nearly as much data to load in WoW as in other MMOs.  Moreover, WoW is known as one of the most highly performing, low-spec friendly MMOs on the market.  What exactly does this game do that others do not?

    There are several tricks that WoW uses.  First, it will start by having less data that it needs to load than a lot of games.  If you reuse characters so that a large number of characters look exactly the same, you only have to load that particular character once for a zone.  If a particular character spawns in 30 different places in the game in total, it won't seem like the game is completely overflowing with them.  If they're all in the same zone, then you have to load the texture maps for that character only once in that zone and never otherwise.

    Notice how different WoW zones have very different themes?  The idea is that you can get a lot of graphical variety by making Ungoro Crater look very different from Teldrassil or Loch Modan.  If you reuse a particular tree or rock a hundred times in a zone, you only have to load it once for the entire zone.  You can reflect it or rotate it to add to the apparent variety, while still only needing to load it once.

    The level of detail also makes a big difference in how much a game needs to load.  Lower polygon counts and lower resolution textures mean less stuff to load into memory.  So WoW probably has to load a lot less for a given zone than you might naively think it does.

    Next, how do you travel from one zone to the next?  Is it some huge wide border that you walk across?  No, it's narrow passageways that really don't have anything there.  You know what it's doing as you walk through that?  It's loading the next zone.  And it's doing so while the processor isn't terribly busy, as it doesn't need to display anything fancy.  As you get close, it knows that it might need to load the next zone.  But there's only one other particular zone that it might need to load, and it has a fair bit of time as you go along the very wide boundary between zones.

    What about flight paths, you ask?  Don't those cross right over the middle of mountains, and traverse zones quickly?  Yes, they do.  But they follow completely fixed routes.  The game undoubtedly has something stored of exactly what graphical assets it needs for each particular flight path.  As you go along a flight path, the game is loading things into memory for what you'll need along the path, and also for the zone that you'll end up in.  And here, if there's some hitching, it doesn't matter, so it can go all out on loading things, and not have to worry about it messing up the process of rendering the game.

    And then you can also ask, is a lengthy area of essentially empty land between adjoining zones really better than a loading screen?  The loading screen might well get you to the next zone faster.

  • ClerigoClerigo Member UncommonPosts: 400

    Originally posted by Quizzical

    Originally posted by Homitu

    An obvious question does come to mind, however: how is a game like WoW, which has (aesthetic style aside) done a great job of updating its graphics with each expansion, able to create full continents with no loading screens?  It would seem there is just as much, or nearly as much data to load in WoW as in other MMOs.  Moreover, WoW is known as one of the most highly performing, low-spec friendly MMOs on the market.  What exactly does this game do that others do not?

    There are several tricks that WoW uses.  First, it will start by having less data that it needs to load than a lot of games.  If you reuse characters so that a large number of characters look exactly the same, you only have to load that particular character once for a zone.  If a particular character spawns in 30 different places in the game in total, it won't seem like the game is completely overflowing with them.  If they're all in the same zone, then you have to load the texture maps for that character only once in that zone and never otherwise.

    Notice how different WoW zones have very different themes?  The idea is that you can get a lot of graphical variety by making Ungoro Crater look very different from Teldrassil or Loch Modan.  If you reuse a particular tree or rock a hundred times in a zone, you only have to load it once for the entire zone.  You can reflect it or rotate it to add to the apparent variety, while still only needing to load it once.

    The level of detail also makes a big difference in how much a game needs to load.  Lower polygon counts and lower resolution textures mean less stuff to load into memory.  So WoW probably has to load a lot less for a given zone than you might naively think it does.

    Next, how do you travel from one zone to the next?  Is it some huge wide border that you walk across?  No, it's narrow passageways that really don't have anything there.  You know what it's doing as you walk through that?  It's loading the next zone.  And it's doing so while the processor isn't terribly busy, as it doesn't need to display anything fancy.  As you get close, it knows that it might need to load the next zone.  But there's only one other particular zone that it might need to load, and it has a fair bit of time as you go along the very wide boundary between zones.

    What about flight paths, you ask?  Don't those cross right over the middle of mountains, and traverse zones quickly?  Yes, they do.  But they follow completely fixed routes.  The game undoubtedly has something stored of exactly what graphical assets it needs for each particular flight path.  As you go along a flight path, the game is loading things into memory for what you'll need along the path, and also for the zone that you'll end up in.  And here, if there's some hitching, it doesn't matter, so it can go all out on loading things, and not have to worry about it messing up the process of rendering the game.

    And then you can also ask, is a lengthy area of essentially empty land between adjoining zones really better than a loading screen?  The loading screen might well get you to the next zone faster.

    This image

    Then yet again it isnt hard to perceive that if you play an MMO with high character customization and you are opting to play it with high quality textures for everyone around you, the time it takes to load 50 players around you looking all shinny and different is simply staggering. Take that in account if we talk about loading a zone full of them. Now imagine if you are crossing the plane, with no loading screen, and you get hundreds of players in that spot? Imagine a PvP area where you can walk to it, with no loading screens, and there are 500 players there? The time it would take to load all that would make you hammer your keyboard untill you could actually see whats going on in the field.

  • Seamlessness is a myth.

     

    There is no spoon.

  • ClerigoClerigo Member UncommonPosts: 400

    Originally posted by gestalt11

    Seamlessness is a myth.

     

    There is no spoon.

    image

  • xDayxxDayx Member Posts: 712

    I think this thread wouldnt be complete without mentioning the fact that zones tend to make the world less lifelike. They put like level mobs in one zone and you stay there until level x. Then move onto the next.

    I think alot of people would rather have a seamless world, with mobs of different strengths scattered throughout. Where there is grey area between what is a group mob and what is a soloable mob.

    My hope of the future is one with migrating mobs, mobs that see each other as food sources, etc, as they have tried to do with past games but never truly pulled it off, yet.

  • KenFisherKenFisher Member UncommonPosts: 5,035

    Agreed.  The issue I see is that artwork is outpacing engine capabilities on the current average level of hardware.

     

    In fact, I'd go so far as saying that artwork is killing games in general because artwork is now more important than gameplay.  As long as this stays the trend, we'll have great looking games that aren't great games.

     

    edit:  I think TES is probably one exception to this rule in that they have always done an excellent job of balancing artwork and gameplay.  It seems to have worked well for them.


    Ken Fisher - Semi retired old fart Network Administrator, now working in Network Security.  I don't Forum PVP.  If you feel I've attacked you, it was probably by accident.  When I don't understand, I ask.  Such is not intended as criticism.
  • ladyattisladyattis Member Posts: 1,273

    And here's my rebuttal as a person working on my masters in Computer Science.

     

    Bandwidth is not the bottleneck (SSDs or your network connectivity). The bottleneck is in leveraging concurrent programming. Many programmers today still don't know how to use concurrency nor how to use it effectively if they do know some of the idioms for it. That's why Google created a whole language (Go) for the purpose of making concurrency easy to understand for programmers. So, the technical ability of every PC today can easily support dynamic streaming of zones and multiplayer events (actions, movements, etc). Even a Pentium 4 was designed with concurrency in mind despite its flaws and those programs designed to exploit its hyperthreading did better than those that couldn't (The same for Core-2 Duo). Ultimately, programmers today are just not up for the task of delivering on promises. It's not artwork, nor your PC, it's the programmers and the terrible education (or rather mis-education) they've received at US universities. Maybe in another decade when the universities understand that computer science is about logical idioms and not the specific languages which can express those idioms then you'll get capable programmers and game designers. Until then, expect failures.

     

  • QuizzicalQuizzical Member LegendaryPosts: 25,564

    Originally posted by ladyattis

    And here's my rebuttal as a person working on my masters in Computer Science.

     

    Bandwidth is not the bottleneck (SSDs or your network connectivity). The bottleneck is in leveraging concurrent programming. Many programmers today still don't know how to use concurrency nor how to use it effectively if they do know some of the idioms for it. That's why Google created a whole language (Go) for the purpose of making concurrency easy to understand for programmers. So, the technical ability of every PC today can easily support dynamic streaming of zones and multiplayer events (actions, movements, etc). Even a Pentium 4 was designed with concurrency in mind despite its flaws and those programs designed to exploit its hyperthreading did better than those that couldn't (The same for Core-2 Duo). Ultimately, programmers today are just not up for the task of delivering on promises. It's not artwork, nor your PC, it's the programmers and the terrible education (or rather mis-education) they've received at US universities. Maybe in another decade when the universities understand that computer science is about logical idioms and not the specific languages which can express those idioms then you'll get capable programmers and game designers. Until then, expect failures.

     

    In one sense, you're right.  It is possible to cover up hard drive access times a lot better than games now do.  It is possible to create a seamless world that will run just fine on the hardware that gamers commonly use without the graphics looking clearly inferior to zoned competitors.

    The problem is, that something desirable can be done does not automatically mean that it is smart to try.  What happens if you try to create a seamless world without any tricks like "here's an empty spot in the world where we can stop to load things"?  And what if you don't cover up the hard drive access times very well, so that the game engine sometimes has to stop and wait for you to grab something off of the hard drive?  Now you've got a game that won't run very well on most gaming computers out there, even at low settings.  That's catastrophic, and dooms your game to be a commercial failure.

    There are a lot of reasons why a game might not be coded as well as you'd like.  Maybe your crack programmer who would do that part of the engine isn't as good as you thought he was.  Maybe he leaves the project halfway through and the next guy can't follow what he was doing.  Maybe pressure from the publisher to hurry up causes mistakes that would otherwise have been avoided.

    If you try to make a game seamless and succeed via clever programming, then the game is a little better than it would otherwise have been.  If you try to make it seamless and fail because you just can't hide the hard drive accesses well enough, then nothing else matters and your game is a failure.  If you think there's a 50% chance that it will succeed, do you try it?  80%?  90%?  No, no, and no.

    So why do solid state drives change this?  Because grabbing things off of a solid state drive can happen quickly enough to not cause any noticeable hitching.  If you try to cover up hard drive access times and load things on the fly, and don't do a very good job of it, people running the game off of an SSD won't notice.  The game will still seem smooth to them, because the penalty of waiting on a slow hard drive is about two orders of magnitude less.  If the game stops rendering for 200 ms while you try to load something, you've got a big problem.  If it stops for 2 ms, no one will notice.

  • bobbymobobbymo Member UncommonPosts: 48

    We love your love for SSD Quiz, and we all KNOW the benefits of having one, but seriously, the speed difference is so small in gaming that no one will know the difference(regardless of coding). Yes, zones will load faster, but not fast enough to change the outlook of an entire game. Your wild praising of the SSD hard  drive has gone from questionable to downright weird.  Now, tell us all and don't lie, if someone has 4 memory slots available on a dual channel memory motherboard, and they have 2x 4gb, and 2 x 2gb(in the coresponding slots)  do they have mis-matched memory???

  • QuizzicalQuizzical Member LegendaryPosts: 25,564

    Originally posted by Clerigo

    Then yet again it isnt hard to perceive that if you play an MMO with high character customization and you are opting to play it with high quality textures for everyone around you, the time it takes to load 50 players around you looking all shinny and different is simply staggering. Take that in account if we talk about loading a zone full of them. Now imagine if you are crossing the plane, with no loading screen, and you get hundreds of players in that spot? Imagine a PvP area where you can walk to it, with no loading screens, and there are 500 players there? The time it would take to load all that would make you hammer your keyboard untill you could actually see whats going on in the field.

    Suppose that you have ten texture files and you know that whenever you use one, you'll use all ten.  You can bunch them together so that when you load those ten files, provided that the hard drive is properly defragmented, you only pay the ~10 ms penalty of waiting for the hard drive to spin to the right spot once, and then you get all ten texture files together.

    The problem is that with players, you can't do that.  If players can choose their helmet, chest piece, gloves, boots, leg armor, face, hairstyle, and various other customizable bits independently, then you can't bunch everything together to load it all at once.  Rather, you wait 10 ms for the hard drive to spin to the right spot, load one file quickly, wait 10 ms again, load the next file quickly, and so forth.  If you have to load ten textures and wait for each, then now you're looking at 100 ms to get the textures for a single player.

    That's why players are harder to display than mobs.  You can plan things out so that you know the exact look of every piece of gear on a mob, but you can't do that for players unless you disable customization entirely.  That's how you end up taking a long time to load data for a bunch of players at once.

    But it's also the reason why a solid state drive is the answer.  A solid state drive means that rather than having to wait 10 ms for the hard drive to spin to the right spot, now you only have to wait perhaps 0.1 ms.  If you need ten independent texture files for a player, then you're at 1 ms.  Even if your game engine isn't coded very well and completely stops everything while waiting for the player textures to load, it doesn't cause any noticeable hitching.

Sign In or Register to comment.