I have one month to make an MMO: Sprint 1

This week’s plan: Network infrastructure

It’s Day 1, I’m taking some time out to do some planning, and documenting my planning process. I’ve been a technical manager for a number of years, and I’d like to take the time to share a little bit about the process with those who may not be familiar with Agile workflows.

In Agile, we work in terms of “Sprints”, which is just a term for a period of time over which work is planned. It’s very often 1 week, sometimes 2 weeks. I’m actually going to buck the trend and go with a 4-day sprint since I’m working alone, at home, and can do weekends; I’ll be looking for rapid sprints to force myself to not overscope, and to encourage myself to iterate rapidly.

Sprint planning tools

For task planning, I’ll be falling back to an old favourite of mine: Pivotal Tracker, a free web-based agile project management tool. I prefer it over Trello for personal projects for the following reasons:

• It’s linear. I am a linear thinker, I make lists. I find the 2nd dimension very threatening, “why’s my task over to the right rather than above or below in priority order? oh no! too many directions to deal with”.
• I like task estimation points, it helps me plan and prioritise tasks. I’ll be using 1-point = roughly half-day.
• The github integration is great, but since this is a personal project, I’m unlikely to use it
• Icebox, current-iteration, and backlog are already set up and part of the flow

While Trello has integrations for all of the above, Pivotal Tracker already have the core set of features I want, so it is ideal for me. JIRA is also excellent, but more than I need for a personal project.

Here’s how the current sprint is shaping up:

Hopefully over the next 4 days, according to my current estimation of the tasks, I’ll be able to get the login system completed by day 3.

The Point System

Task estimation like this is a hugely important skill, not only for managing a project, but also managing yourself. Being able to realistically estimate how long it takes you to complete a task helps you be a more efficient team member, and avoids overscoping.

If this were part of a larger team, the project manager would have worked with team members, or perhaps only technical leads if the team is large, to figure out the individual steps needed to achieve weekly or monthly goals. The tasks would be estimated in terms of more like half-days or even whole days, estimating tasks in terms of hours is micromanagement, and isn’t actually helpful other than to create stress — nobody can predict things to that level of detail anyway. A rule of thumb is: round tasks up. Even if you think a task will only take an hour, round up to half a day, or even a whole day anyway, because even if you were right and finished it in one hour, there’ll be another task you thought would only take an hour and ended up taking three days instead, or other distractions like meetings or having to help someone else. I’ve found rounding everything up helps average things in the end and avoid underestimating.

The beauty of the point system for task estimation is this: you start out trying to estimate things in terms of 1 point = 1/2 day, and then you see how many points you’ve managed to actually do by the end of the sprint. That number becomes your “velocity” — how many points you have been able to do per sprint in the past, and helps you manage scope for the next sprint.

The hand-wavy Jedi mind-trick here is that by managing a sprint in terms of an abstract point “velocity” rather than actual time estimates, you (or your team members) can keep estimating tasks in terms of 1 point = 1/2 day, but as long as the sprint is managed in terms of “velocity”, the time estimate is adjusted based on track record. Your estimates might be completely off and have everything take 3 times longer than you thought they would, but after the first sprint of this, as long as you’re consistent with estimation, this would simply be reflected in your “velocity” (you’d only achieve a velocity of 3 points rather than 10 per sprint, for example).

While you slowly improve your task estimation, or while your skills and competencies at the task develop, the task planning is at least a bit more accurate and therefore predictable. Projects succeed when they’re predictable — it means inefficiencies can be addressed, scope or manpower adjusted, expectations and release dates revised early. Projects fail when they’re unpredictable — release dates slip, future plans are uncertain, problems are only addressed when it’s already too late.

How well I do on this task estimation task we’ll find out in a couple of days.

Look through the scope, not over it. Don’t overscope. Photo by Specna Arms on Unsplash

Those of you who are eagle-eyed will see that I actually have 10 points assigned for this sprint of 4 days (which should be 8 points). I’m allowing a slight over-assignment here so I can find my velocity. In general, it’s not a big deal to be over-subscribed, it just means there is a risk of not reaching the goals by the end of the sprint, which is fine, as long as those expectations are managed/communicated.

Sprint 1 Plan + Tech

The plan for this sprint is to get the backend built out, allowing user registration, game clients to connect, and the backend database needed to hold the world state.

I would normally highly discourage starting with user logins before even creating a game. I’d recommend making and prototype the core game first, but in this case, I’ve recently made a MMO that I’m happy with using as the base of the project going forward so I’d like to claim that I’ve technically already got a prototype and know where to hook in the login code.

I’ll be actually building a website first for handling user registrations, because I really don’t want to start off making a registration form in GameMaker. UI is not one of its strengths. I can get a user database and authentication working much faster with a web-based frontend than with a game client, and this way I can avoid getting into a situation where there’s too many new pieces coming together at once. I’ll be putting my web-development skills to good use here.

Approximate backend topology of the FCF project

Once that’s done, I’ll fill out the server backend a little. So approximately, the tech used will be:

• Vue.js for the web frontend. I’m familiar with Vue.js, it’s a quick way to get a website up and running fast, and that’s what I’m after. As far as I’m concerned, Vue, React, and Angular are currently the go-to technologies for building websites.
• Firebase Auth for user authentication. Using an Authentication provider cuts out having to re-invent the wheel in terms of databases, storage, passwords, etc. I pick Firebase for this as I have existing code, and though lacking in features, Firebase is enough for what I need. Otherwise I would have gone with an AWS service like AWS Cognito.
• Python Tornado for the server backend. Tornado is an excellent web framework that support async, I could have also chosen Python Twisted which is what my previous MMO work has been in, but I’ve decided to go with Tornado for this one.
• Redis for the state storage. An in-memory datastore, perfect for low-latency and distributed access to the world state. I could have also picked zMQ or another message queue/in-memory datastore for this.
• JSON-RPC as the response-request communications protocol. Other RPC protocols would have been appropriate, but since GameMaker can handle json reasonably well, it’s easier to implement JSON-RPC. A future optimisation involves stripping out JSON-RPC for a lighter weight binary protocol, but I’ve already proven with past work that JSON-RPC doesn’t present any significant performance bottlenecks, and is much faster to get going than defining binary protocols.

Let’s go! It’s 1:45pm and I’ve not written a single line of code. This is fine.