Una serie de hilos de twitter con las Lecciones aprendidas de un proyecto de videojuegos SHARD PROJECT. Lo primero de todo, reconocer el trabajo de documentación que ha hecho el autor de los diversos hilos recopilados en este post, dado que la cantidad de información que puede ser encontrada en cada uno de los hilos es absolutamente impresionando y probablemente uno de los mejores que hayamos visto desde que empezamos a andar por twitter .
Indice Lecciones aprendidas de un proyecto de videojuegos
Hilo Original Lecciones aprendidas de un proyecto de videojuegos SHARD PROJECT
SHARD PROJECT | LESSONS ——————————————- Como ultimo hilo del proyecto, me gustaria recoger las lecciones mas importantes que he aprendido durante el desarrollo
Hilo Editado Lecciones aprendidas de un proyecto de videojuegos SHARD PROJECT
SHARD PROJECT | LESSONS
——————————————- Como ultimo hilo del proyecto, me gustaria recoger las lecciones mas importantes que he aprendido durante el desarrollo
THREAD 👇
1. COMPARTIR EL PROGRESO
Para comenzar, me gustaria comentar lo mucho que he disfrutado de compartir el progreso del proyecto aqui, en Twitter. No solo me ha servido para mejorar mi vision del proyecto si no que he tenido la oportunidad de conocer a gente maravillosa +
+ que ha acabado no solo aportando al proyecto si no a formar relaciones de amistad. No dudéis en animaros a compartir lo que estais haciendo, todo el mundo esta deseando verlo 🙂
2. PATRONES DE DISEÑO
Si hay algo referente al código que quiero destacar, es sin duda la importancia de los patrones de diseño. Disfrute muchísimo de leer “Game Programming Patterns”, y fue genial encontrar el pedazo de repositorio de @cosmopod
GitHub – cosmopod/Unity-Programming-Patterns: A collection of programming patterns in Unity with examples when to use them. These are primarily from the book “Game Programming Patterns,” but translated from C++ to C#
A collection of programming patterns in Unity with examples when to use them. These are primarily from the book "Game Programming Patterns," but translated from C++ to C# – GitHub – cosmo…
3. EVENTOS
Siguiendo con mas temillas de codigo. Algo que queria hacer en este proyecto es crear componentes desacoplados, ahi fue donde los eventos fueron mi viaje confiable. +
+ Si no tienes cuidado se puede montar una buena, y mas de una vez se me ha colado un += en el OnDisable, para que mentir. Pero a la larga da gusto tener sistemas funcionando de forma independiente y que las explosiones de código no sean en cadena :_)
4. COMPOSICIÓN DE OBJETOS
Esta era otro habito que me habia propuesto adoptar con este proyecto. En lugar de tener scripts gigantes tipo “Player”, queria tener scripts pequeños del tipo “PlayerController”, “PlayerMovement”, “PlayerAnimations”. +
+ De esta forma el codigo es mucho mas legible y si lo combinas con algo de polimorfismo, te puedes ahorrar bastante trabajo jeje
5. ESCALABILIDAD
La escalabilidad creo que es un tema que aun no domino del todo. Me he visto mas de una vez en la situacion en que quiero añadir X elemento al juego y eso implica:
1. Añadir un case a un switch 2. Añadir un enum 3. Añadir un prefab
6. INSTANCIAS ESTÁTICAS Y DONTDESTROYONLOAD
Ahora que he empezado a trabajar con varias escenas, algo que me ha resultado muy útil es tener los objetos de tipo controlador dentro del DontDestroyOnLoad. Y además con una referencia estática a su instancia.
7. FIXED UPDATE Y TIME.FIXEDDELTATIME
Bueno, si supierais los dolores de cabeza que me ha traido este tema… Por favor, no seais como yo y pensad muy bien si quereis osar a usar Update y Time.deltaTime porque luego cuando probeis la build os vais a llevar sorpresas jajaja +
+ En general, si estais haciendo cualquier cosa que involucre físicas, haced uso del FixedUpdate y el Time.fixedDeltaTime para que el comportamiento sea independiente del framerate
8. EL NEW INPUT SYSTEM
Una funcionalidad que tenia mucha curiosidad por probar era el nuevo sistema de input. Aunque es cierto que es algo raro de montar, una vez que lo tiene listo es un gusto usarlo, ademas en general creo que responde mejor que el anterior.
9. LA IMPORTANCIA DEL CONTROL DEL PERSONAJE
Hacer un personaje 2D que se mueva y salte es facil. Pero hacer que se “sienta” como el de Celeste o Hollow Knight es un mundo. +
+ Personalmente es un tema que me flipa y creo que es buena idea dedicarle un poco mas de atencion a como calculáis las ecuaciones de movimiento y salto. Veréis como cambia el feeling de jugar 🙂
10. EL SISTEMA DE TILES
Si hay un sistema que me ha encantado usar en este proyecto, es el de las Tiles. Si estais pensando en usar Tiles, dadle una oportunidad. Montar la Palette y las Tiles Rules es mas sencillo de lo que parece y vais a notar los beneficios muchisimo.
11. EL PODER DEL PIXEL ART
Siguiendo con el punto anterior, escoger un estilo Pixel Art también creo que fue un acierto. El Pixel Art es una de esas disciplinas en las que hay un suelo bastante bajo (es fácil hacer cosas simples) y un techo alto (puedes fliparte, si quieres) +
+ Además de que aunque lo he dicho ya 256 veces, @aseprite es uno de los mejores programas que he usado en mi vida. Da gusto trabajar con el todas y cada una de las veces.
12. COMUNICACIÓN AL JUGADOR
Pasando ahora a temas de diseño, me he dado cuenta de que es super complicado comunicar ciertas ideas abstractas al jugador. Al tener un juego que trata sobre programar, me he dado cuenta de que hay conceptos que para mi son obvios +
+ pero que para otras personas se les hace un mundo. Cuando expanda el juego, lo ire introduciendo poco a poco.
13. DEJAR QUE LOS JUGADORES “HAGAN TRAMPAS”
Ahora que estoy recibiendo algo de feedback. Estoy viendo que algunas personas sienten que estan “haciendo trampas” en algunos puzzles. Esto me alegra por que es algo que tenia en mente desde el principio +
+ en el sentido de que quiero que existan soluciones enrevesadas que hagan sentir al jugador que está rompiendo el juego, pero sin romperlo realmente.
Algo parecido a escalar por las paredes con la Gloom Gun en Prey.
14. COMPLEJIDAD DEL LEVEL DESIGN
Sin duda, la disciplina con la que más me he agobiado es la del diseño de niveles. Es algo sobre lo que quiero indagar más por que los beneficios son más que notables.
15. MENTALIDAD
Para terminar, me gustaria comentar la importancia de la salud mental en el desarrollo de un videojuego, sobretodo si es en solitario y si tienes unas deadlines especificadas. +
+ Habra dias en los que no te sientas motivado y no te veas capaz de sacar el juego adelante. Es totalmente normal y es importante tener unas expectativas realistas, no pretendas hacer de tu primer juego el proximo Hollow Knight por que en el proceso vas a acabar contigo mismo +
+ Personalmente, limitar las horas de trabajo diarias y seguir cierta organización me ayudan a sentirme en control del proyecto. Es importante tomarse descansos por que cuando te estas quemando de algo, no te das cuenta hasta que ya es demasiado tarde
———————————————- This is a 2D platforms/puzzle game in which you will program little robots to help you beat the levels.
Lecciones aprendidas de un proyecto de videojuegos – Prototipo del Juego
SHARD PROJECT | Tweet-DevBlog
————————————————— Recopilación de hilos explicando temas de arquitectura, diseño e implementación que me han parecido mas interesantes mientas desarrollaba SP
THREAD 👇
SHARD PROJECT | INPUT —————————————— Para implementar el registro de input queria usar tanto el command pattern como el New Input System ya que me parece mas flexible y con menos acoplamiento en general.
THREAD 👇
La idea principal con este sistema nuevo es crear action maps con todos los posibles inputs. Este package genera su propia clase sobre la que trabajar. Realmente para asociar el input al metodo que quieras, es tan simple subscribirlo al metodo como si fuera un evento de C#
En cuanto al tema del Command pattern. Queria probar a usarlo para tener todo mas organizado y tener la posibilidad de tener un Undo. La idea es tener una clase abstracta Command sobre la que crear todas las acciones a ejecutar. Luego ya creas el comando que quieras como subclase
El tema del movimiento no es algo que preocupara mucho en general ya que este juego no se centre especialmente en el plataformeo. Lo que si queria mejorar si o si era el metodo de comprobar si el jugador esta en tierra.
THREAD 👇
Como digo, el movimiento es muy simple. Un smoothing en la velocidad del rigidbody y una fuerza para el salto.
Para las entidades tengo dos colliders, un box para el cuerpo y un circle para las piernas. Esto es asi porque en general me parece que cubre mas edge cases como las slopes o los edges.
El caso es que esto conlleva a que para hacer el checking ground tengo que hacer un raycast circular. Hasta donde he podido ver, es mejor usar OverlapCircleAll que RayCastCircle en este caso, pero no me vendria mal un poco de info extra 👀
En principio funciona bastante bien y de momento esta solucionado el problema que tenia el prototipo en el que la gente no podia saltar. Veremos de aqui a un par de meses jajajaja
Lecciones aprendidas de un proyecto de videojuegos – Prototipo Juego
Actualización del salto del jugador, no se si os habeis fijado porque yo desde luego, hasta que no me he puesto a mirarlo no me habia dado ni cuenta. Pero en casi todos los plataformas 2D, tardas mas frames en subir que en bajar
Lecciones aprendidas de un proyecto de videojuegos – Video Games Nintendo GIF
Ademas, queria implementar diferentes alturas de salto en funcion de cuanto tiempo se pulsara el boton. Para ello he jugado con las llamadas a los eventos started y canceled y listo.
Lecciones aprendidas de un proyecto de videojuegos – Activando Controles
El efecto que comentaba se consigue aplicando en cada frame la gravedad y la diferencia entre los saltos es el multiplicador a la misma.
Lecciones aprendidas de un proyecto de videojuegos – Código Unity de control del personajeLecciones aprendidas de un proyecto de videojuegos – probando movimiento
SHARD PROJECT | ENTITY ACTIONS ——————————————- Para las acciones, tanto del jugador como para los robots, he hecho un ActionCommand parametrizable desde el que llamar a la ejecución de acciones. Estas las tengo controladas con un Enum por si aca
Para el tema de como compartir comportamientos entre jugador y robots aun no lo tengo decidido. Lo que creo que acabare haciendo sera herencia + composition porque hay implementación parecida entre las dos entidades
La acción de ReCall es tan simple como atraer al objeto en cuestión hasta el jugador, nada fancy
Lecciones aprendidas de un proyecto de videojuegos – Recall
Con el Grab, queria probar a usar el componente Relativa Join 2D y estoy bastante contento con el resultado. Es tan simple con activarlo y cambiar el RigidBody 2D que tiene asignado. Ademas que el efectito que produce esta muy chuli
Lecciones aprendidas de un proyecto de videojuegos – Probando mecanicas en Unity
——————————————————– Soy plenamente consciente del debate sobre el Singleton y sobre si habría que usar o no😂. En mi defensadirée que esto no deja de ser mi TFG, estoy probando cosas.
THREAD 👇
La implementación del patron como tal es un tanto distinta a como seria en un contexto mas tradicional. Aqui al tener GameObjects con el script asociado en cuestión, miro que solo haya uno en la escena (borrando los otros) y lo “Inicializo”.
Lecciones aprendidas de un proyecto de videojuegos – Código Unity de Singleton
Luego en la clase en cuestion es simplemente tener acceso estatico a la instancia y hacer el casteo que toque
Lecciones aprendidas de un proyecto de videojuegos – Código Unity de control con Singleton
Probando, todo parece que funciona guay. Si fuera por mi usar full clases estaticas pero queria probar a ver que tal iba implementar este patron tambien 🙂
———————————— Queria incluir algo de TDD en el desarrollo de SP y cada sprint o 2 intento escribir algunos tests. Me ha costado un poco pillar la diferencia entre EditMode y PlayMode pero creo que ahora lo llevo mejor
THREAD 👇
Por supuesto que bajo ningún concepto y en absolutamente ningún punto de esta, mi existencia, he osado a realizar el terrible e imperdonable acto de escribir primero el código y luego el test. JAMAS
Los EditMode los estoy usando principalmente para comprobar que la libreria que estoy construyendo según avanza el proyecto funciona. Son cositas pequeñas que hago mucho dentro del juego
Lecciones aprendidas de un proyecto de videojuegos – Código Unity para cambio de color
Con los PlayMode ya me meto en cosas algo mas complejas. Ahora mismo estoy probando tanto los patrones de diseño como las acciones básicas del jugador, de forma que cuando me ponga a tocar luego y lo rompa, recuerde en que punto funcionaba jajaja
Lecciones aprendidas de un proyecto de videojuegos – Probando el juego
———————————————- Esta es una de las partes que mas ha cambiado desde el prototipo, inicialmente iba a ser una interfaz enfocada totalmente a comandos pero ahora he apostado por algo mas hibrido
THREAD 👇
Estos son los primeros bocetos de como queria que fuese la nueva UI. Un punto clave era que no tapara totalmente la pantalla para que los jugadores pudieran ver el puzzle a la vez que programaban. Principalmente esta dividida en dos secciones: blocks y trigger-events
Lecciones aprendidas de un proyecto de videojuegos – Diseño de nivelLecciones aprendidas de un proyecto de videojuegos – Diseño de nivel
Y estos son los primeros Mock-Ups. Soy consciente de la aberración que acabo de crear pero lo principal es ver si cabían todos los elementos jajajaja Ahora voy a intentar pasar esto a Unity con el UI Builder y después lo retocare un poco aunque siga siendo placeholder
Asi ha quedado de momento el placeholder en Unity, ire retocando cosas mientras implemento el Drag & Drop de los bloques y el registro de input de los Commands.
Me gusta la estructura, cuando este con los diseños Pixel Art finales creo que puede quedar chulo 🙂
Lecciones aprendidas de un proyecto de videojuegos – Montando el nivel
———————————————- Esta es una de las dos mecanicas principales del juego, construir comportamientos para los robots basados en bloques. Inicialmente iba todo por comandos pero creo que asi es mas intuitivo
THREAD 👇
Lo primero en lo que me he centrado es en la mecánica de Drag & Drop de los bloques. La solución que tengo ahora mismo se basa en tener un elemento de tipo BlockDragging que actúa a modo de trigger, cuando lo pulsas genera una copia de el DraggableBlock asociado
Lecciones aprendidas de un proyecto de videojuegos
Después, este DraggableBlock es el que controlas con el ratón. Necesitaba restringir donde puedes poner los bloques así que he determinado ciertos Block Space como espacios disponibles. Para ver en qué espacio poner el bloque, simplemente he usado Colliders
Lecciones aprendidas de un proyecto de videojuegos – Código Unity programación de UILecciones aprendidas de un proyecto de videojuegos – Prueba UI
He dividido el componente que maneja el tema del dragging del que se encargará del propio behaviour del bloque. De momento me queda añadir la interacción de cuando colocas un bloque encima del otro.
Lecciones aprendidas de un proyecto de videojuegos – Prueba controles
Una cosa que me preocupaba bastante era el como implementar una zona con scroll para poder tener mas de 7 bloques a la vez. Al final ha sido mas sencillo de lo que me esperaba. Con el Scroll Rect, Content Fit y Vertical Layout se construye muy facilmente 😀
Ya va cogiendo una forma muy chula 🙂
Bueno pues a falta de solucionar un par de bugs, el sistema ya esta montado. He estado estos ultimos dias en refinar como poner, quitar y mover bloques. Ademas de como se calculan las posiciones de estos
Al final he implementado una indentación similar a la de Python para controlar los condicionales, creo que es lo mas sencillo de entender.
Para la generación del behaviour he almacenado todos los bloques y para gestionar el tema de los condicionales, he jugado con cual seria el siguiente bloque en función del resultado de la condicion
Bueno pues despues de mucho sufrimiento con los crashes, he conseguido que el behaviour se ejecute de forma correcta.
Al final la ejecución es simplemente una CoRoutine que va bloque a bloque ejecutando todo, son los propios bloques los que controlan el siguiente a ejecutar.
—————————————- Los robots son la mecanica principal del juego, se les puede asociar un comportamiento por bloques y uno (o mas, ya veremos xD) comportamientos de comandos
THREAD 👇
Tanto las acciones como el movimiento se basan en la misma implementación del jugador, este ultimo tiene mas posibilidades pero las que usan los robots funcionan de la misma manera
En cuanto al comportamiento de bloque, el Block Management se comunica con el Robot Controller a traves del Observer Pattern, nada fancy pero efectivo
En cuanto a los bloques que necesitan comunicarse con otros componentes del robot, también he usado Funcs y Actions. Los bloques condicionales se conectan con los sensores a través de su isMetEvent y los accionales con el movimiento/acción con su executeActionEvent
Estoy super contento con cómo ha quedado esta parte del juego en comparación a como estaba en el prototipo. Quiero apostar por una experiencia de aprendizaje hacia la programación y creo que este sistema de bloques es mucho más intuitivo
—————————————————- Esta es la otra mecanica principal del juego. Ademas de los comportamientos por bloques, se le pueden asignar ciertos eventos a los robots a acciones del mismo o del jugador.
THREAD 👇
El sistema se basa en introducir comandos del estilo: <event>(<trigger>).<delay>
Donde el evento indica lo que hacer, el trigger cuando hacerlo, y el delay (opcional) cuantos segundos esperar antes de ejecutarse
El input es el TMP_Input tipico, en cuanto al Parser es simple porque al final son solo 3 elementos chiquitos, y el historial va llevando un recuento de todos los comandos de la sesión para proporcionar luego la funcionalidad tipica de las flechitas al escribir
Lecciones aprendidas de un proyecto de videojuegos – Command Behaviours
Para generar el comportamiento como tal es muy similar a los Block Behaviours. Tengo un manager en estático que genera el behaviour y ya luego el Robot Controller se encarga de conectar el evento con el trigger
A falta de añadir todos los posibles eventos y triggers, tengo el sistema ya montado. El behaviour se basa en asignar cuando se realiza el evento y que es el propio evento. Luego, el controlador ya se encarga de asignarlo a donde toque
Con esto ya tengo una de las primeras mecánicas que pensé, usar a los robots como plataformas móviles 🙂 Asignas el salto del robot al tuyo, con algo de delay, y despues saltas sobre el robot para después volver a saltar
———————————– El juego tiene un estilo Pixel Art simplificado. Al menos de momento, no hay demasiado tiempo de desarrollo para dedicarle a esta parte
THREAD 👇
Lo primero he de decir que mis conocimientos de Pixel Art son reducidos, he tenido que refrescar la memoria porque no recordaba lo chungo que era esto jajajaja.
Esta es la primera versión de Lily, el personaje principal, la verdad que me chirría el hecho de que no tenga cara 😅 Como primera versión me sirve para seguir avanzando, pero en el futuro intentaré arreglarlo. Y de paso que no sea una gemela de Madeline tambien estaria bien.
Lecciones aprendidas de un proyecto de videojuegos -Lily personaje principal
Update de Lily, he conseguido hacerle unos ojos que no den todo el mal rollo 😂. Me gusta bastante mas asi, seguramente acabe cambiando algo mas cuando me ponga con las animaciones
Lecciones aprendidas de un proyecto de videojuegos -Lily personaje principal
En cuanto al robot, ha sido algo más sencillo porque tiene menos detalles. Estoy especialmente contento con la antena.
Lecciones aprendidas de un proyecto de videojuegos -Robot
En cuando al tileset, mi idea era que la temática fuera un laboratorio con colores sobre todo claros. Creo que ha quedado bastante bien la escena. Ahora tengo que sacar de ahí el tileset 😅
Lecciones aprendidas de un proyecto de videojuegos -Lily y Robot
Último update de los personajes. Ahora que ha metido mano un artista de verdad como @Golf8765 ha quedado muchísimo mejor jajajajaja. Poco se habla la cara de buena gente del robot
Lecciones aprendidas de un proyecto de videojuegos -Lily y Robot
————————————— Este es uno de los temas del arte que mas ganas tenia de aprender. Me parece super chulo cuando un juego tiene montado un sistema de tiles inteligente y queria algo asi para el mio
THREAD 👇
Los componentes principales que he usado de Unity han sido: – Tilemap – Tilepalette – Sprite Editor – Tile Rules
Lo primero que he hecho ha sido hacer un tileset para la geometria basica con el que construir el esquema de los niveles.
Lecciones aprendidas de un proyecto de videojuegos – El mapa
Con estas primeras tiles, he construido la estructura básica del nivel para ver cómo cuadran las dimensiones.
Lecciones aprendidas de un proyecto de videojuegos – El mapa
Ahora es cuando me he puesto a construir las tiles finales. Primero he dibujado la escena final para ver como quedaba el conjunto. Y después lo he adaptado a un tileset usable en Unity
Y ya para terminar he descubierto el maravilloso mundo de los Rule Tiles, y creo que es lo mejor me ha pasado en la vida 😂
Lecciones aprendidas de un proyecto de videojuegos – El mapa
Da gusto poner tiles a cholon y que Unity se encargue de poner la que toca 🙂
——————————————- Es la primera vez que hago UI en Pixel Art y tenia bastantes ganas de aprender. En mi caso, me parece hasta mas complicado a veces que hacer personajes 😂
THREAD 👇
La primera interfaz a traducir a Pixel Art es la de programación.
El diseño placeholder era este y cuenta con 4 zonas principales: 1. Información 2. Comportamiento de bloques 3. Comportamiento de comandos 4. Ejecución
He empezado haciendo el borde y el fondo. Y después he dividido las 4 zonas para ver cómo posicionar los elementos.
A falta de poner los textos, ha quedado así. Estoy bastante contento con el resultado la verdad. Ahora tengo que ponerme con los bloques individuales, a ver como me las apaño para diferenciarlos entre ellos jajajaja
Y así ha quedado después de añadir los detallitos 🙂
Una vez integrado en Unity y con todo el resto de sprites queda incluso mejor jeje. Estoy super contento con la estetica general 🙂
—————————————– Personalmente, este es un aspecto que me cuesta bastante. Me flipa ver como cambia un juego cuando tiene animaciones, pero sufro mucho en el proceso jeje.
He empezado por el jugador, las animaciones mas basicas que queria implementar eran:
– Idle – Jump – Crouch – Grab (Walk y Jump extras) – Drop – Clap
Reitero el pedazo de programa que es @aseprite jajajaja. El workflow de animacion me parece super importante a la hora de reducir tiempo en el desarrollo, y personalmente en Aseprite se hace muy gustoso.
Para ir cogiendo soltura de nuevo, estoy contento con la animacion idle 🙂
Estoy bastante contento con el resultado. Es cierto que la de andar necesita un repasillo pero la de saltar y aterrizar tienen ese rollito de elasticidad que me mola mucho 🙂
Para las animaciones del robot quería tener algo chulo para cuando se encendiera y cuando se apagara.
Personalmente todo lo relacionado con el robot es el arte que mas me esta gustando hacer jeje. Es que es to cute el cabron :3
Asi han quedado las animaciones de salto y movimiento del robot. Tengo que pulir las curvas para que quede mas fino pero ha quedado chulo 🙂
He retocado un par de cosillas y añadido una animación muy simple a la UI. Me quedaria solo hacer todas las animaciones del jugador cuando tenga algo agarrado y listo
Las maquinas de estado no son demasiado complejas (de momento… jeje).
Para el jugador tengo dos subestados similares que tienen como animación prioritaria la de salto. Y que se comunican a través del grab y el drop.
Y para el robot es comprobar cuando está encendido o apagado
Para la transición de niveles, he montado esta pequeña secuencia. La verdad que este detallito le da bastante unidad al juego, hace que parezca un juego de verdad y todo jajajaja.
Lo que es la secuencia, es la misma tanto para el inicio como para el final, simplemente están invertidas. El orden de ejecución lo tengo un poco hardcodeado ahora mismo. En el futuro intentare montar un sistema de eventos en los clips mas chulo 😛
Lecciones aprendidas de un proyecto de videojuegos – el nivel en unity
—————————————— Este era uno de los aspectos que mas ganas tenia de tocar, ya que nunca habia profundizado en ello. Han sido bastantes horas de research pero creo que he encontrado un workflow bastante cuco 🙂
THREAD 👇
La metodologia que he seguido se basa en el diseño modular, es decir, en lugar de construir los niveles como tal, se diseñan pequeñas situaciones, o modulos, con las que luego se forman los niveles completos
El primer paso seria diseñar los modulos para una mecanica en concreto. Personalmente he seguido el metodo Nintendo:
1. Introducir la mecanica en un entorno seguro 2. Explorar la mecanica 3. Producir una situación con un “twist” de la mecanica 4. Diseñar un desafio final
Una vez hecho esto, quedaría diseñar el propio nivel. Para ello he definido primero el objetivo principal del nivel, le he asignado una dificultad, y finalmente he cogido los módulos diseñados anteriormente y los he ordenado de menos a mas dificil, cada uno dentro de su categoría
Una vez tenía tanto el nivel como conjunto y su representación por bloques. Simplemente tenia que construir el nivel en Unity e implementar las mecánicas que hicieran falta. Al tener ya montando el sistema de tiles, el proceso ha sido bastante fluido 🙂
Un ejemplo de este proceso basado en la mecánica de botones y puertas sería el siguiente: En las primeras fotos se encuentra el diseño de la mecanica como tal. Y en la ultima se pueden apreciar los 5 módulos conformando el nivel entero
El siguiente paso que he seguido ha sido el de traducir el papel a un esquema básico de nivel en Unity. El objetivo aquí es probar distancias, camara, saltos…
Cada nivel esta dividido en secciones o “modulos”, de forma que la curva de dificultad y de exploración de la mecanica del nivel ascienda de forma gradual. Esto da una vision general de como quedaria el nivel como conjunto, ahora tocaria juntar los trozos entre sección y sección
Lecciones aprendidas de un proyecto de videojuegos – el nivel en unity
Una vez que tengo todas las secciones, quedaria conectarlos añadiendo secciones de plataformeo ligero a modo de descanso entre puzzles. El nivel ya empieza a parecer un nivel como tal 😂
Lecciones aprendidas de un proyecto de videojuegos – el nivel en unity
Lo siguiente seria aplicar la primera pasada de arte: definir donde esta el techo, el suelo, y las plataformas intermedias.
Lecciones aprendidas de un proyecto de videojuegos – el nivel en unity
Para poder probar a fondo el nivel, solamente quedarian por añadir los controladores del “Gameflow”: – Checkpoints (Verde) – Death Triggers (Rojo) – Camera Switchers (Morado)
Lecciones aprendidas de un proyecto de videojuegos – el nivel en unity
Una vez probado y pulido, solamente quedaria aplicar todos los detalles de arte al suelo, techo, fondo…
Lecciones aprendidas de un proyecto de videojuegos – Detalles del arte en el suelo
———————————————- En este hilo quiero ir comentando un poco los sitemas que he montado para cada nivel. Como ya comente anteriormente, en principio cada nivel explorara una mecánica en concreto.
THREAD 👇
Para el primer nivel de la demo, me he centrado en la mecánica de botones abriendo puertas. Nada super complejo de momento.
El principio que he seguido es el de desacoplamiento, quiero que mis puertas puedan ser activadas por cualquier mecanismo. Y estos poder activar mas cosas
Tambien queria que el diseño me permitiera modificar el comportamiento directamente desde el editor. Asi que he montado un sistema de objetos con el Serializable y listo 🙂
Lecciones aprendidas de un proyecto de videojuegos – Modificación del comportamiento en el editor
SHARD PROJECT | AUDIO ———————————– Siempre me ha molado mucho trabajar en este aspecto del gamedev porque me parece que es de los que tiene mayor impacto en como se “siente” jugar a un juego
THREAD 👇
Lo primero que queria comentar es la mayor parte del sistema esta basado en el que en su dia publico @BrackeysTweet . Como suele ser habitual, el trabajo que produce Brackeys es genial 🙂
Lecciones aprendidas de un proyecto de videojuegos – Tutorial sobre Audio en Unity
El sistema se basa en dos elementos: Un AudioController y una clase custom Sound. En el AudioController definimos los tipos de sonidos que tenemos y el script se encarga de añadir un AudioSource por cada uno de ellos
Lecciones aprendidas de un proyecto de videojuegos – el nivel en unity
La clase AudioController simplemente organiza todos los Sounds y permite lanzarlos o hacer un Fade In/Out.
En cuanto a la OST, simplemente hay una cancion distinta por escena. Y en la secuencia de inicio y de finalizacion de nivel, se realiza el correspondiente Fade In o Fade Out
Lecciones aprendidas de un proyecto de videojuegos – Prueba de Sonido
Y para los SFX es algo similar, solamente es definirlos todos en el AudioController con su volumen, pitch y loop. Y después llamar a la instancia estática del controlador
———————————————– Por fin! El ultimo paso que queda es generar los archivos que enviar a la gente 🙂
THREAD 👇
Realmente en este tema tampoco he indagado demasiado, al final lo que estoy haciendo actualmente es un MVP, no estoy incluyendo opciones de ningún tipo. Aun así hay un par de cosillas interesantes que me gustaría comentar.
Lo primero es el tema de los StreamingAssets, aunque es cierto que al final opte por descartarlos, en el primer prototipo que implemente, hice uso de esta funcionalidad para copiar archivos a las builds
En cuanto a las builds settings, nada demasiado enrevesado, estoy compilando para Windows + MacOS + Linux con opciones bastante básicas.
Un detalle importante es que como mi monitor es 2K, cuando estaba trabajando con la UI la lie bastante porque la resolución de la build era 1080p xD. Para el siguiente juego me lo apunto.
Lecciones aprendidas de un proyecto de videojuegos – el nivel en unity
Tambien he cambiado el icono del juego y la splash image del principio. Que al final siempre le dan un toquecito chulo :3
