Browser game architecture considerations

Question

I am currently working on a browser game. It's not my first one, but it is the most complex I have worked on to date.

In the past, I would code everything in PHP, and have functions checking whether certain maintenance operations were required or not, carrying them out when necessary (for instance, if players must receive 50 gold every day, I would have a function which checks when was the last time 50 gold were added to each player; if it's less than 24 hours, do nothing; if it's more than 24 hours, then add 50 gold * the number of times 24 hours have elapsed (in case no one has accessed the website in more than a day)).

This worked, but was rather inelegant and resulted in a quite large and complex codebase as the game's features grew.

For my current architecture, I am thinking of having a very elementary front end that just fetches the data from a database and renders it in the browser; when players perform actions from this front end, it adds the actions to an event queue.

Then I would have completely separate server code running 24/7 (written in C++ or Python or whatever) which would be continuously polling the event queue, updating the database accordingly, and also run a set of functions at various intervals (for example, add 50 gold everyday), a bit like cron would.

I think this architecture will be better, as it will allow me to better separate game logic and front end; it will scale better; and it will just make for better code overall.

Are there any considerations/drawbacks with such an architecture?

Answer 1

The answer is yes.

Basically you are considering moving from server side scripted game to a dedicated running server, which runs all the time and the clients talk to (presumably through web services or something).

In your "do a bunch of checks in your php file" manner of doing things, it was relatively simple to update what the game did.... you'd dink the appropriate php file in your test/dev environment, see if it worked, and if it did, you uploaded it to the production web server, and the new rule simply worked.

If you have a dedicated server running and calculating all of these things all of the time, when you want to update it you have to STOP it from running, replace it, then start it up again. Naturally there will be a tendency to have a lot of state that the server works with, which will need to be saved off when shutting down and reloaded when it starts up.

Even if your dedicated server is relatively stateless, you still have down-time. In your "update a php and go" method, the game is only "down" for as long as it takes to upload the php files.

Which means that naturally you will want to be more deliberate, strategic, and careful about updates when you switch to a continuously running server.

Also, I don't see in your question anything to make me think that anything is happening "in real time" and if nothing is in real-time then a real-time always running server is sort of overkill.

It sounds more like you need to take a good look at your code and do a (probably painful) refactor of it in order to streamline how it works.

Good luck.