Category: Gameplay

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.

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!

In our first Early Access release there are two skill levels to unlock. The first is Sharphooter, for which three medals are needed. Have you unlocked it yet? Can you beat Peter’s highscore:

Once you have defeated the Chapter 1 boss, Two teaser levels for Chapter 2 and 3 are unlocked as well. Chapter 3 introduces multipaddles and we hope you are excited for them. What do you think of our crazy-pazy work-in-progress shader effect:

We are currently working hard on finishing Chapter 2. Check the pinned discussion on Steam to keep track of our progress. We are aiming to release Chapter 2 before the end of October, but yeah… part-time indies 😛

For the Dutch fans, or any happy travelers; in 2.5 weeks, from 9-11 October, we will be attending FirstLook in Jaarbeurs Utrecht. Here you can play Caromble! and have a sneak peek at our Chapter 2 levels! Hopefully we see you there!