Re: structured programming of automata with behavior trees

Yoshiki Ohshima via Squeak-dev <[email protected]> Mon, 13 Jul 2026 15:04:44 -0700
Newsgroups gmane.comp.lang.smalltalk.squeak.general
Message-ID <CAHC3jCMLF+Ke31ESPxpA1eqwbN1_8=Y2UsgvihBY3jC2f1pj3Q@mail.gmail.com>
On Mon, Jul 13, 2026 at 2:20 PM Lauren Pullen <[email protected]> wrote:

> Hi Yoshiki,
>
> On 7/13/26 10:37, Yoshiki Ohshima via Squeak-dev wrote:
> > Sounds cool.
> >
> > Is there a way to check it out with Squeak JS?
>
> If Squeak JS can use monticello, it and *Variable are at
> <www.squeaksource.com/Cephei>.  I don't see why it shouldn't work.
>

Well, I asked because my simple-minded attempt did not work. It appears
that the NetNameResolver primitives are failing in Squeak JS (obviously, I
guess. Monticello needs to be adapted to Squeak JS). I just wanted to check
it out without downloading things to my local disk initially.


> > 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".
>
> Nice catch.  I'd not heard of functional reactive programming (or
> reactive programming, for that matter) until just now.  It seems my
> source materials predate the term.  Seems I have some studying to do.
>
> My implementation uses the latter property, where a part of the tree is
> evaluated at most once per tick.  I went with 3-valued logic so you
> wouldn't need to use a looping DECORATOR to break the illusion that
> you're working with 1 time unit per tick:.
>
> > I am getting to like this property more and more nowadays.
> Me too.  It's greatly simplified some of the things I wanted the game to
> do, and I've had luck using it as a replacement to the dependency protocol.
> Squeak-dev mailing list -- [email protected]
> To unsubscribe send an email to
> [email protected]



-- 
-- Yoshiki

Squeak-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]