F.A.P.

[DarkstaR]

FAP, or Fully Autonomous Pantologist, is an entirely self-governed bot that will verse itself in complete knowledge about the world of Tibia by automatically immersing itself into and collecting data about the game. In layman's terms, it is a completely independent artificially intelligent bot.

Our (and when I say our, I mean me and Akalic, the developers) goal for the FAP project is to ultimately create a bot which run on its own dedicated machine and self-dictates every single action it carries out. Not only do we want to create a bot that can level from 0-50+ efficiently, but we want it to be able to figure out how to do this completely on its own. FAP will be equipped with the tools to discover data about items, creatures, and so forth, but it will not, however, be given any data thereof - everything it knows, it will learn from its environment.

FAP will be open-sourced and written in mostly C#, with a few C++ libraries and wrappers to help make it run soundly inside Tibia. The program itself will contain many advanced functions which will allow it to contemplate complex decisions about gameplay faster and more effectively than a human could. Also, FAP will be able to learn from mistakes and previous characters, just as a human would, to ultimately make it as good as - or better than - a human.

Below this paragraph I will be creating a hierarchy of utilities -- which will be included in FAP -- their abilities, and their limitations. This list will constantly change and programming will not begin until we have a full layout of the program.


I. Information Mapping

• Game-map data
  The map will be recorded in a customized database containing various pieces of data about each tile. The map will be dynamically updated as Tibia changes.
  
  • isProtectionZone
  • isHouseTile
  • isPremiumTile
  • isBlocking
  • isBlockingProjectile
  • walkSpeed
  • averageCreaturePopulation
  • averagePlayerPopulation
  • isWalkingDissallowed
    This will be different from "isBlocking" in the sense that the tile really contains no items that would block the player. An example of this is a quest chest tile. Though, normally, a tile with just a chest can be walked on, quest chests tiles will not allow you to walk over them.
  • teleportTileStatus
    This will store data about a "teleportTile." A teleportTile is defined as a tile which offsets the characters location in more than one dimension when used properly. For this reason, teleportTiles will include the following objects:
    
    • Stairs
    • Ladders
    • Rope Holes
    • Riding Turtles
    • Actual Teleports
    • Kaz Railway cars
    • ETC
    
    A teleportTile will also store data about how it must actually be operated to carry out its teleportation. For example:
    
    
    • Do we step on this tile?
    • Do we use it?
    • Do we use a rope or a spell on it?
    • Do we throw a scarab coin somewhere while we wait on it?
    • Do we have to pay to use this?
    • ETC
    
    
  • doorTileStatus
    If the tile has a door on it, data will be stored containing information about whether this tile is a door, a gate, or some form of object that temporarily will obstruct our path until action is taken against it. Data about various things will be stored for door tiles, such as:
    
    • Do we need a key?
    • Is this a level door? If so, what level?
    • Is this cuttable grass, do we need a machete?
    • Do we need door rights or a certain quest status for this door?
    • Does a lever need to be pulled for this door?
    • ETC
    
    
  
  
• Creature location data
  Information about creatures on the game-map will be contained inside a custom database which contains the following data for each creature present.
  
  • UID
    Each different TYPE of creature will be assigned a UID (so, all Cyclops share a UID but Cyclops don't share a UID with Wolves). This UID, or unique identification number, will represent a creature type in the data set of creature data, which I will define later on.
  • mapLocation
  
  
• Item location data
  Information about items that remain statically on the game-map will be stored in a database which will contain data for each item in side database. The data format is as follows.
  
  • ItemID
  • mapLocation
  
  
• Locational definitions (TOWNS)
  Special information about certain areas on the map will be stored in order to
  
  • templeLocation
  • depotLocation
  • townName
    The towns name will be determined based upon information gathered from guides and other NPCs.
  • townArea
    This will store the area of the town in an array of two-dimensional vectors which, when put together, represent a polygon outlining the town itself.
  • innerNpcUIDs
    This will be an array which stores multiple UIDs representing every NPC residing within the towns boundaries.
• Locational definitions (OTHER)
• Creature data
  NOT YET DEFINED
• Item data
  NOT YET DEFINED

II. Decision Making

• Path-finding
  The path-finder will take into account a wide variety factors when calculating a route to its destination. It will be a highly mutated version of the standard A* algorithm.
  
  • PZ Lock
    
    • If the character is PZ locked, the path-finder will not include protection zones in its walkable path
    • If the character has a skull, the path-finder will avoid running through main streets and busy areas
    
    
  • House Tiles
    The pathfinder will take house tiles and invitation status into account.
  • Creatures
    
    • Is there creatures along the way that may kill us?
    • Do we need a certain item that we can buy from an NPC along the way, or loot from a creature?
    • Is there a strong possibility of there being a lured monster or a PKer?
    
    
  • Items
    
    • Are we stuck in a hole? Is there usually ropes on the ground near-by?
    • Is there a daily-item spawn we may want to check out along the way?
    • Is there a new quest that we are now capable of doing that we saw before?
  
  
  In addition to the before-mentioned factors, the path-finder will learn from its mistakes and previous trips, creating faster and safer routes of travel.
  
  • Example #1 - The path-finder decides which route is faster
    
    • Traveling to destination A with heuristic B takes 323 seconds on average
    • Traveling to destination A with heuristic C takes 305 second on average
    
    Since we are in a hurry and the path-finder has learned in the past that heuristic C is faster for this area on the map, it will use heuristic C to calculate its path.
  • Example #2 - The path-finder decides which route is safer
    
    • Traveling on route A brings encounters with wolves and snakes
    • Traveling on route B is faster but brings encounters with dragons and juggernauts.
    
    Since we are a level 8, the path-finder decides to avoid the juggernauts because we may not have enough potions to kill them.
  • Example #3 - The path-finder takes into account cost and wealth status
    
    • Taking boat from A to B and then carpet from B to C takes 40 seconds but costs 200 gold
    • Taking boat from from A to D and then boat again from D to C takes 10 seconds but costs 250 gold
    
    Since arriving early to our spot ensures more profit, the path-finder decides to go by boat.
  
  
• MORE TO COME

[lifriet]

Good luck in your job!
Looks like it'll be good.. waiting more info!

[muttley]

Good luck! If it's C# maybe I'll do something for it

[maozao]

Nice project.

I hope to see it soon =)

Good luck!

[Renusek]

Looks really good. And great that it will be C# - another good source from which I can learn . Good luck!

PS. I like fap :shy:

[Devil]

OMG
It will be veery hard to do, but I believe in you XD
Good lucky in your project!

[Akalic]

Yet another thread I must ruin with my presence.

[komar_rk]

So man gl.

[DarkstaR]

Thanks guys.

I've currently drawn out a diagram for the neural networks and how they will interact with the agent itself. The networks will be forward-feeding networks. Multiple neural networks will be used to solve different problems and handle the different states of the environment (since we are working in a semi-static environment). The agent itself will tie together our perception, actuation, and brain classes to our environment and stored data. Forward from there, the FAP program itself will manipulate the agent - this is where the actual logic comes into play.

One thing I have been debating is whether or not to run every separate neuron layer asynchronously to one another to actually replicate the way the neurons in the human brain fire. I do believe this will help the bot solve multiple problems at once a lot faster (for instance, where to run to when getting PK'd as well as how to fight and free itself from traps)

Also, I'm not sure if we should actually make this a client modification or a stand-alone player.

Anyways, once I download excel, I will be posting diagrams of how the current system is planned out.

[Kayan Lua]

I've got a Bot coded with C++ and LUA. It's clientless, works with 8.62.
I was implementing simple functions like pathfinding, things like talk to 'Santiago', etc.
It has a nice structure, but does nothing. You might be interested.