Debugging Embedded Mono

It's been announced that Go Home Dinosaurs will be released using Google's Native Client technology later this year, but what isn't known (as much) is we're using Mono / C# as our "higher level" logic and scripting system. Generally, I'm a huge fan of C# as a language, and the performance benefits just seal the deal for me. The one issue we have right now, though, is debugging embedded Mono, especially in conjunction with the game running in Visual Studio. There aren't very many instructions on how to do this online, so I thought I'd share our experience.

There are two very weird issues when debugging embedded Mono. First, it currently works exactly opposite of how most debuggers work. In most soft debuggers, the application starts the server and the debugger connects to it. In Mono soft debugging, the debugger creates the server and the client connects to it. Second, the Mono soft debugger uses signals / exceptions to work halt threads. This means that you can't debug both with Visual Studio and Mono Develop, because Visual Studio will pull the signals before they get to the application. This also prevents

However, there are changes in the works from the Unity team which fix both of these issues. However, they are not currently part of a stable mono release (or in the Elijah's version for Native Client). Once they are, I may revisit this whole article, but that's where we are right now.

So, with all of that in mind, how do you get this working right now?

Set Up MonoDevelop

First up, grab MonoDevelop.

Second up, you will want to add an environment variable to your system called MONODEVELOP_SDB_TEST and set it to 1. This gives you access to the following menu item when you have a solution loaded:

Which brings up this dialog:

Now, for some reason, I've never been able to get MonoDevelop to launch the application directly. It always fails attempting to redirect standard out, and then immediately crashes (I could look at the code to figure out why this is, but I haven't had a chance to). We'll come back to this dialog in a minute.

Prepare Your Code

There are a few things you need to add to your code to get debugging to work. The first few lines can occur at initialization, regardless of whether you're debugging or not:

mono_debug_init(MONO_DEBUG_FORMAT_MONO);
mono_debug_domain_create(mMonoDomain);

These should be done before you load any assemblies.

In addition, if you're running Mono from a background thread (like we are), and not running it on your foreground thread, after initialization you need to detach the foreground thread. This is because when Mono attempts to halt all threads when it hits a breakpoint, it can only do so when you're executing Mono code. If your main thread never executes any Mono code, it never halts, which means debugging doesn't work. This is good practice regardless, because if the GC needs to halt all of your threads, it will also fail if a non-Mono executing thread is still attached.

Last thing you'll need to do in code is set up the debugger. Here's the code:

     bool isDebugging = AresApplication::Instance()->IsDebuggingMono();
     const char* options[] = {
          "--debugger-agent=transport=dt_socket,address=127.0.0.1:10000"
     };
     mono_jit_parse_options(1, (char**)options);

This needs to be combined with any other options you may have (I only have one other, which is –soft-breakpoints), and should only be done if you want to start debugging. If the Mono client can't connect to the debugging server when it starts up, it will call exit, which is no good.

Lastly, if you're using the Microsoft C# compiler, instead of the Mono one, you'll need to generate mdbs from all of your pdbs. There's thankfully a utility for this. We actually now perform this step as a post build event, which keeps the mdbs up to date with latest code.

Put it all together

Alright, so let's get this party started!

Open MonoDevelop. Set some breakpoints, then open this dialog again.

Don't change anything, and click "Listen".

Now start your application outside of Visual Studio with whatever command line arguments you chose to signal to your app you want to debug in Mono.

Everything should now connect and you should be debugging Mono in your app!

Let me know if you have any issues!

GGJ 2012: Eat Sheep (and Die)

This weekend I participated in Global Game Jam for the third time (after taking a hiatus in 2011 to go speak at conference overseas). This year, I was at the UVA site and took part in a 3 person team with my brother in law and an awesome UVA student. The result was an interesting two player competitive game called Eat Sheep (and Die).

This jam was way less stressful than any other jam I've participated in. We essentially had something fun to play by middle of day 2, and just polished things throughout the end of day 2 and day 3. As a result, this is probably the most complete jam game I've ever worked on. Very little went wrong. It was great.

So what when right?

  1. AngelXNA – Power of Angel combined with the power of XNA! This was the third time I've used Angel in a jam and every time it's improved. We were able to get levels in games quickly, spawn actors, and do all sorts of things quickly and easily. It actually worked really well. Again.
  2. Abandoning Design – The original point of the game was to have a cyclic back and forth of helping and hurting the other player. On your turn, you would have your goal, and a directive to help or hurt your opponent. On the next turn, you would be given a bonus based on how well or poorly your opponent did. At some point, we realized there was never any reason to help your opponent. It just wasn't worth it. So we abandoned the helping, turn based component, and went with real time versus. This makes it questionable whether we obeyed the theme, but whatever. The game was much better as a result.

What went wrong?

  1. AngelXNA? – So, the one thing I don't like about Angel and XNA is that it does have a huge barrier to entry for people playing the game after the Jam. I know I don't bother playing a GGJ game that requires a download unless it comes VERY highly recommended. I will, however, look at pretty much every HTML5 or Flash game. That said, Angel is awesome, so maybe I have to figure out a way to fix this. Native Client maybe?

That's it. Not too many lessons this time out because everything went so well. It's a weird feeling. Really looking forward to next year!

On Singletons

Inspired by a Twitter discussion with Liam Devine about my previous blog post, I've decided to take a bit of time to talk about my opinion on Singletons. In my previous post, I used a lot of them, though generally, I'm not a huge fan. In fact, I've been known to dedicate non-trivial amounts of time in talks to the subject of why singletons suck. Singletons are just globals under another name, and they have almost all of the same drawbacks as globals, and don't provide too many benefits. Each singleton is a potential bottleneck, a potential threading nightmare, and almost always creates giant side effects throughout the code base every time they're used. In addition, if you're doing unit testing, use of singletons / globals requires significant set-up overhead, which can make tests more complicated.

So what gives? Why am I using them here?

Generally, there's nothing intrinsically wrong with a Singletons or globals. It's their overuse that becomes a problem. As mentioned above, each singleton needs to be managed carefully because it can become a potential bottleneck across your entire code. However, when you're working with something that does need to be global, a Singleton is sometimes a better option, since you can insist certain conditions be met before an instance can be returned.

A good example is a Fixed String Table. If you're unfamiliar with this, here's the idea: every string in your code is translated to a hashed number. In some cases, this translation is done manually, but for the sake of code readability and simplicity, I do the translation in code any time a FixedString object is created. In order to make sure that same string always returns the same hash, and to make sure we can translate the hash to a string, we put the string into a table. This table could be a static member of FixedString, but if you want to, say, tell the table where to allocate its memory from, or how much memory it's allowed to use, you need to initialize said table. Again, you could use a static method for this, but this is hiding what's actually happening. Furthermore, if your table class is any amount of complex, or has functions for accessing usage data, you're essentially going to be pushing that all into static methods of FixedString. It's a pain, when you are, in essence, creating a global interface anyway, since FixedString itself will probably be in global scope. At least by moving things into a singleton you potentially have the option of creating multiple tables in the future, should you so choose.

But what about all those Factory singletons from my initial post?

First, a point of clarification: in the previous post, I made it look like every factory was a singleton. I did this for simplicity, and I apologize. It actually isn't true. My factories aren't singletons. In reality, the code reads like this:

Application::Instance()->GetFactory()->RegisterComponent(…);

Application is one of the other few singletons I have in my engine. Now, I'll admit that this isn't much better than having the factories themselves be singletons, since they're retrievable from a singleton anyway. If you look at the code, it looks like my component code is now coupled to both the factory AND the application.

But in reality that's not true. My factories aren't coded or tested as singletons. If I wanted to create another factory I could, and all my unit tests will still work. And the components themselves aren't coupled to the factories or the application at all. The only thing that couples factories, the components, and the application is the auto-registration system, which serves as a bridge between all three systems. Each system is still usable stand alone.

This just leaves whether or not the Application as a singleton / manager is a good idea. The answer is, no. No it isn't. But since it is one of few, it sticks out like a sore thumb when you type it, and in code review. Every time you see or type Application::Instance() should be like warning lights going off in your brain that you're potentially doing something dangerous. BUT, since I'm mostly doing this during initialization, and at no other point, I'm okay with it.

Cardboard Jam: Best Jam Ever

This weekend Boston Game Jams ran Cardboard Jam, a game jam where everyone made board or card games instead of making digital games. I have to say, I think I had way more fun at this game jam than at almost any other digital jam I've been a part of for a few reasons.

First, there's no tech choices or learning curve. At game digital game Jams, the first thing you have to do (once you have a game you want to create) is decide what technology you want to work in. This can be tough when you have multiple people who all come with different tech backgrounds and make them try to work together. Either you end up choosing teams based on tech that people know, or a few people end up working in tech they are unfamiliar with. This can make many digital game jams more about overcoming technical challenges, rather than overcoming design challenges in the game.

Second, other than the theme of the materials, there was no theme for this Jam. Though originally I thought this was a detriment, I am beginning to think that the lack of theme contributed to making this Jam awesome. In every game jam I've participated in, the themes have been aesthetic. They're themes like "immigration," "extinction," or "deception," and although they offer a good constraint on the Jam (and place everyone on equal footing for implementing an idea), they force most Jammers to think in terms of aesthetic first, mechanic last. This is why most Jammers can't "finish," because they're actually pushing for an aesthetic, rather than mechanical goal.

Last, jamming in board games meant that iteration cycles were really, really fast, which meant that you could focus on and tune the game and the mechanics quickly, which resulted in better games across the board. The game I worked on took about 10 minutes to play, and after initial discussion, we did nothing but play it, with short discussions in between. We probably play tested the game 50 times, each time with slightly tweaked rules to attempt to address problems we were seeing in the previous play through. Iteration times like this not only let you learn more about the game you're creating, but more about game design in general, since you see the results of you actions quickly. This speed of iteration and learning would have been impossible in a digital game jam, since implementing rule changes requires too many cycles. In digital game jams, if you get two to three full playtests in before time is up you're lucky, and that's including for teams that use prebuilt engines like Unity.

So in closing, if you get a chance to participate in a board game jam, you absolutely should. There's less stress, more learning, and way more collaboration. That, and you end up with an actually complete board game at the end, which is super awesome.

5 Games You Should Play

I've been thinking recently that I should make a list of my favorite games of all time, especially as I find it harder and harder to find games that I like. For now, though, I want to mention several games that don't have the wide spread popularity I think they should, even in the development community. I'm always surprised when I'm talking to game developers and bring up specific games that I feel are "cannon" that they haven't played. So here's a list of 5 specific titles I think you should play.

  1. Strife: I mention Strife in conversation a lot, and I'm always surprised how few people have even heard of it. Strife is a plot based, almost open world RPG like first person shooter, based on the Doom 2 engine, and was actually the last game to use the Doom 2 engine. In my opinion, the game was largely ignored mostly because it game out the same year as Quake, and the graphics couldn't compete with the more modern 3D engine. That said, the story is reasonable, the dialog is good to great at times, there are interesting choices to be made (though, unfortunately, mostly in dialog) and the level design is pretty fantastic. If you play Strife, you'll realize why I feel horribly let down by 90% of FPS games. If you can find a copy of the game, you can either play it in DOSBOX, or use the zdoom engine, which will allow the game to run natively in windows.
  2. Star Control 2: Now available in a renamed open source format, there is NO excuse for anyone to not play this game, save lack of time, but even then I'd say you should find the time. Another open world game, Star Control 2 basically gives you a galaxy to explore, and very little direction, at least at the beginning. However, it's very good about chaining elements together, or giving you pointers if you get stuck. The story and dialog are some of the best I've ever encountered in a game. The choices, again mostly though dialog, have actual impact, and you feel repercussions for most things that you do, eventually. Just play Star Control with a pad and paper, because people will tell you coordinates for things, names of stars, and information, which no in game system keeps track of, one of its few failings.
  3. Beyond Good and Evil: A platformer RPG with an interesting story, an interesting mechanic involving photography, great action / escape sequences, and amazing music, this game got passed up by the general buying public partially because the title has nothing to do with the game and partially because there was little to no marking for it. Thankfully, an HD version is being released in 2011, and you should pick it up when it comes out. When you play it, pay close attention to the puzzle design, and how the puzzles build on each other from stage to stage, as well as the variety of encounters throughout the game. In addition, note the various music, camera, and speed tricks that are used to provide the game with a really amazing atmosphere.
  4. Quest for Glory 4: If you know me, you know I can't talk about games without bringing the conversation around eventually to Quest for Glory 4. This is adventure gaming done right, with light RPG elements that keep the game especially interesting. The 4th game in the series I feel is especially interesting because it deals with a lot of really dark and mature subject matter, and although it's standard lock and key puzzles (you don't really have too many choices about how to solve puzzles), very frequently in the game you'll find yourself wondering if you actually did what was "right". The story aside, the game also has fantastic puzzle design, and does not contain any of Sierra's traditional "unsolvable" puzzles.
  5. Intelligent Qube: This game is almost unknown, and actually extremely rare. It's a real time puzzle game for the PS1 where you're a guy on a big box trying to get rid of other boxes before you get crushed by them. The game is exceedingly hard without practice, but the style of it is amazing, specifically because of the music and sound. It was so insanely epic for what was, essentially, a pretty standard puzzler. If you can find a copy (or emulate a copy) I highly recommend you do.

Simplicity in AngelXNA

I know I've promised tutorials on AngelXNA, and I actually have the first one written, but I've been distracted by crunch on my current project and don't feel comfortable just posting the first portion without more to follow. In addition, the first tutorial feels way too long, so I'm hoping to add some minor changes to Angel to make getting started even easier, specifically by setting up GameManager and default screens in ClientGame, rather than forcing you to make them yourself.

But enough about that, this post is about rendering.

Angel is really nice in that it makes a lot of things really simple and really transparent. With a few exceptions, everything does what you expect. There are very few pre-conditions for any given call in Angel, so you don't have to worry about whether you've set up X or Y before calling things, or worry that calls will fail because objects weren't in the right state. That just doesn't exist In Angel. With that mind, I'm looking for a way to add a piece of complexity and functionality to Angel without sacrificing the external simplicity.

In AngelXNA, all actors render as a rectangle by default (we didn't port over circles from Angel C++), so by just putting an actor in the scene, you get something rendering. If you want to make it a sprite, you call Actor.SetSprite or (simpler) Actor.Sprite = "ContentFile". Animations follow a similar pattern, loading a sequence of files using Actor.LoadSpriteFrames (or, again, you can use Actor.Sprite = "ContentFile_001" and it will automatically load the sequence). Then you can play the animation sequence using Actor.PlaySpriteAnimation.

The problem is, now, I want to add two additional render paths, one for rendering static and animated sprite sheets, and one that allows you to specify and load multiple named animations (so you could say Acor.PlaySpriteanimation("Jump")). This is easily done by either inheriting from Renderable or Actor, but inheriting from Renderable loses all of the functionality in Actor, and inheriting from Actor means I can't use these render paths in other sub classes of Actor (namely PhysicsActor). In addition, if these render paths were reusable *outside* of actor, it might make alleviate some problems we've had adding things as Actors that aren't just to get their rendering properties.

So my question is, how do I make this simple? One option is to just add more methods and properties. Actor.SetSpriteSheet(), Actor.SpriteSheet, Actor.LoadSpriteSheetAnim() etc. This does have the benefit of being consistent, but doesn't make those render paths reusable. I could create an IRenderPath interface and have one for each render path, using SetRenderPath to assign a specific render path to an Actor and remap the current functions to creating those render paths. In addition, it means the SpriteSheetRenderPath could make use of a reusable SpriteSheet for both tilled maps as well as character animations. This, however, I feel makes Angel overly complicated. Maybe some combination of the two makes more sense?

I feel like I've spent way too much time thinking about this, and would love to get it implemented, hopefully soon.

Get Thee To A Menu

This post is about Fable 3.

Generally, when talking about the Fable series, I talk about the decisions you can make in any given game and how I find them horribly lacking, but today I'm going to avoid that whole can of worms and talk more about how disappointed I am in other aspects of Fable 3. Specifically, I'd like to talk about Fable 3's menu system.

Or, really, its lack of a menu system.

I haven't looked at reviews of the game yet, so I don't know what other people are saying about Fable 3's new immersive menuing, but regardless of whether or not game reviews or community at large likes it, I freaking hate it. In any game, I want a menu system to do three things for me:

  1. Give me all the information I need to know
  2. Present me that information in a clear manner
  3. Allow me to get the most often referred to information quickly.

Fable 3 fails on all three counts.

Let's start with number 3, since here is where I feel Fable 3 is most egregious. Fable 3 is, first and for most, a quest driven RPG, and, as with any quest driven RPG, there are a few pieces of information I access repeatedly: my map, my quest list, and my advancement progress.

Advancement for your character is shown quickly and easily: any time I get experience, it shows me just how much experience I have and how much I can spend. It breaks immersion, but the information I need is there when I need it. Advancement for weapons, on the other hand, requires that I: press start, wait for a short load, walk to the weapons room (or, if I've been playing a while and know the shortcut, press left), wait for a short load, walk to my sword, press a to look at my sword, then press y to see my advancement on said sword. This is neither quick, not easy, and is actually fairly hidden from view. I didn't know you could even do this until playing the game for over 5 hours when I stumbled on it accidentally.

The quest list is even worse, specifically because changing quests is such a pain. Just to look at your active quests, you have to: press start, wait for a short load, walk to the map (there's no short cut key for this), press A to bring up the map, wait for a short transition, press Y to bring up your active quest list, select the quest you'd like to activate, press A to select it, press A to confirm it, then press X to fast travel to its closest location or B to not. This fast travel confirmation (and loading screen if you press X) occurs even if you are already in the same area as the quest. Again, this is neither quick, nor easy, AND I STILL couldn't find it until I stumbled on it accidentally. After 6 hours of play.

Then there's the map, which I've already described how to get to. However, what I didn't describe is how that map doesn't contain the single most important piece of information you can have in a semi-open world RPG: it doesn't show the player's current location in relation to everything else. Now, I can understand how that's more immersive, maybe, but it's a piece of information I want that doesn't actually spoil anything about the game.

I still can't find a way to gift things to friends without coming across their orb in the world. If there's a way, it's so well hidden as to be a useless feature.

The funny thing is, Fable 3's best UI comes through when it stops trying to be stupidly immersive for no reason and just gives you the information (like the player advancement). If they'd just thought for a minute about how often people access the map and quest lists in an RPG, they would have made start take you directly there, instead of requiring three clicks through.

Regardless of any advancements Fable 3 made mechanics wise, they're overshadowed for me by the terrible user interface design. I cringe any time I have to enter a menu in that game. About as much as I do when I hear anyone talk, but that's another post.

Immigration Jam Post Mortem

This past weekend was the Boston Immigration Game Jam, and like previous Jams, I'm going to do a quick post mortem about my experiences, not only because I think it will help others, but because it will help me as I prepare for my next game jam. For this Jam I was in a team of 5 on day one, which included 3 musicians, which later went down to 4 when two of the musicians decided to not show up for day 2 and one new programmer joined the team.

The game we ended up making was called "Cultural Exchange" and was supposed to be about managing a country, trying to attract the "right" sort of people while keeping out undesirables. To do this, you would enact legislation to make your country more appealing to some people, and erect fences and the like to keep out undesirables. However, people in the country wouldn't like things being too restrictive, since they value their freedom, so it was a constant balancing act.

Now I know normally I start with what went right at the jam, but this time I feel what went wrong is more important. So here we go:

What Went Wrong

  1. Not having a clear idea: While the description is fairly clear, neither me nor Kevin had any idea how we were going to get it working. We didn't actually get anything designed until very late in the night, and even that was just kind of border-line. Since we didn't have a clear idea about how the game would play, we had no idea what our restrictions were.
  2. Using Flixel: Now, no offense to Flixel, but I was not impressed with my first outing with it. This is partially linked to not having a clear idea of what we wanted to do, and not having a clear understanding of the limitations of Flixel. I spent 90% of the first day fighting with ActionScript and Flixel, not only because I didn't understand Flixel's limitations, but because Flixel has some issues with transparency, some of which it inherits from Flash. I spent at least 3 hours trying to move some buttons off screen, only to throw up my hands in frustration. In addition, we were using FlashDevelop, which does not have a debugger included for Flash, which made dealing with all the problems that much worse.

    I took 3 learning points out of my Flixel experience, which don't actually relate to Flixel at all:

    1. Always use something you're familiar with for a game jam, even if it's not the best tool for the job.
    2. Constrain your idea to what you know is possible in the tool you're working with.
    3. Do not take platform into account. If you really like your game after the game jam, you can always port it to a different platform.
  3. Too big a scope: Out game had way to big a scope for our time frame. There was just no way it was getting done.

What Went Right

  1. Switching to AngelXNA: At about 10 on Saturday, I switched all of our code from ActionScript to C#, and all of our Flixel code to AngelXNA. I was too pissed with Flixel's limitations to deal with learning how to get around them, whereas I knew the limitations of Angel really really well, and I could get around them very quickly (see point 3a). Even though this meant losing a programmer on the project, it still ended up well (see the next point).If nothing else, Angel, I've realized, is EXTREMELY transparent. I find pretty much everything does what you'd expect. That said, getting started up in Angel is hard, and I do need to do some tutorials for it in the near future.
  2. Having a dedicated designer: The second day, Kevin ended up doing only design. This was the ONLY way we actually were able to finish at all. Kevin ran through turns on paper, and looked into how legislations would affect the population on each turn. Looking back at other Jams, I think we could have done better if we'd had someone we dedicated as "designer" to look into these problems earlier, rather than playing it by ear the whole time.

Generally this was a short Jam, and I went into it already tired, so I wasn't super psyched about it. But I think I learned a little bit more about jamming, and some things I really want to add to Angel for the next jam, so keep an eye out for that.

My Favorite XBLIG Games

Something that bothers me about XBLIG is that too few good games get the spotlight. For some reason, some really good games get passed over in favor of games like "Z0MBIES" (which anyone who knows me knows I'm not a huge fan of) and "Missile Escape." The front channel even advertises crap games like "Try Not To Fart." And this angers me. These games aren't interesting. In many cases, they're one off jokes, and they don't interest me in the slightest.

So, I'm going to quickly go over some XBLIG games that I have enjoyed a lot and have been passed over in Top Rated and in the news.

Lumi

Lumi is actually the reason I'm writing this post, as I feel as it's being completely overlooked and underrated.  The first thing that stuck me about Lumi is that it's really pretty. The second thing that struck me is that it has a really interesting movement mechanic which makes up most (not all) of the gameplay. You move by attaching yourself to spinning disks, and then launching yourself out. You're attracted to disks by using the same color (one of the triggers) and repelled by using the opposite. You move around like this, collecting fireflies to relight the world, attacking evil bosses along the way.

The only reason that I feel that Lumi is anything short of a 5 star game (it's certainly better than "Missile Escape") is that people are rating it low because it has the highest price point available on XBLIG. But I've played Arcade games less pretty, less polished, and more frustrating than Lumi. I feel like it deserves a bit more recognition.

Ninja Bros

Ninja Bros was recommended to me by friend and former colleague Darius, and it's actually really awesome. The gameplay is simple: you have a ninja that you can move around, and he jumps with a given button. Get him to the exit. What makes the game interesting is when you're controlling multiple ninjas. Each of them is controlled by the same thumbstick, but each has a separate jump button. In harder levels, you have to coordinate each ninja, when they jump and when they move, to try to get everyone to the exit in a reasonable about of time.

The game is surprisingly complex for something so simple, and it gets to be very hard. It's definitely worth paying for and playing through.

Miner Dig Deep and Soul Caster

Both of these games are on the Top Rated, so I won't take too much time going over them.

Miner Dig Deep isn't that interesting except in its polish. The game is the definition of grind, but it does it very well, and thus deserves a mention.

Soul Caster is an interesting twist on the RPG / Tower Defense genre. I hate tower defense games, but I enjoyed Soul Caster, which is saying something.

Others?

What to others think? What XBLIG games aren't getting their fare share? Have I missed something I actually might enjoy?

On Motivation

I've been thinking a lot recently about motivation. Specifically, what was my motivation for wanting to get into the game industry? What was it that drew me towards it despite horror stories of crunch, burnout, and under-appreciation? I decided to get into the game industry despite all of that, but why?

I know for many, the answer is simple: they love games. Others love the community of game developers.

I got into the game industry for a different reason. Sure I loved games. Sure I loved the community of game developers, but I wanted more.

In his recent retirement letter, J Allard talks about his initial decision to work at Microsoft:

During every interview, I'd challenge, "'A computer on every desk and in every home' is quaint, but why stop there?" and the typical response would be along the lines of, "That's just our ante." I liked that... +1 Microsoft.

I couldn't believe it, but it was impossible to dismiss the similarity and authenticity I felt in every conversation. On the flight home, I contemplated these discussions, the passion and IQ of the people I had encountered and their invitation to create my own space to drive a bigger agenda alongside them. It clicked. The "computer on every desk..." rhetoric was a ruse, the real purpose and ambition of these people was much, much broader:

"Make the world a better place through technology."

Like every idealistic college hire, this was the unicorn I was looking for. I wanted to do something bigger than me – "change the world!" – with a bunch of people who respected and could augment my superpowers. I had visited the Justice League of Geeks and they had invited me in and had shown me the secret handshake.

When I wanted to join the game industry, I had a similar thought process. I wanted to make the world a better place through games. That bears repeating.

I wanted to make the world a better place through games.

I think my problem now is that I was also very specific on how I wanted to do this. Certainly, there are ways to make the world better through educational games, games for health, or so called "serious games," but this wasn't particularly what I was thinking.

Growing up enjoying adventure games (specifically Sierra adventure games, many of which had more serious tones than other games in the genre) as well as many really good books, I wanted to see games reach a level of literary expression that rivaled our best works of literature. I wanted to see games deal with more mature themes, not in terms of sex and violence, but in terms of how we, as people, interact. I wanted games to take a hard look at subjects like ethics, racism, political freedoms, war, peace, trust, and betrayal among others. I felt games were in a unique place to do this because, if they allowed you to make hard decisions and see the impacts of those decisions, the lessons would necessarily be more poignant. And I believed it was all possible through story, given enough talent and enough thought.

Interestingly, for my first 7 years of GDC, every GDC only made me more convinced that this was possible, and that there were others out there thinking the same things. I would leave every year more invigorated at the possibilities of our medium, and that it was only a matter of time before we started seeing really good literary quality games.

2010 was year 8, and I came out of it a little less hopeful, for a few reasons.

First, I've realized GDC is a self-selecting group of individuals who want to discuss the "hard problems" of making games. These are the types of people that, even if they don't want the same things I do from games, they do want to discuss it. They are excited by the possibilities, even if they don't believe it to be interesting or possible. And with that said, there were fewer people talking about the hard problems this year. It's hard to explain, but GDC this year (for me at least) felt like the industry had exhaled, so to speak. Some of the spark was gone.

Second, I haven't seen games moving toward that direction in a long time. Investigations into actual ethics in games, and real consequential action I think hit its peek with Ultima 4, and with the exception of a few bright spots here and there (Ultima 6, Deus Ex), it hasn't resurfaced. And I feel both the game industry and the gaming culture moving away from such games.

Third, even if I was able to write such a game, I don't think the audience is there for it. Not enough people would buy the game for anyone to justify the effort needed to make it happen. Such a game doesn't work as a small, simple game, or in bite-size chunks. It's an undertaking that seems to provide very little reward. Generally, I think this is true for culture across the board, not just for games. Our media consumption is leaning towards pop-fiction in all forms. Don't-make-me-think media, or (more likely) tell-me-what-to-think media.

Lastly, even if the market were there, I cannot point to a company who shares this ideal. I can point to people (some indie developers, some of the art game crowd, some IF writers), but no groups. There are no Microsoft's. Even Microsoft isn't Microsoft anymore, in the game industry or out of the game industry.

I wanted to make the world a better place through games.

So my question is, given that I've found that my original motivation for entering the industry fading, how do I keep myself motivated? I don't want to leave the industry, but without this initial motivating factor being made manifest….. perhaps there are better ways to make the world a better place? Through technology? Through other ways?

I know this whole blog post sounds ridiculously whiney and / or pompous. And I'd like to be clear that I'm not leaving the industry any time soon, but I still feel my old motivations hanging over me. Maybe I'm getting older, and getting excited over little steps isn't cutting it for me anymore. Now, I'm sure someone can point out games or movements that I'm missing, but from where I'm sitting, I feel like real innovation and evolution, especially in the story department of games, is hard to come by, which is making it hard for me to see a place where I'd be comfortable. Maybe I'm just wearing blinders and ignoring signs that this is taking place? Here's hoping.