Bulletpattern Game design, Flash and Unity development

25May/160

Scripting MOBA AI

I have recently gone back to our MOBA, Adventure Time Battle Party and it reminded me about how I wanted to write up a post about the AI. There were a number of important lessons we learned and I wanted to share them.

 

Ground Rules

We didn't have much time to pursue, what I would consider, strong AI on this project. However, I love working with AI so I made time on weekends to work on this. So to be economical, our explicit goal for AI in Battle Party was "don't be dumb", which is very different from "be smart". Also, my approach to AI is rooted in "make it fun" more than an academic approach to AI, where you might be trying to emulate an algorithm or advanced behavior.

Also, AI was an aspect a number of our team wanted to learn. To keep things simple, I set up and simple state-based AI system and wrote a number of tools for newbie AI scripters to use.

One thing that's important to me is: don't cheat. I try as much as possible to not leverage any data a real player would not have. I don't want to rely on letting the computer know every last detail of a player's state or inputs and make decisions based on that knowledge. There are times when the CPU overhead of certain checks are just too expensive, and in that case, I allow myself to cheat.

 

The "Danger" Measurement

The backbone of the system was a collection of systems that produced a "danger" value. This produced a simple integer that allowed the scripters to make decisions. This system took into account:

  • The number of alive players
  • The number of nearby ("nearby" being 1.5 screens IIRC) enemy players
  • The number of unaccounted players on the mini-map
  • The number of nearby enemy minions
  • How far ally/enemy minions are pushed. This was a +/- value depending on where the minions were pushed relative to the mid-point of the map.
  • A queue of when the AI sees a player use powers. This is a good example of not cheating. Instead of looking at the player cooldowns, when the AI sees an onscreen player use a power, it lowers the danger value by a specific value for a certain time. Higher value powers lower the danger value more.
  • The powers currently available to the AI
  • Player/AI health values
  • Player/AI buffs
  • Being close to an ally/enemy tower
  • Some other items as well.

 

Basic States

The basics were patrol, attack, and flee. Since the more danger there was, the more an AI champ would flee, the back and forth between and attack and flee states created some good dive in/dive out behaviors and some pretty good kiting. If the danger value got too high, the AI would flee to allies, health pick-ups, towers, or the base. If the AI had a power that created movement, it would use this power to run away if pursued (i.e. in a flee state and a champion was close).

If the AI didn't have a champ to attack, it would push minions, help allies, capture altars, patrol, or do special actions. more on social actions later.

 

Listen for Events

Loads of events can trigger a decision to change the state – taking damage, a tower being attacked, the base being attacked, an ally champion being attacked, the danger value changing significantly, altars being open or captured, etc. Many events. Lots.

 

Special Actions

In my experience, I have found you can throw in 95% of random behaviors and 5% of really smart decisions and player's will think your AI is a genius. With this in mind, I did a couple of one-off, hard-scripted behaviors to use occasionally.

  • Tower Dive – Very rarely, when the danger rating was very low and a player was hiding under a tower, the AI would tower dive. During this brief time, it would just go HAM and ignore the danger rating and try to kill the player.
  • Ambush – If the Ai had nothing better to do, it would hide in the brush for a time and wait for players.
  • Dodge – If the player used an aimed power and the AI had a power that could be used to dodge, it would do so.

 

Other Tools

I wrote a number of tools to facilitate other scripters. Things such as "do I have a clear shot to my target?" This mean you could fire a projectile without being blocked by minions. There was a similar check that informed the danger rating on the AI, "does the player have a clear shot to me?

There were quite a few utilities like "find closest safe point", "are targets in range of my powers", etc.

 

Leading the Target

One of the biggest lessons we learned was about the value of trying to lead the target when aiming powers. Every scripture's first instinct was to try to predict player movement and fire where the player would be in the future. This might be good for a game where player velocity cannot be changed instantly, like FPS or racing game, but in a MOBA a player can "juke" (i.e. dodge) in any direction instantly, so the value of prediction is greatly decreased. Experienced players will nearly always dodge. We found that it's statistically more likely to hit player just aiming randomly in a radius around the player than trying to lead their current movement.

 

Conclusion

The AI turned out pretty good considered the limited resources we had. Quite a few people got to try their hand at scripting AI and they only needed to worry about strategies around the character's power set, instead of learning about managing behaviors states & calculating distances.

Filed under: Uncategorized No Comments
24May/160

Multiplayer Ranking Systems vs. Declining Population

The Problem

A solid ranking system is required for a healthy, competitive online game. You want same-skill players to be facing each other – you want your newbies playing and your veterans playing veterans.

A good skill system will allow high-skilled players to quickly rise in the ranks and only face like-skilled opponents. You want these good players away from the lower-skilled players as quickly as possible.

The more granular the system you have, the better matched players will be. Having numerous ranks gives players goals to work towards and the more goals the better.

But what happens a couple years after release and your game's population dwindles? You may still have a small, but dedicated, set of players who can no longer find matches due to your ranking system. What was previously a great feature of your game has become a detriment that will kill your game's community all the faster.

This unfortunately affects the players at the top ranks the most. These are your most passionate players and they are already in the smallest population pool. They will be punished the most with the longest matchmaking times.

 

A Solution(?)

A system that adjusted the number of searchable tiers separately from actual ranks would be better to offset population reduction. These searchable ranks would  shrink and grow depending on average concurrent users.

In our previous game, we had 4 ranks and 14 sub-ranks. We did matchmaking between ranks, and then allowed to expand to more ranks after a set time. Five minutes per rank, if I recall correctly. This means a high-rank player might have to wait for 15 minutes to search the entire player base for a match.

What would be better is something along the lines of:

  • Player population high = Matchmake as 4 ranks
  • Player population low = Matchmake as 1 rank

And some couple gray areas in between. This would mean when the game is healthy there are loads of ranks and similar skill matches, but as population dwindles you sacrifice skill-matching for getting games started at all. I think this is a sound trade-off.

Filed under: Uncategorized No Comments