Hace mucho tiempo tenía pensado hacer varios informes post mortem de cada uno de los proyectos, pero no quería rendirme y traté de seguir programando para terminarlos, pero salían mas y mas errores, eso fue desanimándome y al final terminé rindiéndome, sin embargo ahora es definitivo desde que me pasé al nuevo sistema operativo #ZorinOS, viendo que es poco probable que sea instalable en este sistema, pues ya es hora de dar este informe.
Durante el tiempo que comencé a programar en #Unity desde el año 2012 hasta ahora, he cometido todos los errores posibles y de todos ellos he aprendido un montón, las tres lecciones principales son: No perder el tiempo, medir el riesgo y hacer las cosas hasta la medida de mis capacidades. A continuación voy a mencionar todos los errores que logre recordar y a separarlos en varios blogs, porque son demasiados.
1. Antes de hacer un juego, desarrolla primero la historia y los personajes.
Si tu idea de juego es presentar algo #cinematográfico, entonces primero escribe la idea y has el #guion, diseña los personajes como si fueras a escribir un libro o un #comic, pues es mas fácil que la ejecución de un videojuego fracase que a que lo haga un libro, al menos así te queda algo que puedas mostrar.
2. Los lenguajes del motor son importantes al momento del fracaso.
Evita los motores que dicen tener un lenguaje propio similar a X lenguaje, pues como es propenso a que el proyecto fracase, al menos que te vayas con un aprendizaje útil, un lenguaje que puedas usar en proyectos de tecnología, lo mismo aplica para motores que usan lenguajes poco usados o muy antiguos como Lua, Ruby, fortran, COBOL, Basic.
3. Prototipar, prototipar, prototipar.
Muchas veces cometí el error de centrarme en el arte del videojuego, simplemente porque me chirriaba los ojos ver cubos de colores planos sirviendo como plataformas, todo esto improvisado, sin medidas establecidas, por tanto los saltos no se correspondían las distancias ni las plataformas.
Eso me enseño a que debo #prototipar, crear objetos que funcionen como una medida o un patrón, crear objetos que simulen determinadas funciones, luego eso hará que sea mas fácil centrarse en el arte sin perder tiempo.
4. El diseño modular es el rey en todo lo que diseñes o desarrolles.
La idea detrás de este enfoque es que todo funcione como pequeños ladrillos que apilas de manera consciente para construir algo mas grande, esto puede ser aplicado a los objetos del juego, como a pequeñas porciones de código.
Pensar así a largo plazo te hace ahorrar tiempo, en lugar de hacer un escenario al estilo sastre donde todo encaja para ese personaje y que el mas mínimo error, lleva a rediseñar todo el nivel por completo.
Lleva esa filosofía a lo que sea que hagas, funciona prácticamente para todo y aunque en un principio puede ser difícil es posible que logres terminar aquello que te propongas.
5. Es mas rentable usar tus propias herramientas, que comprar otras que no entiendas.
Un error muy común que cometía es que me descargaba herramientas maravillosas de la tienda del Unity, para darme cuenta de que muchas eran difíciles de usar, no se integraban bien con el proyecto y actualizarlo era pesado.
Al final siempre terminaba usando mis soluciones no muy elegantes, pero prácticas porque se adaptaban mejor al proyecto.
6. Es mas importante la jugabilidad que el diseño artístico.
Yo sé que todo entra por los ojos y que la calidad visual influye mucho en la elección de cualquier producto, esto puede llevarnos a engaños, cuando era un idiota pensaba solo en términos de sí esto es bueno o mal y no pensaba en términos de función, #jugabilidad, calidad visual, calidad sonora etc. Cuando desarrollas algo, jugar ya se convierte en juzgar y empiezas a ser mas consciente de lo que sientes como consumidor. La lección que me quedó es que la funcionalidad prima por encima del diseño, puede verse muy bonito y tener una calidad sonora fenomenal, pero si jugablemente es una pesadilla, de nada habrá servido todo ese esfuerzo.
7. Un buen diseño facilita la optimización que empezar optimizando.
Si algo ya está bien pensado y diseñado, tiene un principio y un final claro, es mas fácil abordarlo y pensar en soluciones prácticas que permita alcanzar los objetivos, de esta forma solo gastas los recursos necesarios. Caso contrario si algo está mal diseñado, empezaras a optimizar desde un inicio, no sabras a ciencia cierta los recursos que vas a gastar, perderas mucho tiempo y esfuerzo que no valdrá de nada.
8. Elegir un motor acorde a la exigencia del proyecto.
Yo elegí Unity por ser un motor profesional multipropósito, pero muchas veces solo quieres hacer un RPG clásico o un juego RTS o una novela gráfica o simplemente jueguitos arcade sencillos, para esto Unity está sobredimensionado y cada año que pasa, Unity es mas y mas complejo, pesado, demora mas en abrir, compilar y todo esto es tiempo que pierdes que pudieras haber ahorrado si hubieras elegido un motor modesto acorde a tus habilidades, aunque tambien debes comparar el gasto que gastarás aprendiendo un nuevo motor o una nueva tecnologia.
9. Una estética simple y bien hecha, es funcional y envejece mejor.
En mi apego a la perfección, siempre traté de ir hacia una estética realista, craso error, pues con el tiempo te das cuenta de que lograr el realismo, hace que los detalles sean mas difíciles de tratar, usas mas archivos, todos los detalles alrededor de este son mas exigentes y demandantes. Con el tiempo la gente notará mas los errores y se percibirá como feo.
Es mejor buscar una estética que evite que pierdas tiempo en detalles y a la vez que resalte el enfoque de tu juego, pues el jugador mentalmente le dará licencia a lo que es modesto y no trata de engañarlo.
10. Un estilo cartoon hace mas tolerable los errores de animación.
Un estilo usado comúnmente es el estilo low poly o cartoon, yo personalmente prefiero este último, pues siento que el low poly pasará de moda rápidamente. El estilo cartoon envejece mejor, permite darte licencias de diseño, puedes hacer una animación menos natural, un guion mas fantástico, mas cómico, usa menos texturas, las físicas son mas fáciles de programar.
La desventaja es que no te guste el estilo o que te limite a la hora de hacer historias mas serias y oscuras.
11. Es mas fácil hacer la animación que comprarla.
Antes yo era de los que compraba assets de animación en la tienda de Unity, pero esto puede dar problemas con el componente animator, porque puede no ir la animación en el sentido que quieras, puede que solo quieras una animación estática en el punto de partida o que quieras una animación que se mueva en el espacio y eso es muy difícil de saberlo.
Muchas veces no puedes comprar una animación individual, sino que viene en un pack con varias animaciones de las cuales solo te sirve unos pocos.
Editar una animación es muy difícil, generalmente hay que hacer limpieza de nodos, sobre todo si viene de otro programa de modelado distinto al que usas siempre.
12. Es mas fácil modelar los objetos tu mismo que comprarla.
Al igual que con las #animaciones, lo mismo ocurre con los #modelos, cuando los compras muchas veces el estilo artístico no encaja o las proporciones del modelo no se ajustan a tus reglas, le faltan texturas o le sobran, resultando a veces mejor hacer los modelos de forma mas artesanal, pero con personalidad y que se ajusten mas a tus reglas.
13. Elige 2D en lugar de 3D, pues te ahorraras muchos problemas.
Un eje extra supone problemas elevados al cubo, por eso es mejor un juego de dos dimensiones, son mas simples, y mas entretenidos, mas fáciles de ejecutar, mas fáciles de entender para el jugador, terminas mas rápido y aun así puedes tardar años en terminar un juego, pero en mucho menos tiempo que si se tratara de un juego en tres dimensiones.
14. Si empiezas un proyecto en una versión del motor, nunca lo actualices.
Un error que cometí dos veces en proyectos distintos, pensando que mas es mejor, o pensando que mas actual solucionaba alguno de los bugs de tu proyecto. Es mentira, siempre una nueva versión te genera mas bugs que los pocos que pueda arreglar, por ningún motivo cambies de versión o elige un motor mas estable en las versiones.
15. Crear una consola o modo debug te ayudará mucho con los tests.
Cuando ya tengas a tu personaje con las mecánicas principales es recomendable hacer un modo debug o una consola, donde puedas recibir información del estado del personaje, puedas alterar la posición del jugador, puedas modificar a voluntad la vida o cualquier otro parámetro del jugador, esto te facilitará probar el escenario con mayor profundidad y encontrar bugs mas rápido, de ser posible y si las habilidades te alcanzan poder modificar el escenario en tiempo real y poder guardar los cambios en caliente, esto facilitará un diseño de niveles mas dinámico y que algún amigo te ayude y proponga cambios mas entretenidos.
16. Usa las herramientas del mismo motor, no quieras solucionarlo todo con código.
Tuve un tiempo que llegaba a programar hasta las animaciones, fisicas, inteligencia artificial y herramientas de optimizacion con código. Esto es una progamitis aguda en el que estaba inventando un motor dentro del mismo motor y esto es absurdo, eso solo quiere decir que el motor no se adapta a tus necesidades.
Cambia de motor o aprende a adaptarte a las herramientas que se te ofrece y profesionalízate en ellas.
Conclusiones.
Se me ha hecho bastante largo este blog y cada día parecen mas largos, pero este tema tenía pensado hacerlo por cada proyecto, se puede decir que este es el resumen de 50 errores que he cometido como desarrollador y las 50 lecciones que he aprendido, actualmente me ha cambiado la manera de pensar y de abordar los proyectos pequeños que me aparecen actualmente, quedando bien y siendo mas profesional.
Espero que estos consejos te sirvan y si tienes alguno mas que pueda aportar, por favor compártelo y en un futuro haré un compilado de los consejos que ustedes puedan aportar.
No siendo mas muchas gracias y nos vemos en un próximo blog con mas errores.
Comments