One of the goals for the Rotablock milestone 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.

Mechanics

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.

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.

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.

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.

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.

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.

Complexity of Play

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.

• Search for existing groups, select and remove them.
• Once all groups have been exhausted try to look for groups of two in which case using sliding can be quickly performed to make a group of three.
• Once all of these opportunities are exhausted, rotate one direction and start searching again.

I think that high level players would follow a more detailed routine.

• Observe the current gem that is falling.
  • Will this gem interfere with a group that could be potentially building? If so can we slide a gem to prevent this? Or can we rotate the grid to prevent it?
  • Could this gem form a group by quickly rotating the grid in one direction, selecting the newly formed group and switching back?
• Search for existing groups. Remove groups that don’t break existing groups or remove groups that lead to more groups being formed.
• Once all groups have been exhausted try to look for areas of the grid that could benefit from sliding.
• Once all of these opportunities are exhausted, look for a rotation that will lead to more groups/potential groups

The differences between the types of play is how the high level players work towards making the state of the grid more conductive to combinations. While the low level players simply look for the obvious matches. There is a limit to how far players can look ahead at future combinations of groups when removing a group. If you’ve played Puzzle Quest or Bejewelled then you’ll know what I mean.

Ramping up Difficulty

As most games do I want Rotablock to become harder the longer you play it. There are limited means that are avliable to scale the difficulty, these are:

• Number of Gem Colors
• The speed at which gems drop, spawn and fall
• The distribution that gems fall in

The number of color types varies the gameplay rather drastically. The more color types you have the smaller the groups tend to be and more dead gems tend to exists. More dead gems results in players having to play at higher levels of skill. Fewer gems result in longer chains but more time being spent trying to select the optimal series of chains. The picture below highlights my point. The grid on the left has four gem color types while the grid on the right has eight.

Changing the speeds that gems drop, spawn and fall causes more pressure on the player to respond quickly. When responding quickly the player is more likely to make a less than optimal decision resulting in a game over sooner or more just more dead gems. Changing the fall speed makes high level rotation tricks harder to time correctly.

The distributions that gems fall affect how groups can occur. The order in which they fall can be changed to make groups harder or easier to obtain. At the moment I’m in the process of nutting out what patterns of distribution can be used to elicit certain mechanics. I’m hoping to implement strategies that will combine all of these ideas.

Thanks for stopping by. Hopefully I’ve given you a good idea about what this game is now about.

After some thought I’ve decided to start working on Rotablock, a game which I prototyped up before but never finished. I could only think of one thing which I wanted to add to my existing code base which was state transition animations. I’ll now add these to the first milestone of Rotablock.

Rotablock Milestone 1

Start on February 6th
Finished on February 18th

• Stage Transitions

  Allow for a transition period on entering and leaving a game state.

• Mock Up Game State Graphics

  Create screens that show how gameplay will work along with title and option screens.

• Port Basic Mechanics to new Framework

  Take the existing code written for Rotablock and move it into the existing code base.

• Create Sound Effects

  Create the sound effects for the game.

• Realise the gameplay mechanics

  Experiment with fundamental mechanics in order to nut out modes, balancing required, etc. in order to highlight interesting parts of game system.

• Think up of a more appropriate name

  Rotablock? Really?

I’ll keep you updated.

It’s been one busy month and I’ve been making lots of progress on my code base. This milestone was on a tighter schedule compared to the last one but I think I’ve managed to get a decent amount of work done. Here is my progress for this milestone. You can read my previous post which contains more details about each item in the milestone.

Milestone Progress

• Tweening for Stage Objects – Completed!

• Option State – Completed!

• XML/YAML Support – Completed!

• Stage Object Pruning – Completed!

• Particle effects – Completed!

• CMake Support for creating functional XCode and VC++ projects – Partially Completed!

• Refactor all Resource Managers – Completed!

I started this milestone by refactoring all of my resource managers. They are now all based upon a central resource manager that maintains reference counts to resources. This system is much simpler than the approach I was using before which maintained resources in a stack. I also added the ability to reload all resources which allowed me to properly handle cases where the screen size would change and OpenGL would need to reload all loaded textures.

After refactoring all of the resource managers I then moved onto tweening and stage object pruning. Stage object pruning was simple to implement. I just created an object represented the stage, much like the stage used in Flash and then didn’t draw items when they were offstage and created events as objects moved on and off of the stage. Tweening was relatively straightforward as well. The results look fantastic as sprites rotate around any give point, change transparency and more while still having their axis aligned bounding boxes in tact. Animation definitely makes your work feel more alive.

XML library research came next. I decided to use RapidXML because of its speed. I found the interface for RapidXML to not be as friendly as I would have liked. You have to allocate memory for all of the information you pass into it. I also decided to stop supporting yaml-cpp because I could not load a file and modify it without first reading the whole file in and then writing it all out again. After writing an XML Parser object I wrote code and tests for editing the Game Configuration XML file and the key mapping XML file. This resulted in the OptionState being a simple plug and play exercise.

In the last few days I finished off creating the particle system. I decided to use an architecture that was similar to that describe in this article. However I heavily use typedef in order to try and keep the type definitions readable. The end result was fantastic, like animation, particle systems look amazing for such little work. I didn’t flesh out the different effects on the particle system. Mostly because I currently have no practical use for them at the moment.

The one thing that I didn’t complete was writing my CMake files to support Visual Studio and XCode. I got very close to building in Windows except I ran into a few weird linking errors. There are changes to support XCode and Visual Studio but they just haven’t been tested. In order to test stuff out on Windows I had to install and configure pkg-config. Over the last month I reinstalled OSX but haven’t set up all of my libraries. Namely due to this bug.

Here are some screens of my progress over the last month.

I’m considering making the next milestone shorter in order to start writing Rotablock. Most of the code now is becoming too specialised so I feel that it’s about time to get cracking on a game. I’ll post details about the next milestone soon.

Over time every developer forms a long list of projects they’ve started but never finished. Throughout the last two years I’ve accumulated several projects like this and today Today I’ve decided to dig out some of them. Along with each prototype I’ve included some details about why it was never finished.

Paint

Those of you who followed my previous blog, Nexfinity, would have read some details about this prototype. In Paint, you control a sponge ball who can run over buckets of red, green or blue paint. When the sponge ball rolls over a bucket of paint he leaves a trail behind him. On the left hand side of the screen are colored(red, green or blue) characters who will follow paths that match their color. Your goal is to get as many characters from one side of the screen to the other.

Paint as a prototype was a success. It proved to verify the problems with initial design that I put forth and so it was a successful prototype. The problems where:

• The location of the buckets lead to a hotspot of movement in one corner of the map. Going back to this one position felt tedious and frustrating.
• Trying to avoid running over your existing path proved too easy and predictable when all characters move in the one direction.

Some possible solutions for these problems are:

• Make the players color selectable on the fly, put the buckets in a more accessible area such as the center of the map or make the position of the buckets more dynamic.
• Make the enemies come from all different sides of the map.

Asteriods

Asteriods is a game that I made for a University Assignment on Computer Graphics. It is just what it sounds like, a take off of the famous Asteriods Arcade Game. My version of the game is a bit more disrespectful to the player than the arcade version. New rocks can spawn without notice and very close to the player. The collision of the rocks is approximated to only circles and these circles are bigger than the rocks. When this game was created we had only learnt the very basics of OpenGL and so there are no textures or spiffy graphical effects.

Rotablock

Rotablock is another game that I discussed on Nexfinity.net. I simply created it to verify new code that I’d written which supported both OpenGL and SDL. Rotablock is a simple matching gem game in which you can rotate the grid that the gems reside in. This causes the gems to shift based upon gravity. You can also slide gems left and right. This prototype was reasonably successful. As discussed in my last post, I plan to release a proper version of Rotablock once I’ve added more code to my foundation code.

Construction Platformer

Construction Platformer was my first foray into Love2D, a dinky, little Lua engine. In this prototype you played a single screen platforming game where you could add and remove blocks. Your goal was simply to get to the end of the level. Ideas from this prototype were used in Platform Chunk Clump.

Sound Maze

Sound Maze was my second prototype with Love2D. My intention with Sound Maze was to try to simulate what it would be like to be blind. The game is essentially a maze game in which you don’t see the maze, you hear it. You play from a birds eye perspective. When you press the space bar you release a sound wave that sweeps around the player. The pitch was intended to change based upon how close the player is to a wall. Unfortunately I didn’t have the control over the sound that I wanted in Love2D so only the volume changed.

A few months after developing the prototype I found out that similar games already exists except in first person. This games converts the screen to audio, you can get a feel for how this technology works by viewing this video. As you can tell the conversion from images to audio sound displeasing on the ears. Trying to train someone to form a spatial model from such sounds is a problem that is just too hard to complete in the short amount of time a player would be willing to spend on a game.

2D Metal Gear Like

This is a prototype that I didn’t finish. It involved creating an engine to recreate the Metal Gear Solid games in 2D. I feel that there is a wealth of mechanics that could be created from the Metal Gear games. The Merry Gear Solid games are wonderful examples of using this template well. I stopped working on this prototype when I realised that the amount of art assets required for such a game were too numerous and I simply don’t have the skills to create them at the level that I would like. My development of this prototype was interrupted by the first Adelaide University Game Development Club Game Jam in which I created Everything will Eventually Come to an End. This game has far more potential in my mind.

Muso

Muso was a quick little prototype that I created in an afternoon with Love2D. Muso is a one button game in which you are a box that oscillates from north to south. You must avoid other boxes that move from the right to the left hand side of the screen. You use the space bar to control how fast these other boxes move. This prototype was hardly fleshed out. I however really like the feel of this game and think that there would be potential in reviewing it sometime.

I hope you enjoyed this sample of my unfinished prototypes.

Along with this blog I was intending on having a separate development blog that would detail my progress on the games I am developing. However I decided to keep both blogs in the same place, right here. In the development blog I would post up milestones for my projects. The milestones would take roughly a month of development, each component of the milestone would have to be completed or be very close to being completed.

Currently I’m not specifically working on any game in particular. Instead I’m working on bolstering up my code base in order to make development easier over the next year. My intention is to release a game that I started ages ago, Rotablock, once the code base is up to a much higher standard. I’m hoping that after two milestones from now which will be mid March, I’ll be ready to work on Rotablock. From there on I plan to work on an expansion to my first game jam game, Everything Shall Come to an End.

December Milestone

Started on December 10th
Finished on January 12th

• Migrate Project to online version control system

  The first thing that I wanted to do was to move my code to a hosted online repository.

• General Tidying up of the Code Base

  I’ve been using this code base for all of the Game Development Club Game Jams and it was becoming very messy so I wanted to clean it up.

• Drawing Classes for Convex Polygons

  In order to make drawing different shapes easier I wanted to create classes that would handle this for me and generate display lists automatically.

• Game Properties yaml file

  Common game settings such as resolution should be stored outside of the game binary. Since YAML is clean and easy to read, I wanted store these properties in YAML.

• GUI System

  Create a GUI System that consists of buttons, drop down lists, radio button groups, check boxes, text fields and sliders. Items would need to skinnable.

• Improved Sprite Classes

  The existing Sprite classes should extend upon the drawing classes for rectangles. There should be sprite classes for a standard Sprite, Multiframe/state Sprite, Animated Sprite, Sprite with sliding texture coordinates and a tiled sprite.

• Stage Objects classes

  Create a Stage Objects class to simplify common operations such as rotation, translation and generating bounding boxes.

• Math Vertex and Matrix Classes

  Create Classes for Vectors of 2, 3 and 4 dimensions and Matrices of 2×2 and 3×3.

• Testing Framework

  Setup a testing framework using CMake

Milestone Progress

• Migrate Project to online version control system – Completed!

• General Tidying up of the Code Base – Mostly Completed!

• Drawing Classes for Convex Polygons – Completed!

• Game Properties yaml file – Completed!

• GUI System – Completed!

• Improved Sprite Classes – Completed!

• Stage Objects classes – Completed!

• Math Vertex and Matrix Classes – Completed!

• Testing Framework – Completed!

As you can see, most of the milestones were completed. I’m happy with the progress I’ve made over the last month. The code base is much tidier than it was before but in a few errors it needs to be touched up. I’ve moved all of my code to a private repository on BitBucket which I’m finding along with Mercurial to be excellent replacements for subversion and my local repository. I unified all of the building scripts into one CMake file. I’m wanting to update the resource managers in the future to allow for reference counts on items so that resources can be shared between game states.

When porting Platform Chunk Clump I noticed that loading detailed YAML files was very slow on Windows. In the future I’m wanting to switch out using yaml-cpp to something much faster.

I’ve attached several screen shots to show my progress.

January Milestone

Started on January 10th
Expected completion February 5th

• Tweening for Stage Objects

  Allow frame rate independent tweens to be placed on Stage Objects

• Option State

  Setup an Option Game State that can be used to set resolution, full screen, sound and music volume, key bindings and antialiasing

• XML/YAML Support

  Modify existing parsers with adapter pattern to support either YAML or XML. Research XML libraries

• Stage Object Pruning

  Create a system that checks stage objects to see if they are offscreen(via bounding box) if so then create events to handle this

• Particle effects

  Create a system that allows for the easy creation of particle effects

• CMake Support for creating functional XCode and VC++ projects

  Would be very handy.

• Refactor all Resource Managers

  Make use of managers with resource counts

You’ll hear more development progress in a month. Hopefully sooner.

On Friday I released all of the games that I made for the Adelaide University Game Development Club Game Jams for Mac(Intel), Windows and Linux. I also updated the source code slightly in order to make the first game jam game run faster and to make it easier for me to compile my code on the different platforms.

Previously I only released the source code for Mac. I use Vim and Macports on Mac so this was hardly optimal for the average Mac developer.

The source for all of the games now comes with a CMake file, XCode Project File and Visual Studio Solution file. The XCode and Visual Studio Projects were created by hand instead of by CMake. I need to refine my CMake skills before I can get everything working perfectly and this gave me the opportunity to suss other the two Integrated Developer Environments(IDEs). Don’t worry I’m sticking with Vim for sure!

For Mac developers, I didn’t convert some of the libraries used into Frameworks. Instead I included the dynamic libraries into the App bundle. These dynamic libraries are taken from Macports. I couldn’t get XCode to update the references to the dynamic libraries inside my executable and other dynamic libraries. So instead I updated the references using a small python script that used otool and install_name_tool. I may publish it sometime.

This marks the completion of my portfolio website and game ludography. The two sites do overlap a little. The portfolio site is to accompany my resume and as I think it’s important to highlight a variety of the different work that I’ve done. The ludography exists in order to provide a nicer interface to my games.

Here are all of the games I made over the last year. Enjoy.

Everything Shall Come to an End

Leave your Path

Biggle

Platform Chunk Clump

I just thought that I’d stop by and post a bit about something I’ve been working on in the background. Over the last few months I’ve been slowly working away at integrating SDL and OpenGL together in a basic game engine while on my train trips to and from University. After integrating the two together I put together a very simple puzzle game which I’ve called Rotablock.

The aim of the game is to find sequences of horizontally and/or vertically aligned gems. Once you have found these gems you can select the sequence and they shall be removed from the grid. New gems fall from the top of the grid and slide down to the bottom. You can rotate the grid 90 degrees left or right and all of the gems will move accordingly. You can also slide gems across.

This game is just a technical demo for the SDL and OpenGL integration and as you may have guessed from the actions performed in the game, I plan to port this over to iPhone/iPod touch at a later date. Hopefully I’ll have the code all ready to post up in coming month and a bit. I plan on adding OpenAL, Boost and FTGL support too.

I thought that it would be a great time to post some progress on the Paint Prototype that I have been working on. Currently the prototype is not at a stage in which I can test out the gameplay mechanics but it is getting closer to that point. At the moment I can see glimmers of the soul that this game could have which is very pleasing. I’m greatly looking forward to getting more progress down to see if this concept can become a reality and if this idea can truly elicit feelings from the player.

For now enjoy some of these screenshots. They don’t help in explaining what the game is about but hopefully you can take away your own interpretation of them.

It has been a while since I have finished programming Draughts and I think that it is time to move onto a new project. About a week ago from today I met up with a few friends of mine whom share a common interest in creating games. Together we discussed potential game projects and ideas. As I mentioned on Twitter, creating interesting game ideas is hard.

By the end of the night however we all agreed upon several ideas that we wanted our game to incorporate. The feeling of true consequence in a game and the sparing use of color and sound to signify importance of things in the game world. Over the weekend we all individually thought up potential game concepts that were based around these ideas. One thing that became quickly apparent to me while brainstorming is that having real consequence, consequences that makes the player feels guilty or sad about is hard. After this realisation I removed this idea from my mind and focused on an emphasis on color and sound. After some more brainstorming I came up with a concept that I thought was interesting but not entirely a good representation of what we had discussed. I discussed this with the group who also shared this enthusiasm for my idea. Another idea had fluctuated to the surface that was also interesting. The aim of my next project is to develop a prototype for the idea that I had designed. I want to keep the details of this idea behind closed doors for now because it is most definitely not concrete.

Currently I am intending on creating the prototype in C++ using my old pal SDL. Before finish I will tease a clue, it involves paint and a lot of different colors. I will keep you posted.