🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Simplifying the Client/Server model

Started by
0 comments, last by LemonCholy 22 years, 4 months ago
I want to add networking to my game. However, it''s not my primary focus, so I don''t want it to impede the development of the rest of my game. With the vast increase in broadband technologies, I''d rather sacrifice some, or hell, a lot, of network efficiency to have a clean and extensible model. Which I guess means moving towards more of a dumb-terminal approach. And that''s my problem. How do I do that? And how far can I take it practically? I know how Quake etc does things. I also know it has a lot of retraints and complications, a lot of stuff has to be hard-coded and it limits what can be done in single-player. Carmack mentioned this and how he plans to compromise network efficiency (no 56kers) in Doom 3 to simplify the networking model. I figure that the game has to be divided into events and state. For example, a particle effect could be an event, a sound would be an event, entities positions would be part of their state. I already see a problem here. I''d need to explictly code for all the events in my network model, which complicates dependencies. And state updates would need to identify what types of objects are being serialized, which implies some kind of run-time type-identification - even more complications and dependencies to my nice clean single-player game model! Are there any good answers to this question, or will I need a hodge-podge mix of the above. All I want to do is find a clean simple extensible solution to networking to my game.
Advertisement
Im messing around with an implementation that''s loosly based off the Q3 network code. Basically state is tracked for each object that will update it''s state on clients across the network. Each state is signed with a state ID.

Basically the server enumerates clients and see''s the last ACKed state for each object and generates a delta packet taht will bring them up to the current state.

The sweet thing is that you can use UDP and you dont have to worry about dropped packets because each packet will bring the client up to the current state. IT''s a simplified network modle because you dont have to worry about sending reliable udp packts and unreliable ones.. everything just takes care of itself.

I realize that there are drawbacks to this approach, tracking state on the server could have heavy mememroy requirements... clients who miss alot of packets could cause very large delta packets...exceeding the MTU... but there are ways to mitigate these problems... performing per-packet huffman compression on each packet etc.

This topic is closed to new replies.

Advertisement