This series of blog posts explains problems that arose during development with their solutions, as well as found solutions and decisions made. It shows the game being built from the ground up.

Why do I make games? Because I want to present the world with new ideas. Sure, it won’t be as innovative as the cell phone, internet, the compass, or any other great inventions, but all my games try out something new, an unique concept that has not been presented up to now.
Everyone knows the casual game Bejeweled. In this match-3 series you can clearly see it evolve through it’s different installments, gaining a space theme in the second game and a fantasy theme in the third. Its second installment would be the game that would get me into these endless puzzlers, with Meteos, an early DS game, at the absolute top. I wanted to make a game like that for my own, and I prototyped this little idea in Game Maker:

The rules are a bit hard to explain, but here I go: you go look for a line of recurring sequences of colors in a grid of squares. By clicking and holding your mouse, you draw a line through the squares to select such patterns. For example, red-blue-red-red-blue-red would have red-blue-red recurring two times, and thus would score you eight points (the length of the pattern * the amount of times the pattern reoccurs). It’s pretty fun once you get it, the problem is communicating these rules to new players. <a>

</a>

• A very early, unimpressive version of the prototype. *

Writing the code for this system was pretty hard. It involves a lot of specific logic specially made for this game, something I hadn’t done much before. Therefore, I am really proud of the result. Instead of using a data structure, I just used some plain strings to get started, although arrays also play a big role in checking the validity of a move.

However, squares weren’t the ideal for this. A square has four sides. Considering the player also enters a square at one side, that leaves three options. And in a corner or at the sides, the amount of options is severly limited. Hexagons have six sides, increasing the amount of tiles a player can jump to from the current tile.

<a>

</a>

Early example of the selection mechanism.<a>

</a>Operative validity checking and gem selection, and replacing them with other colored hexes.

The hexagons brought it’s own problems. How do they fall? If they just stack on top of each other, in a few moves, the whole field will be swiss cheese, again limiting the options. If they just slide to below, how does that deal with crystals who fall straight on top of each other? The only option in deciding they fall left or right would be with randomness, something that should be avoided in a puzzle game like this.

<a>

</a>

This led to some downright epic bugs- like this one here, which I’ve called ‘Waterfall’.

<a>

</a>This is the “Cube Stack” bug, which makes all hexagons stack in such a way that they look like cubes.

<a>

</a>

An example of Sumico’s selection method- green selection indication and arrows. From the game Sumico by Ludomotion.

This is where the inspiration from Sumico comes into play. It’s another hexagon puzzle game, this time based around making sums with numbers and modifiers on the field. (It slightly reminds me of one of my other games, Mathventure.) In this game, hexagons only stack when landing on top of a hexagon in it’s own column. Other hexagons are just ignored, which results in touching the tips of the hexagons in other columns when falling down. During play, you don’t notice this clear abnormality, and so it worked excellently for Hexaria.

In part 2 of this series, I’ll talk about about game design problems and big inspiration from other games. Thanks for reading! You can play Hexaria here.