I was wondering what the real cost of area transitions are to a player? To define what I mean by 'area transitions', I'm referring to when, in an action game or rpg, the player moves to the specific position of one map and ends up in a specific position of another map, and cannot interact with or see things across each of these boundaries. The alternative of this is of course a continuous map, where the player can move from anywhere to anywhere else without a hard transition or demarcation of one area to another.

The reason I'm asking is because implementing continuous play areas come with certain costs, both technical and artistic. However, if the player doesn't necessarily view scene transitions as a bother, then there is less of a reason to pay the costs associated with producing a continuous space.

What do you think? Do players care about this? If so, under what conditions and to what extent?

-edited to fix a few typos.

Obviously one cost is time. Lots of loading-screen-like transitions will force the player to spend a lot of time waiting around doing nothing, and probably getting bored. I can't tell you how annoyed I've been when I've had to exit/enter a building in a city in Skyrim twice in a row, spending nearly five minutes just because I forgot to leave some random item. Something that should have taken me a minute tops, suddenly took about five times longer.

It's also quite immersion breaking if the player finds a way to overcome the invisible walls between zones, and find themselves in limbo. Not to mention that depending on how your gameplay works, it may get the player stuck forever in limbo, ruining all progress (this happened to me in Arkham City after having beat the whole campaign, thankfully, but still was annoying)

I've also disliked how some games allow you to be in a position to affect another area (say, on top of a wall above a battlefield), but you couldn't affect the other area simply because it was 'another area' and you had to go load into it before you could affect it.

There's other issues too if your game is multiplayer. For example, in EVE and its open pvp nature, having specific entrance/exit points in a system causes them to act as choke points for player killings, traps, etc. In EVE its more or less a game mechanic they've worked in, but it's something I've always hated.

The only time I've really seen player feedback for a game is in GW2. That game is very much divided into areas - and quite the opposite of what most games in its genre are doing. I've only seen a few people complaint about the area transitions, but most were ok with it, especially given that the areas are quite large. I imagine if the areas were smaller, it would be a lot more annoying to the player. Well, I've also seen some random feedback from people regarding the next gen consoles, and how they expect no loading areas. Not sure if it's a make-or-break feature, but it can hurt your game if done horribly wrong.

There's also technical difficulties involved in making area transitions. The most obvious one I can think of is AI. If you have any sort of AI, friendly or otherwise, and they have to move at some point - follow/attack the player - you must either write the AI with the ability to use the area transitions, or to give the player a possible exploit if the AI doesn't follow through area transitions. I've seen some pretty bad issues in TES games with AI using area transitions. They get stuck right before exiting, I have to re-enter and push them, or they enter an area before me, and when I enter only a second later, I find they've seemingly disappeared, having advanced much further than the second difference between them using the door and me using the door would allow.

I think as long as you make the areas large enough, minimize the loading times. make the separations as natural as possible, and don't divide areas that look like they should logistically be the same area, the area transitions aren't a major problem. To each his own, but if any of those things above stick out in a game, I often start disliking the area transitions.

Milcho made some great points, and I'm going to comment with some of my own perspectives of some of them.

Obviously one cost is time. Lots of loading-screen-like transitions will force the player to spend a lot of time waiting around doing nothing, and probably getting bored. I can't tell you how annoyed I've been when I've had to exit/enter a building in a city in Skyrim twice in a row, spending nearly five minutes just because I forgot to leave some random item. Something that should have taken me a minute tops, suddenly took about five times longer.
...
I think as long as you make the areas large enough, minimize the loading times

This problem really depends on the scope of your game and the size of the areas. Gigantic 3D Monsters of games like Skyrim and the like are practically forced to have these transitions for the sake of only being able to have so many assets in memory at once. Another issue that wasn't really touched on here was that of the change of scale that occasionally happens between transitions, and those being the reasons for them. This is especially common in 2D games, but I'm sure it's done elsewhere too. How many times have you entered a house only for it to be this sprawling mansion once inside? Not having loading screens (unless you use some really fancy tricks ala something I'm sure Antechamber does, which would be disorienting anyways) means that your assets have to be to scale for whatever you want to be inside of those buildings / structures / caves / whatever.

In a smaller game, loading times are basically negligible (or should be anyways), and shouldn't negatively impact the user's experience. Unless an area is very large in your game, you are quickly moving between non-contiguous spaces, or there is a change of scale (town to world map in old RPG's, things like that) user experience could probably be improved by a fancy camera switch and streaming content in to the world. I know games like some of the later Tony Hawks did this (albeit poorly from what I understand) where you skated though long tunnels that connected their zones. Bar the player cheating and giving themselves super speed, (Conjecture) the new area would have time to load and unload old assets as they moved through the tunnel.

I've also disliked how some games allow you to be in a position to affect another area (say, on top of a wall above a battlefield), but you couldn't affect the other area simply because it was 'another area' and you had to go load into it before you could affect it.

This is huge, and should be avoided as much as possible in your game. If someone is forced to use frequent transitions for whatever reasons, I would much prefer to have awkward loading transitions between seemingly connected areas than being barred off because my skill / ability / whatever can't be used at range because it's at the border of a transition. (and makes sense to use it there.) Not only is it immersion breaking, but it's frustrating, more so than sitting around and doing nothing slightly more often in my opinion. Granted, no one likes loading times, but I don't want them to get in the way of my experience as I'm actually playing the game either. For example, some of the Zelda games do this poorly at times. (I'm talking older map tile based ones). It was more frustrating than anything to exit screen left, only to be faced with an immediate, obvious, 1x1 tile of space that you can walk around in that they decided to put on the other square. This was frustrating for two reasons! One. Now I have to wait (Even if it's super fast) and go back to where I was so I can find a way around, rather than just seeing it clear as day in the last 'room'. Two Now that map square is marked as visited as well! I didn't go there, I simply got a good view and went home. Granted, that's more of a level design flaw in my opinion that doesn't fit well with the constraints of the engine. If you have ideas for your levels, and are building the level loader / transitions around this world, take such things in to account!

carefully consider the costs of building a continuous world as opposed to a section or level based one. they may not be that bad. CAVEMAN is continuous, 2500x2500 miles in size, at 1 foot = 1 d3d unit scale. although continuous, it still draws the world terrain in 300x300 "chunks" generated as needed on the fly. the world is divided into 500x500 map squares of 5x5 miles each. each map square has its own d3d coordinate system 26400x26400 in size. a location in world coordinates is specified by (map_x, map_z, x,y,z). AI and graphics work across map squares. just do everything in world coordinates, then convert to camera relative just before frustum cull and draw. you can walk all the way across the world with no load screens.

CAVEMAN is continuous, 2500x2500 miles in size, at 1 foot = 1 d3d unit scale. although continuous, it still draws the world terrain in 300x300 "chunks" generated as needed on the fly

I can't tell you how annoyed I've been when I've had to exit/enter a building in a city in Skyrim twice in a row, spending nearly five minutes just because I forgot to leave some random item. Something that should have taken me a minute tops, suddenly took about five times longer.

Similar to that, Minecraft does a very similar thing, and I'm willing to bet Dwarf Fortress (Adventure Mode) does something akin to that as well. (Although to be honest, that game is a scary scary enigma. Toady probably doesn't even know how it works.) Depending on your game this could be a feasible (and in some cases even relatively easy to do) option. Even if your world isn't tile based or anything of the sorts, loading the world in to multiple 'chunks' of sorts could be a good step in reducing load times if you can pre-load some of the data before you cross that proverbial boundary in to another zone. Perhaps when a player gets within a certain distance of a predefined area transition assets that are smaller and quick to load are loaded? Though, this is more of a game programming issue rather than a design one in regards to how to tackle such an issue specifically.

With the Skyrim example though, the same technique could be used, even if there has to be a hard transition because of a change of scale. Generally the world in that game is one gigantic no-load screen block isn't it? Why is there no system of detecting that the player is near one of these boundaries and make a best attempt at loading assets that they might come in to contact with in the near future? This is especially the case of shared assets.

Player enters a town for the first time and has a quest to talk to the mayor of the town. Why not load assets like common beds, interior wall textures, things of that nature? On top of that, it's reasonable to believe the player will be visiting the town hall, so why not pull out more specific stuff while they're at it? The banners and conference room chairs could be loaded as well? (Assuming there is room in memory for all this extra stuff. Nothing trumps fast loading times like low memory and slow file read write speeds)

Loading time (transition delay). I think that's the most important "annoyance" factor.

Loading time (transition delay). I think that's the most important "annoyance" factor.

definitely.

a seamless world with zero load time is the ideal to be striven for.

while true zero load times are probably not possible on today's PCs, very low load times are.

you keep as many chunks as you can in ram, and page from disk as needed. keep the paging routines fast. uncompressed unencrypted binary blobs, basically a disk image of the chunk in ram.

the size of the chunk will determine load times. too small will thrash the hard drive, too big will cause loading delays.

the complexity of the scene in the chunk will also affect load times. a chunk with 4 meshes and 4 textures will load faster than one with 25 textures and 5000 meshes.

chunk size will also affect drawing speeds. larger chunks will include more objects that eventually get frustum culled. smaller chunks means more chunks to iterate through.

i've been getting good results with chunksize = 1/2 visual range. even with complex scenes.

if you want to get really fancy, you can do something like a continuous streaming background load routine on a separate thread that anticipates chunks required, and streams them into ram before they're needed. when you go to draw a chunk, if its in ram, you draw it, if the background loader didn't finish loading it yet, you just page read the blob in the foreground, then draw.