Scoping
When you’re planning out your game, scoping is one of the most important aspects of project management. Scoping is picking ahead of time what tasks are necessary to complete a project. This leads to two other terms, overscoping and underscoping. Overscoping occurs when you have more to do than your team can handle in the time given. Underscoping occurs when you don’t have enough tasks to fill the time given.
Clearly, overscoping is about roughly a bajillion times worse than underscoping. If you underscope a project, you simply add more features. You take more time to polish everything. Any surprises can now be handled. Even if you reach a little further and it ends up being too much, you can always fall back to the original working game. This does not mean your ideas have to be boring! Underscoping doesn’t mean you have to make a 2D platformer where you jump and shoot. It means if you are taking a risk and making that soft body physics church organ rhythm game, you cut what you have to around it so you have the time to execute what needs to be done. Underscoping leads to a well executed game and a calmer experience making it.
But on the other hand, overscoping is so tempting. It feels right. It feels like this is where legends are made:
This idea is just crazy enough to work. A dating sim racing game set in a dream world with a day night cycle that is due in three months. That professor just doesn’t believe in us, man. We can do this! I know that if I work for forty hours straight this week, I can easily get all of these features in. This is my passion. Don’t try to restrict my passion!
Here’s the problem:
You don’t know what you don’t know
If you’re reading this as a freshman or sophomore, or hell even a junior or senior, you don’t know what you don’t know. Throughout your entire professional career you need to have a healthy understanding that there is a lot you don’t know. I work at Google. I’m a tools programmer there. I’ve technically been programming for about eight years now. I don’t know anything.
There’s huge amounts of topics in not just computer science, but also project management, business, art, sound, design and writing that you just don’t know about. I didn’t know what a subordinate clause was. I didn’t understand the complexity of lighting. Even in the topics I feel I have the strongest understandings in, I’ve barely scratched the surface. I love project management. I’ve worked on small and large teams, but have I worked with lawyers? What about other companies? How about having a user base I have nothing in common with? What about having a user base that is literally billions of people?
Professional companies only slightly care about how revolutionary your product idea is. What they care most about is if it will be in there hands when you said it would be.
Start your project small. Do one thing.
A dating sim racing game set in a dream world with a day night cycle.
Try just making a racing game! Why take the risk of diving into multiple topics you haven’t actually executed before? Do one. Do it well.
By setting the goals smaller, you’ll be able to focus in on what is interesting about your idea and succeed.
What is a Feature
A feature is any individual thing players can see, do, or hear in your game. When trying to scope, it’s important to be able to effectively pick out what is a major feature in your game. A major feature is any feature that will take a significant amount of resources or time to implement into the game. This leads me to one of the first mind bending concepts that hit me while I was at DigiPen.
Team members are a feature you have to implement.
Let’s assume we’re sophomores making a custom engine 2D physics based platformer with fighting mechanics and a linear story. What’s wrong with this team composition?
- Four artists.
- Three programmers.
- One designer.
- One sound designer.
The artists tasks could be broken up into backgrounds/foreground elements, characters, animations and effects. One programmer for core engine, one for tools and one for physics. The designer can just handle gameplay mechanics and the story. Sound designer pops in three days before submission and makes all the sounds.
What ever could go wrong with this?
Remember, teammates are a feature.
When a game doesn’t have art, there’s no expectation for it to be beautiful. It just needs to look passable. You may still have to worry about basic art features like graphics or lighting, but it’s not nearly as important.
When you have artists, the bar is way higher. You need special shaders to make their art look good. You need tools to get the art in so they can view it in game without your help every time. You need to run faster because the texture quality will be much higher. You need to take the time to communicate technical problems to a person who is not yourself and may not be tech savvy. You need to create animation systems. In 2D, this means Spine (a living nightmare of a code base) or sprite sheets (lots of custom work hooking them up). In 3D, this means…a lot. IK, animation blending, importing assets, testing transitions, etc.
The same applies to adding sound designers, designers and even programmers! Here’s a small list to give you an idea:
Sound Designer:
- Wwise/FMOD implementation
- Sound Engine to play the sounds (including abstractions so you aren’t putting sound files into code)
- Reverb, including finding ways to detect what kind of reverb to be using.
- Occlusion and Obfuscation
- Any special effects they might want to do
- Putting the triggers into game
- Scripting engine so they can put the sound in themselves.
Designer:
- Level editor (This could honestly be broken up into about a thousand sub-tasks)
- Metrics
- Playtesting tools
- Scripting Engine
Programmer:
- Logging
- Performance analysis tools
- Linter
- Code submission processes
- Testing framework
- Code Review
Slow is Smooth, and Smooth is Fast
The list above is a lot.
While you might think you don’t need all of these things, you really should. These little details and tools are what allow you to build incredible games. If you’re missing any of these, you have unnecessary friction in your development process. Making the game should be fun and easy. If you’re skipping tasks to “just get the game done”, you’re hurting yourself, the team and the game.
Build a strong foundation for your game to be built with. There’s a common temptation to try to get the game done as fast as possible, especially at DigiPen; You have tons of work to do and not a lot of time to do it. Resist that urge.
If you can take a little extra time and data drive something, do it.
If you can take a little extra time and really ensure something works, do it.
Tech debt is sort of like cement. The longer you keep it around, the more it hardens. The more you pour on top of it, the harder it is to clear it all. Don’t let problems sit. If you know what the better way is and you’re just too lazy to do it, don’t complain later when it bites you.
Opportunity Cost
Opportunity Cost is what you miss out on or could have done because you decided to do something else. If Safeway only puts one cashier out at 5pm on a Friday and the line goes half way down aisle 5, I’m going to QFC. Whenever you pick tasks, ask yourself what value you gain and what value you miss out on. DigiPen isn’t just about working hard. It’s about working smart and hard.
As the programming saying goes, You Aren’t Going To Need It (YAGNI). While taking your time to build in those extra features will often help, you have to think smart as well. There’s a lot of programming tasks that are “cool” or look fun. Advanced AI is a very common one to fall into. If you’ve taken Prof. Rabin’s Game AI class, you know how often “Incredible AI” turns out to be a voice line. Or just something randomly working out. Or a one liner. If you spend five weeks on advanced cooperative flanking enemy AI and not a single person playing the game notices, you’ve basically deleted a member of your team.
The same goes for core engine. How much is something actually going to buy you? Will that tool be used? By who? Is there some other way to implement it that’s faster? Has someone already created this tool?
If you can (elegantly) design your way around a problem, it’s almost always the best solution. When you commit one of your teammates to a task, you are trading their time for some sort of value.
Every 3D engine needs an editor. Every 3D editor needs something to manipulate the transform of objects. You could write it yourself, or just use ImGuizmo and cut the task down from a month to a night. The linear algebra involved with that tool sounds like a ton of fun to figure out and learn, but is it really worth removing yourself from the team for that long?
Now, going back to that list, some people reading that might be skeptical. Tests? Why? Code review? That’s for cubical workers. In the next one, let’s talk about tools.