Category: Game Design

Caromble! Friday #362: Story & Characters

Thomas—the artist—is completing the final art assets for Chapter 3. The rest of us are adding new sound effects and art assets to the upcoming prologue level. This will be the first level that new players will see. This way we can show a glimpse of the upcoming gameplay and give an introduction to the world of Caromble! and its main characters.

In Caromble! you fight the epic battle against your red alien nemesis. This is a very simple version of the story we have in mind. We know that it’s not necessary to communicate every detail of a story because people will create and experience their own stories inside their minds. What we do want to communicate is this battle between the paddle and the alien. In the prologue level we like to emphasize this duel with a classic “versus screen”. These are some iterations:

Artist’s first sketch

Artist’s first sketch

Programmer's feedback

Programmer’s feedback

Artist's latest version

Artist’s latest version

We have yet to agree on the names of our main characters. Maybe you already have created their names in your own mind?

Bonus question: What are those sentient beings inside the paddle’s spheres?

Yesterday we had our 350th Caromble! Friday. Wow! Luckily it’s not just a special day because of this number, but also because we have completed the creation of the skill level: Race!. A level where the goal is to reach the portal as fast as possible, whilst manoeuvring your ball around and over obstacles as it were a platform game. Lose your ball and you can say bye bye to your highscore.

Race has been an idea of Peter for a very long time. He believed it would be the coolest skill level you can imagine. We were skeptical. It took incredibly long before he started developing it and even in development it just seemed like, meh…

Yesterday Raymond and I (Pascal) have wrapped up the final things in the skill level and when I realized that I was screaming and bouncing on my chair whilst trying to get a highscore.. or no… just to try and reach the end of the level, we realized that Peter’s dream has become reality.

Race is my favourite skill level for the moment and I’m quite proud of my highscore of 1:17. Here is a video of one of my runs where I reached the end. The part with the charge ball in the end gave me a stress level I hadn’t experienced ever before.

April Fools & New Boss Model

So yes… we did our first April Fools’ prank since we’ve started making Caromble!. Of course we will not introduce Pay-Per-Ball. The game remains a premium title. We did get some serious reactions to this, and also some fun responds.

The suggestion to ask 0.99 per ball because of the Dunlop Ball logic was very amusing.

Dunlop balls

Dunlop balls

We are currently working on several stuff. Thomas D. is working on the implementation of some new Sound effects. Raymond is working on the Boss Fight of chapter 3 where you need to use Arkatron #2. Peter is working on a Skill level called: “Race Race Race”, without using the ‘Race card’ of course. Pascal is working on the Prologue story level, which introduces both the Protagonist and Antagonist and where the epic battle for Earth commences. Thomas S is working on the new boss model, which gives it more character:

Like A Boss

Like A Boss

We’re still looking or good names for both the Protagonist (the Paddle) and Antagonist (The Red evil Boss-thing). Do you have any ideas?

We just got a nice question on twitter on how much time it takes for us to build an area. That made us realize that perhaps it would be nice to take this opportunity to explain a bit about how we make Caromble! and also why the game still isn’t finished.

Making a story level

Every story level has four parts set in the same setting. There are three normal areas (you could maybe call them a mini-level), and the action ends with a boss fight. Depending on the level, this can be in a different fourth area or you will encounter the boss within the last area before the fight. Each of these smaller areas will typically feature a specific part of the Caromble! gameplay. So you might have a bit of a puzzle area, then some destruction and maybe finish of with an area that will highlight the surroundings. These three areas usually have some physical connection, for instance they might be set inside each other (a bit like a Russian matryoshka doll).

But how long does it take to make such a level??

Well… It takes quite some time actually.

The process is pretty much as follows.

  1. First we prototype some gameplay and the gross layout of the areas inside the level, this takes 2-3 days of work.
  2. The next step is that we all play through these areas, and probably at least throw out one of ‘m. Playing through the level and making the changes according to the feedback takes roughly 2 days of work I guess.
  3. But now the level still doesn’t look that awesome. So we add some background objects, and arrange the setting of the areas to connect the areas in some manner (for instance make them look like part of a big machine). This can take anywhere between a few hours and a few days, depending on who made the first prototype.
  4. Changing the look of the level might have altered the gameplay too, so we do another playtest and make some more changes. This will hopefully not take much more than a day.
  5. Finally we tweak the ball speed in each area and the occurrence of the different powerups types to fit in in the difficulty arc of the overall game.
If you know how it works, and don't forget to save often, it's quite a good tool! :)

The Caromble! level editor

Taking in mind that we have one day a week to work on the game, the answer is that it can take anywhere between four weeks to three months of actual time between the first idea and having something release worthy. If we had no other obligations we could do it in 4 – 12 days. By the way, this is the time it takes for one person, not for the whole team. So with sometimes 4 people working on levels our velocity gets a combo multiplier.

The good news is that almost all of our 24 levels are at least somewhere in step 2. And quite a few others just need a bit of graphical love.

So when we’ll release chapter two (in the very, very foreseeable future) 8 / 24 levels are done (pending community feedback). Four more are in stage 3-4 and the others are somewhere between 2 and 3.

Making a skill level
A skill level is a small challenge taking place in only one area and is the type we can make the fastest. These can be unlocked by winning medals in the story mode. We have 3 types of challenges:

  1. Score the most points in a given time
  2. Finish the challenge as fast as possible
  3. Survive as long as possible

We have a skill level framework that allows for quickly setting up a skill level. But, most of these skill levels do require some custom code to be written, although often not very complex. For example to spawn an extra ball when a box is destroyed in Ball Frenzy or shooting balls in Spin Master.

For the graphics, we have a set of art objects, floors and skybox specifically designed for these skill levels. The number of objects in this style is far smaller than those in the two story styles (industrial and neon-city) and this makes it easier to quickly setup the design of a skill level.

The main challenge for us as designers is to come up with a good idea for a skill level. But we do find that once you pop, you can’t stop. We are working on a small tower defense skill level, a shuffleboard skill level and Peter has promised to make a race skill level for years now. Furthermore, once our special powerups are released, these ingredients make for even more interesting skill levels.

Survive as long as you can, but the walls will Caromble! ehh... crumble :)

Wall Safety skill level

So I think most time goes into designing the level in your head and once you start building it should be able to finish it in 16 hours after which the other team members will play and give feedback, resulting perhaps in another 4 hours of work.

So that would be 3 days of work (and thus about 3 weeks real time) in the most optimistic scenario.

I hope this has given you some insight in our development process. This blog only tackles the level creation parts, but we are also optimizing our engine, fixing bugs, adding new visual effect, maintaining our steam page, facebook and blog, send an occasional tweet and try and find some spare time to contact press. To do all of this we have only one day a week, so this might explain a bit why the development of Caromble! is taking so long (over 6 years already). But please, bear with us. We’re getting there and we think it’s gonna be more awesome every week. If you want to be part of this process, consider participating in our Early Access. We’d appreciate it!

Last Friday we have finished our implementation for controller/gamepad support. This means that in the next big content update of Caromble!, you can choose your favourite input device out of the big three:

You can now control the paddle with gamepad, mouse or keyboard! More input devices are on their way...

We will do a beta of our first big content update next week on Steam Early Access, and if that won’t bring up any major issues, we will release shortly after. Get ready for Chapter 2, full of explosions, introducing the 1st special powerup (!), two skill levels and support for your favourite gamepad.

Controlling the paddle is the main type of interaction in the game, so this should feel as smooth as that actor in a hot spice commercial. Therefore, during the implementation of gamepad-support, we also tweaked the mouse and keyboard controls to make those better. The implementations of these three input devices are fundamentally different and I would like to use this blog post to explain these different methods and tell you how we achieved the best result for optimal control of your paddle.

In the following snippets we have a few parameters:

  • deltatimethe time between the current and the previous frame; to make the controls framerate-independent.
  • paddleSpeed: this parameter is necessary because of the way we set the paddle position in code. Each level has a left- and right-end position of the paddle. The movement of the paddle can be between these two extremes. A value [0, 1] describes the position of the paddle with 0 as the left-end and 1 as the right-end. If our input devices would work on this value directly, then the paddle speed would be depending on the distance between the two end-point. Instead, we want the speed to be described in terms of paddle-size, which is what you would expect. The value of paddleSpeed is calculated based on the distance of the end-points and the paddle-size and is thus used to make sure that we can control the paddle in terms of ‘move 0.2 * paddle-sizes to the left’, instead of ‘move 0.2 of the distance between the end-point positions of the paddle’.
  • movement: the result of the functions on the input data and is applied directly onto the paddle to map its position to [0, 1].
  • curSpeed: this variable keeps track of the speed of the paddle when using the keyboard or d-pad. We update curSpeed every frame, so it needs to be stored.

I like mouse control the mostThe mouse has the most straightforward implementation. We want the displacement of the mouse to be mapped linearly to the displacement of the paddle, resulting in its new position.  All that is applied to this displacement is a scaling factor. This gives a feeling of direct control. You have the freedom to move the paddle over large distances quickly or apply small displacements in a very precise manner. Here is the code:

float moveX = mouse.getDeltaPositionNormalized().x;
movement = (float) (-16.0 * paddleSpeed * moveX * deltatime);

Because the input for the mouse is provided in pixels, we use getDeltaPositionNormalized() to normalize for the screen size. You want to have the same behaviour in a 1280 x 720 as on a 1920 x 1280 screen. This function also applies the mouseSensitivity setting that can be set by the player.The biggest advantage of the gamepad is that you can really 'hang' on the couch with it. I love hanging...The main difference of the analog stick on a gamepad with the mouse is that it has a limited range of positions. It can be tilted to the left and to the right in a continuous matter, which will produce an input value of [-1, 1]. How can we use that to control the paddle? If we would map this value directly to the position of the paddle between its left- and right-end, the resulting speed and behaviour of the paddle would differ per level (some levels are very wide, like a platformer game; #waitforcaromblechapter3). This is not what we want, so instead of using the analog stick value to set the paddle´s position, we will use it to set the paddle´s speed. Let’s imagine moving the paddle to the right. Keeping the analog stick at 0 will result in a speed of 0. When we put it completely to the right, corresponding to a value of 1, we want a speed of, let´s say, x, which is normalized as described before (dependent on the paddle-size and not the distance between the ends).  Now we can achieve all values between [0, 1] to give the paddle the speed we want, which also gives us a lot of control. Our first idea was to map [0, 1] linearly to [0, x], but as it turned out, it feels nicer if we apply an exponential mapping. So a value of 0.5 does not map to 0.5*x, but more like something as 0.25*x. This allows to have precise control of the paddle when you move the analog stick only a little.

There are still a few more things we have to take into account. Unfortunately, if you release the analog stick, it does not return 0 as its value. Sometimes it ‘sticks’ a little, which can even result in values around 0.2 when the analog stick isn’t touched. To fix this, we introduce a deadzone. We choose a deadzone of [-0.2, 0.2], which means that all values within this range are mapped to 0. In this context we want a value of 0.2 to correspond with 0 as well, so we remap [0.2, 1] -> [0, 1] and [-1, -0.2] to [-1, 0].

Even after introducing the deadzone, we were still not satisfied with the achieved precision when we wanted to move the paddle only a little. In a brick breaker game like Caromble!, this precision is crucial, so we have added something that we call precision mode. When the right shoulder button is hold down or the right trigger is pressed over halfway, we enter precision mode. In precision mode we scale the applied speed with a value of 0.35. Here is the code:

// amplitude is in the range of [-1, 1] 
float amplitude = actionList.getAction("AnalogStickHorizontal").getValue();
// precision mode if one of the right triggers is pressed
float precisionScaler = 1f;
if (actionList.hasAction("PaddleMoveFocus") || actionList.getAction("PaddleMoveFocusAxis").getValue() > 0.5)
	precisionScaler = 0.35f;

curSpeed = Math.signum(amplitude) * Math.pow(amplitude, 2.5) * 3 * paddleSpeed * precisionScaler;
movement = (float) (curSpeed * deltatime);

The introduction of an extra key for precise control works, somewhat to our surprise, great! When you need to move the paddle over a long distance you put the analog stick in its extreme. When you are close to your desired position you hold the precision button and you can place the paddle exactly where you want. Awesome stuff.
There are so many buttons on the keyboard that are not used with Caromble!. Maybe that's reason enough to find a prpose for the 'any' key
And then we have the keyboard; a bit old fashioned, but still a favourite to some players. This is a fundamentally different input device than the mouse and the analog stick. Where with the other two you have a whole range of input values, the keyboard provides… just two. One key to move to the left and one that moves your paddle to the right. It makes sense to map these keys to a certain paddle speed, but we would like to see the paddle move smoothly. More precise, we would like the speed of the paddle to be differentiable, meaning that it doesn’t ‘skip’ values. This is a property that the mouse and analog stick implementation also possess. We can achieve that by letting the two keys correspond to an acceleration of the paddle, which is applied until a maximum speed is reached. This means that the paddle starts moving slow, but while you hold down a key, its speed increases until a set maximum. As with the analog stick, we won’t increase the speed linearly, but exponentially. This provides more control when we hold the left or right key for a short time, which I use in a way I’d like to call ‘tap-tap-super-tap‘. This puts the paddle in the exact position I desire. When I release the keyboard key, the paddle decelerates until its speed is 0.
I mentioned the differentiability of the paddle-speed, but I lied a little there. When we switch from the left key on the keyboard to the right key, we want to move the other way immediately. At this moment we do not decelerate nicely, but set the speed to 0 and accelerate in the other direction.
Also, because we liked the precision mode so much in the gamepad implementation, we use the Left Alt key on the keyboard to enter precision mode. Here is the code:

float maxSpeed = paddleSpeed;
float acc = 20 * maxSpeed;
boolean hasMoved = false;
float factor = (float) Math.pow(Math.max(0, 1 - Math.abs(curSpeed) / maxSpeed), 2);
if (actionList.isDown(paddleLeft) && !actionList.isDown(paddleRight))
      if (curSpeed < 0) 
            curSpeed = 0; 
      curSpeed += factor * acc * deltatime; 
      hasMoved = true; 

if (actionList.isDown(paddleRight) && !actionList.isDown(paddleLeft)) 
     if (curSpeed > 0)
           curSpeed = 0;
      curSpeed -= factor * acc * deltatime;
      hasMoved = true;
float focusScaler = 1f;
if (actionList.hasAction("PaddleMoveFocus") || actionList.getAction("PaddleMoveFocusAxis").getValue() < -0.5))
      focusScaler = 0.5f;

curSpeed *= focusScaler;
if (!hasMoved)
      // decelerate to 0
      curSpeed *= Math.max(0, 1 - 20 * deltatime);

movement += (float) (curSpeed * deltatime);

Of these three input devices I personally like the mouse the most. I feel that it gives me the best control of the paddle. This opinion is not purely subjective; science supports it! Humans tend to find it easier to interact with position-control than with velocity-control. Furthermore, humans like velocity-control more than acceleration-control.

I hope this has blog given you some insight in how we approach the issue of paddle control in Caromble!. We are curious what you think of our gamepad implementation and hope you find it as smooth as James Bond. We have tested our code on these three gamepads, so we hope you have one of these three 😉

The left one is so old! It was also very sticky, but we don't know why...

Besides these three described main means of control, we are also working on a fourth input method: Intel RealSense. We will address this in a future blog post, but we can’t tell you when or if we will actually support this in Caromble! . The Steam controller is on our wish list as well. Hopefully we can get our hands on one soon!

Fun by Metrics

Fun! That’s what most games are meant for. Some people argue it’s the meaning of life. Like in the book Homo Ludens (‘Playing Man’) by Johan Huizing. At least, that’s my over-generalized conclusion of a book that I have yet to read.. It discusses the “importance of the play element of culture and society”. Hence, the importance of playing Caromble!.

Our goal with Caromble! is to create a fun game. One of the aspects of creating a fun game is that it feels immersive. This requires a fine balance between boredom and frustration; or as we like to call it: the ‘Fun Flow’. The zone where you forget about time and yourself while having fun. One of the major slowdowns when creating Caromble! is to debug something and get side-tracked by playing the game. Yes, we as developers think to know the game is fun! Unfortunately, we aren’t important.


Metrico – A game where players themselves can have fun with metrics!

We are humble game developers serving the people’s need to have fun. You, the people, are easily bored and/or frustrated. I don’t mean to offend, but that’s the conclusion of many game design books. So, we want to avoid boredom and frustration by doing our very best in balancing the game. One way to balance a game is to collect game metrics, identify unbalanced areas of a game, and… fix them!

How do we identify these unbalanced areas? By asking the right question. However, we are still arguing about what data to collect. But it will certainly contain data like:

  • How much time does it take to finish a level?
  • How many balls are lost?
  • How many times is screen X shown.

How do we collect these metrics? Unfortunately, it seems that the Steam SDK is not designed for this. So, we searched for another, easy way of tracking data and found Craig Timpany’s article from 2009 on how to collect game statics using Google Analytics. (As a sidenote he happens to have been involved with another brick-breaker – Shatter – as stated on his so-called ludography).

Game analytics dashboard

All Work All Play – Google Analytics dashboard with game metrics by Wolfgang Graebner

Another article by Wolfgang Graebner (2014) says this about using Google Analytics:

“It’s reliable, easy to set up, tracks common metrics such as views & hosts, supports custom metrics, and the data can be shared with others. That’s basically everything [you] need from an analytics service.”. It shows a nice example of collected data:

Bingo! That’s what we need. Let’s collect some data and add more fun!

Creating a living and breathing game world

Charging as a core gameplay mechanic

Caromble! is a brick breaker game. However, I dare to say it is not JUST a brick breaker game. Our aim is to create an interesting and engaging game world, where the core gameplay mechanic is that of a brick breaker.
Gameplay wise, there are several things in Caromble! which you would probably not expect in a brick breaker game. The 3D elements in the game serve an actual purpose and are an integrated part of the level designs and highly influence the gameplay. Our dynamic subareas within the levels add an exploratory factor to the game. Furthermore, the charge mechanic and some special, fresh new powerups add an extra dimension to the brick breaker genre.

Besides these gameplay mechanics, we also focussed a lot on creating an interesting game world. For some players, playing a game is purely about the abstract game mechanic. Other players like to be emerged in a fictional world, where their fantasy can make even bigger and greater stories than the game designers intended. To help you create an interesting game world, it is good to have established a backstory. With this, I do not mean Hideo Kojima-like cutscenes, but a small consistent story in the back of your head. This can be very useful as a game designer. In a next blog I want to tell you more about Caromble!‘s backstory and why I believe it is useful to have one. For now, I just want to say that having only a small hint of a story can already give you many ideas for creating or improving the world your game is ‘living’ in. This can help you think of objects that are within and outside the game world, and can suddenly fill in the gaps if you’re struggling with designing a boss fight. Context leads to ideas.

The world of Caromble! feels alive and I think that the dynamic elements in the game are a big part of how this is achieved. We have 3 kinds of dynamic elements in the game:

– Essential dynamic elements within the gameplay. These can require timing and sometimes bring puzzle elements to the gameplay. A level cannot be completed without using it.

A dynamic ramp that is essential for the gameplay

– Non-essential dynamic elements within the gameplay. These can be moving obstacles that influence the physics world and can have unexpected big impacts. Remember, chain reactions in physics == fun

A none essential car in the level, just for fun

Lastly, and in my opinion a very interesting one:

– Non-essential dynamic elements outside of the gameplay. Often placed in the background or between subareas of a level.

Barrels in the background for an Industrial atmosphere

Moving elements in the menu that are non-interactive

This last one does not influence the gameplay whatsoever, but I believe that these elements are a major ingredient for making a living, breathing game world. I think that when a player sees objects that are somewhat consistent with the created context (made possible by a (small) backstory), they unconsciously make associations and make a (bigger) story in their head. In their self created/associated world, the actions of the player, which in Caromble! is that of a ‘simple’ brick breaker mechanic, can have a bigger meaning in that world. You’re not just jumping on mushrooms. No, you are saving the princess of mushroom kingdom.

A train on the side of a level, which can’t be hit by the ball

All of a sudden the player has a role in a fictive world, and as a game designer you should aim to give as many possibilities for the player to make associations within that world. This in turn makes it a richer and livelier world. I think that dynamic elements, even in the background of the game, helps you achieve that.


Only two weeks ago, we have changed the movement of our game’s antagonist, such that it always follows/looks at the paddle. Immediately I experienced more of a threat from our scary red bad guy, and I think the game world has become livelier because of this change, with only little effort. What do you think:

It’s always watching you!

Brick breaker games are often referred to as breakout clones. But just as not every first person shooter is called a wolfenstein clone, perhaps Caromble! can help to establish an actual genre. At least we hope that the world we have created for Caromble! helps in engaging many players to enjoy the brick breaker mechanic.

The barrels actually fall into the level



Level Iterations

In our previous posts we talked a lot about juice. But in those posts, we mainly focused on main gameplay events and objects. As you might know, we more or less have all our levels finished. The gameplay stands, but the levels are all pretty rough around the edges.
We’re currently iterating over the first few levels. With each iteration, the gameplay is tweaked a little more and the graphics and lighting are made more coherent.

To give a few examples, check out the screenshots:

javaw 2014-10-07 21-47-16-07 javaw 2014-10-07 21-24-16-84

javaw 2014-10-07 21-32-11-52 javaw 2014-10-07 22-00-20-32

PS: We know we’ve been a bit silent on the blog lately… but believe me, it’s the calm before the storm!

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.


Interviews – Part 1

Crimson Owl Studios is a very particular studio. In fact, there is no physical studio at all. Every Friday all team members take a day of unpaid leave and gather at their kitchen tables scattered throughout Utrecht and Amsterdam.

We have talked about all aspects of the development of Caromble! on this blog, but we never had the team talk for themselves.

The coming weeks we’ll have a series of short interviews on this blog where all team members will be given a chance to talk about game development, Caromble! and how the last couple of years have been.

Raymond's table

Developing Caromble! at Raymond’s table. Left to right: Peter, Pascal, Raymond (interviewee), Thomas D (interviewer).

So let the first interview begin!

Who are you?

Wow, that’s a very philosophical question to begin with! I like philosophy. Of course it’s impossible to describe in a few words who one truly is. But let’s try. I am one of the creators of Caromble!. My name is Raymond Bijl and I like video games.

What is your favorite game?

It’s hard to name only one game. I can really immerse myself in a fantasy themed game with a good story. In that genre Baldur’s Gate is one of the best. Next to these comprehensive role-playing games I can truly enjoy arcade or puzzle games created by fellow indie developers. From a game design perspective I can wonder at the elegance of these apparently simple games and then think ‘I would have loved to have made that one!’. World of Goo is a great example of this.

Let’s talk about work. What are the consequences of splitting your time 80 / 20 between a regular paid job and creating Caromble!?

For a lot of game studios there is no guarantee for success and no room for failures. For me, a regular job means guaranteed income and that’s a certainty I really appreciate. Especially when I notice that I have all kinds of financial responsibilities every month. Anyhow, it means that creating Caromble! goes a lot slower in comparison to the development speed we would have if we were a full time game studio. When we say we are working on this game for four years, we mean one day a week for four years, and those days go by fast.

How about the people around you. Do they see you as somebody with two jobs?

Most see the ‘creating games’ part as one of my hobbies, but maybe that’s because how I first approached it myself. My personal goal was to learn to create games by creating games, but not necessarily in a professional way. However, the things that I do, I want to do them well. And I soon realized I could not approach this project as a hobby. Creating a good game means you’ll have to work hard and do that professionally. Of course, we are also friends, so we have fun and drink beers, but most of the time we just work hard. Creating games is not always as romantic as I would like to think it is!

Keeping it romantic. What is the element of Caromble! that you are most proud of?

I would not name one element, but the whole game. I think it’s really nice to see all the pieces fall together and to realize that we are creating a full-blown game that looks, sounds and feels like one of the real games I have always wondered at how they were created.

A very open and last question. What if?

I would really like to see Caromble! succeed and I believe it has the ingredients to do so! I think Caromble! will breathe new life in the brick-breaking genre. This genre is based on a simple concept – keep the ball in play and break stuff – but it has always proven to be fun and addictive. I hope that other players will enjoy Caromble! as much as I do!