Tag Archive: Screenshots

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!

Rocking Steam – and the Indiedevelopment Show!

A very happy update from the Greenlight front!

Greenlight top 100

Top 100 – whee!

If you didn’t vote for us yet, please take the second to click yes on Greenlight. We sure want to stay up there until Valve waves the the top 100 top 75 through.

We’re nearly there! It is not quite clear how much it means at the bottom-line (meaning for sales), especially since Valve seems to wave through a lot of titles. But we always had this as an important milestone for us. So: yay!

More positive news come from showing Caromble! last week at the Indiedevelopment event. We’ve made the list of Ten Best Games on the Dutch site gamer.nl. Other pages list us also in their picks – calling Caromble a beautiful game with addictive gameplay (translated the Dutch from gamecensor.nl).

To top this all off, here are some fresh screenshots of two levels that are the closest to the final look for the level design.

High Dynamic Range Rendering

Now that we are getting closer and closer to an actual release of Caromble!, we have to put a lock on new graphics effects and big engine changes. Since we’d got motion blur up and running, there was one major annoyance left in how we rendered the images to screen: It was very hard (near impossible) to configure how bright or dark the final image would become. We had a basic bloom render effect in place but we had very little control over how it behaved. It basically turned our ball into an huge supernova like inferno from time to time, which made the rest of the image look really dark in contrast.

One of our main issues with rendering was that the ball was often too bright

One of our main issues with rendering was that the ball was often too bright

Enter high dynamic range (HDR) rendering. Photo enthusiasts create HDR images by combining multiple pictures (in LDR, low dynamic range) of the same scene taken under different exposures. This creates surreal images were nothing is too bright while everything remains visible. In game programming it works just the other way around. You create HDR images which allows you to regenerate the LDR images under different exposures.
Previously, all our light values in an image where clamped between 0 and 1, causing us to lose all lighting details around places where the image became brighter. With HDR, we no longer clamp the image values, giving us the full (high dynamic) range.

An old screenshot showing problems with over-exposure

An old screenshot illustrating problems with over-exposure

Once we got a HDR rendered image, we still have a few little problems. Of course, we do not want our game to look as surreal as the previous photos. Neither do lcd displays used nowadays have the capacity to produce lumen as bright as we got in our freshly rendered HDR image.
The first problem is solved by mapping the HDR image to a LDR image (low dynamic range). Basically, we  recreate those LDR images a camera would make but under the exact exposure we chose. We do this by defining a mapping function that maps 0-Infinity back to the LDR 0-1 range of our choosing such that we can display it on a monitor.
Anything below our LDR range becomes pure black. Anything above the LDR range should become incredibly bright.
So how do we produce these bright colors if monitors wont help us. We simply simulate it by enabling bloom for those values, letting the bright areas spread in their neighborhood. This finally gives us fine control over the brightness of our rendered image!


An HDR image mapped to LDR images with different exposures.

Heroic efforts

Often, we write these blog post to brag about our amazing accomplishments, but sometimes, just sometimes, game programming can be just that: …programming. This week there are no heroic successes, no courageous stories, no valiant efforts or exaggerated achievements. No this week it was just work.

So what does a ‘normal’ Friday of working on Caromble! looks like? Well, we’re rewriting how we save our assets in the build script, fixing issues that are causing micro stutters in the menu and explosions, improving gameplay for levels in the last chapter, working on the new paddle and alien models (yay!),  building the menu, fixing and adding sounds, celebrating Sinterklaas, buying a new bicycle etc, etc. I guess nobody can accuse us of being lazy on Fridays. But as you can see, we need more Fridays in a week!

So what to do with lack of content. How do we get away with this? Screenshot!


…and back to work; who needs sleep anyways?



Graphics Effects

Since most of us working on Caromble! are programmers, it shouldn’t come as a surprise that we wrote our own game engine for the game.
In the animated image below we show a few of the effects we apply to Caromble! to get it to look the way it does.

Graphics Effects

Click to enlarge

In the first of the images you see the scene with no texturing and only the main light applied, in the next image you see the same scene with secondary lights and the specular map enabled.

After that, we add bump mapping, basic colors, shadows, bloom & depth of field, ambient occlusion, reflections and soft particles.

On low end machines, you might have to disable some of these effects to get to run the game with decent speed. But on high end machines, we still got some room to spare. Maybe, very maybe, we just might add motion blur to get the game to look even better….

Levels in the new theme

A few weeks ago, our artist Thomas S already showed some of the newly created assets for the new theme: Metropolitan/Commercial style. We have been working hard to create some levels with these and I got official permission to give a sneak peek:

A train that rides more reliably than ours in Utrecht Doesn't the Alien boss look scary!?

We hope you like it! It’s not only the graphics style that is different in this theme. There will be some new gameplay features that could lift you right up:)

Also nice: this week the gaming news website Gamingbolt published a piece we wrote in their section ”Developer journal’. You can read it here. We hope to have some more journals there soon.

Oh, and if you accidentally find yourself  in Amsterdam tomorrow evening, you should go to Pakhuis de Zwijger. There will be another Control Gamelab. This time it is on making Game Trailers. We hope to learn enough to make our upcoming trailer super awesome! Expect it on youtube soon, of course with moving footage of our new graphics theme.


Creating Challenging Challenges

Nowadays, games cannot be taken seriously without having unlockable challenge levels. Ok, it’s probably not that extreme, but it can be a great addition to your game for several reasons. It can present extra content for hardcore gamers that want to unlock everything, encouraging multiple playthroughs. It can also help to engage players and spice up the gaming experience by deviating from the core gameplay. But for us there is an extra reason…

What all game developers probably recognize, is that you can think of too many cool features for your game. When we were in the beginning (read: ‘more than a year later’) of the development of Caromble!, we realized that we had too many features planned for the game. Almost every new level would introduce a new gameplay feature. Finally we became smart enough and decided to choose a list of features to implement and just leave the rest be (I miss you so, oh ‘gravity switch’ and ‘teleporter’). This turned out to be a good decision (still I’ll never forget you…). There is so much more we can still do with our current set of features, that I believe we could make a hundred more levels with these, without becoming repetitive. It is a pity though, that some of the cool features we ‘invented’ are not in the game. But thank goodness we have some unlockable challenge levels!

Caromble! features 24 story driven levels, these are at the heart of what Caromble! is. When certain targets are met in the story, a challenge level is unlocked. A challenge level is a small simple area, in which the player gets one specific task. These levels can be crazy strange and each one stands on itself. No rules, just fun! This allows us to introduce a new feature only for that level. And why not, everything is possible in the HAVEFUN (Hypnotically Abstract Virtual Environment For Unconventional Needs (name suggestion pending)); the simulation room in the mothership designed for training purposes (story pending).

The tasks in the challenge levels range from: ‘hit as many blocks in 1 minute’ to ‘survive as long as you can with a single ball’. These challenge levels provide small ‘snacks’ (as Mark Overmars (professor and creator of Game Maker) once called them in one of his lectures on game design) that allow for a quick play, but are very entertaining for the thrill of beating the highscore. Some examples of ‘snack’ games that are very addictive, partly because of the highscore aspect, are: Jetpack Joyride, Super Hexagon, Super Cratebox and (why was I addicted to this?) Bookworm Deluxe. If the challenge levels in Caromble! provide some of the fun and addictiveness that these games have, I’ll be very happy.

As challenge levels are not part of the ‘core’ Caromble! experience, we work on them in our spare spare time (first spare time is reserved for core Caromble! tasks). Last week I had some of this precious time and created 2 challenge level prototypes. For now I call them WallSafety and BallFrenzy.

In WallSafety the player gets one ball, and one ball only, and is burdened with the task of surviving for as long as possible. The score is given by the seconds survived. The catch? The level sides are made of blocks that are destroyed by hitting it with the ball 1-3 times. Behind these blocks awaits nothing more than emptiness, thus death:



In BallFrenzy the task is to have as many balls in play after 45 seconds. Each block that is destroyed creates another ball:


These challenge levels provide a different gaming experience than the core gameplay and hopefully give Caromble! extra appeal. They are fun to create (because it is so simple) and fun to play (because it is so simple). The objective and scoring mechanic are very transparent and perhaps this simplicity makes it so fun. Games have become much more complex over the years and I think that sometimes we long for the simple gameplay of the old days. In that way, games are a nice analogy for life.


Making waves (or ripples)

Last week was a big week for Caromble!. For the first time since last October we would be showing the game to an audience. And not just any audience. Caromble! would leave the Netherlands for the first time, and travel all the way to EToo London.

Doesn't this make us look like very real and serious game developers?

Doesn’t this make us look like very real and serious game developers?

It wasn’t  just showing the game though, Pascal and me were set to make our first ever appearance in a live stream. So yes, there were some nerves, but all went well. I always enjoy to be able to explain something that I’m passionate about, so I enjoyed being interviewed together with Pascal about Caromble!.

The next day we hooked a laptop to a big TV and had people play Caromble! all day. Collecting feedback from players who never played the game before is very important,  and we definitely learned a thing or two about how we can make the game even more fun. It was also a great chance to meet a lot of very nice people from the UK gaming scene. All in all, I think the nicest thing about showing the game on such an event is just watching people play and enjoy it. Having people enjoy and play Caromble! is the whole reason we are making the game after all.

Showing the game and talking about it is much fun and very important, but most in all it got me all psyched and eager to work on Caromble! even more. So when I had nothing on my hands on Saturday, I figured it would be a great time to do some development.

One of the things I’ve been very eager to improve for quite a while, is what happens every time a ball hits a wall. Since Caromble! is a game, and games are supposed to be fun, all things in the game should be fun. Especially the things that happen all the time. Balls hit walls a lot in Caromble! (sorry I had to write that). We have been trying to make hitting the wall more fun for a while now. Adding nice particles helped a bit, but it never felt quite right.

Last Saturday I finally sat down and wrote a shader that should help. The effect is inspired by the helicopter crash from The Matrix. Or maybe just inspired by throwing a rock in a pond.  Where the ball collides with a wall, I move bits and pieces of the final rendered image back and forth to make it seem like the whole world is kind of rippling. Maybe I should stop talking and start showing. We are very curious about feedback you may have!!





Are both words that would give you a lot of points if you were allowed to use them in Scrabble. They are also (amongst many others) the building blocks of Caromble!.

For most of us, Caromble! has been the first real game we have ever worked on. The Caromble! editor is also the first level editor most of us have ever used. Since we are not using an off-the-shelf game engine, we are also not using an existing editor. We would have to create our own editor as we went along.

A screenshot of the editor. The red boxes are actors, which control the game-play  The lines indicate the relations between the objects. This system will make the camera switch position as the ball shoots over the ramp.

A screenshot of the editor. The red boxes are actors, which control the game-play The lines indicate the relations between the objects. This system will make the camera switch position as the ball shoots over the ramp.

The editor (as we call it) grew (and grows) along with the game. I would say in terms of age the editor is now in its puberty. To be more precise, the editor is in that stage of puberty where body parts lose track of each other and start growing at their own rate.

For a piece of software this means that some functionality is mature (like the stuff Raymond wrote about two weeks ago), and some other stuff not so much. It wasn’t until about a year ago that we added some sort of actor system, that allows you to control object interaction from within the Editor.

The late addition of such a core system lead to an explosion of all sorts of exotic actors with even more exotic names. Those in the title are firmly among my favorites.

To return to my analogy, puberty is a crucial phase of development, although it can be challenging at times. Because we needed the actors, this part grew a lot and right now is  a bit out of proportion. As the Editor ages and eventually will reach adulthood, everything will grow back into proportion.

Right now we are focused on creating game-play, and the editor doesn’t get all the attention it deserves. We’ll give it that attention before (and if) we release it (after we release the game).



Particle Improvements

soft_particlesSince the release of Caromble! is getting closer and closer, we spend more and more time juicing things up. Basically this means adding lots of special effects in places where a player expect feedback from the game. For example, showing sparks and smoke when the ball hits an object.
A lot of these effects are implemented through particle systems: you blend lots of 2D textures on top of each other to get a nice volumetric effect. This Friday we added some improvements in the rendering of particles.

The first problem you have with these flat particles is that you get creases where the particle intersects with the other scenery (see the ‘disabled’ image). Luckily, these artifacts are pretty easy to clean up. Since we already have the distance from every pixel towards the camera, we can easily fade the particles near the intersections. As you can see in the ‘enabled’ image, no artifacts!

The second issue we had is that some of our particles have very high velocities. A particle traveling with a high speed might cross the whole width of the computer screen within just a few rendered frames. This causes the particle movement to look choppy. But why does a ingame particle rendered at around 60fps looks choppy while a moving ball in a movie (typically 24fps) seems to move smooth? The answer is simple: Motion Blur.
For a good example about the importance of motion blur, check this website.

While I would love to add full scene motion blur, we would have to change too much of the rendering pipeline to get it to work (and it would strain slower hardware too much as well). Therefore, we chose to only fake motion blur for particles. Doing this is very easy, we simply stretch the particle in the direction it is moving in (screen space) and fade it depending on its speed. This will make the particle movement seem a lot smoother.