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.

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.