Does anyone have experiences (+ve or -ve) of any Java-based rules engines? In particular, I’m looking for Rete-based systems (of which Drools seems to be the only free one with much exposure).
Drools is XML based, which is horrible, and my previous fumblings with it suggest it’s pretty crummy - but I’d appreciate input from anyone who’s used it seriously.
We’ve got our own rules engine, and I’d like to swap out the basic inference class (which mainly does simple pattern matching) for a Rete system. We’ve experimented with doing our own Rete-clone (not precisely the same) in the past, but re-using a standard impl of the algorithm would be an interesting comparison.
The tool is pretty cool but it’s just free for personal use.
Perfomance is excellent because the tool produces Java code from your visual rule system: JARs actually which you can neatly plug-in to your Java application/game.
Full Rete implementation, and free. Not sure whether it’s the fastest, but it is nicely done.
[/quote]
Free?
[quote]Jess can be licensed for commercial use, and is available for academic use. Contact Craig Smith at casmith@sandia.gov for prices and commercial licensing terms, or for a research based academic license. A trial download is also available.
[/quote]
Indeed, JESS is far from free. You aren’t even allowed to develop software to support or work with it (we’ve asked them about a license that lets us support any customers who choose to use it, but had no response so far).
At the moment, JESS continues to be “an interesting academia project” (it’s free for bona fide academics) unless you don’t mind paying through the nose. As it stands, the latest info I’ve seen (2nd hand - they don’t publish prices) on licensing costs suggests JESS might not actually saev enough in the long run to be worth it to us (nb: we’ve already done a rete-ish inference engine, and have people who’ve written AST compilers etc before, so we’re not exactly starting from scratch).
[quote]mandarax looks promising, though i don’t think it is rete based. http://sourceforge.net/projects/mandarax
[/quote]
Thanks. FYI, it’s actually the opposite of rete :).
For what it’s worth I used JESS on a project about 3 years ago. We optimized our code to death and it was still too slow for needs. We were running an extraction engine on a news feed and the JESS component was at the end of the pipeline. Ultimately we decided on a homegrown XML rule language which was translated into compilable code giving us the flexibility of a rule language and the speed of a hardcoded solution.
The inventor of RETE has made a RETE2 algorithm which he claims is faster for large amounts of data.
Rete II: http://www.pst.com/rete2.htm
OPSJ: http://www.pst.com/opsjbro.htm ( the java based Rete II engine )
There’s a development license but no runtime license. Might be worth looking into.
[quote]For what it’s worth I used JESS on a project about 3 years ago. We optimized our code to death and it was still too slow for needs.
[/quote]
What would be really useful would be some basic stats on number of rules, rate-of-change, etc. This seems to be the main problem for using rete-engines: they’re tuned to the wrong traffic patterns (although we’re experimenting with moulding the input feed to suit Rete; the question is, does the “moulding” + a commercial Rete out-do our custom from-scratch Rete-esque-but-significantly-different inference engine?)
Also, in JESS’s defence, reading the version history two things become clear:
It’s been pretty sensitive to some of the areas where Sun’s been concentrating on massively increasing JVM performance recently; hence it could achieve great gains from late 1.4.x and 1.5.x JVm’s.
The early implementations appear to have been architected ahem less than wisely, w.r.t performance.
If you’re able to go into more detail, I’d be interested to chat further about this (I have some friends who’ve worked on high-performance news-feed processing, and it’s quite interesting).
Yes, spotted that a while back. It’s a bit too “if I told you anything about this, I’d have to kill you, so you’ll just have to trust me - it’s a million times faster than anything anyone else has ever done, and no-one else could even come close” for my liking. What I really need is detailed info on how it behaves on different traffic patterns, but it appears you need to have paid a significant number of thousands of dollars before you’ll get any non-trivial data (possibly because you can infer the algorithm once you’ve seen what it works well on?)
NB please humour me when I say “traffic” patterns; hopefully everyone knows what I mean…
A tried using JESS a few years back for a cognitive tutor project. (Uses JESS to generate context-specific hints for learners engaged in some problem solving activity.) Ultimately I went with a custom solution instead of JESS because there was no way that I could see to make the rules engine to “unapply” a rule that it had already applied. (The way the feedback/hints are generated is to have the rules engine find the best rule given the current problem state. But once you find the rule, you need to be able to unapply the rule so that your model reflects the learner’s current state.)
I’ve never done game AI using a rules engine, so I don’t know whether the same kind of issue can come up, but I mention it since I happen to have had some limited experience with JESS.
Full Rete implementation, and free. Not sure whether it’s the fastest, but it is nicely done.
[/quote]
Jess is very very far from free. Get ready to spit out 10s of thousands.
Let me give you a dump on using rules engine for games. We evaluated several engines including Mandarax, JESS, Drools, JRules. Drools and Mandarax are the only 2 open source ones that were really alive and showed some sign of what could be considered ‘great architecture’. Mandarax is a backwards chaining rules engine, and that may not matter to you if you don’t have a large number of rules (something that RETE is designed to handle well). Drools is a straightforward RETE implementation. Its semantic layer is excellent, allowing you to use Groovy, Java, etc. as the language for rule logic. JESS is ‘interesting’. The syntax of JESS is just nasty, especially if you don’t have a background in lisp like languages. I personally wouldn’t want to touch JESS with a 10 foot pole, but that’s not my decision. JRules is straightforward and has a lot more syntactic goodness than Drools. One thing that Drools does do , however, is compile the rules into bytecode using janino - which gives it excellent performance. In fact, its one of the faster engines we tested both open source and commercially. Drools is still somewhat young though, and its documentation needs some help. It has a fairly simply view of rules engines at the syntax level. However, Drools is certainly a very active project and the users list has maybe a 24-48 hour turn around on questions to the list.
Using a rule engine did bring about some very interesting questions which some people here may have already solved. Even with salience its sometimes difficult to get rules to fire in the order you wanted them to, and have the side effects make sense. In addition - rule engines are NOT the fastest things in the world. You can write custom code that will outperform any of the ones on the market right now… .but it will be a very custom solution.
I wouldn’t really spend a lot of time screwing with JSR-94. Its an ‘interesting’ JSR, but when the rubber hits the road you will find it extremely limiting.
[quote]Let me give you a dump on using rules engine for games.
[/quote]
Thanks. Of those, Mandarax is now the only one I haven’t looked at. I hadn’t noticed that Drools compiled to bytecode - their site, docs, and XML scripting were shockingly bad every time I looked, and I lost interest fast.
That wasn’t a problem :). Compared to Drools, it was much faster for us to get it running - but that probably says more about our backgrounds than the two libraries?
c.f. below, but much more deterministic control over ordering is one of the things that we’ve built-in to our next algo, because it’s so important in game-logic.
That’s what we already have - a custom proprietary system (as a prototype only at the moment) - and it’s fast and effective but I’d hoped to find a better one already in existence. FYI I made the first prototype as almost exactly a rete system having never heard of rete - it just seemed an obvious approach I thought up off the top of my head (over the course of a few weeks) for doing this kind of thing fast. I believe we’ve got a significantly faster algorithm too - althought not prototyped yet - which is more customized towards our particular use-cases (i.e. frequency of queries, number of rules, number of rule-changes per second, etc)…but it’s going to take many months to get that to production quality, and I wanted to try out various 3rd party inference engines first. I was quite disappointed how unadvanced/immature the state of open-source/free engines was, given how ancient the rete algorithm itself is.
For the stuff we’re using it for (coding ALL game logic) performance is critical yet the payoffs for using an inference engine of some kind are immense, in terms of reduced costs of code maintenance and feature-addition and even making frequent and complex changes to the game logic. The main use is to make it much cheaper to “balance” the logic / game-rules for complex games to make a good game rather than a one-sided game.
I unfortunately can’t talk much about our particular uses of it, but when we went shopping for an engine - we pretty much knew that we weren’t going to use a custom engine for a variety of reason, much of which goes in line with supporting it versus people in that space who actually care.
I’m surprised you didn’t like Drools. It took less than an hour to understand exactly what Drools was trying to do. There is so little XML in the system and even it is a bagillion times more intuitive than anything in Clips derivative Jess (there was a long debate, which is somewhat still going on, about the Jess/Drools decision). Drools is just an excellent architecture with its pluggable semantics. You could write your own AI language, plug it into Drools and Drools would function just fine. We liked our rules in Java, however, since we have lots of people who understand Java/C/Pascal/etc and that language syntax. It takes no time for someone completely unfamiliar with our system to be able to read our .drl files and understand what its doing and write new rules. That by itself was a major selling point. But then again our end product will have more ‘regular programmers’ writing declarative rules for our product. Your mileage may vary based on your use cases.
To be honest I’m actually amazed to hear anyone find Drools syntax to be difficult.
If you have a special case use for a rules engine, it is extremely easy to optimize for those cases - but they will have side effects that are bad for a more general purpose engine. Drools is a more general purpose engine, though I’ve been impressed with its performance. Drool’s java semantics and its groovy semantic use janino.net’s open source compiler to turn their AI rules into byte code so it will run pretty fast. When I talk about speed I’m talking about relative to a specialized engine for particular tasks. Most people will likely find Drools to be of acceptable performance - though its not the type of thing you’d call every frame
My architecture has the notion of a Planner which also holds WorkingMemory. While the game is taking place the planner’s working memory is updated periodically for high level decisions and this causes the rules to fire and decisions to be made. The actions from these decisions is usually not defined in the rules - they usually just set a state that determines what an entities goals are. While I liked the idea of Drools giving me the functionality to put actual java code in the consequences and acutally giving me the ability to drive the game right from the rules - that isn’t an ideal seperation.
Our use cases are the same though we didn’t find it reasonable to put all game logic in the rules engine. Some things just work well that far seperated from the engine core. While we’re weaving our rule engine in using Aspects (something its unfortunate that Sun doesn’t seem to understand or use), moving stuff in and out of working memory, updating objects in the working store, and some light synchronizing of data makes doing everything in the rules engine somewhat impractical. Now maybe your use cases will point to something different, but for us after we tried and tried to make that the use case - performance dictated that putting everything in the rules impractical.
You’ve convinced me to have another look. Maybe personally I was too affected by “oh no, here goes ANT all over again”, although my memory is that documentation was the real killer - we just don’t use stuff which has poor or non-existent documentation.
Yes, our prototypes needed a mix and match approach too, and this is partly why I wanted to investigate dedicated engines side-by-side.
If it were ONLY a case of developing a pure (but proprietary) engine then I wouldnt’ be worried, but the prospect of something that is both proprietary and a non-clean arbitrarily mix-and-match (so that game code may get moved back and forth between the rules engine and outside it) is deeply disturbing (nightmares of code maintenance problems come to mind - which is one of the primary things this was supposed to be solving in the first place :().
blah, thought not java-based (in ‘c’), you may find some optimization hints in soar’s rete implementation. (http://sourceforge.net/projects/soar/) the ICCM’04 soar tutorial given by john laird was very impressive. soar is an agent cognitive architecture that is production rule based with working memory and lots of other features.
There is one big problem with it: - it’s performance is completely unpredictable. If you run the engine, it can sometimes take 10 seconds, and sometimes 10 minutes to finish - for exactly some data.
I created something like “bug report” or “change request” on their page and some developer replied, that they know about this problem, and that they “currently work on performance”.
We tried to fix this problem ourselves and we succeded (basically all it takes is to replace every HashSet in drools sources with LinkedHashSet)
So now the engine’s performance is at least deterministic.
To me it appears that it is quite slow (but maybe it’s ok, our data set is really big, and I never tried any other Rete engine, so I cannot compare)
Except the problem with performace it works quite fine.
