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.
 

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.
 

Try, Try, Try again… and again… and again…

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.
 

Be there and be Square!

 

11th November, up at 4:30 a.m. to reach Dadar station to catch a bus to Pune for the Nasscom GDC. Just the night before night Krishna and me realized that we would infact have the time and could actually attend the NGDC. At first we thought it’s too last minute but by midnight we decided, lets go for it. So, groggily we met up at 5am outside the station and got on a Shivneri after a 4 hour journey spent in a half asleep state, we reached Pune and head right to the venue, Taj Vivanta and “freshened up” there. EXCEPT! that was NOT the venue! After speaking to a couple of friends we realized that the venue was Hyatt Regency (I still can’t recollect why we were so convinced that the venue was Taj). Feeling like a bunch of idiots we head towards Hyatt and spent 2 days attending sessions and meeting lots of interesting people.

 

There were some really good sessions this year. I particularly enjoyed Rajat Ojha’s Post Mortem of their upcoming game SNS. It was a simple talk of What they did, How they did it and what did or did not work for them. I wish them luck for the launch and with their new games. Jason Bay’s session on freemium games also had some great insight into the hottest business model in the games indsutry today. Then there were the fellow Indies, Yadu, Kinshuk, Shubhank, Apoorav and the whole bunch. They were lively and passionate with good ideas for the way forward for Indies and game development in general in India (like the BYOG). My personal favorite moments, however, were the heated discussions between Vijay and Yiannis. :)

 

The NGDC ended quite well with a great meeting with Ian Livingstone. I demoed our upcoming game to him and he seemed to think it had potential (YAY!!!) As you can see, it was very Heart Warming. :)