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!

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.

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.

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.

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:

http://gameprogrammingpatterns.com/event-queue.html

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.

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!

Prototype

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…