Please support us: Vote at Greenlight, so we can publish Caromble! on Steam. And tell your friends and every stranger you meet that you like the game! Facebook us if you like.

We're a small indie-team that comes together every Friday to develop our first game called Caromble! It's based on classic breakout, changed to be 3D in art and gameplay. Caromble! has realtime physics and more diverse challenges. Have you for instance ever played a side-scrolling breakout platformer level?

Game Development Blog:

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 Other pages list us also in their picks – calling Caromble a beautiful game with addictive gameplay (translated the Dutch from

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.

Indievelopment 2014


Yesterday (April the 7th) was Indievelopment in the Netherlands. A small conference in Utrecht with speakers like Paul Weir, Clemens Scott and Jonathan Blow. Apart from the great talks many dutch indie-games were showcased. You could play games like Metrico, Reus, Symmetrain and -of course- Caromble!
This wasn’t our first showcase, but it was the first time we had to build our own booth. This was our setup:
It was great to hear all positive feedback and see people really enjoy our game. We would like to thank Indievelopment and all people involved for a great day!


Sphere Evolution – Now in 3D!

In the last art posting here, I showed the concepting steps of the sphere. Here is the progress on the 3D side of things.

These were the meshes I created to choose from. It’s quite a lot – but it is of course in important asset of the game.

We chose number four – and the team basically said “works really well, don’t touch it anymore”. The visibility is much better – and the rolling motion shows more clearly.
There might be an option to use the other versions as addons or bonuses.

Here is a is the work as a still image to enjoy ;). In the later stages I might tweak it still, to add the outline look that all other assets have.

By now, there has been quite some evolution of the sphere throughout the development. Uh, makes me feel nostalgic.

shpere mesh

The progress of the sphere mesh.

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.

Interview with the Crimson Owl Team

The interview with our team is finally online! Check it out if you haven’t already:
gamekings_logo(It’s in Dutch)

Moving Pictures

Some weeks ago our beloved team member Pascal pitched his idea for our next trailer. He actually made a raw dummy trailer, which was very fun to watch! We unanimously decided to work out this idea and add a tiny bit of extra quality to it.

Since that moment we’ve set all gears in motion for our upcoming trailer. The story board is being drawn. Several unfinished art assets are being, erm, finished. And, our audiophiles from Nineyards are producing some vivid music.

We could of course show you the raw material, but that might spoil the experience of the final product. Unfortunately, it’ll be a little while before it’s finished. But when it does, we hope it’ll put a big smile on your face. Hopefully, it’ll also help to get those final Greenlight votes we so desperately want!

We are already looking forward to next year’s Oscar nominations.


For Caromble! last Friday was a sad day. Our kitchen table desk remained empty, and no work was done on the game. All our developers were working at their day jobs.

In contrast, last Wednesday was a great day. The whole team had swapped for Friday and we were at my place, because Dominique, Steljos and Jasper of Gamekings were visiting us for an interview.

Check out the next weekend to see it! DSC_0507

Java, a .exe launcher and NVIDIA Optimus

All modern laptop CPUs have an embedded graphics chip. While not as powerful as a discrete GPU, they are far less power hungry.

To help Windows users choose between their discrete GPU and the integrated chip NIVDIA, has introduced Optimus. When the user starts an application, Optimus will determine if the integrated GPU will be enough, or if all power is needed. This is a great idea, but sadly Optimus doesn’t recognize Caromble! as an application that would benefit from a bit more firepower. And Caromble! does love the firepower.

This weekend I finally managed to get Optimus to start Caromble! on the high-performance GPU, and since it took me a while, I thought it might be nice to share how I did it. All of it is in this pdf, but applying it to Java requires a bit of tinkering around.

Telling Optimus to choose the high-performance GPU is very simple. You just set the global variable “NvOptimusEnablement ” to 1. Which is easy enough, apart from that you can’t do so from Java directly. You have to do it from C or C++, you have to do it before an OpenGL context is created, and it has to be on the same process as your java game.

So that gives you two options. Using the Java Native Interface (JNI) you can either call C++ from Java, or you can start Java from within C++. I chose the latter, since it seemed simple, and would give us a proper Windows .exe. This is nice, because we can pick our custom icon, and Caromble! will show up as Caromble!.exe in the taskmanager, and not as java.exe. And, to a geek like me, that is a bit important too.

Enough talking. The basics of starting the Java Virtual Machine from C++ are explained in the official Java documentation. Beware, it’s a tough read.

Below is my interpretation. I have omitted error checking / handling at some places, all includes, and some other stuff that should be easy to figure out. Visual Studio Express is a good choice for writing your .exe.  This post at helped me quite a lot.

I hope it helps!

//Please oh mighty Optimus, give us the High Performance GPU by default
extern "C" { 
 _declspec(dllexport) DWORD NvOptimusEnablement = 0x00000001;

typedef jint (APIENTRY * CreateJavaVMPROC) (JavaVM **pvm, void **penv, void *args);

int _tmain(int argc, _TCHAR* argv[])
	//Load the java dll. Alternative is to start the jvm directly, 
        //using the system JRE
	HMODULE jvmdll = LoadLibrary(TEXT("java\\bin\\server\\jvm.dll"));

        const int numOptions = 4;
	JavaVMOption* options = new JavaVMOption[numOptions];

	options[0].optionString = "-Djava.class.path=Caromble-GAME.jar";
	options[1].optionString = "-Djava.library.path=lib";
	options[2].optionString = "-Xms600m";
	options[3].optionString = "-XX:CompileThreshold=2000";

	JavaVMInitArgs vm_args; 
	vm_args.version = JNI_VERSION_1_2;
        vm_args.nOptions = numOptions;
	vm_args.options = options;
        vm_args.ignoreUnrecognized = false;

	JavaVM *jvm;      
        JNIEnv *env;    

	CreateJavaVMPROC CreateJavaVM = 
              (CreateJavaVMPROC) GetProcAddress(jvmdll, "JNI_CreateJavaVM");
        int res = CreateJavaVM(&jvm, (void**)&env, &vm_args);
	delete options;
	if( res != 0)
		std::cout << "Error creating JVM" << std::endl; 		
                return 1;

        //Find our main class          
        jclass cls = env->FindClass("main/Caromble");
	if( env->ExceptionOccurred())
		/* Mostly this means that you have configured you 
                   Visual Studio Project paths incorrectly */
		std::cout << "Could not find main class because: " << std::endl; 	 	        

	//Find our main method
        jmethodID mid = 
                  env->GetStaticMethodID(cls, "main", "([Ljava/lang/String;)V");

	/* Prepare the arguments for the main function, 
           here we use it to bypass the menu and start a level directly */
	jobjectArray args = 
                env->NewObjectArray(2, env->FindClass("java/lang/String"), NULL);
	env->SetObjectArrayElement(args, 0, 
	env->SetObjectArrayElement(args, 1, 

        env->CallStaticVoidMethod(cls, mid, args);
	if( env->ExceptionOccurred())
		std::cout << "Could not run main method because: " << std::endl; 		        

	//Destroy the JVM, this function will now return

	return 0;

Sphere Concept Evolution

After showing how the art of the alien art evolved, here is an update on the sphere, that now is closing towards final.

The first concepts already had it as a blue glowing object with some pattern on it.

And it stayed that way for quite a while, whereas I tried around with making the pattern more readable.

That wasn’t quite readable still, mostly because of the light effects in the game. So here are some concepts that add a 3D shape, with more contrast, so that the sphere would work in dark as well as bright areas.

After choosing colors from there, I worked on the shape. I really liked the idea of having a glowing core inside.

Next time I’ll show how it looked in the game.

Smooth Animation

As you very well may know, in movies and games we fake continuous movement by exchanging individual pictures at a rapid pace. We call these pictures frames and the pace in which we replace them (frame-rate) is expressed in frames per second (fps).

Most movies in theaters have a frame-rate of 24 fps, but for games the frame-rate is a lot higher (ideally at least 60 fps). Why this difference? Let’s do a little experiment:
Make sure you have a dark background on your computer desktop. Now move you mouse cursor around the screen as fast as you can and first focus on the background, then try to focus on the cursor. What do you see?
In real life (with sunlight) you would see an object move in one natural motion. But if you look at your cursor, you’ll see it at multiple locations at once and you can hardly focus on it.
The thing is, your cursor is updated at 60 fps. This means that even 60 fps does not guarantee smooth animations!
Even on a screen that updates at 120 fps, you’ll not see the cursor move in one smooth motion. Instead, the distances between the separate cursors will be the half the size as you see them now.

But how come movies get away with only 24 frames per second? First of all, they try to prevent objects moving very rapidly on screen as your cursor just did. This is why you do not see a lot fast panning shots in movies.
Secondly, since cameras have shutter speeds, fast moving objects will blur. Through motion blur, a fast moving cursor like we just had won’t display as a few separate sharp cursors. Instead, you’ll see one smudge in the form of a line between the start position and the end position of the cursor.
Since the photo-receptors in our eye do not react to change of light instantly, we perceive fast moving objects blurred as well. That is why the blurred 24 fps movies still look smooth.

To test what I just wrote down, go to this website and set the fps of the two footballs to 24 fps; one with motion blur enabled, and one with motion blur disabled. You’ll probably notice it’s pretty annoying to try to focus on the ball without motion blur.

But now back to Caromble!. After what you’ve just read it shouldn’t come as a surprise that we are currently experimenting with motion blur to make sure movement in our game feels smooth. If you’re wondering how, read this presentation.

While it’s still work in progress, here is a sneak peak: