I have a couple of questions concerning browser based games. Not the flash type, the ones that use web pages as their interface.
Would it be necessary to have each component run in a separate process? Components could be, for example, the main game logic, login/registration and leaderboards. Should I worry about the overhead of having some users requesting a battle outcome while others are trying to register?
Is it wise to worry about the images the server sends to the client and the bandwidth overhead or should I let the clients browser cache worry about it?
Is writing my game's server in C++ or similarly low level language going to create more problems than speed issues it solves? Would I be better off sticking to something like PHP for example?
Is this 'plan' feasible? Start with shared hosting and gradually upgrade to VPS and dedicated hosting as my game grows and I need more power.
How would I calculate a handy figure that shows the "cost per month per player?" This would give me the cost of hosting the game for a month for every player I have. It would facilitate my hosting upgrade decisions. Do I really need to be concerned with this?
Are there any other 'big' issues with creating browser based games concerning speed and web hosting that I should know about
I'm asking most of these questions because I'm concerned with the speed of my game and, the efficiency and security of the server. If I were to make a browser game I think I would have to make full use of the server because I don't have much money to spend on hosting it...
I hope that these questions aren't too vague and hard to answer.
This depends entirely on the type of game you're trying to make. Some games can be "web based" but run entirely on the client using, say, JavaScript; obviously you can also go all the way up the scale to making constant round-trip requests to your server to coordinate gameplay.
In short, I think we need a lot more detail on the game you want to build to really have meaningful answers.
You will likely be bound on I/O rather than CPU, so C++ would probably be a waste, at least to get started. If the game is super successful and CPU load becomes a bottleneck, you could re-code the logic in C++. That's a problem that's very nice to have :-)
Also, for web services in general, it's more important that you are scalable (can serve more users by plugging in more servers) than being CPU efficient in the small. Make sure your database, caching, and game logic work in a horizontally partitioned multiple-web-server setup, and the rest of the details will be a lot simpler to solve.
This depends entirely on the type of game you're trying to make
Think of it as like a text based online rpg, but in the browser. The server returns web pages to the client. Pretty much every action would have to request some info from the server or get it to compute something.
You will likely be bound on I/O rather than CPU, so C++ would probably be a waste, at least to get started. If the game is super successful and CPU load becomes a bottleneck, you could re-code the logic in C++. That's a problem that's very nice to have :-)
Also, for web services in general, it's more important that you are scalable (can serve more users by plugging in more servers) than being CPU efficient in the small. Make sure your database, caching, and game logic work in a horizontally partitioned multiple-web-server setup, and the rest of the details will be a lot simpler to solve.
Ok, so your saying that I should use something like PHP to start off and if needed, recode some bits in c++. I think I could do this by either making some sort of DLL or getting PHP to start executable files.
What do you mean by making sure my setup works horizontally?
Think of it as like a text based online rpg, but in the browser. The server returns web pages to the client. Pretty much every action would have to request some info from the server or get it to compute something.
If you're basically making an interactive web site, writing your own "server" is massive overkill. Use something like ASP.Net or PHP or Rails or whatever else; there are plenty of good frameworks for building interactive/dynamic web content that don't require you to reinvent a million wheels.
Right now, you probably want to focus on making a GAME.
The only hosting you're likely to need is on your own development server's virtual machine(s) for testing. I suspect (from this question) that you're so far away from having a usable game that you don't need to worry.
As far as how you structure your server side code - do the simplest thing that could possible work. Go with technologies you know, or at least have some understanding of.
Personally I wouldn't write a game server in C++ (or indeed, anything else if possible). But that's only because I find other languages more productive (all of them, actually, including ones I've never used).
