You can get Voxel Farm now. For more information click here.

Saturday, March 30, 2013

Network Update

Here is a new video I recently captured. It shows the networking and storage components in action.



When it comes to networking this is the smallest test possible, you cannot really go below two connected clients. I have tested this same server code with nearly a hundred clients performing queries and changes at rates many times higher than what humans would do. Network tests are good at showing why some stuff does not work. But when the results are good it does not really mean anything. The real network is so complex you cannot replace it by any model. In this case results are as good as any network test can be at this stage. There is very little overhead from the thread and connection management, which is what I was looking for.

While this is good news and by all means necessary, the real bottleneck comes from how any application using this engine chooses to store and process information. So again what you are seeing here is just a brick. You could create many different houses with it.

You could do it like Minecraft servers do, have everything including procedural generation run in the server. You could do like this particular demo does, where user-created content is stored in a server and everything else remains client-side. And you could have solutions in-between, for instance have some custom server-side generation which is merged later with the rest of the client-side generation.

This is a fascinating subject to me, I will be covering some of these approaches in the future.

33 comments:

  1. 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?

    ReplyDelete
    Replies
    1. 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.

      Delete
    2. 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...

      Delete
    3. Yes, that is one possible application.

      Delete
  2. Would it be possible making distributed information across a network on a torrent-like fashion? Player would be clients and server at the same time... Just an idea.

    ReplyDelete
    Replies
    1. Yes it is possible and very intriguing. But today P2P works well for a large data set which you want to get entirely. It has just been tried with streaming, which took a long time to tune. In this case if you need to make random requests on the data it may not be quick enough for the data to arrive faster than what the player moves.

      I believe it can be done, and it allows for amounts of game content never seen before. It is really difficult to get it working, and does not apply to most existing game concepts. For instance cheating and griefing would be possible in this architecture, so forget an RPG, MMO or any game that is based on stats and resources.

      Delete
  3. This is amazing! I hope to see a release of a game with this engine!

    ReplyDelete
  4. Googly eyes: these really must be your highest priority now.

    ReplyDelete
  5. What about the approach of having a Cluster Based Server Type,
    Lets say you have a "realm" which a group of people.
    Where you have a main server which redirects peoples to certain other servers which are directed to one section on the map.
    Meaning that one "Realm" can contain a network of perhaps 1000 servers. Using the main server as a Realm server to redirect players to clusters could bring massive amount of player in the same world.
    this could really redefine open world RPGs.
    if you had 300 servers in a realm, where each person could carry up to 100 clients that would result in a total of 30000 people in the same world.

    Since voxelfarm has such a large viewing range, Large worlds with travels would really bring a great gameplay experience.

    ReplyDelete
    Replies
    1. Yes, that is sort of the idea. Now with an octree-based design, you do not really need to make distinctions for something like a realm. You just have a 3D grid of severs, some covering larger areas, some are covering smaller, busier areas.

      Delete
    2. So rather than having the entire world go down for maintenance, you can have certain regions down for maintenance... Unless there are some major drawbacks which you aren't telling us, this sounds like it could potentially be a big future for both gaming, and mmos.

      Delete
  6. Wondering how far away changes are noticeable and/or if distance affects the speed of propagation of the changes.

    Also still wondering about trees. I'm assuming they're simply like rock - you can chop the leaves, trunk, etc. But I'm curious if there would be a way to tie the foliage to the trunk and implement some kind of falling over mechanic?

    Which brings me to the question of physics. Is that something you're going to eventually implement or will you leave that to the individual games that make use of your engine?

    Awesome work as usual. Take care.

    ReplyDelete
    Replies
    1. The octree nature of what each player is experiencing also helps a lot on how changes are propagated.

      A cell that is very distant may contain an entire city. That means there would be a lot of players doing a lot of changes. But to a viewer that is all happening inside this huge cell. Now, the cell is very distant, so that the remote viewer gets is a very condensed representation.

      In a typical creative scenario, changes necessarily happen at the highest resolution possible. Players can only change what is around them. These changes are propagated up in the octree representation.

      Now, the higher you go in the octree the more it is OK to wait to buffer all these changes since these high octree cells are only seen from a distance. That is, anyone viewing them won't be able to tell there is a delay.

      Regarding voxel-based physics... I'm not touching that with a ten-foot pole. It is hard to know what constitutes a rigid body when you are only looking at voxels. Where cracks should appear, what are the pivot and gravity points, etc.

      I'm sure this is the future, and we definitively must go there. It may be too early now. I just don't want to get burnt by the sun :)

      Delete
    2. I remember reading how you were experimenting with space colonization for tree generation. Is that what you ended up going with or did you revert to a different method (L-systems)?

      In any case do you maintain some kind of data structure which would lend itself to simultaneously treating trees both like voxels AND rigid bodies? If so then it is my opinion that if you could only implement one generalized implementation of "voxel-physics", it should be with trees (a possible exception being some kind of fluid mechanics generalization).

      And speaking of water, you teased us back in December with it. What happened?

      :P

      Delete
    3. Yes, the trees are still space colonization. A hybrid skeletal/voxel system like the one you propose would be possible. Still it seems quite difficult to get it working. For instance you could have built a treehouse. What happens to it if you cut the tree?

      The water is on hold for now. I got a change in priorities. Getting the networking and storage seemed a better investment. In part because water will require some simulation. That means there would be changes not introduced by players. I wanted to understand what the limits on the server-side were.

      I may even go into the atmosphere and day/night cycles before going back to water. Not sure at this point. I should probably stop talking about what comes next so you guys don't get disappointed.

      Delete
    4. That's a pity - I'm looking forward to seeing how you handle water. Still, I'm a patient man. On another note, have you looked into the oculus rift immersive vr system? your engine would suit itself very well to an immersive vr environment (and it would be very cool indeed!) as i understand it, the rift has support for unity baked in - is it a lot of extra work to provide a stereoscopic stream for such a system? I reckon there would be enough of us followers on your blog prepared to chip in for the $300 to get you the oculus rift developers kit!

      Delete
    5. Well in this case the $300 is not the problem. It is the time it will take to develop for it. Rendering the two views with the odd distortion it requires is not a big deal. But figuring out navigation and interaction mechanics will take some time. I rather have something that is enjoyable in a good old 2D first.

      Delete
    6. I love the Oculus rift (concept, haven't got an actual rift) Sounds like a great idea! It would make it an actual partial hiking simulator XD.

      As for not talking about stuff you are going to do, perhaps instead of saying what's up next, why not just tell us what you plan on doing eventually? =D. (And maybe add a disclaimer of how it can change whenever you want it to change).

      As for the physics, couldn't you just allocate a certain time to trying to get it done, if you can't get it done within that time (or nearly done, to prove the concept works) then you just scrap it, if you do get it done or largely done, you can implement it and see what happens =D. Regardless, you'll learn a lot I bet, and it'll help you plan for the future. (Also, Physics are awesome) Could you perhaps find some inspiration in 2D physics stuff, which work with individual pixels? (Cortex command comes to mind)

      Delete
    7. I'm actually waiting for my Oculus Rift to be delivered and as a Unity user I was thrilled when I saw your implementation in Unity. My first thought was that if you would ever publish your engine I would build a world to experience through the Rift.

      Of course, building a world is already easy enough but your engine builds ones that I find phenomenal.

      Delete
  7. Hey Miguel - Wondering if you could expand a bit more on why voxel physics is currently an impractical goal?

    You mention that "It is hard to know what constitutes a rigid body when you are only looking at voxels. Where cracks should appear, what are the pivot and gravity points, etc."

    Is this related to the way in which voxels typically lack coordinates? Would adding in 'weight' to certain types of voxel data be possible/effective, so you could have basic gravity interactions? Or is this crazy talk?

    At any rate, finding these more technical posts interesting, and am totally excited about this potential day/night cycle. Any chance of some more talky videos in the future? :)

    Thanks for your time, all best

    ReplyDelete
    Replies
    1. Yes, coordinate systems are one problem.

      Typically voxels are aligned with an imaginary global grid (aka the Matrix, dude) Any physics simulation using this grid will suffer severe aliasing issues as entities move, rotate etc. You can keep track of the voxel contours, but it makes it really difficult to do in real time. Or you could have a really high resolution for your Matrix. Either case is beyond what current hardware can do and still be commercially viable.

      Then you could have multiple coordinate grids, so there would be multiple grids, not just one. This is like having a skeleton where the flesh is voxels. So if a wall is broken into three large falling fragments, each fragment will have its own reference frame until subdivided again. This could make the physics solvable, since it would be done at the macro level (using the skeletons and larger envelopes) but then it complicates other aspects like rendering, collisions, etc.

      Ideally we would keep a single matrix and compute all interactions at the micro voxel level. Whether you see walls crumbling or people walking would be emergent behavior. This is how it works in RL.

      To whoever says computers have come a long way and we should be OK with what we have now, without need for more, I point to this particular problem. We are still several generations beyond being able to solve this in realtime, even if it is only for entertainment purposes.

      I really enjoyed this talk by Stephen Wolfram, it is a bit long, but it really goes to the core of this issue:

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

      Delete
    2. Speaking of computers still having a long way to go, do you agree that hardware developers should start focussing on processing power a bit more than graphics than they are doing now? (Note: I am not quite knowledgeable about the hardware world of computers, so if theres reasons other than the general *fancy is better* attitude for the priority of graphics, then I will shut up about this =D)

      Delete
    3. No matter which field, I think we have a very long way to go. I think realtime computer graphics are still very ugly, including the stuff I do. Somewhere I read some frames in Toy Story 3 would take hours to compute. But even pre-rendered CGI is lackluster.

      The industry wants you to believe we have hit a limit on how good the content can look and there is no need for improvement. So they are tweaking non-essential things, and this is how we have come to perceive advances in the field of graphics.

      The real limit is how affordable it is to create the content. At this point there is no motivation to move the hardware further since it would be too expensive to exploit it anyway.

      Delete
    4. Except through how youre doing it, procedural generation =D.
      Well.. it would still be time consuming, but a lot less so.

      Delete
    5. I always though of the future of GPU rendering would be mostly geometry shaders with a CAS based shader system. where the base is some kind of advanced CSG being base models with surfaces/curved surfaces.
      Then geometry shaders are applied to the surfaces with some kind of LOD which increases the amount of functions used to make the detail. depending on the distance. Perhaps randomized Fractal Textures aswell

      Delete
  8. So is this how there going to run TUG multiplayer?

    ReplyDelete
    Replies
    1. No, TUG did not license this networking component.

      Delete
  9. Its really nice idea, but I wonder - how do you solve problem of servers being dependent on each other when it comes to crossing the border. I mean, if we're in some octant A and player moves to neighbouring octant B thats being handled by different server, at some point you need that player to be present in both octants, because some player from octant A may still want to shoot an arrow at player that moved to octant B.

    My point is, such server will never be independent thing that can calculate its own physics, deform terrain etc. because it has to share part of the information with neighbouring servers. Do you have any solution / idea for this?

    ReplyDelete
    Replies
    1. This is traditionally solved by one server having ownership of an object, and any other server that covers the influence radius of the object would keep a ghost copy, which updates through dead reckoning or similar.

      I am considering a slightly different model, where the client connects to more than one server. So for instance if you are near the junction of 4 massive octree cells that are owned by different servers, your client would be sending and receiving data to those 4 servers.

      That would help. In the single connection model often you often see a ghost of a ghost. The client only keeps ghosts. If a given object is not handled by the server where the client is connected, it means the object in that server is also a ghost. So you get two layers of ghosting, which add to latency and prediction errors.

      Delete
  10. Hi! I've been following this for some time now. Do you have any idea what marketing scheme you want to follow? Do you want to release alphas as you go, allowing people to buy it early, in the manner of Minecraft? Or are you planning some Kickstarter? Or just develop it like a normal game, release it when it's done.

    ReplyDelete
    Replies
    1. No idea for now. I don't like the Kickstarter approach because it locks you into whatever you promised and was backed.

      I like more the Minecraft "as-is" approach, where backers get something that is already enjoyable and the developers are free to take the game to where it wants to be.

      I think good games are not designed top-down. They "emerge". Of course you need a framework to start, but if you have the option of growing a game organically this is the best way to go.

      Delete
  11. If the terrain generation is known to both clients, does that open it up to hacks like finding ores or caves?

    ReplyDelete
  12. I am a bit confused.
    how does Hosting Servers work?
    Would there be a posibility of using rout Server, or probably LAN-Server for small private Servers? Then there could be such big Network Servers, who would host These ? And would they cost something to Play on?

    ReplyDelete

There was an error in this gadget