I've been keeping an eye on this to use for the rules engine in a card game I'm writing[0]. Very excited to get back into using Prolog; I think it's fallen by the wayside a bit in the last decade or two but there's some sectors that still have strong arguments for using it if not as the main language then at least an extension language. [0] Inspired by a HN comment a while back about Gleemin, the MTG expert engine in…
An embeddable Prolog scripting language for Go
31–36 of 36 posts
Re: An embeddable Prolog scripting language for Go
#32Every language should come with a Prolog interpreter. :) Well done, ichiban team!
Re: An embeddable Prolog scripting language for Go
#33Every language should come with a Prolog interpreter. :) Well done, ichiban team!
I never used prolog. In my mind it is some old unused language. What is good about it and why should it be embedded into other languages?
Re: An embeddable Prolog scripting language for Go
#34 open(File, Mode, Stream, Options)
https://github.com/ichiban/prolog/blob/8e3dafd6d29334417a793...Re: An embeddable Prolog scripting language for Go
#35I see it claiming to have a sandbox but at the same time it seems to allow the program to read and write arbitrary files? open(File, Mode, Stream, Options) https://github.com/ichiban/prolog/blob/8e3dafd6d29334417a793...
`open(File, Mode, Stream, Options)` and other builtin predicates are available if you construct an interpreter with `p := prolog.New(nil, nil)`.
On the other hand, `p := new(prolog.Interpreter)` constructs a sandbox interpreter without any builtin predicates. You can explicitly register builtin predicates as you wish.
Re: An embeddable Prolog scripting language for Go
#36Earlier quoted context omitted.
Oh, hey, that's cool! Good luck with your card game, I hope we'll get to see a "Show HN" soon (no pressure!) :)
Thanks! Your post was really inspiring to me because I'd been grappling with the issue for a while; the rules are all hardcoded in Go right now and I'd been slowly trying to migrate the engine to either Guile or (more likely, since Guile in Go is through cgo) Lua. Reading your comment reminded me that A) that's similar to how Magic Arena handles cards and B) I studied Prolog back in uni and totally could do something…
Yeah, that's how Arena does it also. There was an earlier M:tG computer game, called Duels of the Planeswalkers where each card had to be scripted manually in Lua embedded in a proprietary markup. Ouch. That just made it very hard to add new sets to the game, whereas with Arena, the cardpool is updated around the same time as the physical set hits shelves, it's amazing. That's the power of a good abstraction!
I'm still half-interested in M:tG, as a subject for academic research although it puts me off a bit that it's proprietary. It would be great if there was a community-based, open-source alternative. So what I'd like to do at some point is design a generic card game engine, sort of like a virtual machine with registers representing parts of the game board (like M:tG zones) and player resources (like M:tG life) and so on and with an instruction set to manipulate those. Then different games could be implemented on top of that low-level machine in some higher-level language, compiling to the virtual machine's assembly. The high-level language could be purpose-built, or it could be an existing language, Prolog or Python or whatever, although a compiler would need to be written in each high-level language to compile down to game machine bytecode. The interesting idea would be to have the higher-level language also be the language on the cards (if that works for the game that is). So that'd be like implementing an M:tG rules engine in M:tG ability text, only ability text would be really unwieldy for that kind of thing, whereas a more convenient language could be created from scratch for this purpose. The final game could be a physical game, or a graphics engine could be bolted on top of the high-level engine to make a computer game.
All this comes from the observation that, in M:tG at least and I think in all other card games I've played (I've played a few :) there are some basic operations, particularly moving a card between parts of the board (zones, in M:tG) that can be abstracted away as virtual machine instructions that push bits into registers.
Anyway a generic card-game engine like that could free designers to implement their ideas quickly without having to write a completely new engine from scratch everytime, which is a big stumbling block for people who want to design new card games (I hung around the M:tG Forge forums for a while and there were lots of people planning to start their own M:tG engine, or their own card game, but many seemed to stumble on the implementation details). It would be like Unity or Unreal Engine but for card games. Then we might even see an open-source, community-maintained M:tG clone, as I hope to see at some point. Or a completely different game, of course not necessarily a clone.
Anyway, rambling! Best of luck with your project. I hope it goes well and I get to hear about it.