≡ Menu

Bandwidth

A while back I wrote a simple post with instructions on how to put together some simple AI behaviors in Unity. This is shocking to me in a lot of ways, but my web provider keeps suspending my account because this project gets too many downloads. So I moved the file to Dropbox so that iPage will hopefully stop taking down my website. All of the links should be updated now, and the project should be available once again.

{ 0 comments }

GitHub

I know that I’m totally late to the party when it comes to GitHub, but I finally spent some time this weekend learning about the technology and I think it’s absolutely awesome. I’m disappointed in myself that it took this long, but better late than never I guess. I love pushing the social aspects of open source development, and I’m a fan of anything that makes contributing to these projects easier. GitHub seems like a great implementation, and a solid step forward.

I’ve already put one of my old projects up there (https://github.com/spgar/Progress), and I’ll be putting a bunch more up in the future.

{ 0 comments }

Decade

I got my first game programming gig in May of 2003 at Blue Fang Games (RIP). I left the game industry in 2012 after the death of 38 Studios (RIP). That means I programmed games professionally for just under a decade. That’s a long time, I must have learned something right?

Here’s a list of some things I’ve learned off of the top of my head:

SYSTEMIC: Problems are systemic

I’ve worked for a number of different companies, and have seen the same pain points crop up again and again all over. Different people, different products, different publisher, different console, different target demographic, different management different companies… same exact problems.

I think this means that a lot of the difficulties and pain faced when trying to ship a game are largely inherent to our current understanding of the development process, and don’t generally reflect the implementation details in particular. Different management teams can help or hurt a bit here and there, but it takes a ton of effort to truly fight the system.

BLAME: Be careful with the blame game

Related to SYSTEMIC above, it’s often very tempting to throw blame around from your personal viewpoint. “If person X hadn’t done Y then everything would be perfect!” I’ve personally been guilty of this type of thing in the past, but in retrospect it was never really productive at all. Most of the time the person easiest to blame is just a symptom and not the actual underlying problem.

Publishers are the #1 most blamed entity in game development, listening to some people you’d think that everything to ever go wrong in every game’s development is the fault of the publisher. Now I’m not saying that publishers are blameless (the developer-publisher relationship is completely degenerate), but they are too easy of a target. I’ve worked on several projects with no publisher at all, guess what? All of the problems that people on past projects blamed on the publisher were still there.

Blame, blame, blame.

MISTAKES: I make tons of mistakes

Programming is really hard, and I make tons of mistakes. I think everyone does, but a lot of people don’t seem to want to admit it (consciously or subconsciously).

As a programmer, the counterattack is to use the computer to help you catch your mistakes. Aggressive use of unit tests, static code analysis, interactive testing, etc. These can help to catch a lot of the mistakes I make before they get out into the wild and cause other people pain.

In the past I have been surprised many times by programmers who do not take full advantage of these resources, especially on projects with full testing frameworks.

Here’s a conversation that should never happen:

Developer A: “Hey, when I boot up the game everything crashes immediately. I’m pretty sure it was your change c12345 that caused it.”
Developer B: “That change shouldn’t have caused a crash.”
Developer A: “Did you try launching the game?”
Developer B: “No, it shouldn’t be causing a crash.”

Here’s another conversation that should never happen:

Developer A: “Hey your change c12345 is breaking this unit test.”
Developer B: “Hmmm… I’m not sure why that change would break that test.”
Developer A: “Did you run the tests?”
Developer B: “No, it shouldn’t break any tests so I didn’t bother.”

These are pretty much word-for-word conversations that I’ve actually had. My advice is that instead of thinking hard and theorizing about if a change will crash the game on boot or break a unit test, just launch the game and run the tests.

Also to be clear, I’m not saying that I’ve never caused a crash or broken a test before – but I can say that I’ve always at least put in a decent effort to make sure that I’m not checking in code that’s going to break the product for everyone.

SCHEDULES: It’s hard to get value from a schedule

Creating accurate schedules is extremely hard, and they’re often wrong. The best explanation I’ve seen for why is this post here. In my experience this is sort of just the reality of the situation: making schedules is hard and time consuming, and they’re usually not very good or accurate. It’s a bummer.

Even with all of this effort going into creating a schedule, I haven’t really worked on a project where the schedule was used to make important decisions or really taken seriously at all. Most often a lot of energy went into creating a schedule, and then everyone would just sit around and get frustrated as we fell behind without really doing anything about it.

Actually, something was typically done about it: initiate crunch mode. Then we would just fall farther behind. More on that later.

FEATURES: Lots of features will be cut, even if nobody will admit it

Related to SCHEDULES above, cutting features seems to be one of the most difficult thing to make happen in any game development process. Nobody ever wants to do it, it’s like pulling teeth! But here’s the thing: Features will be cut. Has a game ever shipped with every desired feature? You can either proactively cut features and craft your game accordingly, or you can try to do everything and run out of time.

If you run out of time, then you have just cut a bunch of features at the absolute worst possible time: the end. The earlier you can cut features, the better. Every feature cut makes all remaining features a bit easier to implement. Less interaction between features means less complexity. Every cut feature helps defines the possibility space of your game, and the earlier this happens then the earlier you can enhance the positive aspects of your product.

I have found that deciding what not to do is incredibly productive.

TEAM: Multidisciplinary teams are interesting

One of my favorite parts of working in the game industry was the multidisciplinary nature of the development team. There are few jobs in the world where you can regularly work together on a daily basis with programmers, concept artists, animators, musicians, authors, screenwriters, producers, level designers, and system designers.

I always loved this aspect of the job, but it does bring a bunch of potential challenges. Crossing the divide between disciplines isn’t always easy, and it often leads to conflict. One thing I frequently noticed is conflict arriving over vocabulary. A programmer is trying to work something out with a designer and argues using ‘programmer vocab’, the designer doesn’t understand completely and gets totally defensive, the discussion goes nowhere. One piece of advice I can give when working with other disciplines is to be very careful with vocabulary, I’ve found that things go a lot better when everyone understands the words involved.

REWRITE: Don’t be afraid to rewrite

Making the decision to rewrite a system or feature shouldn’t be taken lightly, but it can be the right thing to do. There’s nothing worse than dumping time week after week into a system that hasn’t been designed correctly and needs a rewrite. I find that sunk costs are often overvalued, and the word ‘rewrite’ is frowned upon. Make an honest assessment of the situation and decide what the best course of action moving forward is. Don’t get defensive, don’t be upset that it wasn’t done right the first time – make the best decision for your product.

Rewriting isn’t something that is always done to major feature/systems, smaller code refactors are often just as helpful. Related to MISTAKES above, I often find that my initial code implementation wasn’t so great in retrospect due to unexpected usage patterns, changing surrounding code, or whatever. When I’m evaluating potential solutions to a problem, I always include “How easy will this be to refactor?” in my heuristic. Chances are it’s not the ideal solution and I’ll want to refactor it at some point in the future, so the easier the better.

Go forth young Jedi and refactor.

CRUNCH: Crunch is poison

Crunch is a horrible practice, and a terror that is damaging the game industry. The culture has been poisoned, and the antidote is nowhere in sight. Sadly, I don’t think the antidote is even really wanted.

Maybe things are different for other disciplines (art, QA, whatever), but as an AI programmer I really feel the effects. Programming is extremely difficult, and when I’m not at my best I just can’t really do it. I’ve been in ‘death march’ scenarios before, seven days a week, 100 hours per week. Not surprisingly, my production just bottoms out. Every day that passes I accomplish less and less. I get frustrated that I’m not accomplishing much, and as a result I end up sad and frustrated. The next day I accomplish even less. It’s horrible.

There are countless studies that show that crunching doesn’t increase software engineering productivity, and all of my anecdotal evidence points in that same direction. One incident I’ll always remember from early in my career is staying at work until 3AM with two extremely smart engineers working on a problem together. We came up with a great solution and went home to crash, feeling very proud of ourselves. I came in the next day and realized within 5 minutes that our solution was terrible and would obviously never work. Sure things like this also happen during ‘sane’ development hours, but during crunch it seems to happen constantly.

I honestly think crunch is now a non-starter for me. Moving forward I just can’t be involved with an industry where crunch is such an ingrained part of the culture. Since leaving the game industry I’ve had actual NIGHTMARES about being back at a game company, crunching.

SADNESS: I don’t want to do this anymore

As a child my dream job was game developer, and I really sculpted my early life to make it happen. Everything worked out according to plan, but fast forward ten years and I don’t want to do it anymore As I get older I guess I value different things. Stability is more important to me. I’m sick of every company I join ending up on life support within a few years. A lot of the cultural aspects that appealed to me as a younger man just don’t appeal to me as much.

There are lots of positives about the game industry, but for me the scales have tipped too far in the other direction. I still love working on games, and I think I’ll always be involved in some degree on a hobby-level, but unless there’s a major shift in the industry I don’t think I’ll be back professionally.

I guess that’s enough for now. I have plenty more to say, but it’s a beautiful day and I want to get out there! Maybe I’ll follow up with a second post at some point.

{ 0 comments }

Compensation

Everything that I have posted on this website is the results of work that I have done for fun, as a hobby. Any sort of payment is flattering, but totally unnecessary. I update so infrequently, and can’t really supply daily support with my schedule, so I’d feel uncomfortable even putting up a donation button or something similar.

If you use something on here and feel the desire to make a donation, then please find someone in your life who needs something and buy it for them instead. Or find a charity that speaks to you and give some money to them. Or you could donate to One Fund Boston. Something bad happened in Boston recently, and money is being raised to help the people affected. This is something very close to me.

Again, I’m flattered but it’s not necessary!

PS: I can’t believe it’s been a year since I updated this website! A busy year, hopefully I’ll find time to make something new soon.

{ 2 comments }

Three Simple AI Behaviors v0.2

Almost a year and a half ago, I wrote up a small Unity3D project that demonstrated a few basic AI behaviors (patrolling, wandering, following). You can check it out here. I get more emails and questions about that simple project than anything else on this website – I guess simple projects that demonstrate the basics of game AI are something people are interested in!

Anyway, this project had a major problem – the sample NPCs didn’t deal with changes in terrain height well (or at all). This has been bugging me for a while, but I haven’t had a chance to fix it until tonight. Check out the project page for a new version, complete with NPCs that don’t burrow into the ground at the first sign of a change in the y-value of the terrain underneath their feet.

{ 4 comments }

ANGELINA

I always try to keep my eyes open for interesting game-related research happening in the academic AI world, and this week a project called ANGELINA is getting a lot of people excited – myself included.

Michael Cook is a PhD candidate at Imperial College in the UK, and has been working on designing an AI that can design games. This is a topic I find fascinating, and something I’ve actually messed around with personally in the past – but never really had the free time to pursue on any sort of deep level. It’s fantastic to see that someone is working on this problem legit, and I can’t wait to see where he takes this in the future.

I’m particularly excited about the fact that the output of his research is an actual product that people can play with, interact with, and think about. A lot of game-related research stops short of taking this step, and it really raises the barrier of entry for a dude like me. I’ll definitely be playing close attention to ANGELINA moving forward!

{ 0 comments }

Chordskilz

I got a message from SonicViz recently that they used my Progress framework in their new game: Chordskilz! I was pretty psyched to hear from them, I always love to hear when someone is able to use the code that I put up on this blog.

Chordskilz is “… a music game designed to give you a total active listening workout in a core area of music ear training: Harmony, or chord recognition.” If music is your thing, check it out!

{ 0 comments }

Upgrade: The Card Game

In the early 90s I was a small child OBSESSED with Magic: the Gathering. I played it for the first time at boy scout camp, and it was pretty much the greatest thing I had ever experienced. After learning about the game, I immediately set out to create my own card game. I’ve always loved making games even more than playing them, and card games are relatively easy to make: come up with a sweet idea, grab a stack of index cards, railroad some people into playtesting, and you’re good to go.

The results were, unsurprisingly, horrible. At ten years old and lacking anything resembling design sensibilities, the deck was seriously stacked against me. On top of that, I was so obsessed with Magic that anything I made was basically just a bad version of my new favorite game. My favorite aspects of Magic were the strong distinction between colors, deck construction, and the land mechanic to represent resources. All of the games I made had something resembling each of these aspects, and were just terrible. Eventually I realized that Magic was already a good version of Magic, so I’d need to think of something pretty different. I can remember two specific games that I made at this point.

At first I thought it would be cool to make a cooperative game where players shared a deck, had to work together to survive, and each had a secret goal as a win condition. It was sort of like Munchkin, except way overcomplicated and with secret, randomized win conditions instead of ‘reach level 10′ for everyone. I think the idea here was pretty decent, but the game balance destroyed the experience. The majority of test games were just not fun, players were generally far too powerful/weak and I wasn’t able to get it right. It was also way too obvious which ‘secret goal’ players had based on how they played the game. DudeX doesn’t want to spend any gold? He probably has the ‘collect 500 gold’ win condition. Also, it was possible for everyone to lose if the players wiped, and this happened too often.

The other card game I can remember making around that time was called Upgrade. When I saw the Experimental Gameplay Project theme for November (Upgrade), I wanted to reproduce that game as best I could. I no longer have the original game (index cards), but I still remember it pretty well. Back then, one of the constraints I was tied to from being a Magic fan is that different cards have to cost different amounts (roughly) based on their power level. I can remember deciding to make a game where each player just played one card per turn. Based on my previous efforts, I also knew that I wanted to make something much simpler than what I had been working on. I was already starting to learn that complexity was a killer. Upgrade was the result, and it was the first card game I made that I thought was actually halfway decent to play. I was really into Civilization and SimCity around that time, maybe there was some influence?

I’ve done my best to reproduce it here, you can download it in a PDF. Just click the image below. Print it out, cut up the cards. Shuffle up, and play. There’s a sheet of rules. It’s all pretty simple. If you want to be super fancy, you can print the game on nice card stock or something.

Download the PDF here or click the image below.

This is not exactly the same Upgrade I made way back when, but it’s not off by a lot. The rules are very close, and the action cards are probably at least 75% the same (in functionality, not in name). The original version didn’t have any artwork – my wife was kind enough to whip some images up for me to use on this version. We played a bunch of test games, and actually had fun – so maybe someone else out there will have fun with it too. I only really tested this with two players, but it should theoretically work ok with three or more.

I used index cards and the Magic Set Editor (with a modified Dvorak theme) to develop this game. I was planning on adding ‘flavor text’ to the products, but was busy with holiday stuff and never got around to it.

Feel free to send me ideas for cards, balance suggestions, etc. I had a lot of fun working on a non-video-game game for the EGP. The next time I’m at my parents’ house I’m going to search my old bedroom and hopefully find Upgrade in its initial form. If I manage to track it down, I’ll make a comparison post.

Thanks for reading!

{ 2 comments }

Four Games About Failure

Here are four games I’ve made recently about failure:

I don’t know why I’m so obsessed with these ideas of games where the player can’t succeed, but it’s pretty much the only concept I can think of anymore. I think it’s pretty clear that these little experiments are declining in quality, so I’m going to to try to focus on some new concepts.

This month’s Experimental Gameplay Project theme is: Upgrade.

Maybe this is a good time to get started?

{ 0 comments }

Combat Chatter as AI Enhancer

Here’s one of my favorite little pieces of game AI wisdom from Jeff Orkin:

There is no point in spending time and effort implementing squad behaviors if in the end the  coordination of the A.I. is not apparent to the player. The squad behavior layer gives us an opportunity to look at the current situation from a bird’s eye view, where we can see everyone at once, and find some corresponding dialogue sequence. Having A.I. speak to each other allows us to cue the player in to the fact that the coordination is intentional.

Vocalizing intentions can sometimes even be enough, without any actual implementation of the associated squad behavior. For example, in F.E.A.R. when an A.I. realizes that he is the last surviving member of a squad, he says some variation of “I need reinforcements.” We did not really implement any mechanism for the A.I. to bring in reinforcements, but as the player progresses through the level, he is sure to see more enemy A.I. soon enough. The player’s assumption is that the next A.I. encountered are the reinforcements called in by the previously speaking A.I., when in reality this is not the case.

Wherever possible, we try to make the vocalizations a dialogue between two or more characters, rather than an announcement by one character. For example, rather than having the A.I. cry out in pain when shot, we instead have someone else ask him his status, and have the injured A.I. reply that he’s hit or alright. When the A.I. are searching for the player, rather than having one A.I. say “Where did he go?”, we can have two A.I. in conversation where one asks the other if he sees anything. The other A.I. may respond with a negative, or call out a known or suspected position.

We also use dialogue to explain a lack of action. If an A.I. taking fire fails to reposition, he appears less intelligent. We can use dialogue to explain that he knows he needs to reposition, but is unaware of a better tactical position. The A.I. says “I’ve got nowhere to go!”

A gamer posting to an internet forum expressed that they he was impressed that the A.I. seem to actually understand each other’s verbal communication. “Not only do they give each other orders, but they actually DO what they’re told!” Of course the reality is that it’s all smoke and mirrors, and really all decisions about what to say are made after the fact, once the squad  behavior has decided what the A.I. are going to do.

— Jeff Orkin from Three States and a Plan: The AI of F.E.A.R

I always love to hear about little smoke and mirrors tricks that developers can use to make players believe that AIs are doing more advanced things than they actually are. The technique that Jeff describes here is one of my favorites – it adds so much depth without really adding any depth at all.

While playing games for fun, I’m often on the lookout for examples of this. Recently I was playing RAGE and listening to the AIs yell at each other during combat. At one point one of them yelled, “He’s flanking us!” Maybe technically I was flanking them, but at the time I was running around in a circle like an idiot trying to get a swarm of dudes off of me. I was firing constantly and throwing out grenades and stuff. I wasn’t doing anything resembling strategy or tactics, I was just in complete desperation survival mode.

This dialogue was really disruptive for me as a player, and totally took me out of the gritty wasteland combat and into ‘trying to figure out the smoke and mirrors land’. I think maybe it’s a good lesson to keep in mind moving forward: if you’re going to use dialogue to enhance your AI, be careful about having NPCs TELL the player what he/she is doing. Because the player KNOWS what they’re doing, and if the two don’t match up then it can seem very out of place. It’s a major breaker of the ol’ suspension of disbelief.

To be fair, if that dude had said – “Finish him off, he’s flailing around like a moron!” I would have been VERY impressed.

{ 1 comment }