Developer Diary | Posted: 04/08/2005
Introduction
Hello reader. The lines you are just reading open a series of informal articles that will familiarize you with the actual course of events in the development of the PC game El Matador. My name is Petr Smílek and my job at El Matador is Chief Programmer (although this is not my sole role within the team, maybe next time I will tell you more :)
I have never written any developer diary (so far), so I choose a form that has just struck me and which I find original. I will question myself and immediately answer myself, so all this will look like an FAQ. This method will have an advantage: if you are not interested in any question, you can just skip it and go to the next one. OK, let's start.
How many programmers are working on El Matador? Who does what?
Three programmers have been working on El Matador from the very beginning till now: Honza, Petr and me. We have divided the whole programmer work into relatively independent areas, so we don't step on each other's toes. Honza is working on the major part of the code of high-level AI (what the enemies can see, hear and, based on this, what they can do) and implements a front-end part of the game (user interface, inventory management, implementing various entity types). He is also a primary author of a script system that we are using. Petr solves a physical simulator, detection of collisions, low-level motion planning & obstacle avoidance + vehicles (cars, helicopters etc.). I have implemented the engine, which is a core module of our games.
How many lines does the El Matador programme have?
Well, it does not make any difference, but sometimes people ask questions like that. The quality of a programme is not determined by the number of lines, more lines means rather more space for errors. Considering what the programme Line Counter displays (http://noeld.com/programs.asp?cat=misc), we have quite enough space :)
Global Summary (42.5 MB, actual: 36.4 MB)
--------------------------------------------------------
Total number of lines: 1663728
Total number of lines of code: 950566
Total number of empty lines: 329478
Total number of comment lines: 199224
Total number of empty comment lines: 184460
--------------------------------------------------------
5349 file(s) processed.
May we have some information about AI in the game?
When you hear "enemies' AI is good/bad", it usually means an impression of the enemy agents' effects on the player. In any case we cannot talk about any real intelligence (though all developers will argue this vehemently in all their declarations. In fact, what is important in action games is not what and why an agent performs an action (which are tactical decisions by themselves, that require an intelligence), but first of all how he does it (a desirable method is of course the most impressive possible).
We use quite standard technologies and algorithms for AI in El Matador. We use a network of so-called waypoints to implement so-called terrain-reasoning (AI's ability to understand the world in which he exists); these are points in space, which have information calculated in them and among them to provide moving of agents in space and to gain tactical information about the environment (visibility between waypoints etc.) There are several thousand waypoints in a level (N) (see fig. Waypoints), so we have to compress the information for NxN waypoints to be able to keep it.
We use Finite State Machines (FSMs) to implement the enemy agents as such. These FSM are directly supported by our script system, so their logging and the work with them is very simple and effective.
Each agent may be in one of many situations (idle, search target, fight etc.) and each situation requires appropriate behaviour. Some (low-level) parts of the agents' AI are written directly in C++, but there is a part programmed in a script language, so some modifications and interventions into AI do not require any change of the main programme.
I would like to mention one more element we use, that is the so-called rule-based systems. This system enable us to define sets of rules (again in script), which AI is used to make decisions in certain situations.
As an illustration, an extract from the file of rules definitions:
//#include "rules_defines.h"
OnSee
{
// See opponent ?
{
(in.ai_game_event_relationship == 1) && //E_CG_RELATIONSHIP_OPPONENT
(!(in.ai_game_event_obj_flags & 1)) && //dead flag is not set
(in.ai_game_event_status == 1) && //E_MEM_REC_STATUS_RECOGNIZED
(in.ai_game_event_last_tact_event != 20) //E_TACTICAL_EVENT_ON_SEE_OPPONENT
:
out.ai_tactical_event_type = 20; //E_TACTICAL_EVENT_ON_SEE_OPPONENT
out.ai_tactical_event_obj = in.ai_game_event_obj;
}
// See fighting friend ?
{
(in.ai_game_event_relationship == 2) && //E_CG_RELATIONSHIP_FRIEND
(in.ai_game_event_obj_flags & 2) && //fight flag is set
(in.ai_game_event_status == 1) && //E_MEM_REC_STATUS_RECOGNIZED
(in.ai_game_event_last_tact_event != 23) //E_TACTICAL_EVENT_ON_SEE_FIGHTING_COLLEAGUE
:
out.ai_tactical_event_type = 23; //E_TACTICAL_EVENT_ON_SEE_FIGHTING_COLLEAGUE
out.ai_tactical_event_obj = in.ai_game_event_obj;
}
…
What about scripting? Who makes scripting and how?
Nowadays a script system is a part of each advanced game engine. Some engines use available script systems, e.g. LUA, PYTHON etc., some engines including ours use their own script system. From the syntactic view our script language is a shoot of C++, with various limits and on the contrary with extensions necessary for the programming of games (FSM support etc.).
In fact, in their previous project the level designers were forced to programme with all the problems connected with any programming. The first problem was to manage the syntax and to adopt the 'programmer' way of thinking. Another and much more fatal problem was the duration of a cycle "write - test - modify". If a designer wanted, for example, to change a behaviour of any agent in the level, he had to open the appropriate script, and write a part of the programme that corresponds to the new behaviour. Of course he made some syntax mistake in that programme, but he did not find it before the restart of the game, which took at least 30 seconds 9
You can imagine that if the level had 50 agents, each of them with a script of few hundreds lines with many errors which could be detected only in a particular moment during the game, the work with such a system was very frustrating.
During the development of El Matador we shifted to a brand new approach to scripting. The base of the current scripting is an event-based entity system. Each object, which participates in the game by any active way, is connected with so-called entity class according to its function. Such entity then defines a set of parameters and events) of the object. This system is very similar to that of Half-Life 2.
Any editing for designers is then visual (see pictures) and it eliminates problems with syntax errors and incorrect references in the scripts, as the designers do not write any scripts. This way the effectiveness of scripting improves drastically. There is still one part of the game written directly in the script language, but it is kept by the programmers. The system allows the expanding of the game's functionality (to add new entities, to expand the function of the entities, etc.) without any intervention in the programme. Our target is to create an architecture which is as data-driven as possible, but its advantages and all details of the implementation will be perhaps a topic of the next diary.
That is all for today. See you next time :)
Hello reader. The lines you are just reading open a series of informal articles that will familiarize you with the actual course of events in the development of the PC game El Matador. My name is Petr Smílek and my job at El Matador is Chief Programmer (although this is not my sole role within the team, maybe next time I will tell you more :)
I have never written any developer diary (so far), so I choose a form that has just struck me and which I find original. I will question myself and immediately answer myself, so all this will look like an FAQ. This method will have an advantage: if you are not interested in any question, you can just skip it and go to the next one. OK, let's start.
Three programmers have been working on El Matador from the very beginning till now: Honza, Petr and me. We have divided the whole programmer work into relatively independent areas, so we don't step on each other's toes. Honza is working on the major part of the code of high-level AI (what the enemies can see, hear and, based on this, what they can do) and implements a front-end part of the game (user interface, inventory management, implementing various entity types). He is also a primary author of a script system that we are using. Petr solves a physical simulator, detection of collisions, low-level motion planning & obstacle avoidance + vehicles (cars, helicopters etc.). I have implemented the engine, which is a core module of our games.
How many lines does the El Matador programme have?
Well, it does not make any difference, but sometimes people ask questions like that. The quality of a programme is not determined by the number of lines, more lines means rather more space for errors. Considering what the programme Line Counter displays (http://noeld.com/programs.asp?cat=misc), we have quite enough space :)
Global Summary (42.5 MB, actual: 36.4 MB)
--------------------------------------------------------
Total number of lines: 1663728
Total number of lines of code: 950566
Total number of empty lines: 329478
Total number of comment lines: 199224
Total number of empty comment lines: 184460
--------------------------------------------------------
5349 file(s) processed.
When you hear "enemies' AI is good/bad", it usually means an impression of the enemy agents' effects on the player. In any case we cannot talk about any real intelligence (though all developers will argue this vehemently in all their declarations. In fact, what is important in action games is not what and why an agent performs an action (which are tactical decisions by themselves, that require an intelligence), but first of all how he does it (a desirable method is of course the most impressive possible).
We use quite standard technologies and algorithms for AI in El Matador. We use a network of so-called waypoints to implement so-called terrain-reasoning (AI's ability to understand the world in which he exists); these are points in space, which have information calculated in them and among them to provide moving of agents in space and to gain tactical information about the environment (visibility between waypoints etc.) There are several thousand waypoints in a level (N) (see fig. Waypoints), so we have to compress the information for NxN waypoints to be able to keep it.
We use Finite State Machines (FSMs) to implement the enemy agents as such. These FSM are directly supported by our script system, so their logging and the work with them is very simple and effective.
Each agent may be in one of many situations (idle, search target, fight etc.) and each situation requires appropriate behaviour. Some (low-level) parts of the agents' AI are written directly in C++, but there is a part programmed in a script language, so some modifications and interventions into AI do not require any change of the main programme.
I would like to mention one more element we use, that is the so-called rule-based systems. This system enable us to define sets of rules (again in script), which AI is used to make decisions in certain situations.
As an illustration, an extract from the file of rules definitions:
//#include "rules_defines.h"
OnSee
{
// See opponent ?
{
(in.ai_game_event_relationship == 1) && //E_CG_RELATIONSHIP_OPPONENT
(!(in.ai_game_event_obj_flags & 1)) && //dead flag is not set
(in.ai_game_event_status == 1) && //E_MEM_REC_STATUS_RECOGNIZED
(in.ai_game_event_last_tact_event != 20) //E_TACTICAL_EVENT_ON_SEE_OPPONENT
:
out.ai_tactical_event_type = 20; //E_TACTICAL_EVENT_ON_SEE_OPPONENT
out.ai_tactical_event_obj = in.ai_game_event_obj;
}
// See fighting friend ?
{
(in.ai_game_event_relationship == 2) && //E_CG_RELATIONSHIP_FRIEND
(in.ai_game_event_obj_flags & 2) && //fight flag is set
(in.ai_game_event_status == 1) && //E_MEM_REC_STATUS_RECOGNIZED
(in.ai_game_event_last_tact_event != 23) //E_TACTICAL_EVENT_ON_SEE_FIGHTING_COLLEAGUE
:
out.ai_tactical_event_type = 23; //E_TACTICAL_EVENT_ON_SEE_FIGHTING_COLLEAGUE
out.ai_tactical_event_obj = in.ai_game_event_obj;
}
…
Nowadays a script system is a part of each advanced game engine. Some engines use available script systems, e.g. LUA, PYTHON etc., some engines including ours use their own script system. From the syntactic view our script language is a shoot of C++, with various limits and on the contrary with extensions necessary for the programming of games (FSM support etc.).
In fact, in their previous project the level designers were forced to programme with all the problems connected with any programming. The first problem was to manage the syntax and to adopt the 'programmer' way of thinking. Another and much more fatal problem was the duration of a cycle "write - test - modify". If a designer wanted, for example, to change a behaviour of any agent in the level, he had to open the appropriate script, and write a part of the programme that corresponds to the new behaviour. Of course he made some syntax mistake in that programme, but he did not find it before the restart of the game, which took at least 30 seconds 9
You can imagine that if the level had 50 agents, each of them with a script of few hundreds lines with many errors which could be detected only in a particular moment during the game, the work with such a system was very frustrating.
During the development of El Matador we shifted to a brand new approach to scripting. The base of the current scripting is an event-based entity system. Each object, which participates in the game by any active way, is connected with so-called entity class according to its function. Such entity then defines a set of parameters and events) of the object. This system is very similar to that of Half-Life 2.
Any editing for designers is then visual (see pictures) and it eliminates problems with syntax errors and incorrect references in the scripts, as the designers do not write any scripts. This way the effectiveness of scripting improves drastically. There is still one part of the game written directly in the script language, but it is kept by the programmers. The system allows the expanding of the game's functionality (to add new entities, to expand the function of the entities, etc.) without any intervention in the programme. Our target is to create an architecture which is as data-driven as possible, but its advantages and all details of the implementation will be perhaps a topic of the next diary.
That is all for today. See you next time :)
Add to My Collection
Write Review