United Bot philosophy and roadmap

[Pierre-Marie Baty]

That suggestion was raised by botmeister and a couple others. The idea is to build a bot AI template, that would be cross-game, and cross-platform.

Cross-platform: the bot must be integrable to a broad set of game engines. Examples include Half-Life, Half-Life 2, Battlefield 1942, Quake III, Unreal, and others. An API must be defined as the input to the core center of the AI template, to which a "game driver" will be able to talk, translating back and forth the engine calls from the game engine to the AI template and back. Not two game engine behave in the same way, and not many of them provide as much facilities as the Half-Life engine does. Defining the core AI template API and its needs for supporting a particular game engine is part of the United Bot project plan.



Cross-game: the bot must be easily integrable with different modifications of the original game available on a certain platform. The most known example is Half-Life and the diversity of its mods. Given a set of configuration files (preferred), or at worse, minor code changes, the end user will be able to have his bots either capture a flag in CTF mods, hunt for a prey in others, work in squads in another one, make a certain action upon a certain entity in order to win the round in some other one (e.g, "plant" a "bomb" like in Counter-Strike) ; this assumes that all possible behaviour for First-Person Shooters environments are already integrated and working in the core AI part of the template. Defining the list of featurable behaviours and their configuration needs is also part of the United Bot project plan.



Template: the bot must feature a core AI center and a great number of APIs into which third party bot makers could insert plugins. Example: you are not satisfied of the aiming of this bot, download the aiming plugin made by Mr. X and plug in into your bot. You want your bots to be more stealthy and take always the safest routes, download the pathfinding plugin made by Mr. Y and plug in into the bot. You are not satisfied with the weapon usage of the bots, download a plugin that will make the bots use the burst-fire better. Defining the list of possible plugins and their respective API is also part of the United Bot project plan.




We need to evaluate and examine a roadmap for each of these three points.



1. Cross-platform Core AI.

1.1 - To define the needs in terms of game engine integration for the United Bot to support a game engine or not.
In our opinion, at least:
. - To have the ability to hook on each video frame and execute arbitrary code.
. - To have the ability to read, interpret and process the game data, either through engine facilities, or directly from the game files on the disk, translated by our means.
. - To have the ability to parse, bind and retrieve data from the game's list of "entities", "things", "moving objects", "elements". Notably their position, velocity, size and mesh (model reference).
. - To have the ability query the engine for testing visibility from point A to point B in the virtual world.
. - More (open to discussion).

1.2 - To define a game driver API.
. - To elaborate the prototypes for each "virtual" engine call.
. - To write wrapper functions that will dispatch these calls into more CPU-efficient engine calls for engines that provide the more facilities, and
. - To write wrapper functions that will emulate the missing calls for the engines that provide the less facilities, given a minimal set of availability.


2. Cross-game FPS AI

2.1 - To define the interfacing differences between games and to solve them. To define the needs for each mod in terms of interoperability between at least:
. - Network messages (if the game engine features it)
. - Round start event (if the mod features it)
. - Goal entities (if appliable) or situations (idem)

2.2 - To define and implement in the driver API the virtual facilities used in this process:
. - To distinguish a player's team by ID (forethink of an alliance system)
. - To distinguish a player's class (abstract this data so as to make it portable)
. - To locate and query the state of a goal entity or situation.
. Abstraction is the key word.

2.3 - To define and implement an abstraction method for the weapon data. Which weapon does light damage, which one has a radius effect, which one is tossable, which one is missile, which one is instant hit, which one is a disabler (flashbang/freezer/whatever), etc. Taking the example of the RACC AI weapons abstraction layer:
. - To forethink for each weapon the number of rails (ex: primary rail = sub-machinegun, secondary rail = grenade launcher)
. - To forethink for each weapon a class (ex: grenade, primary, secondary or melee weapon)
. - To forethink for each weapon a set of properties: (ex: waterproof, disabling effect, radius effect, missile, heavy/medium/light damage, automatic firing capability, buckshot firing capability, scoped, zoomed, silenced, homing, toss effect, needs placement).
. - To forethink for each weapon a best effect distance range that will be useful to the AI. Debatable point: let the/a "weapon usage" plugin decide of this instead.

2.4 - To define and implement a configuration file syntax for all this (XML or .ini file).
. - To separate the configurable data into several databases,
. - To define a syntax for each configuration file,
. - To implement a parser for each file.


3. Template.

3.1 - To define the list of plugins that will be featured in the United Bot, and their API. This will be a static list. It can't be otherwise. The question is to determine what part is "pluginnable" and what other is not.
. - Aiming algorithm,
. - Pathfinding algorithm,
. - Obstacle avoidance,
. - General combat behaviour,
. - Weapon usage,
. - Squad manoeuvers behaviour,
. - More to be proposed.

3.2 - To define an API for each.
. - The aiming algorithm relies on at least 3 data: the ideal angles (the angles the bot is moving its crosshair to), the current view angle, and the crosshair movement speed within the current frame time.
. - The pathfinding algorithm relies on a more complicated set of data; must be included the danger of each waypoint/navmesh face/node on a per-bot basis, the reachability of each link to be matched with the bot's movement capabilities, the path timing, etc. A fixed pathfinding algorithm must be imposed: I suggest A*. Then, the API can be constrained to an heuristic function and a cost function, given the availiability of enough data.
. - The obstacle avoidance must at least make available an engine visibility test facility (TraceLine) and also the velocity of the bot, as well as its movement input keys.
. - The weapon usage part must make available the whole weapon database, as well as the bot's current ammunition and equipment.
. - All of them must make available a standard set of tools to be defined, such as the server time, the bot position, angles, speed, forward/right/top direction (3D orthonormal referential). More to be added on request.


End of the project plan/roadmap.

Gentlemen, discussion:

[botman]

This has been discussed before, but little or no work was actually made publicly available. I think part of the reason behind the "failure" of early attempts was that, if nothing is ever released, everyone will lose interest.

I suggest that, as a group, you spend only a small amount of time designing what the template should be then, spend a little bit of time building an EXTREMELY simple prototype and release it to the public (with the understanding that it will constantly be improved upon).

That was basically what I did with the HPB bot when it first came out. The first HPB bot couldn't shoot, couldn't navigate around intelligently, couldn't handle specific jobs (like planting a bomb, capturing a flag, etc). But the important thing was that it was AVAILABLE for anyone to download and begin working with (even when there were problems getting bots to spawn properly in Counter-Strike, which was fixed by DaTa from the old Android bot).

So my suggestion is, don't spend 3 or 4 months designing something and then spend another 6 months trying to have a completely finished and fully functioning bot, because everyone (including the developers) will lose interest in it before it is available to the pubilc. Do something simple just to prove the concept and then keep constanly making improvements.

I have quite a bit of knowledge in the Unreal world now and would be a good resource for providing information and code in the Unreal engine (perhaps I would take on the task of "Lead Unreal Developer").

More disussion...

[botmeister]

I wrote most of this late last night, and some of it will add to what botman has already said above ...

The UB project can be made into something that is very complex, and complex tasks tend to take a long time to complete. If the time to complete is too lengthy, then there will be a lot of developer turnover, which will delay things even more, and the project may drag on for years. A long development cycle should be avoided right from the start.

How we are organized is of great importance. Those of us who have worked on software teams before will know what to expect, so let's deal with the inevitable challenges right from the start.

The development team must be able to make difficult design choices quickly, therefore we'll need a "Project Leader" to help facilitate the decision making. I suggest that we look at the how Bots United is structured for some ideas on how to structure the development team, or at least get the ball rolling.

The bot template concept with plugins was proposed for some very important reasons that everyone should understand:

The bot must be very flexible and allow multiple developers to add their own ideas on to it without much restriction or tight collaboration.

We do not have to actually build a fully functional bot, we only have to build the template, and this will save us a significant amount of time. It is the template that will allow developers to add their own plugin functionality without having to build an entire bot from scratch.

The template should keep things as simple as possible by only providing services that the various plugins and "game engine drivers" connect to. The template should not be a functioning bot by itself. It becomes functional as a bot only after a suitable collection of plugins are assembled together.

Getting to the point where plugins can be added will be the first major achievement. I suspect that we will want to add a few demonstration plugins to get the plugin devlopment ball rolling. The UB template will automatically help facilitate collaboration across plugin developers because it provides a consistent standard to work with. For the first time, we'll see developers working on building a common bot, but at the same time not actually working on the exact same bot! We'll also see for the first time users gathering up the right mix of plugins to make their own "flavor" of a bot, and perhaps people will be encouraged enough to learn C++ and tinker with modifying plugins to suit their individual needs better.

I propose we break the project down into "phases". Each phase should be completed relatively quickly before moving on to the next phase. We won't always know what is needed, but this is expected because a lot of the effort is R&D and we'll be breaking new ground, so we'll be learning and changing our ideas as the work progresses. There will be multiple "phases" of completion which taken together mayl span several months or more, but no individual phase should span more than 3 months or less if possible.

We define what "completed" means for each phase, so that a realistic time frame can be chosen and we will know what the final result is expected to be. For example, the completion of "phase one" will mean far less than having a fully functional bot template that actually works with 20 different game engines. Perhaps all it will do is provide a crude demonstration version of the plugin capability and engine interface.

This project will have to evolve over multiple stages.

I'd also like to point out the UB project will probably differ significantly from the UA Titan project. One difference that comes to mind is that a bot must function in real time without bogging down the game play. An administrative mod is not normally cpu intensive, and the design choices made will reflect this luxury. For the UB, we'll have to pay a great deal of attention to keeping down the CPU usage and making sure that adding multiple plugins does not slow down the game play too much. Ultimately of course it will be the responsibility of the plugin devloper to make sure their plugin does not kill things, however the template interface should be built in a way that helps plugin developers build good plugins that don't bog things down. We can do all sorts of things, including diagnostic tools which identify which plugins are causing bottlenecks or other problems, etc.

[Pierre-Marie Baty]

Very good. And botman has a very good point too.

I agree completely with him and I agree not to spend much time to planify things to the detail. And as botmeister says too, we need short milestones.

First off, WHO IS INTERESTED ? (outloud)

Then, once a core team is made, dispatch the responsibilities.

Then, assign a first milestone (e.g, have a bot to spawn in HL and Unreal using the same API),

and finally, switch the nerd mode on and CODE.

I think we can count botmeister, botman and myself in the project already.

Stefan was saying the other day that he'd like to join too, but I'd like him to come and apply himself. I think we can count on Aspirin too, but same thing. (ot: why not start writing drafts in the wiki ?)

Who else ?

[dead bwoy]

Is there any way someone like myself could observe the development process? I know I could keep up with the progress in the forum or wiki, but I'm interested in learning to code (C++). :D So is there any way I could just check out the files? like cvs on sourceforge? then, once I get a feel for the process, I can start contributing.
OR, if you guys don't mind dealing with a noob, can I be an apprentice on this project? :| ...

[Lazy]

Just dropping off an idea...

I think you should implement a small scripting into this. In addition to allowing plugin dlls, let people create and use plugins in a safe and easy to learn language (maybe basic like?).

This way, you get more people and ideas making good plugins using the easy language and C, C++ developers get to keep the power of their languages.

Just an idea though since virtual machines do take up a bit more work than native code, or maybe just compile into native code to begin with?

Just a thought, unless I completely mis-understood what you were saying.

[botmeister]

Is there any way someone like myself could observe the development process? I know I could keep up with the progress in the forum or wiki, but I'm interested in learning to code (C++). :D So is there any way I could just check out the files? like cvs on sourceforge? then, once I get a feel for the process, I can start contributing.
OR, if you guys don't mind dealing with a noob, can I be an apprentice on this project? :| ...
Some of the development process may be made public, perhaps all of it. We'll have to first wait and see what development process is decided on.

Not all the challenges will be C++ coding issues, a lot will have to do with software design issues which are program language independant. Usefull input can therefore come from people do not have any C++ knowlege, but I expect you will have to have a deep understanding of programming concepts in general.

As for being an "apprentice" you'd have to find people willing to do such a thing. Many of us are already bogged down at work during the day, and there's never enough hours at night to work on all the fun projects we'd like to be working on - some of us are going to bed at 2:00 am ... for some reason PMB comes to mind :D

[botmeister]

Just dropping off an idea...

I think you should implement a small scripting into this. In addition to allowing plugin dlls, let people create and use plugins in a safe and easy to learn language (maybe basic like?).

This way, you get more people and ideas making good plugins using the easy language and C, C++ developers get to keep the power of their languages.

Just an idea though since virtual machines do take up a bit more work than native code, or maybe just compile into native code to begin with?

Just a thought, unless I completely mis-understood what you were saying.
I'm sure scripting of some form will be talked about once we start defining what the UB will do and how it will be structured. At the very least a scripting component could be made available through one of the plugins, or through a plugin-like module.

[dead bwoy]

I spend an average of 3-4 hours a day, either playing the game, or messing about with server plugins. If you do make the source "browseable," (non-editable) I think it would be a good idea to see a well commented (or remarked) source, telling the "browser" what certain portions of the code actually do. That way anyone who wants to can learn can read about how. I basically want to learn how to code plugins for mods, for CS16 AND CZ. I can't wait to check out CZ! I like lazy's idea too, about an "easy" language for people who don't feel like trying to tackle c++ to write a plug-in. Just my thoughts...
===========================================

I am willing to do beta testing for WIN32, CS16 STEAM / DOD / CZ!!! (if needed)

[Terran]

I agree with the assumption that people could be easier attracted to this project if they have some "toys" to play with. Some may have good ideas for parts of a bot but are afraid of other parts, e.g. the navigation. Through this proposed plugin system they could concentrate on their part and don't have to worry about other parts. In the end this should result in a larger development community. ;)

Possible first goals:


spawn a bot with the same API in more then one game engine (as PMB suggested)
concentrate on ONE game engine and start with the design of some of the plugin interfaces, e.g. for an aiming plugin.
I should start to derust my C++, havn't used it much in the past years...

[Lazy]

I'm interested in helping out, I have lots of free time which I use to develop metamod plugins or other half-life related stuff.

Known languages ( complete ): C, C++, C# and I'm learning 6502 assembly now ( Though that has nothing to do with anything ).

[Pierre-Marie Baty]

First things first, before even pointing a finger on a first milestone, we need to get organized.

The people committed in the United Bot are listed here :

http://server.bots-united.com/wiki/index.php/UbCommittedPeople

We welcome Lazy in the crew.
Feel free to comment over this list.

Do you think it's enough for a first prototype ? If so, it'll be time to dispatch the tasks.

[botman]

"Do you think it's enough for a first prototype ?"

I assume you mean prototype of what types of modules there will be. There doesn't seem to be any actual content in any of the wiki pages (like diagrams showing how the modules are intended to fit together, etc.)

Can someone put up the proposed "bot core" code showing how you plan to manage multiple bots in the game and what types of functions will be called for each one? Something like this (in pseudocode)...


for (AllBotsCurrentlyInTheGame)
{
Call PreThink(); // do any pre-thinking processing here

Call Navigation(); // do we need to find a path or set up movement (this includes turning/jumping/ducking/etc.)

Call ItemUsage(); // do we need to press any buttons or use any world items?

Call EnemySelection(); // are there any enemies nearby?

Call WeaponSelection(); // should we choose a new weapon for the current enemy?

Call AdjustAiming(); // do we need to adjust our aim?

if (bButtonsPressed) // does the bot need to press any buttons to simulate player input?
Call PressButtons();

if (bMovementRequired) // does the bot need to send movement information to the engine?
Call SendMovementInfo();

Call PostThink(); // do any post-thinking processing here
}
Obviously other stuff would need to be added, but let's at least start with some kind of "core" framework that can be discussed in more detail.

botman

[dead bwoy]

so i was thinking about the name of the bot last night.
United bot
~appropriate since its named after the forum
Universal bot
~better describes the function of the bot in the name

My suggestion
shorten the name to "UNI-BOT"

[stefanhendriks]

sounds cool this stuff. So in fact to demonstrate this is working. We need a project with the simply API of the bot. And then we need a project which does the translation from HL to this bot. Very commented code so other coders can make an own 'translator'.

I think a sort of 'metamod' approach would be nice.

[botman]

"And then we need a project which does the translation from HL to this bot."

But don't think only in terms of Half-Life. The prototype should work on Half-Life, UT2k3/k4, BF1942, and Quake III as a minimum.

Think in generic terms instead of in Half-Life engine terms.

botman

[Pierre-Marie Baty]

By the way, botman, would you for a chance have heard of / do you know some basic bot templates for these engines available somewhere to download ? (even extremely basic)

I assume you must know something about this at least for Unreal with your knowledge of the Unreal engine...

[dead bwoy]

should i post botmans posted code above to the UB Drafts in tha wiki?

[Terran]

This would be the appropriate place ;).

[botmeister]

Here's some diagrams to get the ball rolling ...

Preliminary Diagrams showing the interface components

GE = Game Engine
GED = Game Engine Driver (custom made for each GE interface)
UBE = United Bot Engine
P = Plugin (supplies a bot component or related service)




|GE-1| <-> |GED-1| <-> |UBE| <-> [P-1, P-2 ... P-m]
|GE-2| <-> |GED-2| <-> |

:

|GE-n| <-> |GED n| <-> |






|P-1| <-> |P-API <-> UBE <-> GED-API| <-> [GED] <-> [GE]
|P-2| <-> |

:

|P-m| <-> |




Here are my rambling thoughts for discussion ...


The UB Engine should only provide a standard set of basic services which allow a bot to be constructed out of various "plugins".

Plugins provide the high level functions, such as combat behaviour and navigation.

Each plugin will use the services provided through the standard P-API (plugin API).

Plugins may communicate with each other, but only through the P-API.

The UBE may communicate with GED's but only through the standard GED-API (Game Engine Driver API).

For maximum flexibility we can allow plugins to directly call GED functions. This way certain game specific functions can be made available that otherwise would not be availble through the UB Engine API. Of course, using non standard function calls leads to driver dependant code which is not 100% portable to other game engines.

Plugins and GED's can replace some of the UBE functions with alternate versions providing "virtual function" capabilities.

Plugins and GED's can also "hook" or "chain" onto some of the UBE functions.

Some of the UBE services will provide status information about each bot, as well as the game environment.

Other UBE services will have to be defined.

The UBE may issue event messages to plugins as a means to trigger events, such as "round start", "team selection", etc.

A sticky problem to solve will be in how to share data between the UBE and the plugins. We don't want a duplication of effort across plugins, for example where each plugin keeps its own duplicate list of bots and associated data.

If data structures are to be shared across plugins, then how is this done? There's more than one way to do this, but some methods are more suitable than others.

How do plugins communicate with each other? Message passing is usually a good method of communications. Messages can be used as event triggers which simplifies the need for constant polling (only the message queue needs to be polled in a generic way).

Function "hooks" can work well as event triggers.

Changes to messages can be made without modifying API's.

more discussion ...

[Pierre-Marie Baty]

holy shit botmeister, you're setting us up a monster! o_O

I believe we should start MUCH simpler, for a start. Keep your scheme in mind as it will certainly be implemented later (although I'm not fond of some of the features you proposed, such as having plugins call directly engine specific functions, or hook over UBE functions. I believe the safest way is always to pass only DATA back and forth)

Even botman's code is above the minimal simplicity... I'd have thought rather of something like:

// main loop
for all bots in game
{
// plugin calls in each of these
UBE_BotSense (Bot)
UBE_BotThink (Bot)
UBE_BotAct (Bot)
}

// sensing part (PreThink)
UBE_BotSense()
{
if (VisionPlugin.is_plugged)
(*VisionPlugin.BotSee) (Bot);
else
UBE_BotSee(Bot); // fallback, default algo

if (HearingPlugin.is_plugged)
(*HearingPlugin.BotHear) (Bot)
else
UBE_BotHear(Bot); // fallback

if (ObstacledetectionPlugin.is_plugged)
(*ObstacleDetectionPlugin.BotSenseObstacles) (Bot)
else
UBE_BotSenseObstacles(Bot); // fallback
}


// thinking part (Think)
UBE_BotThink()
{
if (TeamworkPlugin.is_plugged)
(*TeamworkPlugin.BotProcessTeamIntentions) (Bot);
else
UBE_BotProcessTeamIntentions(Bot); // fallback, default algo

if (StrategyPlugin.is_plugged)
(*StrategyPlugin.BotSelectGoal) (Bot)
else
UBE_BotSelectGoal(Bot); // fallback

etc.
}


// Motile part (PostThink)
UBE_BotAct()
{
// same layout as the others:
// - press movement keys + weapon usage keys
// - move crosshair
// - send audio and text chat / communications
}

The UBE does not have to wonder about the quality of such or such plugin, I believe it must trust them blindly. Since the P-APIs will be fixed for each plugin, and since there will be a data standard for each, as long as the plugin is plugged, just call it. Else, fall back on a dumb algo, just to prove the concept works, HPB_template style :)

Hence I don't quite agree with your drawing of the P-API, botmeister, to me it's rather like

GE <-(arbitrary API)-> GD <-(GD-API)-> UBE <-(PluginX-API)->Plugin X
______________________________________<-(PluginY-API)->Plugin Y
______________________________________<-(PluginZ-API)->Plugin Z

(consider the _'s are spaces, this stupid forum software eats them otherwise)
The only API that will be unique and fixed, is the GD-API that will allow the United Bot core to talk to the game driver.
Since what is "pluginnable" is known (or at least to be defined, but that's the point), there is one P-API for each category of plugins. One API for all the aiming plugins, one other API for the obstacle detection plugins, one other API for the weapon handling, etc. These are not the same APIs.

Since we can't put together an unlimited amount of plugins, I believe it would be a waste of time and an useless expense in complication to unify these APIs into a generic one.

more discussion -

[stefanhendriks]

holy sh*t, its a lot of reading when ur offline for a long time.

Okay. This sort of thing (a game-independant bot) was already 'thought over' by Tub, and he sort of explained his concept to me. he HAD a working version btw. Simplw alking bot. using a 'layer' between the BOT and the GAME dll.

So simply said, probably said already:

game.dll (any game)
translation/layer.dll
bot.dll

the translation dll should provide information to the bot dll so the bot dll can blindy rely on this information and act.

so in short:

translation dll converts data into workable (for bot dll) information (and backwards).

I also think we need a 'seperated entity list'. The translation dll should make sure that all usable entities are generalized so the bot dll can work with them. E.g simple said you can have entities called 'door', 'window' 'breakable', 'goal'.

More concrete example would be to translate vectors. Some games use different vector formats (e.g. x, y,z or y,x,z).

There are a lot of things to think about.

I'd say begin with the general concept , i think we all pretty much agreed on a sort of translation dll and a bot dll.

I think PMB's example is already to in-depth. its more about the bot.dll layout and that does not matter much at this point (at least not that in-depth). I sort of suggest:

translation.dll

function hook_into_game()
{
// does all hooking, and retrieves information
}

function frame_handler()
{
// called by the game , then passes this to the bot dll
}

function vector(x,y,z)
{
// passes through the vector information if needed
}

function look@vector( vector )
{
// makes entity look at vector
}


bot.dll


void main()
{
loop through all bots
- retrieve status of bots
- run plugins (movement, combat, etc)
- send output to translation dll
}


Perhaps it is a bit vague, the bottom line is you have a simple IO system. Bot dll gets INPUT , changes things (according to plugins), sends OUTPUT and translation dll makes sure the bot 'does what it does'.

I think a simple command 'struct' will fit the job:

entity info / script:
- current vector
- current facing
- current health
- bit flag (buttons)
- bit flag (ground/air/water/etc)


most info is used for handling information, however, when sending information back you just change the vector for moving/facing.

Somehow i got the feeling this post became one spaghetty bs. Gotta run for class now.

[Terran]

How about this:
Instead of having only one plugin for a function at the same time we could support multiple plugins of one kind at the same time. This could be use to create bot personalities not only by parameter but also by different plugins. The actual bots would read some kind of configuration for their personality and use the plugins defined there or use random plugins (this selection process could be a plugin too). If no special plugin is defined for some funcions, use the globally defined plugin and if there is no globally defined plugin use the default/buildin functions.

[@$3.1415rin]

about botman's enemy selection / weapon selection / whatever stuff : I think it's not ok to have those stuff seperated like this. maybe we should go a similar direction like parabot does with it's goalfinder ( or joebot xp ), to avoid contradictory actions by different plugin. the goalfinder system of parabot and the joebot xp system which is very similar( http://www.lampel.net/johannes/joebotxp/JoeBOTXPDoc-beta.pdf ) are working nice, although it should still be extended, as anything we are working on :) but it produces resonable results :D and even a hirachial task system shouldnt be very difficult to implement here.

and as PMB said, keep things as simple as possible. and already think about dual use data, that's simplifying a lot of things ... like general data about entities and their specifications in a game, like zones in cs are not drawable, but perceptable and stuff.

back to reality, gotta go visit my grandma in hospital now :)

[botman]

"By the way, botman, would you for a chance have heard of / do you know some basic bot templates for these engines available somewhere to download ? (even extremely basic"

I'm not aware of any 3rd party bots for Unreal or Quake III since both of these games come with bots included. I'm thinking that since the developer of these games included bots with them that very few people would have the desire to create their own bots for those games.

Also, a comment about entities in the game. I don't think it's a good idea to try to abstract the game engine data (entities, the data structures for the world geometry, etc) since every engine will handle these differently. There should be no need for the bot core code to know anything about what's in the world. The core code should only be concerned with calling a predefined set of functions that are geared toward getting the bot to do a specific task ("see things", "hear things", "select a weapon", "fire a weapon", etc.). Each individual bot function should have the engine specific knowledge about how to get things from the world and how to interpret those things. This obviously means that all of these functions are going to be engine specific.

If you try to generalize things too much up front, you will quickly find that there's lots of special cases for each engine that don't fit the generalization model that you've chosen. Also, MODs for each engine will have there own brand new, unexpected types of entities that can't have been planned for in the generalized design.

There's nothing wrong with having engine specific code in each of the bots functions. There can still be generic code that all the bots use to handle common tasks (such as an A* path finding function, some function that generates a navigation mesh based on a list of polygon vertices, a function that provides realistic human-like weapon aiming, etc.). But none of the generic code should make ANY assumptions about things that are engine specific (such as what entities there are in the world, how a weapon fires its ammo, whether a bot has the ability to fly or not, etc.)

botman

[Onno Kreuzinger]

Hi,
i just wanted to "anounce" that i'm with you, i.e. im willing to support you in any way, i.e. tailor a common development enviroment, operating cvs & bugzilla, build testing, release packaging and the nasty QA stuff ;-)

cheers

[botmeister]

@PMB

If I understand what your are saying, you are proposing that there is no function calling API betwen the plugin and the UB Engine, instead there's only data structures which the plugin can interface on to. I assume this means that in your view the the UB engine will abstract the game world into something standardized for the bots to interface onto. Is my assumption correct?

@Everyone else

I agree we *have* to start off with something *very* simple, however we should at least have something for a "big picture" in mind before we go off writing reams of demonstration code.

I think I can see already 3 different perspectives on how a UB should proceed. Let's experiment with these ideas a bit more so we can settle on some kind of consensus.

I think we'll soon have to get organised with a development team structure, although throwing around our respective ideas is fine for now.

[stefanhendriks]

agreed. So how do we get started?

[botman]

I've been doing some research into adding a non-UnrealScript bot in UT2k3/2k4 and it doesn't look like there's any way to use C++ code with an Unreal MOD. You used to be able to do this with the old Unreal Tournament, but UT2k3 doesn't have the .h header files necessary to create your own DLL files from compiled C++ code.

Any bot code created for UT2k3/2k4 will HAVE to be written in UnrealScript (which limits you to what types of world geometry you have access to) and UnrealScript is about 20 times slower than compiled C++ code.

I was going to investigate how much was possible with Quake III as far as replacing the bot code with your own code, but I can't seem to find my copy of Quake III Arena (I can download the Q3 demo, but the demo doesn't allow MODding). I did a Google search for alternative Q3 bots and didn't find anything except discussions on ai-depot.com about someone trying to find an open source Quake III bot (which there was none). It's been a while (5+ years) since I did anything with Quake, but I do remember that all Quake II MODs had to be written in Quake C. I know that with Quake III, DLL file support was added, but I'm not sure if MOD makers would create their own DLLs or if they were still limited to Quake C for their MOD source code.

Knowing these limitations, it will be next to impossible to create a bot with any amount of shared code that will work in Half-Life, UT2k3, and Quake III.

botman

[Pierre-Marie Baty]

@botmeister: yes, completely. I agree it's a lot of work, but IMO that's the way to go to achieve the maximum independency.

@botman: can we at least make external code communicate with QuakeC code or UnrealScript ? If a simple translation layer is still doable, perhaps that's just what's needed ?

[botman]

"can we at least make external code communicate with QuakeC code or UnrealScript?"

You can with UnrealScript. There is a TCP/IP networking package called 'IpDrv' that allows you to create network connections that could be used to transfer movement commands and other bot input from an external application to the bot UnrealScript code in the game. This external app could be running on the server, or it could be running on some external client that has been configured to connect to the host running the game (security might be an issue here, also network bandwidth needed to constantly send commands back and forth could be an issue). Even with an external C++ application controlling the bots in UT2k3/2k4, there is no way to get polygon geometry information from the engine. The Unreal "compiled" map format isn't publicly available and the only information you can get at run-time through Unreal Script is Traceline() info (determining where a line or box collided with the world when ray tracing from one point to another point). Can you imagine the overhead needed to send commands and results back and forth over a network to do a dozen or so tracelines per bot per frame? :D

I'm not sure what Quake III has to offer as far as external network connections. Somebody would have to do some research on this.

I know that UnrealScript doesn't have any other mechanism for sending data back and forth between processes on the same machine (like shared memory), unless you want to start hacking the engine executable to make something like this possible (i.e. hacked DLLs and whatnot), which I doubt anyone here wants to go that route.

botman

[botmeister]

Looks grim for at least the games botman mentions. Are they any other games worth researching?

It may still be worth building the UB, but IMO not for commercial games.

There was some talk of building our own game template which would provide 3rd party bot support by design, and provide many other services by design which are not seen in commercial games (and probably never will be seen). Some of the concepts disucssed for the UB would apply directly to the game template idea.

I would not consider building our own game engine, but instead make use of existing open source, or "free" commercial, game engines.

The same idea of game drivers would provide an interface between the game template and the engine. The same idea of plugins could then be constructed to provide all the essential services which make up a full featured FPS game. A UB would seemlessly plug into the game template providing "by design" 3rd party bot support (for the first time ever). Imagine what you could do with such an interface?

The plugin concept will allow anyone to develop components for the game, with collaboration among developers. The template will enforce standards on the developers, and provide a form of "automated collaboration" (so to speak).

I may be crazy to even suggest such a thing, but if we don't do something radically different, we'll be stuck with the same old worn out problems and limitations forever.

[stefanhendriks]

in fact its not crazy, its a challange. Just do what nobody (dares) to do.. :)

[Pierre-Marie Baty]

@botmeister: the fact is that, I think, if we can't do that for commercial games, our project will generate little interest.

@botman:
Can you imagine the overhead needed to send commands and results back and forth over a networkNot over a network... over the loopback interface :)

... to do a dozen or so tracelines per bot per frame? :DIn HL, I fire around 80 tracelines per bot per frame, it works quite well when you do it cleverly... :)
*edit* wait, right, not "per bot"... hmm, well... 80 tracelines per frame at least. That's what my counter tells me :D

[Terran]

@botman:
Not over a network... over the loopback interface :)
You always have a lot of overhead if you use a general purpose network stack to transfer data, especially with TCP/IP. It doesn't matter which interface you use! All your data will be wrapped into packets which need headers and checksums. And there is not only one header with TCP/IP, there are at least two of them, one for IP and one for TCP/UDP. And both require checksums which need to be calculated. That's one of the reasons why you never get the expected bandwidth that you expect when you transfer data using TCP/IP. Modern server clusters e.g. use specialized network hardware and stacks which are optimized for speed and bandwidth and only need minimal overhead. But I doubt that UT supports that ;).

[botman]

Agreed. It would be most efficient if you could have some sort of shared memory segment to send things back and forth between a game engine and an external application running on the same server. But since UT2k3/2k4 doesn't support this, that's not an option.

The other problem with a loopback IP stack is even it will have a limited Operating System buffer space. So if you send too much data, the sender will be forced to suspend until the receiver has emptied some data from the channel. I have no idea what the size of the buffer is for Windows or Linux OS, but I'm pretty sure that this buffer isn't dynamic. It should be easy enough to test by creating a simple IP application with a sender and receiver that opens a port and have the sender keep sending 1K blocks of random data, while the receiver just sleeps and never reads anything. If you have the sender keep spitting out some output every second or so, you'll probably see a point when the sender stops sending output (because it's suspended).

botman

[Pierre-Marie Baty]

from http://unreal.epicgames.com/UnrealScript.htm:
[...] This fact is transparent to UnrealScript code, but becomes very apparent when you write C++ code which interacts with UnrealScript.so it MUST be possible somehow.

Still investigating...

*edit*
In "UnrealScript variables" section

native: Advanced. Declares that the variable is loaded and saved by C++ code, rather than by UnrealScript. it's a variable specifier (like "const"). looks interesting...

[Pierre-Marie Baty]

I was certain to have seen that somewhere already, now here it is !

http://www.planetunreal.com/gamebots/

read the 2nd paragraph...

[botmeister]

In theory, native functions can be used to pass information back and forth between a custom C/C++ DLL and Unreal Script - there may be no need for a network interface at all.

native (classes (http://wiki.beyondunreal.com/wiki/Class_Syntax) / variables (http://wiki.beyondunreal.com/wiki/Variable_Syntax) / structs (http://wiki.beyondunreal.com/wiki/Variable_Type))
nativereplication (http://wiki.beyondunreal.com/wiki/Class_Syntax)

http://wiki.beyondunreal.com/wiki/UnrealScript_Keywords

http://www.esconline.org/Resources/native.html

[botman]

"so it MUST be possible somehow"

Yes, it's quite trivial for Unreal Tournament licensees. Native code is C++ code.

Unreal Tournament (from, what 1997?) included the header files necessary to use native C++ code in your MODs. Starting with UT2k3, Epic stopped including the header files (probably to help prevent cheating in the game). UT2k3/2k4 don't support any kind of native C++ code unless you have licensed the Unreal engine from Epic.

botman

[Pierre-Marie Baty]

argh. in yer face.

* How much does it cost to buy even the smallest of the licenses from Unreal ? (utopia!... 9_9)
* When Unreal updates/changes the engine, what is their policy regarding their licensees ?

<walking in circles>

If we drop Unreal (with lotsa regrets, since botman would have been a weighted asset while working with this engine), what is possible with Battlefield 1942 for example ?
We need support of at least 2 game engines besides HL, in my opinion.

[Rick]

Uhm both medal of honor allied assault and serious sam have open source bots. Though I know for sure that the bot for serious sam is a 'bot-mod' and I think its written in a C variant, in case this matters.

[Pierre-Marie Baty]

MoH:AA uses a Quake-like engine so IMO it's no surprise it supports 3rd party bots.

I'm currently scouring the net for info about the BF1942 engine. It's a proprietary engine called "Refractor 2" and there's no official SDK although Dice says they are working on "modding tools". I don't know if modders have the same amount of control on the engine than with the Quake series. It looks like Desert Crisis (?) is a total conversion MOD for BF1942 but I don't know the amount of coding involved.

I hope the Unreal track is not definitely closed yet.

[@$3.1415rin]

does anybody know anything about modding capabilities of farcry e.g. ?

[stefanhendriks]

farcy has mod compatibility. I did not take a look into it yet, but it seems promising.

Btw, i do not know if i have to 'apply' for this project? i saw at the wiki page i am not listed yet. Ofcourse i am 100% interested and it would be nice to contribute. I don't know what i can do, except typing long messages with no/less meaning? :P

[Terran]

Than add yourself to the wiki - that's how this nice tool works ;)

[Onno Kreuzinger]

jep, your email account (user/pass) is reserved for you, else any username can be choosen, ist free and open, a wiki.

[Pierre-Marie Baty]

Guys, I need an update on your committment to this.

=> What do we decide regarding the Unreal engine ?
* drop it ?
* use a network socket library to do inter-process communication like the GameBots at planetunreal ?

Other questions will follow but this one oughta be answered first. Answers like "it will be very difficult to do this or that" or "we can do that but it will be tricky" are of no use for anybody. We can tergiverse for ages without taking a decision. DO WE work with the Unreal engine or not ?

Personally I think it's worth a try. The Unreal GameBots are a proof that the concept is working. Even if it's not the acme of usability, we'll have a (primitive) UbGameDriver more in our list, and this is the most important.

I need your point of view.

[Terran]

If it's doable, let's do it. At least we know that it can be done using the network layer "trick", therefore we have a start. ;)

But I don't know enough about bots to evaluate if the GameBots API provides enough information and functions for our goals. But at least we could spawn a bot - our first goal.

[stefanhendriks]

I agree with terran, lets do it.

[botman]

We could always say we support UT2k3 and then drop it later if needed, but you might want to spend some time investigating the other desired engines (Quake III Arena, BF1942, etc) to see if external bots can be created for those as well. If you don't, you might wind up only supporting the Half-Life engine after finding out that all the others just don't allow for easy enough integration of a C++ bot.

EDIT: Time for a new thread?

botman

[botmeister]

We could always say we support UT2k3 and then drop it later if needed, but you might want to spend some time investigating the other desired engines (Quake III Arena, BF1942, etc) to see if external bots can be created for those as well. If you don't, you might wind up only supporting the Half-Life engine after finding out that all the others just don't allow for easy enough integration of a C++ bot.

EDIT: Time for a new thread?

botman
There should be a whole forum for this project imo.

Personally, I'm bothered by the approach in general because it is not general enough.

It appears that very few games intentionally provide the kind of support we need. Even if all the games mentioned are capable, the list is still small, and a new release can easilly knock a game permanently off the list.

Is there another way?

I'm thinking perhaps we can get to a game engine through other means that may be more generic. For example by doing some serious hacking into the dll's and capturing network messages.

One possibility is to build a client side bot that sits on the server side. The bot would emulate a human player.

I realize hacking binaries and/or building a client side bot are not new ideas which have serious problems of their own, but I mention it to demonstrate there are alternatives and to see if anyone can think of something that we could use more universally.

The one advantage we do have is that our bot can sit on the same machine as the game engine and client, giving it access to all the game binaries and other resources. I'd focus on this important advantage to look for a solution.

The line of thinking I'd look at is to commit blasphemy and emulate what the cheat programmers do 8D I've seen some amazing cheats for HL based games that sit on the client side. If the cheat programmers can get good access to the game from a remote client machine, we ought to be able to do even better with local access.

We have to be very creative here, and the normal way of doing things may not be good enough. As they say, it's time to think outside the box, let's get crazy and throw some wild ideas around for at least a moment or two. :D

[Onno Kreuzinger]

One possibility is to build a client side bot that sits on the server side. The bot would emulate a human player.

I realize hacking binaries and/or building a client side bot are not new ideas which have serious problems of their own, but I mention it to demonstrate there are alternatives and to see if anyone can think of something that we could use more universally.

The one advantage we do have is that our bot can sit on the same machine as the game engine and client, giving it access to all the game binaries and other resources. I'd focus on this important advantage to look for a solution.

The line of thinking I'd look at is to commit blasphemy and emulate what the cheat programmers do 8D I've seen some amazing cheats for HL based games that sit on the client side. If the cheat programmers can get good access to the game from a remote client machine, we ought to be able to do even better with local access.

We have to be very creative here, and the normal way of doing things may not be good enough. As they say, it's time to think outside the box, let's get crazy and throw some wild ideas around for at least a moment or two. :D
i thougth about that too, when first reading this thread, and i think it could even work for steam/vac servers, but i doubt that cheating death and other anti cheat software would like this aproach. and since the code sharing / opensource of the UB would allow to copycat the interfaces it could acctually be used to make very bad things. allthough not easy to imagine, one could make very weird things like running bots on the client which could be used to help the player playing on that pc. the hl server would not be able to to tell the difference.

or i'm i to paranoid...

cheers

[botmeister]

[QUOTE]
i thougth about that too, when first reading this thread, and i think it could even work for steam/vac servers, but i doubt that cheating death and other anti cheat software would like this aproach. and since the code sharing / opensource of the UB would allow to copycat the interfaces it could acctually be used to make very bad things. allthough not easy to imagine, one could make very weird things like running bots on the client which could be used to help the player playing on that pc. the hl server would not be able to to tell the difference.

or i'm i to paranoid...
[QUOTE]

Don't forget everything will sit on the same machine, so there's no opportunity for real cheating by remote clients unless a network protocol was specifically built to allow such a thing. It would also have to be installed on the server by the server operator (or someone hacking into the server). This can be done if someone wanted to do such as thing using the methods we're now using already, so in short whatever interface we come up with won't make much difference to the cheaters because they already have full access to the server side interface.

Cheating Death and so on (including VAC) would not be able to detect the going on's of such an interface just as they do not detect the current methods we use for inserting our server side plugins. The current methods we use are useless as cheats because remote clients have no access to the interface.

[FrostyCoolSlug]

I like this idea, it seems that rather than calling them 'plugins' you should call em 'modules' which can (possibly) be loaded and unloaded dynamicly (just simple things like Weapons usage, unload one module and load another), so its something like

Game Engine <--> 'Wrapper' <--> Main Bot Dll <--> Modules.

Someone mentioned a few posts back about using 'Hack style hooking', personally, i think this is a great idea. Its just the difficult part would be preventing things like VAC going nuts :p

I used to do a lot of work for the anti-cheat community, so i've read and tested things like the OGC source (Note: I did this locally, and not on public servers. Dont call me a cheat).

Although i dont concider myself an experianced C++ coder (in fact, i'm trying to work out htf classes work properly, other than that, i'm quite proficiant) I've assisted in developing an IRC Daemon called 'InspIRCd' which is coded in C++ and is modular. I'd like to assist in this project in some way, even if i'm just a beta / alpha tester.

Thanks :)

I'll spend some time reading over Botman's HPBBot source

[botmeister]

@$3.1415rin (http://joebot.bots-united.org/) I agree we need a new forum for all this to separate out all the "threds" going on in here. We may need a council vote. I think you make 4 who are in agreement so far?

[Pierre-Marie Baty]

OK, since a majority in the council already agree, I've set us a new forum and done some cleanup in this monster thread to separate it into different topics.

Let's try to be a little better organized now :)

[FrostyCoolSlug]

nice job, will make life easier :)

[botmeister]

Great job PMB!

[botmeister]

Question:

Is it worth building the United Bot now, for Half-Life with the ability to work later with other engines should it ever become possible?

The reason why I'm bringing this up now, is that POD 2.6 mm is starting to fill the role that the United Bot was to fill - a common bot that we all can work on together.

It seems to me, fixing up POD is a good idea in the short term, but would it not be better in the long term to build the United Bot even if it ends up only for Half-Life?

[Pierre-Marie Baty]

Question:

Is it worth building the United Bot now, for Half-Life with the ability to work later with other engines should it ever become possible?

The reason why I'm bringing this up now, is that POD 2.6 mm is starting to fill the role that the United Bot was to fill - a common bot that we all can work on together.8o 8o
WHAT????
8o
Robert you do realize POD-bot is one if not THE ONE of the most platform and game-centered bots ever written, that POD-bot = COUNTER-STRIKE bot and nothing else ???
Have you looked at this bot's source code ? You can't possibly have, to say something like this (in which case, nothing wrong - but just have a look at it, for heaven's sake). Work together ? To me it would rather be "happily patch stuff together". Put patches on a pierced barrel. Where every patch you apply makes another hole somewhere else !

And personally, I don't feel at all that this bot is starting to fill this role in any way. The bot has its supporters, who are mainly former disappointed PoXBot supporters. What case do you make of all the non-CS bots ? These people are not wanting a multi-engine, multi-platform bot, they want a potable Counter-Strike bot, period !

Excuse me if I sound a bit rude, but your post really puzzles me ! I *MAY* have completely misunderstood what you were saying, but in such a case I'd enjoy some clarification ???:(

[botmeister]

Nah, you've misunderstood, or my post was poorly worded or both. I know what the POD 2.6 source looks like inside, and that it is very specific to CS.

What I see happening with POD is a small gathering of people working together to fix it up and add new features to it, and that's the sort of thing I'd like to see happen with the UB, hence my mention of "assuming the role of ...". which I can see now was too strong of a statement to make.

What I wanted to ask is should we work on the UB even if we only know how to attach it to half-life games?

[Pierre-Marie Baty]

Of course, precisely yes.

botman has good knowledge of the Unreal engine and said he would be willing to assume the role of lead coder for the Unreal game driver - all we have to do is to show a working proof of concept for making UnrealScript and an external DLL communicate.

[Lazy]

My computer is stable again, I will continue work on communicating from unrealscript to an external program.

[Pierre-Marie Baty]

Lazy, don't know if it's too much asking, but I think I would enjoy a weekly update on your experiments. :)

[Lazy]

No problem, It's just been a busy few weeks and I'm only just starting to see some more free time open up.

[Pierre-Marie Baty]

How's the progress for now Lazy ?
Did you have a chance to look at it ?

[Lazy]

I got everything installed but I still have to learn UnrealScript before anything else.
Theres still lots to do and I have to do some work in a few minutes until maybe this evening when I MIGHT be able to sit down at it for a while.

[FrostyCoolSlug]

Re: BF1942

I dont know if i mentioned this before (i cant remember doing so) but http://www.blackbagops.com/ has a quite unique program that is able to somehow hook itself onto Battlefield 1942 to allow for server administration, Maybe it would be worth speaking to a member of the development team there, to ask exactly what was done, and how it was accomplished, and see if that can in some way help us out.

[Pierre-Marie Baty]

That is interesting indeed.
As soon as the Unreal and HL drivers development are launched I take a note to get in touch with these guys.

How's your progress so far, Lazy ?
Don't hesitate to post progress logs, even insignificant things such as "today I learned how to make my first UnrealScript", so that we know what's going on. Nothing wrong by not having the time to do significant progress each time. But keep in mind that many people here are concerned by what you are doing.

[Lazy]

I'm learning UnrealScript right now, UT 2003 is installed and I am working as fast as I can with the time I have.

[RedFox]

Just wanted to share some ideas I've had. The last bit of work on the design of foxbot I did (uhg...I may actually code something _eventually_) I made specifically to be mod independant.....as a side note (appart from the halflife calls) I noticed it could be game independant too....if hooks to the engine could be found.

The basic premice was that it used a blackboard architecture.....a shared memory pool where modules (such as, Can I see an enemy...or Navigation) could post and retrieve information...so all the bits of code where independant of each other.
Given raw entity data posted in the memory pool.....the module that checks visibility would notice it (on its next cycle) and then test to see what was visible to a bot....
it would then post the results.....so the memory pool now contains entities....and what bot can see them.
You can have modules that attach information to them such as....is it hostile...is it shooting..etc etc...
New modules, or changes to module designs won't effect other modules.....unless they change the data thats posted.

Time slicing can be applied if needed....as data is retreived and left on the pool as needed.


After reading over what you've said I scetched out an idea....assuming its possible....the wrapper dll could have plugins too....the wrapper would provide standard calls to and from the bot.....
plugins for this would provide the code needed to hook to specific game engines....so the wrapper need not change, just the hooking....
As some games won't provide all the data needed...plugins can simulate it for some games too.

Not sure what you all think of the two ideas...just my take on it all.
I like things to be easily expandable.

[Maleficus]

I was going to investigate how much was possible with Quake III as far as replacing the bot code with your own code....... but I do remember that all Quake II MODs had to be written in Quake C...... I know that with Quake III, DLL file support was added, but I'm not sure if MOD makers would create their own DLLs or if they were still limited to Quake C for their MOD source code.
Only QuakeI used QuakeC. QuakeII and QuakeIII were plain C and used .dlls (Quake III could also use .qvm which was an opcode based virtual machine that was still coded in C, but was safer than running a .dll). ;)

Its really easy to replace the Q3 bot AI with your own - I already wrote a framework that did this in Q3, which I later converted for RtCW, which became the Fritz Bot. :D

Since RtCW is based on the Q3 engine, it was really easy to do.

The only active q3 bot I know of is the Art of War bot for Q3 - its quite good: http://www.planetquake.com/artofwar
It isn't a "from scratch" bot tho, they just improved the Q3 bot AI. They were supposed to release source for it, but they never did. :(


They have been other custom bots (Clockbot, TangetBot, Battlebots, etc), but they all died. Having an official bot in the game really put a damper on the communities willingness to try out a new bot. And most people just didn't care. :'(


PMB: if your looking for another engine, Q3 (or perhaps Doom3) would be a really good choice! I myself am really looking at Doom3. The game itself will probably be pretty flat, but knowing id software, it will be VERY moddable and the possibilities will be limitless! And theres going to be a whole new generation of games based on it once its released (now that Q3 is getting long in the tooth).

I can't promise I can help out with the design itself, but I can be a source of info for the Quake series of games, and their offshoots, and probably Doom3 (which will use C++) too when it comes out (I've been programming/modding id games since Quake1). :)

[RedLink]

Hmm, I think BF1942 uses a script language just like Unreal. I`m actually working on my own game language named "PCoSL" mainly used as a script for my own game engine "Project: Fuji". I have put a lot of effort in making it universal and easy to convert/adapt, so it might be of some use.

BUT to make a universal A.I bot script would probably be something really useful but as botman mentioned start small and then grow big :D. Just to be able to make a bot spawn in 2 totally different games is a really big step in the right direction.

I rather think that you should but a lot of effort in adding support for game engines like Unreal, HL/HL2, Quake3 and BF(2?). Simply because these are the engines that continue to grow even after the game it self has died.

Anyway, If you guys ever need some help don`t hesitate to semd me a msg @ redlink@redlink-studios.com