Jeff On Games

Just to keep people in the know, I'm giving two talks in the coming months. The first will be at Games Forum Germany (site is in German, obviously, thought the talk will be in English) on either January 27^th or 28^th, I don't really know which. The talk is titled "Data Driven is Half the Battle" and will be talking about why just setting up data driven code isn't enough, and how (both from a high level and a low level) you can create a system for giving others on your team the ability to edit your data quickly and easily.

The second talk will be at GDC, as part of the Game Career Seminar, which takes place on the Friday of the conference and is focused at students. That talk is called "From College to Industry: 20 Lessons for Getting the Most out of your Early Career" and is about, well, getting the most out of your early career. It is basically a lessons learned talk about my 10 years attending GDC, and my 6 years in the game industry. While that isn't a really long time in the game industry (anymore), I feel that some of the lessons I've learned over that time will only really be apropos to students for a short time, and thus it is most useful for me to give the talk now, when it will be most useful to them. I will be practicing this talk twice in front of student groups around the Boston area, once at WPI and once at a local SIGGRAPH meeting, to make sure that the talks really hit all the right notes and lessons and are as useful as possible to the GDC student population.

Both talk's slides will be posted on line after the talks, and the GFG talk will probably be cross posted to the Toolsmiths, since it is a tools related talk.

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 4^th 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.

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.

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.

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.

I've been talking on twitter about working on some stuff involving 2D soft shadows. I was going to write a long blog post about how I got 2D soft shadows working in XNA using the GameDev article in combination with Catalin's implementation and Christian's implementation in D. However, trying to write the post, I wasn't sure if I could make it any clearer, as I'm not sure if I understand it completely myself.

So, instead, I'm just going to post the XNA port I made almost directly from Christian's D implementation without much comment. I will say that, instead of using the images that both Catalin and Christian are using, I've move most of that into shaders. This isn't necessary, but it's in preparation for some other stuff I want to do later with this project.

So if you're interested, my XNA implementation is here. Enjoy!

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?

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.

It's been a while since I posted, but a lot's been happening. If you've visited the site, you probably noticed a theme change, but more importantly, you may have noticed I am no longer at Orbus Gameworks.

There are many reasons I decided to leave Orbus, and maybe some day I'll write a long blog post on the subject, but the short story is that I decided it was time for me to get back into creating games full time. Although Orbus focused on game middleware, the technology we were working on wasn't really game development, and I felt like I was getting more and more behind in the skills and systems that are essential to being a programmer in the game industry.

So I have moved on to another start-up, but this time a game studio: Fire Hose Games.

Working at Fire Hose has been an adjustment, though not a bad one. Because of the size of the team and the schedule, I've been forced to think and program very differently from what I'm used to. It's pushing me out of my comfort zone, which is always a good thing, if only to see different ways things can be accomplished, even if they don't jive with the way you work as a programmer.

Generally, I'm really looking forward to my work with Fire Hose, I'm excited about our product, and I'm looking forward to having shipped another game.

I've been spending a bunch of time reading about continuations and microthreading recently, just trying to wrap my head around them and find areas where they might make sense, specifically in C# using the ISO CLI systems. Of course, the example that most people give is AI, like so the one provided by this article:

 
IEnumerable Patrol ()
{
     while (alive){
          if (CanSeeTarget ()) {
               yield return Attack ();
          } else if (InReloadStation){
               Signal signal = AnimateReload ();
               yield return signal;
          } else {
               MoveTowardsNextWayPoint ();
               yield return TimeSpan.FromSeconds (1);
          };
     }
     yield break;
}
 

Now, implementation details aside (I'm not a fan of the authors implementation of the scheduler), you can then have a scheduler for all of your microthreads that will run each method until it terminates. Run one (or more) of these schedulers in a background thread and everything's awesome right?

Well, I'm not so sure. I have questions about this myself. For example, I would think that this pattern is more useful in cases where you have a lot of things that need to be done in sequence, but potentially in other threads or for multiple frames. For example the "AnimateReload" state from the example. Well, what if that state looked more like this?

 
       if (NeedsReload)
       {
            Signal coverFound = BeginFindCover();
            yield return coverFound;
            if (CoverPoint != null)
            {
                 Signal atCover = MoveToCover(CoverPoint);
                 yield return atCover;
            }
            Signal reloadAnimation = AnimateReload();
            yield return reloadAnimation;
       }
 

This is a more common use case in my mind. Have a procedure that takes many frames of execution and has portions that can be delegated to background tasks (such as path finding, which might take a few frames) and have them written linearly so that it's easier to read.

Here's the problem. Because we've now put the "Alive" check farther and farther away from the actual call, we've ended up in a situation where, at any time, the AI can die, and thus its microthread will need to die with it. To combat this, we'd have to check if the AI is actually alive after every yield, creating this code:

 
     if (NeedsReload)
     {
          Signal coverFound = BeginFindCover();
          yield return coverFound;
          if (!Alive)
               yield break;
          if (CoverPoint != null)
          {
              Signal atCover = MoveToCover(CoverPoint);
              yield return atCover;
              if (!Alive)
                   yield break;
          }
 
          Signal reloadAnimation = AnimateReload();
          yield return reloadAnimation;
      }
 

To say nothing of if the state of the AI was forcibly changed for whatever reason (say, for example, if a Team AI Manager has told him to start running away, or regroup, etc). The only way I can think to combat this is through a special AIYield function which would handle most of that, but even then, I find it hard to think of a way to tell the system it needs to break from the current update thread and start a new one. Reschedule?

What do others think? Am I over thinking this? Am I thinking about this the wrong way? Am I using the wrong tool?