Wednesday, October 3, 2012

Fear and Self-Loathing in Indie Game Development | An Optimistic Depression

It happens to most of us from time to time and it's the worst feeling in the world. We're working along in our own beautiful and completely flawless world when, suddenly, something happens. Something bad. It could be a negative comment on your blog, getting stuck on a piece of code or game mechanic.. or just be a change in your external environment. And then, BAM, full blown depression.

You start questioning your project, your team member's motivations, your own skills and worth. And all that motivation and excitement you felt just 15 minutes ago is filled with complete dread. This thing you thought you loved is now something you hate and want to get away from.

And it's all a (y = -1x + b) from there.

I've been through it. I'm going through it right now. It sucks.


There are two things I suggest that you keep in mind. (And I try, myself, to keep in mind)

"Depression is normal and natural."

Yes, yes. Depression makes it feel like you're in a hole that you'll never get out of. But there was, at some point, a time when you really enjoyed working on this project [1]. Use your depression as a time to self-reflect. What is it that you don't currently like about what you're doing? Is there a mechanic that you've spent forever trying to implement that you're not even sure will be fun? Are your capabilities hitting their limit in relation to your goals? Persistent contentedness is great, but it doesn't force you to sit down and reflect on yourself, your project, and your processes.

Also, when you're depressed, you want to get away from things you can fail at and you just want to sit around and do things unrelated to the cause of your depression. In my experience, doing something tangentially related helps. If reflecting on your project is too close to that kernel of depression, try experiencing something outside of that kernel. Reading, weed pulling, talking with friends, getting out. Getting away from the thing you're depressed about gives you perspective.

"Depression is typically short-lived."

Especially the depression that arises from working in isolation, pouring your self into some creative medium that you want people to enjoy. It's very easy to find yourself staring at the trees and completely missing the forest. If you spent a whole day trying to get a pixel moving around in a particular manner, you are going to see the whole game through the lens of that moving pixel and not the game as it is perceived as a whole.

I have a couple of techniques that I use that tend to help me out. They don't all work all the time, but usually one will.

  1. Change your state
    • Go to the grocery store/gas station/park. Say some words to people like "Hey, how's it going" or "Nice day, isn't it?" 
    • Buy a random thing at the store and consume it (this works especially well if that thing is caffeine based)
  2. Play your game on a different medium than you normally do
    • I spend about 16 hours on my laptop a day. So, 99% of the time, I'm viewing my game in the same tiny box. Try hooking your laptop up to your TV and playing the full-screen version of your game there. If possible, throw it down on a tablet and see what it feels like there. Get your game somewhere else than you're typically used to it being. 
    • Sometimes I'll steal a meeting room at work and play around with my game on the 60" monitors we have. Sometimes folks will walk by and want to give it a try.
  3. Get random people to play your game
    • JUST WATCH THEM. If they have questions, answer them.
    • Watch HOW they play
    • Watch WHAT they fail at
    • Watch WHAT they succeed at
    • Watch WHAT things they do that surprise you

I hope that something here helps someone who's going through a indie game-induced depression. It's never a good time, but if you're able to embrace and integrate it, it will make it less hard (not easier!) to get through.

[1] If there wasn't, then it's possible that you're working on a project that you actually hate. It's best to change the project (if possible) to something you don't hate.. or leave the project entirely.

Sunday, January 2, 2011

Today I learned ...(2/1/2011)

.. about base36 and Positional Notation.

Notch (ala Minecraft) uses Positional Notation to store chunks in a manner than can be easily accessed by encoding the XY coordinates in base36 representation.

I wasn't sure what the advantages of using base36 filenames over just numbers, so I researched. had a pretty good answers:

Adam David (via

It's not a number because base 36 is shorter for the same ID. A 4 digit base10 number can only represent 10,000 articles while a 4 digit base36 number can represent 1,679,616 articles, and still be just as readable/printable/usable.

grokus (via

This scheme should produce very short IDs.
Easy to use these IDs to create on disk structure.
Easy to convert to numeric IDs to look up database, etc.

So, it looks like base36 numbers provide a more compact numeric representation (compared to base10) and encode larger numbers in this more compact representation.


Thursday, April 30, 2009

A few things I found..

If you're having trouble getting Ruby + RMagick to install correctly on OSX, I found a good article that seems to sum it up better than anywhere else I've seen.

And, in case the link is dead:

"I've seen the craziest problems with people installing the RMagick gem before. In this article, I will show you the procedure I use to fix any and all rmagick problems. First, I start by cleaning out any of the following packages:

sudo port uninstall imagemagick
sudo port uninstall graphicsmagick
sudo port uninstall ghostscript
sudo port uninstall freetype
sudo gem uninstall rmagick
Then, I reinstall them:

sudo port install freetype
sudo port install ghostscript
sudo port install imagemagick
sudo port install graphicsmagick
sudo gem install rmagick
This software cocktail has solved the following problems:

RMagick gem won't compile native extensions
RMagick can't find fonts - This is a really common problem, and we have seen a case where this approach will not solve this problem.
RMagick renders text incorrectly and/or unreadable in the validates_captcha plugin
ImageScience is an alternative to RMagick which requires fewer native libraries, but not zero unfortunately. It may or may not be easier for you to use, depending on what you need RMagick for (it won't do text rendering, for example)."

Wednesday, June 18, 2008

Keeping Peace and Secrets

Hey all. So, I mentioned in the last post that I had a few things I wanted to talk about with regard to the industry. I’ve never really worked at a company that develops games, so a lot of the inner workings were very foreign to me. But, I’ve learned a few things in the past two weeks.

First off, I mentioned above that designers have to be very clear when writing Design Documents. There are tons of reasons this needs to be done, not only for the obvious reasons, but for something that I hadn’t thought of before: departmental peace.

Take this scenario: The designer finishes a design document and sends it off to programming and art to be implemented. When the first build comes to the designers, they notice that something in the game isn’t right: it doesn’t do X! Design goes over to programming to ask them why X isn’t in the game. Programming goes around to figure out who was assigned to program X and why they didn’t. After this, either two things have happened:

1. X wasn’t in the Design Document, so the programmer didn’t know!
2. The programmer forgot X, or thought X wasn’t a very good idea and modified it.

So, there’s nothing really great about this situation. Either the designer is mad because the programmer didn’t implement the design the designer worked hard to create, or the programmer is mad because the designer came over accusing the programmer of not doing something didn’t know he was supposed to do.

Now, this wouldn’t be a problem if it was a freak occurrence. However, the nature of working on a large project with multiple people lends itself to miscommunication and mistakes. There are just too many long nights and strict milestones for things to go completely smooth. This isn’t to say there aren’t some projects that are better than others, but the problem exists and can build walls between departments.

This is why a thorough Design Document is a MUST on any large project. Give the programmers the freedom to be programmers, give the artists freedom to be artists, and write a Design Document so that both can execute the game as if you were there.

Another thing! I can’t discuss many of the projects I’m working on. This one I knew before I took the job, but it’s interesting to be reading news websites and see rumors about the release of game X and know that your company is working on it. It can also make things very awkward when trying to explain what I’ve been working on when I can’t mention what I’ve been working on. But I think, so far, I’ve done pretty well. Hurray for day 3.

There’s one more thing I want to make clear about working in the industry. When I was younger, making games seemed like the best job in the world. Although it is a really fun job, I want to disillusion some of you who think its all fun and games: It’s really not.

If you want to get into game design, you HAVE to get good at something that isn’t games. This could mean programming, or writing, or drawing or something that exists outside of what is considered a ‘Game’. ‘Designing Games’ professionally isn’t something you really get to do unless you’ve been in the industry for a while. And even then, you have to prove that you’re good at it.

My advice to anyone who wants to get into game design is to point your productive arrows all in one direction. This means going to college and focus on something you can make games with (art, programming, writing, sound, just to name a few), buying books and absorbing anything and everything about the subject you can and its relation to game design, and use some of that time you would normally spend playing games to come up with game ideas and flesh them out. And then, after all this, what little time you have left you can use to play video games.

For the longest time I told myself that I wanted to get into making games, but never did anything outside of it. It’s not until you force yourself to sit down, go through all hurdles, and start working do things start coming together.

The Game Designer

So, I’ve been working at Black Lantern Studios for the past two weeks now in the Game Design department. For those of you who don’t know what exactly a ‘Game Designer’ does for a studio, here’s a quick rundown:
  • Game ideas
Game Designers get the privilege of taking an idea for a game and actually making it into a game. They have to foresee all possible problems with an idea, come up with compelling ways to make the idea a game, and watch the implementation from beginning to end.
  • Storyline
For the games that have a storyline, the Game Designer has to write it. Depending on the complexity and audience, the story can be very simple or very complex. Because BLS has a focused more on children's games in the past, a lot of the storylines haven't been incredibly in-depth. This isn’t to say it’s not a lot of hard work because of constraints, but allows much more room to reuse children themes without sounding stale.
  • Psychic and Fortune Telling
Designers give a game to programmers and artists in a huge document called a Design Document. This document is essentially the ‘Bible’ to how the game is supposed to work. Because this document is so vital, designers must write it so that it makes sense to all who reads it. They have to put themselves in the role of someone who didn’t come up with the idea and look at anything they write completely objectively. They also have to make sure they plan out the game. If the programmers and artists spend work hours only to find that a designer wrote the wrong thing in the Design Document, it can create headaches for all departments.

So, with that being said, I bet you’d like to hear what I’ve been doing! Well, to be honest, not much yet. Most of what I’ve been doing has not been design tasks (manual XML conversion, bug testing), but soon, I promise! However, there is one design duty I’ve been working on called ‘Balancing.’

Balancing is usually done once a game is built and in a relatively playable form. It allows for designers to go back and look at the design implemented by the programmers and make sure that it will not be too hard or too easy for players.

A good example of this would be in the Half-Life 2 games.

Valve has a nice setup for balancing in their games. They have a group of people each playing through a HL2 level and, each time a player dies, they record where the player died and how he died. After all players have beaten the game, they aggregate all that data and look for where players died the most.

If a lot of players die while trying to kill a particular boss, it’s a good sign that maybe that boss is over powered, or the player is under powered. This is also useful to find places in a level where there is bad level design. For instance, if a player has to jump over a pit, and a lot of players were shown to fall into the pit and die, it’s a good sign that there’s something wrong with that part of the level.

Balancing is a very important part of keeping your game playable. Gamers are very finicky. If they find themselves dying because of bad design, it can turn them off from playing that game. The real trick is to make a game challenging for all types of gamers, which turns out to be a very fine line to walk.
I have a few things to say about the industry, but I’ll hold off until next post.

Monday, June 2, 2008

In the beginning..

To start off, here’s a little introduction about me and where I’m coming from.

I’m a 22 year old Information Technology major at the University of Missouri-Columbia. I began working on games in my early teens with a piece of software called RPG Maker 95. Although a lot of the programming was hidden behind the scenes, the software let me produce games quickly and focus more on story and character development. I never finished a full game, but I learned a few key concepts for future use.

After that, I took a hiatus from game creation to focus more on creative writing. The programming side of games seemed really complex and impossible to me, especially with some of the math related stuff. I would look at someone’s code and try to understand it and come up empty handed and disheartened. So, I did something that was relatively easy for me and wrote random blog posts, songs and stories. Some I was proud of, others made me feel silly for writing them.

What got me into programming, as much as I hate to say it, was a Visual Basic class taught at my high school. The simplicity of the language made it possible for me to better understand the beginnings of how computer programming worked. I didn’t know it then, but that was just the tip of the iceberg.

After graduation, I moved onto Community College where I learned to program in C and found myself writing much less than I once did. I really began to feel the tug between the two sides of my brain: the creative writer and the logical programmer. Programming gave me the freedom to create useful things, where my writing was a tool to expand my vocabulary and express myself.

Throughout this period, I hadn’t thought about getting back into game development until I bought a Nintendo DS and stumbled onto the huge online homebrew community and the open source library Palib. I soon found myself back working on games.

There was just one problem: I wasn’t very good at programming. But that didn’t matter! I would use it to get better. And that’s exactly what I did. As I programmed stuff, I learned about structures, memory management, and other stuff that was really foreign to me in the unimplemented context. I also got the courage to go through the Calculus sequence and, although I managed to only get a C in a lot of those classes, I took away exactly what I needed to learn from them through implementation.

Since then I’ve moved between the Nintendo DS and PC game programming. All of this got me an internship working for a company called Black Lantern Studios in Springfield, MO, which is the reasoning behind this blog. It’ll be used as an account of my time spent at BLS, what I’ve been doing, things I’m learning, and other things I think might be useful to my future-self and maybe some kid looking to get into game development.

Thursday, November 1, 2007

Some semi-pertinent stuff...

To begin, I'd like to say that I really enjoy making games. I've always had the urge to create, regardless of the medium and Game Development provides so many different avenues. Anything I can create, I can create it for a game. Writing, Programming, Drawing (badly), Psychology (game play), music, performance. It's all there.

I view it as an tree-graph with it's roots in the air all funneling down to one node. I think that's what makes video games, and games in general, so popular.

Look at it this way: at the root of every video game is a game. Games have been around forever and are essentially just a set of defined rules in which you must achieve some final result. You take that core and you write a story for it. The story does not change the rules of the game, but serves as a prize for completing the game in context of it's rules. On top of the story goes all the content (music, visuals, models); essentially, these are all the 'performers' in the story that act out what is stated textually (that includes music).

Game -> Writing -> Performance = A Modern Video Game

This of course doesn't cover Casual gaming, which is just a game with performance on top of it.

Anyway, sorry if this seems a little scattered. I wrote it while dealing with a campus-wide power outage on my Campus. PowerOutage + being IT Support = PURE CHAOS.


Random stuff I wrote but didn't use:

I was thinking about forms of entertainment:

A novel is passive, takes a good time to read, puts the reader into the state of Flow, and is easily accessible. It has perceptual value in visual areas, both physically and mentally, but lacks auditory value. The key to this medium is forcing a constant mental visual image and is therefore considered a higher level entertainment. It tunnels readers down one path and it pulls from

A movie is passive, lasts about 3 hours (relatively short time interval), puts the viewer in a state of Flow, and is easily accessible. It has perceptual value in visual areas, more physically than mentally; in auditory areas. It

A sport (the act of playing) is active, it's duration varies, puts the player in the state of Flow, and is difficult to setup.

A game is active, it's duration is dependent upon the player, it puts the player in a state of Flow, and is relatively easy to set up.