Itch.io - Release
Blood Rushers is available for free on itch.io! Try it out yourself :): https://raphael-varga.itch.io/blood-rushers
- produced by myself
- produced by myself
Play Austria 1.5
- We also showed off the project at the gaming-festival "Play Austria 1.5" https://playaustria.com/play-austria-1-5/. Here are some screenshots of that day :)!
Big Indie Fest @ Reversed
- We also showed off the project at the gaming-festival "Big Indie Festival@Reversed" http://www.reversed.at/. Here are some screenshots of that day :)!
- Core-System/Mechanic Design
- Experience Design (Game Feel)
- Combat Design
- UI Design
- Balancing (Paper-Design, Excel)
- Playtesting and Analysis & Documentation
- Documentation (High Concept, GDD, Combat-Overhauls etc.)
- Level Polishing (Environment Creation etc.)
Project Lead & Management
- Team Structuring
- Scrum Management (Documentation, Scrum Master, Product Owner, User Story Prioritization)
- Bug Documentation
- Scene-Conception (Paper-Design)
- Scene-Animations (Camera, Particle Effects)
Audio-Engineering & Sound Refinement
- Sound-Asset List
- Wwise Playback Systems (Conception & Structure, Implementation)
- Wwise Effect & Sound Refinement
Technology I used
- Pen & Paper
- Adobe Photoshop CS 6
- Unity 3D Game Engine
- Dia (Flowchart-Programm)
- Autodesk Maya 2017
This is a One-Sheet I created at the start of the project to give an overview of the project.
Except for 2 sounds everything was recorded and produced by ourselves. We spent a whole day in a recording-studio with all the professional audio-equipment needed and had a recording-session about 7 hours long. So, all the VO's your hear in-game and the impact, hit and flesh sounds of the combat, are all done by us. Below you will find a short video I created summarizing the day. It was funny yes...
3 Stage Design
When I'm designing a new Mechanic/Feature I'm using a approach which I developed for my working process. On a basis-level the whole design process is divided in 3 stages: Brainstorming, Paper-Design, Digital-Polish
In this pre-phase I brainstorm what kind of approaches would be proper fitting for the problem im encountering. Meaning I analyze feedback documents and or do a core-experience-pillar revision etc. to be clear about what confinements I have to adhere to and from that point onwards I consider my solutions and possibilites.
After I settled on a solution/feature I start to specifiy it and polish the concept and idea of it. This is the stage were the first visualization are made on paper. Sketches with info-boxes until I finally reach something I'm satisfied with. Examples are visible below.
One thing I have learned in my past 5 years of making games is, that the more symbolic and visually attractive you transmit information about your ideas and designs to other people, both team-colleagues and people who are interested in it, the closer the final product will be to the inital idea. This may seem obvious, but it's something a lot of developers/designers underestimate in my opinion, especially the aspect of properly visualizing your ideas.
This final phase is the outcome of the statement above. Here I take my sketchy paper designs and reproduce/polish them in photoshop, where I use more symbols and try to visualize it on a basic level for the people who are going to implement it. And yes, it does make a huge difference! Let me show you an example of this process now:
Since Behance cannot contain .docx or .pdf files I can only share some screenshots of some design-documents I did over the course of the development. And I will provide a link below to a dropbox-zip where these doc-files are all contained, and you can watch them fully. The High-Concept and GDD for Blood Rushers plus some other "longer" documents are visible as pdf in the db link: https://www.dropbox.com/s/firofc7xtxcvh68/BloodRushers_DesignDocs.zip?dl=0.
Through playtesting and feedback, I took note that the combat-system was way to unresponsive and chaotic. In order of that I sat down and designed a complete combat and movement overhaul, it later on needed some iteration, but it definitely was the first step into the right direction. Together with my programmer I then redesigned the control-boundaries. The next iteration on it is viewable in the dropbox-collection mentioned above.
When I'm playtesting I divide into 2 stages: Test & Discuss, Document.
Test & Discuss
If I let people play the game I take sketchy notes about what stood out to me concerning the experience and what possibly needs to be changed. Afterwards I talk with the playtesters. What they liked, what they didn't like etc. Whilst doing that I try to avoid any UX-Test Biases, in order to get the clearest and natural feedback possible.
Here I basically take the feedback information and put them in a proper word document, so it's easily to get the important information out. Altogether this looks like this:
In this section I will show you how I approach my level-designs at the example of one of 2 maps currently included in the game. Specifically the MayanMap.
Paper Designs: Mayan-Map
From left to right this was the design-development of the Mayan-Map. The first two concepts were ditched because of the verticality I included. Pretty early we came to realize that verticality and isometric perspective are two things that don't go well with each other. The 3rd design lasted relatively long, but as soon as we started playtesting I figured that the pacing, specifically the amount of combat encounters in a match, took too long between each other, so I squeezed the whole design together so it fits more the core-experience pillar "Fast Paced".
Here I'm going to show you some of the menu-flowcharts, I produced for my programmer to implement. I used a programm called Dia.
In this section you can have a glimpse into how I tried to balance the game and what "technology" I used to do so.
First off: of course, Paper Design
Lastly here are some more design-templates I did in case you're interested in it.
Blood Rushers taught me a lot about Multiplayer-Design and how you constantly must consider the consequences of each feature or mechanic or even visual feedback you implement in the game . It's a totally different approach compared to SinglePlayer-Design where you have lot more control over the overall experience. When you're making a Multiplayer(mp) game you have to both consider the experience of one player as well as the "meta" experience resulting out of the mp factor. To cope with this problem, I used a principle called "Consequences Graph" shown by Maciej Szczesnik a Designer at CD Projekt Red. It allows you to think about the outlines and the consequences of a feature more easily. It's explained in this talk: https://www.gdcvault.com/play/1016470/The-Witcher-2-Between-Dreams. Have a look, it's pretty good.
Another thing I've encountered during the development of Blood Rushers is the importance of "Basic Features" and their proper implementation. Basic Features are the things that players normally take for granted. For example, good and crisp controls or a clear readability. This is also something explained in more detail in the talk mentioned above. The initial "Meta-Design" of the game should incorporate a pattern-switch of the players, meaning a total temporary change in the play-behaviour of the player. Via subtle mechanics and visual feedback this has been achieved. But beforehand we had to fix our readability problem. In the early playtests one of the most important things I and the players took note of was the lack of readability in the game. Players didn't know who they were, especially when all 4 players would clamp up in fight. Same with the attack-direction etc. And because these Basic Features didn't work properly yet, the "Meta-Design" of the game couldn't take place at all. Resulting in a lot of frustration and boredom. So, to fix that I made a total revamp of the dynamic UI and topped it with what I call a "Color-Focus UI", meaning that every player gets a specific color assigned to himself which will affect his whole UI (ex: Healthbar-color) and some vfx related stuff. This feature helped to improve the overall experience for the players a lot. Suddenly also some more complex situations started to pop up.
One of the biggest mistakes I made was the decision to implement a dynamic camera which moved with the players. The initial thought behind it was to tackle the problem that the upper parts of the map near the top of the screen were barely visible and thus harder to navigate on. This was a result of me not doing enough Paper/Lego-Prototypes of the levels, so that I could foresee this problem. Nonetheless I decided to tackle it via the dynamic cam. Aside from some technical issues, with it not always behaving like it should, it was, beside the missing distinction between the players mentioned above, the biggest contributor to our readability problem. The camera would suddenly jump up if a player died and thus leading to everyone in the game wondering what happened to him. It gave rise to a lot of confusion and it always, even after a lot of balancing, moved way to fast and you couldn't really focus on your character and his surroundings. Before I recognized this to be one of the main problems, as I said I thought it would be a solution to something, I tried to solve the readability issue through a lot of other design aspects like the movement and combat & Ui etc. Though these changes and new features where helpful in polishing the overall experience I didn't quite reach the product I wanted, until I finally decided to change the camera from a perspective one to an orthographic one, which is static again instead of dynamic. The biggest "learning-lesson" I got out of this problem, is that if you're encountering a game-experience issue and even after several iterations on old and new systems it's still not quite there, where you want it to be, it might be helpful to revisit your core design/experience pillars and maybe analyse the features you haven't thought about being the problem yet.
The last thing I want to write about, is the experience of being a project-lead and structuring a whole team. So, this was the biggest team I've worked with so far, containing a total of 5 people including me. Jan Theysen, the Creative Director at KingArt-Games once said: "As soon as you have about 5 people or more in your dev-team, you NEED a person only dedicated to managing the whole project." And I can see why ^^. Because aside from your own stuff you have to contribute to the project, everyone wants feedback on something all the time and if there's a problem, you're the one who already should have a solution to it. It's really stressful. But I love it. Though I still have a lot to learn about project-management and leading a team, this was a great learning-experience for me again. Like with every project I made in my past.
So, this was a "short" summary of some stuff I had to face while developing Blood Rushers with my awesome team GO2020! They were altogether awesome and I hope you enjoyed reading :)!
Thank you for your interest!
Thank you very much for entering this small journey in my latest project. I hoped you enjoyed it and if you want to contact me you can do that via: firstname.lastname@example.org :)!