The Work

The plant blueprints are structured like this after some iterations:

There is one base plant blueprint which has the attacking, health and death code. This is the parent blueprint of all outside "wild" plants. From this base blueprint there is another base blueprint for all inside plants, which adds all inside behaviour such as upgrading, growing fruit, water levels, etc. This is then used by all plant stages.

Inside Plants

Each inside plant stage is its own blueprint, which allows the variables to be tweaked for each growth stage.

Pots

Inside plants can be planted into pots. To support this and to support all the various different plant pots the game has, I created a pot slot blueprint which contains all the logic. This pot-slot blueprint is then used as a child component inside all the various pot blueprints. This lets artists and designers put multiple places to plant inside one pot in any location they want.

The pot-slot itself is at first an interactable and spawns the plant of the seed you give it. After this it becomes un-interactable to allow the player to interact with the plant. The slot always keeps track of its current plant. When it doesn't exist anymore, the slot opens up again and the player can plant once more.

Watering

The plants and seeds you place can be watered by the player. When watering a seed it causes the seed to upgrade to the first phase. From this phase on the plant needs to be watered once every three days (indicated by the three water droplets).

The diegetic UI was made by Flemming and the exclamation mark appearing is a small bug in the current build.

When water levels drop to 0 one of two things can happen. Either the plant dies, or if the plant was in the final stage it turns aggressive like a wild plant.

Upgrading

Each plant has a list of items it needs to be upgraded. When the player has all the needed items and interacts with the plant, VFX is triggered and the plant switches to the next phase of itself, which in turn has another list of required items to reach the final phase.

Fruit

When the plant is in the middle phase or the final phase the plant starts producing fruit. Fruit is produced once every 25 seconds and is guaranteed to be there when the player returns from the outside. When the plant has fruit it will play a sparkle VFX until it is harvested by interacting. Each plant has a list of items which are its fruit.

The final stage of a plant gives multiple types of fruit as can be seen here:

The fruit and water system went over some iterations based on ideas of Jeroen. We had finally figured out how the day night system should work and this caused the water and fruit system to need to be overhauled. The plant should now only lose water levels when the player goes outside, not over time. And the fruits should instantly grow when you go outside. Later Jeroen added to this that fruits should still also grow over time when the player is inside. This is an example of the many ways I worked together with other disciplines.

Outside Plants

The outside plants are always in an agitated state. While in this state they play an angered idle animation and turn towards the player. When the player enters their attack range they save that location of the player and turn towards it. Once they are facing where the player was at that point they will attack. These attacks deal damage to the player using a hurt box and get triggered by an animation notify on the exact frame the plant should cause damage.

Face plant:

Tree plant:

Eye plant:

The eye plant was added pretty last minute being modelled in week 7 but in the end we got him in completely and he fits very well. His attack freezes the player for 2 seconds and does 10% damage. (There is a visual bug in the gif showing the health bar going white at 90% but that will be fixed for industry day)

Another example of some of the interdisciplinary work I've done is with the eye plant. The eye plant went over a quick succession of iterations. The first version was too easy to dodge according to Jeroen so I worked with VA to adjust that. The first new animation Rina made wasn't exactly what we needed so I talked with her to make sure we were on the same page. After she had made it I implemented the animation again and showed it to Jeroen who was very happy with it.

Another example is also with the face plant. In sprint 3 together with VA we thought it would be nice if the face plant did damage in two locations at different times. Since that seemed to fit the animation, I implemented this based on that idea. Then a week later Jeroen told me that it made the plants too difficult to dodge so I removed that iteration again.

After all the pots and plants were made they were placed into the level by Marko and Minh and they used my blueprints without much trouble. When they wanted something and didn't know how to do it, I showed it to them or implemented the option if needed. Especially things like damage, health, drops, fruit, grow speed were changed and iterated upon a lot. Showing more interdisciplinary work.

Relevance to the Planning

I started working on the caretaker in sprint 1 when all other tasks were already being worked on; the caretaker was the only task available at the time. Which is why it was set to be a completed prototype at the end of sprint 1. Then in sprint 2 I made some small improvements to make the caretakers playable and in sprint 3 spent quite some time to finish them off and turn them into a presentable state.

Here are some of the tasks I created for the caretaker to show that my work meets the DoDs and was in line with planning:

The Work

I contributed all the logic to the caretaker.

The design of what the caretaker should do was tweaked quite a few times. And I followed these changes as they were tested by Jeroen. At the start of the project the caretaker didn't have any deactivated state yet and the caretaker itself was not very good at keeping plants alive.

The caretaker starts off deactivated and interactable. When you give it the core it becomes un-interactable and starts its behaviour loop. One thing I added to this to help the VAs was that when the caretaker becomes activated it turns on a red spotlight and it turns up the emissive glow of the core in their chest. To do this I created a dynamic material instance and added parameters to it. Something I had no experience with yet. But VAs liked the end result a lot.

After being activated the caretaker wanders around a bit and then selects the plant that has the lowest water level. Then it walks there and waters the plant. After doing this it recharges its water at the pond and starts wandering again.

The caretaker doesn't have a watering can or animation in this video yet since those were finished near the end of the block.

Here is the final caretaker:

Caretaker behaviour loop:

I started work on the caretaker in sprint 1 because all other major parts of the game were already being worked on. Here is a demo from sprint 1 of the caretaker behaviour. The caretaker remained in this state the next sprint until I polished it up in sprint 3. It was a low priority task in sprint 2.

Relevance to the Planning

During sprint 2 I had added the upgrade functionality to the plants. This needed to be showcased to the player to truly be testable. I started work on this task adjusting Tijn's interaction system since I already had experience with it by helping him. After I added the functionality for the pop up window I asked Flemming to take over the UI part since it was very similar to UI he had already made.

The Work

The interaction system was made for a large part by Tijn. However we had to iterate upon parts of it a lot and when we did, I did that together with him. One part I added was an interface that notified actors if they were the object to be interactive with. Which became the core of all diegetic UI.

Another feature I added to the interaction system was the ability to make an object no longer interactable at runtime. I did this by adding a function to the interface which by default returns false. Now for example in the caretakers if I need them to stop being an interactable at some point I can override the function and add my logic.

I created a core in the world that you can pick up. It has a flashing light to grab attention and can be interacted with to pick it up. I also created the core item which is given to the inventory.

Save and Loading

I contributed to Tijn's saving and loading system as well. The majority of the saving was made by Tijn. I added the saving of the selected slot which was causing problems for Tijn.

And I did most of the saving and loading of the caretakers since he wasn't familiar with how they worked. For this I also had to save the caretakers' dynamic materials since there were two variants which were set in the instances in the world, which was an interesting challenge.

Character Health Light

Relevance to the Planning

This was a feature I added before we released our game. At the time there was no way yet to see your current health so our designer suggested putting at least this feature in so we could see if the player's health was low based on the light value of the player.

The Work

Gave the player a flashlight and an emissive red core glow. These are both based on player health. When the player gets hurt their flashlight gets less strong and their emissive core also gets more dull. This was also done using a dynamic material instance.

Dynamic Lights

This was a very low priority task that I completed at the end of sprint 4, when all major blueprints were already checked out. I decided to help out VA by making all the candle and lantern lighting in the world flicker based on a timeline graph.

Itch Contribution

I also contributed to our itch page and builds. For example, I worked together with Flemming to upload our first version to itch and set up the main itch page. After this, I also uploaded our second Itch version and wrote a big change list of all the changes made. For this I also had to format the devlog page and make everything look nice.

View the devlog on itch.io