| Caromble! is a fresh brick-breaking game in a 3D, physics-based dystopic world with an unique art-style and epic gameplay features you wouldn’t expect in a brick breaker. It is created by Crimson Owl Studios, a small part time indie team that comes together every Friday to develop their first game. Caromble! will be released in 2015 and will be available on PC, Mac & Linux. |
 |
Game Development Blog:
Dear Caromble! followers,
Yesterday we made another big step towards the release of Caromble!. We have held an extensive playtest session. The ingredients were:
- 13 friends from inner and suburban circles
- Several story levels
- A few skill levels
- 5 PC’s and 2 laptops
- Coffee, crisps and chocolate
- Observation and a survey that should help us determine what we want to change, balance or add to the game before the release
The developers, nervous for the playtest.
After 6 hours we collected all data files, had some drinks, played some PES2015 (sorry FIFA fans) and talked with the playtesters about their first encounter with Caromble!; the game with which we aim to create the most epic brick-breaker game in the history of the universe.
We are now analyzing all our notes and processing the surveys, but here are already some of the results:
- Many playtesters laughed when they catched the Pixelate power-down for the first time
- 50% of the players destroyed the boss in their first or second attempt
- No crash of the game occurred all day long (what we are quite proud of, as it is running in our own game-engine)
- We encountered one gameplay-breaking bug:
This should NOT happen!
- Unfortunately 4 playtesters could not come (snowy reasons), one of them being a woman. Now we only had male playtesters
- 3 bags of crisps were eaten
- One player wore a Fez shirt, which is very cool:
Thank you very much playtesters! You were awesome and Caromblecious!
- One player thought that one of our gameobjects looked like a giant red dildo. Not sure whether we should address this…
We have had a great time and so much useful feedback. We want to thank all playtesters once more. We were very happy with your effort, feedback and joyful faces. Thank you!
Happy developers after a successful playtest day of Caromble!
Charging as a core gameplay mechanic
Caromble! is a brick breaker game. However, I dare to say it is not JUST a brick breaker game. Our aim is to create an interesting and engaging game world, where the core gameplay mechanic is that of a brick breaker.
Gameplay wise, there are several things in Caromble! which you would probably not expect in a brick breaker game. The 3D elements in the game serve an actual purpose and are an integrated part of the level designs and highly influence the gameplay. Our dynamic subareas within the levels add an exploratory factor to the game. Furthermore, the charge mechanic and some special, fresh new powerups add an extra dimension to the brick breaker genre.
Besides these gameplay mechanics, we also focussed a lot on creating an interesting game world. For some players, playing a game is purely about the abstract game mechanic. Other players like to be emerged in a fictional world, where their fantasy can make even bigger and greater stories than the game designers intended. To help you create an interesting game world, it is good to have established a backstory. With this, I do not mean Hideo Kojima-like cutscenes, but a small consistent story in the back of your head. This can be very useful as a game designer. In a next blog I want to tell you more about Caromble!‘s backstory and why I believe it is useful to have one. For now, I just want to say that having only a small hint of a story can already give you many ideas for creating or improving the world your game is ‘living’ in. This can help you think of objects that are within and outside the game world, and can suddenly fill in the gaps if you’re struggling with designing a boss fight. Context leads to ideas.
The world of Caromble! feels alive and I think that the dynamic elements in the game are a big part of how this is achieved. We have 3 kinds of dynamic elements in the game:
- Essential dynamic elements within the gameplay. These can require timing and sometimes bring puzzle elements to the gameplay. A level cannot be completed without using it.
A dynamic ramp that is essential for the gameplay
- Non-essential dynamic elements within the gameplay. These can be moving obstacles that influence the physics world and can have unexpected big impacts. Remember, chain reactions in physics == fun
A none essential car in the level, just for fun
Lastly, and in my opinion a very interesting one:
- Non-essential dynamic elements outside of the gameplay. Often placed in the background or between subareas of a level.
Barrels in the background for an Industrial atmosphere
Moving elements in the menu that are non-interactive
This last one does not influence the gameplay whatsoever, but I believe that these elements are a major ingredient for making a living, breathing game world. I think that when a player sees objects that are somewhat consistent with the created context (made possible by a (small) backstory), they unconsciously make associations and make a (bigger) story in their head. In their self created/associated world, the actions of the player, which in Caromble! is that of a ‘simple’ brick breaker mechanic, can have a bigger meaning in that world. You’re not just jumping on mushrooms. No, you are saving the princess of mushroom kingdom.
A train on the side of a level, which can’t be hit by the ball
All of a sudden the player has a role in a fictive world, and as a game designer you should aim to give as many possibilities for the player to make associations within that world. This in turn makes it a richer and livelier world. I think that dynamic elements, even in the background of the game, helps you achieve that.
Only two weeks ago, we have changed the movement of our game’s antagonist, such that it always follows/looks at the paddle. Immediately I experienced more of a threat from our scary red bad guy, and I think the game world has become livelier because of this change, with only little effort. What do you think:
It’s always watching you!
Brick breaker games are often referred to as breakout clones. But just as not every first person shooter is called a wolfenstein clone, perhaps Caromble! can help to establish an actual genre. At least we hope that the world we have created for Caromble! helps in engaging many players to enjoy the brick breaker mechanic.
The barrels actually fall into the level
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:
PS: We know we’ve been a bit silent on the blog lately… but believe me, it’s the calm before the storm!
Part two of our interview series where the Caromble! developers interview each other. This time our interviewee is Thomas Duindam.
Thomas drinking beer at a festival
Thomas, when will you release Caromble!?
2014-ish. We release the game when we decide it’s finished.
How many times has this question been asked to you?
It’s a logical question to ask. I wonder about it myself. This year we will at least release something! We will open up and allow for early access to our game.
Let’s ask what should have been the first question: Who are you?
I’m one of the developers of Caromble!. I am a software engineer in the medical field by day, and a game developer by night – and most weekends. Sometimes I drink beer at a music festival.
What is your favourite game?
Monkey Island. I enjoy games with a strong narrative and which are able to immerse me into another world. It impresses me more than abstract skill games.
That sounds a bit like the opposite of Caromble!
Yes it does, but I don’t think that’s a problem. Opposed to my previous anwer, I also game to relax instead of desiring to have a new experience in another world. I relax the most with games that have familiar mechanics. It’s like deciding to watch an important art-house movie or a easy to digest blockbuster. When I want to relax I choose the latter. When I want to relax and play a video game, Caromble! will be a very good choice.
That sounds like fun! I want to play Caromble! How would you describe a day in the life of a Caromble! developer?
Wake up. Drink coffee. Commute to this week’s developer studio / kitchen table. Drink some more coffee.
This is followed by:
– 25% coding, mostly fixing bugs.
– 25% discussions about Caromble! At the time mostly about project management.
– 25% lunch.
– Another 25% coding.
Sometimes the Caromble! workday ends here. Other times the day continues with:
– 25% playing games and drinking beer.
– 25% coding, mostly creating bugs.
You mentioned discussing about the game. What was the most difficult decision during this project?
I remember the infamous ‘Feature Creep Dooms Day’. It was a day’s length discussion about the scope of Caromble!. We slaughtered many feature ideas. At the moment I think the scope is still too big. 25% of the current scope would also suffice for a really nice game. Three lessons learned: limit your scope, limit your scope, limit your scope.
Could you name some ‘slaughtered’ ideas?
Portals, which was the hardest to let go off. Switching gravity’s direction. Zombies. Multiplayer.
Sounds like enough ideas for a Caromble! sequel. You are developing Caromble! for quite some time now. What keeps you going?
I like the game so far and I am very curious about what the final version will be like!
What is the element of Caromble! that you are most proud of?
All technical stuff that’s written in Java. A lot of people said it couldn’t been done! But we did!
It’s been a long time. A very long time indeed. But we are still here, alive and kicking. We’ve had some hectic weeks, busy with holiday trips, finding new houses and unfortunately some hospital visits. But we are well!
I have just returned from a trip to Paris and Caromble! seemed to be a very big thing there, as you can see in the photos throughout this blog post.
At the moment, Peter is probably chilling in a pool with a caipirinha and his girlfriend, but the rest is back in Holland to push Caromble! to the next phase. We will not yet go into specifics about what that phase is, but expect something to happen soon; something involving the fact that Caromble! is greenlit on Steam and yourself collapsing some structures in the Caromble! world.
Because we are limited in our time to work on the game, as we still have our ‘normal’ jobs 4 days in a week, and writing blog posts steals some of this precious time, we have decided that for the moment we will be writing blogposts every two weeks. We will still do a #screenshotsaturday weekly, so check that out if you want to see more of Caromble!.
A couple of weeks ago Thomas Schmall posted an article about the new particle systems he was working on. I finally got around implementing the last system, the spark particles.
I would like to show you two ways we can use this particle system, and give a brief insight in how the Caromble! Editor can be used to place and tweak it.
The first way of using the system is to emulate sparks generated by something like welding. They spray out in a coherent beam.
Timer trigger that triggers every 2-5 seconds and send the trigger to a particle system
This effect works best if the sparks aren’t spawned all the time, so I’ve used a timer to spawn a spray of particles every couple of seconds. In the screenshot to the right you see this timer. I’ve set it to send an event every 2-5 seconds.
Now we just need to place the actual spark particle system itself, and fiddle with the parameters a bit to get the effect we want.
I’ve included a screenshot of the relevant bit of the editor screen below. Five properties are important for this effect.
First of, it is important to set the release rate (very) high. The release rate is the amount of particles we’ll spawn per second, and since we’ll only spawn particles every once in a while, we need to spawn a lot of them in this small period of time.
A less obvious parameter is the “ContinuousParticles” property, which is ticked of to indicate that we’ll provide external triggers for the particle system.
The important settings for the spark particle system.
Next to that is the “PulseDuration”, which determines how long we’ll spawn particles after every trigger.
The collision object property determines which objects the particles will bounce of. For performance reasons we won’t bother the physics engine with all particles, so you’ll have to provide a list of objects with which the sparks can interact.
Finally the “MaxAngleRadian” property determines in what direction the particles will be spawned. Since this is meant to be a coherent spray, I’ve set the angle fairly low.
Alternatively the spark particle system can be used in a more continuous way, as shown below.
To use the sparks in this way, you don’t need an external trigger, the particles will continuously spawn, and 
Perlin noise is used to control the release rate of the particles.
Again I’ve highlighted some important properties for this system.
The upper triplet of properties control the release rate animation in a somewhat mysterious manner. The “FractionOff” number corresponds to the fraction of time that there should be very little particles (the lower bound of the release rate). The “ReleaseRateAnimationSpeed” determines how fast the animation over the release rate is running.
The other five highlighted properties determine the way the particles look. The “MaxAngle” is much higher than it was in the beam example, it now corresponds to a halve sphere. The “StartSpeed” and the “Gravity” property together control how the particles will act after they have been released. They have to be tweaked together to achieve the desired effect.
Finally the “MinLifeTime” and “MaxLifeTime” parameters dictate how long the individual sparks will exist on this planet.
With that I’ll conclude this post. I was hoping to provide a small peek into the daily live of us Caromble! developers, and about the tools we have made to work with. We might release the editor with the game (or at a later stage) so you might get a chance to tinker with it too.
Also, if you have any questions or suggestions, please don’t hesitate to ask!
As we have already mentioned many times, we work on Caromble! only on Fridays and every spare hour in the evening and weekends. Mostly, we write these blogs about our part-time struggles of making Caromble!, but this time, I want to take a moment to talk about my other occupation. Not that of being a boyfriend, but my ‘real’ job at Motek Medical.
Motek Medical creates products for rehabilitation. They combine motion platforms, instrumented treadmills and motion capture systems with a virtual environment to provide motivating and engaging training exercises and precise assessments for rehabilitation:
I am primarily a C++ developer here, but lately I am also working on rehab applications (so called ‘serious’ or ‘health’ games) for patients, doing game design and implementation.
Making a health game is very different from making a game for entertainment. For Caromble! I make design choices using my gut feeling and my own experiences of the games I love. It has to become a game that I too could enjoy. When designing a game for a specific patient group, the approach is very different. More than in any other game, the player is the main focus in a health game and the desired outcome is different. The game should be motivating, challenging and captivating for the targeted patient, not only to entertain, but with the goal of improving her (let’s assume she is female) capabilities. A game designed for this purpose, could very well be a game that I wouldn’t like to play or look at. For me, this takes me a bit out of my comfort zone, where as a gamer I think to know which are ‘good’ game design choices and which are not; knowledge which I can use in the game design choices of e.g. Caromble!. In health games these ‘rules’ I have learned simply do not apply.
When designing a health game, the main question is: “Who is the audience?”, and to go a bit deeper, also: “What is the (clinical) goal of the health game? “, “What is the patient capable of (cognitive, physically and visually)?” In an ideal world, a health game is designed for one person, so you can make specific design choices for that person, taking into account her capabilities and interests. Unfortunately, this is often not the case. A health game has to be designed for a whole patient group, for example stroke patients. The problem is, that one stroke patient is very different from another; one can still move her arm, a second can move it only a little and third can’t move it at all. Or one has an easily overloaded cognition, while another can handle a lot of different cognitive signals easily. Besides these variations there are also the subjective preferences that patients can have about visuals, gameplay and sound. Making a game that is suited for a whole patient group is according to me, the biggest and most interesting challenge.
Before we start prototyping a new health game for a specific illness or physical/psychological problem, we sit around with therapists and patients to get to know the intended audience. With the retrieved insight we start prototyping both gameplay and visuals. We playtest the prototypes ourselves and with patients and with those new insights we often have to go back to the drawing board. It still amazes me how difficult it can be to fully let my own assumptions of a ‘good’ game go and think ‘with’ and ‘for’ the patient, about what is desired for her.
Once we have a suitable prototype for the project, we still have the challenge of making the game such that it is challenging and captivating for the whole range of patients. A scalable difficulty is one of the most important aspects to achieve this in my opinion. There are two ways to do this:
- Incorporate many settings that the therapist can adjust, such that the game can be tailored to the specific patient.
- Design the game in such a way that it uses adaptive difficulty.
I think the best solution is to use a combination of these two. Expose some settings to the therapist, but not too many or the game will be difficult/unclear to use. Also, find a way to let the game decide itself whether it should change its difficulty and if so, think of a good way to do this. Probably many games that I have played use some form of adaptive difficulty, but two examples that come to mind are FIFA Football and Mario Kart. FIFA did this in the worst way possible: after a few games I lost, the game suggested something like: “shall we set the difficulty to a more suitable level for you?” Well thank you very much EA, for pointing out that I’m a loser. Mario Kart on the other hand, gives losing players a higher probability of better powerups, improving their chances of winning. I think that these methods are not the best way to do this, but to hide this mechanic from the player, instead of what FIFA did, seems like a good choice.
Today, my colleague Coen and I went playtesting our current project Bloonies with a patient. The goal of the application is to train dual tasking: stroke patients can have difficulty with walking when executing a cognitive task. During this extra task they can slow down or even stop walking. The goal of Bloonies is to train this dual tasking. I have been reading some game design books (currently ‘A Book of Lenses’, love it!), but none of these books could give me the insight that I got from seeing this patient playing Bloonies and hearing his thoughts about it. Making health games requires a whole different kind of game design, one that I grow more fond of every day. I will share a video of Bloonies on this blog once it is finished and perhaps explain something about the way we achieved scalable difficulty in that project.
Thinking about the concept of adaptive difficulty, it makes me wonder if such a thing would be suitable for Caromble!. We are now too far in the development to incorporate such a thing, but it is an interesting thought experiment. I think that the difficulty in Caromble! is linked to two situations:
- Losing the ball; a higher difficulty makes the player lose the ball quicker and more often.
- Taking more time to complete a level; either to destroy all blocks or to solve a puzzle.
If we would incorporate an adaptive difficulty, we could influence both of these situations. Losing a ball can have multiple causes, but I think the main ones are a ball speed that is too high and blocks close to the paddle where the ball bounces off. If the player loses the ball too often or too quickly, the game could decrease the ball speed and destroy nearby blocks. A solution for a level that takes too long is to destroy some of the blocks after too much time has passed or to provide a hint system for the puzzles that offers these if too much time has passed. I think it is not smart to try and implement this into Caromble! now. These kind of features have to be incorporated early on in the development of a game; otherwise it can introduce balancing difficulties in terms of gameplay.
Also, the process of thinking with the patient, what I am learning through experience at Motek Medical, made me think of how this approach would work on Caromble!. Who exactly is our audience? In my opinion it are retro and indie gamers and perhaps (hopefully), some casual gamers can appreciate it (read: love it to the fullest) as well. Would the game be very different if we carried out an extensive study on the preferences and desires of these gamers? I think it can be very interesting to try this approach on a future entertainment game we make: to let go of our current assumptions and learn from the potential players.
Caromble! is a game that at least we enjoy playing a lot and we can only hope that many players feel the same. Since Caromble! is the first full game we create, I believe that is enough.
Crimson Owl Studios is a very particular studio. In fact, there is no physical studio at all. Every Friday all team members take a day of unpaid leave and gather at their kitchen tables scattered throughout Utrecht and Amsterdam.
We have talked about all aspects of the development of Caromble! on this blog, but we never had the team talk for themselves.
The coming weeks we’ll have a series of short interviews on this blog where all team members will be given a chance to talk about game development, Caromble! and how the last couple of years have been.
Developing Caromble! at Raymond’s table. Left to right: Peter, Pascal, Raymond (interviewee), Thomas D (interviewer).
So let the first interview begin!
Who are you?
Wow, that’s a very philosophical question to begin with! I like philosophy. Of course it’s impossible to describe in a few words who one truly is. But let’s try. I am one of the creators of Caromble!. My name is Raymond Bijl and I like video games.
What is your favorite game?
It’s hard to name only one game. I can really immerse myself in a fantasy themed game with a good story. In that genre Baldur’s Gate is one of the best. Next to these comprehensive role-playing games I can truly enjoy arcade or puzzle games created by fellow indie developers. From a game design perspective I can wonder at the elegance of these apparently simple games and then think ‘I would have loved to have made that one!’. World of Goo is a great example of this.
Let’s talk about work. What are the consequences of splitting your time 80 / 20 between a regular paid job and creating Caromble!?
For a lot of game studios there is no guarantee for success and no room for failures. For me, a regular job means guaranteed income and that’s a certainty I really appreciate. Especially when I notice that I have all kinds of financial responsibilities every month. Anyhow, it means that creating Caromble! goes a lot slower in comparison to the development speed we would have if we were a full time game studio. When we say we are working on this game for four years, we mean one day a week for four years, and those days go by fast.
How about the people around you. Do they see you as somebody with two jobs?
Most see the ‘creating games’ part as one of my hobbies, but maybe that’s because how I first approached it myself. My personal goal was to learn to create games by creating games, but not necessarily in a professional way. However, the things that I do, I want to do them well. And I soon realized I could not approach this project as a hobby. Creating a good game means you’ll have to work hard and do that professionally. Of course, we are also friends, so we have fun and drink beers, but most of the time we just work hard. Creating games is not always as romantic as I would like to think it is!
Keeping it romantic. What is the element of Caromble! that you are most proud of?
I would not name one element, but the whole game. I think it’s really nice to see all the pieces fall together and to realize that we are creating a full-blown game that looks, sounds and feels like one of the real games I have always wondered at how they were created.
A very open and last question. What if?
I would really like to see Caromble! succeed and I believe it has the ingredients to do so! I think Caromble! will breathe new life in the brick-breaking genre. This genre is based on a simple concept – keep the ball in play and break stuff – but it has always proven to be fun and addictive. I hope that other players will enjoy Caromble! as much as I do!
On the art side I can slowly move towards polishing, as at least the industrial set is basically finished. One thing that I really want to tidy up are the effects. My thinking is that if they are in style, then the whole look will come together much more.
The effects were so far really soft – and somewhat realistic. Which doesn’t fit to the more comic-outline style of the textures. The explosion for example is done via an animation. So I redid the thing and animated it in a more cartoonish style:
Here is a smaller hit animation – that will show up when boxes are damaged (that effect is not yet in the game):
A smaller hit.
It would be combined with smoke, and also sparks. Here is the animation for it, which would only really work in motion.
A spark – supposed to be many that fly around.
And here is the explosion.
Explosion!
Here are some screenshots of the explosion in action.
We are working on Caromble! only one day a week for about 4 years now. During this time our primary goal – Learn about every aspect of game development by building an actual game – didn’t change. However, an important secondary goal changed.
After finishing our own game engine and creating all kinds of prototypes with it (as described in our article: How it all came to be), we decided to make a simple game: a modern 3D Breakout. The goal was to make a short, simple game and learn as much about game development as possible and then move on to a full game project. But, creating this simple game seemed to be a lot more work than we anticipated, and our secondary goal of ‘making a simple game and move on to a full game’ gradually shifted to ‘make Caromble! a full game we can be proud of, for the rest of our lives!’.
Our attitude towards that one day we devote to Caromble! changed along. Before, this day felt as our ‘hobby day’ besides our normal work days. Some of these days went by with polishing and fine-tuning insignificant details. However, to actually finish Caromble! someday, we had to change to a more professional attitude. This seems obvious, right? For us, it wasn’t that simple.
Our greatest pitfall is that we are part-time indies who don’t have financial worries because we have a steady day job. Hence, we are not dependent on this game and it does not necessarily have to be a success (mind you, we work hard to try to make it a success!).
This means we don’t feel the pressure of a deadline or the fear of empty pockets. We learned to overcome this pitfall by prioritizing often and by defining smaller, clearer tasks. Both these actions help us to keep focus. It also helps a lot to show Caromble! on game events. These events provide real deadlines that force us to improve the game as much as possible, because we want it to be as good as possible.
Another pitfall is that we keep underestimating the project’s scope. For a lot of projects this would be a danger towards project completion. As we don’t want to make any concessions to the game we envisioned. Our only solution for this is straightforward: we just have to work hard and motivate each other to keep going!
We are already proud to have come this far and we want to sincerely pay our respect to all those indie teams who have already finished one (or even more) games! We hope to join you this year!
Exhibit A – Crimson Owl Studios at an event; with Dennis de Bruin (Gamekings), Thomas D & Raymond (Crimson Owl Studios)
Exhibit B – Working hard