Distinguir entre múltiples objects con el mismo nombre en un juego de aventuras basado en text / ficción interactiva

Estoy en el medio de escribir mi propio analizador en Python. He logrado hacer algunos commands simples, con impresiones simples para asegurarme de que funcionen. Como pretendo que haya combate, necesitaba escribir un command para atacar algo. Acabo de completar eso.

Mi problema es: ¿qué debo hacer para permitir que el jugador elija qué enemigo enemigo atacarán? Es bastante simple cuando son diferentes types de enemigos (por ejemplo, un duende y un troglodita), pero ¿cómo debo distinguir entre dos del mismo tipo (por ejemplo, dos trogloditas)?

Sugerencias que he tenido hasta ahora: Dale a cada una de ellas una característica significativa (color, altura, dirección relativa) pero solo hasta ahora; nombre a cada uno de ellos (para que ataque "bob" o "steve"); o el que he estado favoreciendo más, les doy a cada uno un número (por lo que habría troglodita1, troglodita2, etc.). Sin embargo, esto podría romper la inmersión.

Tienes lo que siento son dos problemas distintos. Uno es un problema de layout: cómo lidiar con múltiples objects distintos que no tienen características claramente visibles. El segundo problema es un problema técnico, que es cómo facilitar la identificación de objects individuales de un grupo a través de commands.

Solución técnica

De vuelta en mis días de progtwigción MUD, acabo de agregar la syntax para especificar ordinales. La mayoría de los MUD hacen lo mismo, aunque la mayoría solo admiten una syntax escueta.

Por ejemplo, puede analizar las siguientes palabras de un enemigo o argumento de elemento a un command: primero, segundo, otro, tercero, cuarto, quinto, etc.

Generalmente puede detenerse entre "tercero" y "quinto", dependiendo de qué tan comunes sean esos tamaños de grupos en su juego. Utilicé "otro" como sinónimo de "segundo".

También querrá una forma de ingresar en el ordinal con dígitos, por lo que no necesita un gran dictionary (o toda la loca lógica para tratar con los ordinales en inglés, al less). El análisis de "1st", "2nd", "3rd", etc. es bastante fácil. Solo hay algunas reglas especiales para ellos ("11 °", "12 °" y "13 °") y el rest sigue un patrón simple. Yendo por esta ruta, haga que los sufijos sean opcionales.

El resultado es que puede escribir frases como:

attack third goblin pet other wolf get 4th sword 

Incluso puedes analizar y tirar un "the" al frente si quieres complacer al 0.02% de tus jugadores que sienten la necesidad de escribir oraciones completas en inglés. (Es una característica interesante para la demo, pero en realidad, nadie que juegue estos juegos está interesado en escribir mucho, y en estos días tendrás suerte si la mitad de tus jugadores puede deletrear "cuarto" correctamente y mucho less usar la gramática adecuada).

Los MUD típicos y las aventuras de text usan un método terser para especificar ordinales, generalmente con algunos signos de puntuación especiales. Por ejemplo, puede que tenga que poner un punto o dos puntos o algo así seguido o precedido por un número, por ejemplo, ".5", que le da syntax como uno de los siguientes:

 kill .5 goblin kill :5 goblin kill 5:goblin 

Tenga en count que esta solución funciona incluso cuando tiene nombres distintos. Tal vez tengas un "duende grande y odioso" y un "pequeño duende tímido". El jugador no quiere escribir todo eso. El jugador será más feliz si admite partidas parciales. Sin embargo, el jugador todavía quiere identificar fácilmente a los dos trasgos al escribir. Los ordinales son una forma en que el jugador puede hacer eso, suponiendo que haya un order claro para los duendes.

Solución de layout

No tenga elementos y criaturas no distintivos o, si lo hace, haga que actúen implícitamente como un todo. Lo enumeró como una opción para resolver el problema. Realmente es bueno, pero solo si puedes hacerlo completamente.

Considere el caso en el que tiene cinco duendes en sus entornos típicos de MUD ("habitaciones" interconectadas). El jugador entra a la habitación y ve:

 [Cavern Entrance] There are five goblins (hostile) here. Exits to the north and south. 

El jugador quiere atacar primero, por lo que escribe:

 attack goblin 

El jugador ataca al primer duende (primero por implicación de no especificar otro, que es el primer trasgo arbitrariamente el primero en la list de objects de juego enemigos que tengas). El jugador hace algún daño al duende. Luego el jugador ve:

 A goblin flees north. 

El jugador mira alnetworkingedor y ve:

 [Cavern Entrance] There are four goblins (hostile) here. Exits to the north and south. 

Un duende huyó. El problema es, ¿qué duende fue? ¿El que el jugador hirió? ¿Uno de los otros duendes? El jugador no sabe. Digamos que fue el duende herido para este ejemplo.

El jugador continúa luchando:

 attack goblin 

El jugador ataca al duende que ahora es el primer duende (pero anteriormente era el segundo duende). Unos momentos más tarde, el jugador ve:

 A goblin enters from the north. 

El duende que huyó recuperó su coraje y regresó. Probablemente, se agrega al final de una list de algún tipo en el código del juego, por lo que ahora es el quinto duende. Si el jugador mira nuevamente, ve:

 [Cavern Entrance] There are five goblins (hostile) here. Exits to the north and south. 

De nuevo, el jugador ataca. Solo que el jugador no tiene idea de a qué duende está atacando. ¿Es el herido? Una diferente? ¿Cómo dice que uno de los duendes está herido? ¿Cómo puede apuntar a ese duende? Sabemos que el herido es el quinto duende, pero sin una forma de visualizar eso, el jugador no puede saberlo con certeza. Y probablemente desee evitar resultados excesivamente detallados como:

 [Cavern Entrance] There are five goblins (hostile) here. The second goblin is injunetworking. The third goblin is injunetworking. The fourth goblin has a nasty rash. The fifth goblin looks longingly at the second goblin, but the second goblin is out of his league. Exits to the north and south. 

Ahí es donde entra la decisión de layout.

Una opción es tratar todos los objects de juego del mismo tipo agrupados como una sola entidad. Por lo tanto, no tienes cinco duendes individuales con valores de salud individuales. Tienes un grupo de cinco duendes con un solo valor de salud compartido. Siempre que ese valor de salud se networkinguzca por debajo de cero, el número de goblins se networkinguce en uno y la salud se incrementa por el valor de salud por goblin.

Ejemplo: Digamos que los goblins tienen 12 vidas y hay 5 goblins. Usted tiene un solo object duende que tiene un conteo de 5 y una salud de 12. El jugador hace 20 daños al grupo. La salud ahora es -8. Un duende se resta del conteo (ahora hay 4 duendes) y la salud se incrementa en 12 (ahora la salud es 4). Si el jugador hace 4 daños más, otro goblin será asesinado.

Combinar y dividir grupos es un poco inestable en este caso, pero se puede manipular. Cuando aparece un segundo grupo de duendes, tome la sum de sus counts y el mínimo de su salud. Cuando un número de duendes debe huir, su recuento está sujeto al número que no huye, y se crea un nuevo object de grupo con ese recuento con plena salud (el grupo original también debe abandonar la sala como parte de esta operación para que no se fusionan automáticamente de nuevo).

Esto, por supuesto, cambia un poco la dinámica del juego. El jugador ya no puede decidir debilitar a todos los duendes y luego terminarlos en un ataque de área. Él siempre está atacando implícitamente al duende más débil. Sin embargo, esta pequeña compensación en flexibilidad le brinda una interfaz de usuario mucho más obvia, limpia, comprensible y accesible para un juego de text. Depende de sus limitaciones de layout decidir si la compensación es apropiada.

Hay otras variaciones de este enfoque que podría usar también. Cualquier cosa que se aproxime estadísticamente a un grupo de individuos con un número de grupo amplio funciona bien. Los juegos de estrategia como Heroes of Might & Magic o Warlords hacen algo como esto. En lugar de tratar con unidades individuales, el jugador tiene "stacks" de unidades, que se tratan como una sola entidad.

En lugar de distinguirlos por diferentes nombres o colors, podría darle al jugador una variedad de commands con el poder de distinguir.

Por ejemplo, si "cinco duendes te atacan" , podrías devise commands numerados o nombrados como – "atacar al primer duende" o – "atacar al duende 1"

Este enfoque es casi como lo sugirió, pero en lugar de nombrar o presentar una larga list de enemigos aburrida para leer, solo le dice al jugador la cantidad y el jugador decide cómo le gusta interactuar / escribir.

Además, puede tener una database de nombres aleatorios para elegir, si realmente desea distinguir únicamente entre enemigos.

La forma en que los juegos clásicos de aventuras de text del estilo Infocom resolvieron este problema fue, de hecho, asegurándose de que cada object distinto tuviera efectivamente un nombre que permitiera identificarlo de manera única.

Un detalle a tener en count es que, en los analizadores de estilo de Infocom, uno podría referirse a un object por cualquier combinación de palabras en su nombre. Entonces, si el jugador se encontró con un networking chrysanthemum , un networking circular amulet y un green triangular amulet , escribiendo:

 > get networking amulet 

o solo:

 > get circular 

le permitiría al jugador tomar el amuleto circular rojo mientras teclea:

 > get networking 

would (si ambos objects estuvieran realmente presentes) producir una request de aclaración como:

 Which do you mean: the networking chrysanthemum or the networking circular amulet? 

Además, los objects podrían tener sinónimos que no formaban parte de su nombre para mostrar, por ejemplo, escribir:

 > get networking flower 

muy probablemente también funcionaría para recoger el crisantemo rojo. De hecho, los jugadores (y, de hecho, todavía lo hacen) esperan que cualquier juego bien escrito comprenda tales sinónimos naturales. Del mismo modo, un amuleto también puede coincidir con la palabra pendant , especialmente si se describió como que es o se parece a uno en cualquier parte del juego, y el amuleto circular también podría describirse como round .

De hecho, este estilo de análisis sigue siendo muy utilizado en la ficción interactiva moderna. Por ejemplo, es posible que desee ver cómo el analizador reconoce los objects en Inform 7 , un lenguaje de propósito especial diseñado para escribir este tipo de juegos.


PD. Los juegos de Roguelike , que generalmente tienen muchos más objects, generalmente resuelven el mismo problema de una manera diferente: le permiten elegir el object que desea de un menu. Algunos de ellos, para lidiar con el problema potencial de objects aparentemente idénticos que, sin embargo, son diferentes de alguna manera, también permiten al jugador nombrar objects individuales, o incluso classs enteras de objects, para que uno pueda ver, por ejemplo

 What do you want to light [pr]? p - a lamp q - a lamp called "magic" r - a lamp called "magic" named "this one's probably cursed" 

Parece que la mayor parte del territorio ha sido cubierto para metodologías principales, pero pensé que sería un buen ejercicio de reflexión explicar cómo podría conceptualizar esta decisión de todos modos, y esforzarme por cubrir algunos methods que no he visto.

Métodos de Perspectiva y Cuantificación

Varias de las soluciones implican trabajar en torno a esta pregunta mediante el uso de nombres o características para identificar a los monstruos. Para abordar la versión más pura de esta pregunta, asumiremos que te encuentras con N duendes idénticos.

Están inevitablemente dispuestos en una disposition espacial y terminarán con algunas forms de describir su disposition en relación con usted:

Perspectiva desde arriba hacia abajo

  1. Se pueden describir contigo mismo como centro muerto en una brújula. Esto permite la distribución espacial más rica, pero imaginemos que los 5 goblins están alineados con respecto al norte, "el norte" por sí solo no es suficiente para distinguir su disposition.

Perspectiva en primera persona

  1. Se pueden describir en una versión informal de lo anterior (izquierda, frente, derecha, atrás). Esto tiene limitaciones similares, pero esto es relativo a su orientación en cualquier momento dado. Esto también puede estar restringido a lo que puedes "ver" (necesitarías tener algún tipo de visión mágica para apuntar a algo detrás de ti).

Cuantificación

Ambos casos permiten indicar la disposition espacial pero no hacen nada para aclarar entre los múltiplos en el mismo espacio relativo. Podemos agregar algún concepto de cercanía que podría aplicarse por sí mismo o para boost una de las concepciones anteriores.

  1. Se pueden describir en function de su cercanía con usted en forma verbal. Cerca de lejos. Esto tiene limitaciones obvias de cuantificación, pero dado un arreglo espacial, nos damos count de que la relevancia de goblins más allá del "más cercano" solo es relevante si tienes algún tipo de método a distancia para alcanzarlos (o algún método para pasar cualquier cantidad de goblins intermedios a atacar al último.) Este método de distinción es más compatible con la metodología de "stack" sugerida por otros.
  2. Se pueden cuantificar en function de su cercanía con usted. El primer duende es el más cercano, y el enésimo duende es el más alejado. Este solo es probablemente el método más común de distinción en uso.

Otro

  1. Es posible que pueda utilizar algún tipo de cliente o tecnología novedosa para requerir que el jugador click el nombre para atacar.

Métodos de denominación y descripción

Hay una serie de enfoques aquí, y todos implican eludir la necesidad de resolver la debilidad del medio de text en estas forms de reference:

  1. asegurar que los monstruos son únicos en la fase de layout y no necesitan distinguir
  2. generar properties locales únicas random para distinguirlas
  3. generar nombres semi-aleatorios (probablemente con algorithms adaptados a la raza / class)
  4. generar indicadores aleatorios únicos como metadatos para la orientación (uno o dos caracteres alfabéticos).

Soluciones más radicales

Todas las diversas soluciones hasta ahora se basan en el supuesto de que la tarea de apuntar a otros objects con acciones es la del jugador. Si desconfiamos de esta suposition, se abren nuevas posibilidades para nosotros:

  1. En su lugar, podría ser que tu juego esté en un reino donde las criaturas dictan acción; los mobilees decidirán si atacan o interactúan con el jugador y el jugador asume un papel puramente reactjsrio dentro del mundo.
  2. Los teléfonos mobilees de tu mundo podrían interactuar contigo en function de las acciones que realices. Para dar un ejemplo, un guardia puede negarse a participar en hostilidades con usted hasta que intente escabullirse o pasar a su lado en ese momento en el que lo enganche en combate. En lugar de intentar algo como "preguntar espía sobre la aldea", en su lugar podría "preguntar sobre la aldea" y permitir que todos los mobilees actuales tengan la oportunidad de responder.
  3. Podríamos diseñar un juego lento y deliberativo en el que al jugador se le presenten TODAS las opciones en algún tipo de modo de selección alfanumérico. (es decir, select la opción 1 para ir al oeste, vaya al oeste, ¿qué le gustaría hacer? 1 – ir al oeste, 2 – ir hacia el este, 3 – atacar al duende feo, 4 – hablar con el duende feo …)
  4. Podríamos diseñar una versión aún más deliberativa del mismo concepto en el cual el jugador toma decisiones ramificadas en una especie de estilo de elegir su propia aventura. El jugador podría enfrentarse a una elección entre una de dos habilidades, y en lugar de tener puntos y agencia para entrenar a la otra más adelante, la habilidad que no eligió podría no presentarse nuevamente.

Decisión: mecánica, tedio e inmersión

Una discusión útil para tener consigo mismo es probablemente: ¿qué tipo de ritmo y escala queremos que tenga nuestro juego? Podrías hacer preguntas sobre la verbosidad y la pureza lingüística, pero creo que estos son valores que, en última instancia, deben estar en armonía con tu decisión principal sobre cómo jugará tu juego. Si su juego implicará un combate ocasional con una escasa colección de NPC, sospecho que es muy viable que tenga un sistema de selección descriptivo. Si tu juego es un hack-and-slash donde los jugadores matan cientos de mobilees por hora, hacer que tengan que leer y volver a escribir las properties con frecuencia va a ser tedioso o se desplazará a los desencadenantes.

Parte de la discusión que rodea esta decisión parece estar basada en la idea de que "get el amuleto 2" o "get el 2º amuleto" de alguna manera rompe la inmersión con los metadatos de intrusión; Yo argumentaría por el contrario que el analizador del juego me preguntó si me refería al amuleto rojo o al amuleto verde es un ataque mucho más atroz en mi suspensión de la incnetworkingulidad que el anterior – subvierte mi agencia, me restring el omnipresente papel del analizador, y habla con una voz incorpórea. Vivimos en un mundo donde las decisiones espaciales tienen sentido. No te paras delante de un grupo de policías y seleccionas al tipo con Levi's maltratado, cabello negro y una figura pornográfica; usted identifica al sospechoso dentro del espacio basándose en estas mismas properties, pero luego selecciona un número apropiado a lo largo de una escala lógica de izquierda a derecha para comunicarse rápida y claramente.

Conclusión

Solo dos de las respuestas propuestas en realidad resuelven la pregunta de raíz: ¿Cómo desaparece el juego entre references a objects similares si / cuando ocurren? Una de ellas es exigir aclaraciones al jugador después de la request, y la otra es asumir una disposition espacial lógica de algún tipo y asumir que el jugador no necesita aclarar la ambigüedad. Hay un momento y lugar para ambos, pero hay una gran diferencia entre los dos, y creo que probablemente corresponda a la mayoría de los juegos de text responder a esta pregunta en el analizador en lugar de intentar idear un juego en el que dos elementos idénticos nunca estar presente y necesita reference.

Obviamente soy fan de una reference numérica, pero creo que también puedes combinar una variedad de las diversas ideas que han surgido para esculpir la sensación de tu juego. También puede dejar estas decisiones al jugador y proporcionarles la capacidad de elegir entre un analizador que responde a requestes ambiguas con una pregunta y un analizador sintáctico que ejecuta requestes ambiguas con una suposition. De todos modos, puede dar a los jugadores la opción de generar un indicador de metadatos para cada elemento que puedan usar para referirse a él.