¿Cómo almacenarías el nivel del juego para un juego de aventura Dizzy-like? ¿Cómo especificaría áreas y gráficos que se puedan recorrer? ¿Las superficies basadas en mosaicos, basadas en píxeles o caminables pueden describirse por vectores?Representación del nivel del juego Dizzy-like (formato)
Los juegos de aventuras muy antiguos (como las misiones de Sierra de los 80) solían mantener un mapa de bits separado de la pantalla completa que representaba z profundidad y materiales para determinar dónde podría ir su personaje y dónde estaría oculto. Utilizarían el muestreo de píxeles para comprobar dónde irían sus pequeños sprites.
Aunque las máquinas actuales son más rápidas, los largos niveles de desplazamiento lateral hacen que este tipo de enfoque sea poco práctico, en mi humilde opinión. Tienes que ir con representaciones más dispersas.
Una opción es "reducir" el juego en fichas invisibles, que son más fáciles de representar. El problema principal con esto es que puede restringir el diseño (por ejemplo, plataformas diagonales difíciles) y puede hacer que las animaciones sean muy de mala calidad (por ejemplo, los pies de los personajes que no tocan la plataforma). Esta opción puede funcionar en mi humilde opinión para juegos de aventuras similares a Zelda, pero no para juegos de acción.
Una segunda opción es representar el mundo del juego a través de una representación vectorial e implementar alguna detección de colisión. Yo personalmente iría con la segunda solución, especialmente si puede ser inteligente acerca de cómo organiza sus estructuras de datos para minimizar el tiempo de acceso (por ejemplo, tener un acceso más rápido a un subconjunto de elementos del mundo cerca de la posición actual de sus personajes).
No me sorprendería si hay motores de juegos 2D disponibles que ofrecen este tipo de capacidad, ya que definitivamente hay motores 3D que lo hacen. De hecho, puede que le resulte más fácil usar un motor de juego 3D existente y usarlo para representar 2D.
El juego Dizzy probablemente esté usando un sistema basado en fichas. El mundo del juego se compone de una paleta de fichas que se repiten a lo largo del nivel. Cada mosaico tendría tres elementos: la imagen dibujada en la pantalla, el z-buffer para permitir que el personaje principal camine detrás de partes de la imagen y un mapa de colisión. Los dos últimos se implementarían como imágenes monocromas tal que:
colour | z map | collision
-------|--------------------|---------------
black | draw dizzy infront | collide
white | draw dizzy behind | don't collide
el almacenamiento de estos son las imágenes monocromas a ahorrar una gran cantidad de memoria RAM también.
Tendría un editor para construir el nivel que mostraría una cuadrícula donde los mosaicos se pueden arrastrar y soltar.
Ese juego específico es un juego basado en fichas, con una colisión perfecta de píxeles. La colisión fue controlada por un solo bit en el byte de color de la ficha (el brillo) y también podría reflejar la ficha configurando el bit intermitente del color.
Los azulejos, sin embargo, sólo podía ser colocado en incluso coordenadas x, y (Sospecho que esto se hizo para ayudar al sistema de colisiones un poco.)
El sistema de colisiones involucrados una comprobación persistente en torno al héroe. Las reglas eran más o menos: - Si encuentra una fila de píxeles sin colisión debajo del héroe, cayó al héroe en 1 píxel. - Si hay una intersección de colisión con el héroe, elevó al héroe en 1 píxel. - Al mover hacia la izquierda o hacia la derecha, se comprueba en esa dirección y si: - si encuentra una pared (altura de colisión de más de 4 píxeles), denegar el movimiento en esa dirección; - si encuentra una caja escalable (altura de colisión de hasta 4 píxeles), permita el movimiento en esa dirección. - Si hay suficiente espacio libre, permita el salto, de lo contrario, deténgase en la última posición libre posible.
Cuando se combinan estas reglas simples, se obtiene una negociación de colisión muy suave capaz de caminar incluso pendientes arbitrarias sin impuestos adicionales.
Al crear un juego así, usaría fichas individuales, las ensamblaría en capas (fondo, primer plano, etc.) y las renderizaría. Armaría un mapa de colisión separado de los atributos de los mosaicos que indican una ficha de colisión, y usaría ese mapa por separado para negociar la colisión y el movimiento del héroe.
similares a esta demo: http://games.catevaclickuri.ro/
Una alternativa para almacenar una imagen monocromática que es como una imagen de canal N, donde cada canal es el bit de información que necesita en ese píxel. P.ej. puede empaquetar visibilidad, colisión y otra información en un espacio pequeño, de modo que solo hay una búsqueda para obtener toda la información importante. –