AI Programmer: Jose Raluy

Before RAS I took a Software Engineering degree, with the Graphics specialty, the first one in Spain (Deusto University) and the second one in London (Middlesex University). While in University I did some database programming (boring as hell, btw). Then I moved back to England (to Etchinghill Studios), to work developing stuff for the Internet, first a 3d chat program, and later the seed of an online RPG, still in the works there. While in England I discovered RAS because of their web page, and I got in touch with them immediately. Here, at RAS, I have worked for 2 and a half years on Blade, doing the AI with Bob Yves, the animation system with Angel Cuñado and game programming in general.

There are three programs running in this picture. Visual C is used for coding. The file AI.cpp is the main gate of C to the Python interface. It toggles the main events of the AI, so the given character will have to decide how to respond to that event. The file A_star.cpp is the high level file for the path finding code. It exports a structure of sectors (which build the maps in Blade) in order to find the optimum path. SourceSafe is a tool used for centralizing the code, scripts and data files (sounds, animations, etc) The directory selected is the "Enemies" one, where the different attributes, animations and combos of the races are stored. Still, that's not all the info for the NPC, as some of the high level ones are stored straight in python. Also, you can see the performance in the Task Manager to be careful with the memory usage (not so relevant for the AI, but VERY relevant as the project is reaching completion).

The AI isn't updating all the times; only for the paths that are already set up, and not even all the times the either. Only every time gap (bigger or smaller, depending on the relevance of the possible event toggled), the checks (and the toggling of the event) are performed. So, we have the same results and we save quite some CPU time.

The AI in Blade consist of:

Reactive AI
Our high level AI is event-driven. That means that it updates itself only when some events are toggled (when an NPC sees the enemy, like the typical example). In that way, we have generic functions like "SeeMyEnemy", which makes the NPC to respond in a natural ways. Of course, it can be customized for different races and different particulars. The typical reactions are seeing and/or hearing something, receiving damage and/or killing the current enemy (it doesn't have to be the player all the times), watching another character performing an alert animation, loss of sight of the current enemy, entering a non allowed area or a not-to-stay-for-long area (they stay there only for a few seconds) and entering short/long range combat. They investigate sounds, and, in general, they react to their environment. They will protect certain areas, patrol and calling for help. Others will come (or modify slightly their behavior at least) if their hierarchy of actions tell them to do so.

We have tried to minimize the problems with path finding in tight spots and/or crowded rooms and hopefully there will not appear those kinds of bugs. Still, there are points in the code in which you have to assume something, not just to make it simpler, but also to make it fast enough. But there are always tricks to use...:-)
If light and darkness will affect AI reactions and pathfinding is something that is still under consideration. The main problems is that we want the player to enable or disable shadows, but a change in the graphical setting must under no circumstances lead into a change in gameplay. If the "toggle shadows" options stay, this could lead into that part of the AI not usable. Other goals like collecting items like food and getting more experience points were rejected, apart from being too CPU intensive, because the difficulty in balancing the gameplay. Although it sounds quite good to have enemies like that, it is not-so-brilliant to have dozens of enemies with an unexpected behavior, because the gameplay will suffer, and games are about gameplay after all. It isn't an excuse. Those behaviors were studied a lot before being rejected.

Combat
The NPCs choose the next attack (or row of attacks, or combos) based on its life, the enemies, and the environment (to name just a few, because there are many). Special moves (magic attacks, invisibility and others that should be kept secret) are included here. If the enemies are intelligent enough, they use grouping techniques. They will coordinate in combat. One of them will be the leader and the others will protect him. In the combat, the attack set can vary a lot from one race to another, and the probability to perform them can change during the combat. The difference is even more relevant when using magic attacks, etc. Sometimes they can set up ambushes and more elaborated ones. If they chase you, they will climb anywhere (if allowed) , break objects to get close to you, and attack in very sophisticated ways. They will not use straight lines or stupid behaviors (unless it is supposed to be stupid).

Scripts
This is used for some very specific behaviors (like an enemy that flees to alert others), which happens only in a given sector of a map. First, the high level AI is done mainly in script (using python), making constant reference to low level instructions. In that way, CPU intense functions (like checking the collision of an attack against the world) that are in C (faster than python). Therefore, the scripts do not have to deal with the format of the animation's data and other "unnecessary" stuff. Still, most of the times and with some lack of precision, the scripted AI is referent to situations like showing a NPC appearing trough a door, show another NPC attacking him and in the case where you try to help him, but you are too far away so before you get there he dies and the other one runs away. This KIND of script (mostly linear, with almost no interaction even as it looks like that) is used in Blade just when needed, only for story-telling purposes (either an emotional response of the player or a progress in the plot of the game). The use of the standard AI libraries of a more scripted thing depends on the needs on each case. Mixed solutions happen quite often as well. .

I worked mainly in the first two parts (reaction and pathfinding) and some other stuff, based on the path finding like patrolling, arches and etc. I also did some of the game programming, and I have been working lately on the animation system, and the combat system (animation and combos wise) too. The sensation of having something (or, more likely), someone "alive" in your computer is a pretty nice feeling. Apart from the graphics field, I think it's one of the most interesting areas in computing. The most frustrating part of programming AI is being limited to a small percent of the CPU time and as it is the AI for the game it is a bit ironic, but you are limited because the gameplay must be fun. I mean, you can always improve the use of the A-star algorithm (the standard for path finding algorithms) in your game, but you cannot try too radical and innovative things without risking the game design.

Previous | Index | Next