Progress Report

Frank and I have worked hard on Where Shadows Slumber, and we continue to do so every day. As a team of two, designing a game at our own whims, it’s very liberating. No one tells us what to do, and there’s no bureaucratic red tape forcing us to work on any specific part of the game.

Unfortunately (for us), that red tape does have an actual purpose. Without anyone telling us what to do, we have to figure out what to do! I just touted this as a good thing, but it’s also terrifying! How do we know if we’re doing the right thing? We’re trying to get to a release of a completed game, and we’re the ones who have to decide how to get there! With success comes ultimate glory, but any failure rests on our heads. Given how likely failure is in this industry, we have to make the right decisions at every point of the way. How are we planning on doing it?

Well, despite the fact that I just really scared myself with that last paragraph, we’re going to take a deeper look into what we’ve done so far, and what we’re going to do next, from a project planning perspective.

 

How Far We’ve Come

evolution

The evolution of Grongus

Frank and I are just two normal duders. (Note: technical term)

We’re also two normal duders who happened to be perfectly suited to approach a project like this. He has some sort of degree related to art and technology, and I have some sort of degree in computer science. We both have the resources to survive without depending on the income from what will end up being a ‘pet project’, and yet we’re both driven enough to dedicate ourselves to that project, even though we’re not dependent on it. We’re close enough to be willing to work together, but not so close that we just end up bickering the whole time.

When the idea for Where Shadows Slumber came up, we knew we had something awesome on our hands. We came up with  a plan, developed a schedule, and started working!

Now, that plan and that schedule have changed a lot in the past two years. Features have come and gone, level design has gone through a lot of iterations, and even our day-to-day process has changed. But, through this flexibility, we’ve managed to stay somewhat on-track. We’re still here, we’re still working on our game, and we’re still in a position where we can have a timely release.

Those of you who have never worked on an indie game are probably wondering why that seems like an accomplishment, while those of you who have are dying to know how we did it. And, if I had to choose a word to describe how we got here, it would be introspection.

in·tro·spec·tion
noun
  1. the examination or observation of one’s own mental and emotional processes.

What I mean by this is that we are constantly looking at our process, looking at what we’ve done, the mistakes we’ve made, and the road ahead. We have to asses our project as often and as accurately as possible, and we have to be completely honest with ourselves, if we want an accurate plan of action.

We’ve done this many times throughout development, and last week, we sat down and did the same thing again. So, let’s take a look at that process!

 

Where we are now

In my experience, when working on a game, there are usually three mindsets you’ll fall into:

  • ‘Future me will take care of that’ – This happens when your target release date is far enough in the future that the time left and the remaining tasks haven’t formed into a concrete plan, but you have so much time that you know you’ll be fine. This is often accompanied with phrases like ‘I’ll still have  plenty of time for X once I’m done with Y’. Be careful with this thought process – in my experience, you always have more work and less time than you think!
  • ‘I’m behind schedule, and I didn’t even realize it’ – This might be the most stressful mindset, but it’s probably the best one. This starts to crop up as your release date is no longer ‘in the distance’, and the enormity of your remaining tasks really hits you. You start thinking things like ‘I don’t know if I can finish all this work in that amount of time’. If you’re here, then fear not! This is a great place to be – there will always be a lot of work to do, but at least you’re not in the final mindset…
  • ‘Finishing on time is literally impossible’ – This is where you don’t want to end up (obviously). If you put tasks off for too long, or underestimate how long things will take, or just don’t realize that your release date is approaching, one day you’ll wake up in this mindset. You’ll realize that, no matter how hard you work, there’s simply too much work left to do, and you’ll curse your former self for not working harder. Again, please don’t let yourself get here!

The first thing you’ll notice about these mindsets is that none of them really seem great! There’s no ‘everything is on track – lookin’ good!’ The first one kind of feels like that, but it’s usually just a trap. There’s a period of time, I think it’s usually like 6-8 months, beyond which it’s hard to see how a schedule will play out. You can end up in the first mindset, even if you’re incredibly far behind, just because it’s hard for us to instinctively schedule that time.

Checklist

It’s okay – the only thing left to do is everything!

But, either way, it’s okay! Nobody gets into indie game development for the relaxing schedule and numerous spa days – we expect to be behind the 8-ball. The reason I bring this up is so that I can describe where Frank and I are in the process. And you know what?

We’re behind the 8-ball. We have a lot of work to do. In particular, in the past month, we’ve moved from the first mindset to the second. When we had more than 6-8 months left, it felt like we had all the time in the world. Now that we’ve just crossed the border into the 6-8 month mark, it’s starting to hit us – there’s a lot of work ahead of us. Do we have enough time? Can we get everything done?

These are the thoughts going through our heads now. And there are questions that naturally follow – can we still make it? What do we have to do now? What’s next?

 

What’s Next?

planning

This is what planning feels like in indie game development

When you find that you’ve fallen behind in development, you have to correct your process somehow. In my experience, you have three major choices:

  • Delay the release – There’s not enough time to do everything. The fix? Just take more time! This approach is fine (especially when your fans are expecting high quality), as long as your fans are somewhat understanding, you’re not racing against anything (like a competitor, or your own funds), and you haven’t already delayed the release by a lot.
  • Reduce the scope – There’s too much stuff to do in that time. The fix? Just do less stuff! This basically means that you’ll make fewer levels, add fewer features, and maybe decrease the quality that you expect from your game. This is useful, but it can be dangerous – just make sure that the game you end up with is still good enough to be worth it!
  • Buckle down – This one is last, but it’s usually the first one we try. We can’t change the release date – we made a promise to our fans! We can’t reduce the scope – we will not sacrifice our game! Sometimes in life, you simply have to work harder. Before you realized you were behind schedule, it was easy to durdle about, not really getting the important things done. Once you know you’re behind schedule, sometimes all it takes is a mental shift to get more done.

These are the three biggest options you have. Choosing what you need to do at any given point is an entirely subjective task, in that it depends on the stage of development, the type of game, the personal lives of the team members, the average annual wind speed, etc. Basically, I can’t tell you what to do here – if you’re already working 50 hour weeks, maybe you simply can’t afford to work harder. If nobody knows what your planned release date was, and there’s no market pressure, maybe you can just move it back a couple of months. Just choose what’s right for you, and don’t be afraid to re-asses that choice as time passes.

The important part is to actually make a choice. If you realize that you’re not going to finish your game on time, you need to do something. The math isn’t lying, and the longer it takes to make a change, the worse off you’ll be. Recognize that there’s a problem, and do something about it.

Right now, Frank and I are behind, and we’ve decided that we’re going to buckle down. We’re going to work harder and get more done. In another week, we’ll asses our progress and take a look at the road ahead. If we’re still behind, then maybe we’ll resort to reducing the scope or delaying the release. Hopefully we don’t have to, but it’s important to be flexible and honest with yourself.

This post, of course, does not get into the minutiae of how this planning process relates to Where Shadows Slumber, but I hope it was either helpful for your own planning process, or at least entertaining. Until next time, may you examine your own progress, and I hope that you always find yourself ahead.

 

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

If you have any questions or comments about our project planning process (or anything else), you can always find out more about our game at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebook, itch.io, or Twitch, and feel free to email us directly with any questions or feedback at contact@GameRevenant.com.

Jack Kelly is the head developer and designer for Where Shadows Slumber.

Advertisements

Time Tracking, When Done Wrong, Is Useless

My good friend, this week you are in luck.

For starters, I’m going to forego my usual wordy style and cut right to the chase. I’m typing this well in advance of the deadline, because I’ll be on vacation when this is posted. That means I don’t have time to blather incessantly about artwork and other such nonsense. (Really, who has the time?)

The other reason you’re in luck is because I’m about to save you about 14 months of hassling when it comes to proper time tracking. They say that good judgment comes from experience – and that experience comes from bad judgment. Well, let’s talk about my experiences with time tracking. Then we’ll get to my bad judgment near the end.

 

Jack

A sample time sheet from the veeeeeeery beginning of the Demo Phase.

 

Time Tracking: An Intro

Before we go on, a quick definition is in order. You’re probably wondering what time tracking is. (If you already know, you’ll save time by skipping this section.) Time tracking is the continuous project management process of collecting data on how members of a project are spending their time working on that project.

In theory, you’re supposed to do it for a few months and then look at the data. If you find out everyone is spending 5 times as long as they should working on some task (A), then you’ll change process (B) so that task (A) doesn’t take so long in the future. That’s the hope, anyway.

In practice, it means filling out time sheets (see above) like a madman every time you do anything related to your indie game. Done incorrectly, it will actually take time away from your project and give nothing back in return. Done properly, it gives you keen just-in-time insights that let you wisely cut features and move staff around before you hit that impending deadline.

 

Old Sheet

On the surface this time sheet may look good. However, on further inspection…

How To Do A Bad Job

I want to tell you how to do time tracking properly, but you won’t appreciate the correct approach until you see it done wrong.

For the entirety of our time working on the Where Shadows Slumber Demo, Jack and I tracked our time with a time sheet I devised. This Google Spreadsheet had an entry for every sprint (a period of 1 or 2 weeks, usually the time between team Skype meetings) with a bunch of headings: Day, Start, End, Total, and Task. Here’s what they meant:

  • Day – What day during the Sprint did you work on this Task?
  • Start – “Punch in” at a time to begin working on the Task.
  • End – “Punch out” at a time to stop working on the Task.
  • Total – The number of minutes you worked on the Task.
  • Task – What you worked on.

As you can see, this tells us a lot about how I spent my Sprint. But none of this information is relevant to project management in the long term. There’s no indication whether or not I actually completed the Tasks I worked on. (Some have percent complete markers, but those are just guesses anyway) Looking at this, I have no idea how the project moved ahead during the Sprint. Our only real metric is the number of hours I worked – nearly 19. But… who cares? It’s not like I’m charging anyone by the hour! Jack and I do this as a labor of love, with salaries to come from proceeds from the final game.

This time sheet makes the critical error of measuring the wrong metric. I must confess that some weeks, I tried to just work for a long time instead of working effectively so I could feel good about logging impressive hours. That’s a sign of bad project management. As a manager, you ought to offer incentives for behavior that gets the project completed on-time and at a high quality.

The results? Internally, we had a lot of arguments about this process as Jack felt it was unnecessary. Because I never returned to the data we created to analyze it, we got nothing for all our tedious efforts. Jack stopped tracking his time, and that was a warning sign that I needed to change things up. Our time tracking was costing us time to do, with no benefit to the team. Time for a change!

 

TimeSheet

Time Sheet: Version 2.0!

 

My Time Tracking Strategy

Here’s how I altered the process for the final project. Starting April 4th, I began tracking my time the way shown above. The headings this time are Task, EST, ACT, Error, and Status. Let’s deconstruct that jargon:

  • Task – One entry for the Task this time, no matter how long it takes.
  • EST – Short for “Estimate”, this is an educated guess about how many minutes this task will take to complete. You’re supposed to guess at the beginning of the sprint.
  • ACT – Short for “Actual”, this is the actual number of minutes this task took to complete. You’re supposed to fill this in as you go. It’s the only thing that requires active time tracking while you work.
  • Error – This is automatically calculated with an Excel formula. It’s the percentage of error between your guess (EST) and the actual time (ACT). You want to get 0%, meaning that your guess was perfect. The larger the number is, the worse your guess was. The formula I use here is =(ACT – EST ACT.
  • Status – The most important part! Each task is a discrete item within the larger project that is either done or not done. We want a full list of check marks at the end of this sprint. If a task is left incomplete, there had better be a good reason!

As you can see, now the spreadsheet is setup with the Task as the most important thing. We’re measuring whether tasks are complete ( ) or incomplete ( ) instead of measuring how many hours someone has worked. That’s important, because people tend to maximize whatever they’re being graded on if you observe them working.

It’s changing my behavior, too! Instead of acting like I need to fill my time sheet with useless “minute points”, now I feel the pressure to get my estimation right. Of course, I can only be right if I finish the Task. The incentive structure of this time sheet is way better! We begin with an incentive to make a good guess. Then we have an incentive to conform towards that good guess so we don’t get “mark of shame error percentages”. Finally, we have an incentive to finish each Task so it doesn’t remain a permanent “X of shame” forever. Perfect!

This will lead to actual progress on the project and helpful information about our estimation ability at a glance.

 

innovation-think-big-act-small-fail-fast-and-learn-rapidly-7-638

In all seriousness, though – I did fail.

The Lesson? Get It Right The First Time

To conclude… I have bad news. If you’re a project manager, listen up! You need to get this stuff right the first time. Putting your teammates through a tedious process of time tracking gets on their nerves after a while. People can only put up with that for so long, especially if they don’t get anything out of it.

I’m still doing time tracking, but Jack has become disillusioned with the process. I don’t blame him, but it’s still a shame. Had I gotten this right the first time, we might still be on the same page.

Don’t reinvent the wheel like I did on my first attempt. Use a proven method that works, read some software management books, talk to an industry professional, and communicate with your teammates during the early stages of the project. If you do, people will find time tracking fulfilling. Otherwise, they’ll fall by the wayside. And remember – you can never force anyone to do anything, you can only offer irresistible incentives!

 

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

Thanks for taking the “time” to read this “clock”. Have a question about time tracking that was not answered here? You can find out more about our game at WhereShadowsSlumber.com, ask us on Twitter (@GameRevenant), Facebook, itch.io, or Twitch, and feel free to email us directly at contact@GameRevenant.com.

Frank DiCola is the founder of Game Revenant and the artist for Where Shadows Slumber.