hestia-rsps / hestia

An open-source Kotlin game server.
BSD 3-Clause "New" or "Revised" License
16 stars 4 forks source link

AI Behaviours #58

Open GregHib opened 4 years ago

GregHib commented 4 years ago

How might a task or behaviour for a bot look like in code?

The decision making would most likely be done by a tree structure, for this example let's say that the bot has been woodcutting and just reached level 41 so it's new behaviour is to buy a rune hatchet.

Find & traverse described in #57

queue {
    If has money is in bank
        Find nearest bank
        Traverse to nearest bank
        Open bank
        Withdraw money
    End
    If has money in inventory
        Find nearest hatchet shop
        Traverse to nearest hatchet shop
        Open shop
        Buy hatchet
    End
} 
GregHib commented 4 years ago

To make bots "content" rather than just fake player count they must interact with real players. List of ways they can gain/lose items from/to other players:

GregHib commented 4 years ago

How will Bots decide at a macro level? While at a micro level they should choose based on what their goal priorities are, is there a need to be an even spread across activities? Could the priority of which activities are popular be influenced? e.g dev planned or player driven event, pest control world

How would this take overcrowding into affect? Should bots deprioritise some activities if real players are doing it? E.g boss vs multiplayer mini games

GregHib commented 4 years ago

Decisions will be run effectively the same as the #67 task system. Abstract concepts: Woodcutting, or Banking logs. However they're suspended if attacked by random event. Once the event has finished then the bit resumes what they were doing before.

Another example: Doing slayer task, receives clue scroll, queue clue scroll to list of things to do, wait until slayer task complete.

GregHib commented 4 years ago

How can content be constructed in such a way that it doesn't need to be developed once for the player and then again for the bot?

GregHib commented 4 years ago

Each bit should have its own characteristics. Nature vs nurture. Some bots might be more risk adverse and so "safe" in combat more frequently, while others might not. Sims like, drives and motivations.

GregHib commented 4 years ago

https://www.gamedev.net/articles/programming/artificial-intelligence/the-total-beginners-guide-to-game-ai-r4942/ Utility-based systems Response Curves Blackboards Influence Maps

GregHib commented 4 years ago

Scenario:

Sense: Double slayer point event. Think: train slayer Act: get slayer task from slayer master.

Task is basalisk so requires mirror shield Check if has mirror shield - doesn't Buy mirror shield No money Check bank Not enough money Prioritise making money

New goal: make money Sell items Alch items Collect new items to sell Fight tagged easy money monsters

GregHib commented 4 years ago
data class Utility(val system: MutableAbsoluteUtilitySystem) : Component() //Highest level, aka as 'buckets'. These are situational based modules. E.g PvP, Agility areas. 

.evaluate() /.sample()

Modifiers/
data class Entry(name: String, function: (entityId: Int) -> Float, action: () -> Unit) 

data class InertiaEntry(name: String, function: (entityId: Int) -> Float, action: () -> Unit, val inertia: Float)

data class CooldownEntry(name: String, function: (entityId: Int) -> Float, action: () -> Unit, val cooldown: Int) 

Clamp/consideration

Mob - Combat strategy/utility bucket