Project management tidbits
In this article, I want to take a step back from the details of game design and instead look at the bigger picture of our games as projects. And where there are projects, there’s project management. This is an article that is very likely to be updated multiple times in the future, mostly because these insights come around a bit more slowly than things like specific mechanical details, but ultimately are applicable in a general sense, independent of the project in question.
So, consider this article a bit of a one-stop shop for handy project management tips and insights that you may find useful when working on games.
Forking
Forking is a term borrowed from software development, but the meaning can be applied to any project regardless of the domain. What it basically amounts to is creating a copy—a fork—of a project, and then working on the fork as a separate project. Most forks in software happen when a developer wants to create their own version of some project, and then instead of changing the original one (which they probably don’t even have access to), they start to work on a copy, and add/change features from there. Often, forks can end up being even more popular than the original project!
The key to forking, in both software and in general game design, lies in its non-destructive nature. Since you’re creating a 1:1 copy of something before modifying the copy alone, the original is left completely untouched regardless of the extent of changes done to any of the forks. More specifically, forking can allow you to figure out the wild ‘what if’ ideas without really having to commit to any major rule or content changes in order to do so, which you would then have to revert if the fork doesn’t really work out. Instead, if you choose not to go through with the fork, you just scrap it.
While forking is a rather obvious approach, I feel like it’s one of those concepts that’s more obvious in hindsight. A lot of new designers might not even consider the option to ‘pause’ the mainline version of the design and/or branch off from their current state and try large-scale changes that way. Treat the ruleset as you would any computer file or piece of paper, and copy it, more often than not quite literally.
As an example, for my card game, Confluence: A Digital Odyssey, I made a fork to try and see what an absolutely core-level change would be like. Confluence is a game where the players get a random set of objectives each match, and then draft decks to best play around that objective. However, I wanted to see if the current system could be adapted to fit a more traditional constructed* deck format. The simplest way to do this in a non-destructive way was to create a fork, since this would have to be a ground-up change and would end up uprooting most of the established systems. I called the fork Confluence: XOR Edition in order to be able to refer to it in a way that was simpler than ‘the fork’ or ‘the constructed version’. With XOR, I took all the content from the latest version of the game as-is, and tried adapting it to fit the new gameplay model, hacking, slashing, and reinventing wherever I saw fit. Ultimately, this version of the game didn’t really work out, aside from providing a bit of insight into the existing systems, but the key takeaway was that the original version was completely unaffected, and resuming work on it was completely painless.
* For those less familiar with card games, a ‘constructed’ format is one where players build and/or tune their decks before they play the game, with very little to no changes allowed to the decks afterwards. This is the default model for most ‘duel’-style card games, i.e. most TCGs.
Forks are a very simple way to try larger-scale changes to your in-progress projects without fear of messing something up and/or losing progress. The best part of designing/developing a fork is that since each version is completely independent, they can be worked on at the same time. Of course, this works best if different people handle the different versions, so that work can truly be done in parallel, but even just splitting up your time between the versions will let you have continuous progress in each. Sometimes forks end up as nothing more than an exploration of a weird idea, but other times they might evolve into complete projects of their own. Don’t believe me? Maybe you’ll believe Linux.
Burnout and pacing
Burnout is terrible. Burnout is also unavoidable… at least once.
All of us have been there. Not necessarily with game design, but with anything you have to put some effort in, whether it’s at work, a creative hobby, or even physical activities. Burnout is everywhere, always lurking around the corner. You’re gonna get burnt out at least once, because that first time you won’t be aware of your limit. After that, armed with newfound knowledge, you can try doing things that mitigate, prevent, or monitor burnout, so you can handle it better in the future. Keep in mind that you’re never really immune to burnout, unless you actively take measures against it.
When it comes to working on games, burnout can hit really hard. During periods where one has a lot of ideas—especially when starting a new project—it’s easy to quickly reach the limits of your creative capability (or just general willpower) by trying to do as much work as possible as fast as possible.
There seem to be two main approaches to how people handle burnout: taking a break and waiting it out; or trying to power through it. The latter can work a lot better in the cases where a game is in the development stage, i.e. the design is more-or-less done and the game’s balance is currently being tuned. Dev work is a lot more manageable in general compared to design: most of the creative heavy lifting is already done, so the rest can often boil down to just grunt work. It’s easier to get through burnout when the most you have to do is tweak existing parameters and playtest things, at least compared to having to try and create core systems while burnt out.
As far as taking a break from the project goes, it’s about as straightforward as it gets. However, when taking a break, make sure to take a complete break for however long you feel like you need. No compromises, no part-time working on things or ‘just a little tweak to this here won’t hurt’. Things like that will only serve to lengthen the burnout period, and chances are the quality of the work you do while burnt out would be lower than your usual output. In cases like that, you might have to come back later and fix things up, which just opens up new work for no justifiable reason.
The key to managing burnout is pacing. Again, an obvious thing, but the approach to pacing is very important. Say you start a new game project, and you have a lot of ideas that you want to get implemented and tested and balanced… but, after a while, you start to feel burnout slowly creeping in. At the first sign of burnout, my approach is usually to just shelve the game. Not permanently, but for long enough so that you take a proper break from it.
It’s all about pacing. Design a bit, then let the game rest. You’ll find out that this way, you can prevent the burnout from individual projects much more effectively, and you can always change to a different (potentially shelved) project when you step away from the current one. Taking breaks between working on a specific game, especially if those breaks are long enough for you to start forgetting some details, can often give you a fresh perspective on certain aspects of the game, or even the game as a whole.
A note here is that while this type of pacing can mitigate a lot of the burnout associated with any individual project, there’s still the burnout from design in general, which you can manage in a similar way. Having a lot of hobbies helps a fair amount in cases like this.
Here’s a handy recipe for project pacing:
- Have an idea for a new game
- Start working on the game, (ab)using the initial rush of ideas that comes with a blank slate project
- After you feel like there’s enough of the game done to be stable (not necessarily playable, just some consistent-enough portion of the design done), put the game/rulebook/notepad/file on a shelf or in a drawer
- Let the design rest for some arbitrary amount of time, usually until you start forgetting details of it or when you reach step 3 for your latest project
- Get the game/rulebook/notepad/file off the shelf or out of the drawer. Dust it off if needed.
- Read through and/or play through what you made in step 2. After this, if you’re not wondering ‘how did I ever think this was a good idea?’, you may resume working on the project. Otherwise, I recommend putting it back and keeping it around, just in case.
- Have fun (?)
Handling testing backlog
Since games are interactive systems, the only real way to evaluate whether the rules or mechanics make sense and are actually fun is to go and do playtests. Test early and test often. However, sometimes the pace of those playtests will slow down, whether it’s because of other responsibilities, logistics, or just burnout. More often than not, the actual design and dev work tends to keep going even when no testing is being done, and that’s how you get a testing backlog.
There really isn’t anything complicated with how you would get rid of that backlog—you just start testing. But, that’s the thing: with multiple—potentially wildly different—changes in the backlog, you need to try and bring a bit of order back to this inevitable chaos. This is where you start prioritizing. There’s at least a dozen different factors you can prioritize your changes-to-test by, but in my opinion and experience, the most important one is volatility.
Volatility is just a fancy way of saying ‘how many other changes would I have to make to the game if I decide to go through with this change?’ Highly volatile changes are ones that require a cascade of other tweaks to be done in order to be implemented. With this in mind, it’s relatively easy to sort the backlog by volatility, going from highest to lowest, and start testing. If/when you have a new change, you just put it in the correct position in the sort order and continue testing from the top.
Testing high-volatility changes first is important exactly because they’re volatile. If you decide that implementing a big change to the core rules is good for the game after testing it, then chances are most of the lower-volatility changes are going to become moot points, seeing as the game would have been modified a lot by then. Also, you don’t really want to have spent time testing things that are no longer applicable to the game.
If we combine this backlog prioritization with the forking technique mentioned above, we can do things like creating a fork of the game that has the highest-volatility change(s) implemented, and then test all the less volatile changes on the other fork. This way, you can test pretty much every change you had in your backlog, but not necessarily every combination of changes, since you’re technically walling some of them off in a separate version of the game.
The sorting doesn’t have to be even close to perfect, but any kind of categorization helps a lot and makes driving things forward that much easier. Some other fairly important aspects you can prioritize your testing backlog by include, but are not limited to: time (how long a change will take to test), number of required tests (to be able to confidently accept/reject the change), logistics (amount of people/physical resources you would need to test the change) etc.
Well, that about wraps it up for now, at least. Like I mentioned at the start of the article, there’s a lot of stuff that can be talked about regarding project management, and this is strictly from a theorist/hobbyist perspective, seeing I don’t have any experience with more professional game design (not yet). As I get more experience through my own projects, and through talking with other designers about the things they’ve learned, I hope to build up a decent repository of game design knowledge that can help people more easily navigate this weird and wacky endeavour.
Until then, keep on jamming:
This is InvertedVertex, signing off.