Bonsai Simulator: A Project Overview

Bonsai Simulator is a two week project submitted to PROCJAM 2024. It is playable on the web and as a downloadable for Windows systems. It does not have special graphics or processing requirements.

• Team size: One (a solo project).
• Built with Unity 6000.0.24f1 game engine.
• Four 3D models created using Blender 4.0.
• Three texture maps rendered in Blender 4.0.
• Three sprite textures hand drawn on a tablet.
• 600 lines of code written in C#.
• Three shader code files written in Unity ShaderGraph.

Bonsai Simulator is all about representing the real processes of tree growth. Players care for a potted sapling using simplified bonsai care methods, such as trimming, pruning, and wiring. My goal was to create a system that represented trees as ongoing developing organisms, rather than a fixed structure at a single point in time. Rather than having complete control over the growth of the bonsai, the tree grows according to an annual system, during which the player has two discrete periods to make changes. What the player chooses to prune will affect not just the appearance of the bonsai, but also how much energy it will be able to generate in the next year.

Things that Went Right

Research

I researched the growth patterns of trees both prior to and throughout development. My main references were articles on The Grove 3D (to understand tree growth patterns,) as well as two books, Principles of Bonsai Design by David De Groot, and The Bonsai Beginner's Bible by Peter Chan, (to inform my decisions when rendering the tree's appearance.) Based on information from these sources, I decided to:

1. Structure Bonsai Simulator's gameplay loop around an annual cycle
2. Limit the growth of new branches around thicker main stems
3. Determine growth based on an annual amount of energy produced by the leaves
4. Pass energy up the trunk and to the ends of each branch for growth
5. Widen the trunk only once a year, by a small amount
6. Maintain a realistic ratio between the diameter of a trunk and it's branches

This research not only added realism to my simulation but also simplified the design of the system by keeping only systems based on real natural processes.

Code Design

My system's design revolves around three main programming concepts: interfaces, vectors, and of course, trees.

Trees

In computer science, trees are also data structures, so this project was a fun time to apply that in practice. In a tree, each branch is a node that keeps references to nodes that branch off from it. The benefit of using this data structure is that there is already lots of literature and researched systems that can be applied to make my life easier when modeling an actual tree (recursion, tree traversals, branching).

Interfaces 

The tree is made up of four main components:

1. The tree object itself, a controller that spawns all other components, computes data about the tree and processes each annual transition.
2. The branch node. The branch grows and passes energy through the tree.
3. The bud node, which stores energy throughout the year and chooses whether to sprout in the spring, based on a chemical called auxin.
4. The leaf node. The leaf node grows in branches of a certain size and falls in the autumn. It is mainly a rendered component.

To coordinate growth across these four nodes, I implement an interface called "Growth." An interface allows multiple systems to be controlled through a set of shared functionalities. The growth interface defines functions called Grow and Year Update which the tree, branch, and bud must implement. Each segment of the tree may grow in a different way or perform different actions at the end of every year, but the interface allows these different actions to be coordinated and invoked at once.

Growth is called recursively each frame, and allows energy to pass up through the tree, from the trunk into the branches, and be stored in buds. Year Update is called at the end of each year, during which time branches compute their change in thickness, buds decide whether to sprout or not, and the tree determines it's energy production for the next year.

Vectors

Linear algebra is an essential toolkit for any 3D or 2D video game, and Bonsai Simulator was not an exception. The tree is rendered entirely through lines drawn between vectors, and each branch has a couple vectors which can be tweaked at runtime to control the tree's appearance and behavior.

Each branch is represented by a vector which determines it's direction and length. When the tree branches, the next branch adds on a small random vector to branch out in a different direction. In addition to a branch's facing direction, a weight vector is computed based on the length and girth of all branches above a given branch. Weight is a downwards facing vector inversely proportional to the girth of the branch (contributing less the thicker the branch is), added to the facing direction to create the illusion of the tree sagging under the weight of its branches.

Things that Went Wrong

Scope

Ah yes, the usual suspect... scope. I did manage a minimum viable product out of most the features in my original plans, however the core gameplay mechanics of pruning and wiring are not present in the final project. I am glad that I focused on producing a good core system instead of rushing features, as the current state of the project should make implementing these features very easy in the future, but the lack of any gameplay does represent a significant failure to scope.

Art

As usual, I tend to procrastinate my art deliverables until I achieve a good code prototype. While I spent time early in the project producing art for the bonsai pot, by the time the tree system was fully developed, I did not have the time to wrap it in more appealing visual elements. As such the current tree is still rendered using line renderers, and I did not have the time to produce visual assets for buds and leaves that are as high quality as I would have liked.

Conclusions

Overall, I am quite proud of this project. It is my first game jam submission in many years and was mainly a creative warm up to get me back in the flow of creating games. I am pleasantly surprised by the improvements in my programming abilities; despite not having done many personal projects in the past four years, I found my overall code quality much higher than in past projects. That being said, I still struggled with scope as I have in the past, and I think there are a number of actionable changes I can make to avoid this issue in the future.

1. Creating more art prototypes. The same way temporary code is the most permanent kind of code, I rarely have time to expand on the visual quality of my game after implementing the first "temporary" solution. With this in mind, I should devote at least as much time to creating an art prototype as I do for a code prototype.
2. Focus on gameplay. I tend to enjoy the systems and simulations aspect of game development much more than gameplay aspect. During this project, my camera controller was put together just hours before submission. This tends to result in complex simulations without much thought to progression, player interaction, or user interface. In the future, I could experiment with combining an art prototype with a gameplay prototype.

In general, my changes speak to creating a more balanced development roadmap with equal parts attention given to the whole project.

Future Plans

This project is not over yet, and I plan to implement the gameplay systems outlined in the project overview, as well as iterate on and improve the art. My goal is to create a fully playable game that covers everything in my original design document. I'll be released changes along with devlogs and development insights to document the process now that I am less restricted by time.

Thank you so much for reading,

-Ian