Warside is a visceral multiplayer Sci-Fi shooter featuring classic 2D gameplay combined with RPG elements. Play as part of a small squad of elite troops fighting for resources and power across the galaxy. Create your own elite soldier and take him in to online battle in this visceral multiplayer Sci-Fi shooter. Use your unique abilities in full blooded combat with other players as well as hordes of monsters and gain tactical battlefield advantages over your enemies by hovering in mid-air, covering great distances in a single leap and hanging on walls to ambush your enemies. Use the flexible RPG system and wide array of equipment to advance and customize your character.

Post feature Report RSS Glance on the bots from within

Or how to build an decent AI and not to lose your mind. My name is Nickolay Tupicin and I am a game-designer. In addition, I am scriptwriter in both senses of that word – I’m writing scripts and cases. I’ll try to show you the evolution of bots in our game Warside.

Posted by on

My name is Nickolay Tupicin and I am a game-designer. In addition, I am scriptwriter in both senses of that word – I’m writing scripts and cases. I’ll try to show you the evolution of bots in our game Warside.

The first bot and a character controller

Initially, we were concentrated on PvP-content, but later it became clear, that it’s very cruel to put novices right into the slaughter of PvP. After a moment’s consideration we decided to add primary training with simple bots. That was the beginning of bots development in Warside.

The first bot’s name was MrChicken and all he was able to do was running from the player in a straight line, sit, and be scared while under fire. Looking from within, all his AI posed a scripted procedure, which was being activated each frame and sent same signals as control keys. Actually, this feature serves the purpose until now: AI controls bots the same way player does, using control keys and aiming by mouse. Surely, there are some differences between them, but they are not essential. That was the main reason for the majority of different restrictions coming from bots – the resources, which are being used on bots always are bigger, than resources wasted on a player, even with hard AI optimization.

Those were the days! Simple bots were not a problem, there were no thoughts in their minds to make a bug, to start killing mice and men or to organize a Skynet and enslave the whole World. It’s a pity that there were just few things they could do.
Besides the character controller, every here and there you still could find some remains of those days. For example, on the “Base Elise-66” map attentive players could find strange square room right below the ground. That “smoking shack” is used to keep inactive bots to be used in spawners and some rooms.

Because of the troubles with bot’s spawn in certain place, we had to spawn them in that “smoking shack” and teleport those bots at certain time in the right place. But after the bug with the big spider (mini-boss), when he fell to death through the “smoking shack” and didn’t even show himself to the players, we were had to make that place much bigger to let all the bots be located inside.

What the FSM is?

Shortly it became obvious, that simple bots were not the solution. Even in training, we needed some bots, who could make slightly reasonable decisions, furthermore we were considering adding PvE missions for a long time. Good old procedure was bugling at the seams and didn’t suit for the behavior emulation, because you could comfortably deliver on particular target with lineal program, but not the whole class of problems with their own conditions and dependences. That’s why I decided to base new bots on the Finite State Machines (we will talk about it a bit later), in a script format for the start, then requesting a specific structure from server-side programmers.

Picture with example of finite state machine. Circles are states and activities during them. Arrows are transitions with different conditions.

Finite State Machine(FSM), as Wiki told me, is a model of a discrete device with one enter and exit. In each particular moment of time, it belongs to one state from many others. In context of bots we can explicate that definition in such a way: FSM is the algorithm of a bot, where the decision of a bots action is based upon external conddition and inner state of the bot.

The picture you could see above looks like in the code in such a way:

As you can see, such lead-up is comfortable and fits to describe a bot. In practice we usually describe a task in that kind of way: “Oh, we want the bot to locate nearby the player (condition of the distance to the player) while attacking (being in attack state), but if the distance between bot and player is too short, bot should run away (if the condition “player is nearby” is accomplished, bot should switch to state “run away”)”.

FSM allowed us to make different kinds of bots, and each one had its own settings. To make a bot creation process a little easier, we added patterns, which determined everything from equipment to tactics. Sometimes some bugs appeared and some curious combinations came alive. For example, pattern of a melee-fighter was accidentally assigned to a flying bee-bot. As a result, we met some bloodthirsty bees with swords on the level.


The scale of PvE-content was growing fast and became more complex than just simple bots from training. The new game mode “Survival” was at hand. Waves of bots are spawned at that mode, but the resources of a server are limited. Bots posed serious disadvantage from a procedure – decision about bot’s action was made every frame. Every single moment all the bots(including dead bots and even those, who hadn’t spawned yet) on the map were struggling over the trivial decision: “Should I continue doing the thing I’m doing now, if nothing changed or not?” You just take no notice of it while the count of bots is small, but if the count becomes bigger, the PvE server inflates very much and just starts to consume all the available resources. You can imagine what happened, when a few PvE-missions were on the run simultaneously.

The rescue came from the server programmers, who added an event-mechanism and expanded functionality of FSM structure. Actually, now bots decided what to do not every single moment, but when something significant happened. This innovation let us reduce the server resource consumption and create big crowds of bots.

As the system was added on a short notice, a lot of curiosities happened then. For example, because of a little oversight, bots continued to work even after death and were responding to condition of the enemy approaching their corpse, they even tried to attack an enemy! However, it seems like only the camikadze-spider succeeded - he naturally worked like a fieldmine after death. Another curiosity was the fact, that you could hide from the bot right in front of him. When another player was attacking the bot, you could just sneak right to him and stop doing anything – there was no new events happening about and bot just had no idea about your existence.


For the next step we needed more bots, different from each other in their behavior. That demand was blocked by strong inner connection of FSM. Strong connection means, that if I want to change one condition in FSM, I have to rewrite almost the whole machine(all the conditions, connected with the changed part, exactly). This kind of rewriting takes toll on the speed of bot creating .

At the start I tried to break machines into the smaller parts, which were repeated from FSM to FSM (IDLE-condition, for example), but that was no deal. We had to rewrite even idle condition for some groups of bots, although we had to add only one factor and relevant action.
I looked over some articles about that problem and found pretty graceful solution. The author suggested to use several FSM instead of one, which described all the behavior of a bot, and to switch them by special procedure. That means that we made an FSM for several kinds of “behavior” – for example, idle behavior while attacking the enemy or while doing a mission, which was chosen in depending on some conditions. It lets us rewrite only differences in behavior, but not the whole bot. It means, that the speed of bot creating is growing.

After the adding of this making-decisions-procedure, process of coding became quite easier and curiosities more funny. One of those was close to become true detective story! Bots were acting standart in Survival, but something was killing bots with shotgun right nearby the object, they were to destroy. That was looking like they was killed by a rocket from rocket launcher. I was searching for a mysterious murderer quite a long time until I finally saw, that their activity “destroy an object” repeated activity of camikadze-spiders. They actually run up to the object and exploded although in all the other situations they acted normally.

Perfect synchronization, or what’s happening when opponents are equal and both controlled by one intelligence. Absolutely synchronous death. And me, as an observer in between them.


We can improve bots further. Besides “brain” improvement of the bots, there are some changes in structure of the bridging structures. AGRO-list was formed with scripting tools, pathfinding system also replaced scripted movement procedures, even some types of attack were replaced by low level counterparts. Modern structure of AI allows us to make changes of that kind quickly and comfortable and, in my opinion, we will use it for a long time. Nevertheless, if someone has particular advices and suggestions, I will be glad to see them.

And remember, that bots also have a soul!

Follow us: @WarsideGame

Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.

Follow Report Profile
Kraken Games
Ogre Engine
Send Message
Release date
Game watch
Related Games
Warside Platformer
Related Engines
Ogre Engine
Ogre Engine MIT
Related Groups
Kraken Games
Kraken Games Developer