Whether it is writing or coding, the singular most important thing is to stay consistent. It is the way that large goals are reached and large projects are finished.

I recently read the Richest Man in Babylon which is about how to manage money effectively, but it had a line which really stuck out to me.

The narrator is giving an example of a man who has decided to throw a stone in the river everyday when he crosses a bridge. He says if the man for some reason forgets to put the stone in the river and remembers later that day, he does not say “I will put 2 stones in tomorrow”. Instead he goes back to the bridge and throws in the stone that day.

The point of the story is to save part of your income consistently, but it applies to any long term project.

A Schedule

This is not the first time I have heard or read (or wrote) about consistency and I did have a pseudo schedule before. However, I believe it is important for me to get back on a regular programming and writing schedule and stick to it no matter what.

So, starting the week before the new year I will be on a regular programming and writing schedule.

Side Note

Game #5 is almost “done” and I have learned a quite a few lessons from creating in Meteor JS. I will continue working on it for the rest of December and the next step is to see if I can get it to build into an Android app using the built in Cordova tools.

I discovered yesterday that a significant change has been made to the installation of the android build components of Meteor. You must now install the Android studio from Google separately, it is not automatically done when you run a ‘meteor add-platform android’. It does however direct you to the steps necessary to get all of the pieces in place.

Now back to your regularly scheduled programming.

I sort of made this mistake with my current game. I started working on it by building a side feature that was not the core behavior of the game and then trying to build the core of the game around that.

Having the side feature was nice, but made actually getting the game working much more difficult. Imagine building a house and you put some furniture and appliances on the ground then try to lay the foundation under them. It is not pretty. It could be done, but works a lot better if you put the priority on getting the foundation laid to support everything else.

The Right Order

The correct order is to build as simple as possible playable version of your game first. For example if you are building a platform, start with a character that moves on the screen and jumps with a flat foundation that it doesn’t fall through.

In my case, I am building a turn based combat game similar to the second game I made using the Monkey-X programming language. The right way to do it (the way I started over doing it) is to first make a map and put a unit on it that can move, then can attack another unit in some way.

Moral of the Story

Build the simplest working version of the game first.

Don’t start putting your games’ furniture in until you have the foundation and probably walls of the game built.

Keep making awesome games.

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.

Oddly enough I had a problem at work that I also found in my own programming.

Just gonna dive straight into it.

Mongo and Dynamic Languages

Mongo is a pretty neat “NoSQL” database that uses a JSON like format (called BSON) for storing information. If you have never heard of Mongo, you should definitely check it out.

Mongo is fairly flexible and stores what you give it, in the type that you give it.

If you give it “5” (in quotes) it will store it as the string “5”.

If you give it 5 (no quotes) it will store it as the number 5.

This usually is not a problem unless you meant to give it 5 and gave it “5” instead. Because when you ask for it back and it hands a nice little “5” to your dynamic language (when you think it is a 5) you may get something you were not anticipating.

In javascript, when you add 1 to your “5” you get “51” instead of 6. And when you subtract 1 from you “5” you get NaN (Not a Number) which is so useful.

Mongo Lookups

Another interesting behavior that arises is when you ask Mongo for that nice 5 you stored it fails to find it. Because 5 the number is not “5” the string. Funny how that works.

This can make some code look like it is not working when in fact you simply have inconsistent data storage and retrieval patterns.

Moral of the Story

Be careful in dynamic languages when using a storage system like Mongo that doesn’t care what you give it.

Use your type casting functions like parseInt to insert and retrieve data, or use a database that cares what kind of data is going in and out.

This is going to be a breakdown of the basic outline of the game I am currently working on, since it is coming slower than I would like.

I probably should have been writing these up for all of my games, and might go back and add the first few in later.

The current game is a turn based strategy game similar in nature to Game #2 (it is basically the same game with a different theme and in a different programming language/platform).

The 10 Things

For each of these games, I tried to sit down and go through the list of 10 things every game needs on paper and see if the game filled all 10 categories or if it could be coerced into filling them. This is the breakdown of my latest efforts.

#1 The Goal

The goal of this game, as in most war themed strategy games, is to completely eradicate your opponents units from the field of play. Wipe them out, all of them.

That was easy right?

#2 The Rules

My first instinct when making this game was, “Oh I know what the rules will be, gonna program them in, shouldn’t have to write them down.” Boy was I wrong.

First of all, it helps if you can with a game like this to do a paper test to see kind of how it will play and what might and might not work. To do that, you need written down rules.

I have a list of some of the basic rules:

– Each team has 1 to N (for an as yet undetermined number of N) ships in a given round.
– Ships have a speed and can move that many spaces per turn
– Ships have armor
– Ships have turrets
– Turrets can attack enemy ships within their range to reduce their armor
– When a ships armor is reduced to 0 that ship is destroyed
– When all the opposing players ships are destroyed, you win the game
– Players take turns moving, then damage is dealt at the same time
– Players cannot see enemy ships that are out of sight range of their ships
– Each round has a limited number of turns so the game does not go on forever
– If a round ends where neither player has destroyed the enemy completely, it is a draw (for now).
– May have a series of rounds for a “campaign”.

There may be some rules I have left out here but this is the basics of the game.

#3 Interaction

What about this games forces players to react to one another?

The primary reaction should come when players spot enemy ships. They will then get to interact with them by attacking or retreating away from them.

Simple, not a whole lot of interaction. (This may need to change?)

#4 A Catch up Feature

This one is actually a bit perplexing and took some thinking. How to give somebody who has fallen behind a chance to win?

The 2 solutions that I have come up with so far are:

– If a player has 2 fewer ships than his opponent, let him move second.
– If a player has 2 fewer ships than his opponent, let him call in a ship for reinforcement.

This bit is still a work in progress.

#5 Inertia

We want the game to end eventually, and according to Mark Rosewater it should be before the player wants it to be over.

With this in mind, the game will have a turn system that ends the game after the allotted number of turns have passed. What that number is has not been determined yet.

#6 Surprise

Surprise is the elements of the game the player cannot predict. This is usually based on hidden information or randomness.

As with many strategy games, the surprise in this game derives from a fog of war that hides enemy position and movement.

Moving a ship to find an enemy ship nearby, having a ship you can’t see attack one of your ships, each of these surprises the player.

#7 Strategy

What about this game allows a player to get better over time?

Learning which units to scout with, how to best order your attacks to maximize the damage, and learning which units to put into a round for the good of the overall campaign.

These are the areas that I suspect will allow a player to get better over time.

#8 Fun

By far the hardest element of game design to predict and design. I have no idea if this game will be fun. It is based off of several other games that I find fun, but it is hard to say if it is.

This is a whole topic that many have discussed and debated but the proof is in the pudding. You will find out when you ask people to play your game.

#9 Flavor

A game that was just numbers and increasing and decreasing them would be pretty boring. But when those numbers represent the armor of your frigate as it takes fire from an enemy battleship, they become more meaningful.

The flavor of this game is not complete but has its basis in the sic-fi grand space battle realm.

#10 A Hook

How do we get people to play this game? A cool trailer, awesome screenshots, perhaps a compelling description?

This is marketing, but as a game designer and creator it is important. Why should people play your game?

I think the hook will be commanding your fleet and making the choices that keep your ships from destruction and lead to victory. Not necessarily the strongest hook, but the best I could come up with in short notice.

A Work in Progress

Clearly several of these points are not very strong and need a bit more fleshing out. As I get more games under my belt, the experience will hopefully lend me some insight into some of the more tricky points so I can design around them better.

This post inspired by The War of Art by Steven Pressfield

You can find a nice summary and notes on this book here

Watch out for Life

It brings Resistance.

Sometimes this Resistance is something shiny that distracts you from your original goal.

Sometimes it is a wall that stops you from progressing as easily as before.

And sometimes it is so many things that have to be done that you lose sight of what should be important.

Many times the Resistance is not in and of itself bad, and many times it is quite good to be doing. The problem comes when we let it break our slow steady march toward our higher goals.

The answer is good old fashioned self discipline and forming good habits.

Put the most important things first and don’t even do the unimportant things. Make sure that when you spend your time on something, it is worth spending time on because time is what you can never get back.

Life got me

I had a good streak of work and writing going from January until June, but then I moved and got really busy and have not recovered.

Occasionally I would work on my next game, or write something but not finish it. But I have not got back into the rhythm of consistently working towards my goals.

So it is time to readjust, rebuild the habits and start putting those goals at the forefront of my day with the top two goals being:
– Finish 1 Game a month.
– Write and publish 1 Blog post per week

More on games, game design, and programming next week.

Were I’ve Been

In a word, moving. I spent almost all my spare time in the last month traveling and doing online searches to find a place to stay and then actually moving to said place.

After many trials including last minute address changes and resulting problems with utility companies, I am finally back to a semblance of stable living conditions and will be returning to a more stable writing and programming schedule.

Upside of the Move

Biggest upside is I am now working from home. My employer has generously allowed me to move and retain my position (a perk of being a programmer and the existence of the internet). This reduces my 10 minute commute to 10 seconds. Not a huge deal but really saves me 40 min to an hour everyday because I used to drive home for lunch.

New to Me Processes

Pomodoro

As part of my move to working from home, I have started using the Pomodoro technique to help me focus during work hours. If you have not yet heard of this process, it is a simple concept of setting a 25ish minute timer and working focused on your task for those 25 minutes, then taking a short break.

I have found this to be extremely useful so far in helping maintain focus and be more productive during working hours and will be using it on my own projects, including my writing.

Kanban Flow

Although not really a technique, I will be planning out my weeks and months a bit better as I have a month’s worth of catching up to do. There is a really nice little website at kanbanflow.com that has a simple board/card system that I will be using to plan out my weeks. It also has the additional benefit of a built in Pomodoro timer.

Good to Be Back

I am looking forward to getting back in a groove and get the games rolling once more.