I've already wrote that clients can't work with double, and will you enjoy if your traffic will be multiplied by 2?
The integers are bad when I check for collisions - I need to transform to float/double - it's an extra time...
Big 3D landscapes
hplus0603 was saying that ONLY when you move over a kilometer or so, THEN you send a single packet with a reference point update in double precision. Take a look into zoning and relative coordinates to improve accuracy in your coordinates - you'll have to think about it anyways as you can't move 500km away from the origin in your scene and render with perfect precision.
Quote:
And what do you advise about visibility? Yes, I have such grid, but how to define whom do I see, who can see me? And if nobody saw me before I need to send an information about me first. Also there is some static objects that cannot inform dynamic objects that "we are here".
Golden rule:
If I can see an object that object can also see me.
The simplest approch is to use radial space. Ie, You can see everything in 50m radius. Of course, if you are in a highly populated area, this may kill performance (major hubs)
another solution is to make the space you can see dynamic, so it changes with the density of the population around you. Ie, you define that the client should see no more than 50 dynamic objects at any given time and you make the algorithm accordingly. If you study how collsion trees work you will get some good ideas on how to implement a system like this.
I also think the advice of splitting the world into a grid of smaller zones (1kmx1km or 2kmx2km) is a good idea. You can also take advantage of this grid map to handle resource managment on the client.
Quote:Original post by Anton Vatchenko
I'll write again. Client doesn't support doubles.
What are you supporting that doesn't have double precision functionality? Just curious. I thought most - if not all - modern computers for quite a while now support double precision.
Quote:Client doesn't support doubles.
But client can't see entire world at the same time anyway, unlike parts of the server (potentially). Thus, client could get all data in a specific reference frame, and that reference frame would be determined at the server side, and occasionally changed when the player moves "far." All that data can be sent using floats.
Fixed point arithmetic can actually work just fine even when colliding, especially if you have 64-bit ints available (which you may not have). Only if there is no integer division instruction will collision detection with fixed point require transformation to float.
Anyway, if the client is a mobile device, I suggest that trying to show 500km x 500km through a 2" screen is probably not the best game design. You can easily get away with zoning, instead of a single seamless world, when that is the interface. The client doesn't even need to display that it "zoned."
Most MMOs that are "seamless" are actually still zone based, you just don't realize most of the time. In fact, it's a pretty natural way to do load balancing between server processes. There's various techniques to handle transitions between zones to make players not realize, both technical ones (using proxy objects on one server representing objects on another, and syncing needed state) and gameplay design ones (don't keep any NPCs around near borders, and make it impossible to "pull" a mob across one, which saves you the need to "transfer" an NPC from one server to another).
The same principles would apply for non-MMO games.
Of course this isn't useful if you're just going to run this on one physical box, but then I'd be interested in seeing how you're going to have enough game content and players to fill a world that large, that doesn't require more processing power than one box can handle :).
The same principles would apply for non-MMO games.
Of course this isn't useful if you're just going to run this on one physical box, but then I'd be interested in seeing how you're going to have enough game content and players to fill a world that large, that doesn't require more processing power than one box can handle :).
Fixed point integers can be sufficientwhen used with 'zones' which have a local coordinate (fine) system with the zones having a coarse coordinate system (where you can have variable sized zones just as longa as they are in increments of the coarse system). You onlu need fine coordinates for things that you can see (and even they can have minimum granularity in inches --
a Int16 can represent ~16383 feet at a 3 inch/tic base coordinate system.
That would have to then encompass the nearby zones (adjacent to the one the player is in) and then further out (where you cant see tiny increments anyway) you can have objects positioned directly in the coarse system (say 1000 zones wide with 64 increments each equalling the 16k feet (64k x 3 inch points) --
ratio between the 2 systems of 1:1024 or less if your 'world' scales smaller (or actually more like 1:256 because the fine coordinate range should encompass an areas roughly 4 zones wide).
Im working on something similar to this and use a heightmap system for most of the world (with 16bit heights... to a differnet Z system) but with grid zone areas possibly substituted with a navmesh + detailed mesh where overhangs and other complex shapings are needed (like tunnel entrance transitions) and yet another structure type zone system used for buildings and vehicles which float on the primary terrain (and which are also local coordinates because they can move and rotate ).
The 'fun' part of the continuous/seamless 'zone' system is of course the transitions of players and npc and projectiles and events (like sounds) tranmission, especially when you have zones which run on different server machines in a cluster (and npcs AI on others...). The npcs can see across the boundries, so the data flow for the AI dwarfs that sent to the users. Im aiming for a higher level of interactions with passive objects (many of them) and am examining a third tier coordinate system for objects VERY near the player (for objects that you would have a hard time seeing 40 feet away).
a Int16 can represent ~16383 feet at a 3 inch/tic base coordinate system.
That would have to then encompass the nearby zones (adjacent to the one the player is in) and then further out (where you cant see tiny increments anyway) you can have objects positioned directly in the coarse system (say 1000 zones wide with 64 increments each equalling the 16k feet (64k x 3 inch points) --
ratio between the 2 systems of 1:1024 or less if your 'world' scales smaller (or actually more like 1:256 because the fine coordinate range should encompass an areas roughly 4 zones wide).
Im working on something similar to this and use a heightmap system for most of the world (with 16bit heights... to a differnet Z system) but with grid zone areas possibly substituted with a navmesh + detailed mesh where overhangs and other complex shapings are needed (like tunnel entrance transitions) and yet another structure type zone system used for buildings and vehicles which float on the primary terrain (and which are also local coordinates because they can move and rotate ).
The 'fun' part of the continuous/seamless 'zone' system is of course the transitions of players and npc and projectiles and events (like sounds) tranmission, especially when you have zones which run on different server machines in a cluster (and npcs AI on others...). The npcs can see across the boundries, so the data flow for the AI dwarfs that sent to the users. Im aiming for a higher level of interactions with passive objects (many of them) and am examining a third tier coordinate system for objects VERY near the player (for objects that you would have a hard time seeing 40 feet away).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
