My goal with Spaghetti Spell was to add an interesting twist to the farming game genre; too often for my liking, the crops you plant in these games are fundamentally just little bundles of money. Outside of one-off quests, it usually doesn't mechanically matter what you grow.

And before I go further I should say: that's not necessarily a bad thing design-wise, even if I'm not the target audience for that particular approach. If a game puts most of its focus into empowering the player to design and customize their farm as much as possible visually, then it makes a lot of sense for crops to be distinguished mostly by aesthetics rather than mechanics. The player shouldn't be punished for choosing the aesthetics that they feel best represent their vision.

That being said, I personally wanted to explore a design space that allows every crop to be mechanically interesting and useful, and I decided to do that by making a magic system that uses crops as inputs and drivers behind spells. Different crops represent different actions that a spell can take and/or data that a spell can read and use to modify what actions it takes. This system is heavily inspired by visual scripting languages like Unreal Engine's Blueprints.

These next design bits dive into some blue sky concepts that either didn't make it in to this small demo, or only partially made it in. Namely, I love the idea of the player having to learn what a particular plant does by studying its historical and modern associations and meanings. Wheat and other grains, for example, were commonly used as offerings to spirits and gods by ancient peoples. I played with that association in game by making wheat the "Beseech" node, which gives a task to some entity in the world (bees in the demo's case) and asks that entity to complete the task.

As I've said, the magic system is heavily inspired by coding, so it does run the risk of feeling more clinical and scientific than I would want a farming game to feel. Playing with the meanings and associations behind certain plants is a good way to soften the system I think, and ground it even more in nature and the earth where it belongs.

Connecting crops to each other

An important aspect of the magic system is the ability to connect crops together to form your spells. But how does the player actually do that?

I needed to implement a thematic and intuitive way to connect crops, and it didn't take long to land on the idea of connecting them via roots. It was a very natural fit given the genre, and they remind me at least of the wires used in visual scripting languages.

To make that concept work, I decided to differentiate between two main configurations of roots: closed shapes and lines. Closed shapes encapsulate crops and lines connect two closed shapes, and therefore crops, together. Detecting whether a root network is closed or a line, as well as detecting the endpoints of lines, were their own sub challenges for sure. But nothing I couldn't nail down with a little trial and error.

Sending generic data to and from crops

In this system, crops function very similarly to nodes in a visual scripting language. They can take in data, perform operations using that data, and provide new data to other crops.

Once I decided this is how I wanted the crops to work, I needed to solve the problem of how exactly two crops should communicate with each other, given that neither can explicitly know about the other.

The implementation I eventually landed on made heavy use of Unity's robust component system. A crop, when activated, would publish its output data by adding new components that contain said data to the crop GameObject itself. This does have some overhead since every piece of data needs to be encapsulated in a MonoBehavior. But the ease by which crops could search other connected crops for data simply by using built in functions like TryGetComponent() made this an attractive solution to me nonetheless.

By taking this approach, connected crops could publish and receive whatever data that wanted easily and without needing to know anything about what exact type of crop they were connected to.

Making the bees behave like bees

An important aspect of the magic system is the ability to connect crops together to form your spells. But how does the player actually do that?

I needed to implement a thematic and intuitive way to connect crops, and it didn't take long to land on the idea of connecting them via roots. It was a very natural fit given the genre, and they remind me at least of the wires used in visual scripting languages.

To make that concept work, I decided to differentiate between two main configurations of roots: closed shapes and lines. Closed shapes encapsulate crops and lines connect two closed shapes, and therefore crops, together. Detecting whether a root network is closed or a line, as well as detecting the endpoints of lines, were their own sub challenges for sure. But nothing I couldn't nail down with a little trial and error.

Optimization

In this system, crops function very similarly to nodes in a visual scripting language. They can take in data, perform operations using that data, and provide new data to other crops.

Once I decided this is how I wanted the crops to work, I needed to solve the problem of how exactly two crops should communicate with each other, given that neither can explicitly know about the other.

The implementation I eventually landed on made heavy use of Unity's robust component system. A crop, when activated, would publish its output data by adding new components that contain said data to the crop GameObject itself. This does have some overhead since every piece of data needs to be encapsulated in a MonoBehavior. But the ease by which crops could search other connected crops for data simply by using built in functions like TryGetComponent() made this an attractive solution to me nonetheless.

By taking this approach, connected crops could publish and receive whatever data that wanted easily and without needing to know anything about what exact type of crop they were connected to.

What I didn't use them for

• Design decisions
• Architectural decisions
• Influencing either of the solutions I came up with for the Magic System challenges discussed earlier

What I did use them for

• Research, specifically on flocking algorithms and how to optimize them
• Refreshers on algorithms I have written before, like A Star
• Helping to find and understand bugs
• Limited code generation*

*By "limited code generation", I'm referring to an experiment I did because I was curious about ChatGPT's ability to convert pseudocode into working code. I built out most of the bee Utility AI system (regular AI, not generative AI), and I pseudocoded the requirements to make a bee stop and wait for a bit once it reaches a particular task.

I gave that pseudocode to ChatGPT and verified and tested the code it outputed to make sure it worked as I wanted, and didn't break any of the other systems. It was a fun little experiment.

Note: "pseudocode" is just code that's written in natural language, rather than in a programming language. It's a good way to organize your thoughts before translating them into actual code.