First off, thanks for playing and supporting Socioball and for all the levels that everyone made!
Unfortunately Twitter has moved to jpgs and the compression is killing our level sharing solution. After some debate we have decided to not support the game further and will be taking down the level share features and we are really sorry for that. As long as the existing tweeted levels are still on png format on Twitter, they will still be playable. Thank you for your patience! I hope everyone had fun with the game. The game itself will continue to be available on the store with the pre-packaged levels.
It’s been over a year since I posted anything here. Somehow I haven’t really taken to blogging very well. But we finally have a release date for Socioball and that is January 15th 2015. We hope to see you download the game and Play, Create, Tweet. :) Merry Christmas, for our family it is an awesome one since we got excellent quality pool tables for our kids as their gift, they love it.
Last week Manu was sick, so Krishna and me decided to have our very own little Game Jam. Both of us would work on our own games on Game Maker that were infinite, could playable on smartphones, were one hit kill and about finding oneself. You Who was my attempt at that. It is fairly crude. The level generation logic is random and needs a lot of work. I don’t think I am pursuing it any further at the moment.
You must escape the darkness. If you collect yourself you get some bullets to push the darkness back. If you bump into others you will shrink and eventually succumb to the darkness as well.
Move the mouse around to move around and left click to shoot when you have bullets.
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.