The other day, I sat down with a student in my Unity class to review some course material and answer some questions. They were wondering why their code wasn't compiling. Their code looked something like this:
I have a lot of training as a writing tutor -- I've read hundreds of essays with misplaced commas, awkward sentence structures, and strange word choice. Grammar and spelling was important, yes, but what was more important was whether the student could communicate their ideas somehow. I think this code snippet was a case of a student knowing exactly what they wanted, but not knowing what the computer would accept.
Here, I could see they learned many details of coding: the fact that you must use the "new" keyword when constructing a Vector3, or that you would use a "+=" operator for an ongoing change across frames. Even Line 4, where the student added "= true", sort of makes sense; if you set something to true, it will happen, right? The meaning of the code was clear.
The worst thing you can do, as a writing tutor, is to point out each error sequentially as you read, all at once. Saying, "don't put this comma here," or, "capitalize this," one correction after another, is ineffective in my experience. The reasoning behind these errors quickly gets lost, and you devolve from a tutor to a copy-editor. Instead, it is best to practice correction in passes, and knowingly push your student toward failure, to model the creative process. In game development, there's a motto that goes, "fail as quickly as possible." We must put that into action.
I identified "cube_move" on line 4 as the most pressing conceptual issue. We had already written countless scripts in-class using transform.position to move things; why set something equal to cube_move? I pulled up a script from lecture, and pointed this out, and also pointed out that the Transform component holds the position data, as we see in the Inspector, etc.
Now let's save and go back into Unity.
... and find out it won't compile, still. So let's look at the error console, and it turns out there's something about line 3? Okay, so let's look at line 3, and use "greater than" instead (but I didn't explain why; that'd derail the debugging process) and remove the semi-colon, which we don't need after if() statements.
Now let's save and go back into Unity.
... and find out it still won't compile! We look at the error console again, this time something about line 4. I point out the line number in the error. Even if we don't know what the complaint is, the line number is a clue for where to start looking. Then I explain that you do not have to put "= true" at the end of every line for it to execute. (The student was relieved.)
Now let's save and go back into Unity.
... it compiled, and we press "Play", but nothing moved! Let's look at the code again... Hmm, everything seems okay. If the code seems okay, then we need to consider other possibilities.
Let's go back into Unity.
... and let's look at the actual specific cube object that we want to move in Unity, maybe there's a bug with the cube_move script there... Oh, look, the script wasn't actually there in the first place! That's why it wasn't moving, and now it is! Don't you feel good?
What I'm finding out in teaching game development, increasingly, is that it is much less about "depositing" this domain-specific knowledge into students' heads, of where the semi-colons go and vector math, and more about teaching them to get over it and debug -- to go back and forth between code and game, to test frequently, to become problem-solving goddesses. I give very specific instructions to click on the Console tab, look here, then look there, over and over. Repeat, over and over. Train your error-checking muscles.
I think as experienced game developers / engineers / artists / makers, we don't realize how we've developed strong senses of "vision" -- the ability to visualize and maintain this thing in our head, and gradually work to realize that thing into existence despite countless obstacles. Frequent failure is expected! But this kind of emotional intelligence, to be patient with yourself and your work, takes time to cultivate. People have trouble grasping this if they are new to making things, and maybe it's our mission to help them own their constant failures.
Perhaps teaching game development (or, anything?) is fundamentally about teaching this attitude toward struggle -- to see yourself in the struggle and own it.
(RELATED: "How a Last of Us art dump thread teaches 'vision'.")
