Tag Archive: Caromble! Fridays


Early Access Round One

And the Oscar for Best Performance by an Actor in a Steam Early Access Video goes to…

What a week! Thanks for all the feedback on our Steam Early Access release! Caromble! only got positive reactions! Which is a great stimulus to work even harder towards the full release 🙂

Also, we we’re a little surprised on the reception of our Early Access Explanation Video. You people really liked it! It’s good to see our message about releasing on Early Access has been received well and gets great support. Haven’t watched the video yet? Please do.

Besides the great reactions on our Steam community page – thanks again! – some friendly redditors picked up on our video and gave really nice comments:

“This was the best explanation and implementation of Early Access I’ve ever heard. Seriously.”

and

“This is a brilliant Early Access video. Using humour and truth to break the news to people will win them a lot of leeway and respect.”

and

“Really great take on the early access system; honestly wish more people would take the route they have.”

Also, great to see Thomas – the artist – being admired for his acting skills! “And the Oscar for Best Performance by an Actor in a Steam Early Access Video goes to…”

Besides creating the game itself, it is also a lot of work for our small indie team to create additional content like our videos. It’s reassuring that the result of those midnight hours is being appreciated!

Controllers

This Caromble! Friday

After this milestone it’s time to look forward again. This Caromble! Friday we’ll discuss all the responses and decide what will be in the next bigger Early Access update. In between the content updates we’ll possibly push some hotfix updates.

We’re glad that the number of issues didn’t grow that much, so we can already focus on introducing new features.

You want control? We are working on our controller support. The logic is already present but the controller needs more tweaking to make you – ehm.. – feel in control. Naturally, we also want to add the next chapter levels. So those will probably be in the coming update.

Until next time, happy gaming!

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!

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!

hdr

An HDR image mapped to LDR images with different exposures.

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.

Black or white?

In a previous post we wrote about creating challenges, or a place to pile our feature creep!

This skill testing place now gets a makeover. At the time – some 5 months ago – we used the available assets to create prototypes. Currently, we are deciding on the final style.

We like this challenge area to look clean, simple, and fun. With this in mind we converged to a clownfish palette containing black, white and orange. With orange only being used for accents, so you’re not actually playing in ‘Clownfish Land’.

The important question is: what will be the dominant color? Black or white? Does it matter? A wise man once sang: ♪ It don’t matter if you’re black or white. Whoo! ♪

The screenshots below are our current mockups for the challenge areas. In a future post we will reveal the final style.

Black

Mockup for a challenge level using black as the dominant ‘color’.

White

Mockup for a challenge level using white as the dominant color.

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!!

 

 

Happy Christmas!

Christmas treeThis is no political blog. Although, one could consider us as a single-issue party for Caromble!. However, we have yet to launch our political campaign. So let’s start right here. Vote Caromble! on Greenlight. Or for president. Just vote!

Where were we? Right, I wanted to address a political issue.

I’ve happened to notice there are some discussions about why people celebrate Christmas. Sometimes referred to as The War on Christmas. Is it a holiday about food, presents, family, Christ, Santa Claus, or an evergreen conifer? To be politically correct, I avoid to answer this question. But, I think it’s great to have hours of extra free time to play video games!

Unfortunately, this Christmas will go into history as the holiday in which video gamers around the globe could not yet play Caromble!. I very much look forward to a later blog post which might be titled ‘Happy gaming!’.

For now, Happy Christmas!

 

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!

Screenshot!

…and back to work; who needs sleep anyways?

 

 

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.

Java garbage collection and device resources

For Java programmers the garbage collector is a pretty nice thing. Peter wrote a bit about Java and the garbage collector on this blog a while ago. In short, the garbage collector will make sure everything that isn’t needed anymore will just quietly disappear. Most of the time you’ll never know it is there. And after a while you sort of forget its existence, and when you do encounter it, it might be a painful experience.

I had one of those encounters when I was nearly finished with our new render-core and rolled it out to all developer machines. One of the laptops (with only an AMD APU) suddenly started running out of video memory very fast. That was strange, the memory footprint of Caromble! isn’t big and hasn’t changed with the new core. So what was happening?

After a bit of debugging it proved related to the rendering of text. Each time some in-game text would change, we would allocate a new vertex array on the GPU with exactly enough space for each letter. For each text (and the game has about 5 of these at any one time) only one buffer was used. Hardly exciting and not something you would expect to cause problems with video memory. Nevertheless, these buffers were causing the problem.

I looked at how the video buffers were disposed. All references to a buffer on video RAM (with a backing system RAM copy) were being managed by a ReferenceQueue. It is a solution from theArdor project that I think is both elegant and powerful. As long as the data can still be used it will remain on the video card. When it can’t be reached anymore, because all references to it are destroyed, it will be scheduled for garbage collection. If we poll the RefenceQueue regularly we’ll get a reference to all buffers scheduled for destruction and can tell the GPU that it can free the corresponding vertex array. So it isn’t necessary to keep track of who is referencing the data, but we still get to execute custom code for cleaning up the memory from the GPU. Perfect right?

Except it isn’t. As soon as the garbage collector detects that a video buffer can’t be used anymore it will return a reference to the object holding that buffer for us. But there lies the problem. We won’t get that reference until the garbage collector determines that it can safely be removed. The only guarantee the JRE makes on this matter is that this will happen before Java runs out of heap-space. So as long as there is sufficient system RAM available the garbage collector might decide that it will be better for performance to just let the garbage lie around for a bit longer. Since it doesn’t know about the video memory we are using, it can’t know that leaving this bit of garbage can be dangerous.

So that was the lesson I learned from all this? The job of the garbage collector is to keep the program inside its heap-space and to try to be as silent about it as possible. If there is enough space there is no need to slow the program down by collecting. So it won’t.

Once I figured out what the problem was, the solution was quite simple (but not very elegant). I solved the problem by explicitly removing buffers that I know are no longer required from the GPU. Buffers that are potentially shared by different meshes are kept on the GPU until the backing CPU data gets garbage collected. But since these buffers don’t often changed that is not a problem.

It was quite an interesting insight in the workings of the garbage collector, and I think it also proves that you shouldn’t try to to be too smart around resources allocated out of sight of the garbage collector.