CAAD

Comunidad de Aventuras Conversacionales y Relatos Interactivos
Fecha actual 14 Dic 2018 23:20

Todos los horarios son UTC + 1 hora




Nuevo tema Responder al tema  [ 38 mensajes ]  Ir a página Anterior  1, 2, 3  Siguiente
Autor Mensaje
NotaPublicado: 17 Feb 2010 20:09 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5304
Ubicación: Coruña
La intuición me dice que se mostraría al revés, porque el mensaje sobre el daño de las brasas habrá que imprimirlo en el método, y para entonces aún no se habrá devuelto el valor, ¿no? Y eso es lo que me hace tener dudas sobre el diseño de este aspecto particular, precisamente... :D

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)


Arriba
 Perfil  
 
NotaPublicado: 17 Feb 2010 20:45 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5304
Ubicación: Coruña
jenesis escribió:
Al-Khwarizmi escribió:
Pero me lo contarás ¿verdad? :mrgreen:


Pues creo que por el momento mejor que no. Porque hasta que no he leído este hilo desde el principio, no he recordado que esto estaba pendiente de una decisión de diseño.

Ahora mismo se pueden cambiar algunos mensajes predefinidos; pero creo que no tiene mucho sentido que te diga cómo si tal vez en dos o tres días lo cambie y eso ya no valga.

Tengo que pensar cuál es la mejor manera de implementar la posibilidad de cambiar esos mensajes sin necesidad de redefinir. Se me ocurren varias maneras, pero tengo que pensar cuál es la mejor (que equilibre genericidad y facilidad de uso).

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)


Arriba
 Perfil  
 
NotaPublicado: 17 Feb 2010 21:02 
Desconectado
xyzzy

Registrado: 09 Mar 2004 22:50
Mensajes: 9150
Al-Khwarizmi escribió:
Tengo que pensar cuál es la mejor manera de implementar la posibilidad de cambiar esos mensajes sin necesidad de redefinir. Se me ocurren varias maneras, pero tengo que pensar cuál es la mejor (que equilibre genericidad y facilidad de uso).


Tómate todo el tiempo que necesites, son cosas que se pueden dejar para el final finalísimo.
Mientras yo iré poniendo mis propias respuestas añadidas, así cuando tengas la solución lo que haré será dejar al parser mudo en todas ellas. :)


Arriba
 Perfil  
 
NotaPublicado: 17 Feb 2010 21:20 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5304
Ubicación: Coruña
A ver, es que éste es un tema de diseño interesante. Cuando cogemos una espada, tanto en AGE como en Inform, y en cualquier otro sistema, se produce la siguiente secuencia de acciones:

A. El jugador teclea "coger la espada".
1.
B. El parser procesa la frase y se da cuenta de que el jugador quiere coger una espada que hay por ahí.
2.
C. Se mueve la espada del inventario de la habitación al inventario del jugador.
3.
D. El sistema imprime: "Coges la espada", o "Cogida", o el mensaje por defecto que sea.
4.

Los puntos que he marcado como 1, 2, 3 y 4 es donde un sistema de creación de aventuras puede dar opción al jugador de inyectar código (o sea, de programar algo que se ejecute ahí).

El punto 1, en inform lo cubren supongo que las gramáticas (corregidme si me equivoco), y en AGE lo cubren los métodos parseCommand.

El punto 2, tanto en inform como en AGE lo cubren los "before".

Para los otros puntos, en principio se podrían tener dos mecanismos que permitieran inyectar código. Pero parece demasiado complicado para el usuario: es relativamente intuitivo tener un "antes" y un "después", o un "sobreescribir la acción" y un "reaccionar al acción"; pero ya tener tres cosas... suena lioso (esto es todo mi opinión, por supuesto).

Por lo tanto, tanto Inform como AGE sólo implementan uno de estos puntos de inyección. En concreto, inform implementa el punto 3 con su "after" (lo acabo de mirar en el manual). Y AGE implementa el punto 4.

Ambas cosas tienen sus inconvenientes:

- La solución de inform tiene el inconveniente de que, al no poder inyectar en el punto 4, no podemos hacer que suceda algo como reacción a la acción después de que se imprima el mensaje por defecto. Por ejemplo, coges una espada y como resultado te pinchas:

> coger espada
Cogida.
¡Ay! Te has pinchado. La próxima vez especifica que quieres cogerla por el mango.

Eso si no interpreto mal el DM4 famoso no se puede hacer en inform más que imprimiendo el mensaje "Cogida." a mano, ya que el after inyecta código antes de que se imprima ese mensaje y no después.

- La solución de AGE por otra parte tiene como inconveniente que, al no poder inyectar en el punto 3, no puedes cambiar el mensaje por defecto de una acción sin cambiar el punto B (la acción en sí). Por ejemplo:

> coger espada
Coges la espada con mucho cuidado de no pincharte.

Igual que en Inform se podía implementar lo anterior pero de manera que requería reimplementar algo (la impresión del mensaje), en AGE se puede implementar esto pero de manera que requiere reimplementar algo (en este caso la acción).

El problema es el mismo en los dos casos: en Inform, al no poder inyectar en 4, para hacer algo después de la acción tenemos que inyectar en 3 e ir por narices antes de D aunque no queramos. En AGE, al no poder inyectar en 3, para cambiar el mensaje de la acción tenemos que inyectar en 2 e ir por narices antes de C aunque no queramos.

¿Se os ocurren soluciones buenas que no sean muy complejas para el usuario? A mí se me ocurre alguna; pero no sé si me convence al 100% así que prefiero leer ideas antes que no estén influidas por la mía.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)


Arriba
 Perfil  
 
NotaPublicado: 17 Feb 2010 21:47 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 15 Dic 2004 21:28
Mensajes: 2302
Al-Khwarizmi escribió:
El punto 1, en inform lo cubren supongo que las gramáticas (corregidme si me equivoco), y en AGE lo cubren los métodos parseCommand.


No, en informATE la gramática es el parseado, eso si no recuerdo mal (y podría, porque tengo InformATE muy oxidado) se implementa con el método "reaccionar_antes" (o "react_before" en INFSP, supongo), que se ejecuta para cualquier objeto en el alcance, ya que al no haberse parseado, aun no se sabe a qué objeto se va a referir.

Al-Khwarizmi escribió:
¿Se os ocurren soluciones buenas que no sean muy complejas para el usuario? A mí se me ocurre alguna; pero no sé si me convence al 100% así que prefiero leer ideas antes que no estén influidas por la mía.


Yo es que de verdad no creo que sea demasiado complejo tener 4 ganchos, no sé a que clase de usuarios quieres que vaya dirigido AGE. :P

En cualquier caso, de quitar alguno veo mucho más importantes los puntos 3 y 4 que el 1, en mi opinión el 1 sólo debería proporcionarse para ejecutar algo global antes de iniciar cualquier acción y no para parsear la acción, sigo pensando que para parsear ya está el propio parser del sistema y no el código de la aventura, y si el autor en algún momento necesita parsear por sí mismo entonces es síntoma de que algo falla en el parser del sistema.

Quizá la clave esté en no llamarlos "antes" o "después" sino de otra manera, ya que en realidad eso solo sirve para 2 ganchos, y puede resultar confuso para un modelo de 4 ganchos (o incluso de 3): ¿antes o después de qué?.


Arriba
 Perfil  
 
NotaPublicado: 17 Feb 2010 22:04 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 15 Dic 2004 21:28
Mensajes: 2302
Documentate escribió:
http://www.caad.es/informate/docs/html/ ... iones.html

Durante el estado 'Antes' la librería llama a tu código varias veces y puede resultar útil conocer en qué orden lo hace:

1. Si has escrito una rutina llamada RutinaPreJuego, ésta será llamada. Si retorna true, no ocurrirá nada más. La acción ha sido impedida.
2. Se llama de igual forma a la rutina ordenes del objeto jugador. Para más detalles ver la sección sobre criaturas.
3. Se llama a la rutina reaccionar_antes de todos los objetos que estén en las cercanías (más técnicamente, los objetos que están en el 'alcance').
4. Se llama a la rutina antes de la habitación en que tiene lugar la acción.
5. Si la acción se está aplicando sobre un objeto (guardado en la variable uno), se llamará a la rutina antes de ese objeto.

(!) Para realizar la fase 'Durante', la librería llama a la rutina encargada de la acción. Por ejemplo, la acción Coger está programada en la rutina CogerSub (que, por cierto, ocupa una buena parte de la librería ya que tiene que manejar muchos detalles).

(!) La fase 'Después' sólo se aplica a las acciones del Grupo 2, ya que todas las del Grupo 3 ya han sido tratadas en la fase 'Durante' (si no 'antes'). En la fase 'Después' la secuencia es como sigue:

1. Se llama a la rutina reaccionar_despues de todos los objetos cercanos (incluyendo al propio jugador).
2. Se llama a la rutina despues del lugar donde se ha efectuado la acción.
3. Si la acción utilizó un objeto en la variable uno, se llama a la rutina despues de ese objeto.
4. Finalmente, si has programado una rutina llamada RutinaPostJuego, se ejecutará ahora.


La secuencia en InformATE es más complicada de lo que recordaba (y más de lo que has puesto, Al-Khwarizmi ;)).

Lo que no me queda claro es en que punto se hace el parseado, aunque es obvio que se hace antes del punto 5 de los pasos "antes".


Arriba
 Perfil  
 
NotaPublicado: 17 Feb 2010 22:12 
Desconectado
Semimomio
Semimomio
Avatar de Usuario

Registrado: 15 Dic 2004 21:28
Mensajes: 2302
Pues he encontrado un ejemplo de código, que de ser correcto:

Código:
[ RutinaPreJuego ;
if (accion == ##ir) rtrue;
]


significa que la acción ya está definida en el punto 1, por lo tanto ya se ha parseado, si no, no se sabría.


Arriba
 Perfil  
 
NotaPublicado: 17 Feb 2010 22:12 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5304
Ubicación: Coruña
presi escribió:
Yo es que de verdad no creo que sea demasiado complejo tener 4 ganchos, no sé a que clase de usuarios quieres que vaya dirigido AGE. :P


Bueno, ciertamente AGE va dirigido a programadores avanzados, eso está claro. Pero dentro de eso, mi objetivo siempre es no hacer las cosas más complicadas de lo necesario, y que el sistema tenga varias "capas". Es decir, que un usuario menos avanzado puede usar "partes" del sistema para hacer una aventura sencilla, sin meterse hasta el fondo.

Que conste que no he descartado lo de los cuatro ganchos por completo. Es una opción que está ahí. Sólo digo que me da la impresión de que puede que sea un poco compleja de más cuando lo único que aporta a mayores es una minucia como poder cambiar los mensajes por defecto sin afectar a lo demás; y me gustaría ver si hay opciones mejores. Si no las hay, supongo que acabaré haciendo cuatro ganchos.

presi escribió:
En cualquier caso, de quitar alguno veo mucho más importantes los puntos 3 y 4 que el 1, en mi opinión el 1 sólo debería proporcionarse para ejecutar algo global antes de iniciar cualquier acción y no para parsear la acción, sigo pensando que para parsear ya está el propio parser del sistema y no el código de la aventura, y si el autor en algún momento necesita parsear por sí mismo entonces es síntoma de que algo falla en el parser del sistema.


El AGE ya parsea y te proporciona el resultado del parseado (los parseCommands de los objetos te dicen qué verbo puso el jugador y a qué objetos se refería, y te dan las partes de la cadena de entrada que se referían a cada objeto). Pero puedes ignorar ese parseado si quieres e ir desde el principio por tu cuenta, es una funcionalidad más.

Realmente en los puntos 1 y 2 no detallé mucho porque quería centrarme en los otros 2, pero en los parseCommands de AGE, tienes desde los que te dan la cadena de entrada "pura" y la parseas tú totalmente, hasta los que te dan la cadena de entrada ya troceada y con los objetos identificados (o sea, parseada), y tú simplemente decides qué hacer con ella (o sea, puede que se haya parseado que el verbo es coger y el objeto directo es espada, pero por algún motivo quieras hacer otra cosa). Así que realmente los parseCommands cubrirían tanto el punto 1 como el 2, según cuál uses.

presi escribió:
Quizá la clave esté en no llamarlos "antes" o "después" sino de otra manera, ya que en realidad eso solo sirve para 2 ganchos, y puede resultar confuso para un modelo de 4 ganchos (o incluso de 3): ¿antes o después de qué?.


Interesante, muy interesante. Realmente los nombres influyen. Pero no es sólo el nombre, es el concepto. Es que es bastante fácil hacerse con el concepto de que algo se ejecuta antes de la acción, y otro algo se ejecuta después. Es más difícil, en mi opinión, acordarse si hay un gancho más. No porque sea uno más, sino porque eso ya te obliga a saber que hay varias fases en la acción que ocurren en un cierto orden. Y ya digo, no es que tener que saber eso me parezca inadmisible, pero sí me gustaría evitarlo... no sólo para programadores principiantes, sino para programadores avanzados con poca memoria.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)


Arriba
 Perfil  
 
NotaPublicado: 17 Feb 2010 22:18 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5304
Ubicación: Coruña
presi escribió:
La secuencia en InformATE es más complicada de lo que recordaba (y más de lo que has puesto, Al-Khwarizmi ;)).


Realmente es muy parecida (incluso asombrosamente parecida, teniendo en cuenta que nunca había visto la de inform :D) Sólo que en mi explicación simplifiqué mucho porque realmente sólo me interesaban los puntos 3 y 4, así que no tenía mucho sentido explicarlo todo en detalle.

En realidad entre los parseCommands hay un parseCommand del mundo que sería como esa RutinaPreJuego, un parseCommand del jugador que sería como esa rutina de órdenes del jugador, y luego los hay de habitación (como las de la habitación), de objeto, etc. Con los eventos igual, los hay de habitación, de objeto, etc.; y también hay un mecanismo para que los objetos cercanos reaccionen.

Las diferencias principales son que el AGE no tiene métodos de reaccionar antes y de antes para objetos de habitación ni para la habitación en sí (pero la verdad es que tampoco los "envidio", porque puedes hacer que el jugador llame a la habitación y a esos objetos); y que a cambio se llaman también los equivalentes a los "antes" para el segundo objeto (no sólo el primero) y tiene algo más detalle en la parte de cosas que suceden antes y durante el parsing. Además de la diferencia entre inyectar en 3 e inyectar en 4 que comenté anteriormente, claro.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)


Arriba
 Perfil  
 
NotaPublicado: 17 Feb 2010 23:11 
Desconectado
xyzzy

Registrado: 09 Mar 2004 22:50
Mensajes: 9150
¿Cuál es el objetivo de las respuestas por defecto del parser?
Yo comprendo que en el caso del inventario es obvio.
Puedo entender que al entrar a una habitación se listen los objetos que hay en la misma, sólo por el hecho de que están ahí.... ¿pero es lógico? ¿no sería más normal que sólo se enumerasen al examinar el entorno?
Comprendo que cuando coges algo, se imprima un mensaje del sistema si por alguna circunstancia la acción falla, pero no entiendo que recibas el aviso de que lo has cogido... es como un eco sin sentido.

> suenate la nariz
Te suenas la nariz.
Te has sonado la nariz.

>Ex habitación.
La habitación tiene cuatro paredes y una puerta.
Has mirado la habitación.

>Coge el pañuelo.
Al coger el pañuelo un objeto metálico cae al suelo.
Has cogido el pañuelo.

¿Por qué en las dos primera se ve ridículo y en la última no tendría porque?


>Coge el pañuelo.
Al coger el pañuelo un objeto metálico cae al suelo.
Ahora el pañuelo está en tu poder.

Suena un poco mejor.

Metes con cuidado la blusa en el cofre.
Acto seguido mueves la palanca, al hacerlo la tapa cae cerrando el cofre.
Pones la blusa en el cofre.

Suena fatal, pero...

Metes con cuidado la blusa en el cofre.
Acto seguido mueves la palanca, al hacerlo la tapa cae cerrando el cofre.
Ahora la blusa está en el cofre.

No sé si cambiar la respuesta por defecto podría ser útil, yo sigo pensando que lo ideal sería que en algunos casos el parser no dijera nada y fuera el programador quien decidiera qué es lo que debe decir.


Arriba
 Perfil  
 
NotaPublicado: 18 Feb 2010 00:33 
Desconectado
Betatester
Betatester
Avatar de Usuario

Registrado: 09 Sep 2004 12:53
Mensajes: 1142
Yo creo que se puede simplificar con un solo gancho de la siguiente forma:

En general cuando queremos ejecutar código después de realizada la acción puede ser para:

a) ejecutar código que no imprime nada -> da igual el punto del gancho
b) cambiar el mensaje por defecto para poner nuestro propio texto -> gancho 3
c) escribir el código por defecto y después nuestro código -> gancho 4

Siendo la única diferencia el escribir el mensaje por defecto lo que haría es añadir algún método para mostrar ese texto, de forma que podamos nosotros elegir si lo ponemos antes o después del nuestro. Es decir, seríamos nosotros los que decidiríamos si estamos en 3 o en 4.

En pseudocódigo chusquero, que puedas hacer:

puerta.despuesCerrar()
{
return self.mensaje_defecto() + "Parece que se ha quedado trancada y ya no se puede volver a abrir.";
}

>cerrar puerta
Cerrada.
Parece que se ha quedado trancada y ya no se puede volver a abrir.

o también

puerta.despuesCerrar()
{
return "Los goznes de la puerta chirrían al moverla." + self.mensaje_defecto();
}

>cerrar puerta
Los goznes de la puerta chirrían al moverla.
Cerrada.

o también

puerta.despuesCerrar()
{
return "Con un terrible esfuerzo consigues cerrar la puerta de piedra.";
}

>cerrar puerta
Con un terrible esfuerzo consigues cerrar la puerta de piedra.

Igual que Jenesis pienso que este último es el caso más común y con esta solución es el más sencillo de implementar.

_________________
- Lenko -


Arriba
 Perfil  
 
NotaPublicado: 18 Feb 2010 01:04 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5304
Ubicación: Coruña
Bueno, a mí me gustan los ecos tipo "Coges tal cosa", "Coges tal otra" porque siempre he pensado que el texto de salida de la aventura se debería poder leer como una historia, sin contar la entrada. Lo de "Cogida" y similares nunca me ha sonado bien, no tiene sentido. Así que los mensajes por defecto no los voy a cambiar.

En todo caso está claro que la solución pasa por permitir al usuario poner lo que quiera independiente de los mensajes por defecto, por supuesto, porque las ideas de cada cual sobre esto son distintas.

Lo que dice Lenko es un poco parecido a alguna de las soluciones que pensaba yo. Yo pensaba en el gancho 2 sin end (sin lo que sería rtrue en inform), con un método que cambie el mensaje por defecto, que sería equivalente a eso.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)


Arriba
 Perfil  
 
NotaPublicado: 18 Feb 2010 07:57 
Desconectado
xyzzy

Registrado: 09 Mar 2004 22:50
Mensajes: 9150
Al-Khwarizmi escribió:
Bueno, a mí me gustan los ecos tipo "Coges tal cosa", "Coges tal otra" porque siempre he pensado que el texto de salida de la aventura se debería poder leer como una historia, sin contar la entrada. Lo de "Cogida" y similares nunca me ha sonado bien, no tiene sentido.


A mí tampoco me gusta eso de "cogido" porque el problema principal sigue siendo el mismo, pero "Coges tal cosa" implica un tiempo verbal en presente de indicativo, que impide se pueda añadir ninguna consecuencia textual al hecho de coger algo.
Antes he puesto un ejemplo real de lo que ocurre en mi aventura.


Código:
Metes con cuidado la blusa en el cofre.
Acto seguido mueves la palanca, al hacerlo la tapa cae cerrando el cofre.
Pones la blusa en el cofre.


La segunda línea es mi respuesta a la acción coger.
La última línea. que es la respuesta por defecto del parser, evidencia una incongruencia temporal con el hecho de que despúes de meter la blusa en el cofre, he movido la palanca y éste ya está cerrado cuando el parser dice "Pones la blusa en el cofre".

En cambio si el parser dijera "Ahora la blusa está en el cofre", tendríamos:

Código:
Metes con cuidado la blusa en el cofre.
Acto seguido mueves la palanca, al hacerlo la tapa cae cerrando el cofre.
Ahora la blusa está en el cofre.


Con lo cual la incongruencia desaparece por completo.
Esta nueva respuesta no es valida para absolutamente todas las circunstancias, pero es más válida que la anterior. Se trata de que la respuesta del parser no devuelva la propia acción que se realiza, sino su resultado y así es más dificil que la respuesta que añade el programador provoque un colapso "espacio-temporal".

Por otro lado lo ideal sería que el programador pudiera redefinir todas las respuestas por defecto del parser, algo así como lo que hace el mensajes.h de inform, eso estaría bien para darle un estilo completamente propio a tu aventura, pero para casos puntuales como el del cofre bastaría con que el programador pudiera hacer que el parser quedara mudo.


Arriba
 Perfil  
 
NotaPublicado: 18 Feb 2010 08:36 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5304
Ubicación: Coruña
jenesis escribió:
La segunda línea es mi respuesta a la acción coger.
La última línea. que es la respuesta por defecto del parser, evidencia una incongruencia temporal con el hecho de que despúes de meter la blusa en el cofre, he movido la palanca y éste ya está cerrado cuando el parser dice "Pones la blusa en el cofre".


Bueno, pero eso es porque has puesto mensajes antes, y ahí efectivamente hay una incongruencia entre lo que has puesto tú y lo que ha puesto el sistema. Pero la idea de los mensajes por defecto es que queden bien cuando el creador de aventuras no modifica la acción. Y en ese caso, a mí me gusta más

> poner la blusa en el cofre
Pones la blusa en el cofre.

que

> poner la blusa en el cofre
Ahora la blusa está en el cofre.

Porque con el primero puedes leer toda la salida del juego como una historia. (de hecho para mí el ideal sería que la entrada del jugador no se mostrara en absoluto y sólo se mostrara la salida, sólo que eso sería romper demasiado con las tradiciones e igual la gente se sentiría incómoda).

Pero sí, estamos de acuerdo en que tengo que proporcionar una forma sencilla de cambiar todos esos mensajes, y así poder solucionar cosas como la incongruencia temporal que has mencionado.

Básicamente manejo tres posibles soluciones:

1. Implementar el sistema de cuatro ganchos. O sea, que haya un método que se ejecute después de la acción pero antes del mensaje por defecto, y otro que se ejecute después de todo eso.
2. Permitir cambiar temporalmente los mensajes por defecto (algo parecido, aunque no igual, que lo que dijo Lenko): que puedas usar por ejemplo un parseCommand, y decir: "hasta el final del procesado de este comando, el mensaje por defecto de coger queda cambiado a tal y cual".
3. Permitir cambiar permanentemente los mensajes por defecto: que haya una lista de mensajes por defecto y puedas cambiarlos. Y si quieres personalizar mensajes para cada objeto, puedes poner el mensaje por defecto correspondiente vacío, y manejar los mensajes a mano en el parseCommand o en los eventos indistintamente.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)


Arriba
 Perfil  
 
NotaPublicado: 18 Feb 2010 09:58 
Desconectado
xyzzy

Registrado: 09 Mar 2004 22:50
Mensajes: 9150
Al-Khwarizmi escribió:
. (de hecho para mí el ideal sería que la entrada del jugador no se mostrara en absoluto y sólo se mostrara la salida, sólo que eso sería romper demasiado con las tradiciones e igual la gente se sentiría incómoda).


Pues no te creas que no he pensado yo veces eso...
Que no se mostrara el comando en pantalla... :lol:
El único problema que le veo es que si el jugador escribe algo mal deletreado, no se da cuenta.
Tal vez se podría hacer que el comando introducido por el jugador se mantuviera hasta el siguiente en algún sitio, así la pantalla quedaría libre para la historia y solo la historia. :roll:

Si no te cuesta mucho podías hacer un AGE (prototipo), que no incluyera los comandos del jugador en la pantalla principal, así se vería rápido el efecto que causaba.
Bueno también se puede editar el log y quitarlo a mano :lol:, un rato que tenga lo haré a ver como queda.

Citar:
Básicamente manejo tres posibles soluciones:

1. Implementar el sistema de cuatro ganchos. O sea, que haya un método que se ejecute después de la acción pero antes del mensaje por defecto, y otro que se ejecute después de todo eso.
2. Permitir cambiar temporalmente los mensajes por defecto (algo parecido, aunque no igual, que lo que dijo Lenko): que puedas usar por ejemplo un parseCommand, y decir: "hasta el final del procesado de este comando, el mensaje por defecto de coger queda cambiado a tal y cual".
3. Permitir cambiar permanentemente los mensajes por defecto: que haya una lista de mensajes por defecto y puedas cambiarlos. Y si quieres personalizar mensajes para cada objeto, puedes poner el mensaje por defecto correspondiente vacío, y manejar los mensajes a mano en el parseCommand o en los eventos indistintamente.


No sé si he entendido bien, pero creo que el que más me gusta es la opción 3.
De todos modos, sería interesante tener una lista de todos los mensajes por defecto.
¿Cómo la puedo conseguir?


Arriba
 Perfil  
 
Mostrar mensajes previos:  Ordenar por  
Nuevo tema Responder al tema  [ 38 mensajes ]  Ir a página Anterior  1, 2, 3  Siguiente

Todos los horarios son UTC + 1 hora


¿Quién está conectado?

Usuarios navegando por este Foro: Google [Bot] y 2 invitados


No puede abrir nuevos temas en este Foro
No puede responder a temas en este Foro
No puede editar sus mensajes en este Foro
No puede borrar sus mensajes en este Foro

Buscar:
Saltar a:  
Desarrollado por phpBB® Forum Software © phpBB Group
Traducción al español por Huan Manwë para phpBB-Es.COM