United Bot philosophy and roadmap.
 

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:

Re: United Bot philosophy and roadmap.
 

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...

Re: United Bot philosophy and roadmap.
 

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.

Re: United Bot philosophy and roadmap.
 

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 ?

Re: United Bot philosophy and roadmap.
 

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? :| ...

Re: United Bot philosophy and roadmap.
 

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.

Re: United Bot philosophy and roadmap.
 

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

Re: United Bot philosophy and roadmap.
 

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.

Re: United Bot philosophy and roadmap.
 

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)

Re: United Bot philosophy and roadmap.
 

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...

Re: United Bot philosophy and roadmap.
 

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 ).

Re: United Bot philosophy and roadmap.
 

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/i...ommittedPeople

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.

Re: United Bot philosophy and roadmap.
 

"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)...

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

Re: United Bot philosophy and roadmap.
 

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"

Re: United Bot philosophy and roadmap.
 

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.

Re: United Bot philosophy and roadmap.
 

"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

Re: United Bot philosophy and roadmap.
 

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...

Re: United Bot philosophy and roadmap.
 

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

Re: United Bot philosophy and roadmap.
 

This would be the appropriate place ;).

Re: United Bot philosophy and roadmap.
 

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)




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 ...

Re: United Bot philosophy and roadmap.
 

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:
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
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 -

Re: United Bot philosophy and roadmap.
 

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
bot.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:
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.

Re: United Bot philosophy and roadmap.
 

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.

Re: United Bot philosophy and roadmap.
 

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/joebo...XPDoc-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 :)

Re: United Bot philosophy and roadmap.
 

"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

Re: United Bot philosophy and roadmap.
 

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

Re: United Bot philosophy and roadmap.
 

@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.

Re: United Bot philosophy and roadmap.
 

agreed. So how do we get started?

Re: United Bot philosophy and roadmap.
 

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

Re: United Bot philosophy and roadmap.
 

@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 ?

Re: United Bot philosophy and roadmap.
 

"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

Re: United Bot philosophy and roadmap.
 

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.

Re: United Bot philosophy and roadmap.
 

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

Re: United Bot philosophy and roadmap.
 

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

@botman:
Not over a network... over the loopback interface :)

In 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

Re: United Bot philosophy and roadmap.
 

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 ;).

Re: United Bot philosophy and roadmap.
 

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

Re: United Bot philosophy and roadmap.
 

from http://unreal.epicgames.com/UnrealScript.htm:
so it MUST be possible somehow.

Still investigating...

*edit*
In "UnrealScript variables" section
it's a variable specifier (like "const"). looks interesting...

Re: United Bot philosophy and roadmap.
 

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

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

read the 2nd paragraph...

Re: United Bot philosophy and roadmap.
 

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 / variables / structs)
nativereplication

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

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

Re: United Bot philosophy and roadmap.
 

"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