We are firm believers in adding depth to games: what’s the point of a puzzle that solves itself in the time it takes to scarf down a handful of M&Ms? We did not want to go down the route of adding depth by allowing the mixing of colors, since we already were depending a lot on colors (and, as mentioned before, we were still to address the problem of how to make the game more color-blind-friendly).
We decided to take on the task of coming up with ‘Special Blocks’ that would make the game play more intricate. Already we had a few ideas of what these special blocks would be like. The first one we thought to implement was the simplest as well. It’s the Dead Block. The name should say it all, but just in case it doesn’t, a Dead Block is quite simply – a Dead Block. This means that it is an unusable cell in the game grid, since none of the colored paths could be dragged through it. The introduction of this particular feature meant a slight re-adjustment of the concept, since we now had to drop the idea that the whole grid, with every single block in it, would be filled with color. Obviously, with the Dead Block in it, the grid would have a few grey areas.
Our self-appointed task got slightly more complicated when we decided to introduce the Community Block. This was like the Donald Trump of blocks – rich, because it had immense potential for complex game play and obnoxious because it could completely screw up whatever solution the players might think they have. And like the Trump, it was also universally hated. Basically, if a colored path was dragged through this block, it could either add to the number of remaining blocks in that color, or it could subtract from it (depending on what type of Community Block it was, +/-). This was, quite literally, our main stumbling block, because it was difficult to visualize a solution that would use it and it was difficult to explain.
Let’s look at it a bit more closely: the Community Block would add or reduce a block to the number that was originally depicted. The problem was that you had to extend your path by one more block before you could actually get to this special block, so it would add one less than it showed, to your existing total. For example, if your Head Block was currently showing 4 remaining blocks in that particular color, but you had a +3 block ahead, you would think if you took the 3 your number would become 7. But you would end up using one of those remaining blocks to enter the +3 and so you would end up with a total of 6. Similarly, if there was a -1 block ahead and your head block showed 1, you could not enter the special block, because while getting in, you would have used up that one remaining block left for you and you would end up with a zero.
OK, this has been difficult to explain even here, but perhaps a shot at this particular feature would make it clearer. In any case, we were relying on the natural braininess of our users to understand the concept, without us having to beat it into their heads.
The Sink Block was a piece of cake after this. It could have been initially confusing, but once understood by the user, would actually help a lot in finding the solution. The essential feature of the Sink Block was that any color could enter it, but once there, the path would no longer be able to exit. This means that the path would actually end with the Sink Block. Once the users understood this important fact, they could see that only certain paths would end here and would need to figure out exactly which paths those would be.
We then implemented another one of our ‘stumbling blocks’, the Wrap Block. Because it could radically raise the difficulty level, we restricted the use of this particular block to the grid ends. This made it less confusing than actually having portals on the game grid. Conveying the matching pair of portals would have been another hassle altogether. So we simply treated the Wrap Block as a way to “wrap around” the grid. One slight hitch that we faced over here was that the Wrap Block took the mouse control away to another block. It meant that users would have to stop and resume dragging from all the way around the grid.
We had initially planned on including something we called the Slide Block. This was supposed to be a block on which one would simply slide to the end of the grid or to a dead block. It sounded like a good idea, but the implementation nearly gave us a nervous breakdown. One of the troubles with this block was that it would immediately take away control from the player. So far, only the Wrap Block did that, and in that particular case, we felt it had been valid. With the Slide Block, we were worried. The block would make it extremely difficult to navigate a path as it would automatically slide it for the user. Another worrying factor was that combined with the Path Cutting and the Wrap Block, the Slide Block would prove too much. What if the player used the Slide Block and unintentionally cut his already completed paths? And yet another problem was death a la Snake where players would slide into a Wrap Block and ‘eat’ the tail of their own path. This was all becoming too un-intuitive to even begin planning for the Level Editor. We finally decided to eliminate this particular block, although we did retain some of its features in the Direction Block.
Now, the Direction Block was initially called the funnel block, because it directs the flow of color. One can enter it from three directions (except the one it is pointing in) but only leave in the direction of the arrow. We could immediately see its value in the game grid as it provided good clues for the solution.
The visual symbols for the special blocks were obviously to be decided with the final art style. Apart from that important detail, we were pretty pleased about the depth we had added to the game. With all the Special Blocks implemented, a level would play something like this:
Obviously you have to figure out which block is which, as there are no visual indications in that early prototype there. A good way to test if you were paying attention! :)
Now we could finally move on to the gargantuan task of creating levels where the Special Blocks could finally come into play.
We’ve already mentioned that we got lots of feedback, right? And useful feedback – not the lame kind that says, “wuz gud. Gr8 fun!”. We got a lot of comments and great insight on how we could improve our game and make the controls more user-friendly (thanks to all our awesome play-testers!). Keeping the touch interface in mind, we added a few new features to help the usability:
Path Visibility – This would help the player understand the exact structure of a color path. We added directional arrows showing the entire flow of the color path. One thing that bothered us about this was that it would make the whole grid look messy, but we decided to postpone a decision on that, until we had finalized the art style.
Path Clearing – This would help in clearing an unwanted path with a single click. The player could erase a path to any block by simply clicking on it once. To continue extending the block further, all they would need to do is drag further without un-clicking. This was intuitive and similar to dragging the color out from the number block and was a perfect match to the existing control scheme.
Path Cutting – This was a feature added to allow the player to quickly try another possible solution by allowing them to cut a path of another color which they had created earlier. A problem with this approach was that the player could accidentally cut a path and lose previous solution that was, in fact, correct. We had to think of a way to undo this without having to implement an undo button.
Number Counting – This was possibly the most important feature we added. This would help the player keep track of the number of blocks they had covered, as they extend the path from the head block. One of the problems with this feature was that it would not help the player if the path was really long. This was because their attention would be focused on the end of the color path which would be (n) number of blocks away from the head. Again this was a feedback issue we decided to look into later.
Check-out the above mindblowing features in the build below:
Again there were no tutorials and we used temporary art. While this build was being tested we tried a barrage of art styles. One of our major gripes with the game was that it totally relied on colors to differentiate between the various paths. This was a problem for us because we wanted to make the game color-blind friendly. Anyway, this too we decided to tackle later. (You can read more about our struggles with various art styles here)
One of the most popular themes was the one with the quirky worms. We thought it would be fun to have the worms eating their way through the blocks. But one problem with this was explaining the undoing of the paths. It would look very odd if we had the worms puking out the blocks into a neat little grid again. Yeah, credibility was hardly an issue in a game where worms would be eating blocks, but there is something like taking a thing too far. We knew the worms would not have won any beauty contests anyway, but they looked especially bizarre in certain orientations. Also, many of our female play-testers who enjoyed the game a lot didn’t particularly savor the idea of touching squishy worms. So we decided to nix the character issue for now, and perhaps revisit it later. For now we decided to go ahead with the doodle lines with the bright color look.
We added another small set of features that would help the player fine tune the path cutting:
Undo cuts – A player could now cut paths, however tracing back on the path would result in undoing it. This was very useful if the player had a hunch for a path but was not 100 percent sure of it.
Suspended path highlighting – This would visually indicate to the player the area of a path that would effectively be cut. In the current build this was implemented by darkening the existing color. But that would only multiply the number of colors on the grind and would increase the players’ confusion. Again this was something we decided to deal with later.
You can play these features in the next post, as this build also had some Special Blocks which we will be discussing then.
By now it was clear that needed to start making levels for this. We did not have a level editor right then, but we would need one soon enough. For the time being we made the levels by hard coding some array information. We had already thought this game could be made arcade-style, along with some kind of co-op mode. We had plans for the having the co-op mode played out in a fashion similar to the current game. But that was not the priority at the given time, and yet again we decided to put this in ‘tackle later’ box. (And we were getting pretty good at it too!)
And so… we were back to where we started this post from: feedback. Our usual guinea pigs told us that the game was interesting, but we all knew that it needed greater depth. One way to do this was to allow mixing of colors, however we didn’t want to go that route, especially since Trainyard had already done such a fine job of it. Already we were depending too much on color. We dropped the idea of color mixing and instead went for newer “special” blocks that would add gameplay. We will discuss more about the special blocks in the next post.
The process of coming up with an idea, getting excited about it and then finally junking it can be quite exhausting. Call it growing up, or call it growing numb, but by the time we have junked our nth idea, we were about ready to give up. And then, just like the first life-form stirred in a primordial swampy soup, something stirred in the recesses of our brains. Remember we talked about how we got to similar ideas as Picross and Paint by Numbers? Something seemed to be whispering to us that all was not lost and it most certainly wasn’t that dude who lives in our office.
No, it was the first, faint stirring of an idea that we knew would be a cracker. It was really quite simple (isn’t it always?) Painting paths to completely colour the grid. So, as we envisioned it, there would be a grid, scattered around which would be a bunch of blocks with numbers on them. The idea was to drag a path from a numbered block and to eventually fill up the grid with the designated colour. The number in the head would indicate the number of blocks that would be coloured in that particular path.
Now we seemed to be getting somewhere. We tested the idea using Paint and then quickly whipped up a build in Flixel. At that point, it was just a crude playable, made for internal testing, where we had the path removed as soon as it was connected with the correct number of blocks.
We had a plan that the pre-coloured blocks in the grid would act as clues: these would be termed the ‘locked’ blocks. Their purpose would be to hint at the location of the coloured path. We thought this was by far the best way to construct the puzzle: there would be enough clues for the player to work with. It would remain challenging, but would also be playable. The difficulty level could be adjusted by simply adding or removing these ‘locked’ blocks from crucial areas.
Convinced that this would work, we decided to test the game on our families and friends. We whipped up some code, added a tutorial before the game, and to make it more playable, we also added a feature that would enable the player to continue dragging from any point in the path. We also decided that it would be better to NOT remove the paths as soon as they were identified. There were two reasons for this:
1) Levels could have multiple solutions and if we removed the path, the player may not be able to switch to an alternate solution in the middle of solving a puzzle. We needed that flexibility.
2) We wanted to reinforce the ‘puzzle’ nature of the game. By removing the paths, we would be giving out the solution part by part and thus making it impossible to create difficult levels.
And the feedback from our testers? Nobody actually experienced pure rapture or fell on our necks, blubbering about what a sooper-fantastic-brilliant-AWESOME experience it had all been. But, we did get some encouraging feedback. Most of our testers also pointed out that we needed to make the controls more user-friendly. Exactly what steps we took in that direction, will be the subject of the next post.
In the previous post, we explained the long and winding road that we took in order to finally arrive at an art style that was consistent with the game we had in mind and that would also be aesthetically appealing. This saga of lengthy journeys, in fact, really began with the very conception of the game. We knew we wanted something simple and we definitely wanted to make something puzzle-based which would not only be addictive, but would also ensure that the players’ brains were stretched to the maximum.
Simplicity, as we’ve mentioned before, is the hardest thing to achieve. As soon as we were done with work on Just a Thought, we started throwing around ideas for a simple, grid-based puzzle game that would require minimal art. Not that we looked on simplicity and minimalism as an ends in themselves. The lack of a proper artist had tied our hands, but we at Yellow Monkey Studios believe in making the best of a bad situation.
Simple, addictive, well-designed: these are three factors with a whole lot of punch. We batted around a lot of ideas initially and came up with a few. What we really wanted to do with the game was emphasise on line drawings, something that had become possible thanks to the availability of touch platforms. This basic concept went on to lay the foundation for the game, as you will see.
As, you can see from the image below, we started out thinking in terms of numbers and grids, of shapes that could be cut and folded.
In fact, the first fully formed idea that we had was of a puzzle featuring a ‘meta’ shape, which would be composed of smaller, single units of a ‘base’ shape.
The challenge would be to fold or collapse the entire ‘meta’ shape to fit into one ‘base’ shape. Basically, the number of times the base shape is used would be provided, and the player had to figure out which base shape was repeated to ultimately create the ‘meta’ shape.
If you’re as smart as we hope you are, you will have spotted the glitch immediately. Here’s another example.
The game just wouldn’t have the depth required to make advancing levels interesting. In other words, anyone with a calculator could solve the problem by simply counting the total number of blocks, divide it by the given number and figure out the number of blocks in the base shape, and then it was just a matter of time. We didn’t want to make things as easy as that and so this idea became the first of many to be flushed down the crapper.
We continued to wade through a whole swamp of ideas, including a lot of mathematical puzzles, looking for a logic-based problem that would work in the context of a game. Some of the ideas seemed like they had great potential. There was one with three-legged aliens that seemed very promising.
There was Osama’s Riddle: a grim puzzle full of ruins of buildings bombed by Osama bin Laden.
Another one we liked was based on the Skyscraper Puzzle. Here, the player would have to fill colours within a grid, with a number outside that would indicate the total number of colours in that particular row/column.
Unfortunately, this was too much like Paint by Numbers and Picross on the Nintendo DS. Yet another idea landed in our overflowing trash can of ideas.
We knew there was a game lurking somewhere in the far corners of our minds; we just needed to find it. It was merely a question of sending out the hounds and galloping off on a hunt. Of course, what we found at the end of the ride was nothing less than a Pandora’s Box of troubles. But that is a story for the next post. And the one after that. And the one after that. And also, possibly, the one after that. You’ll never know unless you stick with this story (please do). So watch this space.
Yellow Monkey celebrated 5 years last night and we had a nice little bash with close friends. We had taken the opportunity to announce our upcoming game HUEBRIX, a game we have been working on for the past 16 months. This morning I woke up to find a flurry of activity contemplating if HUEBRIX is a visual rehash of Puzzlejuice. I just thought I needed to put up our side of the story.
I started off the morning reading Greg Wohlwend’s blog post about Visual Systems. I enjoy his work and have nothing but respect for him and his work. We played and enjoyed Puzzlejuice and we think is a shining example of an amazing game on all grounds.
I want to now talk a bit our the Art style for HUEBRIX and how we got there. We used a minimal art style, not because we thought it was easy to do, in fact we know just the opposite, how difficult it can be to make a game with minimal art. We needed to use our art to efficiently enable interaction and gameplay. Which was our objective.
If you have played HUEBRIX or plan to play it, you will see that you need to concentrate on the grid and not be distracted by anything else. That was the primary goal of our exercise. We had started work on the game ages back and were comfortable with the gameplay and we tried a whole bunch of things with the art. This post is mainly going to go through the journey we took and the experiments we did with our art style
Initially we tried a bunch of things with the art to see what was visually pleasing and what could entice people to drag paths around (the major mechanic of HUEBRIX)
All of these styles didn’t really entice the player to drag these paths, nor did they look particularly pleasing. They were fairly short lived. It was here we realized that having curved edges to each square could not work as it was not creating a desire for people to drag and connect them (unless we had some kind of cool liquid physics thing going). The connected shapes would have repeated patterns of the curved shapes. In the end it was something we could not manage to get our heads around.
We then tried to create a slightly more friendlier look with a more scribbly art style.
This one was fairly popular, all our play-testers thought it was good but definitely not the best we could do with the game.
We then tried to do something with characters, something that may make the game easier to consume. We started of by creating a style with cute little worms.
The worms got a good response, but it did not do well with a lot of our female players. They felt it would be icky to be touching worms. Eventually we thought maybe we can try something else that is similar. We thought of mythical beasts and dragons with the help of a collaborating artist.
Simultaneously, we internally also tried out a style which would involve knotting balloons to complete the paths.
At this point, we saw that the character oriented art was not helping us attract any fringe players or “casual players” but it was turning off puzzle enthusiasts as it was creating too much visual confusion. Eventually we knew we had to do something really minimal. With the help of an old friend, who is a graphic designer, and is currently studying photography as well, we created some styles. She was kind enough to help us out part time and we would do the rest.
This was looking very visually pleasing and also worked well schematically. The square shapes connected with each other very well and created interesting seamless patterns which would give each level and each unique solution (our game each level can have multiple solutions) a good, unique look. At this point we were using a mild grey plain background.
We had another problem, our levels were of varying grid sizes. That meant, we could either resize the levels and have non-uniform size of squares or we needed to do something about all the negative space around the grid which was looking painfully empty.
We decided to use a texture. We started with trying a white and grey checkerboard texture. This would crete a weird visual illusion where the texture was interfacing with the level grid border, and also this reminded developers of transparency in Photoshop :). So we tried gridlines (which would later cause more confusion with too many grids in the game) and a diamond shaped checkerboard which had an awkward warping effect on the eyes.
To make the colors to stand out, the background needed to be darker. We changed over to a darker BG and a hatching lines texture merged with a carbon fibre texture to create something that worked for us.
Again we contemplated a slightly animated texture with particles in the BG but we thought it would distract people from the all important game grid. We also tried elaborate patterns for textures but they too were very visually distracting.
With respect to the colors, we had to accomodate 12 colors, all of which would look good together in the game at the same time. We had very little freedom to experiment with this once the BG was set. However, the colors were looking lively and the game was taking shape visually. We decided to go with this.
As you can see we had a total trial and error approach to the art. Greg is probably right in saying that using this kind of an art style requires a higher level of mastery, and our small team has very little art and graphic design resources and peharps too little understanding. We were just doing what we thought worked best for the game.
Our intention was not to offend anyone, or rip anyone off. Ours was and ernest and honest attempt at getting a game out that worked visually, facilitated interaction and maximized gameplay. I am sure we could have done a MUCH better job if we had the resources. However, I know everyone who will spend some time with the game and give it a fair chance will realize its a geniune attempt at a fun game.