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]