Tuesday 31st July 2007 2:09 pm
Greg Trefry: A Shared Learning Process
Concluding our series about Games and Learning, Project Manager Greg Trefry talks about what he’s learned from the games kids have built with GameStar Mechanic and how the project is making him re-think some of his own preconceptions about game design.
As the project manager for GameStar Mechanic it’s fascinating to read the previous posts about the project. Seeing all of the results from the testing distilled, I’m struck by the how much the experience of kids using GameStar to build games mirrors the experience of the production team building the game. Just as they went through struggles with initial design steps, throwing every element at their disposal into their games before coming to a more balanced approach to making fun games, so have we. Granted, we’re working on a larger scale than our young compatriots, but I see remarkable similarities between their learning process and ours. The process of building GameStar Mechanic has forced me to re-evaluate many of my preconceptions about game design, experience design and even design in general. I guess you could say GameStar has helped me think like a better designer too.
When we set out developing GameStar Mechanic we were fortunate enough to have a very strong vision and theoretical core to build the experience around. We knew we wanted to build an experience that helped students learn the process of game design. And one of the first crucial decisions we made was to couch that experience in the form of a game. This decision has guided our thinking from that point forward.
A Flexible Design
As we began creating technical specifications for the GameStar prototype we focused on making the game as flexible as possible. We wanted every element of the game to be modifiable. More than that, we wanted players to be able to endlessly recombine elements and actions within the game. We wanted players to be able to turn a block in the game into an enemy by allowing that player to adjust the parameters of the block, making it cause damage, giving it a movement pattern. This sort of limitless flexibility is very hard to produce in software. Software tends to be better at producing elements that do specific things. But through some ingenious programming by our lead programmer, Eric Socolofsky, we were able to achieve a remarkable degree of flexibility. This combined with some visual wizardry by our artists, Kyron Ramsey and Phil Weber and we soon had a powerful little tool.
After several months, we had an editor which allowed us to make some great little games, as well as build some very crazy, bad games. It was easy to make fun games, but it was also very easy to make incomprehensible, broken games. It was at this point we had to begin consider how to craft the elements at our disposal into a tighter experience. If the system was too chaotic, it would be hard for users to pick up the strands and find a way through the game. Much like the kids filling every square of the board with a different creature, we had thrown everything and the kitchen sink into GameStar. It was time to start editing.
At this point we began locking down features. No longer could a block be given the same properties as a shooting enemy. That ability was interesting, but confusing. Instead we began to think about elements in the game having intrinsic properties within the system. A block was a block. You could make it move, you could even make it damage things, but then it had to look like it was going to move and damage things. A game needs to have an underlying grammar so that people can understand it. So giving elements intrinsic properties was a way of beginning to build a grammar. We worked to keep the grammar simple so that kids just coming to the game would be able to start building games right away. As Katie wrote, we wanted to steer clear of applications which taught programming more than they taught design. Yet we wanted to leave enough flexibility so that kids could feel creative.
Building a Shared Language
As we’ve moved forward with the project we’ve crafted the language and way we talk about the game, both in a game design context, but also in software design and curriculum design contexts. We’ve developed our own specialized language for how we talk about building the game, for example referring to the elements within the game as “creatures.” We’ve integrated this language with general language about database tables, iterative game design and agile software development. This allows us as developers to understand each other.
And like the kids designing games with GameStar we get very excited to see how people use the editor. It’s been educational, not to mention inspiring to see the games kids have built. Playtesting is an integral part of game development. And having extensive testing done in parallel with development has been hard at times, but always educational. It has really helped inform the design and development process, allowing us to learn about how kids learn by making games.
Fortunately, I’ve been able to sit in on a number of the Ross School workshops and observe kids as they learned to make, share and refine their games like real game designers. Judging from these parallels, I would say that we’re on the right track.It’s this system of designing, sharing and feedback we’ve experienced with building GameStar that we really feel is important to share with kids.
Category: Ecology-of-Games
Like this post?
- Email this page using tell-a-friend, or
- Save it with one of these social bookmarking tools:
, or - View author profile for Greg_Trefry.
