Sponsored By

Interview: Inside The AI Of S.T.A.L.K.E.R.

Gamasutra sat down with Dmitriy Iassenev, the man behind the AI of post-nuclear PC first-person title S.T.A.L.K.E.R.: Shadow of Chernobyl, for a detailed interview on its surprisingly complex NPC 'A-Life' system and resulting emergent gameplay.

March 12, 2008

8 Min Read

Author: by Alex J. Champandard, Mathew Kumar

The post-nuclear PC first-person title S.T.A.L.K.E.R.: Shadow of Chernobyl, developed by Ukrainian developer GSC Game World, is acclaimed for its non-linear gameplay and surprisingly complex NPC AI. Therefore, Gamasutra had a chance to team with AIGameDev.com and interview Dmitriy Iassenev, the man behind the AI and A-Life system in S.T.A.L.K.E.R. Here, Iassenev discusses the complex artificial life system and its implementation, complete with multiple takeaway lessons from the development process: Could you tell how you implemented the A-Life in S.T.A.L.K.E.R.? DI: Our A-life implementation is quite simple. We have introduced two terms that characterize 2 patterns of character’s behavior, different in implementation details: offline and online. The offline behavior is very simple: the character does not play animations or sounds, does not manage his inventory actively, does not build detailed and smooth paths (although he does build paths according to the global navigation graph, but more on that later). In contrast, online behavior is fully detailed. Thus, offline behavior can be considered the LoD (level of detail) of the online. In our system the player acts in a level, other characters live in other levels, i.e. they are offline, i.e. they are using the offline behavior. Moreover, considering the high density of characters in a level, not all characters in the player’s level have the online behavior, but only those who are in a predefined radius from the player (can vary from level to level, but usually it is about 150 meters), or what the game designer sets it to. To achieve this, the A-life system follows the player’s and offline characters’ movements, and switches the latter to online/offline as necessary. What were the other important parts of the system for developing the A-Life in S.T.A.L.K.E.R.? DI: Every character in the game always has a goal: to uncover the mystery of the Zone. In early versions of the simulator, a character knew one or several dealers, which had sets of quests that they generated based on the map of anomalous activity and requests from organizations, which wanted to get rich from artifacts found in the Zone. Completion of a quest brought the character closer to his goal. There was only one type of quest at the time — “bring an artifact”. The character would take on a quest to search for the artifact, go to the approximate area in which it could be found, if able to find the artifact, brought it back to the dealer, traded it, then picked a new quest. Along the way he could encounter enemies and fight them. In offline mode this was simulated: the opponents took turns making moves, the result calculated based on a formula and the random factor. The effect was that one opponent could run away from another, sometimes characters got killed, sometimes they did not even notice each other or decided to avoid confrontation. If the character was a stalker and met a neutral or a friend, they traded with each other, guided by a developed trading scheme. All of this worked both in offline and in online modes. To notify player about the offline activity, we used news, which were generated if some character could see an event or its consequences. It was planned that the number of types of quests would later increase, and character behaviour would diversify due to introduction of requirements of food and sleep. We also planned that our characters would be able to uncover the mystery of the Zone before the player, or at least collect a certain amount of information. Then we changed the way quests were generated. Characters would now get quests not from dealers, but from the so-called smart terrains. A character’s life now worked in such a way, that he took the quest generated by some smart terrain, then walked to the destination it had set for him. After getting there, he would get points, and the smart terrain would take him under control for some time. Under the control of a smart terrain, the character prioritized and carried out the available tasks. This is how the game got faction bases, stalkers by campfires, and such. That is, migration of characters from place to place, their movement between levels, all was caused by changing goals. In retrospect, what parts of the system and/or development process were you particularly happy with? DI: I was very happy with the work done when I followed a stalker from one level to another, saw how he searched for artifacts, found them, returned to the dealer, approached him, traded, picked a new quest, went on — too bad this did not make it into the original game. It was very interesting to witness. When we were implementing goal-oriented action planning, it was very interesting to watch two hostile unarmed characters that knew were to get weapons and ammo: they first run to the weapons, find that they have no ammo, then run to the ammo, the first one to get there causes the other to panic if he is still far away from weapons and ammo, the panicking character gets wounded and falls, the other approaches to finish him (this did not make it into the original game, since all characters received unlimited ammo, and such situations could not take place). It was very interesting to watch a fight of several dogs and one stalker — it was breathtaking to see this sight, as he flees the dogs, switching covers. Sometimes he died quickly, sometimes managed to take down 4-5 dogs, and sometimes all 6. How about disappointments? Was there anything in particular about the system or its development that you would have done differently? DI: I would very much like to play a game in which characters would live their own lives, each would have his own goal in the game, each would have human-like (or some specific for monsters) needs that the character would have to satisfy. Now, instead of creation of an algorithm for choice of current needs and their satisfaction, a simpler model has been used, which offloaded this work to the smart terrains, responsible for change of tasks by characters, able to assign tasks like “sleeping”, which, of course, is not the same thing. Much can be done to improve fights, teamwork, efficiency of combat and efficiency of characters’ actions. I really want to switch from imitation of team actions, to real team AI, even if it means only a few actions. In intellect, adaptation and teaching characters the player’s game style. The emotional part would also be very interesting. I would also really like to teach characters to adequately react to the surrounding world: walk around dynamic obstacles, each other, use the terrain (path and smart objects) in various ways, be able to drive vehicles, fly the helicopter, etc. There are many things they cannot do for various reasons, but in the future iterations of our game we will try to gradually add the missing elements. What about the lessons learned? If you had thirty seconds to give advice to other game developers out there, what would it be? DI: 1. Do not reinvent the wheel. Use the internet to find solutions to your problems. 2.Have a clear idea of the game you are making, of which features it will have and which it will not, use prototyping to avoid implementing features that do not make it into the release. 3.Debug characters with comfortable tools: each component should have its debug draw/mode/screen. Draw paths (all the iterations, all the smooth stages and so on), draw visibility checks to find out why character doesn’t see, draw covers information and so on. To debug characters' behavior we created their debug screen with all the data from all the layers, so we can easily pick the character and find out what is wrong with him. Pause and time factor are invaluable for the animation/movement/orientation debug. 4. Let programmers do programmer work and designers design. Designer is a bad programmer, programmer is a bad designer. This could become a problem when using scripts. Let people do things in which they are strong. Instead of advancing designers in programming, create WYSIWYP editor with many options to tune. 5. Be aware of all the new developments in your area, read Internet resources, like AIGameDev.com. 6. Implement something new in your game. Maybe it is only one thing (since several can be too much for a single project), but necessarily new. We see an excellent implementation of decision trees in Black & White, Jeff Orkin has created an exceptional implementation of a goal-oriented action planner in F.E.A.R., we have tried to make a kind of approximated A-Life in a shooter, maybe someone will make something new tomorrow — this will benefit the players, who will get diverse games, and developers themselves, who will set an example of a good method or approach. [Thanks to AIGameDev.com for allowing us to reprint highlights of their in-depth Iassenev interview, which includes many other relevant sections discussing the development of S.T.A.L.K.E.R.'s A-life in detail and is available in full on their website. AiGameDev.com is an independently run weblog for staying up-to-date with game AI technology, industry news and design trends. If you’re interested in artificial intelligence, the site includes an RSS Feed.]

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like