I have one month to make an MMO: Sprint 2
Having finished core network/backend infrastructure, Sprint 2 will be about movement and maps, and getting that data to and from the server. Hopefully with solid foundations laid in the last 4 days of dry web and backend development, we can start building some of these core movement and gameplay of the game. A summary of the time and where it was spent. Apparently I’ve spent 7 hours blogging. That’s quite a lot.
I’m also going to take a day off today between sprints to recover a bit, and do some planning, and write this blog post, meaning actual Day 5 will start tomorrow.
Sprint 1 Retrospective + my thoughts on “crunch”
As far as timings went, Sprint 1 was slightly over-subscribed, as could probably have been predicted having 11 points for a 8-point sprint, leading to a slight crunch at the end of the sprint. I could have chosen to let it slip slightly, but since I had the time and energy, and since I was the one making plans for myself, I felt it was worthwhile to push to complete the sprint and clear my mind ready for the next one.
Had this been a larger project with more people involved, and were I the one making the plans, I would have had to consider very carefully whether to leave off the pressure and take a “code will take however long it takes” attitude, or apply pressure and hold people accountable to their estimates.
This kind of project management is always a tricky balance. The former attitude is great for a low-stress work environment, but breeds complacency and a lack of pressure can lead to poor prioritisation. On the other hand, the latter attitude prioritises delivery at the expense of stress, energy, and health.
The fact is, you cannot easily predict how projects will take, and projects will always evolve and become more defined as you do them. The plans made at the beginning of the project were made at a point when the project was least understood, so what’s the sense in sticking 100% to the set of plans made with the least understanding of the project? It’s almost always better to continuously re-evaluate and re-scope the project, to make sure that the end date and result is still achievable, and to make sure any changes in scope and challenges that have occurred that weren’t in the original plan have been accounted for. Usually this means either adjusting the delivery date as there is now more complexity than originally planned; or it means adjusting the scope so that the project can be delivered on the date expected. Doing neither is setting up the project for failure — overscoping, and providing too little time.
There’s often stories of “crunch time” in the games industry with employees being overworked for extended periods of time in order to hit deadlines. I believe the root causes of this are poor management in setting goals and reacting to changes, and inadequate communication or action to re-scoping, and revise estimates and plans on the part of middle and upper management.
A common problem I’ve seen is this sequence of events (though there are other ways it can happen too):
- Developers encounter unforseen challenges. This happen quite often, we’re not omnipotent, and it’s not necessarily a sign of incompetence. This leads to missing achieving short term goals. This is also not in itself a problem, it should have been obvious to anyone that plans don’t always go 100% perfectly and as predicted, managers aren’t omnipotent either. Alternatively, the goals could have been badly set in the first place.
- Managers see that something’s slipped, and this is usually where the first error occurs: they either just think “oh we’ll make up for it later” which is probably unrealistically optimistic; or they fail to grasp that this delay has downstream impact on delivery, and fail to communicate this with upper management. Perhaps they desire for their team to “look good” rather than approach upper management to highlight a concern.
- Upper management aren’t aware of plans slipping and still assume the original delivery date is attainable. They continue to make company strategic moves according to the original delivery date, whether it’s financial planning to make sure the company has enough money to pay its employees, or marketing, to publicise the launch of the game and schedule attendance at events. The less upper management are aware of, or act to mitigate delays (either by re-planning or changing scope), the more problematic it’ll be. This is usually where the second error happens: upper management should have had a finger on the pule of the project, not just by getting feedback from middle management, but also through having set measurable goals and metrics by which progress could be objectively checked. There’s various concepts here like OKRs, KPIs, and SMART goals, but ultimately they’re all about the common sense idea that progress should be measurable in some way. Alternatively of course, it’s also possible for upper management to simply have shown particular callousness to the rest of the company by just not acting upon concerns about delivery dates brought to them.
- Whichever mode of failure has occurred, it leads up to delays compounding until it becomes clear to all that the delivery date is not achievable. At this point, the third error occurs: upper management decides not to change the delivery date or scope to one that is realistically achievable. This might be in order to save face for themselves or the company, or they may have particular disregard for the well-being of employees. So instead they apply pressure on middle managers to somehow deliver on time, and middle managers have no recourse left but to increase work hours for developers. This is “crunch time”.
So through a series of failures of management, it’s the developers who are left with having to do overtime. While you could argue that poor work performance and poor communication on the part of developers could also have been a root cause; it is ultimately still a management failure to not have identified and mitigated those risks, whether through training and coaching, or through ensuring employees have the support and resources they need to get the job done (or, in the worst case firing toxic employees that are a drain on others and the company if they aren’t able to improve).
What should have happened instead is that every level of management is on the same page about the realistic prospects of the project; and the delivery and scope re-evaluated on a regular basis to make sure they still match up, changing scope, increasing resources, or delaying delivery if they don’t.
But then again, it’s easy for me to say these things, and hard to do in practice. I’ve personally been the cause or culprit to the failings above, and I’ve also been on the receiving end. There were other times that there was a different cause altogether (malice and office politics for example). So I don’t for a moment claim to have any kind of moral high ground to all this, nor a spotless record. But I do want to encourage everyone: developers, and managers at all levels, to be radically honest to others and themselves about delivery prospects, to communicate, and to set measurable goals because communication is fallible.
Sprint 2 Plan + Tech
Sprint 2 is going to be slightly awkward as I’m going on vacation next week, meaning Sprint 2 may end up up being split into two days of this weekend, plus two more day when I’m back from vacation.
The plan for this sprint is is to building the movement and maps of the sprint. The end-goal is to be able to move around the world (or a small part of it that I will build anyway), and to see other players move around too.
Because we’re actually making what is ultimately a 2D game (and I just realize I never explained this at the start, it was kind of assumed because we’re using GameMaker), the map will be tile-based to ease its creation (don’t need to deal with 3D modelling). I’m hoping to get somewhat of a Stardew Valley vibe going, but a touch darker.
I have a few of requirements for what we can achieve:
- The server does movement validation, to make sure the player doesn’t hack they way around the map
- Each location can be very large but not drastically impact performance of either server or client
- Multiple locations are supported (e.g. different zones, and buildings)
There are an interesting consequences of these requirements: Due to server-side movement validation, there needs to be a way for the server to have a copy of the map. So the map can’t wholly be client-side. This presents an interesting challenge as we must now maintain the map in a way that allows it to be used by two different languages. GameMaker has quite a good room editor, allowing maps to be built, but we can’t use that as there aren’t many tools to export that map to the server.
Instead, I suspect the best option here is to serve the map data from the server only, so that no map information is stored in the client, it’s all loaded from the server at runtime. This also has the side-beneft of not needing to update the client to do content updates, since the data comes from the server. This is much easier in a 2D game where the tile data is relatively compact compared with a 3D game with more complex meshes and textures.
While this sounds like a daunting prospect, fortunately I have some prior work in this area in the form of my GMTiled2 extension, a tool that loads tile maps made in the software Tiled into GM at runtime. I can use this, but with modifications to load maps from a server rather than a Tiled TMX file
The second requirement of having large locations points towards the use of chunk loading rather than loading the entire map at once. From earlier playing around with Tiled, when you turn on the “infinite map” option, the Tiled save format will save in chunks, so this may be an easy way to design locations and export the data in chunks that the server can read.
With chunk loading, the map is split into smaller “chunks” that are a few to a few tens of tiles big. The game only loads up a number of tiles around the player, and doesn’t bother loading the rest, meaning the map can be effectively infinite, but the client only has to deal with whatevers immediately around the player. Other players, NPCs, and entities can also be chunk-loaded, so that if those entities are in the chunks near the client, then the client gets updates about them. If the entities move away from the player, they simply get unloaded from the client, and the server stops sending updates about these entities until they come back. This saves bandwidth and processing time by ignoring things too far away from the player to be seen or to even impact the player.
The final requirement of having multiple locations simply means there needs to be a way to link different distinct maps with doors. This should be a relatively simple requirement to fulfil.
So the current sprint looks like this:
The total number of points is 10, which is one less than Sprint 1. But I will note right now the significant chance of there being unforeseen complexities in this sprint, as there’s a lot of functionality to build. Fortunately since I’m on vacation, which will give me ample time to do some thinking and further planning in my head even if I don’t touch a computer during that time.
I’ll take the rest of the day off to think and relax before diving straight into what should be a fairly technically interesting piece of work tomorrow. See you then!
