RITUAL
Project Description
Developed as the last and biggest project made during my year at Digital Bros Game Academy, in collaboration with Lunar Great Wall Studios, "Ritual" is a third person multiplayer survival game, where your sanity is at stake and the only hope not to get lost in an endless nightmare is the dim light of a lantern. Orient yourself in its dark and twisted environment, watch out for the tricks that your mind may play on you, and try to flee the cursed swamp before losing your mind!
Role(s) and responsibilities:
Lead Designer
-
Supervised and handled the workflow of a team of 5 designers (me included) using the Scrum methodology, making sure that everything fitted together and that we all followed the same vision, helping out my colleagues in case of need.
-
Documentation writing and mainteinance (from the very first pitch and macro design, up to the very last detail design document).
-
Maganged the economy design, using spreadsheets and creating some small Python scripts to automate some functions.
-
Collaborated all together on defining the gameplay loop and the main systemic interactions.
-
Collaborated on level design work, taking care of affordance and helping drawing up the level design master document.
-
Supervised and helped with the work on the menu flow and UI/UX definition.
-
Regularly communicated with the team leader and other departments' leads, in order to address any complications or needs as fast as possible.
-
Briefly worked on the first interaction of the AI's behaviour tree.
Sound Designer
-
Searched and implemented all in game sounds using FMOD.
-
Coded and handled an audio manager class in Unity.
-
Kept track of the type of licence of every audio file used, in order to give the right attributions where needed.
Other
-
Searched (thank you Mixamo) and inserted almost all character's and enemy's animations using Unity's animator controller and by coding some stuff, discovering how cool avatar masks and layers sync are!
Design Process
Pre-production
We kicked-off with a brainstorming session, where each member of any department could express its opinions and ideas, in order to lay out the basis of the game and the desired and shared experience we all wanted the game to have, whilst keeping in mind the constraints and needs expressed by our client, which were:
Genre: Survival (3D)
Camera: 3rd Person
Must have:
Crafting
Synchronous Multiplayer
Original Setting in respect to the genre canons
Target audience: 16-35 mid-core
Business Model: Early Access
Platform: PC
Afterwards, during a short period of 2 days, we (as the design department) worked on studying the market, in order to find feasible competitors/references to analyse and from which to take inspiration from, in order to better define our core mechanics and game loop at a high level, before I finally laid out a short pitch (elevator pitch like) which I eventually presented to our trainers.
After collecting the feedback from our trainers, who were slightly worried about the magnitude of the project but overall satisfied with the concept, we proceeded on better analysing our reference games using the MDA framework, in order to have more clarity on the structure of the game, before pitching it to the client in 3 days.
Following the definition of the whole structure, I proceeded on writing the Macro Design of the game and creating the actual pitch, which I eventually presented to our client.
Subsequently to our client’s feedback reception, which was overall satisfied with the pitched game, we proceeded to review once more the Macro Design with every team member, in order to remember our shared vision to everyone before entering the production phase.
 |  |  |
|---|---|---|
 |  |  |
 |  |  |
 |  |  |
 |  |
Production
We started the production phase by putting our main focus on the 3Cs (Character, Camera, Control), in order to obtain a working prototype with which to test the core loop as well as to find possible technical limitations as fast as possible. In regards to the camera, since we had some problems with the cut-out-view feature during the development, I proceeded to implement a method to bring the camera closer when entering enclosed spaces and move it back to its original position when exiting them.
Meanwhile we started working on better defining the game loop associating it to various mechanics, seeing if the generated dynamics supported the experience we wanted and defining the short, mid and long term objectives for the players. At the same time, being this a survival game featuring mental sanity as the character’s main statistic and core mechanic, we worked on defining the systemic interaction between the various statistics and statuses of the character with the game world and between themselves.
 |  |
|---|
Being it a mandatory feature for the game, we then proceeded on defining the crafting. At first the whole concept was to give the player a “Breath Of The WIld like” experience, hence letting him discover recipes by trial and error. The idea was for him to have an actual magic circle in the base camp, on which to position elements before executing a ritual which would affect its maximum sanity value, giving him back the resulting item.
Whilst defining the whole thing though, we realised that the effort/result tradeoff was way out of our league, considering the development time and that the crafting wasn’t our core mechanics (which is the character’s sanity and the resulting audiovisual feedbacks he’ll experience as a result of its value). Therefore, in future iterations, we proceeded on downgrading the crafting in what I like to call a “vending-machine mechanic”, hence letting the player collect ingredients which could just be considered different cuts of a currency, that he would then spend by selecting an affordable item from a crafting list.
The final version of the crafting mechanic was then connected to our core mechanic by having 3 different levels for each craftable item: the lesser the character’s sanity level is when crafting, the more powerful the shown craftable items are.
 |  |  |
|---|
Another mechanic that caused some troubles was the throw mechanic. At first, in fact, along with the “free-crafting” mechanic, we decided that the player could get 3 different kinds of throwable items, along with all other types, which were: stun, orienteering, diversion (the main idea was to delegate all interactions with enemies to the throw, so that we wouldn’t have to work on melee combat, thus avoiding to further complicate the AI’s behaviour tree and increasing the amount of work needed in general, not being this a pillar for our core mechanic).
Long story short: after laying down a quite detailed and extensive detail design document and all its future revisions and having had a prototype actually implemented in game, we then realised that it was not needed whilst reviewing the whole system design to find superfluous features, hence we removed it in favour of the much simpler lantern mechanic, which can now be found in the game. Lanterns, in fact, can:give the player a choice between higher enemy detection and stealth, also working as a timed shield over sanity when turned on and vice versa
allow players to recognize each other thanks to their different colors, since all players share the same character’s model
promote teamwork by helping players orienteering between themselves and luring enemies away from each other.
Regarding the level design, some mistakes were made at the beginning, which eventually led to a big problem:
When starting out we proceeded on creating a master level design document, where we wrote down the character’s height and the associated game’s scale, along with the climbable objects’ height, minimum objects’ height before being spotted by the AI, etc. During this process, though, we gave too little attention to affordance, in particular to climbable objects.
Whilst analysing our references in fact, we just came to the conclusion that a quick brushstroke on the side of a climbable object would have been enough for our case. No bigger mistake was ever made! This brought us many troubles during future development: in fact, every time we held a testing session with a new build, the main recurring question was “why can I climb here but not there?” and, given that the client was quite fond of the verticality of the map and its navigation, this was a big problem.
So I proceeded on studying affordance more in depth, coming to the conclusion that at the beginning we didn’t carry out the task properly and we should have done many things differently, which was too late to do, which were:defining a buffer on non-climbable models’ height, i.e. after defining that a climbable object would be 2 meters/units high, we should have proceeded to claim that no object’s height could fall in the range of climbableHeight ± 1.
Setting a constraint on model’s color, whose color should have been darker/neutral in respect to a more vivid and distinguishable overall color for climbable objects
Requiring a more rounded or edgy outline for non-climbable objects, in respect to climbable ones who should have had a squared and well-defined shape (letting the player think “I can hang on that”) parallel to the ground.
Since it was too late to do that, I solved the problem by asking programmers to extend the already implemented interaction system to the climbing action, too. In other words, we gave the rope model we previously placed on all climbable objects the same properties as chests, hence every time the player approached the object, the rope would start to glow white and, eventually yellow, as soon as he got close enough, along with displaying a prompt telling him to “press space to climb”.
Another big challenge has been defining the UX and, in particular, insanity effects, which were part of our desired core mechanics. Since this was a new original feature, except for some reference games we found such as Eternal Darkness, which unfortunately weren’t much close to what we wanted to achieve, given that they mainly focused on breaking the 4th wall, we proceeded with a constant trial and error fashion where we would brainstorm, check the feasibility of the feedback, implement it and then reiterate.
Finally we worked on the tutorial, which didn’t create any problems from the implementation perspective, considering we already had tooltips implemented in the base game, which could be easily reused. Anyways, whilst defining it, we used the infamous “Super Mario rule” (or more formally, the Rule of Three) to deliver a tutorial which would be less invasive as possible, whilst teaching the player the basic mechanics of the game by first putting him in the condition of using a mechanic in a safe area and then having him repeating it in a more hazardous place, mixing them up throughout the tutorial level.
For the sake of completeness, I’m now citing the other things we worked on during development, which didn’t cause any major concerns or that I didn't have a major involvement with and, thus, weren’t mentioned before:
UI, of which you can find the whole flow here (along with other cool stuff)
AI behaviour tree
Level design, in particular designing the draft of the map and implementing the blockout
 |  |  |
|---|---|---|
 |  |
