Career Chat with Yellow Monkey Studios

The Gyani Guy recently had a chat with us to know about Game Design and Development as a career path.
 

 

Stumbling Blocks

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.
 

The Pursuit of IP-ness

“The games space in India is going to grow rapidly in the next five years”, is what I have been hearing about the Indian games development scene for the past eight years. Yet, not much has seemingly changed. We still have the handful of big home grown studios we had then – some of them have been acquired by larger overseas companies, and a whole plethora of small studios. But what is everyone doing? Where are those awesome games? Read more here

Piecing The Puzzle Together

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 Mutation

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.