A Pixel Blocked Algorithm

With Pixel Blocked! released on XBLIG, I’ve been able to take a lot of the professional feedback from various reviewers and make Pixel Blocked! a better game for the upcoming XBLIG patch and Windows Phone version.

One of the things I’ve been working on is a Pixel Blocked Algorithm. It sounds silly, but really, it’s just an algorithm to determine whether or not a particular pixel is un-reachable. (i.e. the player can not fill that pixel, thus putting the puzzle into a fail state where it can no longer be solved.)

What I wanted to share was that programming this algorithm has been one of the most rewarding experiences I’ve had making this game. I’ve spent a total of 6 days working on this algorithm, but I mean that very lightly. I’m currently visiting family in WPG and in those 6 days I also managed to spend an afternoon and evening fishing at Seven Sisters… twice, biking 50km+ to Lock Port and on another day 40+km to Birds Hill Park, an Age of Mythology LAN gaming night and various other family activities.

Originally, I started off with a very naive algorithm, which then grew more complex and convoluted over the days as I tried to determine all the scenarios in which a pixel would be blocked. By day 4, my algorithm had grown into a recursive mess and there was one particular scenario involving a specific arrangement of magnetic and crumble blocks that the algorithm could not correctly detect as being Pixel Blocked. Fixing it would mean breaking other parts of the algorithm, which meant more fixing, and a bigger mess of an algorithm.

At this point, I decided to restart from scratch, which meant 4 days of code out the window (but saved in GIT just in case :P). But I now had a stronger understanding of what it meant to be pixel blocked and this time around, I decided to take a completely different approach with the algorithm. It worked, and I managed to complete it in half the time I did for the first algorithm.

I think what’s so rewarding about the whole experience for me is that it reminded me of the things I believe in. I believe in hard work, I believe in learning from my mistakes and trying again, and I believe in being better. It’s been a month now since I’ve released Pixel Blocked! on XBLIG. I’ve received a lot of great reception and reviews. The majority of the reviews have been really positive. However, downloads/sales have been really low: 1998 downloads / 281 sales of Pixel Blocked as of August 28th. There’s this disconnect between the reception and sales of the game. It could be that puzzle games just don’t sell well on XBLIG, or it could be that the game isn’t as accessible as I thought it could be. Like the first attempt at the Pixel Blocked Algorithm, I think the game over the course of the development grew more complex and convoluted than it needed to be, and fragments of an earlier game ended up staying in the final product. The mobile versions of the game represent my second attempt, and I’m working hard on making it better and more accessible than the first.


Pixel Blocked! currently in Playtest

I’ve finally submitted Pixel Blocked! (Xbox version) to Microsoft’s App Hub for play testing. This process takes about a week. It allows other members to try out your game, find bugs, make sure it follows the guidelines and most importantly, give feedback. For me, this process is about making sure my game is complete, and that I haven’t missed anything major.

Pixel Blocked! on Windows Phone 7

I’m still working on Pixel Blocked!. I’m quite happy with my current build of the Xbox version of the game and could submit it today, but I’ve decided to put it on hold while I focus on the Windows Phone 7 version of the game, as well as on advertising.

So far, the Windows phone 7 version of the game is going well. I’ve been able reuse a lot of my current code base. The big changes I’ve had to make so far are: replacing all of my Draw calls, re-writing my save-load system, handling touch input and re-sizing all of my front-end elements. Here’s the title-screen being rendered on the phone:

Here is the same title screen being rendered on the PC:

The Windows Phone version of the game uses the exact same content and about 90% of the code from the Xbox version. However, XNA on the Windows Phone currently doesn’t have support for custom effects. As a result, the game that is currently rendered on the phone uses a basic effect. For controls, I use a mix of on-screen buttons to move the player and shoot blocks, and finger swipes to rotate the puzzle. I’ll probably experiment with other control schemes once the game is fully functional on the phone. For my save-load manager, I had to switch from using Microsoft.Xna.Framework.Storage on the Xbox to using System.IO.IsolatedStorage on the Phone. Having to resize the front-end elements was the result of changing the resolution from 1280×720 on the Xbox to 800×480 for the Windows Phone.

Right now, I’m focusing on doing a straight port over from the Xbox version and having it fully functional on the Windows Phone. I then plan on tweaking the phone version so that it plays better. A few changes and additions I foresee having to make on the phone include having the game be playable while held vertically, making the fonts larger, adjusting the visual style and having the camera be a little closer to the puzzles.

What’s in a Title

Deciding on the title of the game was probably one of the hardest decisions I had to make. I guess it’s because if something’s not quite agreeable with me, I get a little anxious and keep thinking about how I can improve on it. At this point, though, I’ve decided to let it go. It’s Pixel Blocked! and it’s going to be a great game! 🙂

The title actually came about when an innocent friend of mine (who is from overseas) asked me what c***-blocked meant. After I eloquently explained the phrase to him, he shouted out “OMG I shot blocked myself!” while playing my game. And thus, the beginnings of a title was born.

Why Pixel Blocked!? What I like about it is that there’s lot of angles you could look at the title that would all describe the game. Each block in this game represents a pixel in a larger, more cohesive image. When solving a puzzle, you have to think about where you place your blocks in order to not block yourself off from filling in another empty place. The only time you screw up is if you incorrectly place a block where it doesn’t belong, or somewhere in the puzzle that hinders you from filling up another position. In essence, you’ve blocked yourself from completing the image.

I think it’s a fun title. It’s something you can say to yourself when you realize you’ve blocked yourself and something you can ask your friends, “Have you been pixel blocked?”. I want people to have fun with it. For example, as I was watching a Canucks game today I thought it’d be hilarious if I had a commercial where Roberto Luongo (the goalie) turned into a giant block every time a shot was taken on net – the other team was Pixel Blocked!.

What I didn’t quite like about the title when I initially made the decision was that the words on their own are quite generic terms. The words pixel and block are very common. I was worried that searches for the game would result in random things with pixels and blocks in them. I was also worried the game would be lost in a sea of games with the words pixel or block in their titles. However, those worries have disappeared lately. The top few results from a Google search of “Pixel Blocked!” currently refer to my actual game, and will lead you to this blog, as well as the debut trailer for this game I created back in February.

Pixel Blocked! Game Flow

There’s been a lot of updates to my game since my last post in January up until the release of the debut trailer. I wanted to share them, but I got caught up in getting my game ready for the IndiePub game competition, which was due the 18th of February. With that submission out of the way, I’ve got some more time to blog.

The biggest change by far would be the way the game flows. Oddly enough, I sort of went in circles when thinking about how the user would go from one puzzle to the next. When I originally started this game, I had planned the layout of the game to be similar to Picross DS. Levels consisted of puzzles A-O and each puzzle was its own stage. When I play tested this for Pixel Blocked!, it felt like there wasn’t enough substance having just one puzzle per stage, especially with the easy puzzles, where some of them could be completed in less than 3 seconds. It felt odd and annoying to force the user back to the puzzle selection screen so quickly after completing such a short puzzle.

I then made the decision to have 5 puzzles per stage. Each puzzle has the same overall shape, but with different foundation blocks. When you complete a puzzle, the next one flows to the center of the screen to be solved by the player. I really liked the way it felt, having one puzzle floating to the next, and being able to see a preview of the next puzzle on the left of the screen, as well as a completed puzzle floating on the right of the screen. For awhile this worked really well, as it lengthened the time a person would spend on a single stage and the way it floated from one puzzle to the next felt really natural. Each stage of 5 puzzles was given a target time to beat and allotted a certain amount of missiles. Even with 5 puzzles per stage, some of the stages could still be completed in less than a minute.

About 4 weeks ago, I started noticing problems, especially after I began having people play-test the harder stages. For example, levels 21-30 consist of increasingly difficult 9×9 puzzles. I noticed players burning through their allotted missiles before even reaching the 3rd or 4th puzzle of the stage and getting stuck or having to restart because of an error they made. I noticed players spending over 30 minutes on a single stage and ending up failing. I noticed frustration at having to start stages over again just to get to the 4th or 5th puzzle they were struggling to solve. Those were all unintentional design consequences of having 5 puzzles per stage. I wanted a more balanced usage of missiles and to also change the source of frustration. Frustration (the good kind) should come from players trying to wrap their head around solving a particular puzzle, not from having to re-do already completed puzzles.

What I had failed to notice initially was that the only reason it felt like having one puzzle per stage wasn’t enough substance was because I knew the solution to each puzzle so well that I had forgotten to calculate the thought process time duration of actually finding that solution. Design inspiration came in the form of a game called Glow Artisan that I picked up on the Windows Phone 7. It’s such a simple solution I’m surprised and embarrassed that I didn’t see it sooner. In Glow Artisan, the puzzles are just as short as they are in Pixel Blocked!. They are especially short if you already know the solution or are adept enough to quickly find the solution. Now instead of kicking the player back to the puzzle selection screen after each puzzle (especially in the early stages where this might’ve been annoying), the game allows you to simply play the next puzzle. So in short, you solve a puzzle, get your results, click next and start the next puzzle. It keeps the game flowing, and if the user wants, he or she can go to the puzzle gallery and manually select the puzzle they want to play.

I thought that was the perfect solution, so with 3 weeks to go until the IndiePub competition, I set out to make each puzzle its own stage, but still have the ability for puzzles to flow from one to the next. In the end, my solution came to be a hybrid of my first two attempts and I think the game plays better for it. I eliminated unintentional frustration, balanced out missile usage (3 per puzzle) and kept the puzzles flowing from one to the next. On one hand, I probably should’ve realized earlier that one puzzle per stage was the ideal way to go, but on the other hand, had I not made that mistake, I probably wouldn’t have the great puzzle transitions and animations I currently have now.

Minor Touch Ups and Bug Fixing

I worked on minor touch ups and bug fixing these past two days. They’re nothing major but still important things that need to be done. At this point, I’m focusing on creating more content. I have levels 1-20 complete and I’m planning on having 50 levels. Each level consists of 5 puzzles, so that’s about 150 puzzles left to create. I’m going to try and pace myself at 2 levels a day.

caught me thinking