Hmmm... Running the client and server on the same machine but DIFFERENT program is possible, I had already tried it. But what I wanted to do is putting the client and the server in the same running program instance. For example, when you host a game in Half-Life or Quake, it first create a server, and then create a client that represent the host player, and connect to the server that it created. But as you pointed out, DBpro is not multithreaded, I guess this is not possible.
Making the server a seperate program will be something like a creating a dedicated server. I am thinking of this possibility as well. But since the server need to do all the game state updating and stuff, thus it must be able to use those DBpro functions (like positioning object and collision detection, etc.) as well. I had seen most dedicated server doesn't have any user interface (or merely very simple GUI console). This is done such that the server doesn't need to have a good 3D accelerator as well, but just a powerful CPU.
I was considering of creating a dedicated server in DBpro, since I need the DBpro function (as I mentioned above.) But to avoid graphical update, I thought that I might omit the SYNC call in my game loop. I am wondering will this cause any problem? If what SYNC really do is merely rendering job then it should be fine. But what I afraid is SYNC will do other stuffs like updating the internal state of the 3D engine, e.g. object position, collision data, etc. If this is true, meaning that making a dedicated server might not be a feasible choice.
To further elaborate why seperating client and server logic apart is viable, this is to make the implementation logic cleaner and easier. The server will just responsible for receiving input from client and update the game state, no rendering or checking for user input from physical input device is needed on the server. At the client side, it just need to check for input from the user and send it to the server, maintain a subset of the game state, and update this subset as it receive the state update from the server, and render them on the display device. Combining the client and server logic in a single implementation under client/server model is somewhat messy, and more prone to bugs.
Phew... long paragraph. I hoped I didn't make anybody fall asleep.
Bad Nose Entertainment - Where games are forged from the flames of talent and passion.
http://www.badnose.com/
