One of the ultimate goals of a game designer is to have people actually play your game. What better people to offer your game to than people who already love games.

Twitch

Several months ago, I was looking for some entertainment and went to Twitch. For those of you not familiar with Twitch, it is a service that allows gamers to stream themselves playing and build up a following of people who can subscribe and give them money to watch them play.

I happened across a streamer named Cohh playing Fallout 4 which had just been released. I found him to be really entertaining and building a great community so I started watching his channel sometimes while I was working.

Come to find out, he is a game designer and has a game studio that was making his game for him. And he is streaming on Twitch full time to build an audience and a community that enjoys games like the one he is making.

This January he ran a kickstarter campaign for his game and got it completely funded fairly quickly.

It was genius.

So for those of you who like to play video games in addition to designing them and making them, which I am going to assume is all of you. Consider using your time to play as dual purpose and possibly stream on Twitch or make Youtube videos. Both would probably be good. This way you build an audience who already likes you and are willing to try things that you make and possibly even be your beta/alpha testers.

And remember, start as simple as possible. You don’t need a $300 podcast mic or super fancy equipment to get started. Use what you have on hand.

Every week I try to learn something new from people who have done what I want to do already. I read articles, watch videos, or listen to podcasts about games, game design, programming and self improvement. Every month I will try to create a summary of the articles and such which didn’t get individual posts.

Game Design

GDC 2010: Sid Meier Keynote – “Everything You Know is Wrong”

Sid Meier’s keynote at GDC 2010 does an excellent job of going into some odd and unexpected psychological behavior of players and how it is important to the design of the game. It is about listening to a player and using their psychological tendencies to make their overall experience better.

Sirlin – Solvability

I think I will be mining David Sirlin’s articles for a while. He has quite a few good articles on game design and his article on game solvability is no exception. He discusses the importance of hidden information or surprise to keep a game from being completely solvable so that it will remain interesting and maintain replayability. A game where you just have to memorize a certain pattern and do that to win will not remain fun.

Rob Pardo Blizzard Game Design Lecture MIT 2014

Rob Pardo gives a talk about some of Blizzard’s game design values and process. The main part of the talk is sort of a summary of how Blizzard’s values affect the process of game design and what is good about that. He also talks about expanding a game audience and avoiding certain game design mistakes like not play testing early enough. A lot of good game design advice here.

Self Improvement

Jim Rohn – Your Best Year Ever

This is a really long talk (about 4.5 hours) but it is a gold mine of personal development advice. The major theme is if you want things to change, you have to change. Jim Rohn fill this talk with different small things you can do to improve your life that will significantly change the destination you are headed in 5 to 10 years. Topics include health, psychology, finance and suggestions for your personal library. You may need to break it up over a few days, but I definitely recommend watching it and taking notes.

More Next Month

I think this will become a regular monthly posting and hope to be able to provide a nice little aggregate of useful information for anybody trying to learn about game design, programming and self improvement. In the future, I may also add drawing and writing articles since these are also important in game design.

Now, go read about making games so you can make your games better.

If you continue with the habits you have now, will they get you where you want to go?

Our habits, or daily rituals, will slowly guide our lives toward one end or another. Most people don’t stop to think about this, but it is an important part of guiding your life and being productive.

Good Habits

You are as productive over a long period of time as you are in the habit of being. I am only going to talk about good habits today because, frankly there has been a lot written about bad habits. Here are some habits you might want to develop.

Write Things Down

The mind only has so much space. In order to stay creative, we need to take stuff out of memory and make a hard copy of it so we can think more and better thoughts.

This also prevents the loss of a good thought. Often we get going throughout the day and the demands of life cause us to forget things. Writing down an idea allows us to find it and remember it later much easier. Carry a little notebook with you or keep a note taking app on your smartphone and get in the habit of writing things down.

Do Things Now

Often we put off things unnecessarily. If you have time to do something, get in the habit of doing them right away. Don’t say “It can wait until tomorrow.” Tomorrow will have interruptions and delays and you might not find time for it. Now would be a good time.

Put the Most Important Thing First

If you have something that you really need to or want to get done in a day, get in the habit of doing it first. If this is writing, do it first. If it is working on your game, do it first. If it is calling your mom, do it first (unless it is like 5 AM and she wouldn’t be up yet).

This is often said as “Pay yourself first.” And most people use this phrase when talking about money, but it applies just as well to time. Take the first part of your day for yourself.

Have a Plan

Don’t just start things, take a little bit of time and plan them out. Come up with some clear, actionable steps to get you to the goal first. Once you have these, start immediately.

Make it a habit to plan your day.

Get Moving

It is hard to have the energy to make important decisions, do good work, or change bad habits if you are inactive all the time. Starting the day with a 15 min to 1 hour walk can give you a great boost in energy and helps slowly build fitness over time so that you have a larger reserve of energy to call on.

Keeping your body healthy through working out and eating right will help you have the energy to be productive and successful. Make it a habit to move more every day.

Shape Your Life With Habits

Use some (or all) of these good habits to get you on the course to your life goal.

Now go start good habits and make games.

As I learn about games and game design, one of my goals is to eventually create a game that people play against each other at a competitive level. One of the important aspects of a game like this, whether it is turn based or real-time, whether 1 vs 1 or team vs team, is balance.

Originally I was going to read several articles on this and summarize what I learned here, but this article will mostly cover what I learned from an excellent series written by David Sirlin on his blog at sirlin.net. I highly recommend heading over there and reading the original series once you are done here.

What is Balance

What most people think of when they think of the word balanced is usually fairness. That everybody at the beginning of the game has a roughly equal chance to win (not counting personal skill). And in most player vs player games this is an important aspect of balance. But as game designers, when we say a game is balanced we also mean that there is an large number of viable options available at high level play by expert players. And in the talk given by Ernest W. Adams that I summarized previously, he would say that a single player game is balanced if it is appropriately difficult or challenging.

Your game can have tons of options, but for balance, we only care about meaningful options. We want to avoid a game where only 1 or 2 dominant strategies emerge or where only a few characters, decks or builds (or whatever your game uses) are ultimately playable at a tournament level.

Symmetry vs Asymmetry

Games where opponents start pretty much identical lean toward the symmetrical side of the scale and are typically easier to balance. This is the simplest way to balance a player vs player type game. Examples of games that are on the symmetrical side of the scale include most FPS games and Chess.

The more diversity in starting conditions, the more asymmetrical a game becomes. Adams mentions that this makes games much harder to balance but at the same time makes them more interesting. Examples of this type of game include League of Legends, Magic the Gathering, and any other type of game where multiple classes, decks or characters are available as the starting option. In asymmetrical games, fairness is important to design. You want every option to have a reasonable chance to win in the hands of the right player.

Enough Viable Options

One of the harder questions when balancing a game is how to know when you have enough viable options. The first step in this is ensuring that moves and strategies have counters. If a move cannot be countered then it becomes 1 of those dominant strategies we talked about earlier and the game will quickly degenerate into people just using that move to win (not very fun). After a couple layers of countering you probably want to loop back to the original move so that the third or fourth layer of counter is just the original move, sort of like rock-paper-scissors.

One of the things to watch out for and avoid is chaff. Needless mechanics, characters and choices that do not add to the game and are ultimately useless. Don’t just add an option to add it, make sure it is useful. Explore the design space and see what works.

Checkmate and Lame Duck

When one player is doing better than another and they have reached a point in the game where it is impossible (barring a major mistake from the winning player) for the player that is losing to make a comeback, we call that a Checkmate scenario. And this is fine usually.

However, we want to avoid allowing the time from the beginning of a checkmate until the end of the game to be drawn out. This is a Lame Duck situation where one player or team know they can’t win but are forced to play out the game for a long period of time in the losing situation.

Playtesting Is Important But Hard

One of the best ways to find out if a game is balanced or not is to play it and test it. This can be hard. Especially if you have a large number of options. But play testing discovers things you never could have predicted.

When play testing you want to evaluate your playable characters, decks, etc. One trick to balancing games is to not rank your playable units linearly. Sirlin recommends using a tiered list with 3 actual tiers and 2 tiers that you want to keep empty. You want to keep things out of the “God” tier that must absolutely be played if you want to win and conversely you want to keep things out of the “Garbage” tier that must never be played if you want to win. The remaining 3 tiers should all be pretty close.

Getting language type feedback from play testers can also be hard because a lot of good players make decisions subconsciously. In order to balance your game you sometimes need to rely on the intuition of yourself and others. Be careful to get enough feedback that your decisions are not driven by just one loud incompetent person.

Most Important Design Tip

Probably the most important design tip that I got from this article was to try to start the design with mechanics and failsafes that self-balance. Sirlin used a fighting game called Guilty Gear as his example. It built in certain things like progressive gravity and combo breaking type abilities to keep characters from being able to completely immobilize and beat an opponent with no response.

They eliminate potential problems from individual characters with global design features. This is difficult but if you can figure out a way to do it, do it.

Various Tips and Tricks

My notes from the article have a few things that I though were important that won’t get whole paragraphs here. For more on these I recommend reading the original 4 article series on Sirlin’s Blog.

• Don’t balance the fun out of things.
• Counter matches (characters that counter other specific characters) are not good for 1 v 1 style fighting games.
• Avoid special cases and actually balance the game.
• Don’t set yourself up for failure by including too many characters or too much customization.
• If you add a new move, make it too powerful then scale it down as necessary (otherwise play testers won’t use it)

Conclusion

Balancing games is important and complicated. Perfect balance is hard to achieve because to keep the game interesting we don’t want it to be completely solvable. The more play testing you can do the better because it helps you figure out where the game is unbalanced. One of the best ways to balance a game is to have some global design elements that help ensure balance. While this is difficult, it will help tremendously if you can do it.

Sirlin offers a handy pdf summary of his article available here. This subject will be revisited in the future.

Go balance games.

In my last post I reviewed my progress and struggles from 2015. Today, I want to turn the focus completely around to planning for the new year.

New Goals

Writing

Although I did not hit my writing goal of 1 blog post a week in 2015, I am not going to keep that goal the same. I am in fact increasing it to 2 blog posts a week with a 3rd blog post added to a buffer.

I am sort of borrowing this from some financial advice I read in a book called “The Richest Man in Babylon” and from advice given by some of the podcasts I listen to.

The idea is to avoid the scenario that I ran into last year where I met the resistance of life – having to move, go to the dentist, going on vacation with no internet access – and still be able to meet my goals by building a buffer of articles.

In short, goal for 2016 is 104 blog posts published and a small buffer of posts set up for when I am unavailable. The first instance of this is end of January so I really have to get started.

In addition to writing about programming and game design, I will dabble slightly into mindset and productivity tips, much like I did in 2015.

Programming and Games

For this goal, I am actually lowering the number of games I plan to produce to 4 but planning on increasing the quality.

Each of the games last year was sort of blocky and ugly with thrown together graphics and no sound. This year I want to release 1 game per quarter and I want to be able to release them to the Google Play store for Android.

Education and Personal Improvement

Although continual personal improvement has always been my goal, I wanted to add a little direction to it and add it here because it should be relevant to the first two areas.

I plan to read through 6 books on game creation or game design and incorporate the ideas into my games. Keep in mind that books on game design that are not about video game design are still relevant.

On top of that, I plan on finding and reading at least 1 article or watching at least 1 video on programming and game development every week.

Audience

It doesn’t matter how good I write or how good my games are if nobody is reading my writing or playing my games. Therefore, I plan on getting at least 100 people to read my blog every month by the end of 2016.

Here We Go

Looking forward to next year and seeing how instead of falling short of my goals, I exceeded every single one of them.

Until next time.

Ah, a fresh New Year. That time when most people make New Year’s statements about the things they wish would happen automatically in their life and make half hearted attempts to make them come true.

I do not believe in “New Years Resolutions” but I do believe in making a plan for the new year and setting some SMART goals and following through with them in the coming year. In case you have not heard of SMART goals before they are Specific, Measurable, Achievable, Relevant, and Time-Bound.

First we will review how we did last year.

Last Year’s Goals

At the beginning of 2015 I set some public goals for myself (public being used loosely here because a new blog like this has 0 readers). Let’s see how I did.

Goal 1 – Write 1 Blog Post per Week

You can see for yourself that I only got half way there on this goal writing 26 out of the 52 planned posts.

What Went Wrong

I started out good and was writing and posting every Sunday for the first 4 months, then I met Resistance (aka “Life”) and let my writing ritual become sporadic.

The Resistance in this case was I moved cities on a little shorter notice than I liked and spent at least 4 weekends in a row in the new city looking for a new apartment before the move.

I allowed this to break my writing streak and did not recover from it for the rest of the year.

Also, in August I was in Thailand for 2 weeks and traveling everyday without access to internet (which was surprisingly enjoyable) and although I had already planned to be gone and unable to write or post for those 2 weeks, I failed to build a buffer of posts ahead of time.

As far as I know, I have 0 readers for this blog. Which is entirely my fault as I do 0 marketing currently. Planning on changing that this year.

What Went Right

I wrote 26 freaking blog posts!!! Which is 25 more than I wrote the year before and a bunch more than most programmers wrote this year. Definitely a major improvement.

I did stick to a schedule for the first part of the year.

I learned the importance of having a buffer for when Resistance shows up so that the goal will be met. This is similar to insurance or an emergency fund in financial terms.

Goal 2 – Make 1 Game per Month for 11 Months

Again I got about half way there and was doing well until the same Resistance mentioned before but for this one, I also made additional mistakes.

What Went Wrong

First of all, letting resistance break my streak and not recovering same as with the writing. But I made 2 additional mistakes.

First, I started making a game by building a part that was not essential to the game. Game number 5 is a space ship tactics game and instead of starting by building a game board with ships that could move and fight, I built a fleet construction menu which handicapped me when I actually tried to make the playable part of the game. It became easier to start again from scratch than to try to untangle the mess I had made for myself.

Having this mess to slog through to try to finish the game made working on it no fun and so I kept putting it off to do more enjoyable things like reading a book or playing video games. It took me a while to get around to the solution of starting over with a playable MVP.

Second, I switched programming languages/platforms in the middle of the year to one that was not game focused. While this is not really a bad thing, it did cost me a little time learning the second new platform.

What Went Right

I learned a ton. Having never made games before, this was a fantastic learning experience. Now I can say that I have made 5 games.

I got to watch some people try my games. A few friends and family members tested my games for me and it was an great learning experience watching them learn the controls and ask questions to help me learn what was missing. Play testers are invaluable. Try to find as many as possible.

There are now 5 “completed” programming projects that I did that I can put on a Resume in the event that I ever need another job. This is worth it just by itself.

Goal 3 – Take on and complete 6 Freelance contracts

Zero is the number you are looking for if you want to know how many freelance contracts I got.

Not entirely for lack of trying. Admittedly I made no effort until after I moved and then my effort was not focused or very determined, there was no real desire.

I did manage to have a discussion with a guy about a possible job, but it was an overly complicated app idea that I did not feel was in my wheelhouse or would make a good app.

However, I was able to pass along some advice from a freelance and entrepreneur podcast to a friend of mine so not all of my research was wasted.

Nothing went overly right or wrong for this goal because nothing really went at all. Not worried about it though.

Recap

2015 was another year of learning, but with action. I wrote more than I had in any previous year and programmed 5 video games that I can show to people.

Sure I did not meet my goals, but having goals and planning things got me to do more than I ever had before. For that, I say 2015 was a success.

Stay tuned for goals for 2016.

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.