Brick-breaking games have been around for years, on pretty much every platform you can think of. Many have tried to take this classic genre to the next level in the past but added little, so taking on this challenge with our PlayStation Network game Shatter for PlayStation 3 was somewhat daunting.

From my perspective, as the user experience expert at New Zealand-based independent developer Sidhe (GripShift), I was interested in how the whole user experience would be affected by anything we implemented. It would be easy to say, "Hey, it's just a brick-breaking game -- what is there that can affect the experience anyway?"

Well, if we simply set out to recreate a brick-breaking game "as-is" then sure, there's not much to it; move the bat, hit the ball, problem solved.

But we wanted to take it much further by stripping the genre back to its base elements and testing fundamental assumptions, then rebuilding from the ground up adding physics and boss battles along the way. With so many elements under examination and new elements being brought to the table, you potentially introduce a whole heap of new problems.

In this piece I'm going to talk about the game from the user-perspective and highlight a number of challenges we encountered and what we did to solve them.

In The Beginning

The first prototype of Shatter was an extremely basic flash-based game, as can be seen in the image below.

Flash based Shatter

You may think that there's not much to work from here, but the very foundation of the game was actually in place, and by bringing in people to play we gained a wealth of knowledge.

In this first iteration, we tested two possible control schemes for the bat:

1. We mapped the bat directly to the movement of the joystick. If you let go of the joystick, then the bat would jump back to the center

2. Move the bat with the joystick, and if you let go, the bat stays where it is

It was immediately apparent that users had no liking for option 1 at all. There was an overwhelming lack of control, as they had to concentrate too hard on actually moving the bat itself. If this was the case with only a few objects on screen, one could easily imagine the nightmare later on. Finding this out in the prototyping stage meant one less thing to worry about during actual production.

Round and Round We Go

Along with more traditional rectangular playfields, Shatter introduced circular levels. While these have been received well by users, the original versions were not viewed quite so favorably.

The player was initially able to move the bat around the level's entire circumference. The problem here was that when the player struck the ball and sent it directly opposite, actually getting to that ball was incredibly difficult -- or sometimes even impossible. Sure, we could get to the ball, as we played it every day, but the users -- those who would buy and play the game -- soon grew to hate these levels. Something had to be done.

One idea was to incorporate a boost button which would move the bat faster; in truth, this feature would only really be utilized on these levels. Moreover, it was another button the user had to press -- another control which needed to be explained and then translated.

The idea of simply limiting the user's movements came up -- placing walls that halted their movement and kept the ball in play. This was an immediate success and actually turned what was once the most hated of level types into one of the favorites.

Once Upon a Time

You move a bat, you strike a ball and you break bricks. That's it. But after every user-testing session I would get comments such as "So, what's the point in this game then?" or "I don't feel connected to my bat." Inside I was screaming "Hey, buddy, this isn't a three hour war-epic, you know! Just go ahead and break the bricks!"

Gradually, however, I started to feel that maybe they were right. There was nothing there to connect the user to the bat, nothing there to try and make them want to move forward, aside from breaking more bricks. The game just felt shallow.

When this subject was put forward there was initial skepticism but a small story was worked into the game and, on top of that, we tried to give the bat some kind of personality. For example, when the bat got hit by a brick or the ball ended up in the pit, the bat would make an unhappy sound.

Testing this on users was shocking to say the least. The first one immediately stated "Ah, I'm escaping from something am I? Cool." On top of this, when the bat got hit one user actually said, "Awwww, poor thing." I had to hide my surprise at such completely unexpected comments. But it showed that users were now interested in the character, knew why they had to progress and, as a result, became more engaged with the actual gameplay itself.