leander_kurscheidt at February 11th, 2012 14:30 — #1
I am currently working on a browsergame: http://devmaster.net/forums/topic/15925-idea-for-a-browsergame/
Its a mmo (strategy to be clear).
Right now im learning SQL and thinking about the "structure" of my server application.
My plan is to have one "login"-server, who checks the password and the leads to another server, who manages all the things (one per world).
Is this a good structure?? Or are there existing, better models??
I will keep asking questions about my project in this thread so my topic is pretty generaly.
geon at February 11th, 2012 15:57 — #2
Why would you use several servers? It seems to only add complexity. Are you worrying about scaling? A single server architecture will support thousands of players, so don' worry abour performance.
leander_kurscheidt at February 12th, 2012 06:17 — #3
Yes im worried about scaling.....I don´t have any experience with brosergame
geon at February 15th, 2012 05:44 — #4
Dont worry about performance and scaling. Unless you manage to build the next Farmville, you won't have any problem running the server on your laptop.
alphadog at February 15th, 2012 09:42 — #5
I wouldn't say "don't worry about performance". It's good to at least have an idea of where you're heading, so that you can build in anticipation where it makes sense. However, the other end of the spectrum, where you are definitely heading, is premature optimization. As Geon says, a given modern, non-virtualized server with a well-design codebase, can easily handle thousands of connections for casual games, and hundreds to low thousands for more real-time games.
First, get the game going on one server, but keep your code very modular. For example, can you cut out the authentication/authorization subsystem without affecting too much other code? If so, it becomes easier to pull parts out when 1) it is coded well, and 2) you have cashflow to spend on a dev to focus on this for the company.