Category: Various

Doubts and Uncertainties

Disclaimer: These doubts and uncertainties reflect those of Pascal and not necessarily those of Crimson Owl Studio as a whole.

– Will people play Caromble! long enough to reach the end of the game?
– Should we make a new trailer soon or should we wait until we are closer to release?
– Will we even get greenlit before Greenlight is stopped by Valve?
– Should we try and port Caromble! to some consoles?
– If we continue game development with this team, should we start with Unity and stop with our self-made engine?
– Are people (besides family and friends) even reading these blog posts?
– Will a hint of story motivate more players to reach the end of Caromble!?
– For what price should we offer Caromble? online?
– Is it a good idea to make our next trailer a bit more absurd?
– If we are porting Caromble! to tablets, would it be better to make a smaller version (Caromble! Mini) with only the challenge levels?
– Are there intelligent species on other planets that play videogames and struggle with game design decisions as much as I do?
– How much polish does the game still need at this point?
– How much effort should we put in juicing the menu?
– Are all game mechanics introduced clearly enough and will players know how to use them?
– How big should a test panel be to be representative?
– Should we find a marketing/guy girl to help us?
– Am I too stubborn in team discussions for game design ideas I stand for?
– Will we release Caromble! before the end of this year?
– Is game development something I want to do full time?
– Did people like the ‘Dear Lisa’ blog post and should we write a follow up?
– Does making Caromble! with my friends have any negative consequences for these friendships?
– Should we put time in mailing press right now or wait until we are a month from release?
– If we release Caromble! on Leap Motion Airspace before other platforms, will people then see Caromble! as a Leap Motion specific game?
– Is the balance in our team too heavy on the technical side?
– Will a failure of Caromble! make me regret the investment of the last 4 years?
– How much longer can my girlfriend bear me talking about Caromble! on a daily basis?
– Would it be smart to release a small demo of the unfinished game to try and boost our greenlight votes?
– Will I enjoy game development as much as I do now when I would do it full time?
– Will people like this blog post?
– When would I be satisfied with Caromble! in terms of success?
– Does this gif image have any added value to this blog post:

Say hi to my little friend

How it all came to be

As we are getting closer and closer to an actual release of Caromble!, we’re often struck with a flash of sentimentality of how it all came to be.
As you all know, we only work on the game for one day a week (plus all our spare time). Therefore, it shouldn’t come as a surprise that we started working together quite a while back…

It was somewhere in 2008. We were a bunch of friends all studying Computer Science at the University of Utrecht. I do not quite remember who’s idea it was to start building games. As for myself, since I read about the work of John Carmack on games from Doom to Quake3 (I guess I was about 11/12 years old), I always wanted to know how to build my own games (and engine). In that year of 2008 we started to talk about building games more often, and pretty soon we simply decided to stop talking about it and start building our own game engine.

Of course, there was this tiny little problem. We were still studying full time and had side jobs to pay for rent. We first tried working on the engine after college hours only , but pretty soon it became clear that we needed more time. Therefore, we simply decided to skip some classes to be able to work on the engine for a full day every week. Sure, probably our grades suffered a bit, but I still believed we learned more on that one day than all the others combined.

After about a year of fiddling around with our own engine, we started building games/prototypes with it. We worked on all sorts of games, starting a new one every other month, never finishing anything. We worked on pong clones, ball/magnet puzzle games, top-down zombie shooters, zombie puzzle games, games with fireworks on music and much more. At one time, we even secretly used the motion capture lab of the University to record zombie motions…

Around that time, one of our team members decided it was enough. Jiri left the team and got his life back:) (However sad, we really cannot blame him). We realized something had to be done. We decided to focus on the simplest game idea we could muster up and planned to finish that game in about 6 months (this was back in 2010). We made a simple prototype of a 3D breakout game and send it to a graphics artist (Thomas S) who we met during a Global Game Jam a few months earlier. He instantly agreed to join our team.

The first prototype, before it was called Caromble!

With the addition of Thomas and a little later Raymond, we knew we could finish this little game in no time. And as such Caromble! was born.
Since it is our first game, you cannot really blame us for our planning to be a little off now can you?

A lot has changed since then, we’re a little older and wiser. After we got our Computer Science degree, we again had the problem of needing more time. Since skipping classes worked out pretty fine, we decided that we could skip work for one day a week just as well.

And this is what we still do. Sure we had ‘a little’ delay. But at the same time, Caromble! grew from a simple prototype to a full blown game, much bigger and better than we could ever have dreamed of… I really cannot wait to release it into the wild!!



Dear Lisa

Dear Lisa,

It’s been 2 weeks since I last wrote you and many things have happened. I told you about my troubles with my physics tests at school, but these worries have no meaning anymore. Not since last Wednesday. The school is closed and the city abandoned.

It seemed like a bad promotion stunt, when we saw the first giant balls rolling through the streets on YouTube. Unfortunately it was more than a well crafted special effects video. This was real.

Most of the city has now been evacuated, but daddy doesn’t want to leave. “Some black eyed red Martians don’t scare me!” he says. But they do scare me. The screeching sound they make scare me. The explosions they cause scare me.

I have seen one of them. It was near. It had a metallic reddish kind of skin, or more like a shell. It’s eyes were of the deepest black you could imagine. I think it saw me and it screeched. It produced a deafening high pitched tone, as if it was about to attack me or crying for help. Why are they here? What do they want?

We have no television down here, but we have a working radio and enough food and water to stay here for months. Months… I don’t believe I can stand another week of daddy’s End of Day stories: “It was only a matter of time that something like this would happen. I told you so, didn’t I… I told you boy. We have deserved this. We screwed up and now we’re punished. But I knew, didn’t I? I was prepared!”. He doesn’t understand that none of this has any meaning whatsoever. It just happened. That’s it.

Yesterday, the men on the radio said that the giant balls wrecking the city are not created by the Red Monsters. They even seem afraid of it. Some people claim to have seen a white machinelike creature, infused with light, that seems to battle these monsters. It appears that it uses these balls as some kind of weapon. I’d like to belief that there is something out there, helping us.

Although I’m scared, the stories of the light-machine-creature thrill me. It’s exciting to think that some alien races are fighting an intergalactic war and that our planet is their stage. Just like in that show Transformers I used to watch as a child. I’d like to think that something is out there to watch over us…


I intend to post these letters whenever it’s possible and until them I’ll keep them save for you.


I hope you are well.


With love,



PS. I made you this drawing. I hope you like it.


Candy in your shoe!

When I joined the team, my co-developers lied to me about only working on Fridays… Our previous ‘Caromble! Friday’ lasted three days. Yes, it was super-duper Caromble! weekend!

So what did we do this weekend? We refactored the menu – because one might want to navigate through the necessary game options. Also, we tweaked some sound issues – to hear better what you see moving around. And, we made quite some progress on the levels – which are currently over 75% done. Woohoo!

As we are polishing the levels in chronological order, we now get to work on the more complex levels. This means we sometimes encounter a level which would be best described as an enigma. Fun to play and inversely as fun to tweak. I’m exaggerating, but still our level design isn’t always friendly for ourselves. Motto’s like ‘KISS’, ‘worse is better’, ‘less is more’ are sometimes forgotten while trying not to ‘kill your darlings’.

However, with these principles in mind we used a chainsaw to revise our very big to-do list, a.k.a. feature creep list. Because all our decisions are made together – on a 6th century round wooden table – we sometimes tend to get into long-winded discussions. This time we somehow managed to avoid these. We prioritized everything by taking votes, which seemed to work quite well.

Besides creating a game, we also played some games, ordered a lot of food and watched South Park. The last episode happened to be very informative about the pros and cons of the PS4 and Xbox One. Unfortunately, there was no mention of Caromble!. But, as we develop this game for PC, Mac and Linux, I don’t hold any grudges against the creators.

We sideways watched the Netherlands football team tie against the blue samurai from Japan, and last but not least we saw the arrival of Sinterklaas into our country. The presence of this saint often leads to candy in your shoe; hence the title.

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….

Vacation and a major rewrite

You may have noticed that things are a bit more quiet than usual on our development blog. Our vacations are to blame. Personally, I have just spend two awesome weeks touring through Italy with my girlfriend. Eating pasta, drinking wine, sitting in the sun and generally not thinking about anything more complex than where we should have lunch. Maybe I was also gathering some strength for what I knew was waiting for me back home.


You see, back when we first started working on Caromble! none of us had ever made a game for real.  It is amazing to see that lots of the code we wrote in those days is still in the game, and working as it was originally intended. It is also  unsurprising to see that lots of code has been thrown away and rewritten. And it is also unsurprising that there are lots of bits and pieces of code that really should be rewritten, but never were broken enough to warrant such action.

Among this code was core rendering engine. Like I said, when we started there were lots of things we didn’t know. Especially about rendering. We understood the basics, but when it comes to rendering a game there are also a lot of important specifics. So what happened was that we just went ahead working with things we didn’t fully understand, and just getting it to work.  Starting from examples from the internet we actually made quite good progress. Eventually we were even being able to contribute a little bit to Ardor3D, the graphics engine we use.

While we were getting to grips with rendering in OpenGL, OpenGL itself went through a transition. Slowly but steadily the Fixed Function Pipeline got out of fashion, in favor of the programmable pipeline. Initially we didn’t care very much for fashion, and quite happily used both pipelines for different parts of the rendering process. Which didn’t really seem to matter at that time. So what if we depend on both?

Well it turns out it does matter. To be able to run the game on MacOS we needed to choose. Apple drivers will work with either pipeline, but not both at the same time (OpenGL compatibility mode). We couldn’t go back to the fixed function pipeline anymore, as we would not be able to maintain the look of the game. So we had to take the leap forward.

And that brings me to the thing that was waiting for me. A complete rewrite of the core rendering code. Just when the game is quite nearly finished too. To add to the fun, this also means we can’t use the off-the-shelve version of Ardor3D anymore, which is still fixed-function at heart. At the same time, it is also quite exciting. We get to write a rendering core which is tailored exactly to the needs of Caromble!, we anticipate that we can get a bit more performance this way too.

Originally, this would be the blog posts were I would triumphantly boast about the new awesome render core we just put in Caromble!, making life at least twice as awesome. Sadly, all this exiting state-of-the-art rendering core currently does it give me a black screen.  And sometimes crash. But I should be able to fix that pretty quickly. When I do I’ll share how I did it here. We could also make the renderer available to those we would find it interesting.

Until then!







Meet us at Gamescom 2013

Coming Wednesday (21st) and Thursday (22nd) we will be in Cologne at Gamescom. Hopefully we will raise some more awareness for our stunning game!

Caromble! can be played at the Holland Pavilion (Hall 4.2, booth number B-030) because our friends at Dutch Game Garden put our game on INDIGO.

We don’t have a booth ourselves, but we will pop up everywhere to let you play our game (with Leap Motion if you like), talk about games and game development, or talk business.

Would you like to meet us? Please contact us via Twitter: @caromble@oxpal@peter_cc_heil,  @raymondbijl

See you in Cologne!

Java Game Programming

As you might already know, we use Java to build our game (+engine) in. While we wrote all engine code ourselves, we do use Ardor3D (in combination with LWJGL) for graphics and JBullet for physics (love them both).

Because Java is discredited quite a lot these days (mostly security issues), we wanted to write something about our experience using Java for game programming.

  • Is Java safe enough?

While there were numerous security issues found in Java the last few months (Java 8 even got postponed because of it), it won’t necessarily trouble you in using Java for games. The most problems found in Java all have to do in running Java Applets, not with running Java on desktop.
Of course, fewer people will install Java with all the commotion going on so it’s a little harder to make you game run out of the box. Luckily, it is pretty straight-forward to bundle the Java Virtual Machine with your game (as the good people over at Puppy Games already pointed out).

  • Is Java fast enough?

Short answer: yes! Longer answer: but like with every language, there are a few pitfalls… While it is unlikely that Java will ever reach the raw power of optimized C++ code, it does offer speed that comes very close while keeping its readability (of course, opinions will differ) and safeness (no overflow/pointer errors). On top of that, memory leaks are way easier to prevent.
On the down side, there is a warm-up time. It takes a while for the Just-In-Time compiler to compile the most used methods from byte-code. We work around this by running our menu in the game world so once you take the controls everything runs smooth. And while having a garbage collection makes 95% of working with objects a lot easier, it isn’t perfect either. This brings us to our next topic:

  • The Garbage Collector

Having a garbage collector at your side can be a real blessing when writing a game. You’ll never (well almost) have to worry about running out of memory because of memory leaks. But it comes at a price. As you know, unlike languages as C++ and C#, Java does not have structs -you cannot allocate simple groups of primitives on the stack and pass them by value. Therefore, even simple data like the typical Vector3 (basically 3 floats) have to be presented with objects. While the garbage collector normally does a great job cleaning things up for you, having this insane amount of garbage every frame will definitely lead to slowdowns.
The Java virtual machine will try to clear most garbage with minor garbage collections. That are small garbage collections that will hardly take any time (and will not slow your game down). If you leave so much garbage that the minor garbage collections cannot keep up, Java will do a major garbage collections to prevent your application from running out of memory. These major collections will make your game stutter every few seconds (killing for any game with fast-paced game-play).
The way to solve this is making sure the JVM can clean up all garbage with minor garbage collections. So, how do you do this? It’s simple; do not leave too much garbage!
We solved this by pooling our small/most-used objects. But how do you make sure that your temporary objects are always returned to the pool? We do this with the auto-closable interface in Java 7. We use (abuse?) the new “try()” functionality in the same way you would use “using()” in c# like this:

try(Vector3 temp = Vector3.getTemp())
… Some calculations with the temp vector …

And in the Close() of the Vector3 we put the temp vector back in the Vector3 pool of the current Thread. You will need a object pool per thread. Normally this is done using the ThreadLocal class but since we spawn our own worker threads there is no need for it; we get the temp object directly from the pool of the current Thread.
Of course, when pooling objects, it really helps to place some tactical asserts in the classes to make sure it doesn’t get altered while inside the pool (you should not hold references to those objects outside the try{} clause.
Also, it might help triggering a major garbage collection just after switching levels by calling System.gc(). This make sure all/most old data from the previous level is cleared up.
Most of the time, you only have a handful of methods that really spawn a lot of garbage, so grab the Java Visual Virtual Machine from the JDK to (easily!) find these methods and optimize those. Don’t go insane on trying to optimize all code, concentrate on the places where it matters.

  • UPDATE: Escape analysis

As Adrian Papari points out below, Java uses escape analysis to automatically place objects on the stack or replaces them with simple primitives (and thus preventing allocations & garbage). But for our game Caromble! pooling of the Vector3 at some critical places definitely was a must to get constant performance. To get to the bottom of this, I made a test app inspired by this example but made it a bit more complicated to resemble actual game code more closely. Still I made sure that only Vector3 classes where used (no string allocations etc). The results can be seen in the image:

Capture of Java Visual VM Top: escape analysis disabled Bottom: escape analysis enabled (default)

Capture of Java Visual VM
Top: escape analysis disabled
Bottom: escape analysis enabled (default)
The blue lines on the left show cpu time spend on garbage collection

As you can see, with escape analysis disabled the garbage collector was doing minor garbage collections the whole time (taking up quite a lot of cpu time) but still used heap memory was increasing still. Once it the it would have run out of heap space, a major collection would have kicked in to clean thing up.
As for the example with escape analysis, it runs a whole lot better, hardly spending time on garbage collection. But what is interesting to see is that it doesn’t keep the heap space constant! While it does take care of not allocating most Vector3’s on the heap, it does not optimize away all allocations of the Vector3 class and still some garbage collection is taking place.
This explains why in some extreme cases like game programming object pooling might still be useful.

  • DirectBuffers

While the JVM garbage collector is pretty good in handling large amount of garbage from objects, be very careful with native/direct buffers (you need those to communicate with OpenGL). Leaving a lot of direct buffers lying around will lead to major slowdowns pretty soon that can last several seconds! So be sure to reuse direct buffers (mostly mesh data) as much as possible.

To conclude, if you take note to the above and work your way around it, Java is a great language to write your game in. But yeah, like every other language, getting real time performance will always take some effort.

Sushi on Friday the 22nd

Got to have Sushi

This Friday we finally had a meetup with the whole team together again. We talked a lot about the final features that we’re going to put in Caromble before we’re going to start polishing things up. Can’t reveal too much yet, but rumors are the words ‘boss’ and ‘fight’ were heard occasionally…

We also had plenty of talk about marketing. Since we’re all developers this is really something we have to learn as we go. And nerdy developers as we are, we just had to write some code to support us in this process. So now we automatically keep track of the indie gaming sites out there to see who writes about us. And the results, well, lets just say we’ve plenty of room for improving ourselves:) So if you want to write about us, do not hesitate to ask! Also, do check out our press-kit.

To conclude our fruitful get-together, we went out and had Sushi. Just can’t go too long without Sushi.

Caromble! at Game in the City

On the 22nd and 23rd of November, Caromble! will be playable at Game in the City as part of INDIGO on the Road. If you are around, don’t hesitate to try out Caromble! at this event in Amersfoort!