I am making a game that will have 3 different window apps... client... im not good at lingo.
One will be the launcher/login screen.
Second will be the lobby/chat/store/stats etc
Third will be the game you enter through lobby.
So how would you start working on this?
It will be the first big game I make.
And I never done networking before so there will also be questions about server client etc.
Thanks, This is the best forum in my life!
3 different clients.. Which is father and child?
Head over to the multiplayer forum
There's a FAQ there you should read.
In general (since I have no idea what language, API's or tools you will be using) there will be 1 client, that's the one the user is on. he will initially connect to the login machine which houses the lobby, etc. Then, when he plays the game, the login machine will direct the client to connect to the game server.
But, you've got a long way to go before you get to that point if this is your 1st time writing network code.
There's a FAQ there you should read.
In general (since I have no idea what language, API's or tools you will be using) there will be 1 client, that's the one the user is on. he will initially connect to the login machine which houses the lobby, etc. Then, when he plays the game, the login machine will direct the client to connect to the game server.
But, you've got a long way to go before you get to that point if this is your 1st time writing network code.
Author
Head over to the multiplayer forum
There's a FAQ there you should read.
In general (since I have no idea what language, API's or tools you will be using) there will be 1 client, that's the one the user is on. he will initially connect to the login machine which houses the lobby, etc. Then, when he plays the game, the login machine will direct the client to connect to the game server.
But, you've got a long way to go before you get to that point if this is your 1st time writing network code.
Thanks, But I was wondering about those 3 different aps I mentioned..
So when I go to login screen/launcher... and should that app shut down and then the lobby launches?
And when you start a game from the lobby, The lobby runs in the background?
Should game be child to lobby?
And is lobby father to launcher or child to launcher?
[quote name='BeerNutts' timestamp='1341608511' post='4956471']
Head over to the multiplayer forum
There's a FAQ there you should read.
In general (since I have no idea what language, API's or tools you will be using) there will be 1 client, that's the one the user is on. he will initially connect to the login machine which houses the lobby, etc. Then, when he plays the game, the login machine will direct the client to connect to the game server.
But, you've got a long way to go before you get to that point if this is your 1st time writing network code.
Thanks, But I was wondering about those 3 different aps I mentioned..
So when I go to login screen/launcher... and should that app shut down and then the lobby launches?
And when you start a game from the lobby, The lobby runs in the background?
Should game be child to lobby?
And is lobby father to launcher or child to launcher?
[/quote]
Just make it one application with multiple states instead, if you have a launcher its best to keep it simple and only use it to update the actual game (it shouldn't deal with things like logging in etc, just have it check that the game is up to date and then start the game)
Author
[quote name='glhf' timestamp='1341609559' post='4956478']
[quote name='BeerNutts' timestamp='1341608511' post='4956471']
Head over to the multiplayer forum
There's a FAQ there you should read.
In general (since I have no idea what language, API's or tools you will be using) there will be 1 client, that's the one the user is on. he will initially connect to the login machine which houses the lobby, etc. Then, when he plays the game, the login machine will direct the client to connect to the game server.
But, you've got a long way to go before you get to that point if this is your 1st time writing network code.
Thanks, But I was wondering about those 3 different aps I mentioned..
So when I go to login screen/launcher... and should that app shut down and then the lobby launches?
And when you start a game from the lobby, The lobby runs in the background?
Should game be child to lobby?
And is lobby father to launcher or child to launcher?
[/quote]
Just make it one application with multiple states instead, if you have a launcher its best to keep it simple and only use it to update the actual game (it shouldn't deal with things like logging in etc, just have it check that the game is up to date and then start the game)
[/quote]
What exactly are states and why shouldn't the launcher have the login?
A state is... well, a state -- think the same definition as in "a state of mind" or "state of being". Common states in games are "gameplay", "paused", "main menu", etc. At a basic level, you can represent states with a simply switch/case structure; you run the logic for the state in which the game is currently running, and pausing the game or displaying a menu is done by running the logic from a different state.
In general, the functionality you've described would simply be different states within the same executable rather than separate executables.
As to the networking -- each player runs a client, which connects to a server. You run a server which the clients connect to; in a very slightly more complex situation, you might instead have one of the players run the server and other player (clients) would connect to that server; you might run an additional server which helps to connect player clients and servers.
In general, the functionality you've described would simply be different states within the same executable rather than separate executables.
As to the networking -- each player runs a client, which connects to a server. You run a server which the clients connect to; in a very slightly more complex situation, you might instead have one of the players run the server and other player (clients) would connect to that server; you might run an additional server which helps to connect player clients and servers.
This is a fairly good beginning explanation of what a state is and where they can be seen.
http://gamedevgeek.com/tutorials/managing-game-states-in-c/
One of the objectives you should consider when developing software is usability. Making 3 totally different "forms" or "windows" can create an experience that ranges from confusing to down right annoying (also, I consider this unprofessional as well since it makes your app look unpolished). If you handle these three states as, well.. states then you will have a much easier time understanding how to transition between them, which seems like the very thing you are asking about. If you create a state manager and delegate the actual functionality of the game to the child states, then the parent becomes your "State Manager" and the children are the "states". You should look into states as it has a lot of applications (Finite State Automata and AI for example) besides just managing views.
http://gamedevgeek.com/tutorials/managing-game-states-in-c/
One of the objectives you should consider when developing software is usability. Making 3 totally different "forms" or "windows" can create an experience that ranges from confusing to down right annoying (also, I consider this unprofessional as well since it makes your app look unpolished). If you handle these three states as, well.. states then you will have a much easier time understanding how to transition between them, which seems like the very thing you are asking about. If you create a state manager and delegate the actual functionality of the game to the child states, then the parent becomes your "State Manager" and the children are the "states". You should look into states as it has a lot of applications (Finite State Automata and AI for example) besides just managing views.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
