Paso a paso desarrollando un VideoJuego, aporte a la comunidad
ForoCoches: Miembro
14-feb-2017 14:48
#1
|
Hola a todos, Llevo un tiempo madurando la idea de hacer un videojuego. Creo que ya tengo los ingredientes necesarios, es cuestión de echarle el tiempo a implementar. Hasta ahora he estado empapándome de los estándares, posibilidades reales y distintos frameworks. Este tema lo voy a ir utilizando como pequeño cuaderno de vitácora y para que escuchar a todos los shurs que quieran unirse o echarme una mano. El videojuego que tengo en mente es un plataformas con elementos de RPG. La jugabilidad será la de un plataformas de disparos, pero la historia estará guiada por las elecciones del propio jugador en el juego. No hay stats, las habilidades se desarrollan en función de decisiones ingame. Antes de nada. Gif de cómo va el proyecto:  Entrada 1: Selección del entorno en el que voy a desarrollar mis proyectos Me ha tomado literalmente 1 año determinar con qué plataforma quiero programar el videojuego. Creo que es una parte fundamental para no venirse abajo a mitad del desarrollo. Para seleccionar el entorno creo que hay que empaparse al menos de lo básico de cada uno de ellos. He revisado los siguientes:--> Cocos2Dx: Lenguaje principal C++. Manejo de assets, animaciones y sonidos con su herramienta gráfica Cocos Studio. Hace menos de un año han sacado una herramienta que integra todo el flujo de producción denominada Cocos Creator. Por desgracia Cocos Creator no permite utilizar C++ hasta la fecha, y quiero programar con un lenguaje estructurado. Por otra parte, Unity está mucho más maduro, si me decidiese a utilizar un framework gráfico del estilo. Para empaparme de Cocos 2Dx he seguido el libro: Cocos2d-x by Example: Beguinner's Guide - Second Edition Y he realizado los siguientes 2 tutoriales: El juego de la vida y Shushi Neko. Me ha gustado el gran manejo que le deja al desarrollador, que tiene acceso a todo el código del framework. Pero lo he descartado porque la documentación es HORRIBLE, al ser libre, tiene 3 o 4 frentes abiertos de desarrollo, por lo que la terminología del framework es supercomplicada y muy liosa. --> Unity: Lenguaje principal C# (en mi caso, aunque permite otros). Todo el entornno de desarrollo está en su herramienta, animación, música, codificación (con la ayuda de monodevelop o nuestro editor favorito) integración con muchos programas de creación de tilesets... La versión gratuita añade publicidad a tu juego, un banner al inicio de Unity, pero por lo demás prácticamente tiene todas las funcionalidades. Es interesante porque se está conviertiendo en el referente "indie" de la industria, pero por contra estamos totalmente dependientes de Unity, no podemos modificar el motor y todo el código es cerrado. He aprendido a usarlo con los tutoriales: Roll a Ball (3D) y RougueLike Tutorial (2D). El principal inconveniente de Unity es que tú te tienes que adaptar a su Framework Específico, con lo que muchos de los pasos de desarrollo no me parecen "naturales". Pese a que en temas de animación, sonido e integrabilidad no tiene rival... No quiero depender de Unity tan fuertemente, además aprendería un workflow que no es aplicable a otros frameworks. -->Libgdx: El lenguaje es Java: El framework Libgdx al igual que los dos anteriores está enfocado a desarrollo que permita integración multiplataforma. El concepto es simple: Libgdx crea un proyecto base, con unos assets, este proyecto está escrito con las clases del framework. Libgdx se encarga que esas clases en java luego se porten a Android (usa java), Escritorio (usa java), Ios (usaba RoboVM para portar el código, ahora que ya no tiene soporte y no está claro cómo se hace) y web (GWT). Cómo he aprendido a usarlo: mediante la wiki, que es EXCELENTE y este tutorial: Zombie Bird. He elegido LibGDx como plataforma porque utiliza Java, con el cual estoy bien familiarizado, es lo suficientemente flexible para que el framework se adapte a mí y no viceversa; y porque la documentación/foros son geniales y activos. Como parte negativa de libgdx --> es de mucho más bajo nivel que Unity, tienes que hacer mucho más trabajo mediante programación que en el ecosistema Unity se realiza gráficamente (eso no implica que uno sea más lento o rápido a la hora de desarrollar, ojo). Y hasta aquí la recopilación de hoy. Iré actualizando según vaya implementando mi idea. La proxima entrada incorporará algunos de los elementos gráficos que estoy creando para el juego. Shurs que quieran implicarse o echar una mano... MP o bien comentad aquí. ENTRADA 2: Compilando el primer ejemplo con LibGDX y correrlo en el escritorio/iOS En esta entrada voy a revisar los pasos para ejecutar el ejemplo base de libgdx, tarea trivial que viene explicada detalladamente en la [wiki](https://github.com/libgdx/libgdx/wiki), pero que puede llegar a ser muy compleja si lo que queremos es ejecutar el ejemplo en iOS desde nuestros teléfonos móviles (es trivial para Android). Esta segunda entrada rompe un poco el orden cronológico en el cual quiero ir desarrollando las entradas, pero quiero dejar por escrito los pasos ya que algunos son complejos. ¿Qué IDE estoy usando? --> [IntelliJ IDEA](https://www.jetbrains.com/idea) ¿Qué requisitos necesito? --> Una cuenta de Apple para poder firmar la aplicación que desarrollemos, hace falta una cuenta de Developer de Apple. Esto es gratuito, podemos firmar aplicaciones con la cuenta por defecto de desarrollador, eso sí, no podremos subirlas a la App store, para ello tendremos que adherirnos al programa de desarrolladores, usease 100€ / año. Un mac para poder compilar y un iPhone para probarlo. Paso 1: Descargar el Framework y crear un nuevo proyecto: Descargamos el framework Libgdx desde la [página de descargas](https://libgdx.badlogicgames.com/download.html). Lo ejecutamos y rellenamos como la imagen, marcando las mismas casillas:  Por ahora sólo queremos el proyecto para escritorio e iOS. CUIDADO: Antes de aceptar, dirígete a "Advanced Settings" y marca la opción "IDEA". Ya te haces a la Idea por qué... (chistacos aparte, lo necesitas marcar para trabajar con IntelliJ). Mucho ojo con el nombre del Package y del Game class, porque van a ser determinantes para que podamos hacer correr la app en iOS. Paso 2: Abrir el proyecto con IntelliJ IDEA y ejecutarlo en el escritorio Abrimos IntelliJ Idea --> Open --> Y vamos a la ruta donde creamos el proyecto y seleccionamos el *.ipr Clickamos en "Import Gradle" y seleccionamos todas las opciones posibles  Para ejecutarlo en el escritorio debemos configurar el "run configuration". Vamos al menú Run --> Edit Configurations. Y rellenamos con los datos siguientes. Ojo con el working directory!  Si pulsamos Control-R o damos al botoncito de Play, ya tendríamos nuestra app corriendo en el escritorio:  Paso 3: Hacer funcionar nuestro ejemplo base en iOS nativo. Lo primero que deberemos hacer es descargar el plugin 2.3.0 de MoviDevelop (antes se llamaba RoboVM) para IDEA. Lo puedes encontrar en [su página web](http://robovm.mobidevelop.com/). Para instalar el plugin:
Lo tercero que debemos hacer es comprobar que los nombres están bien puestos en el proyecto "ios" de IntelliJ checkeando robovm.properties de dicho proyecto.  Por último, creamos un nuevo Run Configuration, pero esta vez seleccionando RoboVM iOS:  Y ya se instalaría nuestra aplicación en el iPhone. Mucho cuidado, que como nuestra cuenta de desarrollador no es de pago debemos aceptar la firma de ese desarrollador dentro de la configuración de nuestro iPhone. Hasta aquí la entrada de hoy. Seguiremos la próxima semana con una entrada referente a las herramientas necesarias para complementar nuestro framework libGDX. ENTRADA 3: La caja de herramientas del desarrollador de videojuegos. En esta entrada vamos a revisar una serie de herramientas que son clave para poder desarrollar nuestro videojuego. Las herramientas descritas son útiles para todos los frameworks: libgdx, cocos2d, corona... y en algunos casos también para engines como Unity. Sin más dilación, vamos a verlas en acción: 1 Edición de gráficos y animaciones en pixel art: [PyxelEdit](http://pyxeledit.com/) Es una herramienta de dibujo multiplataforma (Mac, Linux y OSx), su precio es muy bajo (9€). Está completamente enfocada a pintar sprites, animaciones y tiles para nuestros juegos. Entre sus características podemos destacar lo ligero e intutitivo que es. Permite trabajar por capas, al igual que Photoshop. Tiene soporte para exportar las animaciones a muchos formatos diferentes. En el ejemplo siguiente aparece la primera animación que he realizado, que es un muñeco corriendo:  Y aquí está como se vería un Gif de la animación completa:  Por supuesto, ni que decir tiene que esta herramienta puede ser utilizada en conjunto con Unity, Libgdx, Cocos2dx... 2 Editor de mapas de Tiles: [Tiled](http://www.mapeditor.org/) De nuevo es una herramienta multiplataforma, pero esta vez gratuita. Es una herramienta perfecta para crear niveles y mapas apartir de celdas. Soporta celdas cuadradas:  Hexagonales:  E Isométricas:  Además de crear este tipo de mapas de celdas, permite añadir más información a los mapas. En el siguiente ejemplo, tengo un área determinado en el que cuando pase el personaje, aparecerán monstruos.  Esta información que creo en el editor Tiled, es exportada como un fichero. Este fichero puede ser leído por cualquier plataforma (Unity, libgdx, Cocos2d...) y tentrá que ser interpretado para que se creen los objetos de nuestro juego y los metadatos que hemos incluído para algunas zonas, por ejemplo que aparezcan monstruos cuando el personaje pase por una zona del mapa. 3 Motor de Físicas: [Box2D](https://github.com/erincatto/Box2D) Box2D en un sitema que nos permite simular las físicas de un mundo realista. En este mundo nos definimos una serie de cuerpos: Nuestro personaje, el suelo, las paredes... y las propiedades para esos cuerpos: su densidad, elasticidad, fricción, posición... El motor se encarga de simular cómo reaccionan esos cuerpos entre sí y ante fuerzas que podemos definirnos. Para juegos básicos podemos intentar crear nuestra propia lógica de físicas y va a resultar acertada. Pero si queremos hacer juegos realmente realistas como [Angry Bird](https://www.angrybirds.com/) o [Cut the Rope](https://www.cuttherope.net/) hay que tirar de un motor de físicas (los dos mencionados anteriormente utilizan Box2d). Unity por defecto utiliza Box2D para implementar sus físicas. Existen librerías en C, C++, Java, JavaScript... para trabajar con Box2D. En el siguiente ejemplo estoy utilizando su implementación en Java para simular el suelo, un cuadrado que se mueve hacia la derecha y una bola que puedo manejar con el teclado. La bola se mueve porque le aplico fuerzas que provocan que se desplace: Los editores de cuerpos son una ayuda para trabajar con los motores de físicas. Podríamos definir todas las entidades de nuestro juego a partir de código, pero para hacer mundos complejos formados por muchas entidades la cosa se complica bastante. R.U.B.E. es un editor que nos permite colocar mediante una herramienta gráfica todos los cuerpos y propiedades que van a aparecer en nuestra simulación. De forma parecida a Tiled, R.U.B.E. genera un fichero que peude ser leído por Unity, Libgdx, Cocos2d-x... para ser interpretado. El resultado de interpretar ese fichero sera crear un mundo para la simulación dentro de nuestro juego. R.U.B.E. cuesta unos 40€, pero es una herramienta indispensable si queremos trabajar con físicas realistas y complejas. El propio editor nos permite realizar simulaciones antes de exportarlas:  5 Editores de partículas: [2D Particle Editor](https://github.com/libgdx/libgdx/wik...article-Editor) Los efectos de partículas son los confetis de los videojuegos. No son más que gráficos que se pintan en pantalla, que siguen una determinada trayectoria (a veces aleatoria), y se modifican a lo largo del tiempo. 2D Particle Editor es un editor de partículas propio para Libgdx, no es lo más sencillo de usar y lo más fácil de instalar, pero es lo que tenemos y es gratuito. En el ejemplo siguiente se muestra como se edita un emisor de partículas para que parezca que emite fuego.  Y aquí tenemos ese emisor funcionando en nuestro programa:  6 Otras Herramientas: Por supuesto que hay muchas más herramientas útiles, aquí os dejo un mini listado, por si queréis googlear: - Github. - Github Pages. - Java Tween engine. -Aseprite. - OpenGameArt. Conclusiones Hasta aquí el arsenal de herramientas básicas que necesitamos como programadores/diseñadores. Por supuesto que hay muchas herramientas alternativas a las que he mencionado. Algunos motores, como Unity traen muchas de estas herramientas ya integradas, pero aun así podríamos decidir utilizar otras alternativas. Como colofón os dejo un pequeño gif con una simulación con todo lo que hemos tratado en esta entrada en funcionamiento:  Os recuerdo que estoy abierto a que me digáis de qué queréis que trate el juego/qué mecánicas implementar, qué estilo gráfico etc, etc... La idea es que yo lleve a cabo una idea colaborativa. ENTRADA 4: Replanteamiento del alcance del videojuego. He estado replanteándome el alcance del videojuego. Teniendo en cuenta que es el primero que publico, tengo que intentar: --> No fliparme demasiado. No puedo pretender hacer el mega-juego sin antes haber desarrollado algo más. Voy a reducir el alcance a algo "sencillo". Voy a construir un juego de coches estilo "Climb the Hill" con físicas realistas y niveles cortos pero que sean un desafío. En principio se va a publicar exclusivamente para Google Play. --> Tocar un poco cada palo: Cosas que considero importantísimas y que no son para nada cruciales: ----------> ¿Cómo adapto el juego a varias pantallas? Solucionado, mediante Viewports (libgdx). ----------> ¿Cómo se utiliza el motor de físicas de Box2D en conjunto con R.U.B.E. (editor gráfico) y cargar esos mundos en el juego? Está hecho, con rubeLoader. ----------> ¿Cómo crear interfaces y separar la lógica de la interfaz de la lógica del juego? Creo que por ahora tengo el código lo suficientemente estructurado... pero por ahora sólo tengo un botón, tengo que trabajar en ello. ----------> ¿Cómo y de dónde sacar sonidos chulos para este juego? Ni idea, tengo un par de contactos que son músicos, espero que me puedan ayudar a esta tarea. --> Publicar el juego y utilizar las herramientas de Google para guardar puntuaciones, valoraciones, estadísticas y publicidad. No tengo ni idea de cómo afrontar este punto, pero lo considero clave para lanzar un producto que sea atractivo. Aclaraciones: Con el tema de poner publicidad en el juego, sinceramente no creo que vaya a generar nada de dinero con él, pero considero que todo el tiempo invertido tiene un valor. Esto lo hago porque me gusta, pero si puedo ganar algo de ello (aunque sea la experiencia de saber que es muy difícil monetizar un juego) eso que me llevo. TOTAL, EN QUÉ ESTADO ESTÁ EL PROYECTO AHORA MISMO:  Qué funciona - Las físicas - El editor de niveles - Los controles funcionan. Qué es lo próximo que voy a hacer: - Interfaz de usuario. - Música y archivos gráficos. ¡No dudéis en comentar dudas y en dejarme nuevas propuestas para las siguientes entradas! |
Editado: 17-abr-2017 00:59 -
Ojos Siempre Rojo
14-feb-2017 14:52
#3
|
buena iniciativa shur, me quedo por aquí en cuanto tenga tiempo quiero ponerme también con este tema... e intentar ayudar en lo que pueda. conoces tutoriales para tener los controles en pantalla táctil?? |
........ Socio Nº 67
ForoCoches: Miembro
14-feb-2017 15:50
#5
|
Pues es dependiente de la plataforma, en Unity hay Assests que directamente te permiten controlarlo y te plantan el joistick. En Libgdx parte de la librería permite identificar los gestos de los dedos como imputs estilo ratón. Iré introducciendo cómo se hace en Libgdx a medida que avance 
|
Editado: 14-feb-2017 15:53 -
ForoCoches: Miembro
01-mar-2017 23:57
#8
| Upeo con nueva entrada: @woji @StevenHyde @Wheelz @kevinxe |
Editado: 02-mar-2017 00:00 -
*AutoBan Spam/Flood/Troll*
02-mar-2017 01:06
#10
|
Te deseo mucha suerte con el proyecto shur. Un abrazo. |
ForoCoches: Miembro
02-mar-2017 10:24
#11
| Supongo que te refieres a la época en la que transcurre el juego. Va a ser en la época actual. Si te refieres a la época de lanzamiento... ni idea, pero queda mucho. |
ForoCoches: Miembro
02-mar-2017 10:28
#12
| Si, me refería a la época en la que se desarrolla el juego. Y los personajes van a ser actuales también, en plan humanos? O mas de fantasía? |
ForoCoches: Miembro
02-mar-2017 11:02
#14
|
De todos modos sí que apuesto por elementos "supernaturales" o que se muevan fuera de lo común. Es algo que dependo en medida de tan bien que sepa implementar el motor del juego a partir de LibGDX y el tiempo y la ayuda que disponga para crear los gráficos del juego. |
ForoCoches: Miembro
02-mar-2017 23:01
#15
|
Muchas gracias Shur, se agradece el apoyo, pese que hasta ahora no he posteado nada "Gráficamente atrayente" |
Editado: 02-mar-2017 23:04 -
ForoCoches: Miembro
02-mar-2017 23:31
#17
|
Pues si por rendimiento nos referimos a qué tal aprovechan los recursos de la máquina, ambas elecciones son buenas, tanto Unity como LibGDX tienen un gran "performance". Más aún si consideramos el tipo de juego que estoy desarrollando (2d con sprites). LibGDX tiene muchas cosas que son naturales a mi manera de afrontar los problemas y soy yo el encargado de controlar todo, como programador, prefiero este enfoque. Como diseñador/Artista la cosa cambia, Unity facilita mucho la vida, pero aprender a manejarlo no deja de ser una tarea ardua. En mi próxima entrada entraré en más detalle, pero libGDX es un Framework (Digamos que una base) y Unity es un Engine (Un entorno con todos los aspectos para desarrollar un videojuego). |
ForoCoches: Miembro
16-mar-2017 01:32
#18
| Upeo con tercera entrada: @woji @StevenHyde @Wheelz @Geno14 @kevinxe @LinkinKiller @_RaiVeN_ |
ForoCoches: Miembro
28-mar-2017 14:18
#21
|
Hola! Gracias por los ánimos @woji He estado replanteándome el alcance del videojuego. Teniendo en cuenta que es el primero que publico, tengo que intentar: --> No fliparme demasiado. No puedo pretender hacer el mega-juego sin antes haber desarrollado algo más. Voy a reducir el alcance a algo "sencillo". Voy a construir un juego de coches estilo "Climb the Hill" con físicas realistas y niveles cortos pero que sean un desafío. En principio se va a publicar exclusivamente para Google Play. --> Tocar un poco cada palo: Cosas que considero importantísimas y que no son para nada cruciales: ----------> ¿Cómo adapto el juego a varias pantallas? Solucionado, mediante Viewports (libgdx). ----------> ¿Cómo se utiliza el motor de físicas de Box2D en conjunto con R.U.B.E. (editor gráfico) y cargar esos mundos en el juego? Está hecho, con rubeLoader. ----------> ¿Cómo crear interfaces y separar la lógica de la interfaz de la lógica del juego? Creo que por ahora tengo el código lo suficientemente estructurado... pero por ahora sólo tengo un botón, tengo que trabajar en ello. ----------> ¿Cómo y de dónde sacar sonidos chulos para este juego? Ni idea, tengo un par de contactos que son músicos, espero que me puedan ayudar a esta tarea. --> Publicar el juego y utilizar las herramientas de Google para guardar puntuaciones, valoraciones, estadísticas y publicidad. No tengo ni idea de cómo afrontar este punto, pero lo considero clave para lanzar un producto que sea atractivo. Aclaraciones: Con el tema de poner publicidad en el juego, sinceramente no creo que vaya a generar nada de dinero con él, pero considero que todo el tiempo invertido tiene un valor. Esto lo hago porque me gusta, pero si puedo ganar algo de ello (aunque sea la experiencia de saber que es muy difícil monetizar un juego) eso que me llevo. TOTAL, EN QUÉ ESTADO ESTÁ EL PROYECTO AHORA MISMO: Qué funciona - Las físicas - El editor de niveles - Los controles funcionan. Qué es lo próximo que voy a hacer: - Interfaz de usuario. - Música y archivos gráficos. Un saludo, seguimos trabajando en esto! Comentadme lo que penséis, no seáis tímidos! @woji @Geno14 @Wheelz @kevinxe @StevenHyde @LinkinKiller |
Editado: 28-mar-2017 14:21 -
ForoCoches: Miembro
04-abr-2017 14:54
#22
|
Ok, he avanzado bastante con la simulación. Ahora ya tengo una primera versión de la cámara pintando el coche funcional así como el sistema de amortiguación mejorado. Dejo gif y Upeo el primer post: 
|
ForoCoches: Miembro
06-abr-2017 01:31
#23
Estoy retocando la cámara. Ahora ya es dinámica, no está posicionada siempre igual relativamente al coche, sino que se mueve dependiendo de la velocidad que tenga. Me queda que el zoom también varíe, pero por ahora me gusta cómo va quedando. Upeo y actualizo primer post. |
ForoCoches: Miembro
07-abr-2017 12:55
#24
|
Upeo, He mejorado el sistema de cámara. Ahora además de desplazarse cambia el zoom dependiendo de la velocidad del coche, he conseguido suavizar todo ese desplazamiento y cambio de zoom de la cámara para que parezca más realista. Se pinta el suelo dinámicamente dependiendo del polígono que utilizo para definirlo, hay que optimizar el suelo con primitivas de OpenGL porque ahora mismo está hecho muy a cascoporro:  |
ForoCoches: Miembro
17-abr-2017 01:01
#25
|
Upeo, he implementado un sistema de fondo que permite mover imágenes para el fondo teniendo en cuenta la posición de la cámara. El factor de movimiento de los sprites de fondo es diferente para cada capa. Ya que lo tengo montado, añadir más capas es cuestión de poca cosa.
|
ForoCoches: Miembro
18-abr-2017 00:38
#26
|
Mantener los pies en la tierra y motivado -> La importancia de mantener un enfoque realista. Como ya sabréis si habéis leído mis anteriores entradas, estoy desarrollando mi primer videojuego utilizando el framework Libgdx. Como a muchos les ha pasado, empecé con la idea clara de que podría hacer el juego que más o menos quisiese si le dedicaba tiempo. Mi definición de lo que quería conseguir era la siguiente: El videojuego que tengo en mente es un plataformas con elementos de RPG. La jugabilidad será la de un plataformas de disparos, pero la historia estará guiada por las elecciones del propio jugador en el juego. No hay stats, las habilidades se desarrollan en función de decisiones ingame. El estilo gráfico será pixel art Pensé que sería algo factible, no quería hacer un mmorpg, ni un juego 3d, ni siquiera iba a utilizar gráficos complejos, yo podría hacer el Pixel Art. De hecho desarrollé algunas pantallas que eran más o menos lo que quería conseguir de estilo:  Y el personaje principal:  Y tenía escrito en un Word ideas sueltas que iban a ocurrir a lo largo de la historia:  En mi mente parecía que estaba progresando, que era capaz de avanzar con cosas que me iban a ser útiles para el juego. Pero en cuanto me puse a codificar... ¡No tenía ni idea de conseguir avanzar en lo más básico! ¿Cómo narices se representa el mundo? ¿Qué resolución de pantalla va a utilizar el juego? ¿Cómo voy a manejar distintas resoluciones? ¿Qué tamaño deben tener las imágenes de los sprites? ¿Cómo manejo la cámara del juego para que siga al personaje principal? ¿Cómo mantengo el sistema de opciones y decisiones? Ante tanta pregunta y tan poca respuesta, en lugar de tirar la toalla lo que he hecho ha sido replantearme el primer juego que quiero desarrollar en algo más sencillo. Lo que voy a hacer es crear un juego arquetipo, marcar un objetivo claro y organizarme para no perder tiempo avanzando en partes del proyecto que no sé si llegarán. Lo primordial pasó a ser definir el videojuego teniendo una demo funcional. 1. Explicación del videojuego para dummies. Mi videojuego va a ser de carreras en 2D para dispositivos móviles. El objetivo del juego será llegar desde un punto a otro de la pantalla pasando obstáculos y saltando de una plataforma a otra en menos de un tiempo determinado. El jugador controla la rotación de las ruedas del coche, que provocará que avance o frene. La cámara seguirá al coche a lo largo del recorrido. Los mapas se editarán y modificarán mediante R.U.B.E. Los gráficos ahora mismo van a ser "placeholders", líneas para representar los objetos que interaccionan. Tras una semana aprendiendo, fui capaz de crear la siguiente demo que corría en mi teléfono móvil:  Por primera vez estaba empezando a ver progreso real, pese a que lo que muestro es algo muy básico, considero que lograrlo en libgdx y siemdo por primera vez no es fácil. Me estaba empezando a gustar una idea que en principio no había sido mi idea inicial. 2. Organización del trabajo. Herramientas y enfoque. En mi caso tengo un trabajo fijo, y esto lo hago como Hobbie. Como era consciente que terminar el juego iba a requerir de mucho tiempo, así que iba saltando de una tarea a otra, ya que al final habrá que tenerlo todo hecho... Es verdad que durante ese tiempo he hecho muchas cosas, pero la utilidad de dichas cosas sinceramente es poca. Mi enfoque ha cambiado desde entonces, ahora mantengo un Trello con las tareas que tengo pendientes: 3. Los gráficos. Me gusta dibujar, creo que no soy demasiado malo dibujando como para producir unos gráficos decentes, pero no estoy acostumbrado a hacerlo. Soy muy lento produciendo recursos gráficos para mi juego. Había creado el personaje principal con algunas de sus animaciones:    Y alguna escena como la que he mostrado anteriormente del puerto:  He decidido cambiar el chip y dedicarme a programar y hacer un juego divertido. Para ello estoy tirando de repositorios gratuitos como [OpenGameArt](link). Esto ha sido positivo en dos aspectos: 1 --> No necesito ni un cuarto de tiempo para producir gráficos para mi juego. 2 --> Descubro estilos que no pensaba utilizar, pero que me están gustando (algo más allá del pixel art). Lo bueno de utilizar gráficos con licencia CC0 es que puedo modificarlos y utilizarlos a mi antojo. 4. Estado actual del proyecto: Sin ser un proyecto terminado, ni muchísimo menos, creo que he realizado avances muy significativos y me siento con ganas de seguir desarrollándolo. Mi idea inicial es bastante diferente a la que estoy llevando a cabo, pero avanza a paso firme y cada vez me está gustando más. Este es el aspecto actual del juego: En cuanto al videojuego original que tenía pensado, ha sido una herramienta para darme cuenta de lo importante que es enfocar el proyecto a algo que pueda ser viable temporal y anímicamente. De todo se aprende, y quién sabe lo que deparará el futuro... |
ForoCoches: Miembro
25-ene-2018 22:47
#29
| Lastima... acabo de descubrir el hilo y tu juego pintaba muy bien, espero que lo termines. |