And now for something completely different. Download and play here.
Arrow keys to try a slide, space bar to confirm it. Imagine it’s on a phone screen; pressing right swipes right, and so on.
Some bad news: this game is going to be incredibly colour-blind unfriendly. I wanted to have letters on the cards to give you a fighting chance but I ran out of time. I’m so sorry.
Anyway, for clarity, because I didn’t have any room in the game/time to fit it in, here is a little breakdown of what you want to be matching:
| Description | Example Combination | Example Result | Points |
| Two primary colours form a secondary colour |   |  | 5 |
 |  | 5 | |
| |  | 5 | |
| Three-of-a-kind for primary colours collapse the cards into one | | | 15 |
| All three primary colours form a white card, which disappears from the board | |  | 20 |
| Three-of-a-kind for secondary colours collapse the cards into one | | | 25 |
| All three secondary colours form a white card, which disappears from the board | | | 50 |
Development
I put the game on the backburner this week and didn’t start coding til Saturday morning. I’d had the idea for the concept on Thursday or Friday, but didn’t have faith in the idea – I feared the gameplay would be too easy. With only a couple of days remaining, I chose to pursue this one over the other idea I was considering, a platformer, as I thought this one was more doable in the time I had left.
Regardless, this was a tough game to make. I’ve never really made anything resembling a puzzle game like this before, so I was a bit out of my comfort zone. I had to rethink some of the structure I use in each Game a Week game, as this required a loop for each slide within the regular game loop (of splash screen, start game, end game, reset with new splash screen, start game, end game, reset, etc).
Ouroboros
I could tell this just while I was planning the development of the game out at the start, but compared to my other games this was kind of an ouroboros of development; where with other games I could develop each system in turn, test it out and then move onto the next, here the entire game just seemed to rely on itself. I started by programming in an enum for the colours and how they relate to each other, which combination would produce what. I then programmed the background grid and set up the code-representation of the grid, which required a Card class which also held its own position in the grid as well as its current colour, but then I needed to program in the slide movement but for this I needed to know whether or not the card could even slide in the given direction, so then I put in a temporary function to constrain it to the grid and got the sliding worked out and then worked on a function for merging cards when they occupy the same space in the grid (ie turning red and green into one yellow card) and then I decided to revisit the constraining function and complete it, specifying the conditions under which a card could slide given its neighbours, but for this I needed another class to represent slide directions…
The point of that horrendously stressful sentence is that I couldn’t actually test the game until about 11pm on Sunday, when all the core systems had been put into place. Wrapping my head around the grid system, how best to represent and use it for determining the limits to where a card could move, took considerable effort, and I’m certain there must be a better way to implement it, but as I was under the time pressure I just went with my gut. I had a 2D array of Cards, where [0,0] was the top left corner and [3,3] was the bottom right. If I were to redo this the first thing I’d change is make [0,0] the bottom left and [3,3] the top right, to match Unity’s coordinate system, which was a stupid oversight but, as I said, born purely out of the “let’s just get this done” mentality I had with the deadline looming.
Finishing Up
It was a stressful development. I couldn’t really play the game til 11pm on Sunday, and even then I didn’t really have time to test it because, although I had the core features in, there was yet still more to do. At that point I had the cards just moving instantly to their new positions during the half and complete slides, so I implemented the tweening as I thought this would help make the working of the game much clearer, and after seeing the result I’m glad I did it. My implementation was rushed though and you can make cards work their way off screen if you tap the controls, but that’s again just a symptom of the time limit, it’d be a five minute fix, but by then I didn’t have five minutes!
Potentially foolishly, the last thing I implemented was the game loop. I had the splash screens and starting a new game functionality finished at pretty much midnight on the dot. Fortunately I’ve done enough of these now that I start each game by writing Reset and StartGame functions for various bits and pieces, so all I really had to do was tie them together and write the splash screen texts. This game has relatively few of those bits and pieces as well, since I have a CardGrid class that sorts out all the cards, and the Game class is in charge of the game state and scoring, and that’s it. Literally everything else was invested in the game systems themselves.
Card Colours
As an aside, I’m very pleased with the little preview you get during the half-slide phase where you can see the colours mixing between cards. If you want to know how I did it, I basically got the effect for free, as I use Unity’s lighting system to make the colours on the cards. The white background rectangles and the card foregrounds are sprites, whose default material is not affected by lighting. The colour of the card is simply a spotlight shining against a quad, the quad nestled between the card foreground and the grid background. You can see this in action below:
As the quad is affected by the lighting, but nothing else is, it remains the only area that is lit. I had to up the intensity of the light from its default of 1 to 5 in order to get the sharp block of colour I wanted. I did have a mild heart attack when I tested the concept out and found Unity would only let me have two light sources, but the fix for this is easy: in Project Settings -> Quality, just up the Pixel Light Count to the number you need. My other worry was that having so many light sources might not work in a browser, but the game works fine on my laptop, I’m not doing anything particularly stressful with the lights, so I think I got away with it. Don’t know how it would perform on mobile platforms though.
Visual Studio Tools for Unity
A couple of weeks ago Microsoft released Visual Studio Tools for Unity 1.9, an upgrade from the previous UnityVS release that is available for Unity free users using Visual Studio Pro or above. I thought I’d try it out for this game (as until now I’ve been using MonoDevelop) and the experience, overall, was excellent. I got it integrated very quickly and easily by following this guide and the experience is exactly how you’d imagine, just writing code in VS.
MonoDevelop is, I find, a passable IDE, but it seems to mess itself up an awful lot. It fails to read in projects, makes itself appear above all other windows (including its own), crashes, crashes Unity, auto-formats code in a way I dislike and doesn’t seem to listen to the options I set it up with… meanwhile, Visual Studio is Visual Studio. My only complaint is that if I hadn’t clicked on the Unity window in a while (to allow it to reimport all the updated scripts) then fairly regularly trying to attach VS to the editor to debug would cause Unity to hang. I could close it using Task Manager, reopen it and reattach just fine, but obviously this is a pretty annoying defect. Other than this, no complaints.
So, to conclude, development of this one was rushed and stressful, but I finished the game pretty much how I envisioned.
Design
Threes
Now that I’ve finished the game, I’ve actually had time to play it and can critique it. Anyone who’s anyone will be able to tell straight away that this game is a huge rip off of Threes. You can play a free version here and instantly see the similarity, but I recommend buying the app store version as the game is a perfect candidate to be played on the toilet train. You may also liken this game to 2048, which is a clone of Threes. A great breakdown of that particular story can be found here.
Concept
Anyway, my concept was to do a combination of this great new puzzle game concept, Threes, and a pretty classic puzzle concept, a match-three game like Bejewelled. There are a bunch of representations of this that you could choose to go with, such as playing cards (imagine matching poker hands) or just plain old numbers just like Threes, but in the end I went with colours. I justified my choice as such: it was the idea I had originally, and in my head the concept looked pretty good. Secondly, I knew I could take advantage of Unity’s lights and get the nice colour-mixing effect for free. Finally, it would constrain the items to be combined to six, the primary and secondary colours, which I thought would be a good limit for a Game a Week (as opposed to programming in all the poker hands and their precedence, or limitless number systems).
My reasoning was that I could extend the basic Threes formula by having a way to remove cards after a certain point, in this case by getting a white card. Playing the game, though, I’m not sure I got this or the score amounts quite right. The RGB/CMY combinations are rewarded twofold, both with a big amount of points and by clearing the grid. I think as a prototype this shows potential, but as a game itself it just falls a little on the flimsy side.
Exploits
Trying to game the system seems to get the player pretty far as well. In the Threes blog linked above, they mention that in either 2048 or Threes you can employ a tactic of continually pressing up and right and ending up getting pretty far, throwing in the occasional down whenever you’re unable to swipe up or right that turn. My game suffers the same problem. In fact, it suffers an even worse one; depending on your luck, you can get a pretty good head start just by continually going in one direction. Since there are so many combinations a primary colour can be a part of (seven total) it’s fairly likely that when a new one pops in from the side, it’ll be able to merge with something straight away. I am not a big fan of this kind of robotic gameplay at all, so this is unfortunate.
Progression
I’d argue as well that the lack of build up caused by removing the white cards actually makes the gameplay less compelling. In Threes or 2048, as you get bigger and bigger numbers, the amount of space on the board you have to work with becomes gradually less and less, in a very clearly defined way. Moreover, you’re working towards a distinct goal, eventually working your big numbers up to wherever your biggest number is, combining it and starting the process again. With my game, there’s no such constant goal, and no such natural difficulty curve. You just are continually removing and replacing these colours. I think if I experimented with which matches were legal, or different effects from certain matches, it would be possible to pivot this game into something more legitimately fun, challenging, stimulating and deliberate.
For now, though, it does seem that the game does eventually comes to a natural end. You can’t plan ahead for individual turns, as there’s no indicator of what the next introduced colour will be (sorry, ran out of time), but whenever I play, I do eventually run out of space as badly placed secondary colours take over the grid. My high score is 13520, beat that.
Conclusion
In conclusion, I’m happy with this week’s game despite its flaws. It’s the first puzzle game I’ve ever made and I think I added an interesting twist onto the core Threes gameplay that I took heavy inspiration from. I was curious as to whether the gameplay would even work or not, and I think it does, to an extent. The creators of Threes had years to tweak and perfect their gameplay, though, and I only had two days, so I’m not going to be too hard on myself. I’m excited to do more of these kinds of games in the future, too, as they really open themselves up for discussion concerning their mechanics and aspects that can be tweaked or changed.
Definitely a lot learned this week, both from a development and a design point of view.
Gallery
