Category Archives: FlowerPlower

DevLog: One Step Forwards – Two Steps Back

The development of the Flower Plower prototype is currently on pause.

Flower Plower started 5 months ago with the hopes of making a ‘quick prototype’ that would give me a chance to develop my tools and frameworks so that future games could be prototyped more quickly.

The overall design of the game was not completely solid. I had some vague ideas of how things would work but changed my mind as things progressed. The design of the project changed from Pacman to Chu Chu Rocket.

While I still really like the idea for Flower Plower as a simulation puzzle the process of converting the code from how it was designed for a maze running arcade game to a puzzle game is getting in the way of the initial goal for the game: Optimize my Unity Workflow

The work I have done so far on Flower Plower was by no means a waste of time as I was focusing on code that I can re-use for any game.

I have taken the code that I developed for Flower Plower and re-purposed it for a new game. Now I can focus on building my tools and solving the problems relevant to many games rather than refactoring classes and staring at compiler warnings.

The idea for the new game is kinda dumb so I’m really excited to work on it!

Devlog – Discretion Required

Booming flower prices promise great rewards for the fastest Flower Plower!

Initially Flower Plower was conceived as a Pacman style maze running game.

The design of that game called for a continuous movement grid. Objects on the grid can move smoothly between grid cells but are only allowed to turn when they are in the center of a grid space.

Objects have two variables controlling their direction. Current Direction and Desired Direction. If the object wants to change its direction it sets the Desired Direction variable.

When the object reaches the center of a grid space it checks if the Current Direction is equal to Desired Direction and tries to turn if not. If a wall is blocking the turn the Current Direction remains the same until it is possible to turn.

This system allows the player to hold the direction they want to turn early and their character will turn when it is possible.

Continuous Grid Turn

Objects move continuously and are only allowed to turn in the center of a grid node.

One added complexity is allowing 180 degree turns in between tiles. It might feel better to allow players to turn slightly late and move back to perform a turn – just a slightly wider window of opportunity.

This system works well for a Pacman style maze runner but now that my prototype is heading in a simulation puzzle direction I have decided to use a discrete grid.

A discrete grid uses arrays of integers for positions rather than Unity vector3s with float values. This means that an object can not be between two grid locations.

This approach has brought with it a lot of additional complexity but I am starting to see the light at the end of the tunnel! So hopefully there will be more details in a future post.

Devlog – Fine by Design

Coordinate the chaos of flower farming during boom times. Become the ultimate Flower Plower

The Limitations of the Design

The initial plan for the game was something similar to Pac Man where you plant seeds and grow flowers.

As development progressed important questions such as ‘What should the player do?’ and ‘What makes the game fun?’ were mostly answered by hand waving.

The rough idea is that the player would plant flowers in the paths between fields. The fields would be filled with sheep who would periodically move from one field to another blocking the paths. As the game progressed the player would expand their network of fields and paths so the strategy would be to create paths that would be good for farming big combos from the flowers while still having enough branches to avoid the sheep.

On the surface it sounds great but when trying to make the ideas more concrete it becomes more difficult to find the fun. Flocks of sheep that block the maze as the main obstacle isn’t great and while the idea that the player creates their own maze is cool the mazes would ultimately be a little dull. After creating your own 4 directional maze you will still end up with a simple maze – it’s hard to see where there’s much room for excitement.

Simulation Puzzle

So the new idea is something of a Simulation Puzzle.

The player places signals on the farm that control the movement of tractors. The tractors pull trailers that will perform actions such as planting seeds and harvesting flowers. The game will reward getting things done as fast as possible and their will be an emphasis on timing actions so that they occur simultaneously.

The main influences on the design currently would be the Dreamcast classic Chu Chu Rocket and a great construction sim called Factorio. There should be plenty of potential fun to be found from setting a farm up, watching it run and trying to improve the amount of flowers you can produce.

Implementation Progress

A focus of the implementation strategy is to reduce coupling between components so that the game objects can be repurposed without throwing out all the code. Happily the plan is working and good progress is being made.

The new design does have the requirement that objects should move across the grid in a predictable fashion.

Objects move continuously through the grid using floating point numbers to represent their current position. The downside to this is that if you move two objects the same distance at the same speed they may arrive on different frames.

This indeterminism is caused by inaccuracies that can result from rounding floating point numbers. Long numbers can’t be represented exactly by a 32-bit number so over time mistakes will creep in.

I have dealt with this problem before when trying to make an action replay system for Jet The Pack and my solution then was to just scrap the replay system. It’s very hard to get the Unity physics engine to do the same thing twice.

For this game I plan to update the objects that move on the grid so that logically they are only ever in the center of a tile. They can move periodically using a tick sent through the event system and the meshes that provide their graphics on-screen can be moved over time using linear interpolation.

Devlog – Every Event Needs a Queue

Sow the seeds of an ultimate score rush combo in Flower Plower!

Before adding exciting gameplay features an important question has to be answered:

How do game objects talk to each other?

One of the most important goals of software design is to reduce coupling.

Coupling occurs when the actions of one system depend on the state of another. If two objects are coupled then making changes one could result in a bug in the other. As the game grows in complexity this can lead to frustrating hours reading stack traces.

Ideally the components of the game should know nothing about each other. The tractor should have no idea what a flower is, how gravity ties it to the road or what strange force is compelling it to change direction. The tractor should sit in isolation just doing whatever tractors do.

If all the components are completely separate then how does the system handle interactions between them? How does the tractor tell the game that it just harvested a flower and scored a point if it doesn’t know what a flower is or even that its performance as a tractor is being evaluated?

This is where Software Design Patterns come in handy. This problem of code getting hairy when components meet has been suffered and studied for a long time. Some smart people have identified the problems that happen most frequently and come up with some template solutions that can solve them.

For this project I went with the Event Queue:

The specifics of my Unity implementation are somewhat different but it has the following features:

  • An Event Queue component can be added to any object and stores a list of events that happened on that frame – the list is cleared during LateUpdate (So technically it’s the events that happened last frame).
  • Objects can read or post events using an Event Queue Accessor component. The accessor component stores a reference to the event queue and actively checks rather than being notified by the queue.
  • The Event Queue does not store a reference to Event Accessor components so it will not keep them alive if they are destroyed. The accessors need to have their reference to the queue set when they are cloned at run time.

An example of how I have used it in Flower Plower would be the detection of the tractor colliding with the flower. Both these objects have a parent called ‘Farm’ with an event queue.

When the flower collider detects a collision with a harvester it puts a ‘Flower Harvested’ event on the farm’s queue. The Score and Audio system don’t need to know the specifics of the collision but they can check the farm’s event queue to find out what’s going on on the farm.

It’s a powerful idea that the Flower and Tractor can do their thing without having to report to any component except to say ‘This Happened’ to the event manager it makes it possible to combine modules in various ways. E.g. the same Tractor that is used for player control could be used in a game demo system.

It took a lot of work to prototype this important system but hopefully it will work well throughout the rest of the development.

As a reward for making it through that wall of text here’s a bonus video of some integration tests running!

Just look at those glorious green ticks.

Each test starts the game and goes through the menus before doing their thing so any weird edge-cases will be caught! My last game Spacebomb has some glitches that can make the player totally invincible so I’d like to avoid that this time.

Devlog – Progressive Regression

Flower Plower is an arcade maze runner where you use a tractor to plant and harvest flowers. Score enough points and you can create new areas on the map. Shape the layout of the maze to maximize your combos and achieve high scores. Just don’t run over your sheep!


Progress is coming along nicely on the prototype version of flower plower.

The basic mechanics of driving a tractor around planting and harvesting flowers are in place as this high quality but low file-size webm video will show

Recording videos and producing good quality web-friendly videos has been a learning curve. The current process is as follows:

  1. Record the screen using Open Broadcaster Software
  2. Edit the video using Power Director
  3. Convert to the video to webm using FFMPEG (My version of Power Director does not support webm).

It’s a slow process but it works!

Regression Testing

There’s currently a bug that occurs when the player changes direction when between two tiles.

As part of my new commitment to following some sort of Software Engineering practice I decided to make a test to re-create the bug before even attempting to fix it:

I had to redesign the input handling so that it would be possible to control the tractor via test scripts. The code is a lot stronger as a result!

I used the Command Pattern to encapsulate any calls to Unity’s Input methods. It helps reduce coupling and now it’s possible to create some sort of replay system if I decide to.

Creating a test that recreates the bug before attempting to fix it is a nice way to approach the problem as it gives you a chance to figure out exactly what the problem is before poking in code.

Unity’s Test Runner is great for executing testings from within the editor. It’s satisfying to watch all the tests run…

Devlog – Adventures in Pathfinding

I am currently prototyping a new game that works a lot like Pac Man except you’re a farmer planting and harvesting flowers.

The finer details of the game are still to be worked out. The first prototype had an open grid of squares and the player was able to move freely in any direction.

Flower Plower Prototype

An open grid did not work well with Pac Man style controls.

This approach did not work due to how the movement system works. The player’s tractor moves continuously in a straight line but is only allowed to turn when it is in the centre of a tile. Turning felt unresponsive if the player turned between tiles.

As a solution I decided to try mazes with long corridors. I wanted a maze that would start small but grow into a large maze as the player progressed.

Starting Maze

The maze starts with 1 square and grows as the player scores points.

After dusting of the old Data Structures and Algorithms textbooks I thought that a good approach would be to use a graph data structure. I put together a simple implementation using C# that I’ll share on GitHub in the future.

One constraint on the grid is that there should always be an Euler Cycle available. This means that it should be able to visit every path in the maze without repeats. The player’s score will scale with big combos of flowers so it’d be nice to always have plenty of scope for long chains without repeats.

The easiest way to accomplish this was to make sure that each node in the grid has 2 or 4 paths as continuous graphs where all nodes have an even number of vertices will always have an Euler cycle.

Maze Extension

The results of applying 1 extension to the grid.

The algorithm for extending the maze is as follows:

  1. Select 2 random degree two nodes. (I.e. Nodes with 2 links.)
  2. Add an extra link to each of these nodes so there are 2 nodes in the graph with 1 link.
  3. While there remains an odd node in the graph: Link it to another odd node.

All being well this method can be used to extend the maze while ensuring there’s an Euler cycle.

Big Maze

A large maze created by repeatedly extending the maze with this algorithm.

When the method works it can generate large mazes with Euler cycles very quickly however it has 2 major disadvantages:

  1. It is complex and error prone: On the plus side I now know how to recover Unity from an infinite loop. On the negative side I put Unity into many infinite loops and chased many frustrating bugs trying to get the thing to work. It would be difficult to further tune the algorithm for varied gameplay.
  2. The mazes aren’t that fun: There’s an infinite variety of mazes but they’re all quite ‘samey’. Playing on random mazes doesn’t seem like it will be terribly engaging.

So while the random maze prototype did not completely pan out it wasn’t a total waste of time. I have a decent graph data structure that can be used to represent levels in future version and some path-finding code that can be used for AI.

Scratch Memory Match

Memory match card game tutorial in progress.

In other news I have a Scratch tutorial in progress detailing how a memory match card game could work.

The Scratch code is nearly complete and I’ll be starting the write-up soon.