Como ya te comenté en el canal, éste era un tema que yo también había pensado. Cuando hice pruebas de mi aventura "Los Inmortales" con gente que jamás había jugado una aventura, para probar el sistema AGE, una de las cosas que me surgieron fue que a la gente, en efecto, le resultaba muy poco natural el sistema de orientación por puntos cardinales.
Por ello, incluí en la aventura la posibilidad de que todos los caminos fueran navegables por el nombre del objetivo "ir hacia el vestíbulo", "ir por la puerta roja", "subir la escalera" o "salir", en vez de "ir al sur/este/norte".
Además de esto, estuve pensando también en el sistema de navegación por direcciones relativas. Aunque no lo incluí en "Los Inmortales", lo implementé de prueba en forma de un par de librerías para el AGE que se podrían incluir en las aventuras.
Por si a alguien le interesa, he escaneado el "documento" que muestra lo que fui pensando acerca de ello, y está en
http://absurdum.f2o.org/misc/doc002.png
Como este papelote está con una presentación bastante mala y en spanglish (siempre que escribo cosas para mí mismo lo hago en spanglish

) resumo un poco la idea.
La idea es básicamente lo que dices tú. Cada personaje del juego (concepto que incluye al jugador, claro) tiene en todo momento una propiedad "facing" que indica en qué dirección está mirando. Esta propiedad cambia cuando el personaje se mueve, por ejemplo si se mueve hacia el norte quedará mirando hacia el norte.
La propiedad "facing" se utiliza para hacer que las descripciones dependan de la dirección. Esto se puede hacer de dos maneras distintas, según si se importan dos librerías o sólo una.
La primera manera es utilizando las descripciones dinámicas normales en AGE, que son simplemente descripciones que dependen de una condición especificada en forma de código:
Código:
<Description>
<Condition>viewer.intProperty("facing") == Path.NORTH</Condition>
A tu izquierda tienes un cuadro, y a tu derecha un volován.
</Description>
<Description>
<Condition>viewer.intProperty("facing") == Path.SOUTH</Condition>
A tu derecha tienes un cuardo, y a tu izquierda un volován.
</Description>
Como se puede ver, esto es un tanto engorroso, porque hay que escribir N descripciones (o al menos N trozos de descripción, dado que las descripciones también se pueden poner por trozos condicionales).
La segunda manera, menos engorrosa, es poner descripciones parametrizadas de una manera especial que son parseadas por la librería (es decir, no usando sintaxis estándar de AGE sino un truquillo sacado de la manga):
Código:
<Description>
$RELDIR(west) tienes un cuadro, y $RELDIR(east) un volován.
</Description>
Como veis, esto es menos engorroso, pues sólo hay que poner unos determinados indicadores donde va a ir una dirección relativa y la librería los sustituirá. Por ejemplo, si estamos mirando hacia el norte, la librería sustituirá $RELDIR(west) por "a la izquierda" o "a tu izquierda". Además, si el jugador selecciona una opción rechazando usar el método de navegación relativa, siempre se puede hacer que $RELDIR(west) se sustituya simplemente por "al oeste".
Con esto, el programador de la aventura sólo tiene que escribir una descripción; aunque sea con esta sintaxis extraña.
La cosa funciona como se espera; pero no la estoy incluyendo en la aventura que estoy haciendo porque tiene limitaciones que no he resuelto. Son básicamente las siguientes:
- Esto está muy bien para la descripción de cada habitación y para los caminos entre habitaciones; pero ¿qué pasa con los objetos que hay en la habitación? Cada uno debería tener una "posición relativa" en la habitación, es decir, estar en la parte norte, en la parte sur, etc. Bien, no es problema, esto se puede implementar en AGE de una forma igual de simple que lo otro. Lo malo es que, si tenemos estas posiciones relativas, lo lógico sería que los objetos se pudiesen mover, y esto no es tan sencillo. ¿Con qué comando dejaría el jugador un objeto en la parte norte de la habitación? ¿Con cuál lo movería en la parte sur? Al final la única manera de hacerlo sería implementar un sistema tipo Dwight; pero esto me parece demasiado complejo para la mayoría de las aventuras, yo quería algo más sencillo y que diese el pego.
- También habría que meterle al jugador comandos de giro, es decir, que pudiese "mirar atrás", "volverse", etc. Esto no debería ser problema; aunque no lo he hecho.
Vamos, que el problema gordo es el primero... Si los jugadores estuviesen dispuestos a vivir sin influencia en la posición de los objetos en cada habitación, podría ponerme a usar este sistema a lo bestia, metiéndolo en mi siguiente aventura. Pero ese pequeño problema me lo impide. ¿Qué os parece, hay alguna solución mínimamente intuitiva para el jugador?
En todo caso, habrá que probar el sistema en algún momento, con nanos y similares, a ver qué tal va. Yo no lo he sacado, y lo he dejado sólo como librería, porque no he tenido tiempo de sacar aventuras.
Espero que la descripción de mi implementación te dé alguna idea para tu implementación en Inform (o en lo que sea) y la veamos pronto, y a ver si resuelve los pequeños puntos débiles de este tipo de modelo. Porque yo creo que es interesante, sobre todo teniendo en cuenta que es fácil ponerlo como opción y dejar que el jugador pueda elegir si se orienta de modo absoluto o relativo, al menos si se hace una implementación del tipo de reldesc.bsh (la segunda que he mencionado aquí).