3 ms·

I'm casually exploring using logic programming to define rules for games, as an embedded scripting language in a game engine, which would handle input and rende

by evnc 4y ago

I'm casually exploring using logic programming to define rules for games, as an embedded scripting language in a game engine, which would handle input and rendering etc. and be written in a more "conventional" language. We'll see if performance is an issue, but the space I'm most interested in is turn based strategy / board games, where it doesn't seem to be a big deal if things are as fast as possible. It feels like a pretty natural fit, e.g.: can_move_to(unit_id, tile) :- Unit(unit_id), Tile(tile), reachable_to(unit_id, tile, move_cost), unit_move_points_remaining(unit_id, mv), move_cost <= mv. You can define a lot of rules from basic unit movement to "what happens when you activate Super Special Rule-Bending Ability" this way, and it's pretty easy to change the definitions if you want to experiment with different game rules / logic. In practice, you want various syntactic sugar. Haven't got a chance to take this very far yet, just casual experimentation, but it seems like there's potential.

YeGoblynQueenne 4y ago
Oh yeah, encoding game rules is a killer app for Prolog's declarative style. See my sibling comment- I've done this with M:tG and WH40k. With M:tG in particular, translating from the rulebook to Prolog, to code a rules engine, is a breeze, just because the M:tG rules are in such strict, formal language already. The jump from a well-written, unambiguous and precise set of board game rules and its translation in Prolog is a tiny step, that could even be automated with some elbow grease. Now, you mention "rendering" and that, on the other hand, I'm not sure is a very good application for Prolog. Nothing to do with speed, but arithmetic in Prolog is a bit meh, and if you want to do stuff like matrix arithmetic, you have to roll your own. Most Prologs don't even have arrays, as such (they kind of do but it's a bit of a hack).
convolvatron 4y ago
top-down datalog can almost certainly be compiled to something quite reasonable. you also might enjoy looking at incremental datalog (differentiating rules and operating on events). this generally does a really good job of touching just what need to update the global state. this is a great application

by evnc 4y ago

YeGoblynQueenne 4y ago

Oh yeah, encoding game rules is a killer app for Prolog's declarative style. See my sibling comment- I've done this with M:tG and WH40k. With M:tG in particular, translating from the rulebook to Prolog, to code a rules engine, is a breeze, just because the M:tG rules are in such strict, formal language already. The jump from a well-written, unambiguous and precise set of board game rules and its translation in Prolog is a tiny step, that could even be automated with some elbow grease. Now, you mention "rendering" and that, on the other hand, I'm not sure is a very good application for Prolog. Nothing to do with speed, but arithmetic in Prolog is a bit meh, and if you want to do stuff like matrix arithmetic, you have to roll your own. Most Prologs don't even have arrays, as such (they kind of do but it's a bit of a hack).

convolvatron 4y ago

top-down datalog can almost certainly be compiled to something quite reasonable. you also might enjoy looking at incremental datalog (differentiating rules and operating on events). this generally does a really good job of touching just what need to update the global state. this is a great application