This is going to be a Design oriented post. You may want to just skip to the very end and download the design document for R.O.V.E.R. For anyone interested in more insight on this, I am going to be discussing my design process for creating the document which won a special award in the Playstation Asia Challenge 2012 for Vita. More information on the contest and other winners click here.
I had initially planned to make an MMORPG with the Vita but I felt it was really done to death. It had nothing unique that I could use from what Vita had to offer. While writing the documentation I was just not feeling it. I decided to switch over to something that exploits Vita’s complete potential in terms of the new hardware (Back touch,Front camera,Dual analog sticks, Gyro-meter). One of the first things I do is sketch the device out, giving my mind a visual of the device that the game is going to be played on. I also try to map out the different kinds of interactions one can have with the device. Here is the sketch straight from my design diary.
PS VITA Sketches
The next day I had to think of a situations/themes in which all of these interactions will be used in. This is probably the most difficult part but when it hits, it’s a home run. I had been playing Metal Gear Solid 4 and I really liked the idea of a stealth game featuring only an RC Vehicle. I also figured that the Vita could be an awesome controller for an RC Vehicle. I quickly sketched some situations the new controls of the Vita be used in. Here is another sketch showing the front camera in action. The lower sketch is actually an enemy trying to pick the RC Vehicle where the player can use the back touch pad to flip the vehicle out of danger.
Pre-visualization for situations
The PS Asia Challenge had a very good skeleton document structure for me to package my thoughts. I recommend you have a look at it as well here. On Day 3 I figured out certain keywords that would explain the game/gameplay clearly. My design would be based around these keywords. They were – Military RC, Nudge, Gyro-Controls (Tiny Movements and Adjustments), Gadgets, Exploring + Killing (more like disabling/destroying actually), Scale. I also quickly jotted down a list of gadgets/verbs in I would want in the game. They were Invisibility, Shorten-Lengthen, Rope, Snipe, Latch, Climb, Mines.
Day 4 – To figure out what the challenges would be in the game I asked myself few of these questions.
How do I reach there? (Maneuvering Challenge)
How do I take this guy out? (Survival/Disable Challenge)
What do I choose to do? Disable or Destroy (Moral Challenge)
Should I go here first? (Exploration Challenge)
The Interaction Map
With this information, I quickly plotted this sort of mind map of challenges you can see in the image below. Everything I wanted in the game was expressed by this simple one page connected map.
That was about it. At this point I had everything I needed to start working on the document filling in the missing details. This process is the longest and took me a handful of days. The story came naturally and hence is cliched. The story is something that will definitely need revision if this game ever gets made.
You are free to download the document and share it with anyone. Heck you can even go ahead and make this into a game if you deem it worthy.
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 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
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.