I'm coming from a mud background and want to work on a coordinate based game this time around.
One thing that has me a bit confused is how networked games (i.e. MMO, FPS, etc), would deal with coordinate granularity.
I mean, lets say I have an avatar that measures 120x120 wide/deep and 240 pixels tall. So to represent this avatar on the map, the trivial approach would be to make all x,z coordinates a grid consisting of 120x120 pixel squares and ensure that the avatar always "belongs" to a single x,z coordinate at once.
Thats fine but I see a few problems with it, mainly though: 1) you have no real sense of offset here during movement and 2) what about large objects or abnormally sized avatars (i.e. halfling? giant?).
With (1) I can see this being solved by using a velocity and previous x,z coordinate so you simply animate the avatar to the next coordinate client side, so that doesn't seem like a huge issue except that people are always going to be moving in a fixed 120px manner which may look a bit odd.
With (2) The only solution I see here is to span multiple coordinates for something large, like a castle for instance, or perhaps you could take and composite a castle by combining a bunch of 120x120x240 blocks - which I would think could be expensive and a real pita for importing models, etc…
So the other thought I have is you could make every x,z coordinate consist of the largest allowable object in your game, or maybe a huge chunk thats something like 12,000x12,000x24,000 pixels. The problem here is now your really going to have some odd movement and if your shooting at someone thats an awfully large space to account for wrt accuracy etc (i.e. shooting a pistol at one edge while the player is visually at the other still "hits" x,z?).
I guess you could resolve this by using a sub-coordinate for each global coordinate (i.e. player is located at { 234,126,0 } in the world and their subcoordinate is { 11234 , 10990 , 0 }).
Anyhow, obviously I need to get my head wrapped around how coordinates really work in a 3d space … do i base the grid on avatar size? largest supported model size w/subcoordinates? or perhaps just make it extremely granular where every point on the map may translate to some 1x1 pixel space?
How do you handle this issue?
Instead of moving, say, 120 pixels every time you update, you could set a velocity of 120 units per second and calculate how much to move the character per frame or update (client-side). So, you'll move at 120 units every second, however it won't be jerky, as each update will move the character {fraction of a second passed}*120 units (which will likely be a floating point number, like Momoko said). For different races (giants versus halflings), you could set a velocity for each race proportional to that race's size.
But, remember, when dealing with jME you generally don't deal with pixels in the coordinate space, but rather with world units.
The issues I had (I came from a MUD background, as well), was placing some reliance on the client to perform the checks it's supposed to, and moving to a floating-point-based world unit system.
The first issue is a bit more complex, and depends on how much you trust the client, so I won't get into it…but for the second I tried a few things.
- Simply use floating-point numbers for positions, and send updates in that manner. This allows for very fine control of location, however you may or may not have issues with server-side calculations of position/collisions.
- Convert your floating-point space into a grid by assigning a size for each spot on the grid. I would simply use a velocity in x/z directions, and when the character moved, let everyone know. When the character is within a certain distance from the "center" of the grid spot, I decided he should stop. However, this could lead to position differences among clients.
Sorry about the rant, I found something interesting and kept going…
Alright, using real numbers seems fine - I'm a bit concerned about performance implications of this … traditionally it seemed to be a real issue for performance as I recall in the pascal/asm/c days 
. From what I've read jme is using floats for world coordinates, so really my server code just needs to deal with floats for an objects position in the world and that will be how I keep client and server sync I take it.
The reason for my confusion comes down to collision boxes and representing larger objects in that vein, thanks for your help sarcius you've made it clear I was over (under) thinking that one .
Unless you're programming cellphone games, floating-point is the (only) way to go. In fact some of the new cellphones which support Mobile3D (M3D) use floating-point as base.
Well, I think the issue here (correct me if I'm wrong) is with the server doing all of those floating-point calculations and communications.
Like I described, one way I handled it was to use a simple grid, in which the server would simply deal with X/Z coordinates of grid positions (50,2), and the client do the footwork for translation. Granularity could be improved by decreasing the size of each grid position, but that simply can become an annoyance client-side (however easy it is doing it server-side). It actually was very workable, however I just got tired of seeing all that translation code in the client :P.
This would be useful for any server that has to handle a massive amount of players at any one point in time, however this could (at times) be handled by distributing the load among other machines.
Again, I ramble…but hopefully it gives people ideas.