Official development blog

The Player is Always Right: An Existential Approach to Game AI

0 Flares Filament.io Made with Flare More Info'> 0 Flares ×

This post is not exactly as philosophical as the title might suggest, just a catchy way to paraphrase what I consider the best way to handle artificial intelligence in games.

In short, as long as there aren’t any glaring oddities in a mob’s behavior the player will tend to justify what’s going on by whatever logic makes sense to them. Thus we should all subscribe to the KISS principle when designing AI. Complex AI systems are not only difficult to create and maintain, they’re exponentially more likely to trip over themselves as the solution space expands outward. On the contrary, simple systems are capable of giving the illusion of intelligence, and half of that work can be done by players themselves!

An example from Cogmind:

  1. Player flees into a room with one other exit, turning to fight off pursuers before planning to escape if things get out of hand.
  2. Half-way through the battle a robot shows up at the other doorway, getting the player in a pincer.
  3. Player: “They’re moving to block my escape!?”
  4. AI: “No, my friend was blocking the other door so I found the only other entrance I could use to get to you.”

This is nothing more than everyday “go straight for the enemy” behavior at work.

Developers can rely on the fact that the player doesn’t know what’s going on behind the scenes. Implementing a realistic thought process isn’t necessary; all that matters is how the final behavior is interpreted by the player. The AI exists to challenge players, interact with them, thus for either tactical reasons or role-playing, players will attempt to rationalize any behavior that is not explicitly explained (i.e. anything a mob does without telling you why).

Of course for some types of games, notably those with many complex interactions, we’d need more capable AIs to deal with the variety of situations. At the tactical level roguelikes aren’t that complex since individual mobs only have a handful of possible actions, not to mention most roguelikes don’t even have any kind of AI for controlling the overall dungeon experience (a very unexplored design space--we’re going to change that with Cogmind). Any game that can should try to get away with the simplest AI possible and work up from there as necessary, just beyond whatever point at which the AI is apparently behaving stupidly.

Expert Systems

AI in games is often some kind of “expert system.” That is, it defines a set of specific behaviors based on the rules of the game, at the simplest level taking the form of if-then logic. At that level it’s pretty much all hard-coded and initially quick to put together, but difficult to maintain once it reaches a certain scope.

The most common type of expert system for games, albeit in an easier to maintain form, is a finite state machine (FSM). An AI essentially exists in a certain “state” and environmental factors can trigger it to switch to another state. While in a given state the AI engages in behavior associated with that state. Cogmind’s AI is sort of this, though most types of robots only have a few possible states.

For example, an unarmed worker bot is cleaning up debris (state: CLEANING) and gets attacked (trigger: ATTACKED), so it starts to run (state: FLEEING); after it hasn’t seen the attacker for a while (trigger: SAFE), it goes back to cleaning (state: CLEANING). The worker only has two states: while CLEANING it wanders around gathering any debris it finds, and while FLEEING it moves away from the attacker.

cogmind_ai_worker_fsm

Inside a worker bot’s brain. An FSM doesn’t get any simpler than this.

One of the most interesting types of game AI is goal-oriented action planning (GOAP), one form of goal-based planner that can calculate the optimal series of actions necessary to achieve a designated goal, and even change that plan on the fly as the situation changes. It’s great for games with numerous possible actions, and once the foundation is built it’s quite flexible. By chaining actions together this type of AI can do some really smart stuff, but it’s definitely overkill for most roguelikes, including Cogmind, in which each AI is only capable of a few actions anyway. I do hope to one day be able to use it in a project (maybe X@COM?).

Robot AI

For now Cogmind uses an FSM, one that was actually born several years ago before Cogmind even existed!

The year was 2011.

X@COM hadn’t been released yet but I was planning to put out a playable version for ARRP that year. The problem was before that point I had only been working on the interface and mechanics--the game still had no AI. So I spent half a day coding and integrating a simple state machine for the enemies. RUN and SHOOT. Very KISS.

In later versions I tacked on a few more states like FLEE, GUARD, and PATROL. Then 7DRL 2012 came around and it was time to write Cogmind, which reused most of the X@COM code, including the AI. The AI required just a few more states for unique robot behavior like CLEAN, RECYCLE, and BUILD, stuff other than fighting (for the non-combat robots). So yeah, the combat robots in Cogmind are still using the same AI as X-COM aliens ;)

After several years of accumulating states and triggers here and there, the Cogmind AI implementation has started to bother me. Imagine code conceived on one of those “I’ll just throw something together” days turning to spaghetti as the amount of behavior it has to account for balloons significantly, made scarier because it’s controlled purely via switch statements rather than an object-oriented solution (the latter would be more flexible). Triggers and states are threaded throughout a single method, and new states aren’t well supported without a sprinkle of special cases…

Okay, end of programming horror story in the making.

So I’m going to refactor it, yeah?

Nope. At least not now. For one, it works (though it’s only 80% complete now that there are new special robots it doesn’t have states for). Even player orders have already been integrated. It would be quite a bit of work to redesign, rewrite, and retest the whole system, so the current plan is to stick with what we have and continue tacking on missing pieces for a first release. In the future if it seems like the game would really benefit from a new AI then we’ll reconsider it.

Squads

In many roguelikes a large portion of enemies work as individuals, though you may end up fighting more than one at the same time due to their placement or poor maneuvering. In Cogmind almost all hostile robots work in groups.

As is these groups will not blow your mind with tactical genius--if they were really that intelligent they’d crush you due to their overwhelming numbers (required for gameplay balance). There’s something to be said for fighting off hordes of weaker enemies. That’s not to say they’re all weak (some you will definitely want to avoid if possible, in true roguelike fashion), nor are all groups composed of same-class robots as they were in the 7DRL. Special purpose squads might have a mixed composition of robots with abilities that complement each other. These are squads that may arrive on a map after you do, usually in response to your presence.

Yep, unlike many other roguelikes the number of enemies on the map is not static, and for that we need the Overmind.

Overmind

There’s nothing called the “Overmind” in game, it’s just a C++ class responsible for coordinating the general response to threats on maps where the primary robot faction has control. It has no direct control over individual AIs, only dispatching new squads as necessary.

This creates a more flexible enemy presence that makes different kinds of strategies equally viable yet hopefully equally challenging as well. Looking at both ends of the spectrum, as a stealthy hacker/assassin there won’t be too many threats to deal with but you’ll have to do so carefully--if you destroy more than necessary or are spotted too often you could eventually have no choice but to beef up your direct combat abilities; as a warmongering deathmobile you’ll be able to force your way through just about anywhere but attract a lot of attention (and therefore company) in the process--at some point it will no longer be worth the danger.

More on this topic in a future post.

 

Notice: Starting next week I’ll be out of town for a long family trip, so the next posts won’t come until the end of the month. When I get back there will be some great new content and a new website as we move towards launch! (No, it’s not quite that close, but the game is good enough to build a proper website around it. Prepare for a screenshot festival, or a gifalanche, or whatever you want to call it =p.)

0 Flares Twitter 0 Facebook 0 Google+ 0 Reddit 0 StumbleUpon 0 Filament.io Made with Flare More Info'> 0 Flares ×
This entry was posted in Design and tagged , . Bookmark the permalink. Trackbacks are closed, but you can post a comment.

10 Comments

  1. Fluff
    Posted October 14, 2014 at 1:04 pm | Permalink

    As a non developer it’s interesting to see some of this behind the scenes stuff as well. Definitely learn something from them.

    and enjoy your trip!

    • Kyzrati
      Posted October 14, 2014 at 1:46 pm | Permalink

      Thanks, I will. Don’t get to see non-nuclear family all that often these days.

      I’d love to be more open about the AI and share all the “secrets,” but as I explained revealing too much could ruin the game ;). There will, however, eventually be at least one more post covering the Overmind, since I’d like players to know a bit about how that mechanic works.

      Next few posts will feature more player-oriented content.

  2. Nico
    Posted October 25, 2014 at 2:01 am | Permalink

    Interesting! Thank you for your nice blog posts

    • Kyzrati
      Posted October 28, 2014 at 9:37 am | Permalink

      No problem! Had a bit of a lull these past weeks due to vacation, but I just got back this morning and things will start moving again soon!

  3. Scott
    Posted October 28, 2014 at 11:50 pm | Permalink

    Your blog is amazing and one of the few I follow diligently. It’s like a masters class in game design. The work you’ve done to track your own time and figure out hours spent and all those little details is really impressive. I would think these metrics must be very valuable to other indie developers. It’s too bad you won’t be able to run a Kickstarter, I think Cogmind could do very well.

    • Kyzrati
      Posted October 29, 2014 at 9:02 am | Permalink

      Thank you! I don’t know about “masters class” ;), it’s just nice to share the progress and get some interaction with followers. Plenty of designers have a lot more experience to share than myself, but then not everyone writes about what they’re doing. As you know it takes a chunk of time out of development to write all these posts.

      If Cogmind’s design were more open-ended there would be a good bit more conversation here. (I’m sure we’ll see plenty with the future X@COM reboot.)

      Yeah, I think Cogmind would do quite well with a KS, too. Oh well. I do, however, like the idea of not having to hand over any part of the design/content to backers like many games end up doing as rewards.

      • allison
        Posted October 29, 2014 at 5:32 pm | Permalink

        Kickstarter or not, still waiting to give you my money as soon as I can!

        • Kyzrati
          Posted October 29, 2014 at 7:56 pm | Permalink

          Now we just have to hope there are at least 10,000 more like yourself so I can keep doing this ;)

          • Scott
            Posted October 29, 2014 at 8:49 pm | Permalink

            I don’t think you’ll have any trouble finding 10,000 fans as long as you get on Steam and keep the pricepoint low.

          • Kyzrati
            Posted October 29, 2014 at 9:04 pm | Permalink

            Steam would make that target far easier to reach, for sure. I think it’s doable.

Post a Comment

Your email is never published nor shared.

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>