Jesper Börjesson.

Design

I had a vision to create a puzzle game that could have a large amount of levels without adding new features and that could easily be playable with one hand. That lead to the concept of a grid with pipes.

Prototyping

I wanted to get a functional version of the game as quickly as possible so during my second week of the project I rapidly prototyped the game using Blueprint. I wanted to do the prototype in blueprint because you can get results very quickly with visual scripts. To make sure that I could easily create levels I needed a solid framework for the game. I made two actors one Pipe-Actor to act as the puzzle pieces and one Grid-Actor to act as a manager for the game.

Pipe: There are seven types of pipes Left-Down, Left-Up, Right-Down, Right-Up, Vertical, Horizontal and empty. The type is an enum that can easily be edited by a designer through a dropdown menu. Whenever a pipe changes type it will automatically update its static mesh and other variables to sure it functions in the correct way.

Grid: The grid holds all pipes, moves and manages them.

Send, Receive, Accept

For the game to work it needs to know that a solution has been found and since there can be more than one solution, I needed a way for the game to check if a solution was found furthermore, I need to track what pipes are currently connected. This was solved with three function that the pipes have:

Send: Any pipe can send a signal to another. Since a pipe knows its own orientation and where it got a signal from it can find out where to send it next. At the start of the game and whenever a move is made, the start pipe will send a signal

Receive: Any pipe can receive a signal from another pipe. When a signal is received it will find out if it can accept the signal. If a signal is sent to another pipe it will always receive it but not necessarily accept it.

Accept: When a pipe has received a signal, it will check if it can accept it from that direction. If it can it will change color and send a signal to the next pipe according to its orientation. If the end pipe accepts a signal the game is won. If a pipe does not accept the signal it will not send a new one effectively stopping the chain.

Rewriting

I had set as a goal that the game should be written in C++, partly to improve my own grasp of the language but also to optimize performance since mobile devices have limited capabilities. I spent most of my third week Blueprint scripts into C++ code. While it was very tedious it wasn’t to hard as the logic of how the game would work stayed the same. Since I had to rewrite it all anyway, I took the opportunity to remove unnecessary parts of the code and add some improvements.

The process helped turn a lot of spaghetti into neat code.

Making level design easier

Another goal of mine was to be able to make tons of levels. In order to achieve that I needed strong tools that could simplify the process. First, I tried to make sure that a designer could easily edit a level. I made template levels for each size 3x3, 4x4 and 5x5. I exposed a very limited number of variables in easy to handle formats. The designer can change the orientation of a pipe by a dropdown menu, set the starting point, ending point and whether the pipe is moveable with bool. This means that a designer doesn’t need to place anything in the level, you can just edit values on one of the existing templates. This also ensures a consistency throughout the game. While it can be fun to handcraft each level, it is not very viable for mass creation of levels. So, I needed some sort of random generation. This led to the shuffle function. Having a fully random level generator would produce levels that can’t be solved, and it hinders the designer’s ability to create scaling progression. The shuffle function is a good compromise, is simply plays the game randomly but still according to the rules. This means that a designer just needs to create a solution and can then let function shuffle it around.

Making it readable

During my last week of the project I decided to add some graphics. Since I am not a graphical artist, I did not intend for it to look great just to be more readable. Mainly I wanted to make sure the player could see their progress. I already had a system that could support this. Every time a pipe accepts a signal it will change its color to green and every time a new move is made all pipes will reset back to the default color. This lets the player see the flow of the signal no matter where the signal is going.

Shipping

The game ran just fine on IOS when doing testing but to fully realize my goals it needed to reach the IOS App Store. Making sure that the App met Apples requirements was a tedious task, but the experience gained was worth it. I wanted to make sure that the app was downloadable without wi-fi and to do that the file size needs to be less than 150MB. To achieve this, I removed everything unrelated to the final product and minimized texture sizes. It got me down to 110MB, slightly below my goal. Now the Arcane Connect is available on the App Store.