Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
EQ:L - what's it gonna be?
Grahor
Member Posts: 828
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!
Comments
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.
EQ2 fan sites
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.
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.
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.
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?
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..
Please check out my channel. I do gaming reviews, gaming related reviews & lets plays. Thanks!
https://www.youtube.com/user/BettyofDewm/videos
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!!!
I work as a programmer for 20 years now, my field of work changed a number of times.
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!
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.
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...
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.
--Custom Rig: Pyraxis---
NZXT Phantom 410 Case
Intel Core i5-4690 Processor - Quad Core, 6MB Smart Cache, 3.5GHz
Asus Sabertooth Z87 Motherboard
Asus GeForce GTX 760 Video Card - 2GB GDDR5, PCI-Express 3.0
Kingston HyperX Fury Blue 16GB
Kudo's Graph...
Good post.. I hope you keep posting on things like this.. TY
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.
*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...
I think posting that was a mistake.
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.
Logic, my dear, merely enables one to be wrong with great authority.
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.
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.
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...
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.
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.
Alright I see you also have a pretty severe superiority complex. Well that does explain a lot...
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.