Twin Kingdom Valley es unjuego de aventuras de texto con imágenes animadas (en la mayoría de los formatos) [ aclaración necesaria ] para BBC Micro , Acorn Electron , Commodore 64 , Commodore 16 y ZX Spectrum . Fue lanzado en 1983 por Bug-Byte .
Valle del Reino Gemelo | |
---|---|
![]() | |
Desarrollador (es) | Trevor Hall |
Editorial (es) | Bug-Byte |
Plataforma (s) | Acorn Electron , BBC Micro , Commodore 16 , Commodore 64 , ZX Spectrum |
Lanzamiento | 1983 |
Género (s) | Ficción interactiva |
Modo (s) | Un solo jugador |
Como se Juega
Twin Kingdom Valley es una obra de ficción interactiva donde el jugador ingresa comandos como "tomar jarra" en un símbolo del sistema y se le dice el resultado de su movimiento ("Lo tengo ahora"). Cada uno de estos comandos ocupa una unidad de tiempo, durante la cual otros personajes no jugadores también se moverán y realizarán acciones.
Fue uno de los primeros juegos de aventuras de texto en tener personajes activos no jugadores . [1] Los personajes son interactivos y tienen sus propias personalidades: algunos son amistosos y seguirán y defenderán al jugador, mientras que otros son hostiles. Las brujas y los reyes son personajes complejos, mientras que los gorilas y los trolls son más simples. Las secuencias de batalla tienen características adicionales que incluyen armas que los enemigos pueden dejar caer, romper, tirar o quitar.
Gráfico
El personaje principal de este juego, denominado "tú" por el motor del juego, es un cazador de tesoros. [2] El jugador comienza el juego en el extremo sur del reino forestal, con pocas posesiones. Un encuentro temprano con el posadero de The Sword Inn puede persuadir al jugador de que le alquile una pequeña cabaña de troncos. En la cabina hay algunos suministros muy escasos, como una jarra simple.
Para progresar en el juego, el jugador debe determinar qué personajes considerar como amigos y cuáles como enemigos. Algunos personajes, como un gorila que ataca al jugador con un palo de madera, se presentan claramente como enemigos, mientras que otros son ambiguos.
Hay dos reinos, un bosque y un desierto, separados por un profundo cañón. Cada reino está gobernado por un rey, y los reyes no se llevan bien entre sí. Se le dice al jugador que la situación ha empeorado recientemente y que falta un miembro de la realeza del reino del bosque, atribuyéndose el crimen al rey del desierto. Con dos reinos ricos en guerra, se sugiere que el jugador podría aprovechar esto y saquear tesoros de ambos lados. A medida que avanza el juego, al jugador le resulta un desafío transportar el botín de regreso a la cabaña de troncos y, en ocasiones, se ve obligado a elegir entre llevar un tesoro y llevar un arma, ya que ambos tipos de objetos corren el riesgo de ser robados si no se los vigila.
La trama se desarrolla con el tiempo. En el juego original de BBC Micro, había un número limitado de ubicaciones y gráficos. Algunas adiciones aparecen en la versión C64, aunque la trama es básicamente la misma. La edición moderna del juego para teléfonos inteligentes incluye más ubicaciones y algunos nuevos giros en la trama.
Desarrollo
Concepto
El juego se inspiró en la aventura original de Will Crowther . [3] El motor del juego original fue escrito en lenguaje ensamblador 6502 . Luego, el juego se transfirió a Z80 para Spectrum. Las versiones más nuevas (para Commodore 64 y Spectrum) tienen un juego extendido. El juego se propuso agregar un nivel de realismo mediante la adición de imágenes y personajes complejos.
Los inicios del juego fueron más un desafío de presión de grupo que una empresa comercial. En ese momento, el acceso a las "máquinas masivas" (según los estándares del día) necesarias para ejecutar la aventura original era limitado. La idea era: seguramente esto se puede hacer en una computadora doméstica, de alguna manera. La lentitud del código de lenguaje de alto nivel (Básico) en los sistemas domésticos lo descartó como una ruta, y no había acceso a un compilador FORTRAN en ese momento. Por eso se eligió el montaje. Pocas personas habían ejecutado el original, y (habiéndose graduado) aquellos estudiantes que tenían acceso a equipos universitarios capaces de ejecutar el juego habían perdido ese acceso privilegiado. Entonces, los elementos recordados (burlonamente) se parecían al original, con una carretera, un edificio (que contenía elementos útiles, como llaves y una lámpara) que se repetían. El edificio está en el bosque, con un manantial cercano. Sin embargo, más allá de este teaser de que se trata de una especie de clon, el parecido termina. El plan cambió a "por qué copiar, cuando puedes hacerlo mejor".
En lugar de simplemente modelar una cueva, el desafío era modelar un mundo más grande, con muchas ubicaciones sobre el suelo, subterráneas, interiores y exteriores.
Se eligió una época algo medieval para el juego, permitiendo elementos de misticismo. Todos los combates se diseñaron como un estilo básico cuerpo a cuerpo, con el jugador y otros personajes turnándose para intercambiar golpes. Los turnos siempre se inician con la escritura del jugador, en lugar de ocurrir en tiempo real. Si el jugador intenta huir del combate, al oponente se le permite un ataque antes de que el jugador se mueva. El comportamiento del jugador se modela de la misma manera que los personajes. Al igual que los juegos similares, los personajes tienen varios límites, como su salud máxima y tasa de curación, y la capacidad de carga.
Gráficos
Una sección importante del software es un lenguaje de gráficos personalizado, que es uno de los primeros formatos de gráficos vectoriales escalables . Cientos de imágenes de objetos y ubicaciones se dibujan en el juego usando esta herramienta personalizada. Se logra una perspectiva de tipo limitado al permitir que las imágenes se dibujen a escala dentro de otra imagen. Por ejemplo, un modelo de castillo se diseñaría para una vista de cerca, pero también se podría dibujar como una subrutina para un castillo distante en un desierto. La velocidad de los gráficos era de aproximadamente 10 polígonos por segundo, por lo que el juego no podía permitirse escribir polígonos de fondo y sobrellenar. Las imágenes solo se crean mediante rellenos de inundación, de modo que cada píxel de la pantalla se rellena solo una vez. Una PC moderna (usando un emulador) puede pintar estas imágenes instantáneamente, pero los propietarios del juego original tendrían que esperar tres o cuatro segundos para que se pinte la pantalla.
Los comandos de gráficos tuvieron que estar muy comprimidos, debido al presupuesto de espacio de memoria limitado. Considere una llamada de dibujo de línea, que "dibuja a" desde la posición actual, con un color y nuevas coordenadas x, y. Si usa 6502 para: cargar el registro x con la coordenada x, cargar el registro y con la coordenada y, cargar el acumulador con un color y luego llamar a "Dibujar línea", ha usado 9 bytes. Si hay un total de 1000 líneas de este tipo en todas las imágenes del juego, entonces se habrían perdido 9K. La memoria real utilizada para un comando de dibujo en el juego es de 2 bytes.
Para dibujar y rellenar un contorno, se necesitan 3 comandos básicos: Mover, Dibujar, Rellenar. Un movimiento (al comienzo de la forma) seguido de un dibujo en cada punto del contorno, hasta que la forma se cierre, luego se rellena dentro de la forma. Dibujar y rellenar necesita un color para la línea. Todo Move Draw y Fill necesitan una coordenada. Para decodificar esto de manera eficiente, solo se necesitan 2 bits para resolver "Mover, Dibujar, Rellenar", cualquier otra instrucción "en un lenguaje ensamblador. [4] Un bit adicional determina si el comando tiene coordenadas de pantalla absolutas o una posición relativa. 3 los bits dan una opción de 8 colores, y finalmente 10 bits dan dos coordenadas x, y de 5 bits.
Los otros comandos (que no necesitan coordenadas) incluyen: Llamar a una subrutina, finalizar una subrutina, dibujar un arco circular (centro en la última coordenada movida), etc. Imágenes complejas, como una cabina hecha de muchos registros, usan una instrucción de bucle, similar al bucle for en C, con un límite de bucle constante. El lenguaje ensamblador no tiene concepto de variables ni instrucciones de ramificación.
Motor de juegos
El juego tiene varias micro bases de datos de información, que representan las ubicaciones, los objetos que se pueden usar, varias criaturas y otros datos. El motor del juego ejecuta un mundo simulado para estos elementos. Un pequeño módulo de IA permite que los personajes no jugadores tomen decisiones. [5]
El motor de ubicación tiene algunas características para ahorrar memoria. En la mayoría de las ubicaciones hay solo unas pocas palabras, pero se interpreta una "base de datos de salida" detallada (empaquetada en bits) para hacer descripciones más largas. Estas descripciones pueden variar a medida que se establecen y borran bits para puertas bloqueadas y desbloqueadas. Una ubicación con aproximadamente ocho líneas de texto que la describen puede tener menos de 30 bytes de datos. Las palabras utilizadas en la base de datos de ubicación del juego se almacenan como un solo byte por palabra, que buscan en una lista de 256 palabras y, como resultado, muchas palabras se reutilizan varias veces.
Por ejemplo, "Estás junto a un arroyo que murmura, al norte puedes ver un arroyo, al sur puedes ver una carretera, el noroeste es un río profundo". El motor del juego agrega las palabras "Tú eres". "por un arroyo balbuceante" es sólo 4 bytes de datos, un quinto byte codifica la longitud (4) del mensaje en palabras. La ubicación tiene 3 salidas, que están codificadas como 2 o 3 bytes por salida. El byte 1 tiene la dirección de la brújula más arriba o abajo (6 bits para N, S, E, W, U, D). Una broca adicional marca salidas especiales, como puertas cerradas. Un byte adicional luego define varios bits para bloqueado / desbloqueado o "puede ver a través, no puede ver a través", etc. Finalmente, un byte para el destino. A continuación, se omite la primera palabra del destino, por lo que: si el norte lleva a "Por una corriente", se omite la palabra "Por" y se agregan las palabras "puedes ver", dando "Norte, puedes ver una corriente". usando solo 2 bytes.
Toda esta compresión era necesaria para que el juego se ajustara al límite de 32k o al sistema BBC Micro original . Se pierden 10k como búfer de pantalla, por lo que la memoria del juego se ha reducido a 22k desde el principio. Con parte de la memoria necesaria para el espacio variable o la pila, el código disponible se encuentra en un sistema que se acerca más a los 20k. Si el juego tuviera 200 ubicaciones a 30 bytes por ubicación, esto sería 6k. Incluso esto dejaría casi ningún espacio para el código del juego, especialmente los gráficos. Las versiones originales del juego tenían menos de 200 ubicaciones únicas, por esta razón. Hay aproximadamente 180 ubicaciones en las primeras ediciones (como la de BBC Micro) y 190 en las ediciones posteriores (como la versión Commodore 64). Otras mesas de juego (como las de criaturas u objetos) son mucho más pequeñas.
El juego tiene un pequeño bloque de restablecimiento de datos, que vuelve a bloquear las puertas y otros objetos cuando el jugador comienza un nuevo juego. En versiones posteriores (como C64), la memoria adicional permitía algunos mensajes más largos en texto sin formato para eventos especiales del juego y acertijos.
Debido a que las criaturas pueden contener objetos, todas las criaturas son tratadas como ubicaciones especiales por el motor del juego. Un objeto tiene una ubicación de un solo byte que puede ser una habitación o una criatura, y todas las ubicaciones por encima de 200 están reservadas para criaturas u otros códigos de ubicación especiales (como "roto").
Desarrollo continuo
El juego estuvo en desarrollo activo nuevamente en 2006, debido a la disponibilidad de nuevas plataformas. El motor del juego se ha portado, del 6502 original, a Java , con algunas herramientas de diseño de juegos en C # .
Recepción
Las críticas fueron en general positivas. El enlace World of Spectrum tiene muchas capturas de pantalla de reseñas de revistas del juego.
Aquí están las calificaciones otorgadas por Crash Magazine, para la versión ZX Spectrum:
- Ambiente: 9
- Vocabulario: 7
- Lógica: 7
- Depuración: 7
- Valor total: 8
Esa revisión comenta las peculiaridades que ocurren al portar juegos de BBC micro o C64 a ZX Spectrum. La versión original de la BBC había sido reportada por el fabricante, Bug Byte, como un "éxito número uno" por una revista, según los informes, según las cifras de ventas. Hay poca o ninguna información disponible sobre cómo las revistas en ese momento compilaban tales gráficos. Sin embargo, las ventas fueron claramente lo suficientemente significativas como para que el editor solicitara los distintos puertos enumerados y ejecutara muchos anuncios de página completa para el juego.
Se enviaron cartas al editor del juego, antes de que se crearan los "sistemas de revisión de Internet". Estos se perdieron hace mucho tiempo, pero incluyeron comentarios generalmente positivos. La más notable de ellas fue una carta del padre de un niño ciego, que pudo jugar el juego gracias al soporte de sintetizador de voz incluido. [ cita requerida ]
Referencias
- ^ Gunness, Jacob (noviembre de 1999). "Entrevista a Trevor" . Archivo de soluciones de aventuras clásicas . Consultado el 3 de diciembre de 2013 .
- ^ http://solutionarchive.com/game/id%2C564/Twin+Kingdom+Valley.html
- ^ http://solutionarchive.com/interview_trevor/
- ^ Gunness, Jacob (agosto de 2006). "Entrevista a Trevor 2" . Archivo de soluciones de aventuras clásicas: Twin Kingdom Valley - en movimiento . Consultado el 3 de diciembre de 2013 .
- ^ http://solutionarchive.com/interview_trevor/
enlaces externos
- Página web oficial
- Twin Kingdom Valley en SpectrumComputing.co.uk