Today, I'd like to discuss something that is not specific to game development--project scope. However, I will be using my experience making games to talk about project scope.
Now, I know what you are thinking: "I thought The Sharpest Blade was their first game?!" Well, I have a confession to make. While this is the first game we have released, it is not the first game we have worked on.
A Hidden Past
We had decided that we wanted to get into game development very early last year, around February or March. We were all in school however, so we made plans for the game, but we didn't start working until the summer.
What was the game about? Well, we tried to keep it simple. It was a sidescroller of a man with a hanglider, desperately trying to return to his home kingdom. In the game, the whole world is filled with hostile territories, and if he lands in any of them, he would certainly be killed. So, he has to glide his way past birds, kites, archers, catapaults, and more to reach home safely.
The premise does not make the game sound too large, and yet, this game is going to be my main subject for analysis regarding project scope.
The Unfinished Game
Summer is a great time to get stuff done, especially when you are in school. However, this span of time can be too much time, as the hours melt together and the deadlines never seem to approch. As we worked on the game, we came up with concepts, basic gameplay ideas, and more.
The timeline more less looked like this:
- Summer, June 1st, 2013: Design a propery game prototype.
- Summer, June 25, 2013: Finsh designing the story.
- Winter, Dec 21, 2013: Official release date for game.
Ahh, what a beautifully vague timeline. Sure, it set some hard dates. In fact, we did finish a prototype (of sorts) by June 1st. It was playable, with lives, death conditions, and some art. So . . .
You know, I never actually thought about what happened to this game until I actually sat down and began writing this post. Now, however, I have a pretty good idea of where things went wrong.
You and I can both probably tell that the aforementioned timeline is not something we wrote in stone. Part of the failure lied in its lack of clarity. That lack of clarity, however, is actually proof a deeper lack of clarity--that of the game. We were not sure what kind of enemies we wanted nor how many levels there would be nor what the story would . In fact, I would go so far as to say we weren't sure of the actual mechanics this game had, that is, what it different than the rest. The first deadline should have been making clear what our MVP (Minimum Viable Product) would be. You can define the entire scope of your project once you know exactly what it is you are trying to achieve first. It is actually laughable that we set a game release date when we no idea what we were actually making.
A lack of defined game characteristics also leads to a lack of direction, because the game "idea" floats in the air, but no actual progress can be made without identifying the mechanics involved. Scope will define what is necessary to prove a concept playable before making it a reality. More importantly though, scope will help you realize earlier when a concept is unplayable.
Iteration is what brings a concept from prototype to a full-fledged game. Not everything is going to be right the first time. However, with a clearly defined set of goals, a prototype can be refined and adjusted to create something beautiful. On the flip side, a prototype that lacks direction also lacks an iterable aspect as a result. This was probably the major flaw in our design.
After we played our first prototype, it became apparent that something was off. This "something" was difficult to express, however, when the mechanics of the game were not thought of properly. The prototype was not oodles of fun, and we knew that, but we tried to add art and music to fix it. Deep in the back of our minds, I think our greatest fear was that the game in and of itself was not fun.
If an iterable prototype were put together quickly, it could have been changed or scrapped without losing too much time. Our prototype had little iterability and took some time to make, which made us too invested in it. Thus, it was less a prototype and more just "game progress," for a game we were not sure would work. Don't kid yourselves guys. Make the prototype to evaluate your ideas, not just to call it a "prototype" and keep working. Since the game was neither here nor there, progress sort of . . . fizzled out.
The Sharpest Blade
I'll keep this part relatively short, because I covered some of it in the postmortem.
On a more abstract level, it could be said that the making of this game was a sort of "reinitiation" to game development. We wanted to find out--was our problem with the previous game due to scope? Or was it that we just can't "finish" games?
For this game, we had an instantly obvious deadline--2.5 weeks, before Joraaver flew back to UCLA. So our scope was inherently limited, and because of the last game we tried making, we forced ourselves to go smaller still. The playable prototype was done in 2 to 3 days. Art and music were not important until the game was deemed playable and most of the design decisions involving the mechanics were made.
Once the groundwork was established, the rest of the work just flowed around it. That's how we avoided repeating history.
Scope is everything a project is, down to the last detail. However, defining the scope at the start is difficult because of how much work it involves. Thus, I've picked out a few things for you to take away from this post involving project scope.
- A fast, iterable prototype is key. With it, you know what the scope may involve. You will also establish your key mechanics here.
- Deadlines. Why after the prototype? Becuase you can't realistically set deadlines unless you know what you are trying to pursue.
- Don't understimate the little things. These take a lot of time, from publicity to the menus.
I hope this post was helpful to all of you. Thinking about it all was certainly helpful to me!