Things I Learned Teaching 2D Unity Game Design to Kids this Summer.
I recently finished teaching a series of weeklong 2D and 3D game design courses in Unity. I’ll talk about the 2D course in this article.
The first class I taught had six kids in it. All boys ages twelve to fifteen. We advertised the class as Advanced 2D Game Design in Unity for kids ages ten to sixteen(over the time we taught this class, the youngest student we taught was ten and oldest was twenty-nine). The big selling point was that we would make a simple Angry Birds-style video game. Kids go crazy for that.
The class was an hour and forty-five minutes each day for five days (Monday-Friday). Monday and Tuesday we created the 2D UFO game in Unity’s tutorials. Wednesday and Thursday we created the Angry Birds clone. I ran into some trouble with that. The tutorials were widely available, but the assets were deprecated and no longer available in the Unity Asset Store. I did some digging and managed to find them, though. Friday, I would show students how to put Unity on mobile devices, add soundtracks, add extra levels to our games, create 2D animations, and I would answer their questions. We also made a simple platformer (like Mario) one Friday and we did the 3D Roll-a-Ball game on others.
I took existing tutorials and I stripped them down to their simplest elements and put them in a format any child could approach. They were simple to begin with, but seem like a behemoth to approach without guidance. With my help, about thirty kids were introduced to Unity and came out of the class with a portfolio of three games. Pretty awesome.
Back to my first class, our test run: I learned a lot. We put our capacity for the class at twelve students, but really, six was a lot. It would have been easier with a projector or something that allowed me to really blow up the projects for everyone to see. We were all crowded around two tables and had a large separate monitor for them to squint at. We eventually moved up to a 42" TV and that helped, but really we needed more.
Students vary in skills.
The students who had strong typing skills were at a clear advantage. Those closer to the monitor or TV were at an advantage. Those with more powerful computers were at an advantage (we made students bring their own computers so they could learn the full installation process and continue their work at home).
Some students were not very good at following instructions. One thing I do not like is when students ask, “Is this right?” My responses vary, all in good humor, but I encourage students to follow instructions, trust in their work, and then work out the bugs if there are any. There simply wasn’t enough time to indulge students each time they performed a single simple action and wanted me to confirm it was correct.
Students learn a lot from their errors.
One of the biggest things my students take away from class is: how to read errors. If they can read the errors, most of the time they can fix the bug on their own. It can take a good amount of time for me to go around and check each student’s C# script when they have an error so teaching them how to read errors was a good time investment at the beginning.
Sample interaction with less motivated students:
Student: It isn’t working.
Me: Do you have this? *Points to solution on the TV*
Student: Yes, but it isn’t working.
Me: If you had this, it would be working. Your neighbors each typed this and theirs are working so you don’t have this. Go line-by-line until you find the error.
That may seem a little harsh, but it was so good for them. C# can be a bit finicky if you don’t have things EXACTLY the way they are supposed to be (capitalization, semi-colons, curly brackets, etc.), so drilling them and challenging them to fix their mistakes made them better. The best part of this was seeing them put together the last game on the final day. It was very rewarding to see the leap in skill and confidence after just a week. If they have the desire and drive, they can go on to do great things. I told them so, frequently.
The next class we taught, I was able to iron out a lot of the details, had a sense of where we should be at the end of each day, and had a better idea for how to instruct them on the subject of 2D Game Design in Unity.
This class had three students. All girls, a ten-year old and twins, fourteen years old. I was BLOWN AWAY by how much more skilled these girls were than the boys. They followed instructions better, typed better, had less crap and therefore better performance on their computers. They finished early every day and we always had time to play and experiment with our games. The girls were way more active and ready to make changes and play with code and other aspects of their games. It was really impressive.
Why the heck don’t we have more women in the game design and software industry? They kick butt at it!
That class exceeded my expectations and I took notes to allow for adjustments in the curriculum.
Next Several Classes.
The next few weeks, the classes varied. Nothing really interesting to note. They loved the class and wanted more. I started making plans for other variations of my 2D game design class so we could retain those students who loved it so much.
One thing I learned a few weeks in. You have to teach some students how to learn. When students tried to do what I was doing while I was doing it or explaining it, they usually ran into bugs, missed a step, or fell behind. Often there are several small, quick, and related tasks that take forever to do individually and should be done in sets of three to five. I had to help students not fall into the trap of over-eagerness by giving them a process to follow.
There were three steps:
- I will do, you will watch.
- You will do.
They weren’t allowed to touch their computers until I told them it was their turn to “do.” This increased the speed of the course, the students retained more, and fall-behinds were virtually eliminated.
Another rule of mine was that they needed to follow exactly what I did during the instruction period, but after, they could experiment to their heart’s delight. I think making changes to both the game and the code is critical to really retaining and learning programming languages and game engines, so I don’t want to stump that, but I also don’t want to help students fix their messes at the expense of everyone else who is ready to go on to the next step. So that rule was good. Everyone was able to do it the right way, then experiment and I would help them fix it if things went crazy.
The Final Class.
The final class of the summer was a bit interesting. There was a wide skill gap in the class. Two students, each fourteen years old, with decent typing skills, struggled. The other three students were very skilled, learned quick, and didn’t need much guidance. One had gone through the local college’s game design program already, but wanted some “one-on-one” to learn 2D in Unity.
Because of the skill gap, the three highly skilled students finished their tasks right away while the other students often took several minutes longer to complete the same tasks. This resulted in the three students getting bored sometimes and falling behind because they would experiment and break something.
If we had some sort of screening process to match students by skill-level (by “skill level” I really just mean typing and the ability to follow instructions without much assistance), it likely would have been a better experience for all.
Overall it was a great experience and I really want to develop and teach more Unity game design courses. Kids are great and seeing that moment when it “clicks” is just incredible.
Having someone actually there to walk you through these things appears to be a great value to parents in the community. I think anyone with a strong desire can pick up Unity 0r most game engines and programming languages if they work hard, have patience, follow tutorials, and experiment. But there’s something about having someone there in person in a small classroom setting that makes this mountain seem climbable.
Thanks for reading.