Portar, continuar o crear, he aquí la cuestión...

[sromero]

No es por llevarte la contraria (que no lo es) Santi, peor en WoS estaban programando un juego de este estilo y no lo veian tan dificil, creo recordar que no iba a ser para +3, y que habian solucionado los problemas que este tipo de juegos podria llevar al Spectrum

Hombre, lo que yo he comentado es matemática pura... Si tienes N localidades y el mapeado de X*Y bytes te ocupa Z bytes por pantalla ... sin compresión, por narices, te ocupará N*Z bytes en memoria.

A menos que, pues eso: cargues el mapa por zonas, uses compresión, tengas un mapeado pequeño, etc etc. Pero entonces, se va MUCHO de lo que es un juego tipo Zelda.

Para que os hagáis una idea:

Mapa del Zelda de Nintendo NES

El mapa del zelda de NES la verdad es que no es muy grande, es de 21x10, la verdad es que con bastante curro se podría hacer algo así ... pero claro, hasta que te das cuenta de que eso es sólo el mapa DEL EXTERIOR (overworld). Ahí no están las mazmorras, ni las habitaciones, casas, etc. El mapa al final es mucho más grande que eso.

Total, que puede ser un pasote de tamaño.

Que no digo que no se pueda hacer, ¿eh? Sólo digo que las aventuras gráficas y los RPGs tienen ESE problema, que tienes que asumir que no va a ser tan grande como un Zelda de hace 20 años.

¿El juego ese de WOS es un "juego tipo Zelda", o un juego con "perspectiva tipo Zelda"?

[Ivanzx]

Ahi esta el thread de lo del Zelda, es bastante largo y en ingles pero por si se puede sacar algo aprovechable lo cuelgo

http://www.worldofspectrum.org/forums/s ... hp?t=11784

[sromero]

Ahi esta el thread de lo del Zelda, es bastante largo y en ingles pero por si se puede sacar algo aprovechable lo cuelgo

http://www.worldofspectrum.org/forums/s ... hp?t=11784

El mapa del juego es de 8x9 pantallas:

http://www.redballoon.demon.co.uk/stuff/th_map.png

De aquí a las 21x9 pantallas del MUNDO EXTERIOR del Zelda 1 de Nintendo NES, ya va un poco. Y súmale todas las mazmorras interiores del Zelda (que son mapas de gran tamaño).

Hombre:

8*9*192 = 13824 Bytes.

13KB para guardar el mapa del juego, está bien. Pero ten en cuenta que este mapa no es mucho más grande que el del Phantomasa 2, que es un arcade. Y desde luego, bastante lejos del mapa de un Zelda.

Vamos, que no saldrá un juego muy largo, a menos que sea multicarga ... o que no hagan crecer más el mapa.

Algunos apuntes de esa web:

To make this game doable, we need to keep things as simple as possible.

(...)


3. Technical specifications. Obviously its a 128K game, but also we need to know how much memory resources we can spend on each element of the game. eg. game code, bosses, graphics, level data, puzzles, items, quests, text/dialog, music/sound effects.

Multi-loaders are okay if the game breaks down into distinct story chapters, but without a disk system, ideally the whole thing should fit into 128K of memory (which is tough - I was designing for the Spectrum SE which has twice that amount). And that means data compression is essential. I'd go with Bit-Buster extreme. Unless you want things to get comlpicated you've also got to fit everything into a tile-set of 256 tiles or less. Walking around the map is easy enough. I got stuck trying to figure out the line of sight stuff that blocks out tiles you shouldn't be able to see (like when you stand behind a wall).

En fin, lo dicho: que tienen que usar 128K, reducir todo lo posible, o hacer multicargas...

[TrueVideo]

Unas cosas sobre el mapeado...

Los cálculos que ha hecho Santi son correctos, pero tremendamente conservadores y para nada realistas. Si bien es cierto que una pantalla completa codificada con bloques de 16x16 ocuparía 16x12=192 bytes, hay que decir que esta no es la mejor forma de construir un mapeado.

Tomemos como ejemplo el mapa de Zelda que se ha mencionado. No hay más que echar un vistazo al mapa original para darse cuenta de que no hay necesidad de codificar uno por uno cada bloque independientemente. Enseguida vemos que la estructura de todas las pantallas está basada en un único bloque "de fondo", por ejemplo las rocas, que se utiliza para delimitar la escena. Cuando aparece p.e. una roca en pantalla, esta es única (con la excepción de las esquinas y rebordes, que presentan variaciones). Sospechoso. Del mismo modo las zonas transitables son áreas que repiten siempre el mismo patrón. Sospechoso también. Por último tenemos otros detalles decorativos que no parecen obedecer a ningún patrón concreto.

Cómo se construye esto? Considerad por ejemplo cada una de esas pantallas simplemente como un fondo predeterminado e invariable (rocas, árboles...) al que se le extraen los huecos correspondientes para construir caminos, etc.. A su vez estos huecos son en realidad combinaciones de unos pocos patrones -fácilmente reconocibles estudiando el mapa- los cuales se incorporan a cada pantalla simplemente con un par de coordenadas y un identificador. De esta forma pueden reutilizarse una y otra vez en diferentes pantallas, o superponerse en la misma para crear nuevos caminos, claros... y siempre con el coste mínimo. Por último los elementos individuales como tumbas y escaleras se codifican uno por uno de forma convencional mediante coordenadas e identificadores.

Resultado: cada una de esas pantallas puede codificarse con muy pocos bytes. Me atrevería a aventurar que algunas necesitan como mucho media docena, ya que con este método el tamaño no es fijo sino que depende de la complejidad de cada escena. Exactamente lo mismo para las mazmorras.

No era mi intención raptar el hilo para convertirlo en una discusión sobre técnicas de mapeado (aunque estaré encantado de comentar las diferentes opciones con quien le interese el tema). Sólo intento demostrar que no hay nada que se haya hecho en una consola de 8 bits que no pueda reproducirse en Spectrum, salvando por supuesto las diferencias técnicas obvias.

Para acabar, un poco de trivia.. No es aplicable al caso que comentamos, pero hace poco leí en RetroGamer que el programador de Pitfall para 2600 codificó 254 pantallas diferentes con sólo 50 bytes utilizando un polinomio. Creo que es un precioso ejemplo de cómo la necesidad agudiza el ingenio.

J

[TrueVideo]

...

Por cierto, se me olvidaba aclarar que el Zelda original de NES es un cartucho de 1Mbit -> 128K.

[sromero]

TrueVideo: hombre, claro, está claro que hay montones de trucos para evitar eso.

Otra posibilidad asumiendo un fondo fijo es, si existen gran cantidad de huecos de fondo "consecutivos", codificar las partes del fondo con RLE, en plan:


tile1, tile2, fondo, fondo, fondo, fondo, fondo, roca, roca, fondo, fondo, fondo, roca

como

tile1, tile2, 192+5, roca, roca, 192+3, roca

Eso implicaría no poder usar más de 192 tiles, pero en tu mapa tendrías definidos todos los fondos como "valores > 192" consecutivos.

Formas hay muchas, pero, vamos, que no es tan trivial como se pretende plantear y que no hay "tanta" memoria como parece.

saludos!

[sromero]

No era mi intención raptar el hilo para convertirlo en una discusión sobre técnicas de mapeado (aunque estaré encantado de comentar las diferentes opciones con quien le interese el tema).

Pues para eso son precisamente los foros, para que salgan discusiones atractivas, y lo que planteas me parece sumamente interesante.

¿Por qué no planteas un hilo sobre técnicas de mapeado en este subforo? Podemos ir aportando todos ideas, algo en plan "Ideas para almacenar mapas en Spectrum", y vamos aportando trucos y maneras diferentes de un mapa raw[ancho*alto] para ahorrar memoria...

Un saludo

[na_th_an]

En realidad os estáis obcecando con los mapas y creo que lo que más ocupa de un juego de estos son los textos y, sobre todo, el script que gobierna todas las comprobaciones que hay que hacer y que lleva el flow del juego.

También, el que el cartucho del Zelda sea de 128K no significa que en un Spectrum 128K pudiera hacerse igual por varios motivos:

1.- Sólo puedes paginar los 16K superiores, lo cual es una limitación bastante bestia. O te quiebras mucho la cabeza, o sólo puedes tener todo el código "gordo", "core" o "motor" en los 16K que van desde $8000 a $BFFF e ir paginando de $C000 a $FFFF lo que te vaya haciendo falta. En la NES hay limitaciones parecidas, pero el sistema es mucho más flexible.

2.- Todo el tema gráfico en la NES está solucionado por hardware. No hay que crear rutinas para mover sprites, ni para hacer el efecto flip-screen, ni para dibujar los fondos, ni para nada. Un montón de código que te ahorras, ya que no hace falta ni siquiera prerrotar los gráficos o dejar espacio para hacerlo en tiempo real: de eso se encarga el hardware.

Zelda de NES podría portarse a Spectrum con muchos recortes. Vale, es posible. Pero cuando hablaba de "típico juego Action RPG de GB" tenía en mente algo con la complejidad típica de un juego de GB de principios de los 90, no la del Zelda de NES que es mucho más sencillo y limitado que dichos juegos, por ejemplo los Pokemon, cuyos escenarios no tienen esa repetitividad y donde hay mucha variedad de ambientes y situaciones, además de infinidad de personajes y miles de lineas de diálogo.

[TrueVideo]

También, el que el cartucho del Zelda sea de 128K no significa que en un Spectrum 128K pudiera hacerse igual por varios motivos: (..)

Totalmente cierto. Las 128K de un Spectrum no son comparables a las 128K de un cartucho. Diferente grado de flexibilidad, la RAM se cuenta aparte, está el tema del hardware dedicado.. sólo mencionaba lo de la capacidad del cartucho para poder hacernos una idea aproximada de lo que estamos hablando. La diferencia no es de "muchos megabits", sino que tenemos prácticamente la misma capacidad en las dos máquinas. Cierto que en términos netos la de un Spectrum es inferior, pero no tanto, y ni siquiera en todos los aspectos. Por poner un ejemplo: el tamaño que ocupan los gráficos es bastante menor en Spectrum gracias a que la información de color se codifica por atributos. Sistemas diferentes, formas de medir diferentes.

Zelda de NES podría portarse a Spectrum con muchos recortes. Vale, es posible. Pero cuando hablaba de "típico juego Action RPG de GB" tenía en mente algo con la complejidad típica de un juego de GB de principios de los 90, no la del Zelda de NES que es mucho más sencillo y limitado que dichos juegos, por ejemplo los Pokemon, cuyos escenarios no tienen esa repetitividad y donde hay mucha variedad de ambientes y situaciones, además de infinidad de personajes y miles de lineas de diálogo.

A mi me gusta el ejemplo de Zelda para NES porque nos viene como anillo al dedo. De hecho creo que ya lo había mencionado antes en el famoso hilo de hardware. Sin embargo no lo hice porque sea precisamente un juego con grandes alardes técnicos. Todo lo contrario, se podría decir que es un juego visualmente austero. No hay nada que no se pueda hacer (o que no se haya hecho ya) en Spectrum. No tiene la variedad de ambientes, infinidad de personajes ni mucho menos las miles de lineas de diálogo de los RPG de 16 bits. La verdad es que no recuerdo que haya una sola línea.. Y sin embargo es una obra maestra.

Pongo como ejemplo este juego (o muchos otros de NES) porque nos puede enseñar cosas importantes que obviamos en nuestros juegos y que no tienen nada que ver con la técnica o la capacidad de la máquina: contar una historia sin necesidad de explicar nada, inmersión, la sensación indescriptible de estar descubriendo cosas aunque los escenarios se construyan siempre con la misma roca y el mismo árbol. Cómo lo consiguen? Hay que buscar respuestas a esa pregunta. Estas respuestas se pueden buscar en cualquier juego de cualquier época, pero no hemos de olvidar que al final los resultados se plasmarán en una máquina humilde como el Spectrum. O la NES.

(...)

Lo del mapeado ha sido un paréntesis más que un obcecamiento. El método que se discutía no me parecía en absoluto adecuado y me ha parecido buen momento para bombardear a la audiencia con alternativas. Sólo este tema podría llenar un foro entero!

J

[TrueVideo]

TrueVideo: hombre, claro, está claro que hay montones de trucos para evitar eso.

Otra posibilidad asumiendo un fondo fijo es, si existen gran cantidad de huecos de fondo "consecutivos", codificar las partes del fondo con RLE, en plan:


tile1, tile2, fondo, fondo, fondo, fondo, fondo, roca, roca, fondo, fondo, fondo, roca

como

tile1, tile2, 192+5, roca, roca, 192+3, roca

Eso implicaría no poder usar más de 192 tiles, pero en tu mapa tendrías definidos todos los fondos como "valores > 192" consecutivos.

Formas hay muchas, pero, vamos, que no es tan trivial como se pretende plantear y que no hay "tanta" memoria como parece.

saludos!

El mapeado no es el principal problema por lo que respecta a las limitaciones de memoria, siempre y cuando se escoja un método de codificación adecuado como el que he esbozado antes. El tamaño de los gráficos sin embargo sí que es un problema cuando buscamos variedad (precisamente lo que Zelda de NES no tiene), pero incluso para los gráficos hay alternativas muy eficientes sin necesidad de recurrir a la compresión.

J

[sromero]

TrueVideo: estoy de acuerdo en todo lo que comentas.

Si te animas, sería muy instructivo lo que te comentaba, el crear un hilo en este subforo de Nuevos desarrollos donde discutir técnicas de mapeado u otros aspectos videojueguiles.

Podría ser un hilo interesante, y si lo iniciaras con tus ideas o apreciaciones (por ejemplo, como lo que has comentado del mapeado del Zelda y los "caminos pregrabados en algún formato"), podría saber un debate muy chulo y un hilo para guardar.

[TrueVideo]

Si te animas, sería muy instructivo lo que te comentaba, el crear un hilo en este subforo de Nuevos desarrollos donde discutir técnicas de mapeado u otros aspectos videojueguiles.

Podría ser un hilo interesante, y si lo iniciaras con tus ideas o apreciaciones (por ejemplo, como lo que has comentado del mapeado del Zelda y los "caminos pregrabados en algún formato"), podría saber un debate muy chulo y un hilo para guardar.

Me parece bien. En cuanto tenga algo de tiempo abriré un hilo para proponer de forma detallada un método alternativo de mapeado. Siempre y cuando haya gente interesada, claro.

J

[Benway]

Me parece bien. En cuanto tenga algo de tiempo abriré un hilo para proponer de forma detallada un método alternativo de mapeado. Siempre y cuando haya gente interesada, claro.

J

Apúntame entre los interesados y agradecidos lectores!

[zxbruno]

Me gustaría mucho poder ver la finalización de los proyectos que se quedaron incompletos. Animo a todos los que tienen el conocimiento para hacer tal cosa. Hace un par de semanas visité aquella página que muestra gráficos para Castlevania ZX y otros, y la verdad es que me da tristeza al saber que nunca se terminó. Pero tengo esperanza.

[Benway]

Eso, contar una historia, es algo que se puede hacer perfectamente en el Spectrum. Que te cuenten (vía texto, o imágenes) algo al principio del juego, y que conforme vas derrotando bosses o cambiando de mapas te completen esa historia, es un añadido que puede dar un punto extra a lo que es el juego. Eso no depende, como dices, ni de bits, ni de Mhz, tan sólo es una cosa que ahora es "estándar" pero antes, en tiempos del Spectrum, no lo era. Y se lo podemos agregar a los juegos, que cuenten algo, sin problemas.

Esta mañana, pensando en esto... me vino a la mente el Jumping Jack y su poema que se iba componiendo al ir pasando niveles