Entron DeathMatch Arena Technical Notes
-----------------------------------------
    This demo shows off the AI and the scripts ripped from the Quake II TC, Entron: Freedom's Edge.
Everything you see in this demo can be incorporated in the game as a part of a level where your objective 
is to go murder some important character inside the arena. In Entron, you will be able to fight your way in 
a living world where so many things happen at the same time. You will not be able to see all of the game 
unless you finish it at least seven or eight times. 

About the script editor: 
    The script editor released in this demo is given as is. There will be meager support as I am still making 
considerable changes to it. The final version will be released with online help and a glossary of all the 
functions supported. The scripts used are compiled and run in real time by the DLL; however, for speed reasons, 
they are only a few fatal errors checks in the script interpreter for the sake of speed. Clumsy scripts can 
definitely crash Quake2.exe, so beware. 

Usage: 
    Scripts will help you add external functionality to existing DLL code. You can control every single entity as 
long as it has a script file pointed to it and a targetname. Script files don't take much memory since they are static
in a the game and are shared by several actors at the same time. You could have several people do the same actions 
in different parts of the map and the script will have to be loaded only once. 

Integration: 
    The script used in this demo will be integrated in the public release of Gang Wars 2.0, and any other mod for 
that matter. Gang Wars 2.0 will have all of the goodies that TF had/has in their map code. No more CTF only maps 
in quake2, not more DLL updates for each game type. You can have the famous hunted, canalzone, etc. themes; 
all you would have to do is write the script and assign it to the entities in the map. Also, this is a step higher 
than TF maps since all of the scripts are loaded in the server only, not in the BSP, players can play different 
games on the same map depending on the server to which they connect. The script interpreter code is pretty straight 
forward, it will only require the DLL programmer to add a single SCR structure in their edict_s structure. That's 
about it. The whole interpreter is now distributed in 2 files b_scrcmd.c and b_scrio.c which can be added to any 
workspace and work flawlessly from the first compile. The .c files will not be distributed, only .obj files will 
be, but people interested in licensing the technology can contact us at www.EndorProductions.com. 

Platform Compatibility: 
    The script compiler as well as the AI (NNE) available in this demo are scalable to any other game. I have not 
yet finished the AI, but in short, it is based on DFS trees and heuristic TSP/PCTSP approximations, not the 
conventional problem solving algorithms. The script compiler/interpreter and the AI we developed to go beyond 
Quake2/Entron; they can be ported once we acquire a superior engine. The script interpreter especially can be 
ported to Half Life, HereticII, Shogo, and the rest of First Person Shooters, in no time, regardless of their coding 
convention. Although, in this demo there are only 2 warriors fighting, we could have put in 20 warriors in the same 
map (all visible at once) and have it run smoothly on a P2-266, the only slowdown from the CPU's part would be the 
triangle processing on the models of each warrior. 

Source files: 
    There are two source files included in the demo: referee.scr and booth.scr, those two files control the referee 
and the person which works in the booth of the arena. The script files are documented and with the limited function 
help from cmdlist available on the compiler, you could make out what those files do in the game. 

About AI: 
    The code written for AI in Gamex86.DLL was not fully developed in C. In fact, most the artificial intelligence 
(although, it is not the correct name to apply for a game's monster behavior, but we shall refer to it as that now 
that it has become a 98 clich) was analyzed in LISP, PROLOG, and ML first. Developing behavioral code based on Fine 
State Automata and a procedural language like C is the wrong way to go. Although most of the code related to AI is 
iterative, huge parts of it are NP-Hard or NP-Complete even. You could notice that at times where a solution is not 
found by the monster and a certain monster's mental block might occur for a fraction of a second. This was my first 
endeavor at procedural AI and I have learned a lot about AI simulation rather than applying real AI. Chapeau to the 
guru programmers out there who make decent game AI. Simulating realistic AI with a procedural language is a challenge 
by itself; think about it. I hope in the future, we can develop a true AI language as fast as C, and as flexible/complex 
as LISP. Of course, that would be a lifetime challenge. 

About AL: 
I have been working on AL lately. Read my .plan about it for further info. In short, AI can't stand a chance. 
  

-----------------------------------------------
Written and compiled by Nawfel 'Topaz' Tricha. 
LifeScript is a propriety of Endor productions. All rights of redistribution or modification are reserved. 
	(c) 1998-1999 Endor Productions. All rights reserved. 
Minimal help will be given at the address below:
	-Topaz@endorproductions.com