{"id":790,"date":"2011-02-15T09:10:12","date_gmt":"2011-02-15T09:10:12","guid":{"rendered":"http:\/\/blog.cjohnson.id.au\/?p=163"},"modified":"2011-02-15T09:10:12","modified_gmt":"2011-02-15T09:10:12","slug":"realising-rotablock","status":"publish","type":"post","link":"https:\/\/cjohnson.id.au\/game-dev\/realising-rotablock\/","title":{"rendered":"Realising Rotablock"},"content":{"rendered":"

One of the goals for the Rotablock milestone<\/a> was to realise the gameplay mechanics and in a way figure out all of the details behind the design of this game. Over the last few days I’ve been tinkering around with the gameplay system, trying to get the most out of it. As a puzzle game, there is a primary focus on providing the player with challenges and interesting ways to overcome such challenges. Today I want to discuss my choices behind the gameplay mechanics and how I’ve tried to fully realise the game.<\/p>\n

Mechanics<\/h2>\n

In Rotablock, colored gems are routinely placed in the row above the grid. These gems, if possible will drop into the grid after a set amount of time. As they are dropped they fall until they sit above another gem or are at the bottom of the grid. If the row above the grid is filled with gems then the game is over.<\/p>\n

\"\"<\/p>\n

I wanted to create a puzzle game and I feel that puzzle games work well when the gameplay is very clear and discernible. This resulted in my idea to use a grid as the discrete columns and rows make the gameplay clear. If you have a grid like structure then what populates the grid will likely either sit inside a row or a column(like Chess) or sit on the intersection of two points(like Go). I hadn’t played Go and so felt more comfortable with having the rows and columns to be populated. Choosing to have different colored gems was a rather arbitrary decision. It does however make the game more readable as you can use contrasting colors. My choice to make the gems fall was chosen because the idea of Rotablock came from me thinking about puzzle games on the iPhone. I thought that the rotating mechanic, described later, and the falling would work well together.<\/p>\n

This brings us to our first mechanic. Selecting and removing gems. The system described above needs a mechanic that removes the gems from the grid. As I was thinking along lines of an iPhone game, I thought that it would be a great idea to run your finger over groups of similarly colored, adjacent gems to select them. Then once you release your finger the group would be removed. This along with the choice of colored gems makes pattern matching a focus of the gameplay. I decided that letting the player choose the formation of the group would add a little bit of complexity to the game. The number of gems required to make a removable group is something that didn’t take long to figure out. After playing around with the game it makes sense that three gems is the perfect size for the minimum group. If you set it two gems then you are clicking and removing groups too frequently as groups of two similarly colored gems occurs frequently. If you set it to four then the groups rarely occur.<\/p>\n

If you play the game with this base mechanic then you soon start to end up with ‘dead gems’. Gems that can’t be reached or removed because the formation of the gems that fall don’t allow it. These dead gems can also lead to a deadlock in which case the player must lose. There are two ways handle dead gems from a design point of view. You can either let the player deal with them by adding a new mechanic to their repertoire or you can let the game deal with it. The latter could be implemented by having the board clear after a certain period of time or every now and then the bottom row could be removed. However I think adding a new mechanic is preferred here as it is a great opportunity to up the complexity of play.<\/p>\n

There are two mechanics I added here. The first is being able to rotate the grid, another idea that came about after thinking about the iPhone. Rotating the grid can drastically change the landscape of the gems as they will continue to fall to the bottom of the screen. Rotation also can lead to higher level play by allowing the player to break a gems fall by rotating the grid at the right time. The picture below demonstrates this. By rotating the grid right you can create a group of five light blue gems.<\/p>\n

\"\"<\/p>\n

Rotation doesn’t allow the player to completely avoid dead gems or deadlocks. For example one gem may slide closer to a group on a rotation while another gem that made up part of the group slides away. To supplement this I added the ability to slide gems either left or right one position. This gives the player more control in avoiding deadlocks. The downside to sliding however is that it takes a bit of time. So it is not something that can’t be relied upon all of the time.<\/p>\n

Complexity of Play<\/h2>\n

Rotablock was designed to be a simple puzzle game. I wanted it to have mechanics that supported both low and high level play. My current thoughts are that a player who is playing at a low level follows the following routine as they play. <\/p>\n