...No me considero un buen programador... Incluso diría que me debería dar vergüenza escribir sobre ésto, teniendo en el equipo a gente tan preparada... ;P pero intentaré dar mi visión... que de eso se trata... Aunque consensuada con el resto del equipo para no "cagarla" tanto... ;P

  Mi experiencia en programación se basa en programar tres videojuegos... A saber: Karnak's Temple ( desde softpedia ), Bugs! ( desde RemakesZone ) y Sir Fred Remake ( desde CEZ )... Algo de publicidad no va mal... Y lo que pretendo con esta entrada no es mas que aclarar un poco las ideas a alguien que tiene curiosidad por saber cómo demonios funciona la estructura de un programa que pretende ser un videojuego ( ... lo interesante no es sólo pretenderlo... pero bueno... ;P )...Todo esto a raiz de unas preguntas que me han hecho hace poco en mi trabajo... Un compañero con algo de curiosidad me recordó a mi mismo en una época ya lejana... bla, bla, bla... jur jur jur... Que viejo estoy...   

Bueno... A lo que voy: ¿Cómo es la estructura de un videojuego?...

   No es que me haya olvidado de qué lenguaje, bla, bla, bla... no... básicamente en todos los lenguajes es lo mismo... Tanto secuenciales como orientados a objeto... ( estoy muy anticuado, aviso... ). Es mas, en mis videojuegos programados con lenguajes secuenciales, siempre he enfocado el desarrollo intentando utilizar la filosofía del OO... Vaya... Podría haber utilizado un lenguaje OO... si... pero no lo hice. ( en esta frase se puede sintetizar la personalidad del autor... íntegro, profesional, en fin... un crack... XP )

  Obviando esto:

   Bueno 2... A lo que voy: ¿Cómo es la estructura de un videojuego?...

 Básicamente hay fases que dependerán del tipo de videojuego... plataformas, de naves, aventura... No todos tienen exactamente la misma estructura, pero casi... Veamos:

intro

 do

menu

mientras ( no fin_partida && no fin_juego ) do

juego

endmientras

mientras ( no fin_juego )

  Ya está... Ya tenemos un videojuego... 

  Ejem... Vale... Profundicemos... Que no me he enterado de la mitad... ;P

  Cada una de las diferentes fases intermedias ( intro, menu y juego ) se basan en una estructura de varios niveles... Y creo que se puede sintetizar  para utilizar la misma estructura, ya sea para el menu principal, la intro o el propio juego... Veamos cual es esa estructura genérica:  

/* INICIO CODIGO */

Carga de recursos globales

bucle de seleccion por pantalla

carga de recursos e inicializacion por pantalla 

bucle de actualización de pantalla

entrada de usuario

actualizacion de objetos dependiente de la pantalla

render de objetos dependiente de la pantalla

fin bucle

Liberación de recursos locales.

fin bucle

/* FIN CODIGO */

  Bueno... mejor... pero aún así, podríamos seguir profundizando... 

/* INICIO CODIGO */

Carga de recursos globales

/* Bucle principal en el que estaremos inmersos hasta finalizar la fase ( intro, menu o juego ) */

bucle de seleccion por num_pantalla

/* Carga e inicializacion de la pantalla */

pantalla = cargar(num_pantalla)

/* Bucle principal en el que estaremos inmersos hasta finalizar la pantalla */

bucle de actualización de pantalla

/* Recoger la entrada del usuario */

entrada de usuario

/* Actualización de objetos */

actualizar(pantalla)

/* Render de objetos */

dibujar(pantalla)

fin bucle

Liberación de recursos locales.

fin bucle

/* FIN CODIGO */

  Vayamos por partes:

    1. ¿Qué leches es esto?:

 /* Carga e inicializacion de la pantalla */

pantalla = cargar(num_pantalla)

  Vale... "pantalla" podría ser un objeto... Podría ser también un tipo de objeto en lenguajes secuenciales... De cualquier forma, es un objeto que se inicializa ( via método o función )... y en su inicialización cargaremos los recursos que necesite esa pantalla...

  Imaginaos un metodo constructor ( en POO ) que, dependiendo de la pantalla que se nos pase por parámetro, inicialice un array de objetos instanciables, llamese  soldados, farolas o ranas... ¿Si?... vale... eso es harina de otro costal... Ya llegaremos mas adelante. De momento, tened claro que pantalla es un contenedor de objetos que dependerán del numero de pantalla que le pasemos... ( no es lo mismo la primera pantalla de nuestro juego, en la que hay pájaros asesinos volando... que la segunda... que ocurre en un pantano lleno de cocodrilos... No es lo mismo, no... ;P )

   2. ¿Qué leches es esto otro?:

/* Recoger la entrada del usuario */

entrada de usuario

  Vale... Este es fácil... se ira recogiendo la entrada de usuario ( ya se un numero para el menu... Un click de ratón... no sé... lo que sea... ) y la irá poniendo, por ejemplo, en variables globales que representan flags de pulsación... Por ejemplo, tecla_derecha contiene TRUE si se ha pulsado el cursor derecho...

  3. ¿Qué leches es esto además?:

 /* Actualización de objetos */

actualizar(pantalla)

  Vale... Si pantalla es un objeto, se llamará a su método de actualización que recorrerá ese array de objetos que se han instanciado dependiendo de la pantalla en la que estemos, llamando a cada uno de los métodos de esos objetos ( farola, rana, cocodrilo o pájaro )...  En esta fase se actualiza todo lo necesario: Posiciones x e y de los objetos... scroll, no sé... cualquier cosa que imaginéis que se ha de actualizar a cada frame del juego, va aquí...

  4. ¿Y ésto?:

/* Render de objetos */

dibujar(pantalla)  

  Vale... Por último... Como antes: Si pantalla es un objeto, se llama a su método de pintado... que a parte de pintar la propia pantalla... se recorre de nuevo ese array de objetos dependientes de la pantalla y llama a sus métodos de pintado... Aqui se controla quien se pinta antes, para tener en cuenta la coordenada Z... por ejemplo... 

  Así... Si sustituimos el código anterior en el primer modelo tendremos el esqueleto de un videojuego... Observamos la parte sombreada... Se han de cargar los recursos antes del bucle de la parte de "juego":

  /* INICIO CODIGO */

  /* INICIO INTRO */

  Carga de recursos globales intro

  /* Bucle principal en el que estaremos inmersos hasta finalizar la fase ( intro ) */

  bucle de seleccion por pantalla_intro

    /* Carga e inicializacion de la pantalla_intro */

    pantalla_intro = cargar_intro(num_pantalla_intro)

    /* Bucle principal en el que estaremos inmersos hasta finalizar la pantalla_intro */

    bucle de actualización de pantalla_intro

      /* Recoger la entrada del usuario */

      entrada de usuario

      /* Actualización de objetos */

      actualizar_intro(pantalla_intro)

      /* Render de objetos */

      pintar_intro(pantalla_intro)

    fin bucle

    Liberación de recursos locales.

  fin bucle

  /* FIN INTRO */

  do

    /* INICIO MENU */

    Carga de recursos globales menu

    /* Bucle principal en el que estaremos inmersos hasta finalizar la fase ( menu) */

    bucle de seleccion por pantalla_menu

      /* Carga e inicializacion de la pantalla_menu */

      pantalla_menu = cargar_menu(num_pantalla_menu)

      /* Bucle principal en el que estaremos inmersos hasta finalizar la pantalla_menu */

      bucle de actualización de pantalla_menu

        /* Recoger la entrada del usuario */

        entrada de usuario

        /* Actualización de objetos */

        actualizar_menu(pantalla_menu)

        /* Render de objetos */

        pintar_menu(pantalla_menu)

      fin bucle

      Liberación de recursos locales.

    fin bucle

    Liberacion de recursos globales menu

    /* FIN MENU */

    /* INICIO JUEGO */

    Carga de recursos globales juego 

    mientras ( no fin_partida && no fin_juego ) do

      /* Bucle principal en el que estaremos inmersos hasta finalizar la fase ( juego ) */

      bucle de seleccion por pantalla_juego

        /* Carga e inicializacion de la pantalla_juego*/

        pantalla_juego = cargar_juego(num_pantalla_juego)

        /* Bucle principal en el que estaremos inmersos hasta finalizar la pantalla_juego */

        bucle de actualización de pantalla_juego

          /* Recoger la entrada del usuario */

          entrada de usuario 

          /* Actualización de objetos */

          actualizar_juego(pantalla_juego)

          /* Render de objetos */

          pintar_juego(pantalla_juego)

        fin bucle

        Liberación de recursos locales.

      fin bucle

    endmientras

    Liberacion de recursos globales juego

    /* FIN JUEGO */

  mientras ( no fin_juego )

  /* FIN CODIGO */

   Y voilà, ahora sí... ya está... Ya tenemos un videojuego...  Os recomiento que peguéis el código en un wordpad... y lo estudieis un poco... es muy simple, pero se ha de estar familiarizado...

  Otro tema es como inicializar los objetos... cargar los recursos, etc... También tengo un truquillo para la actualización de los objetos... mmm... Pero me parece que eso lo podríamos ver en el siguiente articulo... 

  Hasta la próxima!... ;P 

Esperando el siguiente capítulo :)

Lo bueno es que de la forma que lo estás planteando sirve para cualquier sistema, antiguo o moderno. Así que seguro me será útil para C64.

Buena idea la de esta nueva sección, pero de este modo tendréis menos tiempo para dedicar a "la abadia" :(

Asi que ahora mismo me voy a criogenizar y cuando esté el juego disponible me despertáis. Tenedme preparado un colacao con galletas. :D

Vamos que no es, "botón derecho" --> "Crear videojuego" ;)
Ahora en serio, para mi, programar un videojuego me parece una obra mastodóntica. Eso sí el placer de verlo terminado y funcionando tal y como quieres y haber resuelto mil y un problemas antes eso no tiene precio.
Seguid así.

Ahora entiendo porqué a mis tiernos 12 añitos tuve que abandonar mi idea de programar una vuelta ciclista en el Spectrum 48.
"4 equipos de 6 corredores representados por barritas de 8 pixeles de ancho que se iban llenando con tiradas de dados y que se hacían más anchas o estrechas según el terreno era de ascenso y descenso, miles de hojas cuadriculadas tieradas a la basura, clasificaciones que nunca llegaron a funcionar, etc, etc." y yo sin saber que esto era tan complicado. Ahinss

Para colmo dos de Dinamic sacaron el juego ese de Pedro Delgado y me hicieron polvo la moral porque fué un éxito y para mi era mucho peor que lo que había tenido en mente y ademas era con un solo corredor, eso si, tenía gráficos del ciclista corriendo y todo y claro eso tiene mucho tirón.

Queremos la 2º parte!! :)

Podríais poner alguna sección para los no iniciados,explicando un poco el funcionamiento de algunos programas para hacer videojuegos,y vuestra valoración de los pros y contras(game maker,rpg maker,etc..),y algún detalle que a los programadores se les haya olvidado mencionar(con el que algunos novatos se puedan quedar atascados..como poner imágenes de animaciónes de sprites),trucos,etc..Muy buena la sección,seguid así!:)

¿Como se hace para asignar teclas a las acciones?Ej:las flechas al movimiento,z recojer objeto,etc;combinar el teclado con el raton..por ejemplo para hacer un Bowman/plataformas o arcade..

Hola Arkume,

Normalmente, lo que se hace para el tema de los controles es (como dice LordFred) en cada pasada del bucle leer la entrada del usuario. El cómo hacerlo depende de varias cosas, desde la máquina para la que se hace el juego a el lenguaje o las bibliotecas que usas para programarlos.

Por ejemplo, si usas una biblioteca como SDL, independientemente de si estás haciendo un juego para PC, Mac, Wii, o lo que sea, siempre se lee la entrada (teclado o joystick) de la misma manera.

En cuanto a asignar teclas a acciones, el diseñador del juego define las acciones que se pueden hacer en el juego, y cómo las realizará el jugador. A nivel abstracto. Durante el desarrollo se definen las teclas que se usarán para cada una de esas acciones por defecto (o las secuencias de pulsaciones) y opcionalmente se puede programar que el usuario pueda redefinir esas teclas.

Las teclas a comprobar se guardan en memoria, y cuando, en cada pasada del bucle, el juego lee el estado del teclado comprueba únicamente las teclas (o pulsaciones de pad o de joystick) que le interesan en función de lo que ha diseñado que puede hacer el jugador.