English

Postmortem: Battle for Blood.

Battle for Blood is a fighting game developed by 2 students from SAE Institute Mexico as a graduation project. The game is a fighting game that pays homage to horror cinema, featuring the most popular monsters from iconic movies as characters.

• Early Development

 As game development students, our initial pitch was ambitious, with secondary mechanics, quality of life improvements, and deep world-building, given the time available. Gradually, we refined what was achievable within our skillset and time constraints, but that doesn't mean we didn't try. From the start, there was uncertainty about whether it was possible to achieve everything we wanted to implement, but we gradually adapted the project to meet academic requirements.

• The Concept

 The initial concept of the project aimed to incorporate the formula that horror movies use to scare people, and we wanted to infuse those feelings of anxiety and surprise into all elements of our game. However, we quickly realized this wasn't feasible due to the nature of fighting games. In short, a jump scare requires elements of ambiguity or uncertainty to catch the viewer off guard, but that's where our first problem arose. Fighting games rely on quick reactions and strategies, and if the game isn't clear about what's happening, the player can't react accordingly and feels that their loss is the game's fault. We experimented with ideas like regaining health by dealing damage to the opponent to encourage more aggressive combat strategies or obscuring the final portion of a character's life so that the player knows they're close to losing but doesn't know which blow will defeat them. We also considered dynamic stage elements where more light and sound would be present the longer the fight goes on, pressuring players to attack.

• Roadmap

 What kept us realistic about the time we had were the roadmaps at the beginning of each quarter. We were not exempt from making mistakes and promising more than we could achieve, but these calendars kept us grounded in terms of what we could accomplish. However, as in all projects, the roadmap evolved as we delved deeper. Elements such as animations, stages, mechanics, and effects had to be modified to meet the calendar's demands, all with the goal of maintaining functionality primarily. If tasks on the roadmap were completed ahead of schedule, extra time was used to polish other details, mainly addressing previous elements with which we were not satisfied, particularly animations and stage effects.

In the End

 The game worked and is ready for its first edition. The tests were positive in terms of gameplay and aesthetics. It was a significant learning experience for our team in the areas we specialized in, and we feel that the game is a good representation of the effort we put into these six months of development.

• The Good

 The game served as a learning tool for us to delve into the areas we wanted to specialize in, such as fighting game mechanics, animation, 3D modeling, and C++ programming, as well as communication between each of these areas. By communication, I mean the techniques we learned to streamline the development process.

The research we conducted through surveys to develop a local multiplayer game helped us learn a lot about the fighting game community. We experimented with layouts and inputs that could better serve our fighting game and accommodate the player.

The game was a challenge, and we are very proud of completing the project. The stage with its effects turned out better than expected, and the number of animations achieved and implemented was satisfactory. Additionally, animations stood out in tests and surveys.

We overcame uncertainty by implementing the second character along with the user interface (UI). These elements were crucial for the functionality and aesthetics of the game to shine. Similarly, with the extra time in the final stretch of the project, we were able to add sounds, particles, and various color filters, which added the finishing touches to the aesthetics and functionality of the game.

• The Bad

 Communication errors cost us precious time and hurt our development efficiency. If we had been more effective in our planning, we could have polished more elements of the game or animations. Similarly, with limited time and the ambitious concept we had in mind, some elements suffered from receiving less time than they deserved in order to make room for other elements that we couldn't implement.

We sacrificed many of our ideas, such as horror elements, like regaining health by dealing damage, stage effects to create tension, or a life bar that left uncertainty in the final blows. Knowing that these ideas have a place in the complete game concept, it feels empty in some aspects for those who are aware of these missing mechanics.

Being a student project with limited time for idea development, the development experience and the game itself were affected by several factors, including lack of communication, planning, knowledge, or time. However, this is not uncommon in student projects, especially when working in teams.

The historical reality is that we will not work with Unity again due to its limited support for developers, and much of the knowledge about game development we gained will stay with that engine. Unity as a company has not made decisions that support new developers, and the opportunities we have to grow as individuals or a company are not the best with this program.

• What We Learned

 What went wrong is largely outweighed by what went right since we have our complete and functional project with room for improvement, although nothing is perfect. The development gave us ideas on how to streamline our work in the future, and we gained many new skills from this experience, both technical and artistic.

This experience prepared us for the professional world, where different areas work on the same project. We learned how to develop a project more efficiently and avoid workflow hiccups. As a learning experience, it achieved what was expected within the available time.

To create a fighting game, we had to learn a lot, including programming, animation, and new game development concepts. We had to learn various animation techniques and new modeling methods, which will strengthen our skills and facilitate communication with different development areas, preparing us to apply this knowledge in the future.

Español 

Postmortem: Battle for blood. 

     Battle for blood es un juego de peleas desarrollado por 2 estudiantes de SAE institute México como proyecto de titulación. El juego es un juego de peleas que hace homenajes al cine de horror, representando los monstruos más populares de películas icónicas en los personajes.

• Desarrollo temprano

    Como todo estudiante de videojuegos nuestro pitch inicial fue ambicioso, con mecánicas secundarias, quality of life y ambientación muy profunda para el tiempo que teníamos disponible. 

Poco a poco fuimos refinando lo que era posible hacer con nuestras habilidades y limitaciones de tiempo, pero eso no significa que no lo intentamos. Desde el principio había una incertidumbre si era posible lograr todo lo que queríamos implementar, pero poco a poco fuimos adaptando el proyecto a las necesidades académicas. 

• El concepto 

     El concepto inicial del proyecto trataba de incorporar la fórmula que las películas de horror usan para asustar a la gente, y queríamos incorporar esos sentimientos de ansiedad y sorpresa en todos los elementos del nuestro juego, pero rápidamente nos dimos cuenta de que eso no era posible por la naturaleza de los juegos de pelea. 

En corto un susto necesita elementos de ambigüedad o incertidumbre para agarrar al espectador desprevenido, pero ahí surgió nuestro primer problema. Los juegos de pelea se basan en reacciones y estrategias rápidas, si el juego no es claro en lo que está sucediendo el jugador no puede reaccionar de acorde y siente que su perdida fue culpa del juego. Experimentamos con la idea de recuperar vida al hacerle daño al contrincante para incitar estrategias de combate más violentas o hacer que la última porción de la vida quede obscurecida para que el jugador sepa que está cerca de perder, pero no sepa cuál golpe lo derrota, o ambientación dinámica del escenario donde mientras más dure la pelea más luz u sonido haya para que los jugadores se sientan presionados a atacar. 

• Roadmap

     Lo que nos mantuvo realistas con el tiempo que teníamos eran los roadmaps al principio de cada trimestre, no fuimos exentos de cometer errores y prometer más de lo que podíamos lograr, pero estos calendarios nos mantenían realistas en cuanto lo que podíamos lograr. Pero como en todos los proyectos, el mapa fue cambiando mientras más desabollábamos, elementos como animaciones, escenarios, mecánicas y efectos tuvieron que ser modificadas para cumplir con lo que el calendario decía, todo con el objetivo de mantener la funcionalidad principalmente. Si las tareas en el roadmap se completaban antes de tiempo, se utilizaba el tiempo extra para pulir otros detalles, principalmente corregir elementos previos con los que no estábamos satisfechos, principalmente animaciones y efectos para el escenario. 

• Al final 

     El juego funcionó y está listo para su primera edición, las pruebas fueron positivas en cuento a jugabilidad y estética, fue una gran área de aprendizaje para nuestro equipo en las áreas donde sé especializaron y sentimos que el juego es una buena representación del esfuerzo que le metimos en estos 6 meses de desarrollo. 

• Lo bueno

     El juego funcionó para aprender más de las áreas en las que queríamos especializarnos, sean mecánicas de juego de pelea, animación, modelado 3D y programación en C++, al igual que la comunicación entre cada una de las áreas, a lo que me refiero con el punto anterior son las técnicas de comunicación que aprendimos para eficientizar el proceso de desarrollo.

La investigación que hicimos a base de encuestas para desarrollar un juego multijugador local nos ayudaron mucho a aprender sobre la comunidad de juegos de peleas, experimentamos con layouts e inputs que podrían servir mejor para nuestro juego de peleas y acomodar mejor al jugador. 

El juego fue un desafío y estamos muy orgullosos de haber completado el proyecto, el escenario con sus efectos quedo mejor de lo que esperábamos y el número de animaciones logradas e implementadas fue satisfactorio y encima de eso en las pruebas las animaciones fueron lo que sobresalen en las encuestas. 

La incertidumbre fue superada al lograr implementar el segundo personaje junto con el UI, estos elementos fueron de los decisivos para que la funcionalidad y estética del juego brillaran. Al igual con el tiempo extra, en el último tramo del proyecto pudimos agregar sonidos, partículas y diferentes filtros de colores, lo cual dio los últimos toques a la estética y funcionalidad del juego. 

• Lo malo 

     Los errores de comunicación nos costaron tiempo preciado y lastimaron nuestra eficiencia en el desarrollo, si hubiéramos sido más efectivos en nuestra planeación se podrían haber pulido más elementos del juego o animaciones. Al igual con un tiempo limitado y el ambicioso concepto que teníamos pensado, algunos elementos sufrieron al dedicarle menos tiempo de lo que merecían para hacer tiempo para otros elementos que no pudimos implementar. 

Sacrificamos muchas de nuestras ideas, como elementos del horror, ya sea recuperar vida al hacer daño, efectos de escenario para crear tensión, barra de vida que dejaba incertidumbre en los últimos golpes. Sabiendo que estas ideas tienen su lugar en la idea completa del juego, se siente que está vacío en algunos aspectos para el que sabe de la existencia de estas mecánicas faltantes. 

Al ser un proyecto de estudiante y el tiempo para desarrollar las ideas no es mucho, la experiencia del desarrollo y el juego mismo se vieron afectado por varios factores, sea falta de comunicación, planeación, conocimiento o tiempo, pero esto no es raro en los proyectos de estudiantes, y más cuando están trabajando en equipo.

La realidad histórica es que no volveremos a trabajar con Unity por su bajo apoyo a los desarrolladores, y muchos de los conocimientos sobre desarrollo de juegos que tenemos van a quedarse con ese motor, Unity como empresa no ha tomado decisiones que apoyan a nuevos desarrolladores y las oportunidades que tenemos para crecer como individuo o empresa no son las mejores con este programa. 

• Lo que aprendimos

     Lo que salió mal es en gran parte menor que lo que salió bien, ya que tenemos nuestro proyecto completo y funcional, con espacio par mejoras, pero nada es perfecto. El desarrollo nos dio ideas de como eficientizar nuestro trabajo de ahora en adelante y nos llevamos muchos conocimientos nuevos de esta experiencia, sean técnicos o artísticos. 

Esta experiencia logró prepararnos para el ámbito laboral donde se trabajaran diferentes áreas en un mismo proyecto. Aprender cómo desarrollar un proyecto más eficientemente y evitar los fallas en el flujo de trabajo. Como experiencia de aprendizaje se logró lo esperado con el tiempo disponible.

Para hacer un juego de peleas tuvimos que aprender mucho, sobre programación, animación y conceptos nuevos sobre desarrollo de juegos. Tuvimos que aprender diversas técnicas de animación y nuevos métodos de modelado, lo cual fortalecerá nuestras habilidades y facilitará nuestra comunicación con diferentes áreas de desarrollo, preparándonos para aplicar estos conocimientos en el futuro.