Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
How will the game handle the huge amount of data for changing world?
Ulorik
Member UncommonPosts: 179
Tech noob here. Someone might have a very easy to understand answer, but I'm scratching my head at this:
A changing buildable and desctructible world sound really exciting, however I was wondering. How will the huge amount of data be handled that you need to get to each player if you want to experience in realtime all these changes around you, crumbling walls, detroyed bridges, dungeons being dug, houses and villages being erected and destroyed. That on top of your mob movement and fighting, possibly PvP etc, etc.
This sound like a huge step up in data quantity to be moved around compared to "traditional" MMO's
Comments
http://en.m.wikipedia.org/wiki/Procedural_generation
Speculation. And nothing the developer acutally said point to that.. even more the contrary. Every contintent is one seamless zone.
How do they manage it. As Picard pointed partly out. The base terrain is a prodecurally generated with a noise function. With other words they only have to save a noise function for a very large area. Every change of that base terrain can then be safed and is overall a lot less as you would safe all the terrain itself. So basicly you have for every area the noise function and all modifications on top of that. Those modifications are from the game designer himself as they designed the area(the prodecural generated is just the beginning.. and if you look all the terraforming vids you can get a very good picture of that), or from the players afterwards if they add stuff to the world, although this will be limited to areas the player has access to modify. Like the land he owns in Landmark or EQN.
And a lot of destruction stuff is just temporary and will withit just safed temporary. Another way to safe destruction rather easy and with less extra data, if you don't safe the modification itself, but just the vector of destruction, and the effects of it could be generated out of it.. but that is speculation on my part, it would be just a simple way to safe the data of a effect with almost no data to safe.. but instead more cpu power to calculate the destruction out of a vector.
The overall land will be procedurally generated then "smoothed over" by the SOE artistic team and saved as a now static world (nobody is in the world to change it) then they fill up the world. All of this will be in the initial download or Game DVD. You client will already know how to render all of the animations so all the server needs to send to your client is "player_tag_302345 ex ani 54 ^ 55.4 el +10" or basically the servers tells your client to render the animation. The animation itself would not be transmitted over the network. For moveable objects (MOBs, NPCs, other players) a similar thing happens the server sends you the tag for the object and the grid location or only what you can see anyway their vector related to you.
To sum this up the only thing the server needs to send is location infomation. Everything else can be rendered by the client.
Edit: You may have a larger initial download when you connect to the game server after a break while your client updates to the point the server is at.
The best way to minimize workload is to separate into smaller "Pieces".
For example skyrim has its world subdivided into zones, Zones that will stream or pre-load as you adventure towards them.
Now, we can summarize that eqn will utilize a 'hex grid' because its already a system within the light forge engine. within each hex, data can be handled more efficiently.
How data throughput between the client and the server works using such a system i do not know.
edit if i were to guess:
Each client in "Hex A_35" would get the relevant data to what is happening around them, which would be completely encapsulated from all the events that are happening in "Hex Z_15".
TSW - AoC - Aion - WOW - EVE - Fallen Earth - Co - Rift - || XNA C# Java Development
related blog
http://procworld.blogspot.com/
EQ2 fan sites
And, in addition to the other fine answers on this thread, let me ask this question. If a destructive activity occurs in an area that will self-repair, is it even necessary for everyone to see the destruction? Everyone could see the unspoiled natural terrain (or destruction caused only by grouped players) and it wouldn't really make a difference. And it would reduce the need to upload that nifty crater you just whacked in the ground with your hammer.
And even if the damage is broadcast back to the server and distributed, wouldn't that deprive another player from seeing the nifty Hammer-creates-crater animation on their own system? That could even be considered a form of griefing, if carried to an extreme (and we all know it will).
But, realistically, I expect damage to be passed around like spell animations in EQ1 or EQ2. There will be a 'canned' animation played, centered on a character location and targeted at (X,Y,Z) and the client will compute and display the damage. So, I'd go with the procedurally generated answer.
Logic, my dear, merely enables one to be wrong with great authority.
I think the difficulties with destructibility are addressed by the voxelfarm engine that they are using:
http://voxelfarm.com/vfweb/index.html
From what I have seen about it, using voxels is actually quite efficient and can be more easily transformed than traditional polygons.
Most everything else has already been done by previous MMOs (seamless world, high population density, spell animations, etc.). If you look at WoW, it performed pretty well with rather large populations and included a seamless world from launch in 2004. Since then, both server and client hardware have improved dramatically, so I don't think performance will be too much of an issue.
The biggest point here is that the images are not transmitted. When you happen upon another character, MOB or NPC your computer already knows how to display those on your screen. The only thing that needs to be transmitted is the location information, what direction a movable object is facing, and what action is being performed. Also stuff that is so far away that you can't see it anyway doesn't need to be downloaded until you need it.
As far as the crater scenario. Wouldn't it look weird to see people standing below ground level in the crater while you see a smooth healed surface?
I don't think that's accurate, but SOE has already explained it for the most part.
https://www.youtube.com/watch?v=DR3NEsJzP_o
from Minute 21.
Umm... go get yourself the RealmCrafter software. Make a couple of areas in it, then get Blender and make some of your own models, and place them in there (texture, rig and animate them too, don't worry about AI or anything).
Now, get Unity, and replicate what you have done inside the RealmCrafter game. You can use the same assets, just make it look the same.
Come back to us and tell us how long that took.
Now, imagine doing that much work about 1000 times more. That's how much work it would take just to move EQ1 art assets into a new client. It would be a huge undertaking.
You have no idea how complex it is to make changes to a system that is approaching 20 years in age.
All that aside, the people who are working on EQ1 are not the same staff that works on EQN, so... what was your point again?
I personally think people are over thinking marketing hype speech.
I would bet most of it will be state changing, not actually world changing. This means that there will be set states an area can be changed to through actions, not a freedom to change it how you want. So if enough people do this one thing, this part of the area changes to State 2 from State 1. Not you run in and dig a giant hole in the ground somewhere and watch things fall into it.
So a bridge will have two states. Built and destroyed. The game just swaps between the two. The physics are easy enough as the built model has different physics from the destroyed. That part really is not complicated at all.
Just a point of correction here, WoW did not have a seamless (ie zoneless world). It just did a really good job of hiding the seams.
Right. WoW accomplished this by pre-loading adjacent zones. Regardless, that was nearly 10 years ago...
I disagree with your semantics on the basis of linguistic flexbility. If WoW isn't seamless, then no game is seamless, making the term "seamless" itself useless.
I would label a world "seamless" if you never get "LOADING PLEASE WAIT" when crossing non-instanced terrain.
Sure, you may not be able to view "Terrain style A" in "Region B" but if the user never has to care, does it really matter?
Well this is why they keep talking about all the work they are doing to handle it... (they mention all the data they will be pushing in a few video's.)
The main problem with a game that can change isn't what the server can handle... its the fact that you don't have a static "map" on your (the users) computer anymore... To some extent you can look to a product like Second Life where every "sim" might be hand made.
The result is a lot of bandwidth used on your end because all that changing data has to come to you... to me in the end that is going to be the biggest "problem" for people with capped bandwidth. I had a friend up in Canada that was a builder in SL and it used a ton of their monthly allotment due to all the data they had to receive...
^^^this
There are Berserker AA's that didn't work day one of GoD launch (feb 2004) that still haven't been fixed, among many many other things. EQ2 launched without loot tables on final raid bosses LOL.
SOE has a tendency to forget about the past and just keep trying to make content that costs money. That attitude got by in and before 2004, but now we all expect you to have your shit together. The same people are still in charge.
How will the game handle it? Through lag of course
Planetside 2 is free to play, go download it, and head to the nearest hot spot. You'll see how your computer will handle Forge Light engine.
EQ1-AC1-DAOC-FFXI-L2-EQ2-WoW-DDO-GW-LoTR-VG-WAR-GW2-ESO
Yes, thanks for all the answers. I think the above answer is hitting the spot. I had understood the Voxel engine really in that way that people would be in-game manipulating Voxels that make up the Landscape...hence my bewilderment about data loads. If you think about different states just to be sent to the client it of course is manageable.
They are using a voxel engine, which allows much more detailed destruction and terraforming. Minecraft is a good example of a voxel based game (mostly because everyone knows it).
Your example is related to traditional 3D engines and not applicable here.
The biggest problem with voxels is that making moving voxel structures is practically impossible unless the SoE codewizards have figured out some really awesome stuff.
The magic will be in procedural generation on the client, compression, and pre-stored image data on the client.
Only the voxels on the surface need to be rendered on the client computer. The interior of the object can be procedurally generated on the client.
There will likely be an insane amount of repetition, the more repition the smaller the compressed data is.
Since your client will be able to build the exact same thing as any other player; likely your client already has all the data it needs to be able to render the image on the client. The trick is in figuring out how to put it together.
With magical theoretical fairies, goofer dust, cyber bunnies, and spriggans!
Though I do firmly believe, like everything in reality compared to fairytales...It will disappoint without fail. I mean Second Life allows users to create and update and upload content, meshes, textures and build land....And it's still horribly laggy, demanding of computer and network resources....
Though this game won't let us import anything new and fresh, it'll already all be on the client, no new textures or meshes that we create from a 3D design program....So in that aspect it just needs to tell the client to arrange resources it already has readily available, which is much less complicated.
--Custom Rig: Pyraxis---
NZXT Phantom 410 Case
Intel Core i5-4690 Processor - Quad Core, 6MB Smart Cache, 3.5GHz
Asus Sabertooth Z87 Motherboard
Asus GeForce GTX 760 Video Card - 2GB GDDR5, PCI-Express 3.0
Kingston HyperX Fury Blue 16GB
The compression won't work very well outside the release when people start changing the landscape. Myself I'm guessing they are using some clever recursion on the voxels - in effect having another voxel space inside each "master voxel", etc. where it's needed. In fact, that is probably the only way they can have different size voxels without the memory requirements for mapping the whole world from exploding. Basically, most structures would be comprised of X number of big blocks and then a smaller number of those would contain a sub-voxel space, of which a number would contain a third level of sub-voxels, etc.
In effect, the more detailed a structure would be, the more memory it would require to load. Now, I'm also guessing their smoothing algorithm does a ton of this procedurally within the client so that the server doesn't need to hold all that data.
What you would see when entering inside a detailed structure is first a very rough scetch that will then (de)form into the final structure real-time. We will probably be watching a loading screen at that point, though. The trick to stop this happening while in-game is to load the space near the player as far as he can see and then some, and unload it as he moves away from those areas. In effect we would only get loading screens when teleporting from one spot to another, and even then if the system is smart enough it could pre-load the teleport destination as we get close to the portal (or w/e).
What I'm wondering is that how they plan to implement moving structure parts, such as windmill wings, into the voxel-based structures so that they will look to be part of it and will behave realistically once the voxel structure gets destroyed.