C++ plugin architecture
Author
Hello:
I am working on a lobby system which allows new games to be pluged at a later stage. The game will use the network packet from the lobby system.
Here is the basic flow of the system.
1. Player downloads the client.
2. player registers an account
3. player logins to the system
4. In the system, player can see a list of games
5. player click one the the game and the lobby system shows all the rooms associated with that game.
5. In the room, player can join or host games.
Games will be made independently from the lobby system and be pluged later.
Just wondering if any has done the samthing before and can give me some hints :p
Thanks
Leo
There's a few solutions I can think of offhand, depending on the size and technology of the games and the precise types of integration with the lobby that were required. One simple solution would be to have games be separate executables, with the lobby invoking them and passing in a standardized set of command-line arguments.
Author
Thanks for the reply.
I thought of that before. But is it possible to pass the object via the command line argument?
I want the game to use the socket that is already opened by the lobby system, instead of opening another one.
Another way will be to provide the new games as the patch, that is what I can think of right now :p
I will keep researching for possible solutions.
Thanks for the suggestion
Leo
I thought of that before. But is it possible to pass the object via the command line argument?
I want the game to use the socket that is already opened by the lobby system, instead of opening another one.
Another way will be to provide the new games as the patch, that is what I can think of right now :p
I will keep researching for possible solutions.
Thanks for the suggestion
Leo
Quote:Original post by takoyakiNo. But that's probably for the best, because you shouldn't use the same TCP connection for both lobby stuff and game stuff. Splitting up the two will make things a heck of a lot more convenient on both the client and the server side.
But is it possible to pass the object via the command line argument?
Author
Quote:No. But that's probably for the best, because you shouldn't use the same TCP connection for both lobby stuff and game stuff. Splitting up the two will make things a heck of a lot more convenient on both the client and the server side.
Ya, I think that is the best solution for both ends.
Thanks for the suggestion
Leo
EDIT
For some reason, I posted here my answer to another thread. Deleted. Sorry
[Edited by - cignox1 on January 20, 2009 1:40:05 AM]
For some reason, I posted here my answer to another thread. Deleted. Sorry
[Edited by - cignox1 on January 20, 2009 1:40:05 AM]
Just to comment on the TCP socket.. If you think about it, the reason for splitting them up comes down to data management. It would be a huge pain to have to filter out packets coming from the lobby system or vice versa for the game system.
I know online systems like Blizzard Battle.net use a separate connection for the game server and the lobby. It makes life easy and you do not need to keep around the state of the lobby crap when your in the game, assuming you can just disconnect from that and clean it up if your not using it anymore.
I know online systems like Blizzard Battle.net use a separate connection for the game server and the lobby. It makes life easy and you do not need to keep around the state of the lobby crap when your in the game, assuming you can just disconnect from that and clean it up if your not using it anymore.
Author
Quote:Original post by wacko420
Just to comment on the TCP socket.. If you think about it, the reason for splitting them up comes down to data management. It would be a huge pain to have to filter out packets coming from the lobby system or vice versa for the game system.
I know online systems like Blizzard Battle.net use a separate connection for the game server and the lobby. It makes life easy and you do not need to keep around the state of the lobby crap when your in the game, assuming you can just disconnect from that and clean it up if your not using it anymore.
The system will use UDP instead of TCP, for both the lobby msgs and game masg.
So the initial design now will have 2 ports opened at the server side, one for the lobby msgs and another one for the game msgs. Since UDP is connectionless, one thread to handle all the game mags will be good enough, with a well design network API :p
But if that is not the case, I am thinking to dynamically open a game port once the game is about to start. the newly created game port will be passed to the game via command argument.
What do you guys think?
Thanks for suggestions
Leo
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
