Making 'Rollie' roll.

In case if anyone was wondering, 'Rollie' is a 2d plat-former game with a couple of simple game mechanics that revolves around the idea of playing with gravity. And this is its origin story (so they say!).

Concept

After coming up with the initial concept for the game, drawing few sketches to illustrate the idea and pitching it to everyone, a small game treatment was written for what was then called 'Sticky'. Which was later changed to 'Roller Boy' and finally ended up being 'Rollie'.

Early Prototypes

The core mechanics of the game (gravity changing aspect) was challenging than initially anticipated. Even though there were rapid development of two or three systems which utilised Unity Physics in one way or the other, it did not produce the intended gameplay. The main issue was that the results were unpredictable. Most of the time it would work as intended, but not always. And it had a lot of over shooting issues that was frustrating to resolve. 

It was apparent that using Unity Physics is not the best idea after all. Thus a decision was made to take a different approach.

Development of navigation system

In hindsight, deciding to do all of navigation of the player using Bezier paths was a good decision. It later yielded some great results. The process is as follows. 

Initially create a template of a level inside Blender3D modelling software which was just couple of polygons. 

And then import it into Unity. This results in a set of vertices that can then be used to create a Bezier curves. This way it would be easier to create and modify levels. Next step was to  programatically grab all of the vertices on a given plane which was predetermined.  

Finally a calculation of the Bezier path was done taking those vertices as control points. End result was a conceptual bezier path that could be used to place the player on at any point.

Then there was the task of developing the jump mechanic to comply with existing framework. This was done by manually calculating a line intersection check for a given line segment (not bezier segment). And if collided, then calculate the exact point of hit. Even though this approach took some time to implement it was much more elegant and predictable as oppose to using any one of Unity physics approaches (even if they worked).

Milking the navigation system

After finishing the navigation system, it was time to look at edge cases. Idea was to have the player jump around inside a closed Bezier curve based level, but there had to be a way for the player to get out of the level once all the objectives were completed. This was done by extending the functionality of already existing navigation framework. Instead of keeping information about a single bezier curve which is of the game level. Information of two different bezier curves were kept. One, for the normal game level and one for the path for player to navigate out of the level. 

Player would navigate and play the game using the normal bezier path and if the player manages to complete the level, active bezier path would be switched to the secondary one, thus making the player leave the game level through the opened gateway. This worked like a charm and only cost was keeping a list of extra Vector3's to construct the second bezier curve at runtime. Creation of the secondary bezier curve was also automated. This was achieved by using the gateway collider to offset a couple of vertices and saved those vertices in a different list to be used for calculations at the runtime. This meant only one level path was needed from the modelling packed for the whole level.

Time to break the rules!

After completing about 30 levels, it was time to put in some variety in the game, in terms of gameplay mechanics. This was a great place to expand on the navigation framework a bit more and squeeze some more gameplay juice out of it. Two other gameplay mechanics arose from this, with relatively easy implementation. 

First one was having portals. The idea was to have two connected portals, you go in from one and come out of the other. This was used as a puzzle element in the game. 

The second mechanic was to have a timed level where the player has to traverse through a linear type level and reach the end while completing all the necessary objectives. But instead of having a timer to encourage the user, a chasing enemy was created. It ended up been a large lava trap that follows the player as the level progresses. If the player hits this trap, one health point would be lost. 

Both of these mechanics were implemented relatively quickly because of the flexible nature of the navigation framework and the underlying Finite State Machine design pattern that was used as the foundation of the game it self.

Lessons learned along the way

It would have been ideal to have designed a system to totally create and modify levels inside Unity itself, but it was not on the priority list of the project. Even though level creation was streamlined by creating a profile of the level in a modelling package and importing it into Unity, it could have been more streamlined to have an in-editor mesh creation and editing functionality. Turnaround time of modifying levels could have been much shorter and in hindsight, it would have been good to have that kind of functionality. 

Class explosion was another issue that arose from having too deep class hierarchies. For instance, some enemy classes were around 5 levels deep. This was not an intended result but a side product of the whole code design. By the time of realisation of this issue, it was nearly the end of the project, so it was decided, not to fiddle around with it. Because to change that means introducing Factory design pattern and that would be a massive code restructuring which didn't fit the timeline of the project.

But most of the lessons was cantered around optimisation issues. Since Unity by design is more favourable for 3d development rather that 2d development, there were some performance concerns to think about. Some would say more than in other 2d game engines. But there lies the most fun aspects of game development. After all the whole point is, to have fun, right?.

by Shanaka 'Sha' Senevirathne.