Tag Archive: Caromble!

Follow and read our updates on Steam!

Dearest Caromblers!

As you probaby already know, Caromble! is available on Steam Early Access! Instead of updating 2 blogs, we have decided to post all of our development updates on the Steam announcements. We hope to see you there!

We would like end to this blog site with an interview that Thomas D. and Raymond gave in London at PC Gamer Weekender. You can find us again in London next week at EGX Rezzed.

Enjoy this video and enjoy Caromble! 🙂


Hi fans, friends and random people who stumble upon this website accidentally,

This week we have finally released Chapter 2 onto Steam. Chapter 2 introduces Caromble!‘s first Arkatron with the special power: Focus! We are very proud of this milestone and hope you like the 4 new story levels and 2 skill levels as much as we do. We sent around a press release to announce this milestone and you can find that one below. We are currently working hard on finshing Chapter 3 and hope to release it soon! Let’s get ready to Caromble!

Greetings from the Crimson Owl Studios team

Caromble! Chapter 2 is now available on Steam Early Access!
View this email in your browser



The Brick Breaker over 6 years in development


Watch the Video
 ♫ This is Caromble!: A fresh new take on the brick break game! 


This is Caromble!

This is not just another brick breaker game. This is Caromble!: a fresh new take on the brick break game. Fight evil with physics-based destruction, puzzles, explosions, unlockable skill-levels, power-ups, mayhem, boss fights, more explosions, further puzzles, speedruns, superscore medals and much more… Visit us on Steam

Our story: One day. Every week. For over 6 years.

Our story is: high productivity, slow progress and being very persisting. Why we still work on it? Because we love it! We love to transform this retro genre into something exciting and new, hopefully you will love it too!

We are Crimson Owl Studios, a team of 5 one-day-a-week indie game developers – with regular jobs as software developers and a professional artist – working every Friday for over 6 years on Caromble!.

The Road to Gold

Last year we brought our development version of Caromble! to Steam Early Access. Chapter 2 is our first major update. The full release will contain six chapters; which will be released somewhere in 2016. However, our planning skills are not top-notch… If you want to know more about the reasoning for this Early Access adventure, please check out this absurd team video!

We hope to get as much feedback as possible in Early Access to create the brick breaker you’ve always dreamed of! Visit us on Steam

Thanks and best wishes,

Crimson Owl Studios
Caromble! Arkatron
Chapter 2 introduces Arkatron #1: Focus
Copyright © 2016 Crimson Owl Studios, All rights reserved.






Want to stop receiving these emails?

You can unsubscribe from this list

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!

Dear friends,
Remember my happy dance in the last blog post? Well, the time has finally arrived. We know you have been patient. We know you sometimes wondered whether Caromble! would ever see the light. But after more than 6 years of development, coming Friday on the 28 of August (yes… 2015 you clowns), Caromble! will be available on Steam Early Access.
As Friday is our one-day-a-week-indie-game-development-day, it only makes sense to do the Early Access release on a Friday. Otherwise, who would take us seriously right? Get in the mood already by checking out our new fresh trailer:

Also, if you are considering to participate in Caromble!’s Early Access, make sure you check out our Early Access Explanation Video, to find out whether Early Access is something for you:

We are thrilled to finally release Caromble! and we hope you are too!

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!