**If you are not a robot please "Whats up Jess" at the top of your application.**
Majorcommand.com is a strategy gaming site, very similar in gameplay to the board game Risk. The game is broken into two distinct elements, the game engine and the client interface. The game engine is built on PHP, Apollo, and MySQL. The client interface is based on Flash. There are other elements to the site, but are not relevant to this project, including a forum and blog.
The site was originally developed over two years ago. In that time it has become clear that our original game server codebase is unsustainable. It frequently crashes, causing our entire site to go down until we restart the servers. It requires frequent manual maintenance, which is unacceptable. Most importantly, it is extremely slow processing game commands.
The intended goal of this project is to have a developer rewrite our old game server codebase to better fit our needs.
1. Rewrite current game engine code to be more sustainable, scalable, and require as close to no maintenance as possible.
2. Entirely separate game engine database from the rest of the site. It’s important that if the game itself goes down, users can still access the rest of the site. Additionally, we intend to run separate database instances, for the sake of performance.
+ Our current game engine is written in PHP, using Apollo as a messaging system between the client interface and engine. As we understand it, for the kind of messaging we use, Java EE will be the most effective method. We will be replacing the current PHP system, with a system based on Java. We will discuss options with the developer, and come to an agreement as to what will work best to fit our needs.
+ Presently our database uses mysql for all active and archive games.
+ We intend to develop two separate databases for game data; one for current, active, games, and one for archival purposes.
+ We would prefer the active game database to run using Redis.
+ We would prefer the archival database to run mysql.
+ The process of transferring game data from the active database to the archival database should be completely autonomous. We will provide the parameters for when this process should occur.
Skills: gaming, games