What to program first in an online game
I am wanting to make an online game but no idea where to start. I know that if I made it off line then I would have no problem. Should I start on the server then make the client, or just make the game as if it wasn''t online then make the server?
Language: Python
-Libs:
--Pygame (SDL wrapper)
--Twisted (networking)
A day will never come when I shall emit defeat
You have to design both in tandem. Here''s a way of incrementally arriving at that point:
Typically, you''ll implement it as a single-player game first, but in a way where there are two pieces of code (server and client) actually separated by a communications API. You can make these two processes, or just two pieces of the same program.
Once that''s done, move the server to another machine, and make it work (still single player). Then add the second player, and when that works, add support for N players.
Typically, you''ll implement it as a single-player game first, but in a way where there are two pieces of code (server and client) actually separated by a communications API. You can make these two processes, or just two pieces of the same program.
Once that''s done, move the server to another machine, and make it work (still single player). Then add the second player, and when that works, add support for N players.
enum Bool { True, False, FileNotFound };
In my experience(which is limited) so long as you employ a good level of abstraction regarding your game engine, integrating network support is not that difficult(coding the network engine is a bit tough, but the integration aspect is not)
i do see alot of people saying that you must consider each in tandem, but the idea of lousely coupled objects should belay that concern to a large degree.
Dredd
________________________________________
"To die with your sword still in its sheath is most regrettable" -- Miyomoto Musashi
i do see alot of people saying that you must consider each in tandem, but the idea of lousely coupled objects should belay that concern to a large degree.
Dredd
________________________________________
"To die with your sword still in its sheath is most regrettable" -- Miyomoto Musashi
"Let Us Now Try Liberty"-- Frederick Bastiat
The first thing you should do after gathering your desing is to implement the networked objects, getting these right at an early stage is pretty much essential and it''ll save you a lot of time and heartache later on.
Might be a bit obvoius but having shot myself in the foot a couple fo times its always a good one to point out. Personally i''d design and test a network resource that can only be modified by one client at a time first, it sounds trivial but it can be a royal pain in the butt once you start accounting for client disconnects etc.
Might be a bit obvoius but having shot myself in the foot a couple fo times its always a good one to point out. Personally i''d design and test a network resource that can only be modified by one client at a time first, it sounds trivial but it can be a royal pain in the butt once you start accounting for client disconnects etc.
"...it sounds trivial but it can be a royal pain in the butt once you start accounting for client disconnects etc."
Yeah graceful disconnects can be a real pain in the butt. Ungraceful ones are a little easier since once you determine the client is "linkdead" (disconnected) you basically just remove them from the game and then finalize any database transactions they may have been doing. Or if they were say in the middle of a trade with someone, you have to cancel the trade and then send the notification to the other player.
Graceful disconnects have the above problem, but also the added complexity of shutting down the connection and ensuring that all queued packets have been recieved, acknowledged and accounted for.
This is pretty much the area im working through on my stuff right now. If the client tells the server hey, i just logged out, it should quit sending packets. However there may have been packets sent from the client before the disconnect message that may have not been recieved by the server yet.
So while the client isn''t going to be sending any new packets, its still going to have to handle resending the packets if they''ve ended up lost somewhere. Now to add fuel to the fire, what happens if these packets that were sent before the client disconnect packet require that the client recieve some sort of response from the server. SO now the cleint has to keep its ears open, but its mouth shut in a way, until every thing is level on both sides. Same goes for the server.
Once everything is done and neither side have any unfinsihed business with the other, the client can finally exit back to the menu screen or whatever screen the game requires.
Dreddnafious mentioned above that abstraction can help when dealing with things like this and it totally makes sense. Ideally, youd want your network subsystem to be independant of the game, and modular enough that you could just tell the connection is shutting down and to finish up business and it does it and handles all the magic while you wait.
Honestly, sending packets back and forth and using winsock is the easy part. Its things like the above that make network programming in games difficult.
While this wasn''t totally on topic, I hope it gives you some insight as for what to expect.
-=[ Megahertz ]=-
Yeah graceful disconnects can be a real pain in the butt. Ungraceful ones are a little easier since once you determine the client is "linkdead" (disconnected) you basically just remove them from the game and then finalize any database transactions they may have been doing. Or if they were say in the middle of a trade with someone, you have to cancel the trade and then send the notification to the other player.
Graceful disconnects have the above problem, but also the added complexity of shutting down the connection and ensuring that all queued packets have been recieved, acknowledged and accounted for.
This is pretty much the area im working through on my stuff right now. If the client tells the server hey, i just logged out, it should quit sending packets. However there may have been packets sent from the client before the disconnect message that may have not been recieved by the server yet.
So while the client isn''t going to be sending any new packets, its still going to have to handle resending the packets if they''ve ended up lost somewhere. Now to add fuel to the fire, what happens if these packets that were sent before the client disconnect packet require that the client recieve some sort of response from the server. SO now the cleint has to keep its ears open, but its mouth shut in a way, until every thing is level on both sides. Same goes for the server.
Once everything is done and neither side have any unfinsihed business with the other, the client can finally exit back to the menu screen or whatever screen the game requires.
Dreddnafious mentioned above that abstraction can help when dealing with things like this and it totally makes sense. Ideally, youd want your network subsystem to be independant of the game, and modular enough that you could just tell the connection is shutting down and to finish up business and it does it and handles all the magic while you wait.
Honestly, sending packets back and forth and using winsock is the easy part. Its things like the above that make network programming in games difficult.
While this wasn''t totally on topic, I hope it gives you some insight as for what to expect.
-=[ Megahertz ]=-
-=[Megahertz]=-
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement