6 pensamientos sobre Gamedev antes del desayuno (1)
06-01-2017 5:31 AM
- Gamedev se refiere a game development, que se traduce en programación de juegos. Como cualquiera que esté dedicado a gamedev sabe, el inglés es tan omnipresente no solamente porque la mayoría de los foros están en inglés y porque toda la documentación está en este lenguaje, sino además porque las herramientas usan este lenguaje, y fueron desarrolladas originalmente en inglés. Finalmente, sacar al mercado un juego sin una versión multilenguage (que muestre textos, instrucciones y controles en inglés, además del español) es un suicidio de mercadeo. Así, tal como debes saber como programador (o si eres un buen programador que se ufana de serlo, como todos hacemos) el inglés no es necesidad, es obligatorio.
- Estaba leyendo este comentario en reddit: “You also have to have a good grasp of project management and planing. If your game code and assets are a mess 30% into the development time, you will have a very hard time to keep the discipline and your progress will slow” (“Usted también tiene que tener una buena comprensión de la gestión del proyecto y el planeamiento. Si el código del juego y los recursos son un desastre al 30% en el tiempo de desarrollo, usted pasará un difícil rato para mantener la disciplina y su progreso va a ser lento”). Me llamó la atención la consecuencia de la falta de planeamiento: es difícil mantener la disciplina. Cualquiera que entre en el mundo de gamedev sabe que la gestión del proyecto es fundamental porque son demasiados componentes, demasiadas tareas (tasks) que hay que hacer, y si el juego es un mmo, o un juego que requiera 20+ horas para completarlo (desde el punto de vista del jugador), es casi imposible llevar el control y que las cosas no se desordenen. Y cualquiera en medio de un desorden pierde la calma, el desorden se incrementa exponencialmente y las cosas se salen de control. El desarrollo se hace lento y cosas pasan.
- En la misma onda del comentario anterior: “Si el código del juego y los recursos son un desastre” ¿es posible evitar esto con planeamiento? Lo dudo. A menos que seas Niko, quien tiene en su haber 18 productos publicados, un motor gráfico, 2 juegos, etc. psyblast tiene pululando al menos 4 años en mi baúl de zombies y decir que el código es un desastre es al mismo tiempo injusto y una buena aproximación a la realidad. Yo soy 7/8 project manager (no certificado pero con al menos 30 proyectos de más de 200 horas) y escribo documentación para psyblast cada vez que trabajo en él. El año pasado, 2016, me senté 96 veces a trabajar en el proyecto (implica 96 días diferentes, un 27% de los días del año si mi matemática es correcta) lo cual implicó al menos 300 horas de trabajo. Yo no sé ustedes pero 300 horas de trabajo es plata. Dinero. Enero de 2016 tuvo 18 entradas en mi bitácora, estamos a 6 de enero 2017 y ya llevo 4, así que me imagino que mantendré mi performance del año pasado. Sin embargo, a pesar de todo este tiempo, se puede leer en la bitácora cosas como lo siguiente: “Why CMmgr class instance is a member of CGui, m_mmgr?” (¿por qué una instancia de CMmgr es un miembro de la clase CGui? Debería ser un apuntador, o ambas clases deberían ser friend, no sé.
- Por ejemplo. ¿Cómo están organizadas las clases en psyblast? Correcto. No están organizados. Alguna vez tenían un diseño Componente-Entidad, pero en este momento las clases están organizadas en grandes bloques de código super especializados CGui que maneja la interacción con el jugador, CMmgr que maneja los modelos pero también manipula el comportamiento de los npcs, CNpcInt que maneja la interacción de los npcs. En mi bitácora se lee por todas partes “tengo que corregir esto” porque en el fondo se que algo tengo que hacer para seguir las mejores prácticas, como aplicar diversos paradigmas según el caso, por ejemplo un enfoque Model-View-Controller. Pero, eso entra en contradicción con el tiempo de entrega, que debe mantenerse en “pronto”.
- Lo cual me lleva a la lentitud del desarrollo que es algo tan difícil de explicar a alguien que no sabe nada de los intrilinguis de todo lo anterior, como explicármelo a mí. Me quedé atascado en julio pasado porque un boss se estaba desplegando mal en el juego, y podía ser por una multitud de razones, blender, el plugin que exporta el modelo, o que no estaba generando las animaciones correctamente, etc. Hace un par de días descubrí que la armature (el esqueleto) estaba rotado 90° en las X’s, y que algunos huesos tenían un roll diferente de 0°. Porqué no me dí cuenta de eso el año pasado que parece tan obvio es un misterio. Ayer el código que detecta que no hay obstáculos entre el player y un npc estaba fallando, y luego de una hora debugueando aquí y allá descubrí que en la llamada a la función cmgr->rayIntersect (start…) el start debe corresponder al npc no al player, de otra forma el resultado es cualquier cosa. ¿Qué tiene que ver esto con el planeamiento? Nada, resolver estos problemas toma tiempo, y no se puede planificar no tener estos problemas, hay que tener la disciplina para abordarlos y resolverlos sin ceder al impulso de tirar todo esto y llevar una vida divertida (pero vacía) sin el endemoniado gamedev. Por otro lado, ¿tener las clases mejor organizadas evitará estos problemas? Tampoco. ¿Y entonces? Ya lo dije, hay que tener paciencia y disciplina, el resto se deriva de aquí. Quizás mi mentalidad tropical juega en mi contra, es posible que Niko en bavaria quizás tiene los genes y el ambiente flemático que se requiere para mantener el ritmo en un proyecto que toma tiempo para completarse. Quizás.
- La mentalidad tropical se caracteriza por la urgencia de resultados inmediatos ignorando los pasos que se requieren para completar una tarea. Como todo en la vida, hay que tener paciencia y disciplina. O, dicho de otra forma, quizás, como el campesino que tenía un caballo, un hijo y unos vecinos que se apresuraban a decir lo bueno de tener un caballo, lo malo de perder un caballo, lo bueno de recuperar el caballo, lo malo de que tu hijo se rompa una pierna montando el caballo, lo bueno de que como tu hijo se rompió una pierna ya no tiene que ir al ejército. Bueno. Malo. Quizás y quizás. No hay nada que pueda contra la paciencia y disciplina.