Tutorials by Bob Lawrence
World Editor Tutorial
Presentation of GEdit
The portion of the text in this font is an addition to the original Eclipse text who wrote this document.
Appendix A: The Bots
Bot Info for Level Architects
Deathmatch Bots and BotActorStart
Deathmatch Bots act just like another Deathmatch player and spawn on BotMatchStart entity locations.
At least one BotMatchStart entity must exist in a map for Bots to spawn.
In GTest, BotMatchStart will spawn between 1 and 4 Bots (you can set their number in the menu) in the map at any of the BotMatchStart locations.You can also use the BotActorStart entity to spawn a single Bot at a BotActorStart location. BotMatchStart and BotActorStart entities can be both present on a map (i.e. a map with 3 BotMatchStart (set to 4 Bots) and 3 BotActorStart (3 Bots) will spawn a total of 7 Bots).
Bot Level Navigation and PathPoints
GTest Bots navigate a level by the use of PathPoint entities. Multiple PathPoints are linked together to form Paths. PathPoints are entities that are strategically placed by the level designer to help the Bots navigate level geometry and make strategic decisions. They can define simple actions or string together simple actions to perform more complex actions.
A few things that PathPoints will help with:
* Navigation of elevators and moving platforms.
* Finding Hidden Health/Ammo
* Rocket Jumping
* Shooting specific locations
* Jumping up and down ledges
* Navigating winding hallways
Bots have a rudimentary AI that they follow when not getting information from Paths. This AI can do the following:
* Find clear paths to move towards and away from the target player.
* Find Health and Ammo that is visible and accessible.
* Shoot at a target player.
* Avoid running off of ledges.
* TBD - Steal Health resources.
Typically the Bots will always move at the maximum speed when in the general AI mode.
A Path is defined as one or more PathPoints. Some Paths only need one point but the majority will need at least two in order to tell the Bot the direction it should move. For example a Jump point will always require another point after it for direction.
Some paths are one-way paths and others are two-way. One-way paths go only in the direction they are linked together.
Two-way paths can be traversed backwards.
Path Type Descriptions - These are descriptive of what the overall path is trying to accomplish. They will not in themselves cause a Bot to take an action such as jumping. The Bot code will use these description types to make decisions based on the game situation. Only the first point of a Path should have a Path Type.
* Not fully implemented in GTest.
The Y placement of PathPoints can be critical. They generally need to be placed "close" to the "floor". The Bot code tests to see if a point is "visible" and tests to see if it is in his approximate Y range (+/-40 map units). If a PathPoint is too high over the floor the Bot may decide that this Path is not on his level and will ignore it.
A PathPoint is not required to have an Action Type. It can be left as NULL. Action Types are used to cause the Bot to take actions such as jumping, waiting, looking, shooting, etc.
* Not fully implemented in GTest.
Action Modifiers are ONLY used to modify the ActionType. If there is no action type there is no need for an Action
* Time - Time in seconds
* Dist - Distance in map units
* VelocityScale - Applied to the maximum speed of the Bot. Will cease to take effect when Bot is off the Path.
* MoveWithModel - Moves with model
* Direction - The action will only be performed when the direction the Bot is traveling on the path matches these settings. 1=Forward, -1=Reverse, 0=Both/Either. Other actions will be ignored.
* WatchPoint - Used to test for point distance, visibility, and shooting targets. Does not need to be a point on a Path.
* ShootTimes - Shoot at WatchPoint this number of times. Due to weapon firing delay this can take some time.
Bots can be blocked with a BlockActor entity attached to a model. The Bot will not be allowed to move completely into the model.
Finding Multiple Paths
In order for Bots to find a player by following multiple Paths, the Paths need to be laid out so that the program can connect them logically. Paths are connected according to a test: Each endpoint of a Path checks to see if it can see the endpoint of other Paths and that the Y range is within 80 units, and are not more than 1100 units away. (Note: this test can be tweaked easily.)
IMPORTANT - Recap of several key points.
Only the first point of a Path should have a Path Type!!!!!!!!!!!!!!!
Bots can start on any point of a TRAVERSE path - they do not have to be able to see or get to the endpoints. This makes them useful for long Paths with sparse points. I've used them for maneuvering long winding hallways with a single track.
When Bots travel backwards (in the opposite direction the points were linked in) on a Path and hit an action, the Direction Modifier must be set to -1 for any action to occur.
- Do ALL points that are linked together have to be visible to each other?
No. The main situation where points NEED to see each other is when using the WAIT_POINT_VISIBLE action type. It is also highly beneficial for end points of tracks to see each other. This will enable the program to link them up and form larger Multi-Tracks. See section Finding Multiple Paths.
- My Bots aren't riding up lifts very well.
Make sure that the appropriate PathPoint entities are set to move with Models. See MoveWithModel Modifier. Most lifts also need a WAIT_POINT_VISIBLE action type on one of the points to determine when the lift is near its destination.
- My Bots aren't doing the action they are supposed to when hitting a point.
If this track is a two-way track, make sure the Direction Modifier is set correctly to match the direction the Bot is traveling.
- My Bots aren't jumping far enough - OR - My bots are jumping too far.
The VelocityScale Modifier can be adjusted to allow further/shorter jumps.
Command line arguments:
Make paths visible - Path points and lines between them will be visible in the level. White points are normal points. Red points show a path type that is NOT at the first point. Connects points are represented with a white-green line. The direction of the path prepresented by the direction the line turns to green. White to red lines show where a path point is WATCHING another path point.
Commented out are some other debug modes:
N - Show visibility lines - Shows where end points of paths can see other paths. The main idea is that no track be isolated from other tracks.
O - Toggles view from the player to the Bot and vice-versa. Recommended for a single Bot only.
D - Prints debug info about the current mode the Bot is in. Recommended for a single Bot only.