Gamestar Mechanic Teacher Blog

All posts by luke

Gamestar Mechanic as a Pathway to Programming


Posted Jul. 13, 2012

CategoryGaming Education

In addition to interning full time on Gamestar Mechanic’s recently launched Summer Online Learning Program, I’ve been poking around on Unity, a popular 3-D game design engine that requires some basic programming knowledge. As I started programming my very first game, I realized that the game design concepts I had learned from working on Gamestar Mechanic the past two summers were proving to be invaluable. Huh? How does Gamestar Mechanic, an engine that doesn’t require programming from its designers, help you with an engine like Unity?

Bring it on, Unity. I’m not afraid of the word “boolean.”

As much as I enjoy it, programming can be a long, arduous process. This makes it really important for me to prioritize my programming tasks. As I’ve learned in Gamestar, you can spend quite a bit of time making your game look pretty, but if the core gameplay isn’t fun, then you might have to scrap the whole project.

In Unity, I could have spent a month programming the water in my game to flow in an ultra-realistic manner. But if the core mechanic of my game – fighting zombies – wasn’t fun, nobody would care about the tiny details of my game. Thus I decided to dedicate my programming resources towards making a prototype. In this prototype, I focused on making a combat system that was fun to play and required strategic decisions from the player.

I suppose the word “strategic” doesn’t mean much in zombie games.

In addition to the concept of prototyping, Gamestar Mechanic taught me how to dissect games through the elements of game design. Thinking about the element of space, I looked at my game through a critical lens: what is the space of my game like, and how will it affect the core gameplay? I realized that most of the combat in my game will take place on a raft, which is a flat, wide open space.

This type of space doesn’t always lend itself well to combat (see my previous blog post about Game Design Pitfalls to learn about why!) This led me to two game design decisions: 1) create a fairly robust combat system with attacking, parrying, and dodging; and 2) give the player the ability to customize and upgrade their raft into a full fledged boat. With different floors, compartments, and objects, an upgraded boat would make for a much better combat space than just a simple raft.

When I look at this screenshot, I’m often comforted by the old maritime proverb: every great ship starts off as a simple plank of wood… I may have just made that up.

As you can see, my game is still in its early phases. But because of my experience with Gamestar Mechanic, I’m confident that my time has been well spent. Have any of your students tried programming before or expressed interest in programming because of their experience with Gamestar Mechanic?

Common Design Mistakes Made By New Gamestar Mechanic Users


Posted Jun. 04, 2012


As a sophomore in college last semester, I had the pleasure of running a game design afterschool activity using Gamestar Mechanic at a local middle school. While I was consistently impressed with the work of my students, I noticed some common themes in the types of design mistakes they would make. I’ve learned from talking to the folks at E-Line, as well as browsing games in the Game Alley, that these mistakes weren’t just specific to the students in my activity: they can be found among many new Gamestar Mechanic users. Let’s delve in to what these mistakes are and what you can do as a facilitator to identify and help pull your students out of these design quagmires. Hopefully, you will find that the instructional framework prescribed by this post applies to any design issue you may encounter.

Game Design Pitfall #1: The “Spam” Shooter

Chances are you’ve seen this type of game before: the player can blast away from a safe and cozy spot, perhaps surrounded by blocks or at a safe distance. Meanwhile, a herd of enemy sprites is constantly moving in and out of the avatar’s line of fire. As a facilitator, a nice rule of thumb to follow is that if you can beat your student’s game with one finger and your eyes closed, then it isn’t requiring enough engagement from the player.

Those poor enemy sprites never even stood a chance.

It’s been established that these types of game aren’t challenging enough to be much fun. But then why do kids make them? One likely cause for this design tendency stems from the desire of students to make games in which the player dominates hordes of enemies. Speaking as a gamer myself, this is an understandable sentiment. But as a facilitator, it would be ideal to remind your students that what’s fun about these games is not solely the blasting of enemies, but rather the overcoming of a difficult challenge.

A more practical explanation for why students create either repetitively or randomly moving sprites is that these are the default behaviors for each sprite when it is placed into the game environment. It’s possible that encouraging your student to explore the various sprite settings via the wrench tool would help alleviate this particular cause of the problem.

So you have helped your student identify that his game could use some added challenge, and maybe you’ve even psychoanalyzed his gaming habits in order to identify the root causes behind his designing behavior. Now it’s time to salvage his design project. The first topic to broach with your student involves the components of his game. You may want to ask the student about how the behavior of his enemy sprites is allowing the player to just sit back and relax. You could also ask him to consider the advantages and disadvantages of having many enemies that are easy to defeat vs. utilizing a select handful of enemies that are more challenging and impactful to the player.

Perhaps the most glaring issue with this student’s game is his use of space. It would be useful to have the student consider how the wide open environment of his game is resulting in the player being able to defeat every single enemy without even moving. If the student is keen on adding more blocks to his game, but isn’t sure where to put them, you could ask him about what kinds of spaces make it challenging yet fun to blast and defeat an enemy.

You could also ask him if a fragging goal is appropriate given the state of his game. If the enemies are located in a position that makes them too easy to defeat, then perhaps a goal that doesn’t involve destroying them – such as point collection – would be more fun.

While it is unlikely that suggesting a rule change to this game would affect it in its initial state, if the student has added additional challenge to his game via the aforementioned methods, you could consider discussing the rules of his game. You could talk to your student about whether or not the presence of a time limit would force the player to come up with more efficient movement and blasting strategies. Likewise, if the player doesn’t appear to have concern for his safety, then a more strict health counter would encourage the player to develop better evasive behaviors.

Okay, so it wouldn’t be my final submission to the National STEM Video Game Challenge, but this game has definitely come a long way.

Although this framework involving components, space, goals, and rules was applied to this specific design pitfall, it can be extrapolated to other design issues as well. A major theme of this approach is about helping your student become in touch with his intuition about whether or not his game is fun. Facilitators who aren’t necessarily gamers should especially feel free to employ this framework when trying to help their student solve a design issue. For more information on topics such as space and adding challenge, check out Lessons 7 and 10 in the Gamestar Mechanic Learning Guide.

I’m also curious if there are any trends you guys have noticed in your students’ games. Feel free to comment below if there’s any design issue you would like to see addressed!