Is it Still Scope Creep if you Plan for It?

July 24, 2015

Scope creep. The bane of software project managers everywhere. That state of being where more features and more features and even more features work their way into a software product beyond the original scope of the project. They may be good features, they may not. Regardless, they inevitably cause a project to take longer than originally estimated.

Observant players of my first computer adventure, Sleuthhounds: The Unlocked Room, may recall that the credits of the game stated “Watch for the next Sleuthhounds adventure / Coming Spring 2015.” Well, we’ve very clearly passed spring now and the next Sleuthhounds adventure, The Cursed Cannon, is still a ways away from being released. So much so that I can’t yet commit to a release date, although August seems promising. Or possibly September. Or hopefully not before the end of the year. This decade definitely.

So, why the delay? There are a number of reasons, actually, but basically they all boil down to three things.

Complexity

When I created the first Sleuthhounds game, The Unlocked Room, I very intentionally kept the game design simple. This was because I was developing my own game engine at the same time. I wanted a simple game so I wouldn’t have to think too much about its design while I was getting the basic underlying technology in place.

Most of the first game consists of a single character proceeding linearly through the rooms of the game. As the player proceeds, they are unable to go back to earlier rooms. As well, since it’s mostly only one character moving around, complex character-to-character interactions didn’t factor into things. Finally, the various animated sequences of the first game tend to be much simpler than in the second game; with the most complex sequence from the first game (Pureluck Homes knocking a ladder down from a room above) being only slightly more complex than the least complex sequence in the second game.

From a technical standpoint, the design of the second game is much more involved and complex than the first game in every way. So even though I tracked how long things took to do in the first game, those numbers tended to be low when compared to the complexity of the second game.

Breaking Point

When I created the first game I really didn’t know how far I’d be able to push the technology. I didn’t know how complex I could get with animations. I didn’t know how well character conversations would work. I didn’t know how involved incorporating things like voice files, sound effects, and music would be. I didn’t know. I didn’t know. I didn’t know.

When I first designed the second game – back before the first game was even really started – it was much less ambitious than it is now. It was going to be another tiny adventure with length about equal to the first one.

However, once I finished the first game, I realized that the power and flexibility of the game engine and its scripting system were such that I could push the game design much more, which accounts for the increased complexity I discussed above.

With the second game I knew the development tools and process much better. I wanted to see how far I could take the second game in terms of puzzle complexity, grander animated sequences, and non-linearity. The answer is, pretty far. Pretty far but at the expense of making the game much longer than I’d originally anticipated. I estimate the current design for the game is almost triple the size of what I had originally planned.

Play Testing

One goal I had with the first game was to get it done and out the door as quickly as possible. Its primary job was to have just enough content to enable decent construction of the underlying game engine technology. Tech typically either works or it doesn’t. There’s not a lot of gray area in between, so it was very clear when the first game had hit its goal.

With the second game, especially after I decided to push its design so much farther, the end goal is a little different. The second game is much more about the story and characters instead of the technology. Story and characters have a lot more gray area in them. You have to put across enough information to players so they can understand what’s going on, but not so much that they get bored and lose focus.

To help determine that, with the second game I did something that I skipped over with the first game. I ran a play test.

Basically, this consisted of getting several people in the room and watching them play the game while it was still in a relatively early state. They would comment on issues they found or if they had suggestions on how they thought the game could be better. And of course, just watching people play really reveals the areas that are working and the areas that players are struggling with.

In conducting the play test I came away with almost eleven pages of point form notes for things that came up during the session. This was in addition to the list of technical issues that I was aware of that needed fixing.

The biggest change to come out of the play test session was my approach to the Jane Ampson specific Storyboard gameplay mechanic. I’ve previously blogged about changing the Storyboards to be a Timeline so I won’t go into further detail there. Suffice it to say that since that mechanic formed a core part of the gameplay prior to the play test, then changing it out had a lot of repercussions both big and small through most of the game.

The notes and ideas that came out of the play test session were really useful. To be fair, I’m not implementing all of them but I am implementing a good number of them. Put simply, that takes more time. Those items that are going in, I feel, are worth the extra cost in extended development time.

Final Thoughts

I don’t know exactly when the game will release at this point. However, I do have an itemized list of everything that’s outstanding. The number of things unfinished on the list are very much outnumbered by the finished things on the list. The ending may not quite be in sight just yet, but I would say it’s just beyond the next hill.

Obviously I would have liked my initial estimates for how big the game was and for when it would release to be correct. However, from the beginning, part of the reason for doing the first two small games was to get a better sense of how long things took to develop so that when I scope out the first full length game I have some actual history and experience to base its estimation on.

At the end of the day does that make the second game a success or a failure? I think it probably makes it a successure. Or possibly a fail…um…cess? Failcess.

Watch for The Cursed Cannon coming…sometime.

Previous: After a Game Engine, You Can Program Anything   |   Next: CMYW - Support Your Local Game Dev