Similarly, you could enumerate these composite facts with IDs, but I also anticipate performance issues there. %%Instead you must use linear is $Rel $Parent)
%%Does not work because mutable facts are is $Rel $Parent) This can be worked around by interpreting some datastructure composed of lists, but will miss out on optimization by the compiler. You may notice that this macro only works if $Obj has only one relation. Actor driven vehicles, for example.įor the limited arity of facts, you have the macro facility which allows you to bundle facts like so: is $Rel $Parent) While you can get away with floating for stateless objects in a single-actor world, all the player needs to do is drop an object by a tree and wander over to another to discover the ruse. Moving on, I'd like for these zone-rooms to be procedurally populated. This can be as simple as an actor by a tree looking to wave at another that happens to also be by the same kind of tree. This seems unrelated, but imposes a crucial constraint - if an actor is performing an action that involves both a local object instance and a distant one, we can no longer use "floating" singleton objects to fake instances. By itself, this may not seem like much of an issue (you can represent this as a tree), but when one considers how zones typically contain multiple instances of the same object, we arrive back at our problem. Instead of representing only the world as a graph of rooms with binary occupancy, I also intend to emulate old-school "zones" by using a system of waypoints and relations within a single room. These are in service to the following gameplay outcomes: pathable portals with dynamic destinations that may be moved by actors and have multiple instances in the same room.containers) that must present multiple instances simultaneously (e.g. runtime instantiation of an unbounded number of stateful objects.The reason why state is so important for me is that I'm interested in making a text-oriented game with procedural generation and RPG mechanics which requires the ability to dynamically generate objects, manage large quantities of their instances, and support AI pathing about a large world with a constantly changing connection graph. Is there something I'm missing to get around these limitations in Dialog? Is there a better way to handle state in Prolog-family languages?
To my knowledge, neither option is appropriate for large, complex game worlds as an unskilled solo dev.Īt this point I am stuck. To work around these issues introduces serious ugliness and brings into question the performance of larger game worlds.ĭialog isn't the only logic programming language, however, so I've looked into how text games can be made in Prolog and Logtalk and discovered the problem of managing state is even bigger there: one either passes around the world state as a parameter, or uses the dangerous assert/retract family to mutate the database. Dialog has some facilities for handling state, but ultimately it is limited to mutable unary & binary facts and a compile-time fixed number of objects. The problem is that game state becomes difficult to work with.
Logic world game for free#
Now you can download and play this game for free on this site.After learning Dialog, I've discovered representing game logic using the logic programming paradigm is a lot of fun the composability and non-locality makes it feel like some kind of superior ECS. Despite all that, it is very entertaining to experiment and do things like screens, memories, adders, and whatever you can think of and we hope the developer continues to work on improving it since it is in early access. It still has its bugs and problems, you have to restart if components are moved in a certain way, the delayers do not work as expected (you have to keep the pulse for x cycles to activate) and we have not been able to make flip flops work. If you already know electronics basics or have played with Minecraft’s Redstone (the developer said there will be tutorials in the future). The logic world is an amazing experience so far. This is a Minecraft for red stone lovers without unnecessary functions and with normal wires.
0 kommentar(er)
