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.

 

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.