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.

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.