Tag Archive: Game Design


As we have already mentioned many times, we work on Caromble! only on Fridays and every spare hour in the evening and weekends. Mostly, we write these blogs about our part-time struggles of making Caromble!, but this time, I want to take a moment to talk about my other occupation. Not that of being a boyfriend, but my ‘real’ job at Motek Medical.

Motek Medical creates products for rehabilitation. They combine motion platforms, instrumented treadmills and motion capture systems with a virtual environment to provide motivating and engaging training exercises and precise assessments for rehabilitation:

I am primarily a C++ developer here, but lately I am also working on rehab applications (so called ‘serious’ or ‘health’ games) for patients, doing game design and implementation.

Making a health game is very different from making a game for entertainment. For Caromble! I make design choices using my gut feeling and my own experiences of the games I love. It has to become a game that I too could enjoy. When designing a game for a specific patient group, the approach is very different. More than in any other game, the player is the main focus in a health game and the desired outcome is different. The game should be motivating, challenging and captivating for the targeted patient, not only to entertain, but with the goal of improving her (let’s assume she is female) capabilities. A game designed for this purpose, could very well be a game that I wouldn’t like to play or look at. For me, this takes me a bit out of my comfort zone, where as a gamer I think to know which are ‘good’ game design choices and which are not; knowledge which I can use in the game design choices of e.g. Caromble!. In health games these ‘rules’ I have learned simply do not apply.

When designing a health game, the main question is: “Who is the audience?”, and to go a bit deeper, also: “What is the (clinical) goal of the health game? “, “What is the patient capable of (cognitive, physically and visually)?” In an ideal world, a health game is designed for one person, so you can make specific design choices for that person, taking into account her capabilities and interests. Unfortunately, this is often not the case. A health game has to be designed for a whole patient group, for example stroke patients. The problem is, that one stroke patient is very different from another; one can still move her arm, a second can move it only a little and third can’t move it at all. Or one has an easily overloaded cognition, while another can handle a lot of different cognitive signals easily. Besides these variations there are also the subjective preferences that patients can have about visuals, gameplay and sound. Making a game that is suited for a whole patient group is according to me, the biggest and most interesting challenge.

Before we start prototyping a new health game for a specific illness or physical/psychological problem, we sit around with therapists and patients to get to know the intended audience. With the retrieved insight we start prototyping both gameplay and visuals. We playtest the prototypes ourselves and with patients and with those new insights we often have to go back to the drawing board. It still amazes me how difficult it can be to fully let my own assumptions of a ‘good’ game go and think ‘with’ and ‘for’ the patient, about what is desired for her.

Once we have a suitable prototype for the project, we still have the challenge of making the game such that it is challenging and captivating for the whole range of patients. A scalable difficulty is one of the most important aspects to achieve this in my opinion. There are two ways to do this:

  1. Incorporate many settings that the therapist can adjust, such that the game can be tailored to the specific patient.
  2. Design the game in such a way that it uses adaptive difficulty.

I think the best solution is to use a combination of these two. Expose some settings to the therapist, but not too many or the game will be difficult/unclear to use. Also, find a way to let the game decide itself whether it should change its difficulty and if so, think of a good way to do this. Probably many games that I have played use some form of adaptive difficulty, but two examples that come to mind are FIFA Football and Mario Kart. FIFA did this in the worst way possible: after a few games I lost, the game suggested something like: “shall we set the difficulty to a more suitable level for you?” Well thank you very much EA, for pointing out that I’m a loser. Mario Kart on the other hand, gives losing players a higher probability of better powerups, improving their chances of winning. I think that these methods are not the best way to do this, but to hide this mechanic from the player, instead of what FIFA did, seems like a good choice.

Today, my colleague Coen and I went playtesting our current project Bloonies with a patient. The goal of the application is to train dual tasking: stroke patients can have difficulty with walking when executing a cognitive task. During this extra task they can slow down or even stop walking. The goal of Bloonies is to train this dual tasking. I have been reading some game design books (currently ‘A Book of Lenses’, love it!), but none of these books could give me the insight that I got from seeing this patient playing Bloonies and hearing his thoughts about it. Making health games requires a whole different kind of game design, one that I grow more fond of every day. I will share a video of Bloonies on this blog once it is finished and perhaps explain something about the way we achieved scalable difficulty in that project.

Thinking about the concept of adaptive difficulty, it makes me wonder if such a thing would be suitable for Caromble!. We are now too far in the development to incorporate such a thing, but it is an interesting thought experiment. I think that the difficulty in Caromble! is linked to two situations:

  1. Losing the ball; a higher difficulty makes the player lose the ball quicker and more often.
  2. Taking more time to complete a level; either to destroy all blocks or to solve a puzzle.

If we would incorporate an adaptive difficulty, we could influence both of these situations. Losing a ball can have multiple causes, but I think the main ones are a ball speed that is too high and blocks close to the paddle where the ball bounces off. If the player loses the ball too often or too quickly, the game could decrease the ball speed and destroy nearby blocks. A solution for a level that takes too long is to destroy some of the blocks after too much time has passed or to provide a hint system for the puzzles that offers these if too much time has passed. I think it is not smart to try and implement this into Caromble! now. These kind of features have to be incorporated early on in the development of  a game; otherwise it can introduce balancing difficulties in terms of gameplay.

Also, the process of thinking with the patient, what I am learning through experience at Motek Medical, made me think of how this approach would work on Caromble!. Who exactly is our audience? In my opinion it are retro and indie gamers and perhaps (hopefully), some casual gamers can appreciate it (read: love it to the fullest) as well. Would the game be very different if we carried out an extensive study on the preferences and desires of these gamers? I think it can be very interesting to try this approach on a future entertainment game we make: to let go of our current assumptions and learn from the potential players.

Caromble! is a game that at least we enjoy playing a lot and we can only hope that many players feel the same. Since Caromble! is the first full game we create, I believe that is enough.

 

Like a Boss

“DOH”!

Most people will interpret this as Homer Simpson’s catchphrase, but that’s actually spelled as “Do’h”. For me, and perhaps most Breakout fans, the story of Arkanoid comes to mind. Arkanoid’s almost unbelievable story goes like this: Vaus is the space vessel that escaped the ill-fated mothership named Arkanoid – hence, the name of the game. That vessel acts as the game’s focal character: the paddle. After some rounds of brick breaking awesomeness the player reaches the final round where the goal is to demolish the ‘dimension-controlling fort’ which is named… “DOH”.

This illustrates that a Breakout game can have a story to add to the overall experience. In an earlier post we promised to put in boss fights. We didn’t initially plan this – in fact, we rejected boss fights earlier in the development process because we didn’t see how it would fit into Caromble! – but as art, gameplay and story developed, the boss fights seemed to find its way back onto our agenda and seemed to fit right in. Storywise the paddle is our so-called protagonist, the lead character whom the player can identify with. Opposed to that we have the boss as antagonist, the character that (literally) creates obstacles that the protagonist must overcome. Throughout all aspects of the game the idea of protagonist versus antagonist is a nice contrast to elaborate on.

Caromble! is almost gameplay complete now. The boss fight is one of the latest gameplay features that we are still experimenting with. Despite the fact that we rejected boss fights earlier in the development process we are really excited that we put this element back into the game. Finally we arrived at the point that we can proudly say “THIS is Caromble!”.

P.S. For those wondering what Arkanoid’s “DOH” means. If my Google skills are okay it’s an acronym for ‘Dominator of Hours’. I guess this knowledge will score you some nice points in your next video game themed pub quiz!

Since I was a kid, I loved to create something huge with Lego blocks and then… destroy it. Or make a huge card house with my grandfather, like 7 stories high, and then… make it collapse. I’m not unique in this. Many people seem to like destruction, witnessing  the several popular scientific television shows in which objects are blown to pieces or dropped from a crane.

I think that besides seeing things collapsing, people find it even more satisfying  to be the cause of some kind of destruction. Whenever I see a structure of domino stones, my fingers itch and I want to be the one to tip over the first stone. I think we love to be the first part in a causal chain. I’m not  sure why we love it so much, but perhaps it creates a feeling that makes us extra aware of being alive. I experience a similar feeling when travelling by bus. Whenever I need to press the stop button, I also want to see the stop sign lighting up because of MY button press; “Yeah, I did that!”. Perhaps instead of “I think therefore I am”, the statement “I cause therefore I am” suits us better.

Caromble! is in its essence a breakout game. A game in which the player moves a paddle, aims and bounces the ball, hoping to destroy some blocks. Somehow it so much more interesting if one of these blocks was supporting a big structure that is now collapsing. “Yeah, I caused that… again!”. That specific feeling, that is the added value of incorporating a physics engine into Caromble! in my opinion. The core gameplay may not always be very different from an ‘ordinary’ breakout game, but the fact that the player can be the first step in a causal chain that leads to destruction, explosions and chaos , makes the experience so much more satisfying. Here is an awesome video from OK Go that demonstrates this idea through a Rube Goldberg machine. And how satisfying does this look (we use the Java port of BulletJBullet, for our physics)?

The interesting thing of incorporating a physics engine in your game, is choosing when and how to intervene in the physics simulation. Without intervention (moving, creating or destroying objects in the simulated world) there is no gameplay. In Caromble! the single action a player can perform (besides using power-ups) is moving the paddle. With the paddle, the player can influence the most important object in our  game; the ball. The ball is a peculiar object. It takes part in the physics simulation, but it is not totally governed by it. If that would be so, friction of the floor with the ball (which both are not zero) would eventually result in a ball at rest (zero velocity). That would be quite a boring game. That is why the ball is governed by more rules than those of the physics simulation: OUR rules.

For example, each level has a desired ball speed. Whenever the ball speed deviates from it, we make sure it quickly converges to the desired one. Also, we handle all ball collisions ourselves. The collision detection is done by the physics engine, but based on the ingoing direction and the normal of the object at the collision, we determine the outgoing direction of the ball ourselves. One of the reasons we do this, is to ensure that  there is some minimum bouncing angle. Whenever the ball bounces almost horizontally between two opposite side walls, we don’t want it to take forever before  it approaches our paddle again.

Finding the balance between simulation and intervention is quite the challenge. Sometimes, mostly after heated discussions, we decide to add a new intervention rule to our physics simulation for the sake of gameplay. How far should you go with this? Well, we think that you should aim for a certain level of control for the player, such that whenever he/she loses a ball, it should have been possible to prevent this using skill. However, the simulation should add a factor of unpredictability and surprise. You know that once you hit that one block, that structure will collapse, but how exactly, that should be somewhat of a surprise. We aim to get this balance right and I think we are on the right track. As long as Caromble! will make some of you players experience the feeling that I got when tipping over a Lego structure, I am very satisfied.

Meaning of Life

Up to this point the background story has been our neglected child. She has become a wild beast. But now we are walking her back from the forest and we begin to tame her.

I hear you ask: “Why does Caromble! need a background story?”. The answer is quite simple and binary. Concerning stories there are 10 types of gamers. Those who ignore the story, just play, and find that beating the game is its own reward. And those who want an explanation for what they are doing.

But that’s game design theory speaking. The real reason is that we love stories! Every Friday we come up with tons of new game ideas, backing them up with a story as we sing their theme songs describing new fantasy worlds. Games in general are about doing stuff we can’t do in the real world.

Caromble! will be about good vs. bad alien ‘viruses’ in an earth-like environment. That leaves us with more than enough ingredients to write a wonderful background story to reward our players looking for meaning in their games and lives.

Color Coding

About time to post some concept art, that’s still waiting to see the light of the internet. Some time ago we decided on the chapters we will have in the final version. These have to look consistent with each other, but also distinguished as different themes. Add to that that the gameplay itself uses colors too (the common red explosives for example), and you have quite a complex setup to plan.

Since the gameplay also evolved organically, it dawned on me pretty late that each part should have a clear color code. Here is the setup I sketched out:

The bumpers are blue, and the borders, that the player can’t destroy are yellow for example… this might not need to be explained to the player – but tell him subconsciously what he can do in the game.

Here you can see how it works in the game so far:

The strong colors of these elements make it hard to get all the rest work well with the subtle colors I wanted. But gameplay goes first. I’m actually thinking to try black for the “indestructible” border – might be more consistent with the black outlines in the artworks, and allow yellow to be used for other parts, like highlighting important structures.

After that then I approachd an overview of the level art – with more muted colors. And specific shapes for the different chapters. For now we’re going only for the factory and the commercial area. … and now comes the hard part to get all this nearly like it into the game.

Paddle Version 2.0

After we picked the red style from the last post, it was time to come up the paddle design. Here are some possible versions.

We currently have a dummy of version K in the game. Some research also went into how paddles look and behave in other breakout games. I was really surprised to learn that most paddles nowadays don’t use proper reflection. But that makes them way more controllable. The worst problem is really when the player hits the ball and it still goes out – that feels unfair.

Concept: The Alien!

So in our push to get a new demo together we’re also adjusting some gameplay. For one we want to give the player a clear goal what to aim for in a level.

Our idea is to add an alien artifact, that crashed in each level. The player is basically the alien rescue team. Here are some ideas for how the design could look.

It has a clear contrast to the world, to be easily spottable. It also gives us an excuse to make the goodies easily spottable. Red looks nice – so we’ll run witht hat, but we might have to use more colors for different goodies.

Tinkering under the Hood

The last update is a while ago, but there has been nice progress. Most importantly the programmers have been very busy with the editor, as we planned after our Indigo-reviews. We have now a working tool to build levels without working only in abstract text files. There are bugs left to fix for sure, but new levels will pop up here soon.

On the art side there have been mostly changes to the existing assets. Lot’s of boring resizing. But it was necessary, since the whole setup in the demo didn’t quite work. The steps will be always in multiples of four – its easier, and more logical. (Interestingly – after figuring this out with lots of number crunching, I learned that four is a recurring number in “Scaling Laws In Biology And Other Complex Systems“.)

Object Resizing

Object Resizing

Some gameplay tweaks are in already and just need tweaking and extending. For example the spin idea mentioned in earlier posts.

New Gameplay mechanic: Spin ball

A new gameplay mechanic: the spin ball.

And some features we’re planning still, if we get around to it. One of them is to let the people in the game run away from the ball. Should make it a bit more livelier, relatable… and fun! Who doesn’t like chasing little scared humans with a wrecking ball?

Gameplay Crowd

Gameplay Addition: Crowd

Indigo Roundup Part 2

frontpage Ardor3D

BTW: We're featured on the Ardor3D frontpage (the engine we use).

The other week the Caromble team met up to exchange the experiences from the Indie-event and think about where to go next. So now is the perfect time now to reassess before committing to a more final direction in development: Our prototype is far enough to judge the players reactions, but still early enough to change direction if necessary. And we had a lot of input.

The main things we want to figure out now is how to move on commercially: We all agree that we would love to make some money out of it. Maybe early investments (not just after we’re done), so we can put it in the development.

We also want to try some more gameplay tweaks – we have the chance now to still test around. The main mechanic is too simple, we should at least allow more interaction for better players.

Taking aside the problems that result from presenting a prototype (missing content and features, lack of consistent quality, not much guiding of the player), here are the points we agreed on from the feedback.

    The good:

  • It is already a lot of fun, so the basic idea can stay. In my experience early prototypes are often more of a drag (because of the mentioned shortcomings) – Caromble is a positive exception.
  • It ran really stable. After some trouble setting it up, I don’t think we ever had a crash or performance problems.
  • The art style can stay. Also the decision of the scenario with the cities got really positive reactions.
  • The music worked well.
Indigo - yet another pic

Indigo - yet another picture

indigo logo.

Since that is the last roundup: A thanks goes again to the game garden for letting us show our game at thier event.

    The bad:

  • The art is too inconsistent. The idea with making it comic-style is not getting across enough. Funnily it seems I put too much work into it. All the assets I rushed for the event got the most positive feedback. I could write a whole article about the state of confusion and dilemma that puts me in – but I spare you.
  • The sounds: There was not enough variation. They were not convincing enough. But we knew it, since it was a bit rushed but still there is much work ahead for us.
  • Several things caused confusion, that we ourselves didn’t even see anymore: The pink blobs that fly to the player. We should remove them or make them useful. We have to add walls to the level, to make clear what the ball reflects from.
  • The slogan has to change – heh I liked the joking “yet another breakout” – but some people took it seriously. So we’ll have to come up with something more positive. No ideas yet.

So the plan: Fix the problems, add a deeper layer of gameplay and get the level editor going. Then we can test around more, and create a playable version with more levels. Once that all works, we can show it to publishers or even publish it as beta on the website.

Rescaling the Level

We’re working right now on the content for the Indigo – that means getting the first level nicely playable. One thing we will have to do (possibly later though), is to rescale the layout of it. My concept just totally underestimated the size differences between the small scale and the big scale (we want to go from small crates up to destroying skyscrapers).

Here is a sketch just visualizing the size progression:

So instead of this:

We have to do something more like this:

This is very different from usual breakout games. They are very “top-down” usually – not going into height at all, even if 3D. So this will be a gamedesign challenge, to get a more vertical gameplay working. It has advantages though: The top-down camera is not very impressive – so if we can manage to change the angle, then the look of the game will improve. It will also set us apart of existing games.