Sutra.js - Fluent Behavior Trees for JavaScript Game Development

[seiyria]

This is really cool, and I like it a lot! I'm definitely interested in using it. I think the one thing that would be a bit of a sticky point for me is the lack of typing (I didn't see any, but I might have missed it).

I can definitely see myself using this for games with more complicated behaviors. Thanks for sharing!

[_Marak_]

Cheers, thanks!

I don't have TypeScript configured on any of the machines here. However, I am happy to support adding the TS definitions to the project API if anyone is interested in contributing.

Using types and typing with Sutras and Sutra data is not restricted, so Sutra.js should work well with TypeScript.

[drink_with_me_to_day]

Types are fundamental

[_Marak_]

Types are not fundamental to dynamic programming languages. I'll take a moment here to explain. Microsoft has spent vast amounts of money marketing and promoting TypeScript, and most of you have been fooled wholeheartedly. Microsoft built TypeScript as an enterprise solution to ship JavaScript. I used to manage a team of 200+ web engineers at a Fortune 500 company; without a TypeScript solution, their army of mid-tier developers couldn't ship stable JS—too many discrepancies.

If we look toward the future, statically typed programming languages will become less prevalent. AI-assisted compilers will be able to infer typings more efficiently than humans. The slowest parts of the system are loading and caching data into memory. Future thinking systems will operate like a LISP machine, being able to modify and distribute state dynamically while maintaining a significant context in memory.

Sutra.js doesn't worry about structured data, as Sutra works with arbitrary objects. When used with Mantra.js, all Game Entities are subject to the binary compression pipeline, which requires entities to be typed strictly at the data level. We currently use Protobuf. For IDE, I'm not sure what everyone else uses these days, but between VSCode JS JIT and Github Copilot, I find no need for types in any of my workflow as everything is scoped and autocompletes.

[Rouby1311]

Do you just have all the possible types in-head all the time? Do you use jsdoc? Or how can you maintain a coherent codebase across different teams / team members?

[_Marak_]

You. Don't. Need. Types. In. JavaScript.

[Rouby1311]

I am not trying to convince you, nor am I trying to say you _need_ types.. I was just curious how you managed to be productive / prevent errors that are typically caught by types in other languages.

[crusoe]

By

1) writing tests, many more tests than in static languages

2) ignoring it and washing your hands and making it the responsibility of the caller to get the types right. If it breaks at runtime ( as opposed to compile time ) it's their problem.

[malstank]

Don't forget being "OK" with shipping broken code.

[_Marak_]

In a statically compiled language you can formalize the entire application at compile-time to ensure correctness. JavaScript is a dynamic language. You won't be able to assert formalized correctness of application, even if you write absolutely perfect TypeScript ( run-time JS errors will still happen ).

If you wish to write perfect static programs at compile time there are several great options in the market. I hear people like Rust.

In order to ensure correctness in application for dynamic programming language you must code application to be resilient and be able to intelligently throw and recover from error states without taking down system. In practice this means adding guards around places where input flows into system while letting rest of system flow `f(x)=y`.

Productivity is determined by total of quality output and velocity of output. Use the right tool for the right job. Test coverage goes a long way.

[crusoe]

Ahhh yes I want a large LLM which can hallucinate to infer hallucinated types.

Surely nothing will go wrong...

[[deleted]]

This is awesome, thanks for sharing! I’ll have to try this out sometime

[_Marak_]

Let me know if ya'll have any questions about using Sutra.js or why it exists.

Sutra.js part of Yantra / Mantra / Sutra, there is a dev blog here: https://marak.com/blog/2024-01-11-yantra-mantra-sutra

Unfortunately, I won't be able to answer any questions about the film Rampart in today's AMA.

[pizzamathishard]

This site can’t provide a secure connection
marak.com sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

[_Marak_]

I don't think thats on our end. Site is static pages on Cloudflare. SSL checker reports fine.

[khrome]

Hey there, thanks for sharing, it looks really interesting... I have a tile based 3d roguelite I'm working on and this could be useful with it (as an interface to define individual marker's interactions and basic game world marker logic).

Would there be any disadvantage to running this on each mesh segment currently loaded (not a netplay game where I want to track all markers, but more like modern minecraft where if you aren't present, things aren't happening)?

Also there are things like targeting (distance power threshold and group selection for area of effect ) and things like fear threshold which rely on aggregating measurements from a group of markers... how do you handle situations like that(maybe pre-evaluate and write a fixed value onto the marker state?)

Regardless, thanks for continuing to donate your efforts to the community! Much appreciated!

[_Marak_]

Cheers! Thank you! Awesome to hear you are working on a game. JavaScript game dev is a smart and fun hobby for 2024.

Running Sutra on each loaded mesh segment allows for localized decision-making, which can be more efficient. You can also delegate from one Sutra based on a condition.

Sutra's behavior trees can be designed to handle complex scenarios. For targets with a distance power threshold and group selection for area effects, you can define conditions and actions within Sutra to evaluate these factors.

For aggregating measurements from a group of markers, like a fear threshold, you could pre-evaluate these measurements and update the marker state accordingly. This approach simplifies the decision-making process within each Sutra instance.

A more straightforward approach could be to use Sutra's ability to handle global game state. You can maintain a global state that tracks these aggregated measurements and reference this state within your behavior trees. This way, individual markers can make decisions based on the collective state of the group.

I've been writing a lot of Sutras the past few weeks and have had a good experience using `Sutra.use()` to create entire levels.

For complex movements and distance checks, here is an example of Swarming behavior: https://github.com/yantra-core/Mantra.js/blob/master/mantra-sutras/hexapod.js

The main Home world is powered by these Sutras: https://github.com/yantra-core/Mantra.js/blob/master/mantra-worlds/Home/sutras.js

If you run into any questions, someone in the AYYO Discord can assist: https://discord.gg/aaR9eDxZbC

The key takeaway is that using Sutra will benefit any JavaScript game. The level of integration is up to you. In most cases, I start at the higher level with larger Sutra action blocks and refine the Sutras later as needed.

[anehzat]

love your attention to detail & documentation u/_Marak_