Desarrollar videojuegos es un camino largo, se requiere aprender mucho de los errores que vamos cometiendo en los juegos que vamos realizando. Ya que normalmente nuestros primeros juegos no serán exitosos.
Para disminuir los errores es que he creado este artículo.
Seguir leyendo 8 Errores que cometemos los desarrolladores de videojuegos indieCreo que llegó el momento de definir nuevamente mis objetivos con respecto a Indie Libre. Estos meses que han pasado quizás son para mi los más duros en cuanto a mi situación aquí en Venezuela. No entraré en detalles porque mi intención no es generar lastima, sino, por lo menos ahora, decirles por encima por qué estoy inactivo en todas las redes.
Seguir leyendo Regresando con Indie libreDesde hace ya más de un mes se anunció que la plataforma de GitHub pasaría revisión y probablemente bloquearía a los desarrolladores que vivieran en países sancionados por Estados Unidos.
Esto me pareció muy malo. Si bien no me habían suspendido, considero poco ético que lo hagan sólo con gente de países marcados. Había escuchado por muchas partes que después de la adquisición de GitHub por Microsoft, las cosas iban a cambiar en dirección a la filosofía de esta ultima empresa, y, por tanto, el Software Libre debería moverse a otras plataformas que brindaran más libertad y estuvieran “bien” desde un punto de vista ético.
No hice caso de estas advertencias, y podría seguir sin preocuparme. Como dije desde el principio: no me gusta que sólo le pasen lupa a países como el mío, Venezuela. Tenía planeado seguir manteniendo repositorios en GitHub y además abrir una especie de “tienda” aquí en Indie Libre, donde pudiera ofrecer los mismos repositorios con algunas guías únicas. Sería como una forma de recibir donaciones, de algún modo.
Cree una cuenta en la plataforma de SourceForge, pero no me sentí cómodo con su interfaz. Además, la creación de proyectos es un poco más tediosa que en GitLab o GitHub. Durante ese tiempo hubiera intentado otras alternativas, pero coincide con una apretada de tuercas que nos dieron en mi ciudad. Estuve (y sigo) sin Internet, casi que sin agua y con pocas horas de electricidad. Así pasaron días y días, sin embargo, he podido regresar a este blog. Está pasando mucho tráfico, personas interesadas en temas sobre Godot o GNU/Linux que me gustaría traer, y lo haré. Mientras viva no dejaré de trabajar aquí.
Decidí seguir con el proyecto de la “tienda de Assets” donde guardaré el código fuente de mis proyectos. Por ejemplo Sunny Land, así las personas que no quieran hacer inmediatamente el curso de YouTube, podrán descargar con una donación el código fuente del proyecto. Me parece algo sustentable que no rompe con mi ideal de no privatizar la educación. Sin embargo, quizás también abra repositorios en GitLab.
Entonces me toca despedirme. Ya saben más o menos mi estado, y algo que es muy importante: el destino de los repositorios con las cosas que he desarrollado. Quizás mantenerlos sólo en Indie Libre sea peligroso, si la muerte me alcanza no estaría bien que el material se pierda. Paralelamente a este servidor, probablemente guarde en GitLab un respaldo.
Sin más que decir (por lo menos en esta nota), nos vemos pronto familia. Estoy haciendo todo lo posible por trabajar nuevo contenido, me sorprende que hasta el día de hoy, mucha gente me siga teniendo paciencia.
Después de una pausa por cuestiones de salud (toda la semana pasada estuve enfermo) vuelvo con el desarrollo de este proyecto (Juego de Estrategia basada en turnos con Godot). Les dejaré una lista con los avances que hasta el momento pude realizar.
No fueron muchos cambios importantes, espero que durante esta semana pueda avanzar en la interfaz de usuario. Necesito hacer algo bonito para el menú de selección de edificios, la información de recursos del jugador y otros detalles.
Un dato interesante es que los experimentos para medir el rendimiento del proyecto no bajaron de 59fps hasta que llegó el momento de mostrar las casillas viables. Cuando la unidad a la que se hace clic tiene más de 15/20 movimientos disponibles, hay una bajada de veinte o más fps. Generalmente ninguna unidad supera los diez movimientos, ya que se cuentan otras cosas como el coste de movimiento según la casilla, por lo que esta imperfección estará eclipsada.
Entonces cierro por hoy. Sepan que si bien el desarrollo del repositorio apunta a la interfaz de usuario esta semana, también dejaré espacio para abrir una nueva línea independiente sobre la generación de mundos aleatorios (procedural generation) en github. Avisaré cuando llegue el momento, ¡buena suerte compañeros!
¿Cuándo será el día en que pueda publicar un artículo DevLog con relativa constancia?
Muchas semanas han pasado desde que les hablé de mi proyecto de “juego de plataformas”, tanto que ya se encuentra desarrollado y con su curso publicado en YouTube, aunque seguro ya eso lo sabían.
Escribiendo estas lineas me enorgullece anunciarles que he progresado en el desarrollo de un proyecto “BTS” juego de “estrategia basada en turnos”, que reemplazará a mi antiguo «curso» de prácticamente el mismo género, que dejé a medias por falta de dedicación y obsolescencia de los métodos que usé para desarrollarlo.
Sin embargo el proyecto de estrategia pasado, tenía el género “RTS”. Estos días, cuando intenté introducir la nueva versión, me aclararon que hay una diferencia entre “RTS” (Real Time Strategy) y “BTS” (Based turn Strategy), por lo que resolví el detalle y continué con el desarrollo, enfocando ahora todas las características para un juego de turnos.
Estoy emocionado porque después de días enteros estudiando código de referencia y tratando de entender muchas cosas, he podido avanzar un montón y conseguir un resultado estructurado, comentado y limpio, para compartirles.
Pasaré entonces con la lista de novedades, basándome en las “actualizaciones de estado” que compartí en Twitter la semana pasada. Después de eso, hablaré un poco sobre los próximos movimientos respecto al proyecto.
¿Sabes qué es? Esta es de las cosas más interesantes que haya podido estudiar para este proyecto. Es algo a lo que seguro le sacaré el jugo después de estudiarlo a profundidad: la generación de mundos aleatorios. Fue lo primero que me propuse aprender a implementar y hasta ahora tiene un buen resultado, aunque puede pulirse.
En mi lista de actualizaciones, esto fue lo segundo. Intenté muchas formas de movimiento entre Tiles hexágonales tratando de usar Navigation2D. El mejor resultado fue el recurso AStar: un algoritmo que incluye Godot para formar puntos en diferentes partes y buscar las mejores rutas de uno a otro.
Esto es lo más reciente: hice un nodo modelo para la construcción de edificios y empecé a experimentar con la interfaz de usuario. Además, en ese vídeo verán como sigue el estado del movimiento, ahora con una cantidad limitada. Los mundos se generan de una forma diferente, incluyendo zonas de agua.
Sólo estas tres características van a necesitar de mucho tiempo para explicarse como es debido en una serie de vídeos . No he calculado cuántos vídeos me harían falta para respaldar al recurso AStar o la generación de mundos aleatorios, pero serán varios (aún con vídeos «cortos»). En los próximos días abriré un repositorio de GitHub para los patreons de Indie Libre, así como el anuncio de la nueva campaña para este proyecto.
Las comunidades digitales son un escape para muchas personas. Es una forma de compartir lo que nos gusta con gente igual a nosotros, que pueden apreciar esa cosa donde invertimos nuestra dedicación y tiempo.
Dentro de la plataforma Facebook se encuentran muchas comunidades relacionadas con el arte digital, la programación, vídeojuegos (tanto jugadores como desarrolladores), PixelArts o retoque fotográfico. Prácticamente cualquier software que sea usado por muchas personas alrededor del mundo, tiene su propia comunidad en Facebook, con miembros que buscan aprendizaje u opinión sobre sus avances en algún tema. Incluso todo eso se podría juntar para resumir la necesidad del ser humano en socializar.
La interacción entre los miembros de una comunidad tiende a ser respetuosa y solidaria, las personas dan por sentado que sólo se comunicarán con compañeros que comparten sus mismos intereses. El racismo, machismo o necedad, prácticamente están ausentes, cada quien nota el talento y los avances del otro, y eso lo respetan, porque lo han vivido. Los usuarios más experimentados pueden recurrir a una publicación novicia y ofrecer consejos, así como los mismos novatos tratarán de explicar algún concepto acorde a su nivel de conocimiento, ayudando a alguien que lo necesite y aprendiendo, porque no hay mejor forma de comprender algo, que intentar enseñarlo a alguien más.
Antes, las comunidades digitales se formaban en torno a los foros, plataformas donde los recursos se catalogan hasta formar como una gran biblioteca, basada en el conocimiento de cada miembro. Hoy en día se ha tomado el sendero más efímero, además de Facebook también se podrían mencionar las comunidades de Reddit, Amino, o cualquier red social similar.
Hasta ahora todo esta bien, o eso parece para nosotros. Las redes sociales generan una actividad diaria muy elevada. Si María comparte algo, por ejemplo una entrevista de algún artista, después de 48 horas es muy probable que aunque bajemos y bajemos en la bandeja de publicaciones, no encontremos el enlace de María. El mismo caso se puede aplicar en los miembros que buscan aprendizaje: si hacen una pregunta sencilla o complicada, después de una semana o incluso algunos meses, llegará otra persona y preguntará lo mismo, generando que los mismos usuarios participes en aquel primer momento, u otros nuevos, tengan que repetir una respuesta, perdiendo tiempo que podrían invertir en otra cosa.
El concepto de los foros esta hoy muriendo, podemos tomarlo y adaptarlo a los intereses actuales si cambiamos su enfoque: tomar lo mejor de una red social, un sitio web especializado y la vieja biblioteca. Así conseguiremos, quizás, una comunidad próspera y muy productiva, que puede servir como fuente de conocimiento, colaboración y amistad, entre todos nosotros.
La semana pasada ingresamos al congelamiento de lanzamiento con Godot 3.1 beta 1, y desde entonces se han corregido muchos informes de errores de alta prioridad. Ahora estamos publicando una nueva instantánea beta 2 para que los evaluadores trabajen. Esta nueva versión corrige varios escenarios de fallo, así como una regresión del rendimiento en el backend de GLES.
Todavía estamos apuntando a un lanzamiento a finales de mes, por lo que estamos bajo un calendario apretado. A partir de ahora, el enfoque de desarrollo se centra en los problemas críticos de la versión que obstaculizarían seriamente la facilidad de uso y las características de Godot 3.1.
Al contrario de nuestras versiones de mantenimiento 3.0.x, que incluyen solo correcciones de errores compatibles con versiones anteriores y revisadas a fondo, la versión 3.1 incluye todas las nuevas características (y errores posteriores) fusionadas en la rama maestra desde enero de 2018, y especialmente todas las que se muestran en nuestros devblogs pasados Ha pasado casi un año desde el lanzamiento de la versión 3.0 y cerca de 6,000 cambios, ¡así que espere muchas cosas buenas en la versión 3.1 final!
Y una pequeña nota para los usuarios de C#: Godot 3.1 beta 2 ahora incluye mono 5.18 en lugar de 5.16. Todavía está incluido, por lo que no necesita actualizar su sistema mono.
IMPORTANTE: esta es una versión beta, lo que significa que no es adecuada para su uso en producción, ni para revisiones de prensa de lo que Godot 3.1 estaría en su lanzamiento.
Todavía habrá muchas correcciones hechas antes del lanzamiento final, y necesitaremos sus informes detallados de errores para depurar problemas y solucionarlos.
Las notas de la versión ya están redactadas, pero no queremos arruinar la sorpresa del anuncio de la versión 3.1 ;). Mientras tanto, puede consultar el registro de cambios detallado que mantiene nuestro colaborador Hugo Locurcio, así como los devblogs anteriores.
Los redactores de documentación están trabajando duro para ponerse al día con las nuevas características, y la última rama ya debería incluir detalles sobre muchas de las nuevas características 3.1. Juan agregó varios tutoriales sobre las nuevas características 3.1 la semana pasada (mallas 2D, esqueletos 2D y documentación de AnimationTree).
Los enlaces de descarga no se muestran en la página de descargas para evitar confusiones para los nuevos usuarios. En su lugar, navegue por nuestro repositorio de descargas y obtenga las plantillas de exportación y binario del editor que coincidan con su plataforma y el sabor de Godot:
Este artículo es una traducción del anuncio oficial, puedes visitar el original aquí: https://godotengine.org/article/dev-snapshot-godot-3-1-beta-2
La imagen de la ilustración es una captura de pantalla del primer juego de Miskatonic Studio, Intrepid, un juego de ciencia ficción que se lanzó el mes pasado. Steam, Twitter.
Ya hace más de un mes que nuestro alfa anterior, pero mientras tanto no hemos estado inactivos. Se han realizado cientos de correcciones y mejoras en la rama maestra, que nos complace ofrecerles como Godot 3.1 alfa 3. Esta nueva instantánea de desarrollo nos acerca un paso más a la etapa beta, que deberíamos alcanzar antes de navidad.
Al contrario de nuestras versiones de mantenimiento 3.0.x, que incluyen solo correcciones de errores compatibles y revisadas a fondo, la versión 3.1 incluye todas las características nuevas (¡y errores subsiguientes!) Fusionadas en la rama maestra desde enero de 2018, y especialmente todas las que se muestran en nuestros devblogs pasados Han pasado más de 10 meses desde la versión 3.0 y más de 5,000 cambios (commits), ¡así que espere muchas cosas buenas en la versión final 3.1!
La etapa alfa nos corresponde a una congelación de características (ver anuncio en GitHub), lo que significa que ya no consideraremos solicitudes de extracción con nuevas características para fusionar en la rama maestra, y eso hasta que se libere Godot 3.1. De esta manera, podemos centrarnos en lo que ya tenemos, finalizar y pulir las características principales que aún están en progreso (por ejemplo, la compatibilidad con OpenGL ES 2.0) y corregir muchos de los errores antiguos y nuevos informados por la comunidad.
Las instantáneas de desarrollo se seguirán publicando regularmente para probar continuamente la rama maestra y asegurarse de que siga siendo más estable, confiable y lista para la producción.
IMPORTANTE: esta es una compilación alfa, lo que significa que no es adecuada para su uso en producción, ni para revisiones de prensa de lo que Godot 3.1 estaría en su lanzamiento.
Todavía hay un largo camino para corregir errores y mejorar la usabilidad hasta que podamos lanzar la versión estable. Esta versión es exclusiva para probadores que ya están familiarizados con Godot y pueden informar los problemas que experimentan en GitHub.
Tampoco hay garantía de que los proyectos iniciados con la compilación alfa 3 sigan funcionando en compilaciones posteriores, ya que nos reservamos el derecho de hacer los ajustes de ruptura necesarios hasta la etapa beta (aunque los cambios de compatibilidad en esta etapa deberían ser mínimos, si los hubiera).
Nota: Los nuevos usuarios de Godot no deben usar esta versión para comenzar su aprendizaje. Godot 3.0.x es nuestra rama estable actual y aún recibe actualizaciones frecuentes.
Las notas de la versión aún no están escritas, pero puede consultar el registro de cambios detallado en el que está trabajando nuestro colaborador Hugo Locurcio.
Como se mencionó anteriormente, nuestros devblogs anteriores también deberían darle una idea de los aspectos más destacados del próximo lanzamiento.
Este alpha 3 viene con una impresionante cantidad de correcciones de errores en todo el motor, con Juan pasando la mayor parte del mes de noviembre enfocándose en eso. Vea esta publicación de Patreon para obtener detalles sobre lo que sucedió desde el alfa 2
Los redactores de documentación están trabajando duro para ponerse al día con las nuevas características, y la última rama ya debería incluir detalles sobre muchas de las nuevas características 3.1.
Los enlaces de descarga no se muestran en la página de descargas por ahora para evitar confusiones para los nuevos usuarios. En su lugar, navegue por uno de nuestro repositorio de descargas y obtenga las plantillas binarias y de exportación del editor que coincidan con su plataforma:
IMPORTANTE: haga copias de seguridad de sus proyectos Godot 3.0 antes de abrirlos en cualquier versión de desarrollo 3.1. Una vez que se haya abierto un proyecto en 3.1, su archivo project.godot se actualizará a un nuevo formato para asignaciones de entrada que no es compatible con Godot 3.0; este último se negará a abrir un proyecto 3.1. Además, el uso de las nuevas características 3.1 en su proyecto significa que no puede volver a la versión 3.0, a menos que haga el trabajo necesario para eliminar el uso de esas características. Entonces, pruebe 3.1-alpha3 en una copia de sus proyectos 3.0 o inicie nuevos proyectos con él.
Todavía hay cientos de informes de errores abiertos para el hito 3.1, lo que significa que ya estamos conscientes de muchos errores. Sin embargo, muchos de esos problemas pueden no ser críticos para la versión 3.1 y pueden volver a dirigirse a una versión posterior para permitir la liberación de Godot 3.1 en un futuro próximo.
Como probador, se recomienda que abra los informes de errores si experimenta problemas con 3.1 alfa. Compruebe primero los problemas existentes, utilizando la función de búsqueda con palabras clave relevantes, para asegurarse de que el error que experimenta no se conoce ya.
La imagen de la ilustración es de Guegemem de Samuele Zolfanelli, un juego en 2D de excelente aspecto desarrollado para el juego A Game By Its Cover 2018. Se acerca una gran actualización, ¡asegúrate de seguir su trabajo!
El anuncio oficial de Godot 3.1 alpha 3 se encuentra en: https://godotengine.org/article/dev-snapshot-godot-3-1-alpha-3
La semana pasada se publicó UltraSpaceShips RPG. Un juego de naves que nos ofrece mecánicas originales y diferentes modalidades. Su principal desarrollador, Matías Muñoz Espinoza, instructor en Youtube y Udemy, se animó a compartir un poco de su experiencia como programador y desarrollador de vídeojuegos.
Mi nombre completo es Matías Valentín Muñoz Espinoza y estos últimos años me he dedicado en su mayor parte al desarrollo de videojuegos. Tengo un canal de youtube (FuryCode) y formo parte de un equipo (FuryGames), en FuryGames inicialmente era yo solo, pero ahora somos más y vamos avanzando.
FuryCode empezó primero, fue el 9 de noviembre del 2012 (Fue el primer video del canal), empece con algo de desarrollo web (no tenía mucho conocimiento, pero aprendía mientras hacía los videos) el primer curso fue de Sass y Compass, Sass es un preprocesador de CSS y Compas es un framework. Para no hablar mucho de esto digamos que Sass es un lenguaje encima del CSS que se traduce (transpila) a CSS, creo que actualmente se usa bastante y es recomendable su uso.
Y FuryGames fue después, fue mas o menos en mayo del 2016. Y FuryGames a tenido muchos intentos de ser un grupo estable de desarrollo, en cuanto a personas, pero es algo que cuesta bastante. Sobre todo si no tienes dinero que ofrecer y puedes ofrecer solo un porcentaje de participación en los desarrollos, normalmente ofrecía un porcentaje equitativo. Sin muchas reglas y con muchos ánimos. Pero después con el tiempo uno se va dando cuenta que esto de tener grupos de desarrollo es un tema muy complejo, de mucha motivación, etc.
No me considero extremista del Open Source, pero es algo que me gusta bastante. También soy usuario de Linux, tanto que, no tengo Windows ni lo he tocado desde hace mucho tiempo, de hecho me confundo un poco en Windows. Como Godot es un proyecto Open Source y a la vez Software Libre, es algo que me gusta mucho, funciona muy bien con Linux y es algo que se estaba esperando. Hace tiempo no habían engines (con editor) que funcionaran en Linux, o por lo menos no eran tan maduros como Godot Engine.
Godot al principio fue mera curiosidad, antes use un tiempo LibGDX, que es un framework. Y me di cuenta que Godot Engine agiliza mucho el trabajo, en LibGDX me tomaba siglos un par de cosas que se podían hacer en poco tiempo en Godot Engine. Aunque es verdad que hay gente que quiere hacer todo en código, yo les digo a esas personas que no es necesario hacer todo en código, hay trabajo muy tedioso y repetitivo que sea hace en un framework, la idea de los engine es disminuir ese trabajo tedioso y repetitivo. Y ¿Códear?, al final terminas codeando más del 70% en Godot Engine, osea usando un Engine no te deshaces de codear sino que del trabajo repetitivo.
Al principio fue por experimentar mecánicas distintas, se me ocurrió eso de que las naves enemigas y las balas tengan gravedad en una jam. Era una Jam de pocas personas que creamos con unos amigos de Discord. Un saludo para ellos…
Bueno en esa Jam se creó el primer prototipo, que fue en una semana. El juego esta en itch.io como Ultra Spaceship Shooter.
Después de eso trate de hacer el mismo juego pero ponerle cosas RPG, solo algunos elementos RPG, “No iba a ser la gran cosa decía yo” y al final termine desarrollando un plugin para facilitar la lógica de los juegos RPG.
El segundo juego (Spaceship Shooter RPG Deluxe) no lo hice solo, me ayudaron en muchas cosas, sobre todo con la parte gráfica. También programación, un chico que luego desapareció.
En realidad formar un equipo no es difícil, lo que cuesta en realidad es mantener el equipo y cumplir objetivos. Para eso hay que tratar de ser lo mas organizado posible, y no desistir. Claro que puedes tomarte un tiempo de descanso, pero, también después hay que volver.
No soy para nada una persona exitosa, pero tengo algo experiencia en equipos remotos. Por mera práctica. Y lo que recomendaría para un equipo remoto, sería:
1) Un líder que ponga las tareas y que nunca se canse, y motive al equipo. Resuelva conflictos mas que provocarlos.2) Cuando hayan conflictos tratar de que el grupo no se disuelva.
3) Usar herramientas de gestión de proyectos, como podría ser HackNPlan.
4) No ser tóxico, las cosas siempre se puede decir de buenas palabras.
5) Avanzar a pesar de que no todos pueden dar el mismo tiempo de trabajo.
6) Usar GIT.
7) Usar Google Drive o/y Dropbox.
8) Hablar las cosas antes de que sucedan
La verdad que costó bastante tiempo. Estaba tratando de desarrollar la idea y tuve algunos problemas con el proyecto por usar versiones de Software inestable (La alpha de Godot 3.1).
Aunque el proyecto en equipo empezó el 30/05/2018 y salió la primera versión en el 31/10/2018 evidentemente hubieron muchos tiempos de descanso y de poca participación, también hubo un mes que me tome para hacer el curso de GDScript en Godot Engine.
Bueno personalmente me enredé un poco en el tema de los ítems, la tienda y esas cosas. No sabía bien como almacenar los items en disco, recuperarlos, etc. Por eso aislé el problema y lo hice un plugin, liberando el código a toda la comunidad.
Pero no hay nada que no se pueda resolver con un papel y lápiz, y esto aunque parezca una práctica no tan importante, es vital. De hecho hay una frase que dice “Resuelve el problema, luego escribe el código”. No digo que siempre haya que cumplirlo, pero cuando uno se ve complicado, es bueno hacerlo.
Sí, claro, tengo varios proyectos en Itch.io y en Google Play. Actualmente estoy participando en la jam de GithubGameOFF con un juego de monstruos.
La verdad, es difícil, en Google Play hay mucha competencia. Cada día salen más y más aplicaciones. Si uno no tiene los medios para el marketing lo único que queda es tratar de hacer un buen producto y que guste. Y esto no es para nada fácil.
La verdad el tráfico orgánico es lo que mas me ha dado resultado hasta el momento, aunque aún así todavía no hay buenos resultados.
Bueno, no quiero deprimiros con Google Play pero el tema es que hay que seguir y tarde o temprano se cosecha lo que se siembra. Hay gente que le va muy bien con los juegos en Google Play, pero me imagino que solo pocos, muy pocos, les ha ido bien a la primera.
¡Mal! ¿No es suficiente con preguntar lo de Google Play?. Por ahora Itch.io lo veo como portafolio, pero no es malo. Siempre hay gente que le va bien en esas cosas, pero es algo complicado. También tiene opciones muy interesantes como Jams y devlogs.
Por su puesto, es un engine que cada vez me gusta más y cada vez me da mejores resultados.
Por ahora no… Pero en el desarrollo de videojuegos hay que pensar a largo plazo.
Claro, como pudieron ver no soy la persona mas exitosa del mundo, pero si he aprendido varias cosas.
1) Si eres nuevo no hagas proyectos grandes, lo normal es que tengas una mala experiencia con ellos y los dejes abandonados. Es mucho mas motivador terminar cosas pequeñas que muy probablemente no terminar algo muy grande. Puedes ir aumentando de a poco y de paso hacerte portafolio.2) El desarrollo de videojuegos es golpearse contra la pared varias veces, donde la pared es la realidad. Es un tema en el cuál hay que aprender mucho de varias cosas, para lograr buenos resultados. Mucha práctica.
No le hagas asco a las demás áreas. Si eres bueno programando no le hagas asco a la música o al arte o al marketing. Con esto me refiero a que sepas un poco de todo, esto te servirá mucho. Si haces el peor pixel art del mundo, por lo menos es -tú- pixel art y eso se valora mucho.3) Usa Git o un sistema de control de versiones: Esto te ayudará a no perder el proyecto y a recuperar cosas que “perdiste”.
4) Usa un administrador de proyectos: HackNPlan o Trello, estan muy bien, pero se organizado. Esto aumenta mucho la productividad. Aumentar la productividad es también un tema de engañar a tu cerebro.
Aprende de los demás: Ve videos, escucha mas que hablar, hay gente que le va bien que tiene mucho que decir y hay gente que no le va tan bien que también tiene mucho que decir.
5) Filtra bien las críticas: Hay críticas que son sólo para hacer daño y hay críticas que son constructivas. Por lo general las críticas que son dañinas son sólo eso, dañinas, no muestran cosas positivas de tu juego. No pierdas el tiempo con ellas. Siempre hay algo positivo. Por muy malo que sea tu juego siempre se puede rescatar algo. Las criticas constructivas tienen el componente “ayuda” y se nota. Normalmente te dicen me gusta esto, pero no me gusta esto. Son objetivas.6) Termina los proyectos: No soy el indicado para decirlo, pero es algo que se tiene que aprender. Cuando empieces un proyecto, tiene que ser algo que te motive. Motivación vas a necesitar para terminar el proyecto.
7) Planifica tu proyecto, es algo que he aprendido a porrazos. Si lees esto, avisado estas, no comentas estos errores. Has un GDD (Game Doument Design).
Con esto terminamos esta sesión de preguntas. Muchas gracias Matías por estos consejos. Puedes visitar sus redes sociales con los siguientes enlaces:
Canal de Youtube: https://www.youtube.com/user/ElementalCodeNet
Twitter: https://twitter.com/matias_vme
Facebook: https://www.facebook.com/FuryCode/
Udemy: https://www.udemy.com/aprender-a-programar-para-desarrollar-videojuegos-con-godot/
Recuerda descargar juego UltraSpaceShips recientemente publicado: https://play.google.com/store/apps/details?id=spaceship.shooter.rpg.deluxe.furygames
Dos meses después de nuestra versión alfa anterior, nos complace lanzar Godot 3.1 alpha 2, una nueva versión de desarrollo de la rama maestra, que avanza lenta pero constantemente hacia el estado beta.
Al contrario de nuestras versiones de mantenimiento (3.0.x), que incluyen solo correcciones de errores compatibles con versiones anteriores y revisadas a fondo, la versión 3.1 incluye todas las nuevas características (¡y errores subsiguientes!) Fusionadas en la rama maestra desde enero de 2018, y especialmente todas las que se muestran en nuestros devblogs pasados Han pasado 9 meses desde la versión 3.0 y cerca de 5,000 cambios, ¡así que espere muchas cosas buenas en la versión final 3.1!
La etapa alfa nos corresponde a una congelación de características (ver el anuncio en GitHub), lo que significa que ya no consideraremos solicitudes de extracción con nuevas características para fusionar en la rama maestra, y eso hasta que se libere Godot 3.1. De esta manera, podemos centrarnos en lo que ya tenemos, finalizar y pulir las características principales que aún están en progreso (por ejemplo, soporte de OpenGL ES 2.0) y corregir muchos de los errores antiguos y nuevos informados por la comunidad.
Las instantáneas alfa se publicarán regularmente durante esta fase, para probar continuamente la rama maestra y asegurarse de que siga siendo más estable, confiable y lista para la producción.
IMPORTANTE: esta es una compilación alfa, lo que significa que no es adecuada para su uso en producción, ni para revisiones de prensa de lo que Godot 3.1 estaría en su lanzamiento.
Todavía hay un largo camino para corregir errores y mejorar la usabilidad hasta que podamos lanzar la versión estable. Este lanzamiento es exclusivo para probadores que ya están familiarizados con Godot y pueden informar los problemas que experimentan en GitHub.
Tampoco hay garantía de que los proyectos iniciados con la compilación alfa 2 sigan funcionando en las compilaciones alfa 3 o posteriores, ya que nos reservamos el derecho de hacer los ajustes de ruptura necesarios hasta la etapa beta (aunque los cambios de compatibilidad en esta etapa deberían ser mínimos, en caso de presentarse).
Nota: los nuevos usuarios de Godot no deben usar esta versión para comenzar su aprendizaje. Godot 3.0.x es nuestra rama estable actual y aún recibe actualizaciones frecuentes.
Las notas de la versión aún no están escritas, pero puede consultar el registro de cambios detallado en el que está trabajando nuestro colaborador Hugo Locurcio.
Como se mencionó anteriormente, nuestros devblogs anteriores también deberían darle una idea de los aspectos más destacados del próximo lanzamiento.
Este alfa 2 viene con una cantidad impresionante de correcciones de errores en comparación con el alfa 1. El backend de OpenGL ES 2.0 también ha visto mucho trabajo para empujarlo hacia la finalización de funciones, aún no está hecho, pero se está acercando.
Los redactores de documentación están trabajando duro para ponerse al día con las nuevas características, y la rama más reciente ya debería incluir detalles sobre muchas de las nuevas características 3.1.
Los enlaces de descarga no se muestran en la página de descargas por ahora para evitar confusiones para los nuevos usuarios. En su lugar, navegue por uno de nuestro repositorio de descargas y busque el binario del editor que coincida con su plataforma:
IMPORTANTE: haga copias de seguridad de sus proyectos Godot 3.0 antes de abrirlos en cualquier versión de desarrollo 3.1. Una vez que se haya abierto un proyecto en 3.1, su archivo project.godot se actualizará a un nuevo formato para asignaciones de entrada que no es compatible con Godot 3.0; este último se negará a abrir un proyecto 3.1. Además, el uso de las nuevas características 3.1 en su proyecto significa que no puede volver a la versión 3.0, a menos que haga el trabajo necesario para eliminar el uso de esas características. Entonces, pruebe 3.1-alpha2 en una copia de sus proyectos 3.0 o inicie nuevos proyectos con él.
NOTA: esta versión todavía se llama «3.1.alpha» internamente, igual que alfa 1 y compilaciones diarias desde la rama maestra. Esto significa que las plantillas de exportación comparten la misma carpeta de instalación, pero debe asegurarse de reemplazar cualquier plantilla «3.1.alpha» que haya instalado actualmente con las de la distribución alfa 2.
Debido a algunos problemas del sistema de compilación, alpha2 no tiene plantillas de exportación que funcionen para el objetivo ARM de UWP. Además, las características upnp y websockets faltan por completo en las plantillas de exportación de UWP.
Todavía hay cientos de informes de errores abiertos para el hito 3.1, lo que significa que ya estamos conscientes de muchos errores. Sin embargo, muchos de esos problemas pueden no ser críticos para la versión 3.1 y pueden volver a dirigirse a una versión posterior para permitir la liberación de Godot 3.1 en un futuro próximo.
Como probador, se recomienda que abra informes de errores si experimenta problemas con 3.1 alpha. Compruebe primero los problemas existentes, utilizando la función de búsqueda con palabras clave relevantes, para asegurarse de que el error que experimenta no se conoce ya.
La imagen de la ilustración es del juego FOSS Mystic Treasure Hunt 3D de Krzysztof Jankowski. Puedes leer más sobre su viaje como artista en su blog
Aclaro que esto es una traducción del blog original.
