[m-users.] Mercury for Game AI

Julien Fischer jfischer at opturion.com
Wed Jan 26 15:31:47 AEDT 2022


Hi David,

On Sun, 23 Jan 2022, David Epstein wrote:

> This is the kind of functionality I'm trying to develop:

Attached is a modified version of mystery.m, that should be reasonably
close (in spirit) to the original version.  You can try it out with the
attached program, test_mystery.m.

> There are three types (person, door, room). Each person has three Boolean properties (is_alive, is_awake, is_free).

That seems a poor way of modelling people; can dead people be awake or
free?  (That may be getting a little metaphysical ...)

If I were doing this from scratch I would try something like the
following to represent people and their state in the database.

     :- type wakefulness
         --->    awake
         ;       not_awake.

    :- type freedom
         --->    free
         ;       not_free.

    :- type person_state
        --->     dead
        ;        alive(wakefulenss, freedom).

    :- type person_info
        --->   person_info(
                   room  :: room,         % Where is this person?
                   state :: person_state  % What conditition are then in?
               ).

(Of course if your game mechanics allow resurrection of dead people,
then the wakefulness or freedom of dead people may be relevant and
you might use a different representation.)

> Each door has two Boolean properties (is_open, is_destroyed).

Again, I would represent this differently.  Rather than having lists
(sets) of open and destroyed doors, I would do something like.

     :- type door_state
         --->       closed
         ;          open
         ;          destroyed.

The overall database would then be something like:

     :- type db
         --->    db(
                     people :: map(person, person_info),
                     doors  :: map(door, door_state)
         ).

I would also suggest packaging all of the state into a single value (as
with the type db/0 in the example above and in my version of mystery);
otherwise you will end up passing multiple pieces of state across the
Mercury-C# boundary -- that's a likely source of bugs.

Julien.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mystery.m
Type: application/vnd.wolfram.mathematica.package
Size: 8576 bytes
Desc: 
URL: <http://lists.mercurylang.org/archives/users/attachments/20220126/b1a73710/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_mystery.m
Type: application/vnd.wolfram.mathematica.package
Size: 2210 bytes
Desc: 
URL: <http://lists.mercurylang.org/archives/users/attachments/20220126/b1a73710/attachment-0001.bin>


More information about the users mailing list