Dev Blog #7 - Backend Milestones and Server Auto Scaling

It’s been a wild past couple months since our last status update!  But we’re happy to report that some big hurdles have been successfully jumped, long-term milestones have been reached, and in-engine work for the game is full steam ahead. In a sense, this blog serves as the bow being tied over our sparkling new backend structure that started its life more than a year ago, and is now ready to be put to work in-game!

Other than the events surrounding Metrocon, we haven’t been vlogging as much this past year since it can be tricky to visually document all the technical / back-end progress that has been made. But since server auto scaling was the final cherry on top, and has some nice visual elements, we thought what better time to celebrate with a vlog! Check it out below if you haven’t already:

(A lot has happened even since filming this a few weeks back but we’ll save that for the next update!)

And of course there were the many steps and milestones that came before auto-scaling, which would be best explained by the engineer himself below!

Development update from Andrew (Engineering and Design):

The last year of development has been quite a journey for us. We’ve had our fair share of missteps, successes, plans that didn’t follow through, and plans that did. At this point, more than a year has passed since our Kickstarter, which was funded in May 2017, and after many major milestones which I’ll dig into below, I feel legitimate to say: “the future looks bright”.

Taking Super Plexis cross-platform and cross-play

Transforming a game to become cross-platform and support cross-play is no easy task, especially with Super Plexis because the gameplay is real-time and deterministic. Most AAA game companies don’t rush to cross-play because it takes away from the time that could be spent developing new releases, so we had a hunch that this reforging process was going to take an immense amount of time.

The distance we have traveled

We’ve made serious progress on the backend technology to support Super Plexis and any other games we develop, and we are not using any 3rd parties except for AWS. Keep in mind this is the infrastructure that governs account servers, matchmaking servers, spawning game servers, storing user data, and responding to game clients like Super Plexis. The final piece of the puzzle was to make the server infrastructure capable of scaling itself up or down according to incoming traffic. As seen in our vlog, this has been implemented for some time now, and it supports the traffic on our website as well as the development version of Super Plexis.

Milestones Timeline (extremely simplified)

May - June 2017: Learning the tools used for developing server software

  • Quickly learned JavaScript (NodeJS ES6), HTML, and CSS for web & server development.

  • Researched and tested AWS for hosting servers and learned to administrate MySQL databases.

  • Wrote 40 pages of development planning and notes on everything I’d learned up to this point.

July 2017: Hurricane Irma

  • Survived the eye like a boss (Gabe, Emily, and I were all living in Naples, FL during that!)

August - September 2017: Server self-help tools and creating an email service

  • Created server self-help tools like automatic restart (if the software crashes), live error reporting via email, defending attacks like DDoS and Slow Loris

  • Created communication systems for Servers -> DB

  • Created a reliable email service that allows us to send 1.5 million emails every month without losing reputation with ISPs

  • Learned about SSL and implemented secure communication between client / server

October 2017 - December 2017: Staging for Medley ID and the Website

  • We started testing the website featuring Medley ID as a proof of concept that the account servers were working as intended.

  • Tested Medley ID account system on the cross platform game client which had only just begun development

January 2018: Launched Medley ID and developed account preferences

  • Officially launched Medley ID on the website

  • Account preferences followed shortly after the launch allowing players to modify their username, contact email, password, etc.

February 2018: Learned how to incorporate the company

  • Medley was originally an LLC formed in Florida, and we wanted to incorporate for security and to attain a legitimate (and flexible) business structure

  • Researched the legal requirements for becoming incorporating and how to make that transition while avoiding potential pitfalls.

  • Continued progress on Medley Account Services so that we could start integrating Super Plexis data with Medley ID

March 2018: Incorporated Medley and started to work towards an alpha build of SP

  • We officially incorporated the company in early March (no longer an LLC)

  • Underwent a domain change and name change to reduce confusion: “Medley Studio,” VS “Medley Studios,” - this took more work than we had originally hoped (haha!)

  • Began work towards an official alpha build of SP using the HaxeFlixel engine (built on top of OpenFL)

April 2018: Released first cross-platform alpha build of SP

  • Released a very basic build of the game on Android, PC, and Mac; with only a single “Endless” mode playable.

  • Extremely basic integration of Medley Account Services due to server-side limitations (turns out there was no way for players to modify their SP account data due to these limitations, so this called for a server-software revisement before we could resume work on SP)

May 2018: server-side revisions begin and a new SP build releases

  • Researched and found that I could create better account services if the code was more manageable.

  • Wrote up a plan to convert the codebase to use Promises for asynchronous runtime and Knex.js for secure & dynamic (partially player-defined) MySQL database queries. This was key to fixing the problems we found in April 2018.

  • Released a new build for SP that showcased a new type of cursor, fixed all kinds of gameplay bugs, and added block animations.

June 2018: Integrated Promises and Knex.js, split up development environments in Git

One of the many perks of implementing  Promises  &  Knex.js

One of the many perks of implementing Promises & Knex.js

  • Used Git to split up the development environments so that we could store separate configurations for development, staging, and production. This prevented anyone from pushing development code to production (safety) and simplified all devops.

  • Refined >10,000 lines of code in the server backend to use Promises for asynchronous runtime and Knex.js for more flexible DB queries (this is what allowed me to create an environment where SP data can be managed by the player - VERY excited to show this working when we release the next build of SP)

  • Stopped using stored procedures in MySQL to prevent human error and opted to parallel these in JS using Knex.js

July 2018: Switched from HaxeFlixel to LibGDX and set up server auto scaling

  • We liked HaxeFlixel, but we needed some tech that didn't exist just yet in the Flixel engine (message me in Discord if you want more info on this), so we moved to LibGDX. We are still in the process of making this move, but we are nearly back to where we left off in May.

  • Creates Boss Server which communicated with AWS Auto Scaling to deploy server software to newly spawned servers in EC2.

  • Creating Boss Sever required us to create a staging environment in AWS, so we got that up and running with a staging DB and staging EC2 environment, as well as SNS/SQS.

August 2018: Pushed auto-scaling into production and continued work on SP

  • Auto-scaling is working in production. If you’re viewing the website, you are experiencing content supported by account servers which were scaled without me pushing a button. And yes, they respond properly to software updates (we are currently on Account Server 1.7.1 in production).

  • Super Plexis development continues in a race to catch up to where we left off in May. Currently we are working hard on UI so that we can focus on gameplay. Account systems are fully implemented for the LibGDX version of SP in our own standalone library so that we can use these account systems in any game we create.

Although we have encountered our fair share of complications over the last year, you can see how we’ve ended up in a very optimal situation. We’re proud of the tech backing Super Plexis because it is strong and versatile, but at the same time we want to bring you Super Plexis as soon as possible. We’re finally able to build off of what we have without looking back, and we’re excited to bring you more frequent playable updates for Super Plexis in the coming weeks. Thanks for sticking with us. We know this has required more patience than it probably should have. We are dedicated to this and we believe Super Plexis deserves a sustainable future. Thank you to everyone who also believes in that future.

- Andrew


Big thanks to Andrew for the detailed breakdown! The timeline above perfectly captures one of the biggest challenges of having a small development team, where often 1 or 2 people are carrying a workload fit for 4 or 5 (and that’s not even including work done on the side for extra income). But we believe in the long run it will all have been a worthy investment. Having a solid foundation that is future-proofed and can run on its own (with things like auto-scaling) allows us to pour more time and resources into actual game development while also juggling our personal and work lives.

Mainly we’re just excited to have crossed this threshold and can’t wait to share more of the game itself soon! We’re still pushing to have an Android build out by November, so keep an eye out for updates as the time approaches.

Thanks again to everyone following along in our journey so far. Both your patience and excitement is very much appreciated by the team! And probably safe to say that we can match your level of eagerness personally as we get closer and closer to the next playable build…