As the title suggest, I was wondering just how large a landmass a console could generate (Both current and next gen). I wanted to make a rather simplistic game that had a large landmass. So, for example, you took skyrim, removed the npcs, removed the dragons, the mobs, the respawn scripts and turned it into a sprawling continent, with a semi destructive environment similar to battlefield 3's frost engine and a simplistic crafting system like minecraft's. Graphics wise, i was thinking something like Deus Ex/Skyrim-esque with modern skyscrapers (completely intact and capable of ascending) and farmland/forest/lake on the outskirts with towns and villages scattered inbetween as well as the inevitable unending ocean so as to stop ppl from traveling too far.
Maximum Landsize in a console game
That's probably limited less by the hardware specifics and more by how clever you are about streaming it in, modifying, and storing it. Even consoles of the out-going generation are more-or-less capable of rendering as much geometry as you could reasonably want to render at once, with reasonable LoD, if you're clever about it.
What a console of the outgoing generation (and to a lesser extent, incoming generation) can't do, is actually keep the entirety of the land-mass living and breathing. Minecraft, for example, only updates blocks that are in the same zone (and neighboring zones?) as a player are updated -- in Minecraft, the answer to the age-old question "If a tree falls in the forest, and no one is around to hear it, does it make a sound?" is "No." -- In fact, the tree will never fall *unless* someone is around to hear it.
So, I guess the practical answer is that as long as you're smart you can persist as much as you can store, you can keep-live as much as you can process, and you can display more than enough on the outgoing and incoming consoles.
So say I created a game of the same exact scale as.. the United States. So long as I stream it cleverly/smartly?/correctly, I could have a playable world of epic proportions? I guess in that sense I start running into storage issues... which is what you were saying.
No big open-world type games today (from minecraft, to GTA, to Skyrim) actually run the entire world at once, or even have the whole thing idle, sitting in memory. In essence, they run only the part of the simulation that is visible to the player. If it's not visible, it exists and may have state, but its not being actively updated and its probably sitting on the disk rather than in memory. All of these games load only the chunks of the world that are visible, and only process the simulation on those chunks, and perhaps a few more. As long as the player doesn't see the inactive part of the world, it doesn't ruin there sense that things are happening in unseen places.
Once you have a system for managing the loading and unloading of those chunks on demand, the size of your world is essentially only limited by how many of them you can store on disk, and the number of chunks that are actively being processed and (optionally) rendered is limited by the amount of RAM they consume and by how much processing power their simulation consumes -- This is a hardware limit, but even the outgoing generation of consoles had enough RAM and CPU cycles to process enough chunks to provide a fairly convincing representation of a huge, seemless, always-running world.
The large-scale seemlessness of these games is smoke and mirrors, but like any good magic trick, the audience is fooled as long as you don't let them peek behind the curtain.
Thanks! I guess with that in mind, I can be a bit more "generous" with my designing, so long as I or someone else handles it properly. I'd rather have it all in one "world" so as to avoid loading small houses just because there was a door ya know? I hated that in Fallout and never really gave me much incentive to explore those small shacks because loading on consoles was sooooo slow.
Just to note, there still are design limitations imposed by the amount of memory which can impact this kind of thing, even if the technical solution exists. For example, if you're in an outdoor area and the outdoor textures already consume a large amount of memory, and the player goes indoors where the textures are entirely different and also consume a large amount of memory, then you may not get a super-seamless transition. In practice, this is part of the reason why some games that already stream large geographic areas sometimes still have load-times when moving between areas that have drastically different visual appearances. Textures consume, by far, the majority of memory in most graphically-rich apps -- not geometry -- so its really how different the applied textures are that is the practical limit of streaming game areas, rather than the size or detail of the geometry.
There are things that can be done to mitigate this, like inteligently pre-loading the textures that will be needed at a smaller size (to reduce memory footprint), and then loading the full-resolution versions in the background and swapping them in. One could also unload the highest-resolution version of out-going textures that are most-likely to go unnoticed. This all goes back to how clever you are about streaming things in (and out) on-demand. Its not an easy problem. One could literally write a Ph.D thesis or two on this topic.
There are some tech demos out there, and a game on Steam, that render entire planets to-scale using procedural generated terrain, a quad tree hierarchy and other elements for the environment. The beautiful part is that generic artwork is required because everything is generated and processed with algorithms and shaders. LOD is used with the hierarchy of a bunch of heightmaps generated, usually on-the-fly with random control variables, but then those maps can be saved to a disk if you like a particular configuration. The problem is, I've read that you're looking at ~8GBs of heightmaps lol.
Check out Infinity and the XNA Planet Rendering videos on YouTube. That Steam game is called StarForge, and it's quite impressive. It's got voxel-processing, but it's based on realism and more organic, contrary to Minecraft. It's an FPS with neat ragdoll physics and cool RPG elements built into it as well. I haven't bought it yet (all my time goes to makin' games!), but it looks like the entire planet IS your sandbox.
As the title suggest, I was wondering just how large a landmass a console could generate (Both current and next gen).
I think it is storage (hard disk drive) limited - depending of the type of terrain and how it relates to its ram storage, because I think it could be boosted greatly through some compresion algorithms (endoding some bigger places into some ids atc) to very big size in some cases. (such big is relative though)
In simple case when you would like to define a 2d 'tilemap' where size of the tile coresponds to 1 meter, lets see, if you assume you have 10 GB of storage it will be 100 000 tiles x 100 000 tiles so this is only 100 km x 100 km area, but when you will use something like jtpg encoding you will have probably much more area becouse of large flat areas in the image (oceansand deserts and so on) So I think that earth area can be stored on disk drive depending on the amounts of hand crafted heavy compression trees and such
It is some theme of specialised compression of very large images with a need of quick uncompression of its selected parts
(40 000 km equator would be 12* (6.4M*6.4M) -> about 500 Tera tiles - heavy compression needed but depending on the informatin loss is imo obtainable)
So finaly, there is no size that limits here but information/ compression compliance , if you are making your world you could make it compression compliant at will, I think
Take a look at this: http://gamearchitect.net/Articles/StreamingBestiary.html
TLDR: There's not enough RAM for an unlimited world so its partitioned into tiles and streamed in from slow DVD/HDD and possibly changes written back, which limits what can be done.
