Logtalk for multi agent simulation? #179
-
Hi folks, I'm building a multi-agent simulation for a game I'm developing and I'm curious if y'all think LogTalk can work as the simulation language. The key requirements for the system are:
This will then be used to create an simulation of the physical world, and separate simulations of the mind of each of the characters. Minds can update based on observations of the physical world. I've prototyped the above in SWI-Prolog and achieved 3) and 4) via modules and meta predicates, but the code needed to define even a simple ontology will make for a poor authoring experience. I can clean this up by implementing a DSL via a Prolog DCG, but I see no good way of providing editor and debugging support for the DSL. This is where I'm hoping Logtalk might come in. 1), 2), and 3) seem to be exactly what Logtalk is made for, and Logtalk already has editor and debugger support. It seems like I could accomplish 4) by making a Logtalk object for each simulator and including the ontology and facts into that simulation. It seems like 5) is the main issue, especially when it comes to updating the ontology at runtime; once a category is defined by :- category/1 ... :end_category or create_category/4, there doesn't seem to be any way of incrementally updating the category. One could abolish it and create a new definition with the desired changes, but it's unclear if existing instances of that category would continue to work sensibly afterward. Thoughts? I'm especially interested in options for resolving 5) and whether I'm correct that 2) is straight forward. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
Intersting. Btw, one of the first commercial uses of Logtalk (+20 years ago) was a game based on historical events.
1, 2, and 3 should be straight-forward. You may want to look into using prototypes instead of classes and instances for simplicity, however. Also, using categories to simplify hierarchies. Related: https://logtalk.org/2020/02/24/a-category-at-the-top.html Regarding defeasible inference, by default, descendant properties override inherited properties. See the Handbook section on inheritance: https://logtalk.org/manuals/userman/inheritance.html
The "many worlds" design pattern is likely a good fit here. For a very simple example, see: https://logtalk.org/2019/11/13/many-worlds-design-pattern.html A more serious example can be found in the Metagol port (an ILP system): https://github.com/LogtalkDotOrg/logtalk3/tree/master/ports/metagol In this case, the common knowledge is represented in the Is your current prototype available publicly? |
Beta Was this translation helpful? Give feedback.
-
The historical context was one of the French invasions of Portugal and the uprise against the invaders in the village of Soure in the 1800s. Logtalk was used to represent the characters in the game and their behavior: soldiers, priests, ... The game GUI was written in VisualBasic with Logtalk running on LPA Prolog. Fun times. I still have some screenshots somewhere in one of my old computers. |
Beta Was this translation helpful? Give feedback.
Intersting. Btw, one of the first commercial uses of Logtalk (+20 years ago) was a game based on historical events.
1, 2, and 3 should be straight-forw…