jueves, julio 28, 2016

Unity 5.4 está aquí

Y no trae la herramienta de edición de cinemáticas, como esperaba. Al menos, no se hace referencia a ella en las notas de lanzamiento.
Justamente acabo de lograr descargar la 5.3.5, la cual ha sido bastante decepcionante. El MonoDevelop que incluye ha dejado de sugerir el autocompletado para los miembros de algunas clases (me queda por definir cuándo lo hace y cuándo no) y además el precalculado de la iluminación global me suelta una docena de advertencias, aparte de que me ha obligado a recalcular las luces dos veces. Y eso toma bastante tiempo.
Aún no sé si podré echarle el guante a la 5.4, y tampoco es que tenga mucho interés. Aunque supongo que peor no va a ponerse, y quizás hasta se arreglen las cosas.
Por suerte, no estoy programando mucho. Las últimas páginas de la cuarta novela me tienen  bastante ocupado, y también le estoy echando un vistazo a la historia del juego. Sin embargo, eso no será para siempre, en algún momento de esta semana tengo que seguir puliendo el sistema de combate, e incluso portarlo al proyecto viejo para subirlo a github.
Asi que si alguien puede "donarme" los enlaces para la descarga de Unity (esos que están alojados en netstorage.unity3d.com, que sí son accesibles desde Cuba), se lo agradecería mucho, a ver si el 5.4 por lo menos corrige los problemas del 5.3.

miércoles, julio 20, 2016

Torque3d 3.9

Prácticamente me he olvidado de Torque3d, así que ni siquiera me había enterado de que cambiaron de web y dominio hasta hace unos meses. Esta semana un post en el foro de FreeGamedev informaba del lanzamiento de la versión 3.9.
El anuncio resulta bastante atípico, porque se concentra más en lo que veremos en la 4.0, que será la Madre de Todas las Versiones (incluso rompe la compatiblidad con versiones previas), que en los cambios de la 3.9. Vale la pena señalar que entre las descargas podemos encontrar al fin un port nativo para Linux precompilado. No sé cuál es el estado actual del mismo.
Torque3d aún sigue detrás de otros motores de juegos libres en cuanto a funcionalidades, algo que compensa, si es que puede decirse eso, con un excelente editor. No creo que esto mejore, incluso con los importantes cambios que vienen en la próxima versión.

lunes, julio 18, 2016

Planshift se está pasando a Unreal

Llevaba ya un buen tiempo sin actualizarme acerca de los progresos en Planeshift, desde que no tengo posibilidades de conectarme a ningún MMO, forzosamente he perdido el interés en ellos. Tampoco es que fuese un seguidor constante del juego, aunque lo he probado varias veces a lo largo de la pasada década y principios de esta (sí que es viejito el juego), los problemas técnicos, o la falta de interés, me han apartado de él en cada ocasión.
Así que por curiosidad hoy fui a mirar en qué estado se encuentra el desarrollo, y me encuentro la sorpresa de que hace más de un año decidieron intentar portar el juego a Unreal Engine 4. Durante años, Planeshift fue casi como el buque insignia del motor CrystalSpace, que en su momento fue una de las pocas opciones para los desarrolladores de juegos libres. Un poco más complejo que Ogre3d, y siempre desactualizado, con unas herramientas de artista francamente penosas, me preguntaba cómo era posible que Planeshift lograse mantener un proyecto tan grande con una herramienta tan pésima.
Un fork de Planeshift, Tempest in the Aether (que parece haber desaparecido ya), se deshizo en sus primeras etapas de CrystalSpace en favor del motor de Ryzom, si no recuerdo mal.
El esfuerzo no ha concluido aún, no parece haber una versión del cliente basado en UE por el momento, pero es de esperar, considerando la magnitud de la tarea y que habitualmente los cambios en Planeshift suelen tomar años en concretarse. De esto lo que me resulta raro es que Unreal Engine prohíbe el desarrollo de software libre en su licencia, así que supongo que el cliente ya no será libre en el estricto sentido de la licencia GPL. Quizás sea solo gratis.

miércoles, julio 13, 2016

¿Habrá scripting visua en Unity?

Ayer, durante una búsqueda de algún tutorial para el dichoso sistema de combate del juego, me encontré que existe una cosa llamada Playmaker, que es un paquete que añade scripting visual a Unity. Como el Blueprint de Unreal. Eso me trajo a la mente la propuesta de agregarle esa funcionalidad a Godot, que los usuario no acogieron de buen grado, porque preferían que se invirtiese el esfuerzo en cosas más necesarias.

Blueprint se nos presenta como la panacea para los que no saben programar, en teoría puedes hacer cualquier cosa sin escribir una línea de código. Hacer juegos sin programr ha sido el objetivo de muchas otras herramientas a lo largo de la historia de los videojuegos... y no seguiré por ahí porque no viene al caso. Pueden tildarme de obsoleto, pero siempre digo que hacer un juego sin programar quizás esté bien para cosas sencillas, pero que tarde o temprano tendrás que ensuciarte las manos con C++.
En cuanto al tema principal de esta anotación, creo que en algún momento caerá. Al igual que sucedió con Godot, la comunidad apoya mayoritariamente que se priorizen otras cosas, y también está muy dividida en cuanto a la efectividad real del scripting visual, o en concreto el Blueprint, que es el más extendido en la actualidad (vale aclarar que desciende de Kismet, o sea, que no cayó del cielo). Me abstengo de opinar sobre algo que no sé.
Lo que sí podría asegurar es que la afirmación "permite hacer juegos sin escribir código" es demasiado atrayente como para resistirse a su llamado. En especial para un motor que se adjudica el título de paladín de los indies, defensor de los débiles y muleta de los que no somos desarrolladores pro. Me pregunto cuántas cosas prioritarias quedan en la cola, ahora que Unity3D ya cuenta con su propio editor de cinemáticas, antes de que se decidan a trabajar en este tema. Yo me decanto por un sistema de shaders mucho mejor, y otros muchos también. Para empezar, ni siquiera tenemos un shader SSS decente.
No es que mis predicciones valgan un comino, pero creo que podríamos ver algo de esto en un año o dos.

lunes, julio 11, 2016

Un paso más

Este fin de semana lo dediqué a trabajar en el sistema de combate, y creo que he dado un paso más. Lo que no sé es en qué dirección. Esto ha probado ser una cosa bastante compleja, con muchos subsistemas involucrados, o mejor dicho, enredados.
Quizás lo estoy haciendo de la forma incorrecta, pero combatir implica múltiples cambios de estado de animación, en dependencia del arma. Hay que verificar los objetos equipados (ahora solo tengo en cuenta las armas), las habilidades, etc. No hay que olvidarse de que los NPC necesitan una IA que se encargue de eso. Al principio, pensé que RAIN resolvería todo, pero en esencia, es solo una solución cómoda para implementar sensores y algunas conductas sencillas. El combate es todo tuyo. Vale la pena mencionar que RAIN usa su propia malla de navegación, así que hay que utilizar el componente de IA para mover los personajes. Esto puede resolverse, pero ya sería un paso adicional, durante el cual podrían aparecer más problemas.
Por el momento, el prototipo permite pelear contra un NPC (realmente, varios pueden atacarte a la vez) , utilizando armas cuerpo a cuerpo o de rango, hasta que uno caiga muerto. Unas animaciones apropiadas ayudarían, pero aún no las tenemos. Esto sirve para probar el concepto y poco más.
El algoritmo del sistema de combate en realidad es muy simple y se resume a lo siguiente:
1- Si el jugador está en modo combate, hacer click en un NPC genera una acción ataque, que por defecto utilizará el arma equipada. Si ya hay  acciones en la cola, el click se ignora.
2- En el método Update() de la clase del jugador, se verifica si hay acción en la cola. Si la hay, se verifica que no estén en cooldown y se ejecuta (implica verificar si el objetivo está dentro del rango del objeto equipado). Si el cooldown ya terminó, se elimina.
Desde el punto de vista del NPC, es mucho más complejo, aunque la mayoría aún esté pendiente de implementar. Por ahora, lo que hace es encolar ataques. Insuficiente para divertirse un poco, aunque quizás la cosa cambie cuando le agregue algunas habilidades.
Desde el punto de vista del sistema RPG, faltaría por agregar variables que hagan el combate menos determinista, sin necesidad de acudir al socorrido atributo Suerte. También completar un conjunto de habilidades balanceado para cada estilo de lucha, algo que haré cuando termine todo lo anterior.

miércoles, julio 06, 2016

Sistema de combate

Luego de unos cuantos días de trabao y pruebas, he logrado un prototipo del sistema de combate. Está bastante incompleto por ahora, pero espero ir puliendo detalles para poderlo someter a pruebas reales. Al final descarté la idea inicial, en la cual las aciones se ejecutaban automáticamente sobre el objetivo, en favor de un sistema que demanda más atención por parte del jugador. O sea, antes el jugador solo intervenía para encolar alguna habilidad, mientras el ataque se repetía, ahora, hay que seguir clickeando para desencadenar más ataques. Es el sistema típico en la mayoría de los RPG que he probado en los últimos tiempos.
No ha sido un trabajo fácil, porque realmente solo tenía una vaga idea de cómo hacerlo. Es posible que siga descubriendo cosas a medida que avanzo, o incluso puede que ni siquiera sobreviva la etapa de pruebas. Si no me resulta divertido a mí y las víctimas que lo testeen, habrá que volver a la mesa de diseño. El sistema de combate se complica porque depende de otros subsistemas, como el de inventario, objetos y habilidades, que a su vez aún están bastante incompletos y son propensos a ser reescritos.
La buena noticia es que pronto debería empezar a integrar el arte específico del proyecto. Es de esperar que los dos artistas 3D estén trabajando a full a partir de la semana próxima para producir los personajes básicos del demo. Quedaría por cubrir algunos huecos, pero que no son de urgencia ahora. En cambio, lo que sí se mantiene deficitario es programación, que la hago yo solo, y arte 2D. Si alguien se anima acolaborar, pues bienvenido.
 

lunes, junio 27, 2016

Buscando la motivación para trabajar

En un reciente encuentro entre Stephen King y George R.R Martin, éste le preguntó a King cómo hacía para escribir tan rápido. La respuesta de King fue que tenía una disciplina establecida de escribir cierta cantidad de páginas al día. Sí o sí. Como escritor, puedo dar fe de que si no lo haces de esa forma, tu libro nunca verá la luz. A menos que seas de los que pueden sentarse y escribir cien páginas en un día y volver dentro de un mes y escribir las otras cien.
Sin embargo, simplemente decir que vas a escribir X páginas cada día no es suficiente. La escritura creativa depende de algo que llamamos inspiración. Si no tienes deseos, o si simplemente no sabes qué va a continuación, no podrás escribir por muy disciplinado que seas, o te saldrá un bodrio sin sentimiento. Esa inspiración, o motivación para continuar, hay que sacarla de algún lado.
Y ya que estamos, programar es muy parecido, también demanda su dosis de inspiración y motivación.
Yo considero que todo puede ser una fuente de motivación, si decidimos asumirlo como tal. Mi ex-novia solía justificarse diciendo que no podía escribir porque no tenía las condiciones, la tranquilidad, etc. Yo digo que hay que utilizar los buenos momentos y también los malos. Nada me motiva más para querer escribir que las necesidades y desgracias con las que vivimos a diario los cubanos de a pie (esa categoría de personas, que efectivamente, andamos a pie y a menudo con zapatos rotos). No porque sea un masoquista, sino porque me obligo a pensar que escribir tal vez me saque de esa situación, al menos mientras dure el exiguo pago por los derechos de publicación. Todos tenemos nuestra cuota de pequeños (o grandes) problemas o frustraciones. ¡Echalos a la caldera de la motivación!
No obstante, inspiración o no, siempre es bueno que cada día pongas al menos dos o tres líneas, o revises y arregles algo. Algunos son partidarios de que la inspiración te llegue trabajando. En mi experiencia, eso funciona... a veces. Es muy difícil establecer un método que funcione para todos, así que cada cual tendrá que buscar el suyo. Los días que decido programar, casi siempre le echo un vistazo a los mejores trailers de juegos de mi colección. Ver a los grandes me hace querer emularlos, me impulsa a sobreponerme a mis limitados conocimientos y recursos.
Ya seas escritor o programador, mi consejo es que identifiques qué cosas te motivan, y también las cosas que deberías convertir en motivadores, porque el simple hecho de fijarte una meta no es suficiente. En ocasiones, no queda más remedio que detenerse por un tiempo y dejar que el tiempo pase. Eso es normal (excepto en los casos en que la parada dura más de un año), y no deberías forzarte a trabajar.
Espero que mi modesta experiencia les sirva de lección. Y si alguien puede sugerirme otros métodos, pues soy todo oídos (u ojos, en este caso).