Match Three Update

So I dusted off my MatchThree game the other day, after roughly 8 months of not looking at it. I had left it in a pretty wonky state. The last thing I did was to turn it into a puzzle/RPG hybrid a fantasy twist, where matching gems would harm the other player.

However I quickly realised that what I had programmed just wasn’t fun. In part that was because my game concept wasn’t very well fleshed out. However I also found that it was difficult to iterate on, and various bugs and glitches made the core game play mechanic not very enjoyable.

I think part of the fun of a game like Candy Crush is the really solid underlying game engine, which just feels satisfying when you match gems. Part of that may be down to the art and graphics, but obviously you need solid game mechanics underpinning everything. With my game prototype it felt like I was building on an unstable foundation. So as a first step when picking this back up, I ripped out all that code and went back to basics!

Refactoring

My focus was on making the matching system work more reliably and smoothly. After reading through the code (that I wrote), I was amazed how confusing and hard it was to follow. After several attempts to fix some minor bugs, I decided a more drastic approach was needed.

Having worked on Rails now for a couple of years, I was curious whether I could apply a more rigorous architectural style to the code (over the jumbled mix of objects that I had). Doing some research, I found an excellent resource on technical Game Design by Robert Nystrom. However none seemed to fit my particular problem. A particular issue that interested me was the separation of game state and graphical display. Apparently that’s not as straightforward in games, since the loop is much tighter as compared to web apps which utilise the MVC pattern to separate out business logic, application logic and rendering of the views.

I am currently reading about Domain Driven Design, which puts emphasis on having a clear domain model with strict divisions between business logic and other application logic. It made me think about the classes that I currently had, and I realised that some of my classes were just doing too much. For example my Board class was a giant object that handled all the complexity of gem matching and refilling the board. So I started splitting obvious related bits of code into separate classes (for example a MatchingShapeFinder class for determining whether there was any match on the board, as well as GemManipulator, Logger and MatchedGemCounter classes). Following this strategy made it much easier to reveal where the problems were in the code, and to focus responsibility on individual objects, rather than lumping it all in class which became really hard to parse. I’m still not 100% happy with the class that I’ve got, but abstract concepts like a GemManipulator are harder to pin down than concrete concepts such as Gem, Board, etc. Check out the code here if you're interested in this sort of stuff...

What even is fun and what is next?

I’m fairly happy with the game engine in its current state now, in that it feels more stable and better structured. The next phase will now probably be to turn it into an actual game. From my brief experiment with the puzzle/RPG hybrid it strikes me that making something that’s actually fun to play might be quite hard! I’ll probably have to take another good look at the current addictive puzzle games, such as CandyCrush and Puzzle Quest. I suspect part of it is the sense of a challenge as well as progression, which might be fun things to implement.

Finally, here’s a link to the current game.