POST

Every project needs an end, and that includes video games. But how do you decide what "done" means for your prototype, your vertical slice, or even your whole game? I might not know much about game development—but I have a lot of experience defining software scope. For my most recent iteration, I spent time out of the code editor and in a Markdown editor. I even used spreadsheets! *gasp* 😜

As I went through this past two-week iteration, I spent the majority of my time trying to nail down the project scope. More specifically, trying to answer three questions:

• What is this game?
• What are my project constraints?
• Where is my audience?

Although I am not experienced in game development, I have quite a bit of experience defining scope for non-gaming projects. I tried to map that experience to what I am trying to do with the Passenger prototype.

So, what do you do to define scope in software?

You write documentation, of course! Which is exactly what I did this iteration.

Here's what I worked on in terms of documentation.

GDD (Game Design Document)

A GDD is sort of the obvious one. I am not going to go into depth here about how to write one, as much more experienced folks out there have already done that. However, if you are unfamiliar with them, I suggest doing some research.

I based mine on the one shared at develop.games, which is still available as a Google Doc here.

The GDD provides the scaffold for the project and, more importantly, a reference you can always return to when figuring out if something belongs in your game or if it's scope creep.

Project Plan / Schedule

I have grouped these together because they help define the constraints for the project.

With projects, you always have constraints. The usual suspects are time and money. In my case, I am most curious about time (mainly because I have very little to no money for the project at this point).

I use GitHub for the project plan, and it helps me understand how much work I need to do to complete the various milestones of the project. The schedule shows me how much time I have available and what beats I want to hit with my game. Together, these let you do "project math" to determine if you have enough time in your schedule based on how long you estimate the project will take.

Again, not going to elaborate on project math—and estimates, by definition, are not facts or truth. However, they can help you determine if you have too much scope in your plan and need to trim things down a bit.

You trim them down by reviewing the GDD and the issues list in your project plan to figure out if every feature is needed.

Competitive Analysis

I learned to put together a competitive analysis for a game through a masterclass and through local resources with the business development group New Media Manitoba.

When you learn about what it takes to get funding for a video game, you find that it takes more than just a great pitch and a demo. It also takes a business plan.

The competitive analysis is what publishers and investors are going to want to see (amongst other things) to determine if your game is commercially viable, because it helps answer the question of finding your audience.

Once you know where your audience is (i.e. they are on the Steam pages of those comparable games), you can analyze the tags and figure out if your game idea aligns with the games you defined as comparable.

In my case, I assessed the tags that I wanted to use for my game and figured out if they aligned, in some capacity, with the games I believed to be comparable to Passenger. From there, I can start to deduce if my scope is big enough, too big, or too small for that audience.

It helped me answer the question where is my audience? when it comes to Steam. I can see the size of other games I believe to be comparable and figure out if my scope is realistic, too big, or too small.

Story Outline

This might not work for every game project, but it works for the ones with a narrative as a core feature of the game.

I started writing down the story to figure out how I would tell it through the gameplay mechanics I had defined so far and those I had planned. This exercise of understanding all my story beats helped me clarify the game I have in my head and, ultimately, whether I have all the pieces to deliver that story.

If I do, then my scope is probably in a reasonable state to deliver the vision I have in my head.

If I don't, then I either need to change my story or add the features I think I need.

Related Devlog

I recorded and published a video on YouTube. I go into a bit more depth about some of these documents if you want more specific context about how I use them for Passenger.

Have a great rest of your day.