The last post was just a dump of what I’ve found so far. Here I’ll attempt to distill what I’ve learned
A direction not to go
I discovered through crawling sites about science games that there’s not a lot out there that’s actually polished. The vast majority tends to be flash-esque games that seem like they were built by a budding game developer hoping to up their game dev skills by starting small and simple. I have no idea if that’s the reality, but that’s what it felt like to me. Even the games that were wrapped in a science framework felt flat. They often fall back on old education tropes like quizzes, or matching, or vocab building and either aren’t really games or aren’t really about science. I quickly realized I had to look elsewhere for inspiration.
Leave it to the professionals
There’s a wealth of open world games that encourage experimentation, problem solving, analytic thinking. Minecraft, obviously, but also puzzle games like Inifinifactory, survival crafting games like Subnautica and Don’t Starve, and psudeo sciency games like Spore. The polish on these games makes them engaging. They obviously require hundreds, thousands of man-hours and are well beyond the scope of a one-person thesis project, but they serve as a good point of inspiration for mechanics and ideas. In particular, since I’m building a game maker, a game like Garry’s mod will be really helpful in fleshing out the interface of my tool. But as far as using these games for research, I’m starting to lean away from spending too much time dissecting these games, as what I’m doing is fundamentally different.
Toys, Games, and Constructionism
In comes Seymour Papert, and his constructionist, Piagetian way of thinking about learning. His work led him to create the LOGO programming environment. His work can be seen in countless other tools: Smalltalk, Scratch, Lego Mindstorms EV3, just to name a few examples. They all approach teaching programming in a new way by providing visual or simplified syntax that has an immediate response, whether it be visual or physical. This immeidate response is incredibly valuable as it keeps the student engaged and encourages them to explore more. The more I read about constructionism, the more I learned about a few key tenants. This is taken directly from the wikipedia page for Construcionist Learning Theory:
- The learning activities should be related to a larger task. The larger task is important because it allows students to see that the activities can be applied to many aspects of life and, as a result, students are more likely to find the activities they are doing useful.
- The learner needs to be supported to feel that they are beginning to have ownership of the overall problem.
- An authentic task should be designed for the learner. This means that the task and the learner’s cognitive ability have to match the problems to make learning valuable.
- Reflection on the content being learned should occur so that learners can think through the process of what they have learned.
- Allow and encourage the learners to test ideas against different views in different contexts.
All these tenants come from the following source:
Wilson, B. (Ed.) Constructivist learning environments: Case studies in instrumental design. Englewood Cliffs, NJ: Educational Technology Publications.
I’m starting to feel like a Game Maker is going in the right direction. It provides a larger task, and the activities produce a usable output. The challenge is going to ensure that the cognitive load matches that of the student using the tool.
It’s illustrative to look at a few key products or projects that are in the same vein as my game maker.
The first is a visual game maker developed at Microsoft called Kodu
Kodu is 3D, and while it looks relatively simple, there’s actually quite a lot going on. Understanding how to build a game requires understanding a bunch of technical details: the animation loop, framerates, sprites, bounding boxes, collisions, events, inputs, logic, and the list goes on. It’s a lot to throw at a student who’s never really used a tool like this before. Kodu attempts to abstract that all away, but also seems to give pretty granular control if you want it. It’s a really nice looking tool.
So how will mine be different? Well, I want the focus to be on the science, not the game making process directly. Thus, I want to abstract away much more than Kodu does. The tradeoff is a tool with much less flexibility that can only make certain kinds of games. But that’s what I’m aiming for. If this is a game maker tool to teach kids about physics, then it doesn’t have to concern itself with games that aren’t primarily physics based. Thus, a lot of features can be left out. A lot of flexibility can be sacrificed. Ultimately, it’d be great to have a more flexible platform, but in terms of scope and time, it makes sense to focus on one particular subject as a proof of concept.
It differs in other ways as well:
- It’s browser based, meaning it can go anywhere, to anyone, at anytime.
- It’s 2D, so the complexity of 3D thinking is removed, and the focus is on fundamental principles, not full featured games
- Students can save their games and share with friends, adding a layer of social engagement
- It can be paired with a curriculum to teach specific physics concepts, like momentum, velocity, gravity, mass, and friction