Gamieon is a privately owned entertainment software development company located in Tampa, Florida. Since October of 2004, we have aimed to provide quality video game software which emphasizes both intellectual and action-driven challenge to the gaming community. Gamieon depends on the talent of individuals working as a team to develop video games and video game engines with a focus on exceptional game play and surrealism.
Posted by Gamieon on Feb 20th, 2013
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:
Here are requirements for an ideal implementation:
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:
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."
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.