Smoothing out production in a multi-project indie studio

by | Mar 5, 2024 | Blog | 0 comments

This article is a collaboration with Ewan McKenzie, Producer at Ant Workshop, about the importance of time logs for game production.

At Ant Workshop, we’re a small indie studio that has worked on a variety of projects of differing scopes. From small prototypes to porting PC titles to consoles, to the full development of our mini golf party game Dungeon Golf, we’ve done loads of different things since the studio started in 2015. Over the years we have found that each of these different project scopes has their own unique challenges!

One of the consistent processes we have, no matter which project, is making sure the team provides accurate time logs through HacknPlan. We get it though, nobody gets into the games industry to add time logs every day and sometimes it can slip the team’s mind. An automated Slack application posts reminders every day at 09:30, masquerading as the titular character from the 1994 Jean-Claude Van Damme film Timecop. However in our instance Timecop isn’t investigating time travel crimes, but crimes against missing time logs. The most heinous of crimes to a producer!

Time logs are vital to our production process, both for looking at historical data to figure out how long future projects will likely take, and also for short-term planning. Combined with time estimations from the team, we can use logs to figure out historically how accurate estimations are, and plan production accordingly.

Everyone is different – Some people can be good at estimating short tasks, but not so good at longer tasks, or vice-versa. However, through the magical power of the laws of averages (and some spreadsheet skills), we can figure out how much time it will likely take someone to do a task. HacknPlan acts as the communication tool between the developer and production in some respects, allowing the developer to update logs and estimates as appropriate when working on a task or bug.

One of the main challenges in managing multiple different types of projects is the difference between having fixed deadlines that cannot be budged for external clients, and working on our own internal projects where we can implement self-imposed deadlines and targets.

On our own projects, we’re fortunate to have flexibility on delivery dates, but still find it beneficial to set our own milestones. We settled into a rhythm of one-month-long milestones when developing Dungeon Golf, which consisted of roughly a solid week’s worth of work for each developer. This allowed us to deliver an achievable amount of deliverables while still allowing flexibility to work on other things as they popped up. 

This level of flexibility isn’t an option when our clients have hard deadlines that need to be achieved, so our production approach changes accordingly. Typically our co-development and work-for-hire projects will not include everybody on the team, so we often have multiple projects happening concurrently. We create a task list before we begin work, and have the relevant people estimate the length of each high-level task. We then use the experience we have on other projects, combined with the historical accuracy of that person’s estimates for that size of task, to adjust the estimate. Of course, no two projects are the same so even something as common as an achievement handler can throw up the occasional surprise, but over time our estimates become more accurate. It means we can start any work-for-hire with a schedule and work plan we have confidence in.

Using the techniques previously mentioned, we can figure out if a project or task is slipping behind schedule for whatever reason, and plan to either adjust the scope (if possible) or have other team members jump on and help out. This alleviates the pressure of a mounting task list on others and avoids major workload issues.

Whether it’s on client projects or our own, we’ve also got to account for team absences, holidays and contingency time. The last thing we want is to crunch because of some easily avoidable situations!

  • Booked holidays are easy to put into a schedule, but we also consider the possible amount (based on averages for the timescale) that each person might take based on their remaining holiday allowance for the year. This means that if someone wants to take a long weekend at last-minute notice, it isn’t an issue and has already been accounted for. Additionally, the expected amount of other absences (such as illness, or attending events) is calculated for a given period proportionately based on our historical data.
  • “Contingency” time is also calculated into schedules. This accounts for time that is on the company clock but is not likely to be spent directly doing development work. The most common thing to attribute contingency time to is meetings – we’re a hybrid/remote team and have three scheduled meetings a week, so everybody has a chance to see and talk to each other, and keep up to date on what other folks are working on. Other things can also happen that need to be accounted for, however! Technical issues, reviewing work, writing documentation and playtests for example. Time spent on these can add up, and it’s best to factor that into planning from the start, rather than hoping that this will be the magical month where everyone can work 100% with nothing else cropping up.

In conclusion, there’s a lot to consider when planning out different projects! But for us, a solid backbone based on time logging in HacknPlan is the key to smooth, stress-free, on-time development which allows us to deliver the high-quality games our players and clients have come to expect of Ant Workshop.


Submit a Comment

Your email address will not be published. Required fields are marked *