Striking A Balance: The Devtober Postmortem


This was my first Devtober. It was interesting, though I think I approached it differently than most participants.

I’ve written postmortems before, but this is a bit of a weird one for me. Usually I do it after the project is complete, sometimes after the judging period of a jam (if it’s a jam game). This time, I’m doing it halfway through, while the game is still in development. Usually I focus on mechanics and design with a side order of technical challenges. This time, I’m focusing on development processes and approach.

My overall goal for Devtober wasn’t to spend more time on or get better at building games, but to get better at balancing game dev with everything else in my life. That meant using time more efficiently, reducing stress levels from the project, and in some cases, cutting scope and just doing less.

Game dev is a hobby for me that doesn’t bring in any dough, I have a completely different full-time job for that. Lately game dev has been taking over more and more of my life, giving me more stress and less time for leisure. I wanted to reverse this trend, but I also still wanted to hit my intended deadline for this particular project.

Before we dive in, a little disclaimer

I’m going to talk about my experiences and what worked for me, but none of this is universal, it’s not industry best practice, and it may not even be good advice. This isn’t a guide and it’s not meant to be copied. It’s more of a rambling on where I’m coming from, what I’ve tried, and why I think it worked or didn’t work. If you can gain something useful from it, great! If not, I hope you were at least entertained.

A primer: what is Takagi?

Note: Until about a day before this was written, The Crystal Tower was known only by its codename Project Takagi.

Project Takagi is a Christmas special in the Outliers and Outsiders series, set about a year after At The Break Of Dawn. For those who aren’t familiar with the series, I started it for Magical Girl Game Jam 2, it’s actually all first-person shooters with some elements of other genres, and there’s quite a story to how it happened. You can read some of that on the game pages, but it’s beyond the scope of this devlog.

The last Christmas game I made was made for Christmas 2016 and was never publicly released. I’ve really wanted to do another Christmas special for a long time now, but I’ve always either been too busy, had no ideas for it, or both. Finally, this time around, the stars aligned. I had a solid idea of what I wanted to do and I had time to do it (though I did have to bump Shattered 2 to 2022).

In terms of scope, Takagi is a bit bigger than I really wanted it to be. But it’s a ripoff of whole plot reference to a favourite Christmas movie of mine (not going to say which one, though if you know your movies it’s pretty obvious by the name alone) and there was only so much I could cut while still keeping it coherent. I didn’t want to do something huge for a Christmas special- it’s just a special little thing to bring out for the holidays, not a massive title to eclipse all others. My plan is to slowly add more to it every year, possibly bringing in stuff from other projects as those develop.

At the beginning of Devtober, Takagi was around maybe 50-60 percent complete. It’s now more like 80-90, though I’m very aware of the ninety-ten rule.

Working a little bit at a time

Some people are very good at using small bits of time, getting one little bit done here and there. I am not one of those people. I tend to not work on stuff unless I have a big chunk of time I can devote to it all at once.

There are several reasons for this. Part of it is technical. It just takes time to open the editors, open the folders, open the project and navigate to where one needs to be. A fixed cost in time no matter how long the work session is. But a lot of it is mental. It takes time to get going; to remember where you left off, get in the right headspace, get the rhythm down and get into the flow state. And then you might be forcibly ejected from it just as you get started, because the time is up, and that sucks.

Unfortunately, if your life is even remotely busy, it’s hard to get those big chunks of time. I may have, for instance (this is just a random number for the sake of illustration), five hours a week to work on games. But it’s not one contiguous five hour block, it’s ten minutes here and thirty minutes there and an hour elsewhere.

For me, these little snippets can’t replace the big chunks, but they can supplement them. What I’ve found works best is to take on one small, simple task that is well defined and ideally can easily be paused. For example, adding a sound effect, writing a section of dialogue, or drawing a character portrait. Many of these also have the advantage of not requiring my full dev environment to be up, just Photoshop or VS Code. Then, if I have time, I’ll pick another. The harder problems I’ll save for when I have more time, though I’ve found that a lot of them can be broken up at least partially into little tasks if I think about it a bit first (for example, doing a scripted sequence or adding a new weapon).

I wrote bits and pieces of this postmortem while waiting for dinner to cook, which isn’t something I would have done in the past. I didn’t get it finished, of course, but I managed to get a few paragraphs down during time which I would normally consider completely wasted.

Just do it!

I tend to waste a lot of time pondering how to do something, or sometimes just despairing of the scope of the work ahead, or sometimes even wondering if I should be working on this or doing something else. Instead of doing something productive, I’ll just sit there and stare at the project as the clock ticks by.

This is, obviously, not ideal.

I’ve found that breaking up and taking on smaller tasks, as I alluded to above, helps with this. It’s easier to get started on something if it’s smaller and clearly defined. I’ve also consciously realized and dismissed that impulse to strive for perfection, to figure out the best possible solution before starting to implement. Instead, I’ll usually roll with the first idea I have that could possibly work- often the simplest idea- and just go with that. Usually what I’m doing isn’t critical even if it’s not done The Best Possible Way (tm), and isn’t too big a deal to rework later if necessary.

Still, resisting the impulse to hem and haw and procrastinate instead of just doing something is difficult for me. I’m better at this now than I used to be, but I still have room for improvement.

Perfection is the enemy of close enough

One of my favourite maxims. Another is do the simplest thing that could possibly work. Once again, I already alluded to this a bit above.

Scope creep is inevitable, but it’s possible to curtail or even reverse the trend by aggressively cutting scope. Target the minimum viable product. Scrap any mechanics that don’t substantially add to the game. Cut down scripted sequences to the bare minimum necessary to get the point across. Reuse audio, music, and graphics wherever possible. Then, iff we have time at the end, we can build up some of the weaker points again, and add in some of the nice-to-haves. If not, oh well, we’re at least good enough.

I don’t think this is necessarily a good attitude for indie devs. I think there is a very real danger in missing the forest for the trees, but I also do acknowledge that I fall too far on the “just get it done, it doesn’t have to be good” side of things which sometimes results in a rough product. I think it’s important to hit a balance, to strive for quality while retaining an understanding of the amount of time and effort that’s reasonable to put into a project.

I can justify it for this particular project, though. It’s a Christmas special, which started off as just a fun little thing for the holidays and it was never supposed to have a scope this big in the first place. It has to hit a specific deadline because it’s tied to that holiday. And, if there’s stuff that I don’t like about the first release, it’s no big deal, because I’m planning to update it every year with a little bit more.

I’d like to do a game where the ratio between time and scope is enough to get the quality high the first time around. I don’t know if I’ll ever have the chance, but it would sure be nice.

Quit while you’re ahead

I have a habit of trying to do one more thing. Some would call it a good habit that increases productivity. I would not. For me it results in overly late nights, missing other things, and plain stress and frustration from taking on extra tasks that were not as simple as they first appeared. It’s rarely ever necessary; either I’m going at a jam pace and this doesn’t apply, or the deadline is far off or flexible enough that it doesn’t matter. This is one of the biggest challenges I have to overcome, and I’ve already screwed up badly here once this month. Still, I’m at least somewhat better at finishing what I set out to do and then closing everything and doing something else than I used to be.

A curse and a blessing: miniature milestones

I use a form of miniature milestones for my projects. At the beginning of a day, week, and/or month (depending on the length and pace of the project) I’ll work out what I want or need to get done, and then try to get it done. I don’t use any fancy tools for this; at most I’ll make a list in OneNote. There’s a lot of guesstimation but I usually have a pretty good idea of what’s reasonable and what’s not.

I tend to push myself to meet my goals for the day, week, or month at the expense of other things, and it feels absolutely awful when I don’t make them, especially if I’ve already pushed things. The thing is that I put way more pressure on myself than there needs to be; I’m usually not trying to make a deadline, and when I am, I usually have enough room to maneuver in either scope or time that missing a target isn’t the end of the world.

In general, I think setting these little goals helps me than it harms me. It helps a lot to go in with a plan, and having goals and targets keeps things on track. But I definitely need to be more flexible about it.

Should you work every day?

It’s the idea of Devtober. I’m not convinced this is a good thing, though I’m not sure if it’s a bad thing either.

Making even a token effort, a tiny bit of almost symbolic progress, can help keep momentum and motivation up on a project. On the other hand, forcing yourself to work on your game when you really don’t want to for one reason or another seems antithetical to the idea that a hobby should be fundamentally enjoyable.

For the record, I did work on my game at least a little bit every day in October.

Focus on the now

One of the reasons I tend to push myself to get more done even when I don’t really need to is because I’m not thinking about this project, but the next ones down the line. In the past these have been pretty big, daunting projects, so I feel this push to get the current one done as quickly as possible to buy more time for the next one.

This is 100% unnecessary stress. Most of these projects don’t really have deadlines, and plans tend to change anyway. Both 2020 and 2021 turned out way different than I had expected, for various reasons.

That being said, I’m still thinking about CommonCore 4.x, Shattered 2, and other 2022 projects right now.

What doesn’t work for me: multitasking

One thing that I’ve never been able to do is multitask. A lot of my friends watch videos while they work, but I’ve never been able to do this. If I try, I screw up what I’m trying to do and it takes me forever to get through the video because I keep missing sections, going back and rewatching them. I pretty much have a single-track mind. Pausing work momentarily to go deal with something else can also throw me off.

What I could have done better: tracking progress

I usually plan my projects by making a list of tasks in OneNote, marking them off as they get done and adding or removing tasks as the scope of the project changes. It’s all very unscientific, but it works well enough for me. I’ve never had a project where I didn’t know where I was or what I had to do, and I can get a good idea of how it’s progressing just by looking at the list.

The main reason why I’m hesitant to use more formal or more sophisticated tools is the overhead associated with using them. I’d have to set up a system, put the tasks in, change them as the project shifts, mark completion and maybe time spent as I do stuff. All of that takes time and energy. I never want to spend more time tracking progress on a project than actually working on it. Most of my projects are short, almost all of them are solo, and many don’t have time constraints, so loose organization isn’t a problem.

However, in this specific case, I feel I should have and could have done better.

I’ve been working through the game linearly from start to finish (I do approximately half of my projects this way), tracking progress by where my game is relative to the movie it was inspired by. This isn’t a great metric, as some parts are harder than others, I’m not doing a strict remake of the whole movie, and there’s various stuff that falls outside of this process, but it’s a reasonable rough estimate. Where I really screwed up is that I never recorded this metric at regular intervals. If I had, I would have been able to get a much better idea of not only where I was at but also how well it was going and if I needed to change things up to still hit my release target.

So what’s the verdict?

I’d love to have a firm conclusion here. I’d love to be able to cap this off with “it worked great and this is why” or “it didn’t work out and this is why”, but the reality is the jury’s still out on this one. I think some things worked, I think I’ve achieved a better balance, I think there’s probably still improvements to be made. But the thing is, the whole idea is to make game dev more sustainable for me as an individual, and I’ve only been at this for a month, and a confusing month with changing circumstances at that. I can have an inkling at a month, but the real test is over the months ahead.

I’ll probably reflect on this again some time in the future, though not on this particular project. I realize it’s a lousy way to end this, but all I can really say at this point is that I tried some new things, and I think at least some of them were beneficial.

Postscript: Doing both Devtober and Inktober/Drawtober

I just flat-out do not recommend this. You have to trade off time between one and the other, which adds conflict and stress to things that are supposed to be fun.

Get The Crystal Tower

Comments

Log in with itch.io to leave a comment.

Thanks for sharing = ]  How do you plan to go forward, you think you'll try to keep most of these changes or relax a bit now that the month is over?