If there's a option of not letting you keep your building private, you clearly don't live on a "client-only" shard, it's a true MMO.
*le siiiigh* people, you read into developers' words the damndest thing. It does nothing of the sort.
Let's check the options. You build in an instance. Do you want your build to be on a "portal map", for others to upload and see it only when you have finished the build? Half-way, using one of intermediate saves of my build? Keep it private and control who can access, load and see it even after I've finalized the build and uploaded final version to servers? Or, the last option, "others - anyone - can download my instance in any step of the build, in read-only format, and I only control by access rights who have the right to add/edit it."
Absolutely nothing here says anything whatsoever against instanced build. On the contrary, it supports instanced builds/intermediary saves/object downloads/access control completely.
There are 30 forums pages on this poll on the EQ:N site.
Zero posters share this belief that there is one build site per instance and you have to subscribe in advance to visit one.
Exchanges with the SOE Comminity Relations person are like the following:
“My only thing with building in public is when some comes by while your building and wants to talk about what your doing. I have built in alot of persistent worlds. And I just feel rude if I dont reply to them. But when I am in "build mode" I want to build, not talk.”
Someone else mentioned this earlier in the thread as well (and I cannot find the quote! Sorry! " />). Do you think some sort of flag (like how other games have or would help with this?
This is an important distinction, and it is why we made sure to include "in Landmark" in the question. They may be handled the same, and they may be handled differently, so I appreciate your comment (and others similar to it) that have compared/contrasted how they want to see building in Landmark vs. Next.
If you parse this with an open mind, it is clear that SOE has the capability for "open world building" and that you can run across a person while they are building, and that therefore any instancing will purely be a convenience feature for those who don't want their products being poached or who feel uncomfortable revealing half-done work.
Of course, I'm sure it remains possible to find a loophole and accuse me of fanboism.
>>I still have trouble believing they offered this as a "theme" 20 years ago when AI was so simplistic back then. You didn't even really have 3D space to work with. There wasn't much to work with much less make a degree out of.<<
Okay, that shows the level of discussion you are offering. Off to block you go.
Like your own arrogant and condencending level of discussion is so much better... :P
My arrogance and condescension is deserved and backed up by at least some knowledge. His self-evidently isn't. Makes a world of difference.
But I'm perfectly okay with people blocking me. If they think that my posts will not add anything worthwhile for discussion, they actually should block me rather than to waste their lives on reading worthless posts. That's why I apply block feature liberally - threads become a LOT shorter and easier to read.
You've provided no evidence and your only claims are that you are a programmer for 20 years and you worked on AI and graphics engines a long time ago. If you want we can test each other and I can show you who is more knowledgable about modern graphic's programming. I highly doubt the validity of your claims, especially since every bit you claim seems a little suspect.
I on the other hand explained why you are wrong and even provided a concrete example of why you are wrong. Not to mention you are going against the entire SoE development team or at the very least flat out calling them liars. If you want I'd happily take the time out to prove that you are the one who is ignorant and not I with various articles on the differences voxels vs. polygons have on hardware, so more games using voxel technology, etc.
*sigh* cave can't be procedurally generated if it has arbitrary, not designer-object form. It have to be sent to you in voxel-shape, which IS the information about every damn voxel. Compressing that information - separating the arbitrary shape into geometrical primitives etc - is rather complex and can't be done on massive scale in real time.
*shrug* but if you still believe all you'll get is metadata, there is nothing I say that can prove it otherwise to you. We'll just have to see.
Mind you, I'll be delighted to be mistaken. It's such a freakin rare thing, for me to be mistaken...
An arbitrarily shaped cave can still be compressed using run-length encoding. You can transmit a 2D-grid of horizontal runs of empty space with slanted caps on the end. Voila, roughly 100 to 1 compression on an arbitrary cave that's roughly 10 meters wide, assuming voxel dimensions of 0.1 meters like Voxel Farm.
I wouldn't call runs "metadata", but it's just semantics.
At the end of the day, it's almost irrelevant, since the client doesn't need to store any voxels at all, only polygons, and SOE's EQ2 streaming zone downloader can easily outpace the fastest builder.
You could read about this stuff on the VoxelFarm blog, or you could continue to shout in the dark.
Also, I think it's unfair of me to just leave the thread like that and actually refute your claim once again, this time with an analogy and a little bit more explanation:
Let's take a set of Legos for example. You could probably build nearly anything you want given enough Legos, but obviously the amount of resources needed to purchase and buy the legos you need to build anything you want is going to be a bit absurd. Obviously, Legos isn't going to create individual molds and special Legos to cater to building every specific object possible. Instead, they create very specific flexible legos. This is similar to the first general method of compression. You don't have to create an individual separate voxel for each little tiny piece of an object you create, you can just build one from a set of voxels you have in memory.
Before you go in claiming this is "pre-defined blocks" it absolutely is, and the method for rendering with polygons is EXACTLY THE SAME THING. This is how we create meshes or models, we create parts then put the parts together and animate them based off that.
Now, let's take it a step further. We still need to store a lot of data on each individual voxel, right? How can we reduce that? There are a few ways. Let's take for example a set of 20 numbers all of which range from 1-4, sorted:
Rather than represent each individual number in memory, why not just reduce it to a simpler pattern:
1X4, 2X5, 3X6, 4X5
Now, instead of having to store 20 integers we can just store 8 instead. You can apply this method to voxel data such as color and density as you see fit.
We can use these compression methods and others with voxels exactly how we use polygon meshes and models, a set of pixels to form image, etc.
I've worked on a couple of games (which never saw the light of day, by the way, due to mismanagement) as AI designer and engine coder. *shrug* I still was paid for my work, so I don't mind. That doesn't make me "special" in any way - lots of people have experience with that type of work - don't see many of them posting here, though. Currently I'm mostly working with databases and client-server applications - again, nothing special, but I have a bit of understanding for what can be done with databases and what can't.
I am surprised that a experienced programmer, even with experience in client-server applications don't have the imagination to solve this very problem rather simple.. at least from a network traffic standpoint.
You don't have to transfer every voxel or voxel-object, rather transfer every operation from the player... it is basicly the same as you transfer movement or combat commandos, with the difference that you terraform/build the world with those commands. The terraforming/building can then be done both on the specific client and the server.
The problem is much more to make those changes permanent, therefore you have to optimize every object (at the server) and only transfer that to the specific clients visiting the new terraformed area. This is one reason why in EQN most will heal back and you can only build preset structures(and with that already optimized). In Landmark they have to do it on the fly and could be somewhat of a problem.
Basicly you have to transfer the noise funtion(basic terrain) + all modified and optimized structures on top of that. To transfer all data during walking through a zone could be troublesome, so it is most probably better to transfer a lot of that every time you start the client and during idle times.. so that just a rather small part have to be transfered during walk through.
With other words it is not that impossible(or fatal) as you may think.. I don't work on that specific project, nor do i have any specific informations, but a lot of those problems are sovleable with some think around solutions. Although the complete landmark world seamless without any loading and thousands of players building all around the world is at least rather hard to accomplish.. with other words i think they will utilize some zoning and maybe some instances. But to really say anything more specific you need a lot more in detail information and i would need to work on that project.
If you open your mind too wide, your brain will fall out. You've offered an argumentum ad populum and a couple of quotes that don't actually say a thing at all! That can be read any way you want. Hard to take that seriously.
As for reading Voxelfarm blog, I've read it very carefully. Exciting and wondrous thing, but I don't think it says what you think it says. Could you please link to specific posts that support, in any way, your assertion that run-though compressing is easy to do in a massive multiplayer real time environment? Because as far as I remember Voxelfarm run-through compression is used to store things in single-player environment, and not actually in realtime.
>>You don't have to transfer every voxel or voxel-object, rather transfer every operation from the player... it is basicly the same as you transfer movement or combat commandos, with the difference that you terraform/build the world with those commands. The terraforming/building can then be done both on the specific client and the server.<<
That's how they'll probably do it in EQ:N, even though it's not exactly as easy as you say. First of all, no mmorpg transfers movement or combat commands to client; server processes them and transfers to players the results of it; moreso, it's autocorrecting - you can lose a packet of 10 in transition, and the next packet will autocorrect the losses - that's called "lag" or "desinc", it can be small, but it's never zero.
However, if you build the terrain on a client this way, you can't afford to lose even a single one terrain-changing command, because then you'll have all the consequent commands to generate incorrect terrain and desinc the client with the server. And you can't exactly place autocorrect information into following packets - it's not as if it's a single object like player that simply changes its position and stats in time - it's a throng of independent objects. Imagine a hunded players generating them, say, once every 5 seconds, and you'll see an unholy amount of data you need to transfer in real time without errors.
Nevertheless, it's possible, and that's why I think they'll do it in EQ:N, with some limitations; but here we are talking about EQ:L, and the situation in EQ:L is different - you can't do in this way in EQ:L.
>>I am surprised that a experienced programmer, even with experience in client-server applications don't have the imagination to solve this very problem rather simple.. at least from a network traffic standpoint.<<
I always marveled on how easy and simple it is for people to solve all the problems in their heads... and how hard it is to actually implement. Remember SimCity debacle? SWTOR engine problems? GW2 Auction house? EvE Jita and FleetBattle lags? If all those things are so easy, it must've been reeeeel poopyheads working in those companies!
If anything my experience taught me, it's that there are no "simple solutions" in networking.
If anything my experience taught me, it's that there are no "simple solutions" in networking.
And you're absolutely right about that, because in the end the laws of physics limit what we can do with networking.
But where the magic comes in is the workarounds, which are the stuff that needs true thinking out of the box.
You also keep bringing up networking examples that didn't really work as planned (at launch) to back up your argument that building in a voxel space cannot be done on the large scale, real time and open world. All the while ignoring networking examples that work, such as SOE's own Forgelight engine capable of handling 100 vs 100 battles in PS2, with bullet ballistics and all that. Sure, it doesn't have deformable terrain, so we don't know how well they can adapt the netcode to a voxel engine. That remains to be seen.
I guess my point is that even if some things are downright impossible (such as transferring X amount of data over Y amount of time, if the bandwidth is Z), there can be workarounds that accomplish (almost) the same thing.
Scientist all around the world agree that nothing can exceed the speed of light, yet it doesn't stop them from researching ways of travelling from point A to point B faster than light, by various workarounds.
But where the magic comes in is the workarounds, which are the stuff that needs true thinking out of the box.
You also keep bringing up networking examples that didn't really work as planned (at launch) to back up your argument that building in a voxel space cannot be done on the large scale, real time and open world. All the while ignoring networking examples that work, such as SOE's own Forgelight engine capable of handling 100 vs 100 battles in PS2, with bullet ballistics and all that.
The problem is, "the magic" quite often creates other problems solving this one. Let's take your example. I haven't actually played PS2 and didn't do any real research on that, but as far as I can judge, PS2 engine have unloaded all the calculations of moving, ballistics and so on on clients' machines. Servers don't, actually, calculate any of that. As a direct consequence, PS2 is wide open for hacks of any sort whatsoever: wall-walking, speed hacks, intant headshots, etc. Simply because servers don't calculate any of that: client machine says to server: "I'm walking through that wall, because there is no wall here for me, honest!" and the server can't help but accept it - because it doesn't know if it's true or not, it doesn't do any of the calculations or checks.
That's the tradeoff. If the same engine will be used in EQ:N, with the same calculation unload to clients - you'll have all the same hacks in EQ:N, there is no way around it - that's the tradeoff. Tradeoffs of similar magnitude will have to be made for any "workarounds". Kind of black magic, eh. You often pay more than you get.
Scientist all around the world agree that nothing can exceed the speed of light, yet it doesn't stop them from researching ways of travelling from point A to point B faster than light, by various workarounds.
Dafuq?!!
Current theory says that nothing can't exceed the speed of light, because it's impossible - information transferring faster than light means travel in time. No workarounds can, even theoretically, help here, period.
What the scientists do (without any success, I have to add) is trying to find data to disprove current theory. That's not "researching ways to travel faster than light, using workarounds", it's "finding a way to run an experiment that demonstrates, that current theory is wrong". No "workarounds" involved.
The problem is, "the magic" quite often creates other problems solving this one. Let's take your example. I haven't actually played PS2 and didn't do any real research on that, but as far as I can judge, PS2 engine have unloaded all the calculations of moving, ballistics and so on on clients' machines. Servers don't, actually, calculate any of that. As a direct consequence, PS2 is wide open for hacks of any sort whatsoever: wall-walking, speed hacks, intant headshots, etc. Simply because servers don't calculate any of that: client machine says to server: "I'm walking through that wall, because there is no wall here for me, honest!" and the server can't help but accept it - because it doesn't know if it's true or not, it doesn't do any of the calculations or checks.
That's the tradeoff. If the same engine will be used in EQ:N, with the same calculation unload to clients - you'll have all the same hacks in EQ:N, there is no way around it - that's the tradeoff. Tradeoffs of similar magnitude will have to be made for any "workarounds". Kind of black magic, eh. You often pay more than you get.
Scientist all around the world agree that nothing can exceed the speed of light, yet it doesn't stop them from researching ways of travelling from point A to point B faster than light, by various workarounds.
Dafuq?!!
Current theory says that nothing can't exceed the speed of light, because it's impossible - information transferring faster than light means travel in time. No workarounds can, even theoretically, help here, period.
What the scientists do (without any success, I have to add) is trying to find data to disprove current theory. That's not "researching ways to travel faster than light, using workarounds", it's "finding a way to run an experiment that demonstrates, that current theory is wrong". No "workarounds" involved.
There are ways to detect these hacks and ban them. But yes, client side calculation is the way to go if the game requires heavy calculation, such as the deformation of large masses of voxels. It's a tradeoff, but one that can again be worked around.
And no, the scientists are actually trying to figure ways to "make the way shorter" by bending space, therefore eliminating the need to exceed light speed locally.
I've been writing terrain engines for over 15 years including several voxel engines (one a procedurally generated cave system including real-time octree LOD processing). I still would not claim to be an expert. Modern techniques like sparse voxel octrees are developed by top programmers and academics with input from parties like NVidia, i.e. they know what they are doing. Trying to say you know better is embarrassing.
>>You don't have to transfer every voxel or voxel-object, rather transfer every operation from the player... it is basicly the same as you transfer movement or combat commandos, with the difference that you terraform/build the world with those commands. The terraforming/building can then be done both on the specific client and the server.<<
That's how they'll probably do it in EQ:N, even though it's not exactly as easy as you say. First of all, no mmorpg transfers movement or combat commands to client; server processes them and transfers to players the results of it; moreso, it's autocorrecting - you can lose a packet of 10 in transition, and the next packet will autocorrect the losses - that's called "lag" or "desinc", it can be small, but it's never zero.
And yet again you prove you have no idea what you are talking about. There are reasons teleport hacks, speed hacks, and hacks related to combat exist in games which are done completely client side. While most of this is handled server side, MMOs do put a lot of things on the client side with with the server acting as a sort of regulator (syncing everything together) because after all by your own notion that voxels won't work due to memory footprint wouldn't handling all movement/combat related functions like hit detection for example for 1000s of players bog the server down tremendously?
However, if you build the terrain on a client this way, you can't afford to lose even a single one terrain-changing command, because then you'll have all the consequent commands to generate incorrect terrain and desinc the client with the server. And you can't exactly place autocorrect information into following packets - it's not as if it's a single object like player that simply changes its position and stats in time - it's a throng of independent objects. Imagine a hunded players generating them, say, once every 5 seconds, and you'll see an unholy amount of data you need to transfer in real time without errors.
It doesn't matter how many voxel objects there are, but the size of each individual object. Again with compression I can create a large set of voxels and compress them down where the overall data size is much smaller than the original set of voxels. In a typical MMO I'd imagine player data has likely 1000X more data than a typical voxel which really only needs to store density and position - 3 floats and an integer. Each voxel costs a whooping 16 bytes of memory. If you have 100 million voxels, you're looking at somewhere around 1.5GB of memory and that's uncompressed. No way a server with terabytes of data can store that! It's TOO HARD! You do not need to store color data in a voxel, and you can use alternate methods to display "faces" on a voxel. There are also 100s (possibly 1000s) and players on a server at any given time, yet you don't seem to think the memory footprint they cause is a problem, yet voxels are?
Nevertheless, it's possible, and that's why I think they'll do it in EQ:N, with some limitations; but here we are talking about EQ:L, and the situation in EQ:L is different - you can't do in this way in EQ:L.
Why can't it be done in EQ:L with the same limitations? There is no reason something that works in EQ:N won't work in EQ:L or vise versa. Obviously there are going to be some limitations. You can't create any object you can imagine using the landmark system as that would just create the ridiculous situation you are trying to force on the game, instead you are likely going to have to build objects you want using a set of very flexible voxels. The legos example I gave.
>>I am surprised that a experienced programmer, even with experience in client-server applications don't have the imagination to solve this very problem rather simple.. at least from a network traffic standpoint.<<
I always marveled on how easy and simple it is for people to solve all the problems in their heads... and how hard it is to actually implement. Remember SimCity debacle? SWTOR engine problems? GW2 Auction house? EvE Jita and FleetBattle lags? If all those things are so easy, it must've been reeeeel poopyheads working in those companies!
And humanity really needs people like you telling them they can't do something because they have limited knowledge of the way things are supposed to work. I'm sure people like you are the pillars of progress in our society.
If anything my experience taught me, it's that there are no "simple solutions" in networking.
Though I certainly never worked on a project as large as a AAA MMO like EQNext, I've always found network coding to be one of the simplest aspect of game programmer. Certainly it's more difficult than simple game logic, but I find programming 3D Graphics Engines with the complicated math (and the need to understand how everything works) to be far more difficult, followed by AI programming. There is a good reason why Technical Artists are one of the highest paid positions in game programming.
Originally posted by rounner I've been writing terrain engines for over 15 years including several voxel engines (one a procedurally generated cave system including real-time octree LOD processing). I still would not claim to be an expert. Modern techniques like sparse voxel octrees are developed by top programmers and academics with input from parties like NVidia, i.e. they know what they are doing. Trying to say you know better is embarrassing.
*siiiiigh* I don't claim to know better than the programmers. I claim that users on this forum misunderstand what programmers say and/or public relations people in companies slightly bend the truth.
Why people aren't even bothering to read what I write?
And while hierarchical octrees keeping occlusion datastructure and sh!t are a neat idea which demands a sh!tload of fancy math, it doesn't have anything to do with things we are trying to dicuss here.
There are ways to detect these hacks and ban them.
If forums are anything to go by, SOE is a bit lagging in that department. Even, though, it would be easy - see? This word again - easy! - to, say, calculate on the fly the percentage of headshots or speed of movement by players and ban them, again, "on the fly", without any human involvement, computer-speed fast - oh, so easy, right? And yet, and yet... Something stops programmers from implementing such easy things, eh?
But yes, client side calculation is the way to go if the game requires heavy calculation, such as the deformation of large masses of voxels. It's a tradeoff, but one that can again be worked around.
We shall see, we shall see.
And no, the scientists are actually trying to figure ways to "make the way shorter" by bending space, therefore eliminating the need to exceed light speed locally.
Interesting stuff, although currently at a very theoretical level and for all practical purposes could prove to be impossible.
Those ideas are still going against current understanding of theory of relativity; say, same wormhole idea would still be a time machine, with which you would be able to travel into past; and if any of them will be implemented, the current theory would have to be amended or replaced; I think it was called "workarounds" for "public relations" reasons - rather than to explain the complexities...
My point was, even if some things are proved to be impossible, brilliant minds often find a way to work around the impossibilities.
Oh, there is nothing theoretically impossible in fully destructible voxel mmorpg; it's purely engineering problem, and my doubts are simply in the area of "can it be done in the way that is hoped for on forums, right now, in current condition of mmorpg market and infrastructure, by SOE, within reasonable limits of time/money spent".
And engineering problems are nothing to sneeze at; we still don't have our flying cars, even if we, apparently, it looks like, could get our jetpacks soon.
We shall see if that particular engineering problem will be solved and how, or if it'll be done with practicly same functionality (instanced) but at fraction of the cost.
Oh, there is nothing theoretically impossible in fully destructible voxel mmorpg; it's purely engineering problem, and my doubts are simply in the area of "can it be done in the way that is hoped for on forums, right now, in current condition of mmorpg market and infrastructure, by SOE, within reasonable limits of time/money spent".
And engineering problems are nothing to sneeze at; we still don't have our flying cars, even if we, apparently, it looks like, could get our jetpacks soon.
We shall see if that particular engineering problem will be solved and how, or if it'll be done with practicly same functionality (instanced) but at fraction of the cost.
We shall see, yes. Obviously doing it instanced is easier and cheaper, but will it satisfy the customers so that they start throwing money at SOE? That's what's on the other cup of the scale.
As for reading Voxelfarm blog, I've read it very carefully. Exciting and wondrous thing, but I don't think it says what you think it says. Could you please link to specific posts that support, in any way, your assertion that run-though compressing is easy to do in a massive multiplayer real time environment? Because as far as I remember Voxelfarm run-through compression is used to store things in single-player environment, and not actually in realtime.
Ask and you shall receive. This video is the "smoking gun" for the now-dead client-instance argument.
How would this work with scaling? Suppose you where to make this into an MMO, would it be possible to have multiple server applications running on different machines being responsible for a little part each?
Yes, this was one of the design goals. All these components align with the main octree used to represent everything in the world. So you can have servers dedicated to some octants. The more load you have in one section, the more divisions you can make. This also allows a seamless experience, that is, no world zones.
Wait, so you mean theoretically you could have a minecraft like games, where hundreds, if not thousands of people play in the same world? (If you have enough servers to work with) If so, that's amazing...
As for reading Voxelfarm blog, I've read it very carefully. Exciting and wondrous thing, but I don't think it says what you think it says. Could you please link to specific posts that support, in any way, your assertion that run-though compressing is easy to do in a massive multiplayer real time environment? Because as far as I remember Voxelfarm run-through compression is used to store things in single-player environment, and not actually in realtime.
Ask and you shall receive. This video is the "smoking gun" for the now-dead client-instance argument.
How would this work with scaling? Suppose you where to make this into an MMO, would it be possible to have multiple server applications running on different machines being responsible for a little part each?
Yes, this was one of the design goals. All these components align with the main octree used to represent everything in the world. So you can have servers dedicated to some octants. The more load you have in one section, the more divisions you can make. This also allows a seamless experience, that is, no world zones.
Wait, so you mean theoretically you could have a minecraft like games, where hundreds, if not thousands of people play in the same world? (If you have enough servers to work with) If so, that's amazing...
I'm sorry, what? THIS is your "smocking gun" and "death blow"? As if I somehow didn't watch this video (which I, by the way, have cited earlier in support of my position) or didn't read the comments? You mean, those very careful "theoretically, it's possible" means "yes, yes, it's happening right now!"??
This idea, dynamic division of servers depending on load, each running a part of single world, is pretty much ancient; EvE is built on it (although I have no idea if it used octan tree model or some other); every MMORPG, theoretically, independently of using voxels or not, could use this server architecture model to have a single world and not be separated to servers. Imagine GW2, SWTOR, TESO, etc without separate "servers", using dynamic server division model to hold a single world for anyone to live in, like EvE does.
Theoretically, it's not less possible than doing the same in EQ:L.
Theoretically, a flying car can be build.
I always accepted that there is nothing impossible, in theory, with making a single non-instanced world in EQ:L; see my posts above. However, practicly, there are some pesky engineering problems with both scenarios; specifically, in this case, I can immediately think of 2:
1) you may not make servers hold a piece of world less than some amount, you need to hold on one server at least the part players can immediately see. Which means that while this architecture can hold thousands of players distributed across the world, any shout like "hey, here's great big tonker being built right here, let's go watch it!" will crush the system.
2) you need a metric fcukload of servers for that, all connected into one currently completely undeveloped dynamic octree server networking architecture. ("Theoretically can be done" doesn't mean "I did it and it's working!") We are talking at the very least EvE's level of server numbers and supporting programming; a decade of development compressed in - what? Next half year? - horrendous (and pointless!) expenses compared to instanced building. NOT gonna happen, as it didn't happen with all the other mmorpgs which _could, theoretically_ use that model for a single-server instanceless world.
I'm sorry, what? THIS is your "smocking gun" and "death blow"? As if I somehow didn't watch this video (which I, by the way, have cited earlier in support of my position) or didn't read the comments? You mean, those very careful "theoretically, it's possible" means "yes, yes, it's happening right now!"??
One measley guy, who you claim did not need "mad skill", did all this and load tested it with hundreds of simulataneous pseudo user clients querying at faster-than-human rates. Yet you claim SOE doesn't have the resouces to make distributed servers happen on their flagship project?!
However, practicly, there are some pesky engineering problems with both scenarios; specifically, in this case, I can immediately think of 2:
1) you may not make servers hold a piece of world less than some amount, you need to hold on one server at least the part players can immediately see. Which means that while this architecture can hold thousands of players distributed across the world, any shout like "hey, here's great big tonker being built right here, let's go watch it!" will crush the system.
Why exactly will a bunch of viewers "crush the system?" So the server needs to send out 100 extra copies of the same, very small set of half-second updates? So what? The per-second building updates are no different than combat updates. And they can throttle them so you get less regular updates as load increases.
The only thing that would crush the system would be, as Miguel Cepero clearly states in the video, if you had to get updates for every building everywhere in the world instantaneously. And he's solves this by sending updates from distant towers at a diminishing rate.
If you're claiming "I bet they can't have X thousand people watching a building up close", I would respond that I bet MMOs can't have X thousand people watching the same raid up close either.
2) you need a metric fcukload of servers for that, all connected into one currently completely undeveloped dynamic octree server networking architecture. ("Theoretically can be done" doesn't mean "I did it and it's working!") We are talking at the very least EvE's level of server numbers and supporting programming; a decade of development compressed in - what? Next half year? - horrendous (and pointless!) expenses compared to instanced building. NOT gonna happen, as it didn't happen with all the other mmorpgs which _could, theoretically_ use that model for a single-server instanceless world.
What's so great about "EVE's level of server numbers?". SOE is a lot bigger than an independent outfit in Iceland and they have plenty of experience with distributed servers. And why do they need "a metric fcukload"? There's just not that much you can build in a couple of seconds. They've already clearly stated "There will be no creative mode". Thus, it's an MMO, not a client design tool.
WoW has a seamless world that is presumably supported by lots of servers. It's been around forever. And EQNext has been advertised as seamless since forever, so much of the architecture is probably in place and just needs to be converted to octtrees. What's so mind-bending about it?
I dont know who's right or wrong in this debate, but your arrogance makes you seem like a caricature, Grahor. I think you're going to be proven wrong, from everything I have read and watched about eqn and eqnl. I'll never know though because I'll be playing the game by the time we can know for sure and not lurking this forum.
None of these arguments take into account the increasing capability of commercial hardware. Any argument about WoW or EVE or any other MMO built a decade ago is pretty much invalid because hardware is so much more advanced now. By Moore's law the density (number of transistors) in integrated circuits doubles every 18 months (memory and processing power increase as a similar rate). Networking technology has also advanced astronomically.
EVE was released in 2003. A decade is lifetime in computer hardware.
Originally posted by Metrobius I dont know who's right or wrong in this debate, but your arrogance makes you seem like a caricature, Grahor.
That's because people I'm arguing with are a caricature in itself. It's not possible to argue with them seriously. I mean, the post above this one assumes that EvE is currently running on the hardware it was built on. What can anyone possibly say to that?
I really can't answer the posts anymore. Even my arrogance, which I've used as shield to protect myself from sheer lack of knowledge and understanding is broken; I'm sitting here naked and crying, defeated by the hydra of stupidity.
And thus I'm turning my tail and running from the thread, for I can't fight anymore, and let my opponents jubilate and dance on the streets.
Originally posted by Metrobius I dont know who's right or wrong in this debate, but your arrogance makes you seem like a caricature, Grahor.
That's because people I'm arguing with are a caricature in itself. It's not possible to argue with them seriously. I mean, the post above this one assumes that EvE is currently running on the hardware it was built on. What can anyone possibly say to that?
I really can't answer the posts anymore. Even my arrogance, which I've used as shield to protect myself from sheer lack of knowledge and understanding is broken; I'm sitting here naked and crying, defeated by the hydra of stupidity.
And thus I'm turning my tail and running from the thread, for I can't fight anymore, and let my opponents jubilate and dance on the streets.
I've been secretly watching you in this thread. I will throw you a bone and agree with you. EQ:L will be a bland instanced disappointment. In order to update all that information realtime, you would need a 2050 internet infrastructure and a super computer (by today's standards).
Each personal instance of EQ:L will exist as some lobby to join where you will subsequently download that person's data. And that estimation is very liberal and idealistic. Who's to say your personal claim will even have a multiplayer feature? Maybe all you can do is record yourself walking around and upload it to youtube?
As Grahor is basically arguing, people need to have realistic expectations of EQ:L. People are overhyping this system, which by realistic standards wont be the sandbox utopia everyone has been dreaming of; modern technology simply won't support it.
My most generous prediction is that, like the video, you throw down your flag and claim some territory. This flag will act as the entrance to your "area of minecraftable land" People can then hover over a field of flags until they find your name and click on it to zone into your work. That is my expectation of EQ:L. There is no way in hell there will be actual tracks of land that exist in a massive multiplayer arena which can be edited real-time while you share the same space with 10's of 100's of others. Not for another 50 years at least.
Originally posted by Metrobius I dont know who's right or wrong in this debate, but your arrogance makes you seem like a caricature, Grahor.
That's because people I'm arguing with are a caricature in itself. It's not possible to argue with them seriously. I mean, the post above this one assumes that EvE is currently running on the hardware it was built on. What can anyone possibly say to that?
I really can't answer the posts anymore. Even my arrogance, which I've used as shield to protect myself from sheer lack of knowledge and understanding is broken; I'm sitting here naked and crying, defeated by the hydra of stupidity.
And thus I'm turning my tail and running from the thread, for I can't fight anymore, and let my opponents jubilate and dance on the streets.
Well you've got nothing to lose, really. If you are correct, you can be here gloating around your "victory" with the hundreds of disappointed EQNext fans. If you're wrong, no one ever will remember you saying anything.
As I'm not equipped with any kind of knowledge about the technical side regarding the topic, I wont comment on that. I'll say though that if my building is actually done behind "the scene" if you will, in my own building phase/instance, I'm somewhat disappointed. Although with picturing that scenario, I'm still interested in Landmark.
I've been playing Minecraft since early Alpha and today I'm co-admin on a very successful and still quite popular Minecraft server. As you can imagine I've placed thousands and thousands of blocks, with most of them being placed by myself. Unless you're working on a "community project" if you will, most of the building is actually done "in private". As in every player is at their own little spot and building, rarely bringing people over untill it's about complete.
It's a thing I will be somewhat sad over, but it's definitely not game-breaking for me personally.
Comments
There are 30 forums pages on this poll on the EQ:N site.
Zero posters share this belief that there is one build site per instance and you have to subscribe in advance to visit one.
Exchanges with the SOE Comminity Relations person are like the following:
Petabyte32 said: ↑
Someone else mentioned this earlier in the thread as well (and I cannot find the quote! Sorry!
" />). Do you think some sort of flag (like how other games have or would help with this?
This is an important distinction, and it is why we made sure to include "in Landmark" in the question. They may be handled the same, and they may be handled differently, so I appreciate your comment (and others similar to it) that have compared/contrasted how they want to see building in Landmark vs. Next.
If you parse this with an open mind, it is clear that SOE has the capability for "open world building" and that you can run across a person while they are building, and that therefore any instancing will purely be a convenience feature for those who don't want their products being poached or who feel uncomfortable revealing half-done work.
Of course, I'm sure it remains possible to find a loophole and accuse me of fanboism.
You've provided no evidence and your only claims are that you are a programmer for 20 years and you worked on AI and graphics engines a long time ago. If you want we can test each other and I can show you who is more knowledgable about modern graphic's programming. I highly doubt the validity of your claims, especially since every bit you claim seems a little suspect.
I on the other hand explained why you are wrong and even provided a concrete example of why you are wrong. Not to mention you are going against the entire SoE development team or at the very least flat out calling them liars. If you want I'd happily take the time out to prove that you are the one who is ignorant and not I with various articles on the differences voxels vs. polygons have on hardware, so more games using voxel technology, etc.
An arbitrarily shaped cave can still be compressed using run-length encoding. You can transmit a 2D-grid of horizontal runs of empty space with slanted caps on the end. Voila, roughly 100 to 1 compression on an arbitrary cave that's roughly 10 meters wide, assuming voxel dimensions of 0.1 meters like Voxel Farm.
I wouldn't call runs "metadata", but it's just semantics.
At the end of the day, it's almost irrelevant, since the client doesn't need to store any voxels at all, only polygons, and SOE's EQ2 streaming zone downloader can easily outpace the fastest builder.
You could read about this stuff on the VoxelFarm blog, or you could continue to shout in the dark.
Also, I think it's unfair of me to just leave the thread like that and actually refute your claim once again, this time with an analogy and a little bit more explanation:
Let's take a set of Legos for example. You could probably build nearly anything you want given enough Legos, but obviously the amount of resources needed to purchase and buy the legos you need to build anything you want is going to be a bit absurd. Obviously, Legos isn't going to create individual molds and special Legos to cater to building every specific object possible. Instead, they create very specific flexible legos. This is similar to the first general method of compression. You don't have to create an individual separate voxel for each little tiny piece of an object you create, you can just build one from a set of voxels you have in memory.
Before you go in claiming this is "pre-defined blocks" it absolutely is, and the method for rendering with polygons is EXACTLY THE SAME THING. This is how we create meshes or models, we create parts then put the parts together and animate them based off that.
Now, let's take it a step further. We still need to store a lot of data on each individual voxel, right? How can we reduce that? There are a few ways. Let's take for example a set of 20 numbers all of which range from 1-4, sorted:
1, 1, 1, 1, 2, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 4, 4, 4, 4, 4
Rather than represent each individual number in memory, why not just reduce it to a simpler pattern:
1X4, 2X5, 3X6, 4X5
Now, instead of having to store 20 integers we can just store 8 instead. You can apply this method to voxel data such as color and density as you see fit.
We can use these compression methods and others with voxels exactly how we use polygon meshes and models, a set of pixels to form image, etc.
I am surprised that a experienced programmer, even with experience in client-server applications don't have the imagination to solve this very problem rather simple.. at least from a network traffic standpoint.
You don't have to transfer every voxel or voxel-object, rather transfer every operation from the player... it is basicly the same as you transfer movement or combat commandos, with the difference that you terraform/build the world with those commands. The terraforming/building can then be done both on the specific client and the server.
The problem is much more to make those changes permanent, therefore you have to optimize every object (at the server) and only transfer that to the specific clients visiting the new terraformed area. This is one reason why in EQN most will heal back and you can only build preset structures(and with that already optimized). In Landmark they have to do it on the fly and could be somewhat of a problem.
Basicly you have to transfer the noise funtion(basic terrain) + all modified and optimized structures on top of that. To transfer all data during walking through a zone could be troublesome, so it is most probably better to transfer a lot of that every time you start the client and during idle times.. so that just a rather small part have to be transfered during walk through.
With other words it is not that impossible(or fatal) as you may think.. I don't work on that specific project, nor do i have any specific informations, but a lot of those problems are sovleable with some think around solutions. Although the complete landmark world seamless without any loading and thousands of players building all around the world is at least rather hard to accomplish.. with other words i think they will utilize some zoning and maybe some instances. But to really say anything more specific you need a lot more in detail information and i would need to work on that project.
>>If you parse this with an open mind<<
If you open your mind too wide, your brain will fall out. You've offered an argumentum ad populum and a couple of quotes that don't actually say a thing at all! That can be read any way you want. Hard to take that seriously.
As for reading Voxelfarm blog, I've read it very carefully. Exciting and wondrous thing, but I don't think it says what you think it says. Could you please link to specific posts that support, in any way, your assertion that run-though compressing is easy to do in a massive multiplayer real time environment? Because as far as I remember Voxelfarm run-through compression is used to store things in single-player environment, and not actually in realtime.
>>You don't have to transfer every voxel or voxel-object, rather transfer every operation from the player... it is basicly the same as you transfer movement or combat commandos, with the difference that you terraform/build the world with those commands. The terraforming/building can then be done both on the specific client and the server.<<
That's how they'll probably do it in EQ:N, even though it's not exactly as easy as you say. First of all, no mmorpg transfers movement or combat commands to client; server processes them and transfers to players the results of it; moreso, it's autocorrecting - you can lose a packet of 10 in transition, and the next packet will autocorrect the losses - that's called "lag" or "desinc", it can be small, but it's never zero.
However, if you build the terrain on a client this way, you can't afford to lose even a single one terrain-changing command, because then you'll have all the consequent commands to generate incorrect terrain and desinc the client with the server. And you can't exactly place autocorrect information into following packets - it's not as if it's a single object like player that simply changes its position and stats in time - it's a throng of independent objects. Imagine a hunded players generating them, say, once every 5 seconds, and you'll see an unholy amount of data you need to transfer in real time without errors.
Nevertheless, it's possible, and that's why I think they'll do it in EQ:N, with some limitations; but here we are talking about EQ:L, and the situation in EQ:L is different - you can't do in this way in EQ:L.
>>I am surprised that a experienced programmer, even with experience in client-server applications don't have the imagination to solve this very problem rather simple.. at least from a network traffic standpoint.<<
I always marveled on how easy and simple it is for people to solve all the problems in their heads... and how hard it is to actually implement. Remember SimCity debacle? SWTOR engine problems? GW2 Auction house? EvE Jita and FleetBattle lags? If all those things are so easy, it must've been reeeeel poopyheads working in those companies!
If anything my experience taught me, it's that there are no "simple solutions" in networking.
And you're absolutely right about that, because in the end the laws of physics limit what we can do with networking.
But where the magic comes in is the workarounds, which are the stuff that needs true thinking out of the box.
You also keep bringing up networking examples that didn't really work as planned (at launch) to back up your argument that building in a voxel space cannot be done on the large scale, real time and open world. All the while ignoring networking examples that work, such as SOE's own Forgelight engine capable of handling 100 vs 100 battles in PS2, with bullet ballistics and all that. Sure, it doesn't have deformable terrain, so we don't know how well they can adapt the netcode to a voxel engine. That remains to be seen.
I guess my point is that even if some things are downright impossible (such as transferring X amount of data over Y amount of time, if the bandwidth is Z), there can be workarounds that accomplish (almost) the same thing.
Scientist all around the world agree that nothing can exceed the speed of light, yet it doesn't stop them from researching ways of travelling from point A to point B faster than light, by various workarounds.
The problem is, "the magic" quite often creates other problems solving this one. Let's take your example. I haven't actually played PS2 and didn't do any real research on that, but as far as I can judge, PS2 engine have unloaded all the calculations of moving, ballistics and so on on clients' machines. Servers don't, actually, calculate any of that. As a direct consequence, PS2 is wide open for hacks of any sort whatsoever: wall-walking, speed hacks, intant headshots, etc. Simply because servers don't calculate any of that: client machine says to server: "I'm walking through that wall, because there is no wall here for me, honest!" and the server can't help but accept it - because it doesn't know if it's true or not, it doesn't do any of the calculations or checks.
That's the tradeoff. If the same engine will be used in EQ:N, with the same calculation unload to clients - you'll have all the same hacks in EQ:N, there is no way around it - that's the tradeoff. Tradeoffs of similar magnitude will have to be made for any "workarounds". Kind of black magic, eh. You often pay more than you get.
Dafuq?!!
Current theory says that nothing can't exceed the speed of light, because it's impossible - information transferring faster than light means travel in time. No workarounds can, even theoretically, help here, period.
What the scientists do (without any success, I have to add) is trying to find data to disprove current theory. That's not "researching ways to travel faster than light, using workarounds", it's "finding a way to run an experiment that demonstrates, that current theory is wrong". No "workarounds" involved.
There are ways to detect these hacks and ban them. But yes, client side calculation is the way to go if the game requires heavy calculation, such as the deformation of large masses of voxels. It's a tradeoff, but one that can again be worked around.
And no, the scientists are actually trying to figure ways to "make the way shorter" by bending space, therefore eliminating the need to exceed light speed locally.
http://www.nasa.gov/centers/glenn/technology/warp/ideachev.html
Interesting stuff, although currently at a very theoretical level and for all practical purposes could prove to be impossible.
My point was, even if some things are proved to be impossible, brilliant minds often find a way to work around the impossibilities.
*siiiiigh* I don't claim to know better than the programmers. I claim that users on this forum misunderstand what programmers say and/or public relations people in companies slightly bend the truth.
Why people aren't even bothering to read what I write?
And while hierarchical octrees keeping occlusion datastructure and sh!t are a neat idea which demands a sh!tload of fancy math, it doesn't have anything to do with things we are trying to dicuss here.
If forums are anything to go by, SOE is a bit lagging in that department. Even, though, it would be easy - see? This word again - easy! - to, say, calculate on the fly the percentage of headshots or speed of movement by players and ban them, again, "on the fly", without any human involvement, computer-speed fast
- oh, so easy, right? And yet, and yet... Something stops programmers from implementing such easy things, eh?
We shall see, we shall see.
Those ideas are still going against current understanding of theory of relativity; say, same wormhole idea would still be a time machine, with which you would be able to travel into past; and if any of them will be implemented, the current theory would have to be amended or replaced; I think it was called "workarounds" for "public relations" reasons - rather than to explain the complexities...
Oh, there is nothing theoretically impossible in fully destructible voxel mmorpg; it's purely engineering problem, and my doubts are simply in the area of "can it be done in the way that is hoped for on forums, right now, in current condition of mmorpg market and infrastructure, by SOE, within reasonable limits of time/money spent".
And engineering problems are nothing to sneeze at; we still don't have our flying cars, even if we, apparently, it looks like, could get our jetpacks soon.
We shall see if that particular engineering problem will be solved and how, or if it'll be done with practicly same functionality (instanced) but at fraction of the cost.
We shall see, yes. Obviously doing it instanced is easier and cheaper, but will it satisfy the customers so that they start throwing money at SOE? That's what's on the other cup of the scale.
Ask and you shall receive. This video is the "smoking gun" for the now-dead client-instance argument.
RIP thread.
http://procworld.blogspot.com/2013/03/network-update.html#comment-form
knarfMarch 30, 2013 at 4:09 PM
How would this work with scaling? Suppose you where to make this into an MMO, would it be possible to have multiple server applications running on different machines being responsible for a little part each?
Yes, this was one of the design goals. All these components align with the main octree used to represent everything in the world. So you can have servers dedicated to some octants. The more load you have in one section, the more divisions you can make. This also allows a seamless experience, that is, no world zones.
KamicaMarch 30, 2013 at 7:26 PM
Wait, so you mean theoretically you could have a minecraft like games, where hundreds, if not thousands of people play in the same world? (If you have enough servers to work with)
If so, that's amazing...
Yes, that is one possible application.
Nice find. This gets me really excited about EQ:L. Quite to blow to the naysayers of this thread
>>http://procworld.blogspot.com/2013/03/network-update.html#comment-form<<
*blink, blink*
I'm sorry, what? THIS is your "smocking gun" and "death blow"? As if I somehow didn't watch this video (which I, by the way, have cited earlier in support of my position) or didn't read the comments? You mean, those very careful "theoretically, it's possible" means "yes, yes, it's happening right now!"??
This idea, dynamic division of servers depending on load, each running a part of single world, is pretty much ancient; EvE is built on it (although I have no idea if it used octan tree model or some other); every MMORPG, theoretically, independently of using voxels or not, could use this server architecture model to have a single world and not be separated to servers. Imagine GW2, SWTOR, TESO, etc without separate "servers", using dynamic server division model to hold a single world for anyone to live in, like EvE does.
Theoretically, it's not less possible than doing the same in EQ:L.
Theoretically, a flying car can be build.
I always accepted that there is nothing impossible, in theory, with making a single non-instanced world in EQ:L; see my posts above. However, practicly, there are some pesky engineering problems with both scenarios; specifically, in this case, I can immediately think of 2:
1) you may not make servers hold a piece of world less than some amount, you need to hold on one server at least the part players can immediately see. Which means that while this architecture can hold thousands of players distributed across the world, any shout like "hey, here's great big tonker being built right here, let's go watch it!" will crush the system.
2) you need a metric fcukload of servers for that, all connected into one currently completely undeveloped dynamic octree server networking architecture. ("Theoretically can be done" doesn't mean "I did it and it's working!") We are talking at the very least EvE's level of server numbers and supporting programming; a decade of development compressed in - what? Next half year? - horrendous (and pointless!) expenses compared to instanced building. NOT gonna happen, as it didn't happen with all the other mmorpgs which _could, theoretically_ use that model for a single-server instanceless world.
It's a toy gun you are showing here.
One measley guy, who you claim did not need "mad skill", did all this and load tested it with hundreds of simulataneous pseudo user clients querying at faster-than-human rates. Yet you claim SOE doesn't have the resouces to make distributed servers happen on their flagship project?!
Why exactly will a bunch of viewers "crush the system?" So the server needs to send out 100 extra copies of the same, very small set of half-second updates? So what? The per-second building updates are no different than combat updates. And they can throttle them so you get less regular updates as load increases.
The only thing that would crush the system would be, as Miguel Cepero clearly states in the video, if you had to get updates for every building everywhere in the world instantaneously. And he's solves this by sending updates from distant towers at a diminishing rate.
If you're claiming "I bet they can't have X thousand people watching a building up close", I would respond that I bet MMOs can't have X thousand people watching the same raid up close either.
What's so great about "EVE's level of server numbers?". SOE is a lot bigger than an independent outfit in Iceland and they have plenty of experience with distributed servers. And why do they need "a metric fcukload"? There's just not that much you can build in a couple of seconds. They've already clearly stated "There will be no creative mode". Thus, it's an MMO, not a client design tool.
WoW has a seamless world that is presumably supported by lots of servers. It's been around forever. And EQNext has been advertised as seamless since forever, so much of the architecture is probably in place and just needs to be converted to octtrees. What's so mind-bending about it?
Perfect for a toy argument.
I think you're going to be proven wrong, from everything I have read and watched about eqn and eqnl. I'll never know though because I'll be playing the game by the time we can know for sure and not lurking this forum.
None of these arguments take into account the increasing capability of commercial hardware. Any argument about WoW or EVE or any other MMO built a decade ago is pretty much invalid because hardware is so much more advanced now. By Moore's law the density (number of transistors) in integrated circuits doubles every 18 months (memory and processing power increase as a similar rate). Networking technology has also advanced astronomically.
EVE was released in 2003. A decade is lifetime in computer hardware.
That's because people I'm arguing with are a caricature in itself. It's not possible to argue with them seriously. I mean, the post above this one assumes that EvE is currently running on the hardware it was built on. What can anyone possibly say to that?
I really can't answer the posts anymore. Even my arrogance, which I've used as shield to protect myself from sheer lack of knowledge and understanding is broken; I'm sitting here naked and crying, defeated by the hydra of stupidity.
And thus I'm turning my tail and running from the thread, for I can't fight anymore, and let my opponents jubilate and dance on the streets.
I've been secretly watching you in this thread. I will throw you a bone and agree with you. EQ:L will be a bland instanced disappointment. In order to update all that information realtime, you would need a 2050 internet infrastructure and a super computer (by today's standards).
Each personal instance of EQ:L will exist as some lobby to join where you will subsequently download that person's data. And that estimation is very liberal and idealistic. Who's to say your personal claim will even have a multiplayer feature? Maybe all you can do is record yourself walking around and upload it to youtube?
As Grahor is basically arguing, people need to have realistic expectations of EQ:L. People are overhyping this system, which by realistic standards wont be the sandbox utopia everyone has been dreaming of; modern technology simply won't support it.
My most generous prediction is that, like the video, you throw down your flag and claim some territory. This flag will act as the entrance to your "area of minecraftable land" People can then hover over a field of flags until they find your name and click on it to zone into your work. That is my expectation of EQ:L. There is no way in hell there will be actual tracks of land that exist in a massive multiplayer arena which can be edited real-time while you share the same space with 10's of 100's of others. Not for another 50 years at least.
Take the Magic: The Gathering 'What Color Are You?' Quiz.
Well you've got nothing to lose, really. If you are correct, you can be here gloating around your "victory" with the hundreds of disappointed EQNext fans. If you're wrong, no one ever will remember you saying anything.
Interesting thread to say the least.
As I'm not equipped with any kind of knowledge about the technical side regarding the topic, I wont comment on that. I'll say though that if my building is actually done behind "the scene" if you will, in my own building phase/instance, I'm somewhat disappointed. Although with picturing that scenario, I'm still interested in Landmark.
I've been playing Minecraft since early Alpha and today I'm co-admin on a very successful and still quite popular Minecraft server. As you can imagine I've placed thousands and thousands of blocks, with most of them being placed by myself. Unless you're working on a "community project" if you will, most of the building is actually done "in private". As in every player is at their own little spot and building, rarely bringing people over untill it's about complete.
It's a thing I will be somewhat sad over, but it's definitely not game-breaking for me personally.
Tweet at me - Visit my website