Post #1: 360 No-Scoping the Project

Listen closely, for I am about to share with you a tale of great importance.

To correctly scope a project can be a challenge. Over-scoping is pervasive in video game development, where “feature creep” and underestimating the amount of time the game will take lead to games being delayed for years or canceled altogether (which can be a better outcome in some situations). How should one go about scoping their game? I don’t know. I’m inexperienced, a student, and this is a problem that even veterans experience. Here’s how I approached determining a scope for making the game Friendship Down. It seems like I may have done a good job with it. Maybe.

Sometimes there’s just too many robots.

The concept for Friendship Down was only chosen by my own group, Poltergeist, arguably the best group, but that’s beside the point. No one chose it for good reason. It features two companion characters which need their own AI, two bosses, three levels, mechanically is a bit less traditional, and the characters in the game are people, alien people. Now the people part of that may not seem so bad, but one must consider animations. Shoot ’em ups traditionally feature some sort of flying combat vehicle, generally a spaceship. Spaceships are pretty easy: a lot of straight lines, doesn’t move around much. If we look at the concepts that were chosen by other groups, we have similarly easier player avatars: a boat, a flying boat, an underwater boat. Humanoid characters are harder to draw in the first places, and may require extra animations such as for walking. One can simplify and abstract the characters, for sure, but that was not the art style used by the original group, and would not fit the game as well. I do not even want to get into the complications of the AI for the companions and the bosses. We had a daunting task ahead of us.

My first step was to get out the chainsaw. I had to trim down the design, make it streamlined, lean and mean. First thing was to cut the bosses. Don’t need ’em. Then, remove the need for some extra animations. No one needs to walk, it’s a sci-fi game, they can have futuristic hover technology. Three levels? No way, one level. Being able to shoot up and down? That means more coding and animations. You shoot to the right, and you’re going to like it. Making AI dodge bullets is hard, so how about the companion characters have special future energy shields that block most bullets, i.e. they are only damaged by special attacks. Enemies can just shoot randomly, because that’s what shoot ’em up enemies do. Suddenly our game became much more feasible.

We still had a problem. All of us are pretty much completely inexperienced in making games. We do not really know what is within our abilities, so it is hard to predict what we will be able to do in the allotted time for the assignment. So, the solution to this was to focus on the core of our game and push anything superfluous to be done later, where it can be cut if we have to. This means we can get the most vital features out of the way first, and any problems associated with them. If we find that we overestimated what we can get done, it’s okay, the things we did not get to will be unnecessary. In this way our scope is flexible. In fact having your features be variable is quite [AGILE].

So far, cutting the game down to size and leaving the less important parts of it open to being cut as well seems to have been a good choice. We have dropped a few more ideas along the way, but overall are on track to where we need to be.

However, the chainsaw is still close at hand.