Estado

Segunda demo jugable

Buenas de nuevo.

Después de otro largo intervalo, he de admitir que “me ha pillado el toro” por trabajar en este proyecto mientras que a la vez he estado haciendo de grafista para Mad Gear Games, que hace poco han lanzado su primer juego en la plataforma Steam Greenlight. Ahora ando realizando el máximo esfuerzo posible para poder terminar el proyecto lo más pronto posible. Por ahora mi intención, es terminarlo para finales de Julio. Si no es posible, al menos tener toda la parte de programación terminada en esas fechas y dedicar el verano a terminar la memoria para entregarlo definitivamente en Septiembre.

Así que lo más seguro es que no escriba en otro periodo largo de tiempo, pero que seguramente la próxima vez que publique algo será para colgar la beta final. Y después de eso intentaré colgar algunas entradas atrasadas mientras termino la documentación y la memoria. Sin embargo, si a pesar de lo dicho no hago las entradas faltantes, no os preocupéis porque lo más probable es que acabe públicandolas, cuando acabe todo, en algún magazine web sobre videojuegos.

Os hablo ahora de la demo actual, esta vez lo implementado es principalmente elementos de la interfaz, usando el sistema UI de Unity, y el sistema de ficheros de guardado y ajustes:

  • Menú principal con botones de nueva partida, cargar partida y salir del juego.
  • Ratón personalizado que cambia encima de los botones y los objetos interactivos.
  • Barra con los nombres de los elementos interactivos dentro de los niveles.
  • Menú de opciones al que se puede acceder dentro del juego (mientras no se esté ejecutando una acción).
  • Botón de mapa en el menú de opciones, en el que aparecerá un mapa (no definitivo) con una localización, si clickamos en él nos transportará al lugar indicado.
  • Botón de ajustes en el menú de opciones, en el que podremos modificar la resolución del juego (en resoluciones 4:3), modo pantalla completa, de ajustes de volumen en el audio (se guardan los cambios aunque todavía no haya música ni sonidos) y se puede cambiar de lenguaje entre español e inglés.
  • Botón de notas en el menú de opciones, aunque aún solo contenta una nota de ejemplo, aquí se iran colocando pistas y recordatorios según el jugador vaya haciendo cosas.
  • Botón de partidas guardadas en el menú de opciones, aquí podremos guardar la partida actual, cargar una partida o borrar las partidas.
  • Botón de salir del juego en el menú de opciones.
  • Ventana modal para verificar según qué acciones en los menú.
  • Implementado sistema de guardado de ficheros de guardado.
  • Implementado sistema de guardado del fichero de ajustes del juego, y estos valores se cargan automáticamente al iniciar nuevamente el juego.
  • Bugfixes  y mejoras varias.

Para poder jugar la demo, tenéis que hacerlo desde la página de GameJolt al igual que la otra vez. Aunque esta vez he deshabilitado la versión web por problemas con el navegador Google Chrome y porque de esta manera no funcionan los sistemas de ficheros para guardar ajustes y partidas. Tenéis ejecutables para Windows de 32 bits y GNU/Linux de 32 bits. En el caso de que alguien con Mac OS X o con SO de 64 quiera otra build, que me avise y la cuelgo también 😉

Click para ir a la página de GameJolt y bajarse la demo.

Al igual que con la demo anterior, si encontráis bugs o tenéis sugerencias, indicarmelas por un comentario a esta entrada, en la entrada de esta demo en GameJolt o en el apartado Issues del repositorio de GitHub.

Respecto al repositorio, ahora mismo no está actualizado, mañana colgaré la nueva versión del proyecto. Pondré aquí un edit con las instrucciones para bajarselo de nuevo cuando esté listo. Aviso de que seguramente haya bastante código sucio que no he podido limpiar o esclarecer debidamente 😦

Edit: Ya están subidos los cambios, al igual que la otra vez,  en la branch demo he subido todo el código usado en la demo, lamento decir que aún no está documentado. Espero poder hacer la documentación a lo largo de este mes.

Página del repositorio de la branch demo.

Desde ahí os lo podréis bajar en un zip, si lo preferís bajar usando una terminal, el comando es el siguiente:

git clone https://github.com/Firenz/1812.git --branch demo

Cómo en la demo anterior, si hay alguien que se baja el repositorio, que me avise si hay algún problema. Intentaré solucionarlos y subirlos al repositorio si ocurriera el caso.

Esto es todo por ahora, ya queda menos para tener implementado todas las funcionalidades. Lo cual me alegra bastante a pesar de que el tema de los puzzles a implementar vaya a sufrir bastante.

Saludos y espero que os guste la segunda demo.

Minientrada

Diseñando un juego #2: controles y mecánicas básicas

Después de un tiempo sin escribir, ya tocaba volver a realizar otra entrada para el blog. Desde la entrada anterior me he estado dedicando a terminar de elaborar el primer puzzle del juego (con su correspondiente documentación) además de parte del segundo, por lo que lo más lógico sería hablar de eso en esta entrada. Sin embargo, aún no me considero con los conocimientos suficientes para hablar sobre cómo hay que hacer los puzzles de una manera básica, teniendo en cuenta que, para mí, también es la primera vez que los elaboro. Por ello, prefiero relegar esa entrada para más adelante, contando mi experiencia al término de realizarlos y sobre los pasos que seguí para conseguirlo, sean los mejores o no.

Así pues, voy a dedicar esta entrada a los elementos que he ido enseñando en los vídeos, que son los controles y mecánicas en un juego. Esto lo comentamos brevemente en la entrada que escribí sobre lo básico para empezar a diseñar un videojuego y que, ciertamente, el argumento y la ambientación (en el caso de que la haya) pueden ser relevantes para que un jugador disfrute con nuestro juego. No obstante, el núcleo y la principal fuente de diversión de nuestro juego siempre serán las mecánicas de juego acompañados de un diseño de niveles que le proporcionen un reto superable al jugador. En otras palabras, el cómo lo jugamos.

Aunque hay que hacer el inciso de que es igualmente importante el diseño de niveles, en el que usando las mecánicas diseñadas hay que crear un reto, el cual siempre ofrece un desafío más difícil o complejo que el anterior, para así lograr mantener el interés del jugador. Además de muchas más cosas a tener en cuenta, que procederé a escribir más adelante en otra entrada.

De la misma forma, un juego que goce de unos gráficos exquisitos y de un argumento espléndido puede inspirar aversión hacia el usuario si sus controles y mecánicas son complejas, tediosas o han sido mal diseñadas. Sin embargo, si esas mecánicas son fácilmente asimilables e incluso adictivas, unidas a un diseño capaz de mantener la atención del jugador por el reto que ofrece, dará igual todo lo anterior. Y si no, que se lo digan a los juegos clásicos que han acabado en la cultura popular (Tetris, Pacman, Space Invaders…) o incluso juegos más actuales que técnicamente carecen de gráficos (VVVVV) o historia (Counter Strike, Worms).

Centrándonos en el tema, una vez que tengamos una ligera idea de sobre qué queremos hacer el juego, debemos preguntarnos:

  • ¿De cuáles acciones dispondrá el jugador para interactuar con el entorno que le ofrece el juego? Estas pueden ser tan básicas como caminar o saltar, o ser cada vez más complejas como disparar diferente según las armas de que disponga, lanzar conjuros que realicen diferentes cosas, etc. Todo esto sin olvidarnos de posibles acciones necesarias para poder interactuar con los menús disponibles en el juego.
  • ¿Qué realizan dichas acciones? Puede parecer un poco obvio el comentar que hace cada acción, pero realmente es necesario para tener claro qué hace la acción paso a paso, y de cómo afectan a otros elementos o al mismo jugador. Así evitamos interpretaciones erróneas de las acciones por otros miembros del equipo que desarrollen el juego.
  • ¿Cuándo se podrán realizar dichas acciones? No siempre tendremos las mismas acciones para todos los elementos disponibles en el juego ni todas las acciones se pueden hacer bajo las mismas condiciones. Por ejemplo, si un personaje está agachado para evitar que lo detecten, no podrá correr, o si está en mitad de un salto, no podrá saltar otra vez. O lo mismo un objeto del juego, no se puede coger pero si examinar.
  • ¿Cómo se pueden ejecutar las acciones? Para ello, es necesario saber de qué tipo de controles vamos a poder usar, dependiendo de la plataforma a la que estará destinada el juego sea un smartphone o tablet, consola u ordenador. Según nuestra plataforma elegida dispondremos de trazos y toques en una pantalla táctil, joysticks, botones, o teclas y ratón. Una vez elegida la plataforma y sabiendo de los controles disponibles, tendremos que ir asignandole a estos una acción a realizar, o incluso que si ejecutamos una serie de controles de una forma en concreto, también se haga. Pero cuidado, no es cuestión de asignar de forma aleatoria los controles y ya está, hay que tener en cuenta que estos se tienen que poder realizar de manera cómoda con los controles disponibles. Por ejemplo, en el caso de usar un mando, dispondremos las acciones que más se vayan a utilizar, en los botones más accesibles en el mando, y si se requiere de una combinación de botones para realizar otra acción, que estos dos botones sean fáciles de pulsar a la vez.

Cómo veis, a pesar de ser un tema relativamente sencillo, hay que pensarlo concienzudamente porque es con lo único que el jugador va a poder usar para comunicarse con el juego. Y si esta comunicación falla, todo lo demás se va desmoronando conforme el jugador se va frustrando por su impotencia. ¿Os imagináis jugar con las manos atadas y que os pidan pulsar tres botones a la vez para poder saltar en un juego? Pues esa es la idea a evitar.

Una vez más, espero que os haya gustado mi breve (pero larga) visión sobre cómo diseñar acciones para nuestro juego. Y si tenéis algún comentario, objeción o mejora, no dudéis en comentármelo por aquí o por las redes sociales.

Hasta la próxima entrada.

 

Vídeo

Vídeo de muestra #2: Prueba de coger objetos y usar el inventario

Después de otra semana entera programando, por fin os traigo un nuevo vídeo sobre cómo va el proyecto. Ya queda menos para la demo pero aún quedan unas cuantas cosas por hacer antes de lanzarla.

Tengo que admitir que esperaba que programar el inventario y los objetos del inventario solo me iba a ocupar un par de días. Que equivocada estaba. He tenido que aprender por el camino el uso de delegar eventos, los listener de eventos, objetos (tanto del inventario como del escenario) que realizan acciones distintas según sea el estado del otro con el que interactúan, y alguna que otra cosa más. Y un par de reajustes en el control de estados para la situación especial que supone usar un objeto del inventario en el escenario.

Las funcionalidades que he programado para este vídeo son:

  • Inventario que se abre y se cierra al hacer click izquierdo sobre la barra superior de este, y que a su vez también lo hagan los objetos del inventario. Para lograr este efecto con los objetos del inventario, lo que he hecho es que sean hijos del gameobject del inventario. Así si este se mueve, también lo harán los gameobject de los objetos del inventario anidados en él.
  • Añadir un objeto al inventario si interactuamos con un objeto del escenario que se puede coger con click derecho.
  • Función de examinar un objeto del inventario para obtener una descripción más detallada de él al hacer click izquierdo sobre él.
  • Al realizar click derecho sobre un objeto del inventario, lo arrastraremos con el ratón hasta que volvamos a hacer click derecho con él, de ser así, volverá al inventario y en el caso de haberse sido usado encima de un objeto del escenario con el que puede interactuar, realizará la acción pertinente.
  • Durante la interacción entre el objeto del escenario y el del inventario, la acción a realizar dependerá del estado actual de dichos objetos. Y en algunos casos incluso se borrará el objeto del inventario después de su utilización.

Si bien ya tengo las mecánicas de interacción en el escenario totalmente implementadas, aún quedar hacer algunos arreglos. Lo siguiente será el sistema de automatización de escenas en cuanto ocurran ciertas cosas en el escenario y un sistema de guardado de variables para cuando se cambie de escenario, de manera que si salimos de un escenario y volvemos a entrar, todo siga estando tal y cómo lo dejamos. Una vez implementados estos, podré centrarme en sistemas más internos como el de pathfinding y la localización de los textos.

Una vez más, espero que os haya gustado el vídeo y gracias a todo por la difusión del proyecto.

Minientrada

Normas de estilo para el código

Después de unas semanas dedicadas a la familia, toca entrada por fin. Aunque por ahora me limitaré a entradas cortas sobre temas específicos y un poco más centrados en el código, pues ahora toca retomar y acabar con algunos temas pendientes tales como terminar la demo, finalizar los retoques del documento de puzzles y actualizar el documento de diseño con los pequeños cambios que van surgiendo con el desarrollo.

De estas entradas de carácter corto, en esta en concreto trataremos algo que muchos novatos programadores se olvidan, o que ni siquiera saben que existe: las normas de estilo (en inglés se suele denominar como coding guidelines).

Tal como os puse en situación con la entrada del control de versiones en los proyectos y de cómo era necesario no sólo para tener una copia controlada del proyecto, sino en el caso de varios programadores a la vez, este es otro de los elementos necesarios en el caso de que varios programadores trabajen a la vez y tengan que leer los códigos de otros. O simplemente para que el código sea más fácil de leer para otras personas una vez publicado.

Y esto es un problema que se adquiere por aprender a programar sin tener estos factores de que tu código no solo lo tienes que entender tú, también tiene que ser comprensible para todos los demás.

Esto es algo muy importante, pues si varios programadores escriben el código cada uno siguiendo sus propias normas, llegará un punto en el que si otra persona no entiende que es lo que está haciendo el otro, ralentizando el ritmo del grupo (has de dedicar un tiempo a comprender qué quería hacer el otro programador con el código que lees) y creando confusión y/o diversidad de opiniones sobre como debería haberse escrito X código. Todo ese tiempo perdido se podría haber empleado en seguir trabajando en el proyecto, y lo que es peor, no será una situación que se dé de manera excepcional, sino que se dará de manera habitual.

Si dichos programadores llegasen a un acuerdo de cómo escribir el código de forma que los dos lo escribiesen de la misma forma, lograrían un código uniforme y fácilmente legible, evitando esta situación.

Algunos casos prácticos simples son tabular siempre con cuatro espacios los códigos anidados, poner saltos de línea en los bloques de código if/else sin importar su longitud, poner nombres explicativos a las funciones y variables usando la notación CamelCase sin importar lo largos que sean estos.

Muchas empresas y organizaciones ya proporcionan sus propias normas de estilo, algunas prácticamente a nivel de estándar internacional, para que lo tomen en cuenta los programadores profesionales para que a la hora de embarcarse en proyectos sea de la envergadura que sea, tengan en cuenta estas facilidades sin tener que crearse sus propias normas.

Algunas de las normas más conocidas son la de Google para C++, la de Microsoft para C#, o unas de las más completas que puede aplicarse en la gran mayoría de los lenguajes es de la PHP creada por PHP The Right Way.

Lamentablemente de Unity no hay ninguna convención que esté más o menos estandarizada, así que para 1812: La aventura he decidido adoptar algunas normas de estilo que están más o menos aceptadas. El formato que he elegido es el presente en la página de Unity Gems, que os la recomiendo visitar pues contiene artículos variados y muy útiles sobre Unity.

Y hasta aquí esta entrada, si conocéis más normas de estilo que consideráis que debería mencionar aquí, no dudéis en comunicármelo y las pondré.

Espero, como siempre, que esta entrada os haya servido y que los novatos os vayáis dando cuenta de los muchos detalles que hay que tener en cuenta a la hora de empezar un videojuego, para que al menos tengáis unas garantías sino de éxito al realizar el juego, pero al menos amenizaros el trabajo lo más posible.

Vídeo

Vídeo de muestra #1: Prueba de animaciones e interacciones básicas

Después de pegarme una paliza esta semana programando para la demo y, por consiguiente, también para el juego (pues el código se reutilizará), aquí os traigo una muestra de lo que he hecho esta semana.

La verdad es que para ser la primera vez que programo un juego con cierta complejidad, me ha gustado el que haya sido capaz de aprender a manejar algunas funcionalidades y código para luego aplicarlas a mis scripts de control del personaje en el corto plazo de una semana.

Las funcionalidades que he programado para este vídeo son:

  • Control de animaciones por máquina de estados en script y que este modifique los valores necesarios para que Mecanim (la máquina de estados que aparece en el vídeo) cambie a las animaciones correspondientes.
  • Función de ir a un sitio (sin sistema de navegación aún, sólo camino directo) o examinar con click izquierdo si le damos a un objeto interaccionable, en ese caso el personaje irá hasta dicho objeto y hablará para comentar lo que ve.
  • Función de interactuar con los objetos interaccionables con click derecho. Dependiendo del tipo de objeto interaccionable hará una cosa u otra, en el caso del vídeo la puerta solo es un objeto examinable y la ventana es un objeto con mecanismo (abrir y cerrar).
  • Diálogos que cambien según la información que nos dé el objeto.

Falta por implementar aún muchas cosas. Por ahora lo siguiente a implementar será el sistema de inventario, seguido del control de escenas en el caso de escenas automatizadas o que ocurra un evento y modifique el escenario. Más tarde me dedicaré a los sistemas de navegación para que el personaje se mueva por rutas en el escenario y el de localización de textos.

Todo lo que se muestra en el vídeo ya está disponible en el repositorio de GitHub, pero no aconsejo aún a la gente que ojee el código pues aún no he comentado el código para su documentación con Doxygen, estoy esperandome a terminar la demo para ello.

Espero que os haya gustado el vídeo, y con suerte para el final de esta semana o principios de la siguiente tenga otro vídeo con el que deleitaros.

Minientrada

Unity y el software de Control de Versiones

Llevo ya varios días programando una especie de demo del videojuego en mi ordenador. Por ahora no he subido nada a la forja porque me estoy esperando a tener el código más claro, y si lo hago en un futuro próximo, no lo subiré a la rama de desarrollo principal.

Pero eso no quita que ya haya tenido que mirar cómo preparar el proyecto de Unity para ser subido a GitHub, tal y cómo conté en una anterior entrada de este mismo blog.

Dado que voy a trabajar en Windows por no existir ninguna versión de Unity para GNU/Linux y no poseer un MacOSX (no hay dinero para eso), he tenido que buscar software de Control de Versiones basados en la tecnología Git con aplicación para este sistema. Algunos bastante completos tales como SourceTree o la oficial de Git para Windows. Aunque la que voy a usar es la de GitHub For Windows por su simpleza, incluye tanto una versión con interfaz como una por comandos. En mi caso prefiero el de comandos, así voy aprendiendo y memorizando los comandos de Git más comunes a usar y que puedan servirme en futuros proyectos.

Consola de comandos de GitHub For Windows

Consola de comandos de GitHub For Windows

Pero eso no es todo lo que hay que hacer. Normalmente en un proyecto que solo entrañe código y librerías, con excepción de algún archivo de gráficos y de audio, no genera demasiado problemas el subirlo a un repositorio. Pero con Unity la cosa difiere un poco ya que los proyectos de este programa generan archivos auxiliares. Si bien normalmente son inocuos a la hora de subirlos al repositorio como desarrolladora, cuando algún interesado se baje el proyecto y lo ejecute,  puede tener la mala suerte de que no pueda debido a problemas de mal enlazamiento entre los ficheros auxiliares del proyecto porque estos tienen referenciado carpetas de mi ordenador, no del suyo.

Para evitar este problema, tendremos que modificar algunos parámetros del proyecto en Unity.

  1. Para hacer que se muestren los ficheros auxiliares de Unity de cara al software de Control de Versiones:
    Edit->Project Settings->Editor->Version Control Mode = Meta Files
  2. Para que el software de Control de Versiones Git pueda usar bien su diferenciador de código entre distintas versiones de los ficheros:
    Edit->Project Settings->Editor->Asset Serialization Mode = Force Text
  3. Por último y una vez tengamos instalados nuestra aplicación para trabajar con el software de Control de Versiones, en este caso Git, y hayamos creado una copia en nuestro ordenador del repositorio para trabajar, nos saldrá en dicho directorio un fichero de nombre .gitignore . Le hacemos click derecho y elegimos editar con un editor de texto y escribimos los directorios, ficheros, y extensiones de ficheros que queremos evitar que se suban al repositorio. En este caso el mío es el siguiente:
    # =============== #
    # Unity generated #
    # =============== #
    Temp/
    Library/
    # ===================================== #
    # Visual Studio / MonoDevelop generated #
    # ===================================== #
    ExportedObj/
    obj/
    *.svd
    *.userprefs
    /*.csproj
    *.pidb
    *.suo
    /*.sln
    *.user
    *.unityproj
    *.booproj
    # ============ #
    # OS generated #
    # ============ #
    .DS_Store
    .DS_Store?
    ._*
    .Spotlight-V100
    .Trashes
    ehthumbs.db
    /*Thumbs.db

    Cada línea de este fichero es un fichero o (directorio si contiene “/”) a ignorar cada vez que subamos una nueva versión de nuestro trabajo al repositorio, aliviándonos la carga de escrutinizar los ficheros a subir para evitar que se suban también los que no queremos. Como nota final, los asteriscos sirven para indicar que nos da igual el nombre, solo los carácteres que lo acompañan a la hora de filtrar ficheros y directorios y también que si escribimos una línea empezando por “#” es un comentario y por tanto no será leida por el programa.

Con esto ya tendríamos que tener todo listo para subir nuestro proyecto de Unity a un repositorio basado en Git.

Nada más por hoy, y espero que os haya servido la entrada. Por ahora me limitaré a seguir programando la demo para sacarla cuanto antes posible y quizás cuelgue algún video de prueba de lo que voy haciendo estos días.