Re: structured programming of automata with behavior trees
gettimothy via Squeak-dev <[email protected]> Fri, 17 Jul 2026 20:33:28 -0400
| Newsgroups | gmane.comp.lang.smalltalk.squeak.general |
|---|---|
| Message-ID | <[email protected]> |
You typed "Croquet" and that caught my eye. I will have to research this. At first glance "Behavior Tree" sounds like a "State" design pattern. all the best. t From: Yoshiki Ohshima via Squeak-dev <[email protected]> To: "The general-purpose Squeak developers list"<[email protected]> Cc: "Yoshiki Ohshima"<[email protected]> Date: Mon, 13 Jul 2026 12:37:26 -0400 Subject: [squeak-dev] Re: structured programming of automata with behavior trees Sounds cool. Is there a way to check it out with Squeak JS? I had a colleague (a long time game developer) who implemented the behavior tree on top of Croquet JS. It worked well for the purpose. I kind of liked a more general and meta solution, and later created a Functional Reactive Programming based system called Renkon. Croquet and Renkon use explicit logical time. Your Behavior Tree implementation probably shares the property of "at a logical time t, a node has at most one value", or "a node is evaluated at most once at an evaluation cycle". I am getting to like this property more and more nowadays. On Sun, Jul 12, 2026 at 8:38 AM Lauren Pullen < mailto:[email protected] > wrote: -- -- Yoshiki Squeak-dev mailing list -- mailto:[email protected] To unsubscribe send an email to mailto:[email protected] Greetings List, I thought I'd follow the spirit of the upcoming Squeak release to work on improving some of my programs. If you had previously looked at Cephei-BehaviorKernel and thought it looked like a neat, but impractical, toy, and weren't quite sure why, the answer was you couldn't create subroutines. And now, as of lrnp.12, you can! Wander over to BTSubtree's example1 for a nostalgic demo. For those of you just tuning in, a behavior tree uses an execution model completely unlike smalltalk's. Smalltalk uses the normal successor, PC=PC+1, while a behavior tree uses a boolean successor, like Prolog. Control flow is based on the shape of the tree and whether you used an AND, OR, or NOT node to combine nodes. Unlike smalltalk and prolog, behavior trees use 3-valued logic (success, failure, and incomplete). If you disregard the "incomplete" value, you can represent boolean successor in regular smalltalk code. It looks like this: ^self m1 and: [self m2 and: [self m3 or: [self m4]]]. Instead of writing statically-compiled methods, Cephei-BehaviorTree defines procedures dynamically using 1st-class objects and simulates a boolean successor machine. My behavior tree implementation is designed to augment my dynamic Mealy finite-state automata implementation (in StarVariable). Instead of implementing Harel statecharts or relying on backtracking to enforce interlocks you use behavior trees to guard against sending improper input to the FSM, and more. This is a pretty low-level tool, but it's object-oriented. Any instance can be a node if you define the methods from BTNode's instance side. The bare minimum is #tick:; the dynamic environment (a StarDictionary) is passed as the argument, and it must answer one of true, false, or nil. (A BTShallowBinder only extends the dynamic environment. It's a subnode's responsibility to put something useful in the slot. Low level gives you flexibility.) Squeak-dev mailing list -- mailto:[email protected] To unsubscribe send an email to mailto:[email protected] Squeak-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]