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