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.

Suck and Blow (No, Really)

Being able to control the ball using gusts of wind came about more as an accident than anything. One of the fundamental limitations of traditional brick breaking games is the intermittent, disconnected nature of the control over the ball.

During a session when we were throwing ideas back and forth, I suggested one where we had a vortex which would suck in the ball and then get blown out someplace else on the screen.

While it was not implemented, our producer Alan Bell took the idea of the vortex and suggested we have it as a permanent mechanic within the game where we could use wind to control the ball. Remember at the start when I said that new ideas can cause new problems? This gave us headaches!

During my user-testing sessions it was safe to say that people just didn't get it. They would press the blow feature and the ball would go one way but they had no idea why -- because it seemed that no matter where they were on the screen, the effect was the same.

The other problem was that they could continuously blow and keep the ball on the far end of the screen, happily letting it smash the bricks on its own. While this had the positive effect of destroying the bricks, it also made the game pretty uninteresting.

This fed into yet another problem, in that users were simply forgetting about the bat. Because they had the ball on the far side and were able to keep it there, when it did eventually come back they were so focused on blowing that they would actually miss the ball.

All these problems lead to a game which was not particularly well received during the user testing sessions.

The initial suck and blow gave the user full control over the ball, no matter where it was in relation to the bat, as shown below.

Bat and ball blow

After watching a fair amount of users playing and going over the videos countless times, I thought we were perhaps giving the user too much control over the ball.

If they're in the bottom right of the screen and they can affect the ball at the top left, then of course they would be confused. So I suggested we make everything localized whereby the ball is only affected in the vicinity of the bat. This is shown below.

Localized suck and blow

Another user testing session was scheduled; up until this point, the game had been scoring quite low on my user surveys and I was wondering what else would go wrong. But you can imagine my delight when the first user sat down and got the hang of the suck and blow on the first try. The best thing about this was that it wasn't a one-off -- they all got it!

But this refinement went further than just fixing the control problem. People were now paying close attention to what was happening within the game -- paying close attention to the bat and the ball, for starters.

On top of this, they now had the added confidence to play with the other aspects in the game such as sucking in bonus fragments to gain special attack power, using the shield, and also collecting powerups.

Fixing this one problem had a knock-on effect which addressed a whole lot of others and it goes to show just how important controls are within a game. Let me tell you that when I presented my findings to the team on that day, it felt good.

This mechanic also tore down a huge flaw that all classic brick-breaking games suffer from: the last brick problem. Users were now able to direct the ball anywhere they wanted.

Some may say, "Ah, but it's a challenge to get that last brick." This is true, but "some" is the operative word here. The majority say, "Argh! I can't get that last (insert expletive here) brick!" And you have to ask, where is the fun in that?

The Proof of the Pudding Is In the Eating

There were quite a few more problems that arose during the development of Shatter, but the ones I have highlighted here not only caused us the most headaches but are also quite interesting in their own right.

After the end of all my user testing sessions, I administer a questionnaire and nestled amongst the questions is your classic "fun factor" question. The data below shows a combination from the last three user-testing sessions.

I would show the graph for the first two sessions, but it's far too depressing. As we approached and fixed the issues, the game improved drastically. Users were getting the hang of the game, they were able to pick up the joypad, jump in and play and, most importantly, they openly showed signs of enjoyment.

But it was only during the final sessions did we truly have something which was scoring consistently as fun to play. It was fun for us and, most importantly, it was fun for the users too.

Conclusion

I'm a big advocate of developers testing their games out on the general public. It is only through this approach can we truly determine whether unseen barriers to play exist.

I must stress though that there should be openness, strong communication, and a desire to identify and resolve issues with the game within the team. Taking "bad news" to people is always a daunting task. You know that the developers work themselves to the bone in order to get the game out on time and someone who just brings bad tidings is not going to be welcomed for long.

But if the team is open to feedback and can take on board the findings as a learning experience, then everything is fine and the game itself will benefit. This is where I feel extremely lucky at Sidhe, because each project team is always willing to listen and any negative findings are seen as a way of simply improving the game.

However, this experience has also taught me that we should never take anything for granted. When trying to evolve a tried-and-tested genre we could have simply assumed that people would "get it" because the general foundation was already there.

But just adding one new feature, such as the suck and blow, can make a huge impact on the game's enjoyment. It also showed me the extent to which problems are interlinked and that taking the time to analyze them and addressing the correct problems, can have a positive knock-on for the entire project.