Logo Studenta

Introduccion-a-los-videojuegos--un-enfoque-matematico-y-computacional-de-su-desarrollo

¡Este material tiene más páginas!

Vista previa del material en texto

1 
 
 
 
 
UNIVERSIDAD NACIONAL 
AUTÓNOMA DE MÉXICO 
 FACULTAD DE ESTUDIO 
SUPERIORES ACATLÁN 
 
 
Introducción a los videojuegos: un enfoque matemático y 
computacional de su desarrollo 
 
 
 
 
 
 
 
 
 
 
 
 
 TESINA 
 
 
 QUE PARA OBTENER EL TÍTULO DE: 
 Licenciado en Matemáticas Aplicadas y 
Computación 
 
 P R E S E N T A : 
 
David Arturo Granados Cervantes 
 
 
 
 
 
 
 
 
 
 
DIRECTOR DE TESINA: 
Lic. Ricardo Domínguez Esquerro 
 
Santa Cruz Acatlán, Naucalpan, Estado de México, 2018 
 
 
UNAM – Dirección General de Bibliotecas 
Tesis Digitales 
Restricciones de uso 
 
DERECHOS RESERVADOS © 
PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL 
 
Todo el material contenido en esta tesis esta protegido por la Ley Federal 
del Derecho de Autor (LFDA) de los Estados Unidos Mexicanos (México). 
El uso de imágenes, fragmentos de videos, y demás material que sea 
objeto de protección de los derechos de autor, será exclusivamente para 
fines educativos e informativos y deberá citar la fuente donde la obtuvo 
mencionando el autor o autores. Cualquier uso distinto como el lucro, 
reproducción, edición o modificación, será perseguido y sancionado por el 
respectivo titular de los Derechos de Autor. 
 
 
 
2 
 
 
Contenido 
ANTECEDENTES ...................................................................................................................................... 9 
EVOLUCIÓN MATEMÁTICA Y COMPUTACIONAL DE LOS VIDEOJUEGOS ..................................................................... 10 
EL HARDWARE Y LOS PRIMEROS DESARROLLADORES ........................................................................................... 11 
OBJETIVOS DE LA INVESTIGACIÓN ................................................................................................................... 13 
CAPÍTULO I ........................................................................................................................................... 15 
EL CONCEPTO MATEMÁTICO DE VIDEOJUEGO Y EL ORIGEN DE GAME ENGINE .................................... 15 
1.1 EL CONCEPTO DE MODELO Y SIMULACIÓN .................................................................................................. 15 
1.1.1 Modelos basados en agentes y sistemas dinámicos ................................................................ 16 
1.2 MATEMÁTICAS APLICADAS EN LOS VIDEOJUEGOS. ....................................................................................... 20 
1.3 DEFINICIÓN DE UN GAME ENGINE ............................................................................................................. 23 
1.4 ARQUITECTURA DE UN GAME ENGINE ........................................................................................................ 24 
1.4.1 Hardware, sistema operativo y drivers .................................................................................... 25 
1.4.2 Middleware y SDKs ................................................................................................................... 26 
1.4.3 Independencia de Hardware .................................................................................................... 26 
1.4.4 Núcleo del Sistema ................................................................................................................... 26 
1.4.5 Recursos ................................................................................................................................... 26 
1.4.6 Motor Gráfico........................................................................................................................... 26 
1.4.6.1 Procesador de bajo nivel .................................................................................................................. 27 
1.4.6.2 Escenario Gráfico .................................................................................................................. 27 
1.4.6.3 Efectos Visuales ................................................................................................................................ 27 
1.4.7 Fundamentos del Gameplay .................................................................................................... 27 
1.4.8 Subsistemas específicos del videojuego ................................................................................... 27 
CAPÍTULO II. ......................................................................................................................................... 29 
GAMEENGINE UNITY3D, UNA OPCIÓN COMO HERRAMIENTA DE DESARROLLO. ................................. 29 
2.1 ARQUITECTURA DE SOFTWARE................................................................................................................. 29 
2.2 ESTILOS ARQUITECTÓNICOS. ................................................................................................................... 31 
2.2.1 Arquitectura N-Tier(N-Nivel) /3-Tier (3-Niveles) ...................................................................... 32 
2.2.2 Arquitectura Cliente-Servidor ................................................................................................... 33 
2.2.3 Arquitectura Diseño guiado por el dominio ............................................................................ 35 
2.2.4 Arquitectura en capas .............................................................................................................. 36 
2.2.5 Arquitectura Bus de mensajería (Message Bus Architecture o MBA por sus siglas en inglés) . 38 
2.2.6 Arquitectura Orientada a Servicios (Service-Oriented Architecture o SOA por sus siglas en 
ingles) ................................................................................................................................................ 40 
2.2.7 Arquitectura Orientada a Objetos ............................................................................................ 43 
2.2.8 Arquitectura basada en componentes (Component-Based Architectureo CBA por sus siglas en 
inglés) ................................................................................................................................................ 44 
2.2.8.1 Programación Orientada a Objetos (POO) vs Programación Orientada a Componentes (POC) ....... 47 
CAPÍTULO III ......................................................................................................................................... 49 
DESARROLLO DE UN VIDEOJUEGO CON UNITY .................................................................................... 49 
3.1 INSTALACIÓN DE UNITY .......................................................................................................................... 49 
3.2 INTERFAZ GRÁFICA................................................................................................................................. 52 
3.2.1 Vista del Proyecto .................................................................................................................... 53 
3.2.2 Vista de la Escena..................................................................................................................... 53 
3.2.3 Vista del Juego ......................................................................................................................... 54 
3.2.4 Vista de Jerarquía..................................................................................................................... 54 
3.2.5 Vista del Inspector .................................................................................................................... 55 
3.3 GAME OBJECT ...................................................................................................................................... 56 
3.3.1 Componentes ...........................................................................................................................57 
3 
 
3.4 CREACIÓN DE ESCENARIOS EN DOS DIMENSIONES ........................................................................................ 57 
3.5 CREACIÓN DEL PERSONAJE PRINCIPAL ........................................................................................................ 63 
3.5.1 Movimientos del personaje. ..................................................................................................... 70 
3.5.1.1 Primer Script ..................................................................................................................................... 73 
CONCLUSIÓN ....................................................................................................................................... 77 
BIBLIOGRAFÍA. ..................................................................................................................................... 78 
 
. 
4 
 
Ilustraciones. 
 
ILUSTRACIÓN 1 EL RADAR UTILIZADO EN LOS AEROPUERTOS PARA CONTROLAR EL TRÁFICO DE LAS AERONAVES ES UN CLARO 
EJEMPLO DE LA APLICACIÓN DE SISTEMAS DE TIEMPO REAL RÍGIDOS, EN DONDE NO PUEDEN EXISTIR ERRORES DE 
SINCRONIZACIÓN. IMAGEN: 
HTTP://S03.S3C.ES/IMAG/_V0/635X300/6/1/4/INDRA_PANTALLA_CONTROL_AEREO.JPG ............................. 19 
ILUSTRACIÓN 2 UN ERROR DENTRO DE UN SISTEMA DE TIEMPO REAL SUAVE EN LOS VIDEOJUEGOS OCURRE CUANDO LOS 
PROCESOS ENCARGADOS DE DIBUJAR LAS ESCENAS U OBJETOS NO COMPLETAN SUS PLAZOS DE EJECUCIÓN. IMAGEN: 
HTTPS://IMAGE.REDBULL.COM/RBCOM/010/2015-01-
09/1331698786896_2/0010/1/1600/1067/1/ASSASSIN-S-CREED-UNITY.JPG .......................................... 20 
ILUSTRACIÓN 3 ESTRUCTURA BÁSICA DE UN GAME ENGINE. IMAGEN: 
HTTPS://I.PINIMG.COM/ORIGINALS/64/84/E7/6484E712CAB874227C62C3B83A41ED10.JPG ...................... 24 
ILUSTRACIÓN 4 DISEÑO BASADO EN CAPAS DE UN GAME ENGINE (EN DONDE LA CAPA SUPERIOR CONSUMIRÁ LOS RECURSOS 
PROPORCIONADOS POR LAS CAPACES INFERIORES, CREANDO ASÍ UNA DEPENDENCIA LINEAL). IMAGEN: GREGORY, 
JAMES. GAME ENGINE ARCHITECTURE PÁG. 29. .......................................................................................... 25 
ILUSTRACIÓN 5 ARQUITECTURA DE UNA APLICACIÓN CUYOS COMPONENTES SON AGRUPADOS POR DIFERENTES ÁREAS DE 
INTERÉS. IMAGEN: HTTPS://IMAGE.SLIDESHARECDN.COM/SOFTWAREARCHITECTUREALSONEEDSAGILE-
150603045511-LVA1-APP6892/95/SOFTWARE-ARCHITECTURE-ALSO-NEEDS-AGILE-4-638.JPG?CB=1433307509
 .......................................................................................................................................................... 30 
ILUSTRACIÓN 6.EJEMPLO DE UNA ARQUITECTURA CON DISEÑO DE ALTO NIVEL PARA UNA APLICACIÓN WEB QUE UTILIZA LA 
FUNCIONALIDAD DE UN COMPONENTE EXTERNO PARA REALIZAR BÚSQUEDAS AL SERVIDOR Y DEVUELVE SUGERENCIAS EN 
RELACIÓN CON LOS DATOS INGRESADOS. ..................................................................................................... 31 
ILUSTRACIÓN 7 DISTINTOS ESTILOS ARQUITECTÓNICOS ORGANIZADOS POR CATEGORÍAS. IMAGEN: 
HTTPS://MSDN.MICROSOFT.COM/EN-US/LIBRARY/EE658117.ASPX ............................................................... 32 
ILUSTRACIÓN 8 ARQUITECTURA DE 3 NIVELES, QUE REPRESENTA LA RELACIÓN ENTRE LAS CAPAS DE PRESENTACIÓN, DONDE EL 
CLIENTE REALIZA PETICIONES; LA CAPA LÓGICA QUE VALIDA LAS REGLAS DE NEGOCIO Y POR ÚLTIMO LA CAPA DE DATOS, 
QUE ALOJA LOS DIVERSOS DATOS QUE SE REQUIEREN PARA ENVIAR LA RESPUESTA. IMAGEN: 
HTTPS://WWW.IBM.COM/SUPPORT/KNOWLEDGECENTER/ES/SSAW57_8.5.5/COM.IBM.WEBSPHERE.ND.DOC/AE/I
MAGES/THTRCS.GIF ................................................................................................................................ 33 
ILUSTRACIÓN 9 ARQUITECTURA CLIENT-QUEUE-CLIENT. IMAGEN: 
HTTP://PRACTICE.GEEKSFORGEEKS.ORG/CKEDITOR/IMAGES/UPLOADS/1491250148_CLIENT_SERVER.PNG .......... 34 
ILUSTRACIÓN 10 EJEMPLO DE LA ARQUITECTURA GUIADO POR EL DOMINIO. IMAGEN: 
HTTP://I.MSDN.MICROSOFT.COM/AA699358.IMAGE003(ES-ES,MSDN.10).JPG ............................................. 36 
ILUSTRACIÓN 11. CAPAS QUE CONFORMAN A UN SISTEMA OPERATIVO EN GENERAL. IMAGEN: 
HTTPS://WWW.TECHNOLOGYUK.NET/COMPUTING/OPERATING-SYSTEMS/IMAGES/LAYERED_OS_ARCHITECTURE.GIF 37 
ILUSTRACIÓN 12. REPRESENTACIÓN DE LAS CAPAS DE PRESENTACIÓN, NEGOCIO Y DATOS EN UNA ARQUITECTURA 3-
TIER.IMAGEN: HTTP://WWW.SOFTWARETESTINGCLASS.COM/WP-CONTENT/UPLOADS/2013/01/THREE-TIER-
ARCHITECTURE.PNG ................................................................................................................................ 37 
ILUSTRACIÓN 13 DISEÑO BÁSICO DE LA ARQUITECTURA BUS DE MENSAJERÍA. IMAGEN: HTTP://1.BP.BLOGSPOT.COM/_-
JEMWY3YIQK/SBWJSBIY47I/AAAAAAAAADK/XWCVFDYUQVI/S400/BUS+DE+SISTEMA.JPG ....................... 38 
ILUSTRACIÓN 14 EJEMPLO DEL DISEÑO DE LA ARQUITECTURA ESB. IMAGEN: HTTP://DASMU.US/WP-
CONTENT/UPLOADS/2017/07/ENTERPRISE-SERVICE-BUS-ARCHITECTURE-STUNNING-ON-ARCHITECTURE-ENTERPRISE-
SERVICE-BUS-5.JPG ................................................................................................................................ 39 
ILUSTRACIÓN 15 EJEMPLO DEL DISEÑO DE LA ARQUITECTURA ISB. IMAGEN: 
HTTPS://CLOUDCASTS.BLOB.CORE.WINDOWS.NET/BOOKIMAGES/SERVICEBUSOVERVIEW_FILES/IMAGE010.PNG .... 40 
ILUSTRACIÓN 16 DISEÑO PRINCIPAL EN UNA ARQUITECTURA ORIENTADA A SERVICIOS. IMAGEN: 
HTTPS://IMAGES.TECHHIVE.COM/IMAGES/IDGE/IMPORTED/ARTICLE/CTW/2004/03/01/HOWSOAWORKS_LARGE-
100405512-ORIG.GIF ........................................................................................................................... 42 
ILUSTRACIÓN 17 ARQUITECTURA ORIENTADA A OBJETOS. IMAGEN: 
HTTPS://CORONET.IICM.TUGRAZ.AT/SA/ASSIGN/2/ARCH.PNG ....................................................................... 44 
ILUSTRACIÓN 18 EJEMPLO DE UN PATRÓN DE DISEÑO BASADO EN OBJETOS. ................................................................ 45 
ILUSTRACIÓN 19 COMPONENTES QUE SERÁN DESCARGADOS E INSTALADOS EN NUESTRO SISTEMA. IMAGEN CAPTURADA POR EL 
AUTOR. ................................................................................................................................................ 51 
ILUSTRACIÓN 20 OPCIONES PARA EL MANEJO DE LICENCIAS EN UNITY. IMAGEN CAPTURADA POR EL AUTOR. ..................... 51 
ILUSTRACIÓN 21 PANTALLA PARA INGRESAR O CREAR UNA CUENTA DENTRO DE UNITY. IMAGEN CAPTURADA POR EL AUTOR. 52 
ILUSTRACIÓN 22 PANTALLA PARA ACCEDER O CREAR UN NUEVO PROYECTO. IMAGEN CAPTURADA POR EL AUTOR. .............. 52 
5 
 
ILUSTRACIÓN 23 EDITOR DE UNITY CON SUS DISTINTAS VISTAS. IMAGEN: HTTPS://UNITY3D.COM/ES/LEARN/TUTORIALS .... 53 
ILUSTRACIÓN 24 VISTA DEL PROYECTO.IMAGEN: HTTPS://UNITY3D.COM/ES/LEARN/TUTORIALS .................................... 53 
ILUSTRACIÓN 25 VISTA DE LA ESCENA. IMAGEN: HTTPS://UNITY3D.COM/ES/LEARN/TUTORIALS ..................................... 54 
ILUSTRACIÓN 26. VISTA DE JERARQUÍA. IMAGEN CAPTURADA POR EL AUTOR. .............................................................. 55 
ILUSTRACIÓN 27 VISTA DEL INSPECTOR AL SELECCIONAR UN ACTIVO DE AUDIO (IZQ.) Y UN ACTIVO DE TIPO MATERIAL (DER.) 
IMAGEN CAPTURADA POR EL AUTOR........................................................................................................... 55 
ILUSTRACIÓN 28. VISTA DEL INSPECTOR MOSTRANDO LAS PROPIEDADES DE LA CÁMARA QUE SE ENCUENTRA EN LA ESCENA. . 
IMAGEN CAPTURADA POR EL AUTOR........................................................................................................... 56 
ILUSTRACIÓN 29. CREACIÓN DE CARPETAS QUE ALOJARÁN LOS DISTINTOS ELEMENTOS DEL JUEGO. IMAGEN CAPTURADA POR EL 
AUTOR. ................................................................................................................................................ 58 
ILUSTRACIÓN 30. CARPETAS CREADAS POR MEDIO DEL EDITOR, VISTAS DESDE EL EXPLORADOR DE ARCHIVOS. . IMAGEN 
CAPTURADA POR EL AUTOR. ..................................................................................................................... 58 
ILUSTRACIÓN31. EVOLUCIÓN DE LOS SPRITES PARA EL PERSONAJE DE MARIO BROS. IMAGEN: 
HTTPS://WWW.IONLITIO.COM/IMAGES/2006/10/SPRITES_SUPER_MARIO.GIF ................................................ 59 
ILUSTRACIÓN 32. POSICIÓN DE LA CÁMARA PRINCIPAL JUNTO CON LA PROYECCIÓN DE TIPO PERSPECTIVA. . IMAGEN 
CAPTURADA POR EL AUTOR. ..................................................................................................................... 59 
ILUSTRACIÓN 33. VISTA DEL INSPECTOR AL SELECCIONAR EL FONDO DEL JUEGO.. IMAGEN CAPTURADA POR EL AUTOR. ........ 60 
ILUSTRACIÓN 34. VALORES PARA LOS DIFERENTES SPRITES DENTRO DE LA ESCENA DEL JUEGO. . IMAGEN CAPTURADA POR EL 
AUTOR. ................................................................................................................................................ 60 
ILUSTRACIÓN 35. ESCENARIO COMPUESTO POR TRES OBJETOS, LA CÁMARA, SPRITE DE FONDO Y SPRITE COMO SUBFONDO. . 
IMAGEN CAPTURADA POR EL AUTOR........................................................................................................... 61 
ILUSTRACIÓN 36. COMPONENTES QUE UN OBJETO PUEDE CONTENER. IMAGEN CAPTURADA POR EL AUTOR. ..................... 61 
ILUSTRACIÓN 37. COMPONENTES PARA IMPLEMENTAR LA COLISIÓN ENTRE OBJETOS. IMAGEN CAPTURADA POR EL AUTOR. .. 62 
ILUSTRACIÓN 38. CAMBIOS AL AGREGAR UN NUEVO COMPONENTE FÍSICO AL OBJETO EN LA ESCENA. ............................... 62 
ILUSTRACIÓN 39. OBJETOS QUE SE REUTILIZARÁN DURANTE EL DESARROLLO, TAMBIÉN DE NOMINADOS “PRE-FABRICADOS”. . 
IMAGEN CAPTURADA POR EL AUTOR........................................................................................................... 63 
ILUSTRACIÓN 40. SPRITE SHEET QUE ALBERGA CADA UNO DE LOS MOVIMIENTOS DE UN PERSONAJE. IMAGEN: 
HTTPS://IMG00.DEVIANTART.NET/9B49/I/2010/247/6/5/MEGAMAN_RUNNING_SPRITES_BY_COBALT_BLUE_KNIG
HT-D2Y1I8S.JPG .................................................................................................................................... 63 
ILUSTRACIÓN 41. VISTAS DEL PROYECTO E INSPECTOR AL SELECCIONAR UN SPRITE SHEET. . IMAGEN CAPTURADA POR EL 
AUTOR. ................................................................................................................................................ 64 
ILUSTRACIÓN 42. VENTANA DEL EDITOR DE SPRITES. . IMAGEN CAPTURADA POR EL AUTOR. ........................................... 65 
ILUSTRACIÓN 43. SPRITES RESULTANTES DE LA DIVISIÓN REALIZADA EN EL SPRITE SHEET ORIGINAL POR EL EDITOR DE SPRITES. 
IMAGEN CAPTURADA POR EL AUTOR........................................................................................................... 65 
ILUSTRACIÓN 44. COMPONENTE RIGIDBODY2D. IMAGEN CAPTURADA POR EL AUTOR. ................................................. 66 
ILUSTRACIÓN 45. OBJETO CON COMPONENTE RIGIDBODY2D AFECTADO POR LA GRAVEDAD. CAERÁ HASTA SALIR DE LA 
ESCENA. IMAGEN CAPTURADA POR EL AUTOR. .............................................................................................. 66 
ILUSTRACIÓN 46. PERSONAJE CON COMPONENTES RIGIDBODY2D Y BOXCOLLIDER2D, COLISIONANDO CON PLATAFORMAS DE 
TIPO COLLIDER. IMAGEN CAPTURADA POR EL AUTOR...................................................................................... 67 
ILUSTRACIÓN 47. CREACIÓN DE UNA ANIMACIÓN EN EL EDITOR UNITY. IMAGEN CAPTURADA POR EL AUTOR. .................... 67 
ILUSTRACIÓN 48. OBJETOS RESULTANTES AL CREAR UNA ANIMACIÓN. IMAGEN CAPTURADA POR EL AUTOR. ...................... 68 
ILUSTRACIÓN 49. VISTA DENOMINADA ANIMATOR, EN LA CUAL SE OBSERVA AL CONTROLADOR DE LA ANIMACIÓN CREADA. 
IMAGEN CAPTURADA POR EL AUTOR........................................................................................................... 68 
ILUSTRACIÓN 50. CAMBIO DE ANIMACIÓN INICIAL EN EL OBJETO. IMAGEN CAPTURADA POR EL AUTOR. ............................ 69 
ILUSTRACIÓN 51. DEFINICIÓN DE LOS PARÁMETROS QUE ACTUARÁN EN EL CAMBIO DE ESTADOS. IMAGEN CAPTURADA POR EL 
AUTOR. ................................................................................................................................................ 69 
ILUSTRACIÓN 52. DEFINICIÓN DE LAS CONDICIONES QUE AFECTARÁN LA TRANSICIÓN ENTRE ESTADOS. IMAGEN CAPTURADA 
POR EL AUTOR. ...................................................................................................................................... 70 
ILUSTRACIÓN 53. CREACIÓN DE UN NUEVO COMPONENTE DE TIPO SCRIPT EN JAVASCRIPT. IMAGEN CAPTURADA POR EL 
AUTOR. ................................................................................................................................................ 71 
ILUSTRACIÓN 54. CONFIGURACIÓN DE IDE EXTERNOS. IMAGEN CAPTURADA POR EL AUTOR. .......................................... 72 
ILUSTRACIÓN 55. DIFERENCIA EN LOS TIEMPOS DE LLAMADA DE LAS FUNCIONES UPDATE Y FIXEDUPDATE. . IMAGEN 
CAPTURADA POR EL AUTOR. . IMAGEN CAPTURADA POR EL AUTOR. .................................................................. 72 
ILUSTRACIÓN 56. ENTRADAS PREDEFINIDAS EN UNITY. . IMAGEN CAPTURADA POR EL AUTOR. ........................................ 74 
ILUSTRACIÓN 57. VARIABLES DECLARADAS EN EL SCRIPT. IMAGEN CAPTURADA POR EL AUTOR. ....................................... 74 
ILUSTRACIÓN 58. VALORES DE ESCALAMIENTO PREVIAMENTE DEFINIDOS. IMAGEN CAPTURADA POR EL AUTOR. ................. 75 
6 
 
ILUSTRACIÓN 59. CÓDIGO EN UNITY3D PARA MOVER UN OBJETO DE TIPO RIGIDBODY DE IZQUIERDA A DERECHA. . IMAGEN 
CAPTURADA POR EL AUTOR. ..................................................................................................................... 76 
7 
 
“A delayed game is eventually good, a bad game is bad forever.” 
-Shigeru Miyamoto. 
 
“Imagination is more important that knowledge. Knowledge is 
limited. Imagination encircles the world.” 
-Albert Einstein. 
 
“The important thing is to not stop questioning. Curiosity has its own 
reason for existing.” 
-Albert Einstein. 
 
8 
 
Dedicatorias 
 
Para mi Esposa Dulce. 
Gracias por siempre sacar lo mejor de mí, apoyarme en mis más locas, bizarras y desquiciadas ideas, 
por enseñarme en donde me equivoco para tomar la mejor decisión. Pero sobre todo por tu amor 
incondicional. 
 
A mis Padres Lourdes y Arturo 
Por apoyarme en continuar mis estudios no importando la edad y los tropiezos de un mal estudiante, así 
como el estar insistiendo para terminar este trabajo, que me imagino lo anhelaban más que yo. 
 
A mis Hermanos Miguel y Antonio 
Por la pasión que seguimos compartiendo en los videojuegos. 
 
A mis Amigos. 
Edith, Medel, Argel, Sergio, Jorge y Toño. Gracias por la sana competencia, por las anécdotas, por estar 
siempre en las buenas y en las malas. 
 
A mis Profesores. 
A todo el profesorado de MAC muchas gracias por el conocimiento impartido durante los años de 
carrera. 
 
Sobre todo, gracias Ricardo, por todo lo que me enseñaste durante la carrera, no solo ha sido el 
conocimiento dentro de la carrera de MAC, si no en la búsqueda de sobrepasar nuestras metas y 
objetivos, además de ser nuestro propio y más cruel crítico en todas nuestras decisiones. 
 
 
9 
 
 
Antecedentes 
 
Definir un videojuego no es sencillo, en sus orígenes sólo se consideraba como una serie de 
comandos y patrones que el usuario memorizaba para alcanzar un mayor puntaje; pero al ir 
evolucionando, ahora es posible la interacción con entornos gráficos que buscan ser cada vez 
más realistas, en donde se han implementado aspectos literarios al presentar historias que 
contienen un inicio, un desarrollo y un desenlace, apoyados de elementos visuales, acústicos y 
escénicos capaces de transmitir emociones y pensamientos. Por ello, en la actualidad resulta 
difícil conceptualizar a los videojuegos de una manera general dada la amplitud de áreas que 
abarcan, y aunque frecuentemente sólo se hace mención de los aspectos técnico y artístico, 
también se debe de considerar una definición dentro de un punto de vista social o cultural, por 
mencionaralgunos, cuya definición también sería válida y correcta. No obstante, el concepto 
más importante del videojuego proviene del usuario, quien lo define como un medio de 
entretenimiento que permite interactuar con diversos elementos dentro de una historia que se 
desarrolla en un mundo digital. 
 
La evolución de las computadoras (donde la tecnología sigue avanzando de manera 
exponencial), ha beneficiado directamente a los videojuegos, ya que, al tener acceso a mayor 
capacidad de procesamiento y almacenamiento, sus desarrolladores se enfocaron en la creación 
de simulaciones con entornos y elementos cada vez más realistas. Se hizo necesaria entonces, 
la aparición de diferentes lenguajes, paradigmas y metodologías de programación, lo que a su 
vez propició el diseño de software cada vez más complejo, que en consecuencia requirió un 
hardware más rápido y eficaz para poder ejecutarlo. Como resultado, se han desarrollado 
diversas plataformas,1 en donde los usuarios no se limitan a interactuar2 sólo con botones y 
comandos para enviar instrucciones, sino con nuevos mecanismos3 que han otorgado una mayor 
libertad al usuario al no tener que depender de un televisor o un lugar estático para poder jugar, 
y más aún, al incorporar las tecnologías de redes (como el Internet) el público usuario compite 
y convive con usuarios de distintas partes del mundo. 
 
El impacto social que han tenido los videojuegos no abarca únicamente el rubro tecnológico, 
sino también el económico; tal como se desprende del elevado porcentaje anual de crecimiento 
que las ganancias de los videojuegos reflejan, incluso mayor a las obtenidas por toda la nación 
estadounidense; además esta industria ha sido reconocida al generar empleos y apoyar 
economías locales al expandirse en diversos estados de una región. Es por esta razón que la 
industria del videojuego ha sobrepasado a otras tan importantes como la industria 
cinematográfica4. Los propios usuarios han obtenidos ganancias al formar economías dentro de 
 
1 Chernyak, Ulyana. “Video Game Market Overview: Console vs. PC vs. Mobile”. 2014 
<http://www.gamasutra.com/blogs/UlyanaChernyakXsolla/20140527/218626/Video_Game_Market_Ov
erview_Console_vs_PC_vs_Mobile.php > (01 Jun. 2014) 
2 Huang, Sunnie, yWilliams, Jamie. “No longer kids stuff: the evolution of video games”. From hit titles 
like Pong to Call of Duty, video games have been with us for over 50 years. 2013. 
<http://www.cbc.ca/news/canada/hamilton/news/no-longer-kids-stuff-the-evolution-of-video-games-
1.1313249 > (01 Jun 2014) 
3 Wisniowski, Howard. “Analog devices and Nintendo collaboration drives video game innovation with 
iMEMS motion signal processing technology”. With ADI’s ADXL330 3-axis iMEMS accelerometer, 
Nintendo’s Wii Console redefines the gaming experience by bringing the gaming world into the physical 
world.2006.< http://www.analog.com/en/press-
release/May_09_2006_ADI_Nintendo_Collaboration/press.html > (10 Jun. 2014) 
4 Kain, Erik. “Grand Theft Auto V' Crosses $1B In Sales, Biggest Entertainment Launch In History”. 2013 < 
http://www.forbes.com/sites/erikkain/2013/09/20/grand-theft-auto-v-crosses-1b-in-sales-biggest-
entertainment-launch-in-history/ > (01 Jun. 2014) 
10 
 
mundos virtuales, con sistemas tan sencillos como la compra-venta de “propiedades” o de 
premios en torneos que se realizan a nivel mundial a través de la Internet. 
 
La industria del videojuego ha generado incluso la creación de nuevas leyes en los diversos 
países o regiones del mundo; en parte para defender el trabajo de los desarrolladores de 
reproducciones ilegales de su trabajo a nivel global, así como para optimizar la creación de 
patentes de nuevas tecnologías que las empresas investigan y desarrollan para futuras 
implementaciones. Actualmente se han creado distintas clasificaciones de los videojuegos, 
tomando en consideración los distintos contenidos que ofrecen los videojuegos, esto a raíz del 
cuestionamiento sobre el nivel de violencia que contienen y si esto afecta la conducta de los 
usuarios5. 
 
Durante aproximadamente medio siglo los videojuegos han dejado un impacto cultural a nivel 
mundial;6 esta industria, además de ser un medio de creatividad para autores, artistas, 
escritores y desarrolladores, también ha influido en áreas como la educación, la milicia, la 
música, o hasta el propio cine. Se han definido diferentes estilos de juegos, creando distintas 
tendencias en los usuarios. Realizar un análisis de los videojuegos no es tarea fácil; sin embargo, 
es posible abordarlos desde el punto de vista tecnológico, así como en el artístico, el psicológico, 
el financiero, o bien a un determinado nivel social, sólo por mencionar algunos. 
 
Este trabajo de investigación está dirigido principalmente a los egresados de la carrera de 
Matemáticas Aplicadas y Computación, con la intención de ofrecerles una perspectiva diferente, 
creativa y personal de expandir y desplegar los conocimientos adquiridos durante sus años como 
estudiantes; pues el desarrollo de videojuegos viene a significar un área del quehacer humano 
donde su pasión por la programación, el análisis matemático y la resolución de problemas 
resultan características indispensables. 
 
Incursionar en la industria de los videojuegos, así como adentrarse en el conocimiento de las 
nuevas tecnologías disponibles y atestiguar el vertiginoso avance con que éstas evolucionan les 
permitirá a los egresados de la carrera descubrir un mundo apasionante, en donde, sus 
conocimientos, creatividad y talentos serán muy bien recompensados. Por ello, la principal 
gratificación que este trabajo aporta será el haber contribuido para orientarles, -aunque sea de 
manera breve-, en el momento en que decidan la actividad laboral a la que se dedicarán, la cual 
a todas luces denota un futuro promisorio. 
 
Para comprender el actual enfoque tecnológico de los videojuegos, es preciso explicar en primer 
término su evolución a nivel de hardware y software, a partir de los primeros desarrollos dentro 
de esta industria. 
 
Evolución matemática y computacional de los videojuegos 
 
Una corriente analítica de la materia ha considerado a los juegos de arcade (Pong, Space 
Invaders o Pac-Man) como los primeros representantes de la industria, aunque en realidad los 
pioneros en videojuegos fueron desarrollados veinte años antes, aproximadamente en 1946, 
durante el inicio del conflicto conocido como la Guerra Fría, suceso que, además de los 
problemas militares, económicos o sociales, propició la búsqueda por lograr un mayor progreso 
 
5 Norcia, Andrea. “The Impact of Video Games”. 2013 <http://www.pamf.org/parenting-
teens/general/media-web/videogames.html> (10 Jun. 2014) 
6 Wilson, Devin. “What's in a Game?”. 2013 
<http://www.gamasutra.com/blogs/DevinWilson/20130411/190328/Whats_in_a_Game.php> (10 Jun 
2014) 
http://www.pamf.org/parenting-teens/general/media-web/videogames.html
http://www.pamf.org/parenting-teens/general/media-web/videogames.html
11 
 
tecnológico. Proyectos armamentistas como el de Estados Unidos alentaron la construcción de 
una de las primeras computadoras: la ENIAC7. 
 
Tanto científicos como matemáticos especializados en computación, vieron en la ENIAC un 
objetivo claro: la creación de inteligencias artificiales. El matemático británico Alan Turing8 y el 
experto en computación Claude Shannon, cuyos teoremas son los fundamentos de la 
computación moderna, plantearon que el primer gran paso sería demostrar que una 
computadora podría vencer a una persona en un juego de ajedrez. Esto implicaba que la 
computadora tendría que ser capaz de reaccionar y anticipar los movimientos de la persona de 
una manera inteligente. La meta de ambos no se ceñía a la simple demostración de la 
superioridad de una inteligencia artificial en el desarrollo de un juego de destreza, sino a 
despertar el interés teórico sobre su investigación, sustentándose enla intención de que, al 
probar la eficacia del ingenio artificial sobre el humano en esta área, se abriera el camino hacia 
la resolución de otros enigmas de manera similar. 
 
En 1947 Alan Turing fue la primera persona en escribir un programa de ajedrez para 
computadora; sin embargo, su código era tan avanzado que no pudo ser probado. Para 1952 
Turing decidió ponerlo a prueba contra un estudiante que pretendía ser la computadora; 
después de horas simulando su código finalmente fue vencido por el estudiante. Posterior a la 
muerte de Turing, Shannon dedicó sus esfuerzos durante la década de los cincuentas a la 
investigación de la inteligencia artificial logrando que las computadoras jugaran diversos juegos, 
siendo el ajedrez la prueba final. 
 
Hacia 1951, en Reino Unido, el australiano John Bennett propuso la creación de una 
computadora que jugara Nim, un juego de estrategia matemática, cuyo objetivo fuese 
demostrar su capacidad al realizar distintos tipos de cálculos. Irónicamente Nimrod (como fue 
llamada la computadora), a pesar de haber logrado el éxito en su objetivo al ser presentada al 
público, no despertó el interés técnico que se pretendía, habida cuenta que las personas se 
interesaron únicamente en jugar y vencer a la máquina. 
 
Para 1958 el concepto de videojuego era un tema que la comunidad científica prefería eludir, 
simplemente porque no era importante dentro de sus investigaciones. La computadora de 
Bennett fue hasta ese entonces lo más cercano a una interacción real entre la computadora y el 
jugador. Sería a finales de ese mismo año cuando se dejaría a un lado la formalidad con la que 
se había tratado hasta ese entonces a la programación de aplicaciones y se daría paso a 
experimentos más creativos. 
 
El hardware y los primeros desarrolladores 
 
Fueron dos desarrollos los que iniciaron la industria del videojuego; de hecho, los historiadores 
no han podido definir a cuál de ellos se le puede considerar como el primero. No obstante, la 
importancia de ambos desarrollos no radica en atribuirles su origen primario, sino, en resaltar 
que su aparición marcó un valor matemático y computacional sin precedentes, habida cuenta 
que fue el principio para que una gran diversidad de matemáticos, físicos e ingenieros, que 
carecían por completo de experiencia en videojuegos, comenzaran a buscar nuevas formas de 
diseñar hardware, dando como resultado las primeras arcades o máquinas tragamonedas, 
donde los juegos serían cada vez más elaborados y con un mayor reto para los usuarios. 
 
7 Ennis-Cole, Demetria. “Computers, Evolution of Electronic”. 2002 < 
http://www.encyclopedia.com/doc/1G2-3407500068.html > (10 Jun. 2014) 
8 Hodges,Andrew. “Who was Alan Turing?”.1995 <http://www.turing.org.uk/> (09 Oct 2017). 
http://www.turing.org.uk/
12 
 
Uno de estos desarrollos fue realizado por el físico William A. Higinbotham, quien trabajó en el 
proyecto Manhattan responsable de desarrollar los interruptores de temporización para 
accionar en el momento preciso la primera bomba atómica. Después de la Segunda Guerra 
Mundial tomó posesión como director de la División de Instrumentación dentro del Laboratorio 
Nacional de Brookhaven. Para la exposición anual del laboratorio de 1958, donde se mostraban 
diferentes trabajos de investigación, diseñó un juego de tenis con el cual las personas tuvieran 
la oportunidad de interactuar y divertirse, lo nombró Tennis for Two. 
 
Comenzó su desarrollo en la computadora Donner Modelo 30 cuyas funciones computacionales 
le permitían simular trayectorias de misiles balísticos, balas y el rebote de una pelota, 
considerando factores como la gravedad y la resistencia al aire. Utilizó un osciloscopio como 
monitor donde por medio de resistencias, condensadores y relevadores generaba distintas 
curvas en el tubo de rayos catódicos mostrando así la trayectoria de la pelota, al igual que una 
cancha de tenis con perspectiva horizontal. Los jugadores podían interactuar con el juego por 
medio de dos controles análogos de aluminio que estaban formados por un botón, el cual emitía 
un sonido cada vez que se golpeaba a la pelota, y una perilla con la cual se controlaba el ángulo 
de lanzamiento. 
 
Su juego fue un éxito, lo cual produjo su regreso para la exposición de 1959 con una versión 
mejorada, con una pantalla más grande y con la opción de tener diferentes niveles para simular 
la gravedad. Lamentablemente el producto fue desmantelado para reutilizar partes en otros 
proyectos. 
 
El segundo gran desarrollo tuvo su origen en el Instituto de Tecnología de Massachusetts, (MIT 
por sus siglas en inglés), que en 1961 obtuvo la computadora PDP-19, donación hecha por DEC 
(Digital Equipment Corporation); aparte de su gran tamaño, fue la primera en poseer un teclado 
y pantalla con el objetivo de tener una mayor interacción con el usuario, convirtiéndola así en la 
antecesora de las computadoras de escritorio. La manera de programar en ella era por medio 
de perforaciones en tiras de papel realizando aplicaciones como controles de procesos, creación 
de música, manejo y visualización de gráficos e investigación científica entre otros. 
 
Steve Russell, estudiante y fanático de la ciencia ficción, además de ayudar en la implementación 
del lenguaje de programación LISP, daría otra aplicación más a la PDP-1: un videojuego. Steve 
tuvo la idea de crear un duelo entre dos naves en el espacio, para eso necesitó la ayuda de Alan 
Kotok, quien le proporcionó una rutina para calcular el seno-coseno de un número de punto 
flotante. Después de seis meses, obtuvieron una primera versión en que mediante dos controles 
compuestos por un botón y dos interruptores se podía controlar la dirección, velocidad y lanzar 
misiles. Steve llamó a su juego Spacewar. 
 
Los usuarios de la PDP-1 estaban acostumbrados a revisar las aplicaciones de los demás, ya que 
las tiras de papel en donde estaban escritas eran dejadas cerca de la computadora, lo que 
propició revisiones y mejoras a dichas aplicaciones; lo mismo sucedió con Spacewar. Para 1962 
ya se tenía una versión mejorada del juego que incluía un mapa de estrellas como fondo y un 
Sol con un campo gravitacional, además de otro botón para la simulación del hiperespacio. Esta 
versión final fue utilizada para demostrar el poder de la PDP-1 ya que, por ejemplo, para realizar 
el movimiento de la nave se requerían de 100,000 cálculos por segundo. 
 
Aunque estos dos desarrollos fueron exitosos, nunca fueron comercializados, debido a que las 
primeras computadoras eran muy costosas, aproximadamente 120,000 dólares en ese tiempo, 
por lo cual sus compradores se limitaban a universidades, laboratorios o empresas. Pero como 
 
9 Computer History Museum. < http://pdp-1.computerhistory.org/pdp-1/index.php > 
13 
 
se mencionó antes, esto propició a que se buscaran nuevos diseños de hardware para poder 
llegar a los consumidores casuales. Con el auge de la televisión, varios ingenieros, muchos de 
ellos trabajando para la milicia, idearon la manera de transferir imágenes a la televisión, dando 
comienzo a las máquinas tragamonedas o arcades, desarrollando juegos que comenzaron a 
dejar ganancias a sus desarrolladores, fundando posteriormente compañías dedicadas 
exclusivamente al desarrollo de videojuegos. 
 
La aplicación de las matemáticas también ha sido parte fundamental dentro de la evolución de 
los videojuegos, conocimientos en trigonometría y geometría de vectores, así como álgebra 
fueron bases para desarrollos en dos dimensiones. Posteriormente los desarrolladores 
comenzarían a trabajar en entornos y objetos en tres dimensiones, donde implementarían 
álgebra lineal para el cálculo de matrices, como la traslación, rotación y escalamiento de 
coordenadas10, lo que permitiría el manejo de polígonos, efectos de luz y ángulos para crear 
diferentes perspectivas. Como resultado hoy en día se tienen simulaciones dinámicascuyos 
modelos matemáticos, que en un principio sólo eran diseñados para cuestiones científicas11, 
permiten interactuar en entornos más realistas integrando elementos físicos como la gravedad 
y colisiones entre objetos. 
 
Objetivos de la Investigación 
 
No es posible abarcar toda la historia de la industria del videojuego en este trabajo; en 50 años 
se han observado grandes avances en esta actividad, tanto en el hardware, en el software y en 
las personas que empezaron a desarrollar estos proyectos. En sus orígenes no existía un perfil 
definido para el desarrollador de videojuegos, no había especialidades en manejo de gráficos o 
escenarios en tres dimensiones, y muchos menos pensar en escritores de guiones, diseño de 
personajes, por mencionar sólo algunos. 
 
El objetivo del videojuego pasó de simple entretenimiento a la simulación de entornos cada vez 
más reales. Esto llevó a buscar nuevos diseños para el desarrollo de un videojuego, cambió la 
manera de pensar para el desarrollador y de trabajar para el equipo de desarrollo, se crearon 
nuevas herramientas, (game engines), para minimizar tiempos, y reutilizar código. Se buscaron 
nuevos lenguajes de programación y los programadores se especializarían en distintas áreas 
formando así diversos perfiles dentro del desarrollo. 
 
A raíz de estos cambios y de estas nuevas herramientas de desarrollo, muchos programadores 
inexpertos comenzaron a realizar proyectos independientes explotando estos game engines 
cuyo código era liberado, añadiéndoles nuevas funcionalidades para el manejo de gráficos, física 
de objetos o efectos en luz y sonido. Sus desarrollos fueron bien recibidos en la industria 
sobrepasando a muchos videojuegos de renombre, lo que propició que importantes estudios 
apoyen a los desarrolladores independientes. 
 
Se ha mencionado que el objetivo principal de este trabajo es introducir al estudiante y egresado 
de la carrera de Matemáticas Aplicadas y Computación,(así como afines), en el desarrollo de 
videojuegos como otra aplicación de sus conocimientos, al intentar describir funciones y 
componentes principales que conforman la lógica de programación en un producto final, pero 
de igual manera con base a sus conocimientos en asignaturas como Algebra Lineal, Geometría 
 
10 DeLeon,Chris, “Math for videogame making or will I need to use calculus”,2010 
<http://www.hobbygamedev.com/articles/vol11/math-for-videogame-making-or-will-i-need-to-use-
calculus/> (8 Jul. 2014) 
11Bramson,Aaron, “Comparing ABMs, Math Models, and Computer Games”, < 
http://complexityblog.com/blog/index.php?itemid=57 > (8 Jul. 2014) 
http://www.hobbygamedev.com/articles/vol11/math-for-videogame-making-or-will-i-need-to-use-calculus/
http://www.hobbygamedev.com/articles/vol11/math-for-videogame-making-or-will-i-need-to-use-calculus/
14 
 
Analítica, Lenguajes de Programación, o Graficación por Computadora, podrán comprender 
mejor el concepto matemático en el cual se basan los videojuegos y cuya complejidad originó el 
diseño de herramientas como los game engines que por su arquitectura permite rediseñar y 
reutilizar módulos para alcanzar las simulaciones deseadas dentro de un proyecto. 
 
Estructura de la Investigación 
 
La metodología empleada en la elaboración de este trabajo pretende establecer una forma de 
lograr un desarrollo o tener un producto terminado, y para ello es necesario comprender en 
primer término la complejidad matemática que representa un videojuego al definirlo como una 
simulación interactiva, exponiendo los distintos conceptos que lo acompañan como modelos y 
sistema dinámicos, así como la aplicación de asignaturas como álgebra lineal y geometría 
analítica. Posteriormente se analizará el concepto de game engine a fin de puntualizar la 
necesidad de su diseño de manera integral a su arquitectura a nivel computacional habida 
cuenta que este sistema viene a significarse como una herramienta de desarrollo fundamental 
dentro de la industria del videojuego. 
 
Se expondrá brevemente los diseños arquitectónicos que se han implementado en el desarrollo 
de game engines, y se explicará por que se ha seleccionado a UNITY3D como herramienta de 
trabajo detallando su interfaz gráfica, así como las ventajas y desventajas de tener una 
arquitectura basada en componentes. 
 
Al estar familiarizados con esta herramienta de desarrollo, finalmente se describirá de forma 
puntual los componentes que UNITY3D provee para la simulación de la física de objetos; 
posteriormente se explicará cómo comenzar el diseño, la codificación y la ejecución de los 
objetos y funciones principales que conforman un videojuego. 
 
 
15 
 
Capítulo I 
El concepto matemático de videojuego y el origen de game engine 
 
Ha transcurrido poco más de medio siglo desde que el primer videojuego fue desarrollado con 
un solo objetivo en la mente: el entretenimiento. A lo largo de la historia de esta industria, los 
desarrolladores se enfocaban en diseñar diferentes tipos de patrones en donde el reto para los 
usuarios consistía en memorizarlos y sobrevivir el mayor tiempo posible para poder alcanzar un 
puntaje mayor en cada intento. Como resultado de la evolución tecnológica, el hardware 
resultante proporcionó herramientas para poder realizar desarrollos cada vez más complejos. 
 
Los desarrolladores utilizaron estas tecnologías para programar "mundos" virtuales; es decir, 
simulaciones de un mundo real. Para lograr este nuevo objetivo, se diseñaron modelos 
matemáticos, cambiando para siempre la perspectiva que se tenía de un videojuego, 
considerándolo ahora científica y matemáticamente como una simulación de computadora 
basada en agentes interactivos en tiempo real. 
 
1.1 El concepto de modelo y simulación 
 
En la mayoría de los videojuegos, gran parte del mundo real o imaginario es construido en un 
lenguaje matemático y lógico para alcanzar una aproximación certera de una realidad 
simplificada. Se comprende que el modelado12 es el proceso necesario para diseñar un objeto, 
(denominado modelo), que permita representar matemáticamente un sistema de interés capaz 
de observar los distintos resultados derivados de los cambios o eventos que se apliquen en él; 
otra característica importante del desarrollo del modelo es que su operación no debe de ser tan 
compleja, ya que esto impediría entenderlo y experimentar con él. 
 
Además de ser una aproximación, este modelo incorpora la mayor cantidad de características 
salientes; dicho en otras palabras, contiene todas las posibles variables de salida y lo más 
significativo, es que el modelo es lo más similar al sistema que representa y a la vez más simple. 
Tanto la aproximación como la simplificación equivalen a dos de las herramientas más 
poderosas con que cuentan los desarrolladores, que al saber explotarlas pueden crear modelos 
simplificados indistinguibles a la realidad. 
 
Cabe destacar que una simulación no se construye, sino que realmente se diseña un modelo en 
el cual se realiza una simulación13. Así, una simulación es considerada como una herramienta 
útil para la evaluación del comportamiento de cualquier sistema, existente o propuesto, bajo 
diferentes configuraciones del modelo diseñado y con periodos de tiempo muy largos. 
 
Al tener clara la diferencia entre un modelo y una simulación, se aprecia que los modelos a 
desarrollar pueden ser distintos entre sí, tomando en consideración el sistema al que se necesite 
enfocar, ya sea en Ciencias Naturales como Física, Biología o Meteorología, en aplicaciones de 
Ingeniería tales como Inteligencia Artificial o en Ciencias de la Computación, o bien en Ciencias 
Sociales en ramas como Economía, Sociología o Ciencias Políticas. En el caso de los videojuegos, 
los modelos que se desarrollan son basados en agentes. 
 
 
 
12 Quarteroni, A. (2009). Mathematical Models in Science and Engineering. Recuperado el 2 de agosto del 
2014 de http://www.ams.org/notices/200901/tx090100010p.pdf13 Institute for Simulation & Training (2014). Just what is "simulation" anyway?. Recuperado el 2 de agosto 
del 2014 de http://www.ist.ucf.edu/background.htm#modeling 
16 
 
 
1.1.1 Modelos basados en agentes y sistemas dinámicos 
 
Un modelo basado en agentes14 es un tipo de modelo computacional enfocado en la simulación 
de interacciones de agentes autónomos. Un agente puede definirse como una entidad discreta 
que tiene su propio comportamiento y un objetivo a cumplir; y lo más importante, que es 
autónomo, lo que significa que tiene la capacidad de adaptarse y modificar su comportamiento. 
Al momento de construir un ABM (Agent Based Model por sus siglas en inglés), se requiere 
considerar los procesos o reglas que dirigirán las interacciones entre los agentes; y para esto hay 
que ponderar las siguientes cuestiones: 
 
Se ha mencionado con antelación que los agentes tienen comportamientos propios (estados 
internos), catalogados como atributos o datos; estos pueden ser representados por variables 
discretas o continuas. 
 
Una vez definidas las variables de estado, el comportamiento del agente puede ser definido 
como un autómata de estado determinado (o una máquina de estado finito), entendido como 
un modelo computacional capaz de efectuar cómputos de manera automática sobre una 
entrada con la intención de producir una salida. 
 
Este modelo está integrado por los siguientes elementos: 
 
• Un alfabeto 
• Un conjunto de estados finitos 
• Una función de transición 
• Un estado inicial, y 
• Un conjunto de estados finales. 
 
Su actividad se sustenta en una función de transición, la cual recibe a partir de un estado inicial, 
una cadena de caracteres pertenecientes al alfabeto; es decir, a la entrada, y que va leyendo 
dicha cadena a medida que el autómata avanza, desplazándose de un estado a otro para 
finalmente detenerse en un estado final o de aceptación, lo cual viene a representar la salida. 
 
El objetivo de los autómatas finitos es la de reconocer lenguajes regulares, que corresponden a 
los lenguajes formales más simples, esto atendiendo la corriente doctrinaria enarbolada por 
Chomsky15. 
 
Así, un estado de transición se dará en el momento en que un agente interactúe con otro agente. 
 
Cuando la aplicación de un ABM es más sofisticada, se necesita un comportamiento más allá de 
un autómata de estado determinado, esto con la inclusión de capacidades de acceso a memoria 
al azar. Esto les permite almacenar descripciones y representaciones de su ambiente 
(Inteligencia Artificial y / o Teoría de Juegos). 
 
El rango de las interacciones de nuestros agentes también debe ser específico y pueden incluirse 
los siguientes factores: 
 
14 Schank, J. (2010). Agent-Based Models, methodology and philosophy. Recuperado el 3 de agosto del 
2014 http://www.agent-based-models.com/blog/2010/03/30/agent-based-modeling/ 
15 NOTA DEL AUTOR: La jerarquía de Chomsky denominada también como la jerarquía de Chomsky–
Schützenberger. Es una clasificación jerárquica de distintos tipos de gramáticas formales que generan 
lenguajes formales. Esta jerarquía fue descrita por Noam Chomsky en 1956. 
https://es.wikipedia.org/wiki/Gram%C3%A1tica_formal
https://es.wikipedia.org/wiki/Lenguaje_formal
https://es.wikipedia.org/wiki/Noam_Chomsky
https://es.wikipedia.org/wiki/1956
17 
 
 
• Interacción global (cada agente interactúa con todos los demás agentes). 
• Interacción local (cada agente interactúa con ambientes locales de otros agentes). 
• Interacción local con cierto alcance global (red de mundos pequeños). 
 
El comportamiento de los agentes es determinado por reglas. Estas reglas van desde un simple 
predicado lógico hasta algoritmos que contienen miles de línea de código. 
 
El sistema evoluciona con el tiempo. Las interacciones de los agentes toman lugar en un 
determinado orden. Este orden, en un principio, no es secuencial ya que los agentes se 
comparten de manera individual en paralelo uno con el otro. 
 
En este caso, tiempo y espacio pueden ser discretos o continuos. 
 
La representación matemática de un ABM deviene en un sistema dinámico16, y consiste en un 
estado de fase abstracta o un espacio de estado, cuyas coordenadas describen el estado en 
cualquier tiempo y una regla dinámica que especifique el futuro inmediato de todas las variables 
de estado, dando solamente los valores presentes de esas mismas variables de estado. A manera 
de muestreo, se tiene que el estado de un péndulo es su ángulo y la velocidad angular, y la 
evolución de la regla es la ecuación de Newton 𝐹 = 𝑚𝑎. 
 
Un sistema dinámico es un espacio de estado 𝑆, un conjunto de tiempos 𝑇 y una regla 𝑅 para su 
evolución, 𝑅: 𝑆 × 𝑇 → 𝑆 que da el consecuente a un estado 𝑠 ∈ 𝑆. Un sistema Dinámico es 
considerado como un modelo describiendo la evolución temporal de un sistema. 
 
Los sistemas dinámicos poseen un tiempo discreto o continuo. Por ejemplo, un sistema 
determinístico con tiempo discreto es definido por el siguiente mapeo 
 
𝑥1 = 𝑓(𝑥0), 
 
donde obtenemos el estado 𝑥1 resultado del estado inicial 𝑥0 en el siguiente valor de tiempo. 
Después del tiempo “𝑛” obtenemos lo siguiente 
 
𝑥𝑛 = 𝑓𝑛(𝑥0), 
 
donde 𝑓n es la enésima iteración de 𝑓. Un sistema determinístico con tiempo continuo es 
definido por un fluido 
 
𝑥(𝑡) = 𝜑𝑡(𝑥(0)), 
 
que da el estado en un tiempo 𝑡, dado que el estado fue 𝑥(0) en el tiempo 0. Un fluido suave es 
diferenciado con respecto al tiempo para dar la ecuación diferencial, 𝑑𝑥/𝑑𝑡 = 𝑋(𝑥). La función 
𝑋(𝑥) es llamado campo vector, describiendo la dirección de la velocidad en cada punto en el 
espacio de fase. 
 
Ahora bien, un ABM, desde el punto de vista computacional, es programado en cualquier 
lenguaje, donde el paradigma de programación17 orientado a objetos18 es el más apropiado, esto 
 
16 Recuperado el 1 de agosto del 2014 de http://www.scholarpedia.org/article/Dynamical_systems. 
17 IBM Smalltalk Tutorial. What is Object-Oriented Programming?. Recuperado el 13 de agosto del 2014 
de http://www.inf.ufsc.br/poo/smalltalk/ibm/tutorial/oop.html#oop 
18 Object-Oriented Programming o OOP por sus siglas en inglés. 
18 
 
debido a que el concepto de objeto es similar al concepto de agente. En otras palabras, al definir 
una clase en POO se está diseñando el comportamiento de un agente, donde el modo de 
interacción con otros agentes se realiza a través de la herencia misma. 
 
En los videojuegos los agentes son objetos diversos, como armas, vehículos, personajes 
(principal o secundario), entre otros. ya que cada uno tiene su propio comportamiento; por 
ejemplo, con los vehículos, su objetivo puede ser el mismo que es transportar, pero el 
comportamiento cambia dependiendo si es un automóvil, un avión o un barco, cada uno 
interactúa de diferente manera con otros agentes como el agua o el aire ya que no se desplazan 
de la misma manera. En el caso de objetos como armas, la acción de disparar cambia 
dependiendo de sus características físicas, que a su vez afectará su relación con el protagonista 
(o demás personajes del juego) en su estado de movimiento. 
 
Los videojuegos también son considerados sistemas dinámicos. El estado del videojuego, el 
mundo virtual, cambia a cada momento, es decir, mientras la historia se desenvuelve el aspecto 
de los personajes, escenarios y otros objetos ya no es el mismo, y estos sucesos ocurren en 
tiempo real. Estos estados también son manipulados por las entradas, que tienden a ser 
impredecibles, dado que proceden de los jugadores, por ello, que estos sistemas son 
considerados como simulaciones interactivas en tiempo real. 
 
El hecho de que los videojuegos sean simulaciones en tiempo real significa que garantizan una 
respuesta dentro de restricciones estrictas de tiempo usualmente llamadas plazos, o deadlines. 
Es decir, uno de los requerimientos críticos en el desarrollo de un sistema de tiemporeal es su 
performance en el manejo de recursos (hardware y software). El cumplimiento de estos plazos 
se convierte, por tanto, en procesos de planificación que se estructuran de dos formas. 
 
• Procesos Periódicos 
• Procesos Aperiódicos. 
 
Los procesos periódicos, como su nombre lo indica, se ejecutan de una manera regular. Están 
caracterizados por: 
 
• Su periodo. 
• Su plazo que usualmente es igual al periodo. 
• Su tiempo de ejecución requerido (por periodo). 
 
El tiempo de ejecución se da en términos de una medida promedio. Por ejemplo, dentro de un 
videojuego, es un requerimiento que la pantalla se actualice cada 24 veces por segundo para 
crear la ilusión de movimiento (algunos juegos dibujan la pantalla entre 30 y 60 cuadros o 
frames19, por segundo, porque estos son múltiplos de la frecuencia de actualización de un 
monitor NTSC.).Estos plazos no sólo se limitan a dibujar escenas en pantalla, sino también se 
observan en simulaciones físicas, donde se requiere una actualización de 120 veces por segundo 
a fin de mantenerse estable; un personaje con inteligencia artificial necesitará “pensar” cada 
segundo para prevenir acciones incongruentes o la librería de audio deberá ser llamada cada 
1/60 segundos para mantener los buffers de audio llenos y prevenir pérdida de audio dentro del 
juego. 
 
 
19 Klappenbach,M. (2014).Understanding and Optimizing Video Game Frame Rates. Recuperado el 17 de 
Agosto del 2014 de http://compactiongames.about.com/od/Overclocking-and-
Performance/a/Understanding-And-Optimizing-Video-Game-Frame-Rates.htm 
19 
 
Cada segundo, durante la ejecución de estos procesos, en promedio equivalen a 100 
milisegundos de tiempo del CPU. 
 
Los procesos aperiódicos son esencialmente un evento al azar y son usualmente activados por 
una acción externa al sistema. Estos procesos también tienen asociadas restricciones de tiempo, 
ya que son completadas en un periodo de tiempo predefinido. Aunque a menudo estos procesos 
tratan con eventos críticos dentro del ambiente del sistema, sus plazos no son rigurosos, aunque 
la ejecución de éstos no deja de tener relevancia. 
 
Ahora bien, los sistemas en tiempo real dependiendo de los requerimientos de sus plazos se 
clasifican en dos: 
 
• Sistemas de tiempo real rígidos 
• Sistemas de tiempo real suaves. 
 
Los sistemas de tiempo real rígidos son aquellos cuyos plazos son críticos. El fallo en el 
cumplimiento del plazo desencadena más que un error en el dominio de valores. Los requisitos 
de tiempo de respuesta en estos sistemas están dados en milisegundos o menos. Este tipo de 
sistemas permanecen sincronizados con todos los estados del ambiente en todos los casos; 
además, contienen pocos archivos de datos y bases de datos de tiempo real. Una manera 
frecuente de revisar las necesidades temporales es a través de simulaciones y con diferentes 
algoritmos de pruebas. Algunas aplicaciones de estos sistemas se encuentran en controles de 
tráfico aéreo, controles de mando o sistemas multimedia en red. En la ilustración 1 se aprecia 
un ejemplo de un sistema de tiempo real rígido. 
 
 
Ilustración 1 El radar utilizado en los aeropuertos para controlar el tráfico de las aeronaves es un claro ejemplo de la 
aplicación de sistemas de tiempo real rígidos, en donde no pueden existir errores de sincronización. Imagen: 
http://s03.s3c.es/imag/_v0/635x300/6/1/4/indra_pantalla_control_aereo.jpg 
 
Por otro lado, en los sistemas de tiempo real suaves, los plazos no alcanzados carecen de un 
resultado catastrófico. En este tipo de sistemas es muy difícil garantizar que todos los plazos se 
cumplan; por tanto, de lo que se trata es minimizar el número de plazos que se perderán. En 
este rubro, garantizar el cumplimiento de todos los plazos deviene en una tarea imposible; esto 
se debe a que los procesos o tareas que se ejecutan son muy complejos y resulta difícil predecir 
con exactitud cuánto tiempo se tardarán en ejecutar o qué recursos se necesitarán. A nivel base 
de datos, el tiempo de búsqueda dependerá de las transacciones que se están ejecutando en el 
20 
 
momento y mantienen un bloqueo. Las aplicaciones que se catalogan bajo este apartado son 
propiamente los videojuegos, habida cuenta que, si algún proceso no concluye en su plazo 
determinado, no hay una pérdida critica; claro está, el jugador no morirá o sufrirá una pérdida 
grave, sólo terminará el juego o se quedará parado en algún ciclo. Otro ejemplo de este sistema 
es la aplicación empleada en la venta de boletos de las aerolíneas, donde si los plazos de los 
procesos resultan afectados, la pérdida se refleja en el tiempo de espera de la transacción o 
simplemente no se finaliza la transacción de compra. La ilustración 2 ilustra un error en un 
sistema de tiempo real suave. 
 
 
Ilustración 2 Un error dentro de un sistema de tiempo real suave en los videojuegos ocurre cuando los procesos 
encargados de dibujar las escenas u objetos no completan sus plazos de ejecución. Imagen: 
https://image.redbull.com/rbcom/010/2015-01-09/1331698786896_2/0010/1/1600/1067/1/assassin-s-creed-
unity.jpg 
1.2 Matemáticas Aplicadas en los videojuegos. 
 
Las simulaciones o videojuegos contienen reglas para que todos sus objetos convivan entre sí, 
además de tener un comportamiento propio. Las bases de estas reglas son las matemáticas, 
mismas que al ser implementadas por los desarrolladores, crean acciones tan simples como el 
movimiento de un objeto. 
 
Los videojuegos más sencillos son presentados en dos dimensiones, donde el movimiento de los 
objetos es de izquierda a derecha, o bien de arriba abajo. Esta acción es resultado de la 
implementación del Álgebra de Vectores. 
 
Un vector es una cantidad que tiene magnitud, dirección y sentido, en el desarrollo de 
videojuegos se comprende como cambio de posición de un objeto por medio de la suma o resta 
de vectores. 
 
 
Ilustración 3 Representación gráfica de cambio de posición. Imagen: 
https://www.gamedev.net/uploads/monthly_03_2013/ccs-208401-0-75174000-1363382404.png 
https://www.gamedev.net/uploads/monthly_03_2013/ccs-208401-0-75174000-1363382404.png
21 
 
La acción de posicionar un objeto A hacia un objeto B, es posible por medio de la substracción 
de vectores, permitiendo así, conocer la dirección y distancia entre dos objetos de la siguiente 
manera: 
 
 𝑝𝑜𝑠𝑖𝑐𝑖𝑜𝑛_𝑎𝑟𝑏𝑜𝑙 = (10,10,0); 
 𝑝𝑜𝑠𝑖𝑐𝑖𝑜𝑛_𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑗𝑒 = (3,3,0); 
 𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑖𝑎 = 𝑝𝑜𝑠𝑖𝑐𝑖𝑜𝑛_𝑎𝑟𝑏𝑜𝑙 – 𝑝𝑜𝑠𝑖𝑐𝑖𝑜𝑛_𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑗𝑒; 
 
Si se desea cambiar la velocidad con la que un objeto se mueve por segundo, es necesario 
sumar un vector que representen esta propiedad. 
 
 𝑣𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑 = (500,0,0); 
 𝑝𝑜𝑠𝑖𝑐𝑖𝑜𝑛_𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑗𝑒 += 𝑣𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑; 
 
Por último, si se desea “simular” una fricción cuando el objeto se encuentre en movimiento, es 
necesario sumar una vector que represente una fuerza contraria. 
 
 𝑓𝑟𝑖𝑐𝑐𝑖𝑜𝑛_𝑎𝑖𝑟𝑒 = (−2,0,0); 
 𝑣𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑 += 𝑓𝑟𝑖𝑐𝑐𝑖𝑜𝑛_𝑎𝑖𝑟𝑒; 
 𝑝𝑜𝑠𝑖𝑐𝑖𝑜𝑛_𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑗𝑒 += 𝑣𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑; 
 
Para un escenario es tres dimensiones la acción de movimiento se vuelve más compleja, donde 
el desarrollador debe de considerar conceptos de Geometría Analítica como planos y espacio. 
Un ejemplo de su aplicación es la implementación de fuentes de luz dentro del videojuego. 
 
Para iluminar una superficie, es necesario conocer la posición de la fuente de luz, el cual es un 
vector, la posición del punto de la superficie, donde el resultado de su resta es la distancia entre 
ellos, por último, para conocer que parte de la superficie será más brillante, es necesario realizar 
un producto escalar o punto entre esta distancia y el vector normal a la superficie. 
 
Otra aplicación de la Geometría es en la colisión de objetos, por ejemplo, deslizar un objeto 
sobre un plano, para ello es necesario realizar un producto cruz entre vector que representa al 
objetoy el vector normal a la superficie, donde el resultado es otro vector perpendicular a los 
anteriores, y así conocer la dirección a la que se deslizará. 
 
El uso de formas primitivas como triángulos, círculos y cuadrados es indispensable en el 
desarrollo de los videojuegos para el diseño tanto de escenarios como de personajes y 
elementos que interactúan entre sí, ya que al rotar estas superficies sobre un solo eje se 
obtienen cuerpos más complejos, conocidos como sólidos de revolución. Los sólidos básicos que 
se obtienen por medio de estas rotaciones son cilindros, esferas y conos, no siendo los únicos 
pues cualquier plano puede ser rotado dando como resultado distintos objetos. 
 
22 
 
 
Ilustración 4 Ejemplos de Sólidos de Revolución. Imagen: https://www. 
http://mathworld.wolfram.com/SurfaceofRevolution.html 
Otras asignaturas que son aplicadas en el desarrollo de videojuegos son: 
 
• Cálculo. 
• Matemáticas Discretas. 
• Trigonometría. 
• Teoría de Gráficas. 
 
Algunas de las aplicaciones dentro del diseño del videojuego son: 
 
• Animación. 
• Arquitectura de Game Engines. 
• Scripts de Gameplay. 
• Física de objetos. 
• Implementación de gráficos y texturas. 
• Inteligencia Artificial. 
• Diseño de niveles de manera procedural. 
 
 
 
El perfil matemático de un desarrollador de videojuegos es de gran importancia, para 
comprender la complejidad de los distintos cálculos que se realizan durante la ejecución de las 
simulaciones, y entender en que momento se debe de aplicar para obtener los resultados 
esperados. 
 
Con base a lo anterior, los videojuegos poseen un fuerte sustento matemático y son 
considerados simulaciones suaves interactivas computacionales basados en agentes de tiempo 
real. En ese orden de ideas, válidamente se concluye que estos modelos y simulaciones 
requieren de arduo trabajo al momento de ser codificados, impulsando a los programadores a 
buscar nuevas formas de optimizar y reutilizar sus códigos, además de minimizar el tiempo de 
codificación. Esto los condujo a diseñar y desarrollar programas que contaran con las 
herramientas necesarias para sus simulaciones; es decir, el diseño de librerías, que al mismo 
tiempo se modificarán a la par que la industria de los videojuegos, que cada vez más, demandará 
https://www.gamedev.net/uploads/monthly_03_2013/ccs-208401-0-75174000-1363382404.png
https://www.gamedev.net/uploads/monthly_03_2013/ccs-208401-0-75174000-1363382404.png
23 
 
juegos o simulaciones con mayor realismo. Estos programas son lo que hoy en día conocemos 
como game engine20. 
 
1.3 Definición de un game engine 
 
Antes de los años 90’s, los primeros videojuegos eran desarrollados y diseñados pensando en 
un uso óptimo del hardware; es decir, todo era construido a partir del kernel21 que viene a 
significarse en el programa principal de un sistema operativo. Esto permitía a los desarrolladores 
tener control sobre el procesamiento de datos y el manejo de memoria. El producto final, a nivel 
de programación, era único ya que no era posible la reutilización de los componentes que ya se 
habían realizado con anterioridad para un nuevo proyecto, debido a las mismas limitaciones de 
memoria que se tenían, por lo que aún no era posible la implementación de un software que les 
ayudara con dicha tarea. 
 
Posteriormente, los desarrolladores cambiaron su manera de diseñar y desarrollar juegos al 
trabajar en un ambiente en tres dimensiones; comenzaron por hacer dos distinciones básicas. L 
a primera, sobre el contenido que tendría el producto final; es decir, elementos con los que 
interactúan los usuarios, tales como armas, vehículos y personajes por mencionar sólo algunos; 
la segunda consistió sobre aspectos de física y lógica que se implementarían en el desarrollo del 
videojuego, como la colisión entre objetos y la inteligencia artificial además de la renderización22 
de gráficos. 
 
En general ésta es la idea principal de un game engine, un framework23 que les permita a los 
desarrolladores poder trabajar por separado con varias tareas para posteriormente unificarlo 
todo en un solo proceso; además de poder tener un control entre el software y el hardware 
necesarios para un mejor resultado. Pero lo más importante, su diseño les permite la 
reutilización de código, así como la reimplementación de métodos. 
 
Desde el inicio, los diseñadores de game engines como herramientas de desarrollo evitaban su 
manufactura con un propósito en general; o, dicho en otras palabras, si se tenía como objetivo 
crear un juego de carreras que sería reproducido sobre un hardware con determinadas 
características, con posterioridad la herramienta ya no se podría reutilizar si las especificaciones 
del hardware cambiaban para el siguiente proyecto o bien para cuando se requería realizar otro 
tipo de videojuego. Como tal el game engine dejaba de ser óptimo. 
 
Por esta razón, hoy en día pueden desarrollarse juegos de peleas, carreras o de acción con una 
sola herramienta. Aun así, existen varios game engine dentro de la industria del videojuego; 
cada uno con distintas características, entre otras, como el uso de distintos lenguajes de 
programación, métodos para la simulación en la física de objetos en dos y tres dimensiones, así 
como en su interfaz gráfica para los programadores. Una de las más importantes se basa en su 
comercialización; es decir, las herramientas que fueron desarrolladas para uso exclusivo de las 
compañías, y las herramientas cuyo código es liberado para que otros desarrollares puedan 
 
20 Ward, J. (2008). What is a Game Engine?. Recuperado el 8 de Agosto de 2014, de 
http://www.gamecareerguide.com/features/529/what_is_a_game_.php 
21 The Linux Information Project (2005). Kernel Definition. Recuperado el 9 de Octubre de 2017, de 
http://www.linfo.org/kernel.html 
22 NOTA DEL AUTOR: Renderización proviene del término ingles render; que es usado en terminología 
informática para referirse al proceso de generar una imagen o video mediante el cálculo de iluminación 
partiendo de un modelo en 3D. Este término técnico es utilizado por los animadores o productores 
audiovisuales y en programas de diseño en 3D. 
23 Shinde, Dnyanesh (2015).What is a framework in programming?. Recuperado el 9 de Octubre de 
2017, de https://www.quora.com/What-is-a-framework-in-programming 
https://es.wikipedia.org/wiki/Anexo:Jerga_inform%C3%A1tica
https://es.wikipedia.org/wiki/Gr%C3%A1ficos_3D_por_computadora
24 
 
mejorarlos e implementar nuevos métodos. Como se mencionado antes, este trabajo de 
investigación se enfoca en el game engine UNITY 3D, el cual se explicará con mayor amplitud en 
capítulos posteriores. 
 
1.4 Arquitectura de un game engine 
 
El objetivo principal de un game engine, además de la reutilización de código, es separar tareas 
como métodos e interfaces. Desde esta perspectiva, el diseño de su arquitectura es sustentado 
en el manejo de datos24, es decir, se tiene una parte con código abstracto que son todos aquellos 
métodos y procesos que se encargan del manejo de memoria, uso del CPU o de la tarjeta gráfica, 
estos son utilizados posteriormente por medio de scripts como archivos XML25 o bien archivos 
de música y video, los cuales describen distintos tipos de datos. En la ilustración 3 se muestra la 
estructura básica de un game engine, en donde, la capa superior contiene los procesos y 
métodos encargados de la administración del hardware, esta capa es responsabilidad de los 
programadores, mientras que la capa inferior consumirá los recursos del hardware por medio 
de scripts definidos por los diseñadores 
 
 
Ilustración 3 Estructura básica de un Game Engine. Imagen: 
https://i.pinimg.com/originals/64/84/e7/6484e712cab874227c62c3b83a41ed10.jpg 
 
Esta arquitectura conlleva una estructura de trabajo que permite al equipo de desarrollo 
dividirse en áreas, tomando en consideración su especialización; esto es, que un programador 
únicamente se enfoque en procesos parael manejo de la inteligencia artificial, la física de los 
objetos, la renderización de gráficos o el manejo de dispositivos de entrada y salida en el 
hardware. 
 
Por otro lado, los diseñadores que se encargan del contenido del juego como personajes y 
vehículos además de implementar acertijos, objetivos y decidir cómo será la interacción con el 
usuario. 
 
Y por último los artistas encargados de crear todo el arte en los escenarios, manejo de efectos 
de luz y cámara, implementan estos métodos para darle forma al videojuego. 
 
 
24 Wilson, K. (2002). Data-Driven DESIGN. Recuperado el 17 de Agosto del 2014 de 
http://gamearchitect.net/Articles/DataDrivenDesign.html 
25 PC Magazine. (2014). Definition of XML. Recuperado del 17 de Agosto del 2014 de 
http://www.pcmag.com/encyclopedia/term/55048/xml 
25 
 
En otras palabras, el diseñador y el artista no se preocupan por la lógica que lleva la inteligencia 
artificial implementada o cómo es que se dibujan las texturas en los árboles o montañas; así 
como el programador tampoco se preocupa por diseñar vehículos o escenarios. Como se 
aprecia, esta arquitectura es la que diferencia a un game engine de un software común. 
 
El diseño de los game engines, así como de la mayoría de los softwares, está basado en capas 
donde sus niveles superiores dependen de las inferiores; esto obedece a una regla 
preestablecida, ya que de lo contrario ocurriría una dependencia circular, la cual volvería 
inestable a la herramienta de desarrollo, además de evitar la reutilización de código. La 
ilustración 4 muestra la arquitectura de estas capas en tiempo de ejecución. 
 
 
Ilustración 4 Diseño basado en capas de un game engine (en donde la capa superior consumirá los recursos 
proporcionados por las capaces inferiores, creando así una dependencia lineal). Imagen: Gregory, James. Game 
Engine Architecture Pág. 29. 
 
De lo anterior, se observa que la arquitectura de un game engine es realmente grande, donde 
sus capas inferiores son las encargadas del manejo de hardware, memoria y redes, así como las 
superiores del aspecto visual, estético y físico en los objetos del juego. A continuación, se expone 
una explicación general de cada una de ellas. 
 
1.4.1 Hardware, sistema operativo y drivers 
 
Cuando se comenzaron a desarrollar los videojuegos, los diseñadores disponían de un solo 
hardware en donde ejecutarlos; con el paso del tiempo lograron que un solo desarrollo pudiera 
ejecutarse en diferentes consolas, plataformas o dispositivos móviles, cada una con distintos 
controles, y sistemas operativos. Es por ello que estas capas son las encargadas del manejo de 
los recursos del hardware, previniendo problemas como la comunicación entre las capas 
superiores y los drivers (programas que proveen las interfaces necesarias para la comunicación 
26 
 
entre hardware y software), así como la organización de las diferentes tareas en el sistema 
operativo con lo cual se evitó que el juego tome control total de la plataforma. 
 
1.4.2 Middleware y SDKs 
 
Al existir una gran diversidad de componentes que integran a un game engine, los 
programadores en la mayoría de los casos deben auxiliarse de otras aplicaciones para la 
implementación de redes, inteligencia artificial, animaciones o audio por mencionar sólo 
algunos. Estos softwares son conocidos como middleware, los cuales también se apoyan de 
herramientas para el desarrollo de software26, en los lenguajes de programación como C, C++ o 
Java se les conoce como librerías27 por virtud de las que se realizan referencias a distintos 
métodos que permitan el manejo de estructuras de datos. 
 
 
1.4.3 Independencia de Hardware 
 
La función esencial de esta capa es mantener un comportamiento consistente en el hardware, 
sin importar si el juego será ejecutado en plataformas como consolas o dispositivos móviles. 
Verifica la portabilidad del código implementando en la capa del middleware, de esta manera el 
software resultante será compatible en el dispositivo en donde sea ejecutado. 
 
1.4.4 Núcleo del Sistema 
 
Dentro de esta capa se encuentran códigos, métodos y archivos de configuración que son 
indispensables para el funcionamiento del game engine. Es aquí donde se encuentran todas las 
funciones matemáticas para vectores y matrices, rotaciones de quaterniones, operaciones 
trigonométricas; además una parte vital son los métodos implementados para el parseo de 
archivos XML que contienen la información de objetos modelados y animados importados de 
otros game engine. 
 
1.4.5 Recursos 
 
Como su nombre lo indica, en esta capa se encuentran todos los recursos necesarios para el 
videojuego, entre otros, texturas, modelos en tres dimensiones, propiedades físicas además de 
diferentes tipos de datos de entrada. Estos son presentados como una suite de interfaces, 
accediendo a ellas por medio de paquetes28, o bien de clases propias del game engine. 
 
1.4.6 Motor Gráfico 
 
Uno de los componentes de mayor trascendencia y complejidad dentro de un game engine es 
el motor gráfico29, el cual cuenta con una arquitectura propia, constituida de la siguiente 
manera: 
 
 
26 Joshi, Rahul (2015). What is the meaning of “SDK”?. Recuperado el 9 de Octubre de 2017 de 
https://www.quora.com/What-is-the-meaning-of-SDK 
27 What is the meaning of API? Recuperado el 9 de Octubre de 2017 de https://www.quora.com/What-
is-the-meaning-of-API 
28 Daconta, Michael (2014). What is a package in Java?. Recuperado el 9 de Octubre de 2017 de. 
https://www.quora.com/What-is-a-package-in-Java-2 
29 Slick, J. (2014). What is Rendering?. Recuperado el 20 de agosto del 2014 de 
http://3d.about.com/od/3d-101-The-Basics/a/Rendering-Finalizing-The-3d-Image.htm 
27 
 
1.4.6.1 Procesador de bajo nivel 
 
Es aquí donde el diseño se enfoca en renderizar una colección de figuras geométricas conocidas 
como primitivas30, como cuadrados, triángulos, torus, cilindros o cubos, los cuales permiten 
crear figuras más complejas; es decir, polígonos, vértices y aristas. Además, aquí se encuentran 
librerías como DirectX y OpenGL que facilitan el manejo y la manipulación de la tarjeta gráfica. 
Otras funciones de las cuales se encarga esta capa, es la implementación de un sistema de 
materia y luz dinámica, que se encargan de generar una textura específica para las figuras 
primitivas y el cálculo dinámico de las luces que deben llevar para obtener un efecto de 
sombreado. 
 
1.4.6.2 Escenario Gráfico 
 
En tanto que en la capa anterior se dibujan todas las figuras geométricas sin importar en qué 
espacio visual se generarán, el escenario gráfico se encarga de calcular el espacio que ocuparán. 
Esta operación la realiza a partir de una subdivisión espacial31, la cual consiste en subdividir un 
espacio en celdas en donde se almacenarán los objetos geométricos anteriormente acumulados 
en estructuras de datos, lo que permitirá detectar colisiones entre las figuras cuando se realiza 
una animación o bien eliminar objetos cuando la cámara no los detecte dentro de la escena. 
 
1.4.6.3 Efectos Visuales 
 
Para completar la escena o animación que se esté generando, se implementarán los efectos 
visuales como fuego, humo o lluvia para lograr un efecto realista; esta capa cuenta con sistemas 
de partículas, luz, mapeos de luz, ambiente y corrección de colores. 
 
1.4.7 Fundamentos del Gameplay 
 
Dentro de este componente se encuentran las reglas del mundo virtual, así como los objetos 
que lo conforman; así su funcionamiento viene a significarse como puente entre el código con 
la lógica del juego y los sistemas de bajo nivel en el game engine. En esta capa se encuentra el 
sistema de eventos que es el que permite la interacción entre objetos, vehículos, personajes, 
cámara y luces, pero además la interacción con el usuario por medio del GUI32 que se 
implemente, así como el sistema de escritura33; este sistema es el que permite realizar cambios 
en

Continuar navegando