Un nuevo tipo de Pascal

[Ñuño Martínez]

Como digo, es para definir el comportamiento de los actores en un videojuego. Cada actor tiene un estado, el cual es quien define su comportamiento. Los mensajes se usan para que los actores se comuniquen entre sí.

La ventaja está en que el intérprete permitirá (si el motor así lo indica) que el diseñador del juego cree sus propios estados sin limitarse a los que el motor provee.

Empezado por Casimiro Notevi

Véndeselo a facebook, para que lo usen todos sus usuarios que tienen la costumbre de ir contando al mundo lo que están haciendo

Me lo pensaré.

[mamcx]

Si, entiendo lo de los estados. Lo que no entiendo es porque independiente de los mensajes (aparte que asi como se ven no muy diferentes a GOTO).

Si hay corutinas, cada vez que se hace YIELD se cede el control. Pero si ademas hay un canal de mensajes y por ende el YIELD se redirecciona con precision a quien espera el mensaje, entonces es como brincar a un nuevo estado (asi es como se hace en GO).

[Ñuño Martínez]

No tengo ni idea de GO, así que no sé muy bien cómo va; y la verdad es que me pierdo con eso del YIELD y las corrutinas...

Los mensajes no son GOTOs, ya que modifican el flujo del programa. Es más, es que en mi lenguaje no se definen flujos de ejecución, en el sentido estricto. Tanto las respuestas a mensajes como las descripciones de los estados se ejecutan en un tick o, quizá mejor dicho, en una iteración del bucle principal de juego. Es decir:

Código Delphi [-]
  PROCEDURE BucleJuego;
  BEGIN
    REPEAT
      ObtieneEntradasJugador; { Teclado, ratón, mando de juego... }
      ActualizaEstadosActores;
      DespachaMensajesPendientes;
      DibujaNuevoFotograma;
    UNTIL FinJuego;
  END;

ActualizaEstadosActores y DespachaMensajesPendientes son los puntos de entrada al intérprete del lenguaje. En el primero se ejecuta la rutina del estado actual del actor y en el segundo se despachan los mensajes de la cola de pendientes.

Hay que tener en cuenta, también, que puede establecerse un retardo al envío de un mensaje. Es decir, que pueden funcionar como una especie de "alarma". Por ejemplo, cuando el minero Bob llega a casa avisa a su esposa Helen; la respuesta podría ser:

ACTOR Helen IS Wife
 ...

  MESSAGE EnCasa
    IF SENDER = Esposo
      Msg "Hi hun.  I'll prepare your dinna'."
      SEND MESSAGE CenaLista TO SELF DELAY 100
    END IF
  END MESSAGE

  MESSAGE CenaLista
    IF SENDER = SELF
      Msg "Hun, her' are your dinna'."
      SEND MESSAGE CenaLista TO Esposo
    END IF
  END
 ...
END ACTOR

Como ves, las respuestas a estos mensajes no modifican el estado de la esposa, por lo que no modifican el "flujo" del programa.

No sé si esto aclara algo. Espero que sí.

[mamcx]

Basicamente, estas describiendo el modelo de canales y mensajes de GO.

Pegate una revisada de todo eso, que hay otras posibilidades muy interesantes para lo de juegos que se pueden modelar basado en ese modelo (que se llama https://en.wikipedia.org/wiki/Commun...tial_processes).

Tambien revisa que es una corutina, un closure y como se usa el comando YIELD en C# o en Python.

[Ñuño Martínez]

Ok. Le echaré un vistazo.