Achievements

Let's talk about Achievements.

Some people love achievements in their games, going out of their way to try and acquire every single one; others care very little for them, and are more interested  in the story/plotline or the actual game mechanics.
But I think they are very few people do who not enjoy achievements at all- almost everyone can appreciate a notification popping up, congratulating you on having completed a task!

 

This makes achievements the natural first option when trying to create game-like educational software. Achievements appeal to pretty much everyone, and have plenty of depth in terms of how they are earned, how many there, and their own tiers/classes.

I'd like to reference a piece from the Gamification Wiki on Acheivements, which you can check out here. It has some great questions to consider for a game designer wanting to incorporate Achievements into a game. Highlights include:

• Do you give Achievements often?
• Have you implemented a place for players to collect and show their Achievements, such as a Trophy Case?
• Do you have an Achievement Map to show the Achievements you have, ones you could earn, and available info on how you can earn them?
• Have you implemented Achievement Tiers such as the common ones like "Easy, Medium, Hard, Insane, and Unknown?"
• Do you use clever names and graphics on your Achievements to add Character? How about humor or wit not only in the names or graphics but also in how you obtain the Achievements?

I want to touch on that last one in particular. Whenever I think of achievements, I think of Xbox's Achievement/Gamerscore implementation and Playstation's Trophies - these two systems have pretty much shaped how I view modern achievements, primarily because they were so smooth, well designed, and the character of the achievements was extremely well done. For example, consider the game inFamous for the PS3. In the game, the player (endowed with the power to control electricity) acquires a power which allows for limited levitation/gliding, a useful ability when trying to get somewhere quickly. When the player travels a certain total amount of distance solely by using this power, the "Frequent Flyer" Trophy is awarded. All of the achievements in the game have some kind of unique, funny, or interesting title, and it's always fun for the player to discover these awards.

 

I can go into great detail about all the different facets of a great Achievement System, but I'll just say a little bit more to wrap up: Achievements are almost always great game elements to incorporate. They appeal to pretty much everyone, and even more so to those players and perfectionists who strive for 100% completion. Collecting things is fun. Game designers have to make sure to not only make the achievements themselves interesting, but the journey to obtain them fun as well.

This will be the first in series of posts describing various Game Elements, such as Achievements. Check back soon!
Peace,
KR

Core Aspects of an Introduction to Programming Game

Just wanted to put up a quick post today going over the most important features an educational programming game should have. These are the aspects of the game most likely to be represented in the final design, are quite broad and general, and are shared among many games already in existence.

The first requirement for this game is the most apparent - the game must facilitate the learning of, or cover over the course of its play, the core ideas and concepts of the introductory programming course. All the concepts and information that were previously taught to the students via lecture slides should ideally be represented in some way, shape, or form in the game (for loops, conditionals, basic algorithm design, critical thinking, etc.). Lesson plans may change with the introduction of this new, gamified medium of learning, but those key topics should still be around.

Next, as in most games, there should be progression. This could be with regards to the levels, in the equipment that a player character obtains, etc. (this will all depend on the actual game of course), but there will be some development. As the student/player learns more and more about coding, his/her capabilities and skill will increase. The difficulty and challenge of the game must evolve along with the player; exposure to more thought provoking programming problems over the course of the game is guaranteed.

Rather than something that should be included in the game, I want to propose that there be a distinct lack of chance in a programming game. Many popular games have an interesting balance between skill and chance; random events can keep games interesting and fun, as there will always be a chance for someone to win out of nowhere (we've all experienced this). However, when it comes to education, students should always be able to concretely see the correlation between their existing knowledge, preparation efforts, and performance with their success or failure. A good educational game, competitive or otherwise, should 100% of the time reward players who have a greater understanding of the subject material. Now, I am not completely against random elements in an educational game (e.g. which problem is given to a student is chosen from a question bank at random), but when it comes to performance, results, and their corresponding evaluations, influential nondeterministic elements should be absent.

 Finally, as with almost all games, a programming game should provide immediate feedback. It is often the case in the classroom that coding assignments take some time to grade, which is suboptimal when it comes to crystallizing a student's understanding of a topic. In games, the immediate in-game responses to whatever the player is doing helps to illuminate the correct path. The ideal programming game should be based in an environment which can very quickly provide feedback on the student's solution to a programming problem.

That's all for now! The core aspects listed above may not be comprehensive - I will come back and update if need be.
Peace,
KR

Formal Elements of Games

What is a game made of? Well of course, there's the graphics, the physics engine, etc., but I'm talking about what really defines a game as a game.

From Game Design Workshop: Designing, Prototyping, and Playtesting Games, Fullerton/Swain/Hoffman, we have a list of the formal elements that make up a game. There are also dramatic elements (Story, Characters, and more), but I will skip over them for now and discuss just these core components, and how they relate to a potential programming game.

Formal Elements

1. Players
2. Objectives
3. Procedures
4. Rules
5. Resources
6. Conflict
7. Boundaries
8. Outcome 

For better or worse, I will consolidate Procedures, Rules, and Boundaries into just Rules. The three components are relatively similar, and though they each have their own nuances and deeper meaning, for simplicity's sake I group them as one. That leaves us with Players, Objectives, Rules, Resources, Conflict, and Outcome.

 In the context of a programming game, I am immediately inclined, for whatever reason, to design it for a single player (though from my own experience, I have enjoyed multiplayer titles quite a bit more). The question remains whether, from an educational standpoint, students will be better empowered playing/learning solo or in a group.

The overarching objective of this game is to learn programming...but insofar as the actual game's goal, that is still up in the air. But, we do know that every game must have an objective of some sort, a goal to be reached. The Rules and Resources with regards to this game are similarly still in development. The primary challenge in the design of this game (or any game for that matter) likely lies in the conceptualization of these components.

Next, we have conflict. This could simply be PvE, or, if the game is multiplayer, PvP. In either case, there must be some interesting challenge or obstacle impeding the player's "natural" progress. This is probably the most interesting part of game design for me; designing a programming game with some interesting problems to solve will be a fun task.

The last, and potentially most controversial formal element of games is the Outcome; in other words, the conditions for winning or losing. In games, having an unequal outcome is all well and good - many people play games for a sense of achievement, they want to be competitive. But competition has mixed results when it comes to learning. The challenge here will be balancing outcome, a core aspect of games, with the educational goal of learning and acquiring skills and knowledge in a fun way.

That's all for now, still have many more updates to come. If you want to know more about these game elements, I would suggest taking a look at Game Design Workshop or reading this wikipedia article: http://en.wikipedia.org/wiki/Game.

Peace,
KR

Greetings

 Obligatory "Hello World"

First blog post, just testing things out. I've created this blog to explore the art of game design and record my thoughts and ideas on the subject. I'll mainly be using this an open journal for my research at university, but I might post about some related game design/game making topics as well.

Thanks for visiting. Updates will come every few days or so, check back soon.

Peace,
KR