Curso “Programación de Juegos”
Curso Gratuito con codigo fuente.
Entrega 6.
Eliminando el BUG de nuestro programa
Nuestro programa de la nota anterior no estaba completamente depurado, porque tenía un pequeño error.
Como habrá visto al correr el programa, en cada colisión, el carácter-sprite se “come” al obstáculo representado por la [X], pero resulta ser que, debido a la técnica empleada para dibujar la pantalla, cuando borramos las [X], éstas se borran de la pantalla, pero “persisten” dentro de las variables Screen$(filas) o para ser más claros, en la memoria RAM.
La consecuencia de esto es que después de limpiar la pantalla, debemos también eliminar las X de la RAM (es decir, de las variables que las contienen).
Si no lo hacemos, la rutina de detección de colisiones (que trabaja con la RAM, no con la pantalla dibujada) vuelve a detectar una colisión porque ha quedado el FANTASMA: no se ve en la pantalla pero para el programa sigue "estando" en la RAM.
Esto trae una consecuencia: si vuelve a pasar el caracter-sprite por el lugar en donde antes había una X, el programa vuelve a sumar puntos, reaccionando como si la X estuviera aún dibujada.
Algo de Teoría
Lamentablemente ahora debo hacer un paréntesis para explicarle algo. Estos conceptos deberían ser básicos para cualquier programador: ¿Qué sucede cuando creamos y asignamos una variable?
No se ofenda, pero es un hecho que muchos programadores tienen dificultades al desarrollar sus programas porque no saben (a ciencia cierta) cómo trabajan los lenguajes en la RAM. Es por eso que le explicaré en detalle lo que sucede cuando usted crea una variable, le asigna un valor y trabaja con esa variable.
Ahora veamos el primer grafico para entender esta explicación
Casi todos los lenguajes admiten más de una manera de crear o definir una variable. Mientras más estricto sea el lenguaje, menos formas de definir y asignar variables tendrá.
Cuando usted crea una variable tiene que ponerle un nombre.
Pero el nombre de una variable es un artificio del alto nivel, que hace que la vida del programador sea más sencilla. Con un nombre de variable, el programador no necesita tener en cuenta las posiciones de memoria. Porque eso es una variable: una posición de memoria que contiene datos.
El sistema (que trabaja en código máquina) no ncesita identificar una variable con un nombre, porque en realidad trabaja con los espacios de memoria RAM que pueden contener información (y que el programador identifica con el Nombre_de_la_variable).
Cuando alguien crea una variable, el sistema aparta en RAM un espacio que tendrá tantos bytes como el tipo de variable que usted esté creando:
• Una variable integer (entera o identificada como %) se guardará en 16 bits o 2 Bytes.
• Una variable long (o entero-largo o &) se almacenará en 32 bits o 4 Bytes
Todas las variables numéricas tienen una cantidad fija de Bytes para su almacenamiento. Si usted crea un array en la RAM se almacenarán tantos bytes como haya declarado en el array:
• Por ejemplo, si en el alto nivel usted declara a%(1 to 10)
• En la RAM se reservarán 20 bytes: a%(1) ocupará los bytes 1 y 2, a%(2) ocupará los bytes 3 y 4, a%(3) los bytes 5 y 6 y así hasta terminar en a%(10) que ocupará los últimos 2 bytes del espacio reservado en RAM. ¿Por qué solo 2 Bytes por elemento? Pues porque USTED declaro con el símbolo % a la variable a%() y el sistema reservará 2 bytes por elemento para ese tipo de variable.
Cada vez que usted use una etiqueta, indicando que necesita usar el valor almacenado en la variable ( por ejemplo, invoca a%(12) ), el sistema ubicará en la RAM el espacio reservado para a%(12) y leerá los datos almacenados en esos dos bytes interpretándolos como datos numéricos de entero corto. Y se los retornará o los usará según sus instrucciones.
En realidad, el programador (desde el alto nivel), no necesita usar la etiqueta para trabajar con los datos. ¿Por qué? Porque si conoce el lugar de la RAM en donde están los datos, puede leerlos directamente sin usar el nombre de la variable. Incluso puede modificarlos.
Es por ese motivo que muchos lenguajes de alto nivel le dan la posibilidad a los programadores de leer y escribir directamente en las posiciones de memoria, con la única condición de que escriba y lea en los lugares correctos para evitar un crash.
En Qbasic usted tiene las instrucciones PEEK y POKE para leer datos y escribir directamente en RAM. Para saber en que lugar de la memoria se almacenan los datos de una variable, tiene VARSEG que le indica el segmento de ram en la que se almacena y tiene VARPTR para saber su desplazamiento (alto, no se desespere, recuerde que Qbasic es PREHISTORICO…jaja y usa técnicas antiguas para manejo de RAM).
En realidad, si el lenguaje le da o no posibilidades o instrucciones para determinar la posición de RAM de los datos de una variable, no tiene mucha importancia. Hay muchas formas de leer directamente la RAM, aún cuando el lenguaje no le ayude. Pero tocar la ram directamente sin saber lo que está haciendo… es condenar al programa al crash inevitable.
En un lenguaje usted puede “leer” un contenido de esta manera:
B% = A%(12)
Y el programa hará lo siguiente: buscará en RAM los dos bytes que corresponden alos datos almacenados en a%(12), identificará la posición de memoria que almacena datos para B%, y después de eso, transferirá los datos entre las dos posiciones de memoria RAM. Es decir, llevará los dos bytes de a%(12) hasta la ram que identifica a B%.
¿Muchos pasos, verdad? Allí usted puede ver que hay un conjunto de lecturas y pasos adicionales que no hacen más que enlentecer su código, porque se podrían trasladar los datos más rapidamente haciendo un "enroque" de datos entre las dos posiciones de memoria.
Así es que una forma más eficiente de transferir esos datos sin tanta demora (o uso innecesario de ciclos de reloj de microprocesador) sería usar una instrucción de este tipo:
Poke Varptr(b%), Peek(Varptr(a%(12)))
O algo por el estilo (según el intérprete/compilador/versión de lenguaje que use).
Esta instrucción transfiere directamente datos entre dos posiciones de memoria sin tanto alboroto, interpretación o perdida de tiempo de microprocesador. El problema es que si usa mal las instrucciones, se alterarán los datos de la ram con consecuencias imprevisibles.
Algunos lenguajes, hacen justamente eso desde el alto nivel (probablemente conoce la instrucción SWAP de algunos lenguajes de alto nivel). O la instrucción SWAP de lenguajes de bajo nivel qie intercambian el byte alto con el bajo.
Lamento toda la jerga técnica de procesos obsoletos, pero creo que la idea de entender cómo se trabajan las variables en RAM es importante para un programador.
Mucho más para un programador de juegos porque a veces necesitará aumentar la velocidad de sus aplicativos. Las técnicas de acceso de datos en RAM sin pasar por el alto nivel, disparan la velocidad de los juegos.
Esto depende del lenguaje que usted esté usando, claro está. Algunos lenguajes mastodónticos son tan pesados y dependen tanto de rutinas y funciones de alto nivel que no importa lo que haga el programador, nunca tendrán buena velocidad. Sucede mucho con los que dependen de un run-time o un framework…. tienen grandes demoras en la ejecución.
Comprenderá que como programador…no me gustan los run-times, los frameworks ni los lenguajes interpretados… pienso que limitan a los programadores a los caprichos de los fabricantes de lenguajes. Microsoft es muy famoso por sus caprichos y dependiendo de sus intereses económicos, deja de actualizar entornos completos de programación.
También están los vaivenes económicos. Las empresas quiebran, cierran, o se fusionan. Muchos lenguajes prometedores dejaron de producirse por cierre o por decisiones de directorios en empresas fusionadas.
A eso me refiero cuando digo que es bueno que los programadores no hagan depender a sus proyectos de herramientas de terceros.
Un programador C++, PowerBasic, Delphi o Masm32 nunca dependerá de nadie. Si usted aprende a trabajar con un lenguaje de propósito general, nunca dependerá de rutinas de terceros. Cuando necesite algo en particular, simplemente...lo creará, lo inventará... y lo usará tantas veces como lo necesite.
Es por eso que es muy bueno (desde el punto de vista profesional) crear nuestros propios motores o engines. Y no me refiero solo a juegos, sino a aplicativos de todo tipo.
Hoy veo un gran problema en los países en desarrollo. La gran dependencia de herramientas de terceros. También se ve en la industria de juegos. Muchisimos programadores dependen de engines y sin ellos, serían incapaces de crear sus propios juegos. Hay pocos programadores básicos, con dominio completo de lenguajes de propósito general.
En fin, sigamos adelante…
Continuemos con la solución al BUG
Ahora que ya comprende como se manejan las variables en RAM, entenderá las dos posibles soluciones al BUG que propongo.
Ambas soluciones se aplican a la función GetColision%
La primer solución (la menos eficiente)
Esta solución es la menos eficiente, porque trabaja con muchas instrucciones adicionales. Pero la doy porque algunos compiladores no permiten la segunda solución propuesta.
Esta solución consiste en dividir la cadena Screen$(fila%) de la que debemos borrar la X.
Tenemos que crear dos subcadenas: una con los caracteres que están a la izquierda del valor de columna% y otra con los caracteres que están a la derecha del valor columna%
Para el trabajo, se usan variables intermedias:
DIM der$
DIM izq$
DIM LenDer%
DIM LenIzq%
LenDer% y LenIzq% son números que contienen la longitud (en caracteres) de las cadenas derecha e izquierda. Se calculan teniendo en cuenta el valor columna% que apunta a la X que debe ser borrada:
LenIzq% = columna% - 1 (un lugar a la izquierda de columna%)
LenDer% = LEN(Screen$(fila%)) - columna% (al tamaño total de Screen$(fila%) se le resta el valor de columna% y nos da el tamaño de la cadena derecha)
Una vez obtenidos estos valores, simplemente definimos las subcadenas derecha e izquierda de este modo:
izq$ = LEFT$(Screen$(fila%), LenIzq%)
der$ = RIGHT$(Screen$(fila%), LenDer%)
Y terminamos reconstruyendo la nueva cadena Screen$(fila%) asegurándonos de colocar entre las cadenas izquierda y derecha un espacio vacio que en definitiva es el que borra la X fantasmal de nuestro juego:
Screen$(fila%) = izq$ + " " + der$
Mucho trabajo ¿verdad? Pero nada puede compensar el entretenimiento de ser programador básico… jeje.
Segunda solución: la más eficiente
Esta solución implica modificar directamente el contenido de la RAM.
Para eso usaremos la instrucción MID$ que modifica directamente en RAM los bytes que contienen sus datos. Escribimos esta instrucción:
MID$(Screen$(fila%), columna%, 1) = " "
Esta orden le dice al intérprete Qbasic que modifique dentro de la variable Screen$(fila%), al carácter número columna%. Así se ordena el reemplazo de un solo caracter (eso indica el ,1), que en este caso el el byte que contiene la X a borrar, para asignarle a ese carácter un espacio vacío
Tenga en cuenta que algunos compiladores no permiten la manipulación directa en RAM a partir de funciones incorporadas, como el caso de MID$.
Pero no es el caso de Qbasic, que como puede (y podrá ver en otros capítulos), tuvo muchisima popularidad por muchisimas buenas razones técnicas (en su momento, claro, porque ahora es obsoleto).
Como puede ver, es la solución más rápida porque tiene menos instrucciones, lo que se traduce en menos tiempo de ejecución.
Conclusión
Hay otro motivo por el que incluí las dos soluciones. Muchas veces desarrollar juegos implica que hayan varios programadores involucrados y suele haber también un coordinador general que toma decisiones al respecto de ciertos temas.
En casos parecidos a este del BUG, puede ser que el programador le presente una u otra solución y el coordinador deberá tomar la decisión de qué solución será la adoptada.
A veces los programadores no proponen las mejores soluciones técnicas o las más eficientes, sino que adoptan las soluciones más portables. No siempre lo mejor desde el punto de vista técnico es lo más portable.
Escuche lo que tienen para decir sus programadores. Puede ser que le estén evitando un dolor de cabeza más adelante, cuando deba portar su proyecto a otros entornos.
Finalmente, es bueno que “lea” códigos fuentes y los re-escriba una y otra vez... Eso es lo que le aconsejo con este curso.
Re-escriba estos códigos. Equivóquese y acierte implementando otras soluciones que las propuestas. Ser programador es mucho más que leer un código y aceptar premisas porque alguien lo dice (en este caso el que escribe).
Modifique. Explore. Genere versiones mejoradas. ¿Que no puede? ¿Qué no sabe cómo? Pues… bienvenido al mundo de los programadores. Los programadores y desarrolladores somos los que vivimos en las fronteras, allí en donde se hacen cosas que nunca nadie hizo antes. Y se hacen de un modo completamente diferente al habitual.
1. Introducción
2. A quienes va dirigido el curso
3.Temario del curso / Herramientas
4.Primer programa (codigo fuente)
Servicio de consultas técnicas gratuito
Servicio Técnico en Sistemas, Redes y CiberSeguridad
Márketing en Internet y Redes Sociales
Su Aula Virtual en Internet
Su Taller en Internet
Su empresa en Internet
Curso Gratuito con codigo fuente.
Entrega 6.
Eliminando el BUG de nuestro programa
Nuestro programa de la nota anterior no estaba completamente depurado, porque tenía un pequeño error.
Como habrá visto al correr el programa, en cada colisión, el carácter-sprite se “come” al obstáculo representado por la [X], pero resulta ser que, debido a la técnica empleada para dibujar la pantalla, cuando borramos las [X], éstas se borran de la pantalla, pero “persisten” dentro de las variables Screen$(filas) o para ser más claros, en la memoria RAM.
La consecuencia de esto es que después de limpiar la pantalla, debemos también eliminar las X de la RAM (es decir, de las variables que las contienen).
Si no lo hacemos, la rutina de detección de colisiones (que trabaja con la RAM, no con la pantalla dibujada) vuelve a detectar una colisión porque ha quedado el FANTASMA: no se ve en la pantalla pero para el programa sigue "estando" en la RAM.
Esto trae una consecuencia: si vuelve a pasar el caracter-sprite por el lugar en donde antes había una X, el programa vuelve a sumar puntos, reaccionando como si la X estuviera aún dibujada.
Algo de Teoría
Lamentablemente ahora debo hacer un paréntesis para explicarle algo. Estos conceptos deberían ser básicos para cualquier programador: ¿Qué sucede cuando creamos y asignamos una variable?
No se ofenda, pero es un hecho que muchos programadores tienen dificultades al desarrollar sus programas porque no saben (a ciencia cierta) cómo trabajan los lenguajes en la RAM. Es por eso que le explicaré en detalle lo que sucede cuando usted crea una variable, le asigna un valor y trabaja con esa variable.
Ahora veamos el primer grafico para entender esta explicación
Cuando usted crea una variable tiene que ponerle un nombre.
Pero el nombre de una variable es un artificio del alto nivel, que hace que la vida del programador sea más sencilla. Con un nombre de variable, el programador no necesita tener en cuenta las posiciones de memoria. Porque eso es una variable: una posición de memoria que contiene datos.
El sistema (que trabaja en código máquina) no ncesita identificar una variable con un nombre, porque en realidad trabaja con los espacios de memoria RAM que pueden contener información (y que el programador identifica con el Nombre_de_la_variable).
Cuando alguien crea una variable, el sistema aparta en RAM un espacio que tendrá tantos bytes como el tipo de variable que usted esté creando:
• Una variable integer (entera o identificada como %) se guardará en 16 bits o 2 Bytes.
• Una variable long (o entero-largo o &) se almacenará en 32 bits o 4 Bytes
Todas las variables numéricas tienen una cantidad fija de Bytes para su almacenamiento. Si usted crea un array en la RAM se almacenarán tantos bytes como haya declarado en el array:
• Por ejemplo, si en el alto nivel usted declara a%(1 to 10)
• En la RAM se reservarán 20 bytes: a%(1) ocupará los bytes 1 y 2, a%(2) ocupará los bytes 3 y 4, a%(3) los bytes 5 y 6 y así hasta terminar en a%(10) que ocupará los últimos 2 bytes del espacio reservado en RAM. ¿Por qué solo 2 Bytes por elemento? Pues porque USTED declaro con el símbolo % a la variable a%() y el sistema reservará 2 bytes por elemento para ese tipo de variable.
Cada vez que usted use una etiqueta, indicando que necesita usar el valor almacenado en la variable ( por ejemplo, invoca a%(12) ), el sistema ubicará en la RAM el espacio reservado para a%(12) y leerá los datos almacenados en esos dos bytes interpretándolos como datos numéricos de entero corto. Y se los retornará o los usará según sus instrucciones.
En realidad, el programador (desde el alto nivel), no necesita usar la etiqueta para trabajar con los datos. ¿Por qué? Porque si conoce el lugar de la RAM en donde están los datos, puede leerlos directamente sin usar el nombre de la variable. Incluso puede modificarlos.
Es por ese motivo que muchos lenguajes de alto nivel le dan la posibilidad a los programadores de leer y escribir directamente en las posiciones de memoria, con la única condición de que escriba y lea en los lugares correctos para evitar un crash.
En Qbasic usted tiene las instrucciones PEEK y POKE para leer datos y escribir directamente en RAM. Para saber en que lugar de la memoria se almacenan los datos de una variable, tiene VARSEG que le indica el segmento de ram en la que se almacena y tiene VARPTR para saber su desplazamiento (alto, no se desespere, recuerde que Qbasic es PREHISTORICO…jaja y usa técnicas antiguas para manejo de RAM).
En realidad, si el lenguaje le da o no posibilidades o instrucciones para determinar la posición de RAM de los datos de una variable, no tiene mucha importancia. Hay muchas formas de leer directamente la RAM, aún cuando el lenguaje no le ayude. Pero tocar la ram directamente sin saber lo que está haciendo… es condenar al programa al crash inevitable.
En un lenguaje usted puede “leer” un contenido de esta manera:
B% = A%(12)
Y el programa hará lo siguiente: buscará en RAM los dos bytes que corresponden alos datos almacenados en a%(12), identificará la posición de memoria que almacena datos para B%, y después de eso, transferirá los datos entre las dos posiciones de memoria RAM. Es decir, llevará los dos bytes de a%(12) hasta la ram que identifica a B%.
¿Muchos pasos, verdad? Allí usted puede ver que hay un conjunto de lecturas y pasos adicionales que no hacen más que enlentecer su código, porque se podrían trasladar los datos más rapidamente haciendo un "enroque" de datos entre las dos posiciones de memoria.
Así es que una forma más eficiente de transferir esos datos sin tanta demora (o uso innecesario de ciclos de reloj de microprocesador) sería usar una instrucción de este tipo:
Poke Varptr(b%), Peek(Varptr(a%(12)))
O algo por el estilo (según el intérprete/compilador/versión de lenguaje que use).
Esta instrucción transfiere directamente datos entre dos posiciones de memoria sin tanto alboroto, interpretación o perdida de tiempo de microprocesador. El problema es que si usa mal las instrucciones, se alterarán los datos de la ram con consecuencias imprevisibles.
Algunos lenguajes, hacen justamente eso desde el alto nivel (probablemente conoce la instrucción SWAP de algunos lenguajes de alto nivel). O la instrucción SWAP de lenguajes de bajo nivel qie intercambian el byte alto con el bajo.
Lamento toda la jerga técnica de procesos obsoletos, pero creo que la idea de entender cómo se trabajan las variables en RAM es importante para un programador.
Mucho más para un programador de juegos porque a veces necesitará aumentar la velocidad de sus aplicativos. Las técnicas de acceso de datos en RAM sin pasar por el alto nivel, disparan la velocidad de los juegos.
Esto depende del lenguaje que usted esté usando, claro está. Algunos lenguajes mastodónticos son tan pesados y dependen tanto de rutinas y funciones de alto nivel que no importa lo que haga el programador, nunca tendrán buena velocidad. Sucede mucho con los que dependen de un run-time o un framework…. tienen grandes demoras en la ejecución.
Comprenderá que como programador…no me gustan los run-times, los frameworks ni los lenguajes interpretados… pienso que limitan a los programadores a los caprichos de los fabricantes de lenguajes. Microsoft es muy famoso por sus caprichos y dependiendo de sus intereses económicos, deja de actualizar entornos completos de programación.
También están los vaivenes económicos. Las empresas quiebran, cierran, o se fusionan. Muchos lenguajes prometedores dejaron de producirse por cierre o por decisiones de directorios en empresas fusionadas.
A eso me refiero cuando digo que es bueno que los programadores no hagan depender a sus proyectos de herramientas de terceros.
Un programador C++, PowerBasic, Delphi o Masm32 nunca dependerá de nadie. Si usted aprende a trabajar con un lenguaje de propósito general, nunca dependerá de rutinas de terceros. Cuando necesite algo en particular, simplemente...lo creará, lo inventará... y lo usará tantas veces como lo necesite.
Es por eso que es muy bueno (desde el punto de vista profesional) crear nuestros propios motores o engines. Y no me refiero solo a juegos, sino a aplicativos de todo tipo.
Hoy veo un gran problema en los países en desarrollo. La gran dependencia de herramientas de terceros. También se ve en la industria de juegos. Muchisimos programadores dependen de engines y sin ellos, serían incapaces de crear sus propios juegos. Hay pocos programadores básicos, con dominio completo de lenguajes de propósito general.
En fin, sigamos adelante…
Continuemos con la solución al BUG
Ahora que ya comprende como se manejan las variables en RAM, entenderá las dos posibles soluciones al BUG que propongo.
Ambas soluciones se aplican a la función GetColision%
La primer solución (la menos eficiente)
Esta solución es la menos eficiente, porque trabaja con muchas instrucciones adicionales. Pero la doy porque algunos compiladores no permiten la segunda solución propuesta.
Esta solución consiste en dividir la cadena Screen$(fila%) de la que debemos borrar la X.
Tenemos que crear dos subcadenas: una con los caracteres que están a la izquierda del valor de columna% y otra con los caracteres que están a la derecha del valor columna%
Para el trabajo, se usan variables intermedias:
DIM der$
DIM izq$
DIM LenDer%
DIM LenIzq%
LenDer% y LenIzq% son números que contienen la longitud (en caracteres) de las cadenas derecha e izquierda. Se calculan teniendo en cuenta el valor columna% que apunta a la X que debe ser borrada:
LenIzq% = columna% - 1 (un lugar a la izquierda de columna%)
LenDer% = LEN(Screen$(fila%)) - columna% (al tamaño total de Screen$(fila%) se le resta el valor de columna% y nos da el tamaño de la cadena derecha)
Una vez obtenidos estos valores, simplemente definimos las subcadenas derecha e izquierda de este modo:
izq$ = LEFT$(Screen$(fila%), LenIzq%)
der$ = RIGHT$(Screen$(fila%), LenDer%)
Y terminamos reconstruyendo la nueva cadena Screen$(fila%) asegurándonos de colocar entre las cadenas izquierda y derecha un espacio vacio que en definitiva es el que borra la X fantasmal de nuestro juego:
Screen$(fila%) = izq$ + " " + der$
Mucho trabajo ¿verdad? Pero nada puede compensar el entretenimiento de ser programador básico… jeje.
Segunda solución: la más eficiente
Esta solución implica modificar directamente el contenido de la RAM.
Para eso usaremos la instrucción MID$ que modifica directamente en RAM los bytes que contienen sus datos. Escribimos esta instrucción:
MID$(Screen$(fila%), columna%, 1) = " "
Esta orden le dice al intérprete Qbasic que modifique dentro de la variable Screen$(fila%), al carácter número columna%. Así se ordena el reemplazo de un solo caracter (eso indica el ,1), que en este caso el el byte que contiene la X a borrar, para asignarle a ese carácter un espacio vacío
Pero no es el caso de Qbasic, que como puede (y podrá ver en otros capítulos), tuvo muchisima popularidad por muchisimas buenas razones técnicas (en su momento, claro, porque ahora es obsoleto).
Como puede ver, es la solución más rápida porque tiene menos instrucciones, lo que se traduce en menos tiempo de ejecución.
Conclusión
Hay otro motivo por el que incluí las dos soluciones. Muchas veces desarrollar juegos implica que hayan varios programadores involucrados y suele haber también un coordinador general que toma decisiones al respecto de ciertos temas.
En casos parecidos a este del BUG, puede ser que el programador le presente una u otra solución y el coordinador deberá tomar la decisión de qué solución será la adoptada.
A veces los programadores no proponen las mejores soluciones técnicas o las más eficientes, sino que adoptan las soluciones más portables. No siempre lo mejor desde el punto de vista técnico es lo más portable.
Escuche lo que tienen para decir sus programadores. Puede ser que le estén evitando un dolor de cabeza más adelante, cuando deba portar su proyecto a otros entornos.
Finalmente, es bueno que “lea” códigos fuentes y los re-escriba una y otra vez... Eso es lo que le aconsejo con este curso.
Re-escriba estos códigos. Equivóquese y acierte implementando otras soluciones que las propuestas. Ser programador es mucho más que leer un código y aceptar premisas porque alguien lo dice (en este caso el que escribe).
Modifique. Explore. Genere versiones mejoradas. ¿Que no puede? ¿Qué no sabe cómo? Pues… bienvenido al mundo de los programadores. Los programadores y desarrolladores somos los que vivimos en las fronteras, allí en donde se hacen cosas que nunca nadie hizo antes. Y se hacen de un modo completamente diferente al habitual.
----------------------------------------------------------------------
Curso Gratuito de Programación de VideoJuegos1. Introducción
2. A quienes va dirigido el curso
3.Temario del curso / Herramientas
4.Primer programa (codigo fuente)
5.Detectando colisiones y comiendo objetos
6.Eliminando el bug de nuestro programa
7.Juego completo "El Minero"
8.La I.A. ( Inteligencia artificial ) en los juegos
9.La generación de bots enemigos en el juego
6.Eliminando el bug de nuestro programa
7.Juego completo "El Minero"
8.La I.A. ( Inteligencia artificial ) en los juegos
9.La generación de bots enemigos en el juego
----------------------------------------------------------------------
Por Ricardo Ponce
Links de Interés:
Cursos de Formación Profesional
Toda la oferta de cursos
Libros Gratuitos para Usted
Nuestro Canal YouTube
Toda la oferta de cursos
Libros Gratuitos para Usted
Nuestro Canal YouTube
Servicio Técnico en Sistemas, Redes y CiberSeguridad
Márketing en Internet y Redes Sociales
Su Aula Virtual en Internet
Su Taller en Internet
Su empresa en Internet
