-
Notifications
You must be signed in to change notification settings - Fork 23
What is a bot?
Bots are computer controlled opponents, typically designed to play a game in a similar manner as what you might encounter when playing online multiplayer with other players. Although it is very difficult to get bots to actually play like a human would, most bot authors invest considerable time giving the bots the ability to competently play the game, and be a fun opponent.
Anyone that has played FPS(First Person Shooter) games is probably familiar with bots.
Bots typically reside on the game server, meaning it is the game server that actually runs the bots, processes their navigation and AI, and ultimately controls the overall actions of the bots. Client side bots are commonly considered cheats, because they too are computer controlled and are often capable of giving individual clients unfair advantages. Aimbots could be considered a form of client side bot.
Omni-bot should not be confused with an "aimbot". Omni-bot is not a cheat. If you have come looking for cheats or aimbots, you have come to the wrong place.
Bots can be useful to players or server administrators for several reasons.
-
Sometimes, for some people, playing against a bot can be more fun than playing a human. Humans are commonly idiots in multi-player games. They may cheat, complain, camp vehicles/spawns, teamkill, or generally do other things that ruin the enjoyment of other players. A well coded bot will play the game as designed. They don't complain. They don't cheat.
-
They can be good practice. Playing against some bots, or even a hoard of bots, can be a good way to practice your death-matching skills, dodging, avoidance, sniping, etc.
-
Bots are a good way for a server administrator to attract real players to their server. In a server browser, there are often many hundreds of servers listed. Few people will choose to join an empty server, so bots are often a good way to keep some gameplay going on a server even when no humans are around. Most bots have options that allow bots to be removed from the game as human players join, eventually resulting in a game of all or mostly humans.
-
Playtesting maps. As a mapper building a map, it is often a good idea to playtest it. Sometimes it can be difficult to get enough humans together to properly test a map. If the mapper so desires, they can build bot navigation for their map as they develop it and test it with a full game of bots, or humans and bots, to test the balance, fun, and overall flow of the map. Foxbot for TFC was often used in this way.
The answer to this is somewhat complicated. Since computer controlled opponents cannot perceive a game world in the same way that a human does, by some strict definitions, one might say that a bot must do limited cheating to even function at all, although that is the case in any and every game that one plays against computer controlled opponents. The key is that most A.I. developers have as their primary goal, creating a computer controlled opponent which is fun to play against, and that typically requires artificially restricting what the bot can "know" about the environment, and faking things like reaction times, etc.
Some examples of things that might be considered cheating
- Bots 'see' by doing collision tests with the environment. This means that in order to determine if a bot can 'see' another player, a ray to world collision check is shot from the bots eye to the target. If this ray doesn't collide with anything, such as walls, other players, props, etc, we would consider the object visible. If the ray does hit something we consider the view blocked.
This mechanism is both a strength and a weakness of bot AI. The strength, and the potential for cheat accusations to come about, are often due to the reliance on collision to determine visibility. For example, many games have foliage in their outdoor maps. Grass, bushes, trees, etc. Often these sort of things do not have any kind of collision on them, so they don't obstruct the view of a bot at all. To counter this, some games go through extra efforts to simulate obstruction through foliage. Some bots don't make such compensations, so in maps that contain objects that to humans might be considered cover because they block your view with partially opaque geometry, sometimes the bot is able to see right through them as if they weren't there. This also comes into play with game elements such as flash bangs, smoke grenades, tear gas, or other things that might to a human player be based around altering the rendering of a human players screen. These sort of effects are often faked with bots, in one way or another through much simpler mechanisms. For example, smoke bombs in ET are treated as temporary view occluders to Omni-bot.
A weakness of this visibility method, is that it gives the bot a very rough view of the environment. At the simplest level, a bot might cast a single ray from his eye to the enemy eye or enemy position to see if it can 'see' them. If the ray hits something, he can't see it, if it doesn't hit anything, he can see it. The problem with relying on a single raycast to make this determination, is that in reality that one spot on the target might be obstructed, while the rest of the target might be visible. Due to this, sometimes bot authors do several raycasts at different positions on the target, to account for the possibility of partially obstructed targets. This results in a better view system, at the expense of requiring more processing. In extreme cases, a bot might cast a ray to every body part or bone on the target. This would give excellent resolution to the bot, but at a high cpu cost. Ultimately it depends on how accurate the bot author wants them to be. Most games typically don't notice slight inaccuracies in the resolution of the bots view system, while a slower paced tactical game might benefit more from it.
Also under the category of cheating, it is true that as a server side mod, the bot author technically has full access to where everything and everyone is in the game. It is fully within the capabilities of a bot coder to make the bots fully aware of everyone and everything. As a matter of fact, that would be the easiest way to make a bot. Fortunately, most bot authors don't like their bot to cheat that badly, which is why a bots knowledge of the world is heavily filtered, usually by parameters that mimic the view capabilities of a human player as close as possible, like the field of view, view distance, and whether the view is obstructed, usually by doing ray cast collision checks.
Finally, the subject most often accused of cheating is a bots aiming. It is very easy to make a bot shoot exactly on target every time. Some bots have implemented aiming systems that have resulted in an almost superhuman accuracy. These bots are rarely fun to play, and most bot coders also put a lot of effort into a more human-like aiming system, with properties such as a limiting turn rate, minimum reaction times to even 'notice' a target, and adding acceleration/deceleration to aiming, both for smoothness and for less robotic behavior.
In the end, bot AI, and game AI for that matter almost always cheats to some degree. It isn't feasible, both in time and processing power, to make an AI work exactly like a human. Some cheating is inevitable, but a good bot will not make it obvious that they are cheating. It's all about being fun for the human players, and sometimes the code has to be written to work around the fact that bots don't see a rendered world at all like players, and sometimes have very limited or non existent hearing capabilities too. Ultimately it doesn't matter, as long as the gaming experience is fun.
Omni-bot is a project with much bigger goals than just being a bot.
From the start of development, the intent was for Omni-bot to be a bot capable of being easily ported to different engines, and different mods within those engines. Essentially it was to be the first cross game and cross mod bot. It was my desire from the start that the Omni-bot code would primarily be contained seperately from the game, and interact with the game in a standardized manner that could be easily ported to other engines and mods with minimal work. The vast majority of the Omni-bot code is shared between all supported games and mods.
The Omni-bot goals were pretty ambitious.
- Create a bot that was easily portable to completely different engines and mods.
- Create a highly customizable bot, with data driven properties, and scripting support.
- Release an SDK, so that other mod authors can leverage the design of Omni-bot to easily enable bots in custom mods.
These goals have long since been achieved. Omni-bot supports Enemy Territory, Quake 4, ETF, early unreleased support for HL2:DM, and soon the official bots for Fortress Forever. Development continues, with improvements made to the code that all supported games can take advantage of, as well as plans for supporting more games.
The desired support for many games and many mods is where Omni-bot got its name.
The primary Omni-bot developer, Jeremy(me), started out as one of the later bot coders of Foxbot, the popular bot for Valves Team Fortress Classic. As a huge TF fan, and a even bigger fan of bots, coding them became an addiction from early on. Jeremy started Omni-bot in winter of 2004, building up the shared framework and game specific interface code.
The first supported mod was ETF. Due to my love of team fortress, and the fact that ETF was a mod in development, on a mod friendly engine(Enemy Territory/Quake3), it made sense to use it as both a development platform of Omni-bot, but also as the first supported mod while I built up the Omni-bot code. ETF shipped with a very early playable version of Omni-bot. It had limited scripting support, but was capable of playing most of the Team Fortress classes decently. During development of ETF, Marc "Magik" joined on as an Omni-bot developer to develop support for Enemy Territory. Marc was crucial in early development of Enemy Territory support while Jeremy primarily worked on ETF.
After ETF released it's final version, Jeremy moved over to help support Enemy Territory, where a majority of the collective Omni-bot development was focused for quite some time. While Marc is currently kept busy with real life, he has helpfully provided a home for the Omni-bot website on the internet on a fast dedicated server. Hopefully in the future more free time will become available for him to do some more bot work.
Throughout development of Enemy Territory, Omni-bot has grown leaps and bounds over it's initial release in ETF. The scripting capabilities have been dramatically improved and the overall capabilities of the bot are significantly more than they started. Today, there is enough scripting exposed in Omni-bot for a user to take complete control over the bots, implement custom goals, or just about anything they desire.
Additionally, Omni-bot support has been added to several Enemy Territory modifications, See Supported Games for details.
A majority of the Omni-bot code is contained and isolated within a dynamic library. A small part of bot related code is compiled into the game. This code is called the interface code, because it's job is to act as the middle man between the engine, and bot. It translates the engine specific data into the standardized messages and implements functions that the bot can call based on common requirements.
Originally, the intent was for a single library(.dll, .so) to contain support for all mods, so every game loaded the same dll to run the bots. Early on, ETF and ET both shared the same dll, which was then simply omnibot.dll It became clear early on that this wasn't a practical way to set it up. Although it was relatively easy to do, lumping all bots into the same dll created several limiting factors that would have been hell to work with.
- The dll would eventually become very large. Even though much of the code is shared in the bot dll, custom game modes, weapons, and goals are implemented as part of the support for a particular mod.
- It would require each and every release to be an update for every supported mod. It was clear very quickly this wasn't going to happen. One person doesn't have the time to develop several mods to a releasable state at once, and even with multiple developers, it would be very difficult to synchronize releases.
Ultimately it was decided to split dlls per mod, although it is still entirely possible to add support for several mods and/or games to a single dll. Now, bots for a given game can be developed and released independent of each other, which simplifies the process. It also allows a distribution method to differ between mods. The desire at first was that all Omni-bot would reside in a central location, such as C:\Program Files\Omni-bot This is mostly how it works, but it is often desirable to be packaged another way, for dedicated servers, or for some mods, like ETF and Fortress Forever, where the bot must come with the mod and more or less be a part of it.
That's more or less a rundown of the goals and history of Omni-bot. Presently, development moves ahead at full speed, with some interesting developments in the works. Follow the development updates for more details. The community has grown pretty large and users are often submitting navigation and scripts for the bot to share with others.
All feedback is taken into consideration. If you have ideas for improvement, or ideas that would simplify or expose more flexibility in the scripting, feel free to share them. Much of the scripting systems power got the way it is now from feedback from people that were using it. Many optimizations, many bug fixes, many functions, and many features were a direct result of user requests and questions about how to do something in particular.
See Supported Games for details.