-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
I'm not familiar with the implementation in odoyle (the terminology used is out of scope for me), but it looks like the [e a v] facts are being stored in nested {e {a #Fact[e a v]}} maps. Since the facts are records, it's plausible that you could get effectively the same performance with via the associative indices that I'm used to, although since they aren't stored in sorted indices, range queries aren't built in like in most datalog tuple stores (no big deal if you don't need them though).
Thank you! Not to get into clojure tropes, but aren't events just data? Why do we need to have a special concept of an event, when we can just insert a fact that represents the event and write rules that react to it?
In a way my dungeon crawler game is kind of what you describe -- the delta time is inserted every frame, which forces most of the rules to fire, including movement/collisions of characters. But at some point my nim rules engine would be more appropriate. I actually wrote a nim version of the same game and i'm sure you could have a party adding more ogres and elementals, especially if you compile in release mode.
The algorithm is the same but yes it's mutable. Maybe the most interesting difference that affects performance is that in nim i can generate a special stack-allocated type to store your matches internally. It is a sum type, which nim calls an object variant, that has a "branch" for each rule. Unsurprisingly this was a huge perf improvement over using hash tables. Generating types with a macro is some wild stuff :D
As far as code, my implementation focuses on the functional approach. There's a stress test in the testing ns, of which the behavior-related stuff looks like this (I re-ordered it for presentation purposes, I typically define this stuff in a clojure friendly way, building "up" more complex behaviors as you go down the through the source, this is "top down" for visual purposes):