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.

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.

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.