For a number of different reasons, I am making my current game using a javascript framework called Meteor JS. In the course of doing so, I also have to learn this framework and some of its intricacies.

Quick Summary of Methods

Meteor uses MongoDB as the default database. To simulate your app running faster, it keeps a copy of the database in the browser along with the copy on the server.

For some actions such as logging in, we don’t want to allow users to do database modifications from the client side. This is a security risk.

Thankfully, Meteor has server side code that can be called from the browser using its Meteor Methods interface.

The Problem

Like any good game, I am trying to have a little bit of graphical display that currently consists of a simple canvas that draws colored squares that represent the players and their opponent’s units.

Because drawing over and over would be processor intensive, we only want to draw the canvas when it changes. Initially when we load the page, we get the positions of the units and draw them on the map.

However when we move, we are sending asynchronous calls to the database. This presents a race condition. The page could load before the server database is synced with the browser database resulting in an non updated canvas when it is drawn.

The Solution

The creator of Meteor must have stumbled across this before because there is a nifty little wrapper to put around your code if you want it to run when the database is updated.

It is Tracker.autorun() and allows you to maintain security by running code solely on the server while still tracking the changes in the database and allowing your app to be reactive.

Last week I broke down my current game into the 10 basic parts of game design that I have been following. For the 8th part, Fun, I had no clue (and still don’t), if the game would be fun or not. This week however I address “Why Are Games Fun?”.

Help from OSCON

One of the hardest parts of game design is finding the fun.

What makes a game fun?

Thankfully, I was able to attend OSCON (Open Source Conference) this year and was surprised to find a series of talks about games and game design.

One of those talks was titled “How Do I Game Design?” and attempted to address what makes games fun and how to design games.

The talk centered on the MDA (Mechanics Dynamics Aesthetics) theory and that is what we will be looking at today.

MDA

MDA describes the 3 layers of a game.

Mechanics is the stuff you actually put in your game. The rules that define how the players can behave and interact. As the game designer you have 100% control over the mechanics of your game.

Dynamics are the combination of mechanics that lead to emergent behavior. The example given in the talk was the game of Tag. A fairly simple children’s game where the rules are simply:
– 1 person is “it”
– if “it” touches or tags you, you are now “it”
That is the mechanics.

The Dynamics that come from this are the players running away from “it” and the player who is “it” chasing the other players. Running and chasing are not part of the rules, but are a result of the rules.

This emergent behavior is what in turn feeds the Aesthetics.

Aesthetics is a single word for saying how the game makes you feel, the sensation the player gets. This is where the fun comes from according to the MDA theory.

However, it is very difficult to directly design Aesthetics into a game. You have to put in Mechanics that give you the desired Dynamics to get your player to the right Aesthetic.

How It’s Done

In order to design around this, you need to start with how you want your player to feel. Do you want them to feel all powerful, clever, sneaky, explorative?

Once you have decided how you want the player to feel, you can reinforce the feeling through the setting and dynamics of the game. For example, if you want to make them feel all powerful you might make the Mechanics of your game allow them to do pretty much whatever they want and make them invincible. If you want to make them feel explorative, you might place them in a maze or a large open world. If you want to make them feel clever, you might give them puzzles to solve.

Fail Faster

Something that was said in this talk and that I have heard in other talks about game design, is “Fail Faster.” This way you get the bad ideas, the ones that don’t give your players the right feeling, out of the way quicker.

One way to do this is Paper Prototyping. Instead of spending hours or days coding up a prototype, spend a few minutes creating a playable paper prototype (if possible) or at least simulating it as best you can in the shortest time possible. Then play it and ask others to play it. Take their feedback, change it and play it some more.

This is the way you get to the fun faster.

Resources from the Talk

The presenters of the game design talk gave these websites as places that they got some of their information.

8 Kinds of Fun
Game Definitions

And you can find out more about the team that gave the talk at Secret Lab.