Caromble! is a fresh brick-breaking game in a 3D, physics-based dystopic world with an unique art-style and epic gameplay features you wouldn’t expect in a brick breaker.
It is created by Crimson Owl Studios, a small part time indie team that comes together every Friday to develop their first game. Caromble! will be released in 2015 and will be available on PC, Mac & Linux.

Game Development Blog:

Caromble! Cover Art Is Coming

This will be an important part of our Greenlight launch, so I have to get this right. Here are some first sketches I did for the cover art – of which I will use elements for the various images in the Steam store.

Quite a lot of elements to get in there. I have the paddle shooting the ball straight at some objects. Lots of explosions of course. And the nemesis wailing about.

In a second sketch I tried to highlight the specific game elements more: The ball bounces around, and aims finally at the enemy as central figure. The scale comes across a bit better – and I think it’s overall nicer to look at.

More work is to be done on these concepts – I’ll update next week with the progress.

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!

Sweating the Small Stuff

As we’re in the final mile of the project, there are quite a lot of little details that need polishing. Not the most fun work – but gotta be done. Girders and metal bars are used all over the game, and used still some early test textures without final effects like normal maps. So now I redid all of them, fixed all errors – and brushed them up to the style of the other objects. That will also help to make the game look consistent.

girders 3d

Supports and girders

And menu stuff – little navigation arrows and medals for the achievements.

Menu Icons

More Icons – including achievement medals

And the endboss you will meet every chapter got updated – we’re still tweaking the gameplay. Beware: He can now shoot back!

alien mesh

The “alien” – got a new home.. and weapons.

Caromble!: The Playtest

Dear Caromble! followers,

Yesterday we made another big step towards the release of Caromble!. We have held an extensive playtest session. The ingredients were:

  • 13 friends from inner and suburban circles
  • Several story levels
  • A few skill levels
  • 5 PC’s and 2 laptops
  • Coffee, crisps and chocolate
  • Observation and a survey that should help us determine what we want to change, balance or add to the game before the release

The developers, nervous for the playtest.

After 6 hours we collected all data files, had some drinks, played some PES2015 (sorry FIFA fans) and talked with the playtesters about their first encounter with Caromble!; the game with which we aim to create the most epic brick-breaker game in the history of the universe.

We are now analyzing all our notes and processing the surveys, but here are already some of the results:

  • Many playtesters laughed when they catched the Pixelate power-down for the first time
  • 50% of the players destroyed the boss in their first or second attempt
  • No crash of the game occurred all day long (what we are quite proud of, as it is running in our own game-engine)
  • We encountered one gameplay-breaking bug:

    This should NOT happen!

  • Unfortunately 4 playtesters could not come (snowy reasons), one of them being a woman. Now we only had male playtesters
  • 3 bags of crisps were eaten
  • One player wore a Fez shirt, which is very cool:

    Thank you very much playtesters! You were awesome and Caromblecious!

  • One player thought that one of our gameobjects looked like a giant red dildo. Not sure whether we should address this…

We have had a great time and so much useful feedback. We want to thank all playtesters once more. We were very happy with your effort, feedback and joyful faces. Thank you!

Happy developers after a successful playtest day of Caromble!

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!

Interviews – Part 2

Part two of our interview series where the Caromble! developers interview each other. This time our interviewee is Thomas Duindam.

Thomas Duindam drinking a beer at a festival

Thomas drinking beer at a festival

Thomas, when will you release Caromble!?

2014-ish. We release the game when we decide it’s finished.

How many times has this question been asked to you?

It’s a logical question to ask. I wonder about it myself. This year we will at least release something! We will open up and allow for early access to our game.

Let’s ask what should have been the first question: Who are you?

I’m one of the developers of Caromble!. I am a software engineer in the medical field by day, and a game developer by night – and most weekends. Sometimes I drink beer at a music festival.

What is your favourite game?

Monkey Island. I enjoy games with a strong narrative and which are able to immerse me into another world. It impresses me more than abstract skill games.

That sounds a bit like the opposite of Caromble!

Yes it does, but I don’t think that’s a problem. Opposed to my previous anwer, I also game to relax instead of desiring to have a new experience in another world. I relax the most with games that have familiar mechanics. It’s like deciding to watch an important art-house movie or a easy to digest blockbuster. When I want to relax I choose the latter. When I want to relax and play a video game, Caromble! will be a very good choice.

That sounds like fun! I want to play Caromble! How would you describe a day in the life of a Caromble! developer?

Wake up. Drink coffee. Commute to this week’s developer studio / kitchen table. Drink some more coffee.

This is followed by:
– 25% coding, mostly fixing bugs.
– 25% discussions about Caromble! At the time mostly about project management.
– 25% lunch.
– Another 25% coding.

Sometimes the Caromble! workday ends here. Other times the day continues with:
– 25% playing games and drinking beer.
– 25% coding, mostly creating bugs.

You mentioned discussing about the game. What was the most difficult decision during this project?

I remember the infamous ‘Feature Creep Dooms Day’. It was a day’s length discussion about the scope of Caromble!. We slaughtered many feature ideas. At the moment I think the scope is still too big. 25% of the current scope would also suffice for a really nice game. Three lessons learned: limit your scope, limit your scope, limit your scope.

Could you name some ‘slaughtered’ ideas?

Portals, which was the hardest to let go off. Switching gravity’s direction. Zombies. Multiplayer.

Sounds like enough ideas for a Caromble! sequel. You are developing Caromble! for quite some time now. What keeps you going?

I like the game so far and I am very curious about what the final version will be like!

What is the element of Caromble! that you are most proud of?

All technical stuff that’s written in Java. A lot of people said it couldn’t been done! But we did!

Caromble! in Paris

paris_5paris_3It’s been a long time. A very long time indeed. But we are still here, alive and kicking. We’ve had some hectic weeks, busy with holiday trips, finding new houses and unfortunately some hospital visits. But we are well!

I have just returned from a trip to Paris and Caromble! seemed to be a very big thing there, as you can see in the photos throughout this blog post.

monarombleAt the moment, Peter is probably chilling in a pool with a caipirinha and his girlfriend, but the rest is back in Holland to push Caromble! to the next phase. We will not yet go into specifics about what that phase is, but expect something to happen soon; something involving the fact that Caromble! is greenlit on Steam and yourself collapsing some structures in the Caromble! world.

Because we are limited in our time to work on the game, as we still have our ‘normal’ jobs 4 days in a week, and writing blog posts steals some of this precious time, we have decided that for the moment we will be writing blogposts every two weeks. We will still do a #screenshotsaturday weekly, so check that out if you want to see more of Caromble!.

Making Sparks with Caromble! Engine

A couple of weeks ago Thomas Schmall posted an article about the new particle systems he was working on. I finally got around implementing the last system, the spark particles.

I would like to show you two ways we can use this particle system, and give a brief insight in how the Caromble! Editor can be used to place and tweak it.

The first way of using the system is to emulate sparks generated by something like welding. They spray out in a coherent beam.


Timer trigger that triggers every 2-5 seconds and send the trigger to a particle system

This effect works best if the sparks aren’t spawned all the time, so I’ve used a timer to spawn a spray of  particles every couple of seconds. In the screenshot to the right you see this timer. I’ve set it to send an event every 2-5 seconds.

Now we just need to place the actual spark particle system itself, and fiddle with the parameters a bit to get the effect we want.

I’ve included a screenshot of the relevant bit of the editor screen below. Five properties are important for this effect.

First of, it is important to set the release rate (very) high. The release rate is the amount of particles we’ll spawn per second, and since we’ll only spawn particles every once in a while, we need to spawn a lot of them in this small period of time.

A less obvious parameter is the “ContinuousParticles” property, which is ticked of to indicate that we’ll provide external triggers for the particle system.

The important settings for the spark particle system.

Next to that is the “PulseDuration”, which determines how long we’ll spawn particles after every trigger.

The collision object property determines which objects the particles will bounce of. For performance reasons we won’t bother the physics engine with all particles, so you’ll have to provide a list of objects with which the sparks can interact.

Finally the “MaxAngleRadian” property determines in what direction the particles will be spawned. Since this is meant to be a coherent spray, I’ve set the angle fairly low.

Alternatively the spark particle system can be used in a more continuous way, as shown below.

To use the sparks in this way, you don’t need an external trigger, the particles will continuously spawn, and Perlin noise is used to control the release rate of the particles.

Again I’ve highlighted some important properties for this system.

The upper triplet of properties control the release rate animation in a somewhat mysterious manner. The “FractionOff” number corresponds to the fraction of time that there should be very little particles (the lower bound of the release rate). The “ReleaseRateAnimationSpeed” determines how fast the animation over the release rate is running.

The other five highlighted properties determine the way the particles look. The “MaxAngle” is much higher than it was in the beam example, it now corresponds to a halve sphere. The “StartSpeed” and the “Gravity” property together control how the particles will act after they have been released. They have to be tweaked together to achieve the desired effect.

Finally the “MinLifeTime” and “MaxLifeTime” parameters dictate how long the individual sparks will exist on this planet.

With that I’ll conclude this post. I was hoping to provide a small peek into the daily live of us Caromble! developers, and about the tools we have made to work with. We might release the editor with the game (or at a later stage) so you might get a chance to tinker with it too.

Also, if you have any questions or suggestions, please don’t hesitate to ask!

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.