Learning computer science can be a foreign endeavor due to it’s structure and language. Like learning any language and it’s associated logic structure, it is important to make the topics in computer science a tangible experience. When learning computer science concepts are access through the different modalities according to the Universal Learning Design (UDL), the learner is able to make connections and associations between the abstract concepts and the synonymous experiences. As a middle school game design and development teacher, teaching game development is a great way to make these computer science concepts come alive as they see objects interact with other objects when a particular programming structure and algorithm is applied to it. Yet in the Spring of 2018, our STEAM:Coding faced a limitation in their capabilities in creating their game. They expressed a need to learn the GameMaker Language which is very similar in structure as Java and C#.
Because of this need, over the summer of 2018, I scrapped my STEAM:Coding curriculum and rebuilt it so that it was grounded in learning the programming language and programming structure.
In my last curriculum, I used the GameMaker Apprentice book, which provided many examples of games that students can make. Though after a while it felt like a passive recipe book that our students are not really learning and thinking for themselves, rather they are following direction step by step. After a while, this learning structure becomes boring and our learners will want to challenge themselves by applying what they know. I want my student to start not only remember how to do things but making choices in using the vast number of tools that they know. Though drag and drop has it’s place in making sure student develop prototypes rapidly, giving our students an experience close enough to what they will experience in the the industry will prepare them for the industry and will give them a head start when they transition into high school computer science.
I felt the best way for our kids to learn how to use a language is to actually program a game, especially game structures that they are familiar with and that I have interest in as well. I also encourage programming games with complexity as teaching our kids how to break down bigger game constructs into their essential components needs to be modeled so that our learners know how to divide and conquer these tasks. If you are familiar with old school Zelda, our students are making a top down role playing game. To some of you, it might be an easy task to make such a game from the perspective of a player. There is a preconceived notion that making a game is an easy task until you start breaking it down piece by piece and day by day. This can turn off some of our students who will not see the big picture until 6-7 months later when the game has been developed. As a programmer, designer, developer, the game is so complex, that one will need to be systematic in dividing and conquering each components so that each component that is built connects to other components. That is when our learner get the reality check that making games is actually hard work. It’s just like making a building from scratch.
From an outside teacher point of view, one would ask, “Is there an existing curriculum for this long term project based learning experience?” All I can say is I’m current in the depths of prototyping it and also adapting existing material into my current context. YES, it is a lot of work creating this from scratch and designing instruction based upon student need. It’s definitely an eye opening experience because I’m seeing our kids immersed in the challenge as they want to learn the structure and language. I see them persisting, immerse in creating their own mental models on how this process works, asking questions to me and to each other, accessing their resources online, and testing relentlessly and iterating. The process of learning always precedes the product.
The best way teach this complex games structure is first build it yourself. Take the place of the student so that you know what your student experience. I’m currently making a role playing game in my software engineering class as SF State. Just like setting up for a lab in a science class, it is good practice to try out the lab yourself as you will see the places where your students will get stuck in. On the other hand, I’m also pushing myself to learn programming structure that I haven’t experience to enhance the features of the game that we are making. If you are interested in this journey, check out my weekly blog on developing a RPG Game in our software engineering class. http://www.teamaringo.org/STEAMblog/category/computer-science/
Moving forward, I would like apply some scaffolds so that learning a programming language and structures are reinforced through more formative assessments and more opportunities for checking of understanding. I would want my students to make programming language and structure dictionaries so they refer back to this toolkit. I would change up my screencasts so that it would show students how to do something rather than copying my process. I want my students to apply what they learned to a different situation. Next year, I want to expand this curriculum so that it includes arrays so that student can store items in inventories, select items, and use them within the game. (I’m still trying to figure that out at this moment.)
Through this process, I find it rewarding because I’m learning this along side with the students. It’s great learning from my students, having my students teach other students, and having my students learn from me. At the end of the day, it’s definitely changes the culture of my classroom into a culture of mutual learning.
