top of page

Botanica

FutureGamesProjectBotanica_edited.png

Genre:
Horror
PSX

Contribution

Systems Design

Gameplay Design
Tech Design

Time:
4 Weeks

Team Size:

13

Engine:

Unity

Botanica Office.png

Concept

The second game project at FutureGames we were allowed to work freely within the constraints of two keywords that were going to be the games theme: Growth & Fragility

​

The team pretty quickly landed on a core horror game idea.

​​​

The player works the night shift in a greenhouse performing maintenance work, halfway through the shift is where things take a turn for the worse.

​

The player, stuck in a greenhouse facing a power outage must now locate and assemble all parts of a disassembled weedburner to aid in their escape from the premises with only a hand-crank flashlight, all whilst a monster lurks in the darkness.

​

My work focused on Gameplay Systems Design and some Tech Design on the side to bridge Designer-Programmer communication.

 
Pillar VIT.webp

Fear of the Dark

 

The darkness should feel opressive and dangerous

 
Pillar VIT.webp

Player Consideration

 

Make the player think twice before acting

 
Botanica Corridor.png

Every horror game needs a threat, without a threat tension is lost.

 

When designing such an entity one has to look at their available resources. In our team we had no animators. Working within the confines of this restriction, the natural solution was to make the monster only move when the player is not looking at it. 

​

Playtesting proved this to be a tricky design problem to crack. Initially the monster crept up on the player from behind and killed without warning giving the player no chance to save themselves, a large pain-point in early iterations. In short, it was too sneaky.

​

A heartbeat was added, growing stronger with the monsters proximity to the player, helping slowly build up tension before the kill. But the players still had issues locating the monster due to darkness of the level. So I had annother audio cue added. A spacial cue that fires right before the monster makes the kill, helping the player locate the monster and saving themselves.

​​

Making a Monster

Botanica Monster Behavoiur.png
Botanica Monster.png

This all works wonders to slowly build tension as the monster draws ever closer, and prevents unsatisfactory deaths that seem to happen from nowhere.

Botanica Poster Short.png

Light in the Dark

The greenhouse is dark, pitch black even. And the player needs a way to see.

​

I wanted to create a gameplay system that filled this function and realy reinforced both game pillars, therefore I set three criteria for myself. The system must:

  • Feel plausible

  • Require player interaction

  • Require player consideration

Fusebox systems.png

Initial brainstorming led me to the world of fuseboxes. I took note of how they worked and made efforts to game-ify their use.

In total I made 5 distinct alternatives for possible systems as shown in the image. “Alt 1” and “Alt 2” were good but caused frustrations due to ecessive backtracking. “Alt 3” and “Alt 4” did not deliver on my player consideration requirement since the player made no strategic choices in where light was going to appear. 

​

Only one held up to my criteria and did not cause exessive backtracking to a central controlpanel.
The fifth one, "Alt 5, mod of Alt 1".

 

Implementation & Testing

Fusebox 5 mod alt 1.png

The play area was to be segmented into three zones. Each zone has its own fuse slot. When a fuse is placed in say Area 1s fuse slot, area 1s lamps would turn on. No fuse in the areas slot? No light.

​

The catch is that the player does not have enough fuses to power the whole building at once, requiring the player to move around the fuses strateagicly while compeating objectives around the greenhouse.​​

​

The system was made, implemented and put to playtest.

​

It became painfully obvious quickly that this system would require heavy onboarding. Concidering the lenght of our game was to be roughly 10 - 20 minutes and deadlines were fast approaching one thing was made very clear. My darling had to go. Only one problem, there is still no light.

 

The Solution

Earlier in development, before the fusebox system was put in place, the player had a flashlight with unlimited charge. Now after the scrapping of the fusebox system I looked back to this original functionality I had sought to replace. A system can be made here.
​

Traditional battery replacement was an obvious first consideration. However I felt like a whole new design can-of-worms opened: "Does the player carry the batteries themselves? Are they limited in number or not? Does the player have to find batteries? What if they don’t find any?" Frankly put, I didn't have time for any of that. I needed a quicker solution with less of a "door problem".​​​

Flashlight Prototype Code.png

As a child I remember using a winding flashlight while at my family’s summer house in the countryside. It had almost everything I was looking for. It was believable.

​

It required player interaction. But since winding it makes it burn brighter it didn’t feel like it fit my criteria of requiring player consideration before use.​

​​

So, I just turned off the flashlight while the player was winding it. It's not how they typically work. But now it's both plausible and requires player consideration. It also complemented and reinforced the already long established functionality of our monster. If you can't see it, it can move.

​

Force the player to step into darkness, reward with light.

Prototype Code

DividerGreen.png
DividerGreen.png
Botanica Jungle.png

Botanica has been my first time creating a horror experience. As one who is not too familiar with the horror genre, it was extremely interesting analysing what makes games (and other media) scary and trying to recreate this feeling.

​

My most valuable lesson, without a doubt, is my exposure to “killing a darling.” Not growing too attached to my system and remaining flexible in my work to support the needs of the game/team. I liked my fusebox system and I was sad to see it go, but the reality of the situation was that the project demanded something else, and I, as a Gameplay Systems Designer, had to be flexible in creating a replacement to fill the void left behind.

​

Throughout this project I also refined my iterative process, placing clear criteria and goals for what I want a system to achieve in order for it to be worth my time and act as guidelines.

​

Overall, I’m very happy with the result of this game, seeing friends and classmates genuinely scared while playing is one of the best signs of approval I could have wished for.

 

What I Learned

bottom of page