¿Cómo almacenan los videojuegos información fuera de pantalla?

Estoy tratando de hacer un videojuego desde cero, pero realmente soy nuevo en esto y sigo teniendo problemas básicos. Lo más importante, ¿cómo almacenan los videojuegos información fuera de pantalla? Lo que quiero decir es, ¿cómo sabe el programa qué mostrar a continuación en la pantalla? O incluso, si el jugador cambia el entorno, ¿cómo permanece este cambio la próxima vez que se cargue en la pantalla?

Por ejemplo, en New Super Mario Bros, si golpeas un? bloquear y luego salir de la pantalla, y volver, todavía sigue siendo golpeado. ¿Cómo se guarda y ejecuta esta información la próxima vez que el jugador carga el bloque? ¿Por qué no solo se reinicia?

Por lo general, debe separar el estado lógico de su entorno de juego de la representación visual.

Es posible que el jugador solo vea una pequeña parte en su pantalla, pero aún conserva el estado de todo el nivel en la memoria y, por lo general, también calcula la mecánica del juego para todo el nivel. Cuando su mundo es tan grande que esto requeriría demasiada memoria RAM y / o CPU, puede suspender áreas más alejadas del disco duro.

Su subrutina de representación verifica qué partes del nivel están actualmente en la pantalla y luego solo las dibuja. Lo que está fuera de la pantalla no se dibuja, pero eso no significa que no esté actualizado.

Lo estás haciendo al revés.

Comienzas con el estado lógico de tu juego y lo modelas. Es casi seguro que todo el estado lógico del mundo será demasiado para guardarlo en la memoria a la vez, por lo que lo desglosará en partes más pequeñas que se pueden cargar y guardar de forma independiente. Estas partes a menudo se denominan trozos . Estos fragmentos pueden formar un mundo continuo, pero también pueden ser niveles / instancias separadas. La terminología varía enormemente según el género y la técnica que desea utilizar.

Luego carga las partes que son de interés, es decir, trozos que están cerca del jugador. Los fragmentos que están demasiado lejos se guardan en el disco / almacenamiento permanente y se descargan de la memoria.

Y luego, como último paso, usted determina qué es realmente visible y crea la representación visual del estado actual del juego y lo muestra en la pantalla.

Por supuesto, intentaría no reconstruir toda la representación visual cada vez, sino almacenarla en caché y reutilizarla si tiene partes que ya están construidas, pero ese es el principio principal.

Esto es válido para cualquier programa que tenga salida. Si escribe un programa con una GUI normal, como un editor de texto, probablemente modele el documento, y luego la GUI determinará el estado y las partes visibles del documento y lo mostrará en la pantalla. O rellene los campos del formulario de forma adecuada, o bien.

La esencia principal es: piense dónde y cómo almacena primero los datos (probablemente junto con cómo representarlos). Casi todos los programas tienen que lidiar con el almacenamiento de datos. Solo hay muy pocos casos en los que no almacena ningún dato.

Como otros han dicho, mantienes un mapa (por ejemplo, en una matriz) y dibujas la parte visible en la pantalla, y no lees desde la pantalla.

Pero en algunos sistemas más antiguos, literalmente, mantendría los datos fuera de pantalla. Habría, digamos, 400x300 píxeles de memoria de video para una pantalla de 320x200, y definiría una ventana gráfica en eso ("comenzar en X = 10 Y = 30"). Para que pueda desplazarse por la pantalla simplemente ajustando un registro. No tendría que gastar los cien mil ciclos necesarios para mover los bytes, simplemente cambie el lugar donde el hardware de video comienza a leerlos.

El NES tiene esto, combinado con un sistema basado en mosaicos: http://wiki.nesdev.com/w/index.php/PPU_scrolling

El NES nunca construye la imagen completa en la memoria, porque no tiene suficiente RAM. En cambio, hay una matriz de RAM que define un conjunto de mosaicos de dos pantallas. Un byte por tipo de azulejo. El hardware de video busca el mosaico y las coordenadas de desplazamiento X / Y para decidir qué píxel debe aparecer en cualquier punto.

Bueno, si haces este tipo de preguntas, tendrás un largo camino para llegar al punto en el que puedas hacer un juego. Pero, llegando al meollo de su pregunta, el programa puede guardar el estado de muchas cosas diferentes en variables que se encuentran en la parte posterior de su programa. Veamos un par de ejemplos.

Mario Brothers (o similar) guarda el estado del nivel en el que se encuentra. Eso podría incluir qué tan lejos ha llegado antes de morir, si se golpeó un bloque o no. En un sentido más orientado a objetos, el juego solo dice "sé un bloque aquí" y el bloque existe. luego, cuando golpeas el bloque, el bloque cambia su propio estado interno para decir "Fui golpeado". Datos como ese pueden almacenarse de varias maneras.

Su procesador de textos guarda sus datos en una estructura de datos. Ahora hay muchas de estas y muchas formas en que se pueden implementar, pero probablemente usa alguna forma de árbol. En un árbol tienes al menos un nodo. Cualquier cosa agregada antes de ir a la izquierda. Cualquier cosa agregada después, va a la derecha. Después de agregar tres nodos, tiene dos de ellos colgando del nodo central. Y el árbol puede crecer aún más con nuevas piezas que se agregan en cualquier lugar y el árbol se reconstruirá solo. O piensa en juegos de disparos donde tu enemigo deambula. Cada uno de ellos tiene variables que rastrean su ubicación, vida, etc., de modo que cuando hiere uno, recordará que fue herido.

Todas estas cosas requieren un conocimiento de las estructuras de datos. Va mucho más allá de lo que ves en la pantalla. Sugeriría leer sobre matrices, listas, hashes (a veces llamados diccionarios o mapas) y luego volver a su problema.

Aquí hay algunos buenos materiales de partida:

• http://visualgo.net/

Hasta cierto punto, esta es una función de cómo se representa el 3D. Por ejemplo, OpenGL eliminará automáticamente la geometría fuera del rango -1.0, +1.0 en el espacio de la pantalla XY (Z es más complejo pero similar). La geometría seleccionada nunca genera fragmentos (aproximadamente píxeles) y, por lo tanto, nunca se convierte en imágenes reales, a pesar de ser enviada al sistema para renderizar. En cualquier caso, es imposible escribir en el espacio fuera de la ventana de renderizado (si todo funciona como debería).

En algunos contextos, es suficiente confiar en este comportamiento como una optimización. Sin embargo, aún debe pasar todos los datos de su juego a través de al menos una etapa de representación (sombreadores de vértices) antes de que la tarjeta de video pueda saber qué es visible. En algo como, digamos, Skyrim, eso sería poco práctico. No solo tiene que enviar todos los vértices del mundo a través de la canalización de renderizado, sino que debe cargar cada vértice en la memoria del sistema / video. Eso es ineficiente, si es posible.

Por lo tanto, muchos juegos utilizarán el sacrificio basado en CPU. Por lo general, implementarán algún tipo de sistema LOD (nivel de detalle), donde la calidad y la existencia de los activos se ven afectados por la importancia que tienen en un contexto determinado. Una malla piramidal podría ser una aproximación aceptable para una montaña si estás a 50 millas de distancia. Si no puede verlo en absoluto (como si estuviera bloqueado por otras montañas), ni siquiera es necesario cargarlo. Hay varios métodos más complejos para hacer esto que son temas que no creo que sean directamente relevantes para la profundidad solicitada por esta pregunta, pero mire la teselación para uno de los ejemplos más comunes.

La verdadera esencia de esto es que las imágenes son solo el producto del juego. Los datos reales no tienen nada que ver directamente con lo que está viendo o no ve la mayor parte del tiempo, y los datos se filtran por varias etapas para eliminar información extraña antes de llegar al punto donde se escribe una imagen en la pantalla. Dependiendo del diseño del motor, los elementos visuales pueden estar extremadamente desacoplados de la lógica real del juego, en la medida en que sea posible tener una interfaz 2D y 3D para el mismo juego. Incluso es posible que muchos motores de juego funcionen sin salida alguna; a veces esto se usa para probar la IA del juego.

Sin embargo, ahí es donde las cosas pueden complicarse. En algo simple como un juego de Mario, no es demasiado prohibitivo calcular el movimiento de todos los enemigos en el nivel, incluso si no son visibles. En contextos modernos, lo que sucede fuera de la pantalla es una cuestión real de seria consideración. Si hay varias ciudades enteras de NPC, ¿cómo manejas cómo se comportan cuando son eliminados por completo, como cuando el jugador está en una ciudad diferente? ¿Realmente quieres calcular cientos de decisiones de NPC en todo el mapa? La respuesta generalmente es no, pero el enfoque exacto para lograr no hacerlo puede variar, y puede tener algunos impactos en el juego.

Es importante tener en cuenta que así es como funcionan las cosas ahora . Los viejos juegos de Mario probablemente fueron programados de maneras muy diferentes (no puedo hablar de las formas exactas), dadas las limitaciones extremas de hardware en ese momento. El concepto de 3D no existía en aquel entonces; Sin embargo, hoy en día, casi todos los juegos, incluso los que son completamente 2D, utilizan la representación 3D de alguna forma, incluso si no saben que lo hacen. El hardware de video moderno es primero en 3D, y la representación en 2D (al menos cuando hace uso del hardware correctamente) simplemente ignora la tercera dimensión.

Para responder a su pregunta: los videojuegos mantienen el estado del mundo del juego en una estructura de datos abstracta que no tiene nada que ver con la pantalla. Esto se muestra en la pantalla según sea necesario (es decir, dependiendo de dónde se encuentre el jugador).

Los juegos que usan la RAM de video directamente para fines estatales existían en los años 80 en los 8 bits, tal vez incluso en la era de los 16 bits, pero a menos que esté desarrollando para esa plataforma o para algunos µC que en su lugar confinan su RAM en KB de GB, olvídalo.

Dicho esto, pareces ser muy nuevo en todo lo relacionado con la programación, o la pregunta no habría surgido. Sugiero ir paso a paso, programando cosas muy fáciles primero; tal vez algo que solo tenga entrada / salida textual (indicaciones simples y todo eso). Para ser sincero, el momento en que lo hice fue hace unos 30 años, por lo que no tengo recursos realmente buenos para usted, pero su biblioteca local podría ser mejor que Internet para darle un buen comienzo en la programación.