Your First Milestone: Vertical Slice

Note: A simple example can be viewed here.

This is the unit where you’ll start writing “real” code – code that will end up in your final game. If you’re still getting used to writing code, there are some common pitfalls that can make your life a lot harder than it has to be. These are the top things you can do to help yourself as a coder, based on working with hundreds of beginning programmers here at USC. The examples given refer to Unity, but the basic ideas are the same for other engines.

Give yourself a break

First, notice the things that make learning programming hard. You’re trying to learn a lot of things at the same time:

• Unity and your code editor as applications – finding the right menu, understanding different dialogs and so on.
• The syntax of the C# programming language, that is, where to use parentheses and semicolons, whether to capitalize function names, and so on.
• The programming structures of the C# language, that is, its type system, how it implements things like lists and for loops, and so on.
• The Unity API, that is, how you talk to Unity from code.
• The skill of abstract problem solving, which humans just aren’t very good at.

The hard part really is that last one, but the others will all get in your way a lot as you’re getting used to them. So the most important tips of all are:

1. Be patient. You’re learning a lot of things at once, and computers are passive-aggressive jerks who discourage you wherever they can. But it’s not a matter of being “good at programming” or not, any more than you have to be “good at walking” to walk. It’s a matter of persisting and outlasting the scoundrels.
2. Try to separate the abstract thinking and problem solving from all the other parts. That is, step away from the keyboard. Draw a picture of the problem. Write down the steps you’re going to follow to solve it. Then go back to the computer and try out your solution, one step at a time.

Avoid the hardest work

The hardest part of programming, especially for new coders, is debugging. Once you’ve written code, it’s really difficult to go back and see where you made a wrong assumption or missed a step. Here are some proven ways to avoid debugging.

• Comment your code, particularly if it was hard to figure out. Better yet, comment your code before you write it – describe each 1-3 line block of code and explain what it does. This will help you avoid the evilest kind of bug, a logic error.
• Use descriptive and unambiguous variable names, even if they seem overly wordy. Debugging unclear code is much, much harder than just typing a few more characters.
• Write two or three lines of code at a time, and then test them. That means write a little bit of code, then go back into Unity and make sure you don’t get any compiler errors.
• Before you try doing anything fancy, use Debug.Log to make sure things are running in the order you expect. For example, before writing code to handle enemy collisions, print out the name of the other object in a collision to make sure the collision is happening.
• Then test your code.
  1. First, make your new code run. For example, cause a collision by dragging objects in the Scene view while the game is running. Make sure you don’t get any null references or out of bound errors.
  2. Try to make your code run twice, to make sure it does the same thing the second time – it’s a common source of problems.

Debugging

No matter how pro you are, you’re going to write bugs, and then you’ll have to fix them. But there are ways to avoid the worst of the frustration in debugging.

• First, use the “rubber duck” method. Keep a rubber duck or a Nendoroid or a picture of Chuck Norris on your desk. Once you’ve tried a couple of fixes, pick up your duck/Chuck and tell it exactly what is happening when you see the bug. This is very often enough for you to see the problem. If not, keep talking. Go through the relevant code, line by line, and tell the duck/Chuck exactly what each line is doing. You might find it helpful to write down variable values.
• What you are doing is testing your assumptions about what your code is doing. Are you assuming that you gave a value to a variable when you never did? Are you forgetting to reset some value when you use it more than once? Are you looking for a component or game object that has been destroyed?
• If you’ve given a good effort to solving the problem, don’t bang your head on it. Just ask for help. The game development community is pretty friendly – everyone knows it’s hard, and many people remember how extra hard it is at the beginning. You can start by asking your classmates in this course, but Unity Answers and other sites are also helpful.

To ask for help effectively:

• Search for your question first. As someone who is just starting to work with Unity, you’re likely to make the same mistakes everyone else does.
• Say please, and definitely say thank you if someone responds, even if their answer isn’t what you were looking for. It’s only polite.

Here it is – the moment where you start working towards your first milestone, the vertical slice. As you saw in the video, this is a small slice of gameplay that captures the core of your game across all the parts of development: programming, audio, art, and game design.

The vertical slice is a very important milestone, so you’ll have more time to build it. And this is just Vertical Slice - Part 1, in the next project you will create another version of your vertical slide, using what you learn in this project and next project to get you even closer to a building your functioning game.

This assignment, representing the halfway point of your game development process, will be the first time you’ll create a a build of your game. To get the most out of this course, look at a fellow learner's sprints and vertical slices and do a quick check-in about whether they seem to be on track. In the following week you’ll turn in your official vertical slice build.

This is the final assignment in this project and you will use the feature list and CRC cards you created in precious tutorials to create your first vertical slice.

Review the backlog you created and make a final decision on what you will include in your vertical slice. This is an important moment for you as a designer – take your time and identify the core of your game. Then make a short list of the features and assets you will need. Put a priority (1, 2, or 3) next to each one.

Do a final review of the CRC cards assignment in this project and finalize your coding plan.

Reality Check

Look at your project, and look at your feature list. How many of the features are currently visible in the game? How many of the needed assets have you found or made? Do you feel halfway done, or do you already feel behind?

This is a moment to be ruthlessly honest with yourself. If you’re not going to finish the game you planned, then you’re not going to finish it. You can either accept that now or be forced to accept it a few weeks from now. It doesn’t mean that you’ve failed or that you’ll never make that game.

But it does mean you need to figure out what you can finish. You might need to radically reimagine your game, keeping just a few pieces of what you had planned. You might even need to switch to a new concept, if you haven’t been able to implement a core feature.

This is the last real chance to pivot and still finish a game by the end of the course. Review the digital prototype you built for the last project. Then close that project and start a new one. Remember, you wrote that code to be just good enough – now you’re starting fresh.

Create your Vertical Slice

1. Build as much as you can of your vertical slice. The result probably won’t look like much – that’s okay. Be very careful this week about sticking to your list.
2. Take screenshots or a video capture of your build, including your feature list. If you made a WebGL version share the link.
3. After you submit, give feedback, via comments in the Gallery, to at least 2 fellow course participants.

In the next project you’ll learn about the Agile methodology for making software. It’s the process used by the vast majority of game makers to help contain the chaos of software development and still deliver exciting, well-made games. You’ll then turn another version of your vertical slice.