First, I’ve created a network game before. The previous networked game I’ve done had client-side prediction, client-side move gen, and game objects sent to the client from an authoritative server. I’ve always felt it was too much logic on the client side all double checked by the server. IMO, ultimately the client should only care about draw and input.
I am thinking of a new design. It would work like this…
- Authoritative Server
- Clients only receive drawing data (position, angles, color, etc…) (not png/jpg stuff) (pure render and spatial info)
- Clients would contain the image library (no image transmissions)
- Clients have no game object/entity information on it.
- Clients only send controller input data
That’s it in a nutshell. This isn’t for FPS fast pace where milliseconds matter, but there is on-demand movement. Essentially it reminds me of RDP but this wouldn’t be streaming video.
Pros:
- More client flexibility IMO. They’d receive standard draw data and send standard input data. Multi-platform should be easier. Even could be a different language.
Cons:
- Network lag (however, speeds today are so good). Input sent from client, server sends draw information back, drawn on client.
Has anyone tried something like this? How did it work for you?
Thanks.
I’m not an expert on this type of thing, so all I can offer you is some speculation. The major thing that jumps out at me here is that, if I’m understanding correctly, you’d have your server handle all the calculations and just broadcast spatial data to the client. Would it do this every frame? That might actually be a lot…
There was a person asking a question about this a while back and doing it like I think you’re suggesting… the server would calculate the position and then broadcast it to the client. It was really laggy and after they changed it to just broadcast the inputs and let the client calculate position it was a lot better (I dunno if they ever got around to validation).
So I think that would be the crux of it… if your positions aren’t changing often (so you don’t need to broadcast them every frame) then it would probably work just fine. However, if there is a lot of movement, I think you might have issues.
However, some tests would yield some interesting results here I think 
I’m not an expert on this type of thing, so all I can offer you is some speculation. The major thing that jumps out at me here is that, if I’m understanding correctly, you’d have your server handle all the calculations and just broadcast spatial data to the client. Would it do this every frame? That might actually be a lot…
Great question. No, it wouldn’t do it every frame. Just when an object changes a push would happen. So if something moved, that object would broadcast out its new spatial. So all static objects would only really have one push, any movable objects would broadcast when a move is executed. I would also keep the packets super small, like: ID,X,Y,Z.
There was a person asking a question about this a while back and doing it like I think you’re suggesting… the server would calculate the position and then broadcast it to the client. It was really laggy and after they changed it to just broadcast the inputs and let the client calculate position it was a lot better (I dunno if they ever got around to validation).
So I think that would be the crux of it… if your positions aren’t changing often (so you don’t need to broadcast them every frame) then it would probably work just fine. However, if there is a lot of movement, I think you might have issues.
However, some tests would yield some interesting results here I think
Interesting 
. I think it would work. Lighting/Shadows and effects would be calculated and drawn on the client based off of other draw/spatial information.
Thank you for your thoughts and brainstorming. I know this question is more theoretical. I think some small scale tests will yield the best answer.
Yea, so I think this would really be the deciding factor. If things don’t move often then it would probably be fine… and easier, to be honest. But if things move often that will generate a lot of network traffic and you might have issues like the other guy did.
I’m interested to see how your experiment turns out
I’ve played around with this concept a bit myself and come to the conclusion that with available bandwidth being so large these days it could be possible provided we can guarantee 100% packet delivery in time. This is not true, especially regarding the “in time” rule.
The huge issue with this approach is that you cannot do any preditctive compensation to network lag. In other words not having the properties of the objects you would either predict by deriving speed from position in time (don’t do it) or send the speed of the objects along with the positions. Still not knowing the logic behind it the client would not be capable of respecting the collisions or even basic limits like say joint angle limits for a model and so on.
Don’t get me wrong, it can be done, especially if you aim to use it in a lan party, but once you get to real world networks and the bounces between routers, wifi connections and so on will more often than not create a lot of stutters with object movements.
I would suggest to try it small scale, in a test environment capable of exacerbating theese limitations, so that you have a clear understanding of it BEFORE implementing it on a large scale game/promising delivery to users.