I have one month to make an MMO: Intro
I am moving jobs, and have taken a month of time off between work to do some soul searching…by which I mean make an MMO.
Why.
When I (re)started game dev as a hobby almost two years ago, I frequently saw newcomers to the GameMaker discord (where I spend too much time) asking about how they should go about making their next Undertale MMO fangame, usually to be told that they shouldn’t.
Every time someone says you shouldn’t do something because it’s hard, or impossible, something is kindled inside me. Call it a penchant for taking on complex projects, or a desire to prove myself, or just flat out reckless optimism for what can be done, but it suddenly made total sense to me that I should at some point make an MMO.
I had some history in the area too, I learned programming by doing gamedev, working on multiplayer PHP games; some of my past jobs involved networking; and recently I’ve built a couple of bare-bones “MMO”s for 48 hour game jams to prove out a few networking and server-side concepts.
I think my body is ready.
I’m blogging this partly to help keep my own thoughts in order, but also to help give others some insight into life as an indie, and some of the technical aspects to building MMOs. So please follow me on this 1-month journey to build…something…maybe
How I’ll be doing it
To keep my management skills sharp, I’ll be structuring the project like the usual projects I manage. Sticking with short sprints (unusually short, since I’m working alone, and working at home, I don’t have to stick to weekdays) of just 4 days. This gives me about 6 sprints, here’s an outline at this point, but this’ll likely be updated as we go and discover more about the scope.
The Game and goals
The project’s code-name is FCF. I hope it’ll be an MMO that focuses on collecting things, and arena combat. I have certain ideas about the gameplay and mechanics, but MMOs are by their nature huge, and since the only scoping I am familiar with is “over”, I am sure that most of the month will be dealing with the technical aspects of the game.
My goal is therefore to simply get as far as possible on the tech, rapidly iterating to make sure the game is at least playable for as much of its development life as possible, and leave the fun and the unique for future me to deal with. I’ll focus less on game mechanics and more on technical implementation.
The Tech Stack
- GameMaker for the game client
- Python for the main game servers, using either Twisted or Tornado (my previous bare-bones MMOs use Twisted, but I’m leaning towards Tornado)
- Javascript for some frontend and ancillary HTTP stuff (will explain why later)
- Redis for the real-time message bus
- Google Firebase for user accounts and persistent storage
Add to this a few tools like Tiled for map building; and Docker for deployment.
GameMaker as the game engine? Why not Unity?
This’ll annoy some people for sure. People are passionate about their chosen game engine.
Of the two engines, I know GameMaker the best, and from everything I have done before; the challenges to making an MMO is more than just the challenges of making the game client. I don’t believe GameMaker to be a bottleneck in this project. It’s as simple as that.
Why Python? Why Javascript?
If there’s something I’ve learned about programmers on the internet is that there’s always someone who’s going to tell you your choices are wrong. But here’s my explanation anyway:
Javascript is ideal for handling event-driven tasks, there’s a lot of stack designed for this purpose. I happen to also have reasonable set of existing work to draw on that I can pull into the project, so no question about using Javascript for the ancillary tasks.
Python on the other hand, despite being slower at synthetic benchmarks, has more options for scale and complexity for the kind of workload I want from the server backend, plus slightly fewer dependency management issues (though by no means immune from them). I’ve heard the argument that Javascript is better for large-scale projects, but I highly suspect the person saying this has been mislead. It’s worth mentioning that EVE Online, perhaps the largest single-realm MMO is built on a version of Python good for threading.
Redis is a mature in-memory data store, with pub-sub capability, and sharding. This is ideal for persisting the state of the world in a database that can respond extremely quickly as well as act as a message bus. My previous experiments using Redis for an MMO backend have been successful, so I am motivated to continue using it. Another option would be zMQ, though this would need additional nodes to handle data storage duties.
Google Firebase may be a controversial choice. Since Redis is in-memory, all data is lost when the cluster is restarted, I need some kind of persistent data storage to ensure user data like accounts and inventories are safely stored. I pick Firebase because it’s quick and easy to use, and I happen to have existing code for it. Though I readily acknowledge that other serverless database offerings, as well as existing noSQL databases would work as well.
Ultimately, I think the above choice will use each language/framework for tasks to each of their strength, while leaning slightly towards the ease-of-development side of things.
