Bot AI
Blitz3D Forums/Blitz3D Programming/Bot AI
| ||
| At some point I want to add BotAI to my project Tiny Tanks. Does anyone know of any straighforward lamen material I can read on the subject. There are so many methods it boggles the mind. Pathfinding, waypoint decision trees, task management methods.. I get a headache just considering it all. If anyone has done this successfully in a Blitz3D poject and doesnt mind sharing the experience.. Please do ! |
| ||
| AI is only as complex as you want it to be. The more factors you want to take into account, the more complex the code needs to be. It's not official or anything, but how I approach AI is based upon two main theories: 1) Weighted AI All conditions and situations are given a value. The chosen reaction for the bot is dependant on the sum of the Wighted value. For example: BOT_HAS_FULL_HEALTH = +10 BOT_CAN_SEE_PLAYER = +10 BOT_SEEN_BY_PLAYER = -10 PLAYER_HAS_FULL_HEALTH = 10 This simple example may result in "Proceed to attack" if the weighted value is positive, or "Run away" if the value is negative. 2) Planned Here, there are a set pattern of 'rules' that are continuously followed. Breaking from the rules only occurs in special circumstances (perhaps a result of a combination of Weighted AI as above) These rules may be something like: - Proceed to Waypoint. - Look for Player - Seek Next Waypoint ------------------------------------------ Pathfinding is the internal coding dealing with how the bot navigates your world. Assuming they would be subject to whatever "Laws of Physics" are included in your code (i.e. gravity, collisions, etc) Simmply moving a Bot another step towards its destination may not be adequate if the destination lies beyond an impassable barrier. The generally accepted method of Pathfinding is A* which works by dividing your play area up into 'nodes'. A node may be a room, a valley between mountains, or anything really, what is important, is how this 'node' can be accessed. Say the Node is a room. The room is linked to another room (and therefore another node) by a Door. A* work by informing the Bot that to get from Room 1 to Room 2, it must go via the conduit of the Door. So when the Bot tries to move, instead of simply heading for the direct route towards room 2 (which may be through the wall), it instead makes a path to the door. |
| ||
| Hi about A* a good tutorial with b3d code and nice links: http://www.policyalmanac.org/games/aStarTutorial.htm Juan |
| ||
| Nice tutorial, thank you. |
| ||
| I added some simple bot AI to the NETFPS code written by Jeremy Allesi. http://www.blitzbasic.com/codearcs/codearcs.php?code=1149 Scroll down till you find my entry. It is a very simple "state machine" but is quite effective. I kept the bot sections and messages seperate from the player functions and messages for simplicity in reading and so as not to modify too much the original functions - a better way would have been just to use the same functions and messages for the bots and the players with an AI flag to state whether they were player controlled or bots. You may need to strip out/modify some of the gnet stuff in there as I don't know if the gnet server is still running. |
| ||
| I kept the bot sections and messages seperate from the player functions and messages for simplicity in reading and so as not to modify too much the original functions - a better way would have been just to use the same functions and messages for the bots and the players with an AI flag to state whether they were player controlled or bots. Actually, I think the way you've done it is best. As well as your reasoning about easiness of reading and of course, easy to modify, Despite actions being similar for 'AI Bots' and 'players', there are important differences which would more likely overcomplicate the issue if flags had to be checked each function call. In a payoff between more bloated code (i.e twice the number of functions) compared to stack use on checking flags, I would favour the bloated code :) |
   |