Before the long blog post reflecting & dissecting how this all went, here are the final projects from my students if you wanted to play a few of them first. They’re pretty cool.
This is my second year teaching an introductory Computer Science class, mostly following the curricula provided by Code.org’s CS Discoveries class. Last year I followed the curricula pretty faithfully just to get my bearings; this year I’ve branched out a bit. Reflecting on how things went last year into this year, I know one area I really wanted to improve were the outcomes from the Game Design unit.
Unit 3 of CS Discoveries culminates with students creating their own games in Code.org’s Game Lab environment. Last year, I used the final game project as the final exam for the 1st semester of the course. It worked fine as a first semester final, but I was pretty disappointed in the games that my students produced. The technical ability of the games were mostly fine – they fit the rubrics provided and used many of the coding concepts I was looking for – but the games themselves were… generic. Knock-offs. Uncreative. Several of them were barely adapted versions of the practice games embedded in the Code.org curriculum. Others attempted to be knock-offs of known game properties (like Mario or Final Fantasy) but, since my students didn’t really understand the complexities of how build games in a scaffolded manner, many of these games were half-finished and not really playable.
I also had several games that were just… dumb. Immature. Full of inside jokes and meme references that are maybe fun for a small group of people to play but don’t have any broader appeal. I didn’t do a great job last year of having students consider audience and planning why someone might want to play your game. These are supposed to be fun for other people to play, not fun for only you to play or fun for you to watch someone else struggle with your game because you made a bunch of unsolvable levels full of weird jokes.
I knew going into this year that I didn’t want to play 5 versions of the same knock-off game again and I didn’t want to play games full of memes that isolated the player just so the creator could laugh at their own inside joke. I wanted to make a conscious effort to try and have students think about how to make their games unique and different and to have some sort of personal ownership in what they were creating. I also knew that I wanted to adapt the rubrics and presentations of these games to emphasize these points – force students to have some sort of creative ownership over the code they created. I also knew that I needed to do a better job of preparing students to scaffold their development: that they should pick several things to work on and get ‘just good enough’ to be playable rather than pick a single detail to spend all your time to get perfect but the rest of the game isn’t playable. So, here’s what I tried:
Game Design Is Personal & Creative
The first major adjustment I made was designing a day of instruction where I intentionally re-framed what it means to design a game. Up until the final project, students have mostly been creating partway-started games that either I gave them or are embedded in Code.org lessons. As we approached the final game, I knew I wanted to create an explicit break from thinking of game design as just repacking and recreating work that someone else has already done. Even though your game will probably have mechanics that you borrow or steal from other games, there’s gotta be something about your game that makes it stand out. To really prove this point, I designed a series of videos and reflections to get my students thinking about this. Its probably the lesson I’ve spent the most time planning this whole year – carefully planning out my questions, my transitions between videos & prompts, figuring out what discussion points I wanted to surface – really zooming-in on a micro-scale all of the things I wanted my students to take away from it. Here’s how that went:
I started by having them brainstorm all the types of games we’d made so far throughout the course – platformer games, avoider games, collector games, etc – then suggesting that all of these games are all kind of… boring. No one is leaving class running to their friends saying “Look at this game I made where an alien stops ladybugs from eating cake!” I compare this to seeing a really generic action or comedy movie – you may sit through it and use it to pass the time, but you’re going to forget about it as soon as you’re done and no one really cares about it in the long run. Instead, it’s the movies with a bigger message or a personal touch that are more interesting and last longer in our cultural memory. I use Pixar as an example of this – a movie studio that consistently creates truly memorable and touching movies that are also full of action or drama or comedy. I show about the first minute of this clip of Pete Doctor talking about how he creates stories for Pixar movies (from the totally awesome Pixar In a Box series on Khan Academy). I latch onto this idea of “go ahead and write about explosions and monsters and car chases, but put something into it that talks about your own life” and basically use this as a refrain for the next two weeks when working with students.
Then I show the first minute or of the trailer for the movie Indie Game. I love how each of the game designers talks about how personal their games are and how connected they are to them – and, connects the ideas of the Pixar video to this Game Design we’re about to do. I make this a big deal – that making a game is deeply creative and deeply personal. I think trying to reframe games in this way is a big deal especially considering the non-traditional students in my classroom who may have just been ‘placed’ in my class for scheduling reasons or who aren’t super interested in this whole “let’s make games” mentality. Not everyone in my room may be able to relate to “let’s all recreate the videogames we love to play in our spare time”, but hopefully most students can relate to “let’s make something creative – but instead of a story or drawing, it’s a game”.
Next I showed them a middle section of this clip of Pixar artists talking about how they find inspirations for their stories, then they do a quickwrite of all the interests, hobbies, struggles, and memories they can think of in 5 minutes. This will become the basis for whatever they may want to use as their personal inspiration in the game they want to make. Now we look at a bunch of games that my students probably haven’t heard of, but were designed with similar starting intentions. Importantly, pretty much all of these games are things my students could make with the tools they have. In fact, as we look at these, I ask them to predict what blocks they would need to re-create this on their own.
- I show another clip from the movie Indie Game – this time, it’s Edward McMillen talking about how he used game design to overcome his own personal fears and phobias (between minutes 2 and 3). I like that the clip is kind of emotionally heavy – my hope is it gives my students permission to use real things from their personal experiences as influences in their games.
- I demo the game Elude, which was created as part of a research study on depression. I like that we can actually play this game and, as we talk about the mechanics, I emphasize that my students already know enough to create this game and there are game design careers that exist outside the world of “games as entertainment”.
- We watch this video about Andrea and Sophie who created the game Tampon Run (I show approximately the first minute and the last minute) and we play the game for a little while. I did a lot of mental prep and overthinking on how this moment would go in my class – I think it’s really impactful to hear their story and see that the game is totally within the ability of my students, but it was hard to predict the reactions to this sequence given the maturity level and gender balance of my classes. This section of my lesson didn’t have a lot of audience participation – we watched the clips, then we started playing Tampon Run where I read out loud the introductory slides written by Andrea & Sophie – and, after we played the game, I made a big deal about the fact that the game itself is actually very simple but became a huge deal because of the larger issue these students were raising by creating the game. That was the thing I emphasized to take away from this demo – that with a broader message, a simple game can become something bigger.
After looking at these other games and reflecting on them, I have them pick one of the items they wrote down from earlier to use as the basis for their game and, as an exit ticket, they have to turn in a paper describing what theme they want to use for their game – what personal spin they want to infuse in their game. This became the basis for pretty much every design decision my students wanted to make later in their process. It also made it easier to cut off stupid decisions that my students wanted to make about their games – like wanting to include references to memes or make an ‘unwinnable’ level – having this day to refer back to made it easier to talk about audience and intent and personal ownership in a way that led to a lot less of these types of decisions.
I can’t know for sure, but I think this day created a larger ‘buy-in’ from my students who may have been otherwise disappointed or disillusioned with 2 weeks of “make your favorite video game”. Framing this as a personal and creative outlet, and connecting game design to other career fields and intents beyond just entertainment, seemed to make a difference. I also hope that it challenged some of my students who thought game design was somewhat mindless and one-dimensional – that it challenged them to expand their thinking of what a game could be, the audience it’s serving, and the type of people that create games. My students who were most excited about making the “my favorite most intense best video game ever just like….” seemed the most reserved during this day, which I think (I hope?) is a good thing to have that particular mindset challenged and expanded.
Minimum Viable Products
Another adjustment I made before starting in and making games was we spent time talking about what it means to create a Minimal Viable Product. Last year, I had students who didn’t really know how to think about designing a game – they would start with making all the sprites first or mapping out all the levels – but, when it came time to turn in their game, they didn’t really have anything completed enough to show as a result of their work. I had done a poor job of preparing them as game developers and showing them tips and strategies for incremental game development.
So, I planned a lesson all around the idea of creating games incrementally and planning for a Minimal Viable Product. We started by watching this time-lapse video of someone making the game MetaGun from start to finish as part of a Game Jam competition. As we watch it, I ask students to notice how long it takes for the person to create the first ‘level’, then how much longer it takes to create the ‘second’ level. I also ask them to notice when the creator first starts using sprites. We only watch about half of the video since my goal is to point out that the design process actually starts out with a lot of testing and creating the mechanics before focusing on the ‘levels’ or animations.
Using this as an anchor, I show them the graphic above of how to think about developing with the Minimal Viable Product in mind. We have a discussion about what aspects of the video we saw would map onto these different MVP stages – like starting with just moving a box around, then having it collide with things, then having enemies appear, etc. After getting an idea for what an MVP might look like, we shift gears a little bit and they start doing some research into what game mechanics they may want to steal and use in their own games. I give them this document on Google Classroom to work through, and I encourage them to visit the Game Lab public gallery and the Scratch gallery to look at games and get some ideas for what they may want to do. Importantly, I have them think about what a previous version of each of these games might look like, hopefully training them to break down larger game projects into smaller, workable pieces. I spend most of the class period circulating and having conversations about MVPs.
After these first few days, I set students loose to start working on their games and implementing their ideas. I have them work in the full Game Lab environment so I can take advantage of the ‘Remix’ button that’s available. Every time they reached a ‘playable’ state of their game, I had them remix it and add a new version number to their game – in essence, I’m introducing them to version control in a very naive way. I was pretty happy with how well students latched onto this – here’s an example of versioning that a student did completely on their own:
- Version 3 – The character can move and jump
- Version 4 – the obstacles move and collide with player
- Version 5 – the score works and the jump is a little more smooth
I also had stacks of this Version Planning guide available for students and myself to use throughout the process. Students didn’t use it independently as often as I would have liked, but I used it every time I sat down with a student to start talking about and planning their game. Or, if a student wasn’t sure what to do next, I would grab one of the papers and tell them to start sketching and planning it out on paper first. It was also nice to have multiple copies, so if a student had too lofty of an idea, we could break it down into multiple versions with multiple pieces of paper. It was also a nice tangible metric for both the students and myself that they were making progress – working on a single game for 2 weeks is a long time and can get kind of stale, but continually checking off versions and having the stack of tangible completed sheets did a great job of making it feel more manageable.
If my goal was to have games that felt more authentic, more appealing, and with more student ownership: these adjustments definitely worked. I had lots of some really cool games with really neat stories behind them. I think it helped that I gave students 2 and a half weeks for their projects, that I required them to have all original sprites (either hand-drawn, or taken from the internet and remixed in a significant way), and the project culminated in a ‘Game Expo’ that added a bit more pressure:
Rather than have students rotely turn in their games, we spent our 2-hour finals day putting on a fake ‘Game Expo’. Half the class were ‘developers’ with their games setup at different computer stations with sheets of paper explaining the background of their games and how to play, while the other half of the class were ‘participants’ walking around playing their games. It was really cool to see students showing off their work, describing their code, and genuinely having fun playing each other games and giving positive feedback. Definitely a more impactful way to submit the final project and have a semi-realistic experience of demoing your game to an audience.
Here are all of the games, but here are some of my favorites:
- The Custodian – use the arrow keys to move the custodian around the maze. Avoid the Trash Monster (hint: it moves in a set pattern). Sweep up the trash into the trash can. Once your score reaches 7, a star appears – touch the star to power up. Once powered up, you can defeat the trash monster and sweep it into the trash can. The game ends when both the trash and trash monster are removed.
- Lakeview – Use the arrow keys to move around and follow on-screen instructions, interacting with the environment. This student went out and interviewed friends and family members, asking them about their “worst” and “best” qualities. Each character in the game represents a real person initially displaying a negative quality – your goal is to interact with the environment and unlock their positive qualities. It’s not finished, but this is a game where I feel like my “game design is personal” lesson really took hold. The game isn’t finished yet.
- Ocean Pollution – Use the arrow keys to move the fish. Collect the gummy worms, avoid the ocean pollution (trash bags, plastic, oil spills). When your score is a multiple of 10, the speed increases. Before starting this project, this student already knew the mechanics he wanted in a game – some sort of collector / avoider game – but after the “game design is personal” lesson and listing out interests and struggles, he realized he could connect it to ocean pollution to make it unique. So that’s cool.
- Ocean Depths – use WSAD to push your submarine around the ocean, avoiding the sea monster at the bottom. Avoid the obstacles that try to push you down towards the squid monster.
- Trash Shurikens – Use WASD to move the character. Avoid the black flying enemies. Collect white paper trash, then click the screen to fire the trash in that direction. You can only fire once you’ve collected some trash. In the initial level, you can land on different branches of the tree. After passing the training level, the real game starts and it’s SO HARD.
Some Final Thoughts: Compared to last year, I’m really happy with the level of creativity and personal ownership my students had over their game. This actually feeds into other big-picture thoughts I’ve been having about my computer science sequence as a whole – about balancing creativity and ownership versus technical knowledge and career-ready skills. I sometimes feel pressure from big-picture, top-down initiatives to focus on the latter in my classes rather than the former, which is what I feel like I did last year to mixed results. I’ve been reframing this first-year course to be a lot more about creativity and personal ownership (as in: once my students leave the class, do they feel empowered to return to these skills on their own possibly as a hobby or for their own personal curiosity) and I think everyone, both students and myself, are liking it better.
Sure – I’d love for my students to continue in my program to my 2nd and 3rd year classes. And maybe eventually my students will be prepared for internships or dual-credit classes. But for the majority of my students, this intro class is the first experience they have with computer science and many of them are not here for the long-run – they’re trying it out, or the course just happened to fit in their schedule, or they need the credit for graduation. Hammering in on specific skills because “you need to know these if you want a career in this field!” seems more and more like a losing proposition in this intro class and with my demographic of student. I feel like I’ve had more genuine learning, more buy-in, and better odds at recruiting students for my next year classes by reframing my intro-class focus to be about creativity and ownership (do you have your own idea that you can implement independently in this project?) rather than explicitly drilling skills I know they’ll need for my later classes (do you know the difference between && and || on this quiz?). I don’t need them to be masters by the end of this class – I’ve still got time for that in the other classes in my program. Anyway – that’s where my head is right now in a big-picture sense.