After a few weeks of continuing on the prototype, I finally reached a standard sufficient to provide proof of concept. My greybox demo works as game.
- The game mechanics work as expected.
- The game flow delivers a beginning, middle and end.
- The menu system allows the user to handle gameplay.
While testing the game with a family member with an earlier version of the prototype, I noticed something which I had not previously considered. I gave my tester the Quest demo with the intention that he would play it. That’s not what he did. He didn’t try to play the game, he tried to win it. That’s when I realised that I had to change the emphasis on the greybox release, by building a viable scoring system.
Game Mechanics
The original row interaction algorithm was tweaked slightly from the version previously presented. The first version worked in a simple case, but when I changed the flexibility of the game to allow for different sizes of grid, some unexpected results occurred.
Designing an algorithm to find matching tiles was then a priority. I needed to be able to assess the grid to assess matches so that I could deliver a list of tiles to generate points and to handle for continued game play.
The biggest challenge in this project was in delivering the tile-swap mechanic. I had to deliver the process under which matches could be detected, and then come up with a way of replacing matched tiles with new game assets. After matching tiles, I had two options.
- Tiles would be replaced by the tiles from above dropping down. Chains of matches could be possible.
- Tiles would be replaced by random tiles that didn’t create instant matches.
The first option would deliver the classic experience we see in games like Bejewelled and Candy Crush. However, I opted for the second option as I figured it would be quicker to deliver, and moving fast was important for this proof of concept demo. However, in developing the algorithm, I discovered that programmatically determining how to replace tiles with random new tile types that didn’t create new three-in-a row matches was not exactly trivial. After a few rounds of testing, I arrived at an algorithm that worked.
This algorithm creates an exclusion list, which is a list of tile types that cannot be candidates when assigning a new random tile type. Because the algorithm receives the tiles in order (from bottom left to top right), the undetermined matches after the tile can be ignored and handled differently. When the exclusion list for a tile is determined, a new tile type can be assigned, and the adjusted grid information is used for the next tile swap until all matched tiles are replaced.
Game Flow
I didn’t want to overcomplicate things, so I designed the demo to work off the basis of two core menus.
Gameplay Video
So after all that algorithm planning, here is the demo!
Next Steps
The art-work shown in the demo video, while not literally grey, is as basic as it can be. Having shown that this game works as a concept, one of the next big tasks would be to design an aesthetic for the game to replace the threadbare presentation.
- Tile assets are to be replaced by higher quality prefabs.
- The set and background should be far more elaborate.
- UI menus are rudimentary and need a big upgrade.
- FX should be added to enhance and polish events as well as to add some eye-candy in the background
- A concept which ties all the artwork together needs to be envisioned.
- The sound effects should be replaced by far more fit for purpose candidates.
The other aspect of the game to consider developing is the level design. Not only could the tile-drop (as opposed to tile-swap) approach be introduced, we could also use new mechanics, such as hazards or a system for creating bonus matches. Let’s also not forget that we could use more use of the interactors by creating new ways of interacting with the game elements.
Summary
As a solo developer, not only did I take on the role of artist and game designer. In fact, by far the biggest commitment in creating the prototype was the gameplay programming. Working on the demo certainly gave me a newly found respect for what gameplay programmers are lumbered with. I certainly learned that as a gameplay programmer, you have to solve complex abstract problems by breaking them down into smaller logical steps. Once the algorithms were written, I was really impressed by how straightforward it was to implement the logic in Unity. The Unity input system makes it very straightforward to handle user input from the hand controllers, using that to drive gameplay and flow.
robodojo 