Hamster Chase Online Part 1: Server-Side blog - Gamieon

Hamster Chase is a mobile puzzle game where you guide hamsters around a maze of interactive obstacles (which I'll just refer to as "puzzles" from hereon) to get them to their seeds. In the Hamster Chase 1.1 update, I intend to have players be able to create their own puzzles, submit them online; and let every player be able to download and play them.

Here are the core requirements:
 

1. A storage mechanism for puzzles and their thumbnail previews
2. A web server that provides a public-facing interface to the storage mechanism

Here are requirements for an ideal implementation:
 

1. The storage mechanism needs to process queries as quickly as possible
2. The web server needs to process player requests as quickly as possible
3. The data payloads being transferred between players and the server should be as small as possible
4. The web server should validate the inputs from the players and minimize the potential for bad data going into the storage mechanism
5. The storage server should have regular backups that are tested
6. All server-side user entities should only have the permissions required to perform their tasks
7. There must be a master on/off switch that will make the web server immediately reject all requests in a time of crisis

How I'm satisfying the core requirements:

1. The easiest decision to make was that I would not host anything from home. For both puzzle and thumbnail storage, I chose to go with a MySQL server hosted by an outside vendor because it can quickly filter on and return puzzle content, because I'm familiar with how to use it, and because the vendor I use for web hosting already had one set up. 

2. I would also rely on the vendor to deal with the data hosting, web hosting and all the logistics thereof. I would write PHP scripts to put on the web server that allow players to submit and download puzzles from the database.

How I'm trying to satisfy the ideal implementation requirements:

1. A typical puzzle is between one and three kilobytes of text when uncompressed (and I could probably cut that down in half with some formatting changes; but that's a topic for another day), and a preview thumbnail is also three kilobytes on average. Between the size requirements, a properly indexed data structure and the use of stored procedures in MySQL, I expect fast processing from the storage server.

2. The PHP scripts are lightweight; all they do is validate the inputs, query the data server and give results back to the player. There are no processor-intensive operations going on that I expect would cause a bottleneck.

3. When someone uploads a big puzzle, at most they're sending a roughly 6 KB (3K puzzle not counting any compression + 3K thumbnail) payload to the server. I don't think uploads will take place more than a few dozen times per day after some time passes since the release.
 Downloading, on the other hand, can get a little bit more messy. Suppose a player wants to see the first page of puzzles on the server. A page consists of eight puzzles...so that can be (3 KB Data + 3 KB Thumbnail) * 8 puzzles per page = 48 KB being sent to the player. No problem...but this player is discerning and they may just want to flip through pages of thumbnails to find puzzle they like; so they request a new page every three seconds. That means the server needs to be able to send 48 KB to the client every 3 seconds. No problem! Now lets say you have 1,000 discerning players who want to do the same thing at the same time. That means the server should be able to send out (48 KB * 1000) = 48000 KB ~= 46 MB every three seconds. A good server can handle that and throttle incoming requests as necessary. I don't think the game is so popular as to have this happen in the near future, but still it's something that needs to be thought about.
 There's also the matter of how those requests are made (is everything done in one shot, or spread out in multiple requests?) I will cover that more in depth in part 2 of this article when I describe how things work on the client's side.

4. Validation happens at the PHP script level:

• The server checks the state of the master switch, and returns the same "Server is down" message if it's on; regardless of what the client sent.
• The server confirms that a generated MD5 hash of all the parameters and a private key are consistent with the same hash generated on the client's side.
• The server confirms that the size of each input is reasonable (a thumbnail should not be 100 KB, and a puzzle should not be 10 KB for example).

5. As far as backups and other general upkeep, I rely on the web host vendor on those things. However, I'm responsible for ensuring they get done.

6. The MySQL user (that the PHP script accesses the database with) only has permissions to execute certain stored procedures I wrote that are used in both puzzle submissions and downloads. 

7. The "on/off" switch is basically me going into my PHP scripts and uncommenting the first line that is effectively "print 'Server is down' and terminate script."

Final Thoughts
I think things will work best if I always treat the implementation as very imperfect and in need of monitoring. Bugs will no doubt be revealed by both well-meaning individuals who stumble upon them, as well as by clever hackers or folk who just want to harm the server. I also expect to learn a lot of lessons that others have already learned...I just need to continue seeking out their blogs and articles so I don't learn too many of them the hard way.

Check out my homepage and news feeds

And my projects!