mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-08-25 06:00:16 +01:00
ok-behavior-trees
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
df7832aa43 |
Replaced our NPC AI with Behavior Trees. (#96628)
This PR replaces our current NPC AI with a [behavior tree system](https://en.wikipedia.org/wiki/Behavior_tree_(artificial_intelligence,_robotics_and_control)). Behavior trees are a common way of creating AI in which you place nodes in a tree structure to define what actions an AI should take. AI controllers defined a list of /datum/ai_planning_subtree types in behavior_nodes. Each subtree was a self-contained unit that could call queue_behavior() to fire off /datum/ai_behavior actions. The controller iterated subtrees in order, each one deciding independently whether to queue something and deciding whether the next subtree would run. This has a few issues: 1. There's no real structure; you are just defining a list of things to try in order. 2. There was a loooot of subtrees that were basically the same as another but with some slight modification 3. It was hard to understand. Controllers now define a single json file describing a tree of nodes. The tree is composed of structural composites: Sequence - do A, then B, then C (and so on) Selector - try A, if it fails try B, then C (and so on) Parallel - run A and B simultaneously, with configurable failure/success policies and or looping behavior Subplan - loop a child continiously Along that we also have "Decorators". These are nodes that basically check a condition (E.g.; do we have a combat target). These decorators can be used to gate behavior and are re-useable across behavior trees. They also have a concept known as "Observers". Which lets them cancel lower priority behavior in case their condition changes (Which we check whenever a signal fires that fits that specific decorator). This makes the AI much more responsive to change in environment. For behaviors, we still use the ai_behavior datums. These are the actual behaviors such as "Move to X", "Attack X". The only major change is that these can no longer sleep() since they now run in the ai_controller. Lastly, we now also have subtrees, except now they are essentially pieces of behavior tree that can be re-used, or even overriden at runtime or as a variable. Allowing for making modular AI made out of several smaller trees. You can set variables on these nodes directly via the extension (see below), which should reduce the need to make subtypes of behaviors by a lot. All of these vars are saved on the JSON and will be applied at runtime. If you are using subtrees, you can also assign "bindings" to these variables, which will allow instances of the subtree to override those variables. Since a tree structure with variables becomes hard to parse in a JSON, I've made a VSCode extension to edit these JSONs: https://marketplace.visualstudio.com/items?itemName=BehaviorTreeG.behaviortreeg https://github.com/CabinetOnFire/BehaviorTreeG <img width="1795" height="1268" alt="image" src="https://github.com/user-attachments/assets/56aa2f0b-3cf9-449f-bca4-8281fca82db6" /> This extension allows you to edit the behavior tree JSONs, and browse through all the behaviors/decorators/subtrees we have If you'd like more info on how to build these AI check out the learn_ai.md. I will also make a tutorial to go over more depth on what the system offers because I kind of suck at doing technical write-ups. Targetting has been changed to. I've made a new acquire_targets behavior that takes a target_source (what am I targetting) and targetting_strategy (what does the candidate need to fulfill to be considered a target). This allows us to make composites targetting combinations to reduce the amount of specific find_and_set esque behaviors we had before. Not everything is ported to this system but that would be a longer term goal. I've added a new build_bt script that converts all the behavior tree JSONs into compiled versions. Why is this needed? Because I wanted to keep using defines in behavior trees, so we need a way to convert this into literal values before we send it to DM. This script runs on compile and should also run in CI (If I didn't fuck that up!). This saves to a new build/ folder. I've ported every single AI in the game to this system (except raptors, Kobsa is working on those so should be in soon!), so I do expect some bugs to come out of this. But I also fixed some issues that have probably been in the game for a long time such as: - Fixed penguins being unable to fish - Fixed bileworms not being able to devour people - Fixes goldgrubs not grubbing gold (they could not mine!) - Lizards actually eat food they find Either way, I'd reccomend a long TM on this. 1. (Hopefully) a better development experience for making AI 2. Less copy-paste for behaviors, we should be able to re-use more pieces to make behavior 3. Behavior trees is a more common pattern in making AI, so it should be easier to find resources to find out how to do things. 🆑 CabinetOnFire, Iamgoofball, SmartKar, Ben10omintrix refactor: Replaces our AI system with behavior trees, porting all datum/ai to it /🆑 I will add this PR with more details down the line. I think I got the big picture but its a big PR, so sorry if I missed something important. --------- Co-authored-by: Iamgoofball <iamgoofball@gmail.com> Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com> Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> |
||
|
GhomandGitHub
|
6eb2d1674a |
Implementing materials checks for techweb designs. (#96257)
## About The Pull Request In similar fashion to what was done with crafting recipes last year, this year it's time for techweb designs and printed items to be audited. This is mostly just about consistency, we've a lot of items that can be printed by protolathes, autolathes, circuit printers and techfab etc. However they almost all (except most stacks, mainly) have custom materials that do not match in one way or another with the materials used by the design, which is what this PR is for. "But items printed from lathes etc. already get the mats used to make them." Yes, they do, however that isn't the case for items of the same type that were spawned in some other way (cargo shuttle, space/maints loot, mapped, admins), this create a subtle discrepancy. It isn't a huge deal (in spite of the size of this PR, ton of designs), but given that I have done something similar with crafting recipes before, I may as well give it a second arc of some sort and bring things to completion. And fix a few possible oversights. TL;DR consistency and stuff ## Why It's Good For The Game Consistency, unit test checks to make it harder not to be consistent in the future. Still has a few TODOs like: - [x] Fixed newly printed, fully charged RCDs costing less than the RCD cartridges required to fully charge one. EDIT: I had to tweak the newly added RDD as well because it suffered from the same fundamental issue. - [x] Fixed plates being made of iron and yet shattering like ceramic ones. A new subtype for metallic ones has been made. ## Changelog 🆑 refactor: Refactored a few things with techweb designs (the ones for autolathes, protolathes, circuit printers, mechfabs etc.) to make sure that the materials of items that can be made from these designs more closely match the materials used to make them. fix: Lizard fries no longer need a plate to be made, like all other treats that used to require plates in a distant past. balance: Tweaked the materials cost of RCD, RDD and RCD cartridges. image: Oven trays now have a more metallic hue. balance: Plates printed printed from lathes won't shatter like ceramic ones, in virtue of them being made out of iron instead. /🆑 |
||
|
CabinetOnFireandGitHub
|
2ede6af8bc |
Fix basic mobs triggering click cooldown erroneously. (#95906)
## About The Pull Request Basic Mobs used to always trigger cooldown on clicks. This resulted in missed attacks causing you to have a delay before you could attack again, this makes it really punishing to play as a basic mob. To resolve this I did a mini-refactor on basic mob's attack chain to allow for the return values to determine whether we go on cooldown or not. Preventing attacks that did nothing (due to not passing checks, or simply not having any behavior) from causing cooldown. This fixes #95605 ## Why It's Good For The Game being able to perform melee with the same rules as /human is only fair ## Changelog 🆑 DresserOnFire fix: Fixes a bug where player-controlled basic mobs would get a cooldown when their attacks miss refactor: basic mob attack chain can now decided whether an attack resulted in a cooldown or not. /🆑 |
||
|
|
7763db34a1 |
Basic beepskies and some ED209 additions (#95783)
## About The Pull Request this PR refactors beepskies and ED209s into basic mobs. ive also added a few features for the ed209 because i cant keep my hands to myself: ED bots can now wear hats! a few hats give them some new unique dialogue. Putting a cowboy's hat on an ED will have it acting like a town Sherrif EDs are now rideable when emagged. theyll still be shooting people while ridden. youll also have the ability to charge at people full throttle running them over ive also added a new Nukie variant, purchasable from the uplink. These versions come fitted with an LMG and will patrol the station and shoot all walks of life. If emagged, theyll blow up people with (weaker) rockets (im still working on balancing this). they are rideable but i highly suggest against it; youll be caught in the crossfire. (i understand if ud prefer i atomize this feature) ## Why It's Good For The Game gives some personality to EDs, as well as updating all these bots to the cool new ai system ## Changelog 🆑 refactor: beepskies, and ed209s have been refactored. please report any bugs add: ed209s can now wear hats! some hats give them new dialogue add: emagged ed209s are now rideable! add: added evil versions of the ed209s to the syndie uplink /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |