|
Caromble! is a fresh brick-breaking game in a 3D, physics-based dystopic world with an unique |
|
|
Game Development Blog:
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
Tomorrow it’s Caromble! time! On Thursday the 22nd of May (which is tomorrow), Caromble! will be played by Gamekings for Gamekings Studio in Hoog Catharijne, Utrecht, Holland, Earth. If you are around, or if you are so excited about Caromble! that you want to buy a plane ticket to see it live for 30 minutes, come visit us!
For people who cannot be there, here is a screenshot to keep you satisfied as well:
Almost every game will have lots of moving objects. From an animated deck of cards or a gun that’s reloading, to huge armies that are running around the screen.
In Caromble! we have plenty of moving objects. But most animations are pretty basic. Therefore, way back at the beginning of the development of Caromble!, the question arose “how could we make these simple animations look more interesting?”
When animating an object from one place to another, the first implementation is usually to move the object with constant speed to its target position. This will look very static and unreal because in the real world, objects will need to accelerate to get to a certain speed and decelerate before stopping completely.
Objects that move with constant speed from A to B will have a linear transition from A to B. We can define a transition as the relation between the difference in time to a difference in position (or to be more abstract, a difference in animation). This is often called tweening.
Transitions are not only used in games, but webpages make plenty of use of them as well. You can play around with transitions/tweens yourself.
Below you can see how it looks if we apply some transitions to the movement of objects in our engine:
I am back! This means that I was away, which I was. I visited Indonesia for four weeks together with my girlfriend Hanna. We went to Java, Sumatra, Bali and Gili Trawangan and it was quite the experience: it was great, exciting, different, itchy, inspiring, warm, far away. And I was completely cut off from my laptop with Caromble!’s source code, which was kind of strange.
However, I got some great news in the last week of my holiday: Caromble! is greenlit! As I read this news in my e-mail, I made a strange undefined sound and did a silly dance. I think the sound could be described as a combination of a screech and a high pitched sneeze from the mouth and the dance was inspired by the Batak dance (including some improvised little hops), I had learned on Samosir, an island in Lake Toba, which is a lake in a huge volcano crater #awesomeviews.
I celebrated this wonderful achievement with an Indonesian cocktail with Hanna. The Indonesians themselves also celebrated this achievement with lots of fruit and joy as you can see:
Fruit celebration for a greenlit Caromble!
Of course this was very nice, but I can’t wait to meet up with the team and party hard with some nice, well deserved Dutch (or probably Belgian) beers. I’m writing this in the airplane back to Holland, (yes, yes, technically I’m not back yet and the title of this blog post is incorrect. Get back to your cave troll;) ), where I would like to dedicate a few sentences to congratulate my team members:
Yeaahhhhh!!! Great work guys, we did it! Super awesomedary; greenlit tralalalala greenlit… Tralalalalalaa greenlit, altogether now, greenlit, padappapaadapa greenlit. Caromble!’s gonna be on Steam oh yeah oh yeah, on superduper Steam oh yeah yeah yeah..
So, now I’ve got that out of my system, let’s talk some business. We are currently working on polishing the game and improving the menu and gui to make Caromble! as solid as possible on all levels that influence the gaming experience. Now we have been greenlit, we will get access to the Steam SDK, so we will start implementing that as well. Also we are working on something that allows you players to experience some Caromble! very soon already. I hope we can tell you more about this in the coming weeks.
I want to thank everyone who has upvoted Caromble! on Steam greenlight. Thanks to you we can share our baby (because that is what this project is to us, nourishing it every Friday) with the largest group of players as possible. We will do our utmost best, to make sure that Caromble! deserves your upvotes and attention.
On the island Bali people were also aware of this great news and they sold these great souvenirs. I couldn’t resist buying one for the team ofcourse:)
Caromble Bali Art
Now we can finally say: Let’s get ready to Caromble! on Steam!
On this blog we talked about some of the graphics effects we put into Caromble!. We’ve talked about why we decided on using that specific effect, and talked about some considerations we’ve encountered when implementing and tweaking the effect. But we’ve never actually shown the code. Usually because it was complex, or because the relevant bits where a bit scattered throughout the source. But today there will be code. I’ll show you our chromatic aberration shader. Chromatic aberration is an effect in photography where not all wavelengths of light get treated equally by a lens. It is also the distortion effect shown below: 
So what you see is that all 3 color channels (Red, Green, Blue) get distorted in a different way. This happens in the following GLSL fragment shader (the corresponding vertex shader is trivial):
#version 150
uniform sampler2D RT;
uniform sampler2D NoiseTexture;
uniform vec3 distortionOffsets;
uniform float distortionTime;
uniform float distortionFrequency;
in vec2 vTexCoord;
out vec4 FragColor;
void main(void)
{
float distortion = texture(NoiseTexture, vec2( (texCoord.t + distortionTime) * distortionFrequency, 0.5)).r;
vec3 offsets = distortion * distortionOffsets;
vec3 color = vec3 (
texture(RT, vec2(texCoord.s + offsets.r, texCoord.t)).r,
texture(RT, vec2(texCoord.s + offsets.g, texCoord.t)).g,
texture(RT, vec2(texCoord.s + offsets.b, texCoord.t)).b);
FragColor = vec4(color,1);
}
That is all there is to it, and this is even a bit more complicated than absolutely necessary, to allow some hooks for creating animations with the effect. Let’s go over the code bit by bit and see what happens where.
uniform sampler2D RT; uniform sampler2D NoiseTexture;
Here we pass the render target that contains our scene, the other texture is a 1D noise texture I’ve filled with some Perlin noise.
uniform vec3 distortionOffsets; uniform float distortionTime; uniform float distortionFrequency;
These are the hooks for our animation system. The vector distortionsOffsets controls how much each channel is affected (and the direction of the distortion). So passing (1,0,0) would affect only the red channel. The float distortionTime is an offset into the noise texture, so we can vary the effect over time. Finally, distortionFrequency controls the scale with which we sample the noise texture. Keeping the distortionFrequency zero will apply the effect homogeneously throughout the image.
float distortion = texture(NoiseTexture, vec2( (texCoord.t + distortionTime) * distortionFrequency, 0.5)).r; vec3 offsets = distortion * distortionOffsets;
These two lines calculated the effect. We sample an amplitude from our noise texture, based on the y-coordinate of the input texture. This gives some sort of line-based feel (as if it were a video artifact). We add the time offset, to animate over time. And finally we scale this by the frequency. Now all we have to do is apply this amplitude to the offsets we’ve passed into the shader. Finally all that is left is apply these offsets to the input image, and return the result:
vec3 color = vec3 ( texture(RT, vec2(texCoord.s + offsets.r, texCoord.t)).r, texture(RT, vec2(texCoord.s + offsets.g, texCoord.t)).g, texture(RT, vec2(texCoord.s + offsets.b, texCoord.t)).b); FragColor = vec4(color,1);
And that is all there is to it. We have now applied an offset to all color channels. If you want to get a better feel of how this works, why don’t you plug our shader into Shader Toy and see what you can make of it.
A very happy update from the Greenlight front!
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.
