Rotablock has come to the point where I’m happy to try and finish the game by the end of this next milestone. This leaves lots to do and as always I’m sure are there are going to be lots of small touches to put into place. University starts back up the week after next so I’m unsure as to if I’ll get the time to finish everything but we’ll see how I go.

Rotablock Milestone 2

Start on February 20th
Finished on March 13th

• Title Screen and Options Menu

  Currently both the title screen and options menu are functional but they need some graphical sprucing up.

• Gameplay Demo

  Improve the gameplay recording system to include mouse clicks and to run gameplay recordings after waiting at the title screen. Playback of gameplay recordings will be followed with a list of the highscores.

• Find some background music

  Find some appropriate background music.

• In game tutorial

  Screen tips and suggestions will be placed in game to teach the player how to play.

• Dynamic Gem Dropping behaviour

  The game should progress from being easy to becoming much harder. This difficulty needs to ramp up slowly yet still allow the player to get a good feel for how the game plays. The patterns in which the gems drop need to reflect this.

• Background Graphics

  The in game backgrounds should be more interesting and should contrast better with the grid.

Hopefully you’ll have a brand new game to play by me in March.

Over the last 12 days I’ve been working on Rotablock. It is much more exciting working on a game instead of just working on utility code. However it is also more time consuming as I find that design takes more time than you intially expect, even for a simple game like this one. I also found a few bugs in the code that I’ve been working on over the last few months. A few things cropped up this week that took away a bit of my time. One of which being asked to help out with the Indie Games Room, the other I’ll talk about later next week.

Milestone Progress

• Stage Transitions – Completed!

• Mock Up Game State Graphics – Partially Completed!

• Port Basic Mechanics to new Framework – Completed!

• Create Sound Effects – Completed!

• Realise the gameplay mechanics – Completed!

• Think up of a more appropriate name – Not Completed!

Additional Items Completed

• Graphics Code for handling HSL Color

• Setup high score class

• Particle Effects

The first thing that I worked on was porting the basic mechanics across. I did this first because I usually like to have several days to let them sit in my head while I figure if they are appropriate, how they need to be tweaked and how the levels/stages can show off the mechanics and dynamics. The only mechanic I changed from the initial prototype was to make gems slide across only one position when the player slides them. Beforehand they continued to slide until they fell or reached a wall. I did this because I wanted the slide mechanic to allow for more precise handling of gems as the rotation mechanic doesn’t give you such precision. Earlier in the week I wrote up some details about the fleshed out design.

I then moved onto doing the graphics. There were several problems here as I was unsure of how to approach the backgrounds used in the game as a result I don’t have any mockups to show. I did however do the graphics for the gems and the grid that the gems lie in. I wanted the backgrounds to not be distracting like some games, eg Lumines 2(2:14 onwards) yet to still be like a visualisation. In the end I couldn’t come to a conclusion about what to put in the background. One thing I did want was for the background to fade from one bright color into another. I ended up writing some code for handling RGB to HSL conversions as this made the process much easier. Around this time I also experimented with creating new particle effects once gems where removed. The final result is fantastic, it really fits in well with the look and feel of the game.

In the last few days I created a high score board that is just saved out to XML. I also created a basic title and option screen. sfxr also was a massive help as always when it came to creating sound effects. I’m pretty confident that I’ll use the existing sound effects with maybe only minimal changes. State transitions was my final task. I saved this for last as I wasn’t sure on the best way to implement it. In the end I feel pretty happy about how it came together. Yesterday I had a bit of time to play around with the build on my Mac. I managed to get everything in the build working correctly except I still need to add in code that will copy all the dynamic libraries into the app bundle and change the library reference paths.

I couldn’t think of a new name for the project. Hopefully over the next milestone I can think of something.

I’ll post up details soon of the next milestone.

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.