EQ:L - what's it gonna be?

Grahor

Obviously, nobody really knows what EQ:L is gonna be, not even developers yet, I think; so let's talk what can it be, based on limits of modern technology.

 

Voxel-based free-building environment. What does it mean? It means that when a player builds, say, a wall - ever brick in the wall have to be described, every voxel - or at least every voxel-based object. That's a HUGE amount of data. There is no possible way it can be transfered in real time from computer to server.

 

Even Minecraft, which is an ASCII graphics in comparison, which demands tiny amount of data to describe its building blocks and their positions, have a very limited amount of players on every server. 

 

Therefore EQ:L will be completely client-based programm, where you are building everything alone, on a very small land plot, on your own computer only, not sharing anything to anyone at the moment of building. 

 

Saves, or uploads to server will be extremely rare. Even SimCity, a game with comparably tiny amount of data, crushed and burned because servers were simply unable to process that data. EQ:L keeps significantly higher amount of data which is necessary to move to server on save. Single large object may take hours to upload, depending on the internet speed. Therefore, a battery of servers, each working with small number of users, is needed.

 

As a consequence, forget about "walking around the world with thousands of people, looking at what other people built". You will be scanning the site with screenshots and descriptions, when you see something you like ("I HAVE MODELED THIS CASTLE ON MY GREAT BIG TONKER!") you get in queue and download that asset, load it into your own instance on your computer and look at it from any angle. All alone.

 

That's the only way I can imagine EQ:L being realistically built with modern technology. Yes, I know - "how do you know Smedley's team aren't miracle makers?! I BELIEVE in them, and as long as I believe, fairies will laugh!" or whatever. But I know because there is a limit to what you can do with server channels, and that limit is not elastic. You can't push data through with your enthusiasm.

 

Being a programmer, this way of working with objects (work on your own computer, then carefully and slowly integrate it into greater code) is quite natural for me, but I have a feeling it's not what most people imagine when they talk about EQ:L.

 

====================================

 

Update: recent bulletpoints for EQ:L designers:

• This tagging process will involve some browser and phone functionality and support.
• The player map is the gateway and portal to other builds.  Players will be able to queue up locations to visit.

That's exactly what I've said it will be: every "build" is an instance that you browse around in a brouser and dowlnoad onto your computer to watch. I told you so! Didn't I tell you so? Millenium hand and shrimp!

Nadia

Originally posted by Grahor

Voxel-based free-building environment. What does it mean? It means that when a player builds, say, a wall - ever brick in the wall have to be described, every voxel - or at least every voxel-based object. That's a HUGE amount of data. There is no possible way it can be transfered in real time from computer to server.

maybe it wont be so bad

http://procworld.blogspot.com/2013/09/voxel-instancing.html

In most game engines, which store all models as polygons, instancing is done at the polygonal level. In my case I saw the same advantages would apply if you had them in voxel form. Their memory footprint is constant, and they a blazing fast to bring into the world.

Translated to voxels, the class stores the voxel values that define the object. This can be done either in a regular grid, or an adaptive grid like an octree. Or, in any other form that makes sense to you. In my case I store them compressed using some form of Run-Length-Encoding.

These classes may take one or two megabytes each, in compressed form. Each instance is a much smaller piece of information. It just needs to record where the instance is and to which class it belongs to.

rungard

yeah the whole point of voxels is that you can actually do that.

Also remember that EQ:L is a building game and the things that are built might make it into the EQN game.

technically the meshes and textures are already ingame. Your just combining them in different ways.

Grahor

Originally posted by Nadia

Originally posted by Grahor

Voxel-based free-building environment. What does it mean? It means that when a player builds, say, a wall - ever brick in the wall have to be described, every voxel - or at least every voxel-based object. That's a HUGE amount of data. There is no possible way it can be transfered in real time from computer to server.

maybe it wont be so bad

http://procworld.blogspot.com/2013/09/voxel-instancing.html

In most game engines, which store all models as polygons, instancing is done at the polygonal level. In my case I saw the same advantages would apply if you had them in voxel form. Their memory footprint is constant, and they a blazing fast to bring into the world.

Translated to voxels, the class stores the voxel values that define the object. This can be done either in a regular grid, or an adaptive grid like an octree. Or, in any other form that makes sense to you. In my case I store them compressed using some form of Run-Length-Encoding.

These classes may take one or two megabytes each, in compressed form. Each instance is a much smaller piece of information. It just needs to record where the instance is and to which class it belongs to.

Thats's my point - procedural landscapes and class-based voxel instances take next to no data to describe and store, but custom-made unique objects, made by users, cant be class-based; by necessity, they have to be stored raw, until converted by developers into classes, which is a looooong process.

Grahor

Whole point of voxels is that they are not meshes and textures, so i have no idea what are you talking about.

arcatom

Originally posted by Grahor

Obviously, nobody really knows what EQ:L is gonna be, not even developers yet, I think; so let's talk what can it be, based on limits of modern technology.

 

Voxel-based free-building environment. What does it mean? It means that when a player builds, say, a wall - ever brick in the wall have to be described, every voxel - or at least every voxel-based object. That's a HUGE amount of data. There is no possible way it can be transfered in real time from computer to server.

 

Even Minecraft, which is an ASCII graphics in comparison, which demands tiny amount of data to describe its building blocks and their positions, have a very limited amount of players on every server. 

 

Therefore EQ:L will be completely client-based programm, where you are building everything alone, on a very small land plot, on your own computer only, not sharing anything to anyone at the moment of building. 

 

Saves, or uploads to server will be extremely rare. Even SimCity, a game with comparably tiny amount of data, crushed and burned because servers were simply unable to process that data. EQ:L keeps significantly higher amount of data which is necessary to move to server on save. Single large object may take hours to upload, depending on the internet speed. Therefore, a battery of servers, each working with small number of users, is needed.

 

As a consequence, forget about "walking around the world with thousands of people, looking at what other people built". You will be scanning the site with screenshots and descriptions, when you see something you like ("I HAVE MODELED THIS CASTLE ON MY GREAT BIG TONKER!") you get in queue and download that asset, load it into your own instance on your computer and look at it from any angle. All alone.

 

That's the only way I can imagine EQ:L being realistically built with modern technology. Yes, I know - "how do you know Smedley's team aren't miracle makers?! I BELIEVE in them, and as long as I believe, fairies will laugh!" or whatever. But I know because there is a limit to what you can do with server channels, and that limit is not elastic. You can't push data through with your enthusiasm.

 

Being a programmer, this way of working with objects (work on your own computer, then carefully and slowly integrate it into greater code) is quite natural for me, but I have a feeling it's not what most people imagine when they talk about EQ:L.

Here's a video that explains a bit about what they are doing to solve the high data problem. Starts at 21:30

http://www.youtube.com/watch?v=DR3NEsJzP_o

Now I don't really know if this is what you are referring to, but it does focus on how they are handling the voxel data.

 

 

Kyllien

First there is a difference between DATA and METADATA.  They don't need to send the DATA, they only send the METADATA. 

Second the building will be done on the server while the rendering will be on the client. 

Third there is no reason for the client to download data they can't see at present.  So something that is being built in the next "zone" wouldn't be downloaded to the client until the client needs to see it.  Or can be downloaded while the connection is otherwise idle.

Forth every tree doesn't have to look the same on every client. The branches and leaves can be arranged differently.  The important thing is to generate tree x at location x,y,z with height h.  The client then builds the tree procedurally.  How much data was transmitted?

Dewm

 

 

Before we go any further I have to express, that I've seen your post before.. and they are 90% negative, so its hard to have a real discussion.

 

Now, on to the meat of the post. What sort of programmer are you? that you feel skilled enough to actually post on this and specify you are a programmer?

 

Heck I'm a programmer,... but my java and HTML and half a semester of C# won't help much..

 

Do you work on game design? if so what do you do? AI structuring? graphics engine coding? why do you think you are so special?

 

last but not least... we know they can do it.. Do you really think they would announce something as big as a fully functional destructible game world... when they don't know if it'll work?

This isn't some small game feature that might, might not pan out.. it isn't deciding whether there should be full loot on PVP or longer death spawners...

 

This IS the game.. 

Grahor

Originally posted by Dewm

Before we go any further I have to express, that I've seen your post before.. and they are 90% negative, so its hard to have a real discussion.

My posts are realistic, not negative. I like the idea of EQN, I certainly like destrictible terrain, I like the idea of crowdfunding content creation (EQ:L), it's actually a great idea. What I don't like is overhyping and misrepresenting; people don't actually think what the game will be, they dream their dreams into designers' words.

 

If you'll check my history a bit back, you'll find, that I was called hater about eveything: about GW2 (and I have ended up being exactly right about DE, and got exactly the game I was expected, and enjoyed it - while those dreaming castles in the sky were hugely disappointed), about SWTOR and probably about something else I don't remember now.

 

Developers of GW2 and SWTOR never actually lied; they've just presented the facts slightly more shiny than they were... and people dreamed into it ridiculous things. Like they do with EQN.

 

As for discussion, yeah, it's hard to have it, when people answer your posts with 2 things: 1) you are a meanie hater 2) I BELIEVE!!!

 

Now, on to the meat of the post. What sort of programmer are you? that you feel skilled enough to actually post on this and specify you are a programmer?

 

I work as a programmer for 20 years now, my field of work changed a number of times. 

 

Do you work on game design? if so what do you do? AI structuring? graphics engine coding? why do you think you are so special?

My diploma in the university was on AI in game design, with corresponding work on it. Admittedly, it was nearly 20 years ago, but, to my surprise, the field hadn't changed much, if any, since. One AI that was truly new and surprising for me was Watson; before I've seen it with my own eyes, I could have swear it was impossible. Boy, was I wrong!

 

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.

 

What makes me special is that I have a brain and realistic attitude - boy, does it make me special here!

 

 

 

last but not least... we know they can do it.. Do you really think they would announce something as big as a fully functional destructible game world... when they don't know if it'll work?

 

Errr, they have announced nothing of the sort. They've announced that you can temporarily make a hole in some parts of the world (specifics not disclosed yet), which then will be healed, and shown very little. Yes, it is a destructible world, but it's not like you can destroy everything. 

 

Also, I'm speaking NOT of EQN, where such destruction is completely plausible (again, no physics or persistent debris, but plausible) due to their data compression techniques (which are reasonable), but of EQ:L, where there should (supposedly) be large player-made structures, which is a huge amount of data which is impossible to compress, and which simply can't be transferred to server and back in real time. They have said not a word about how they are going to achieve that and how it'll be looking, so I'm offering a reasonable version which is completely in line with what developers said.

This isn't some small game feature that might, might not pan out.. it isn't deciding whether there should be full loot on PVP or longer death spawners...

 

This IS the game.. 

Not really. It will be, at best, sort of a gimmick, because everywhere, all the time, developers say: it will not be PERSISTENT destruction, game will "heal" itself; any persistent changes will be changes made by developers.

 

But nooooo, we will think our dreams into it, because we want to believe...

 

 

Markusrind

Classic case of someone with a little knowledge thinking they know more then they actually do.

And I agree, your posts are all negative "can't be done", "will never happen", "I don't believe it is possible", "I don't trust them", "they will never get it to work".....Getting boring and irritating.

Electro057

Well as a builder and modder in Second Life...It's going to be heaven in a stable box? I just hope that they have props like furnishings and the like so I can actually make my creations feel lived in, and a proper habitable environment.

Rydeson

Kudo's Graph...

Good post..  I hope you keep posting on things like this..  TY

Kyllien

Originally posted by Grahor

Obviously, nobody really knows what EQ:L is gonna be, not even developers yet, I think; so let's talk what can it be, based on limits of modern technology.

 The plan is to release EQNL by the end of this year or very early next year.  I am sure that the developers are smart enough not to overhype something they would only have a couple months to fix.

Voxel-based free-building environment. What does it mean? It means that when a player builds, say, a wall - ever brick in the wall have to be described, every voxel - or at least every voxel-based object. That's a HUGE amount of data. There is no possible way it can be transfered in real time from computer to server.

You mean every external brick.  And then only the unit as a whole with an algorythm to generate the wall on the clients computer.  Only the METADATA needs to be transfered to the client ( Wall - 5 brick type x high by 15 wide and 2 deep, offset every other row by 1/2 block and trim the ends, apply color patters z with blemish at the following locations brick x at local grid x by y on surface z. Then comes the hard part, apply customer colors 42315  and texture 3251 to specific locations. ) 

Even Minecraft, which is an ASCII graphics in comparison, which demands tiny amount of data to describe its building blocks and their positions, have a very limited amount of players on every server. 

 Minecraft was not designed to be an MMO

Therefore EQ:L will be completely client-based programm, where you are building everything alone, on a very small land plot, on your own computer only, not sharing anything to anyone at the moment of building. 

 It does sound like you should go vote in the poll related specifically to this question.  But keep in mind that what you build will be built on the server.  The client is used to render the image and store the persistent data.  All your client sends to the server are keypresses.

Saves, or uploads to server will be extremely rare. Even SimCity, a game with comparably tiny amount of data, crushed and burned because servers were simply unable to process that data. EQ:L keeps significantly higher amount of data which is necessary to move to server on save. Single large object may take hours to upload, depending on the internet speed. Therefore, a battery of servers, each working with small number of users, is needed.

 You will be building on the server.  There will be nothing to upload other then keypresses.  Allowing offline then uploading can introduce too many exploits.  So again what you build will be built on the server.  If you have a slow connection there maybe a noticible short delay if you queue up too many actions.  But the delay should be short .

As a consequence, forget about "walking around the world with thousands of people, looking at what other people built". You will be scanning the site with screenshots and descriptions, when you see something you like ("I HAVE MODELED THIS CASTLE ON MY GREAT BIG TONKER!") you get in queue and download that asset, load it into your own instance on your computer and look at it from any angle. All alone.

Since everything is built on the server there is no reason why you wouldn't be able to wander around and view other people creations.  And there will probably be a reporting system as well as a voting system to have the "Big Tonkers" removed.  However, why not just walk around the object on the server and view it from the angles you can get to. 

That's the only way I can imagine EQ:L being realistically built with modern technology. Yes, I know - "how do you know Smedley's team aren't miracle makers?! I BELIEVE in them, and as long as I believe, fairies will laugh!" or whatever. But I know because there is a limit to what you can do with server channels, and that limit is not elastic. You can't push data through with your enthusiasm.

 The amount of data they need to push is far, far less then you are making it out to be.  There is a number of ways to deal with the amount of data.  Compression, procedural generation on the client, idle downloading, smart downloading (you only need to download right now what you need to see) comes to mind.

Being a programmer, this way of working with objects (work on your own computer, then carefully and slowly integrate it into greater code) is quite natural for me, but I have a feeling it's not what most people imagine when they talk about EQ:L.

 

Grahor

Interesting. Working with metadata only, designers-defined objects? Indeed, it takes care about data volume, but at the cost of versatility. For example, I was seeing the process like you start with procedurally generated landscape, dig a cave of arbitrary shape, build a radial wall from radial bricks inside the cave and cut the window the shape of a swan in it. This can't be done with metadata; building sims-style can.

 

Well, we'll see it when it's out - I really was hoping for raw voxels building, not metadata-objects-building. It's like building in Sims - too limited for my tastes, but others may really like it. It will certainly take care of learning curve...

Kyllien

Originally posted by Grahor

Interesting. Working with metadata only, designers-defined objects? Indeed, it takes care about data volume, but at the cost of versatility. For example, I was seeing the process like you start with procedurally generated landscape, dig a cave of arbitrary shape, build a radial wall from radial bricks inside the cave and cut the window the shape of a swan in it. This can't be done with metadata; building sims-style can.

 

Well, we'll see it when it's out - I really was hoping for raw voxels building, not metadata-objects-building. It's like building in Sims - too limited for my tastes, but others may really like it. It will certainly take care of learning curve...

Well in that case the cave would be procedurally created on my computer as I get closer to it.  The window info would be sent to my computer in time to see it but if I never come to see your work then the window would not need to get downloaded ever.  And if you are still stuck believing that I would need to download each individual voxel then that is what compression is for.  The game will be really full of stuff that can be compressed to a really small size.

Grahor

*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...

rungard

Originally posted by Grahor

 

Mind you, I'll be delighted to be mistaken. It's such a freakin rare thing, for me to be mistaken...

I think posting that was a mistake.

Mendel

Originally posted by Grahor

*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...

Like you said, meta-data isn't going to solve this problem.  Suppose you have a 3x3x3 voxel rubik's cube you want to build.  Each voxel face can have a different color.   And since this thing might be destroyable, you need the colors for all the hidden surfaces, because you never know when they might be exposed. With a conservative data representation of this simple structure of 3050 bytes (16 bit color for 6 sides for 27 voxels + overhead for other attributes (location within the space, other voxel attributes, etc.).  That will require a fragmented data packet at the physical network layer, and the time taken to transfer this data from server to client (and vice versa) can be computed.  (Transmission times will vary greatly depending on your network's upload and download speeds).

I'm more concerned by the resolution of the voxels.   Will one voxel consist of a 1 pixel x 1 pixel x 1 pixel volume, or could it be 3x3x3 or 5x5x5 or larger?  The granularity chosen by SOE will greatly impact the 'look' of the final product.  And that will directly impact the number of voxels that need to be transferred from server-to-client on a regular basis.

rungard

and I suppose now we start to understand some of the reasoning for the cartoony graphics.

ill be honest I don't know jack about voxels, but im betting that the guy who made voxelfarm probabally has a lot more skill than all of us combined, so I have to believe they can do it until proven otherwise.

Grahor

Originally posted by Mendel

Like you said, meta-data isn't going to solve this problem.  Suppose you have a 3x3x3 voxel rubik's cube you want to build. ...

Well, the thing is, if EQ:L is going to use metadata: you can't. If you can't build it from pre-defined blocks, you can't build it, period. Exactly for the reasons you've stated.

 

And once you can't "cut" pre-defined blocks, you don't neet their "inside" information - or you may simply use "noise maps" for random generation of a set of defined "materials" from which blocks are built. The resulting image of the same "?ut" will be different on every computer, but users will never know it.

 

 

I'm more concerned by the resolution of the voxels.   Will one voxel consist of a 1 pixel x 1 pixel x 1 pixel volume, or could it be 3x3x3 or 5x5x5 or larger?  The granularity chosen by SOE will greatly impact the 'look' of the final product.  And that will directly impact the number of voxels that need to be transferred from server-to-client on a regular basis.

They talk in one of their blogs or posts about voxel resolution. It's definitely not 1x1x1, it's a neat system using relatively larg-ish, in the pixel sense, blocks, but rendering them as antialiased, in a sense, surfaces. All kinds of neat things, but still block-based and somewhat clunky.

 

It's not a CSI episode. You can't "enhance" the display if the data isn't there...

Grahor

Originally posted by rungard

and I suppose now we start to understand some of the reasoning for the cartoony graphics.

ill be honest I don't know jack about voxels, but im betting that the guy who made voxelfarm probabally has a lot more skill than all of us combined, so I have to believe they can do it until proven otherwise.

Errr, making a program like voxelfarm does not demand some kind of mad skill as such (although it demands, not sure if it's right in English, methodicalness and excellent ability to learn and use what you've learned), it demands mostly great self-motivation and workability. Lots and lots of workhours went into it. But it does not necessarily scales to a mmorpg, you know.

Grahor

• This tagging process will involve some browser and phone functionality and support.
• The player map is the gateway and portal to other builds.  Players will be able to queue up locations to visit.

That's exactly what I've said it will be: every "build" is an instance that you browse around in a brouser and dowlnoad onto your computer to watch. I told you so! Didn't I tell you so? Millenium hand and shrimp!

tom_gore

I see the official EQ:N/L pessimist strikes again. Are you doing this on purpose so that you can be positively surprised or what possibly could be your motive to try to play everything about EQ:N/L down?

Minecraft can support 500 players on a server if the server is powerful enough, and we are not even talking about MMO-scale serverfarms. However, Minecraft's multiplayer code (and all the code, actually) is completely rubbish compared to professionally programmed MMO engines, such as SOE's forgelight.

In fact, because Minecraft can support as many players it can, I have no doubt that a proper voxel MMO engine can support a thousand players or more.

I'm getting really tired of your total downplaying. Do you even realize how ridiculous your "predictions" are when you put them into a business point of view. Why in the name of seven hells would SOE release something as basic and instanced as you describe? Nobody would ever want to play rubbish like that, much less actually PAY for it. We're talking about a Free to Play title, which needs to impress the player from the get go, or the publisher will never earn a dime.

tom_gore

Originally posted by Grahor

Mind you, I'll be delighted to be mistaken. It's such a freakin rare thing, for me to be mistaken...

Alright I see you also have a pretty severe superiority complex. Well that does explain a lot...

 

Grahor

The hell are you talking about? That's developers own words about Landmark (not EQ:N). What "predictions"? That's the reality of Landmark.

tom_gore

Originally posted by Grahor
The hell are you talking about? That's developers own words about Landmark (not EQ:N). What "predictions"? That's the reality of Landmark.

That's interpretations on the bullet list you like to quote around. No one still knows how it will eventually work. Many of the points are already contradicting. For example, if it's all fully instanced, why do you need to "claim" an area for yourself?

Yes it might be that you cannot build stuff real time in the "open world", but even that isn't yet confirmed.