write game before network code?
I'd like to write a client/server network action game. Is there ideas on how to write a basic game first and then break it up to client server, or do most people do both concurrenlty? I'd like to not have to run a server and client everytime when debugging when starting the project so i can get the basics working gameplay/graphics/input.
edit
Thanks
quack
there are some gameplay mechanics [someone was asking here a bit ago about how they could have one player "block" the attack of another, but when the attacked player doesn't find out for maybe half a second it doesn't make attacking someone very satisfying to the person attacking [at worst they might see the attack work a full second later]] which are not possible in a multiplayer [over internet] setting, I'd suggest you do them together.
I suggest setting up you're game design in such a way that there is no difference between client/server and local play. So even when you are playing single player, you have a game server and a client connected with it.
So, the local player then becomes just another network-player, but with really short ping [wink].
So, the local player then becomes just another network-player, but with really short ping [wink].
i suggest you to write the engine in a way that you can easily check out the client code and compile the server code into a independent console application and build in a remote control so you can control the server from a remote control program
directly working in the console window is a no since this will lead to lags if you don t have a seperate thread for the console input/output
directly working in the console window is a no since this will lead to lags if you don t have a seperate thread for the console input/output
Easiest is if the client and server can be compiled and run in the same program. Then a simple "F5" will debug both the client and server at the same time.
At the code, you could structure your client and server code to be polled, in a sense, calling a single "server->step()" and "client->step()" call per time through the main loop. You might also want to separate out client->render(), if you want to be able to step several clients but only render one of them (useful when testing multi-player locally).
Your code might look something like:
Some people like factoring all the "set" calls into a single struct or hashtable called an "operating environment" for the different program components, and pass this environment to all components so they can call each other easily. You can then create two environments, one for the server, and one for the client, to mimic the actual behavior once the programs are compiled as two separate binaries.
Similary, maybe each major system needs to be stepped when in the main loop; that could be done with a stepping service that steps a list of steppables -- you get the idea.
At the code, you could structure your client and server code to be polled, in a sense, calling a single "server->step()" and "client->step()" call per time through the main loop. You might also want to separate out client->render(), if you want to be able to step several clients but only render one of them (useful when testing multi-player locally).
Your code might look something like:
InputSystem * input = new InputSystem(); SoundSystem * sound = new SoundSystem(); GraphicsSystem * graphics = new GraphicsSystem(); LogSystem * log = new LogSystem(); NetworkSystem * serverNetwork = new NetworkSystem( GAME_PORT ); NetworkSystem * clientNetwork = new NetworkSystem( 0 ); Server * server = new Server(); server->setLogSystem( log ); server->setNetworkSystem( serverNetwork ); server->started(); Client * client = new Client(); client->setInputSystem( input ); client->setSoundSystem( sound ); client->setGraphicsSystem( graphics ); client->setLogSystem( log ); client->setNetworkSystem( clientNetwork ); client->started(); while( running ) { input->dealWithOsEvents(); client->step(); server->step(); }
Some people like factoring all the "set" calls into a single struct or hashtable called an "operating environment" for the different program components, and pass this environment to all components so they can call each other easily. You can then create two environments, one for the server, and one for the client, to mimic the actual behavior once the programs are compiled as two separate binaries.
Similary, maybe each major system needs to be stepped when in the main loop; that could be done with a stepping service that steps a list of steppables -- you get the idea.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement