Most people will interpret this as Homer Simpson’s catchphrase, but that’s actually spelled as “Do’h”. For me, and perhaps most Breakout fans, the story of Arkanoid comes to mind. Arkanoid’s almost unbelievable story goes like this: Vaus is the space vessel that escaped the ill-fated mothership named Arkanoid – hence, the name of the game. That vessel acts as the game’s focal character: the paddle. After some rounds of brick breaking awesomeness the player reaches the final round where the goal is to demolish the ‘dimension-controlling fort’ which is named… “DOH”.
This illustrates that a Breakout game can have a story to add to the overall experience. In an earlier post we promised to put in boss fights. We didn’t initially plan this – in fact, we rejected boss fights earlier in the development process because we didn’t see how it would fit into Caromble! – but as art, gameplay and story developed, the boss fights seemed to find its way back onto our agenda and seemed to fit right in. Storywise the paddle is our so-called protagonist, the lead character whom the player can identify with. Opposed to that we have the boss as antagonist, the character that (literally) creates obstacles that the protagonist must overcome. Throughout all aspects of the game the idea of protagonist versus antagonist is a nice contrast to elaborate on.
Caromble! is almost gameplay complete now. The boss fight is one of the latest gameplay features that we are still experimenting with. Despite the fact that we rejected boss fights earlier in the development process we are really excited that we put this element back into the game. Finally we arrived at the point that we can proudly say “THIS is Caromble!”.
P.S. For those wondering what Arkanoid’s “DOH” means. If my Google skills are okay it’s an acronym for ‘Dominator of Hours’. I guess this knowledge will score you some nice points in your next video game themed pub quiz!
Since I was a kid, I loved to create something huge with Lego blocks and then… destroy it. Or make a huge card house with my grandfather, like 7 stories high, and then… make it collapse. I’m not unique in this. Many people seem to like destruction, witnessing the several popular scientific television shows in which objects are blown to pieces or dropped from a crane.
I think that besides seeing things collapsing, people find it even more satisfying to be the cause of some kind of destruction. Whenever I see a structure of domino stones, my fingers itch and I want to be the one to tip over the first stone. I think we love to be the first part in a causal chain. I’m not sure why we love it so much, but perhaps it creates a feeling that makes us extra aware of being alive. I experience a similar feeling when travelling by bus. Whenever I need to press the stop button, I also want to see the stop sign lighting up because of MY button press; “Yeah, I did that!”. Perhaps instead of “I think therefore I am”, the statement “I cause therefore I am” suits us better.
Caromble! is in its essence a breakout game. A game in which the player moves a paddle, aims and bounces the ball, hoping to destroy some blocks. Somehow it so much more interesting if one of these blocks was supporting a big structure that is now collapsing. “Yeah, I caused that… again!”. That specific feeling, that is the added value of incorporating a physics engine into Caromble! in my opinion. The core gameplay may not always be very different from an ‘ordinary’ breakout game, but the fact that the player can be the first step in a causal chain that leads to destruction, explosions and chaos , makes the experience so much more satisfying. Here is an awesome video from OK Go that demonstrates this idea through a Rube Goldberg machine. And how satisfying does this look (we use the Java port of Bullet: JBullet, for our physics)?
The interesting thing of incorporating a physics engine in your game, is choosing when and how to intervene in the physics simulation. Without intervention (moving, creating or destroying objects in the simulated world) there is no gameplay. In Caromble! the single action a player can perform (besides using power-ups) is moving the paddle. With the paddle, the player can influence the most important object in our game; the ball. The ball is a peculiar object. It takes part in the physics simulation, but it is not totally governed by it. If that would be so, friction of the floor with the ball (which both are not zero) would eventually result in a ball at rest (zero velocity). That would be quite a boring game. That is why the ball is governed by more rules than those of the physics simulation: OUR rules.
For example, each level has a desired ball speed. Whenever the ball speed deviates from it, we make sure it quickly converges to the desired one. Also, we handle all ball collisions ourselves. The collision detection is done by the physics engine, but based on the ingoing direction and the normal of the object at the collision, we determine the outgoing direction of the ball ourselves. One of the reasons we do this, is to ensure that there is some minimum bouncing angle. Whenever the ball bounces almost horizontally between two opposite side walls, we don’t want it to take forever before it approaches our paddle again.
Finding the balance between simulation and intervention is quite the challenge. Sometimes, mostly after heated discussions, we decide to add a new intervention rule to our physics simulation for the sake of gameplay. How far should you go with this? Well, we think that you should aim for a certain level of control for the player, such that whenever he/she loses a ball, it should have been possible to prevent this using skill. However, the simulation should add a factor of unpredictability and surprise. You know that once you hit that one block, that structure will collapse, but how exactly, that should be somewhat of a surprise. We aim to get this balance right and I think we are on the right track. As long as Caromble! will make some of you players experience the feeling that I got when tipping over a Lego structure, I am very satisfied.
Up to this point the background story has been our neglected child. She has become a wild beast. But now we are walking her back from the forest and we begin to tame her.
I hear you ask: “Why does Caromble! need a background story?”. The answer is quite simple and binary. Concerning stories there are 10 types of gamers. Those who ignore the story, just play, and find that beating the game is its own reward. And those who want an explanation for what they are doing.
But that’s game design theory speaking. The real reason is that we love stories! Every Friday we come up with tons of new game ideas, backing them up with a story as we sing their theme songs describing new fantasy worlds. Games in general are about doing stuff we can’t do in the real world.
Caromble! will be about good vs. bad alien ‘viruses’ in an earth-like environment. That leaves us with more than enough ingredients to write a wonderful background story to reward our players looking for meaning in their games and lives.
About time to post some concept art, that’s still waiting to see the light of the internet. Some time ago we decided on the chapters we will have in the final version. These have to look consistent with each other, but also distinguished as different themes. Add to that that the gameplay itself uses colors too (the common red explosives for example), and you have quite a complex setup to plan.
Since the gameplay also evolved organically, it dawned on me pretty late that each part should have a clear color code. Here is the setup I sketched out:
The bumpers are blue, and the borders, that the player can’t destroy are yellow for example… this might not need to be explained to the player – but tell him subconsciously what he can do in the game.
Here you can see how it works in the game so far:
The strong colors of these elements make it hard to get all the rest work well with the subtle colors I wanted. But gameplay goes first. I’m actually thinking to try black for the “indestructible” border – might be more consistent with the black outlines in the artworks, and allow yellow to be used for other parts, like highlighting important structures.
After that then I approachd an overview of the level art – with more muted colors. And specific shapes for the different chapters. For now we’re going only for the factory and the commercial area. … and now comes the hard part to get all this nearly like it into the game.
After we picked the red style from the last post, it was time to come up the paddle design. Here are some possible versions.
We currently have a dummy of version K in the game. Some research also went into how paddles look and behave in other breakout games. I was really surprised to learn that most paddles nowadays don’t use proper reflection. But that makes them way more controllable. The worst problem is really when the player hits the ball and it still goes out – that feels unfair.
So in our push to get a new demo together we’re also adjusting some gameplay. For one we want to give the player a clear goal what to aim for in a level.
Our idea is to add an alien artifact, that crashed in each level. The player is basically the alien rescue team. Here are some ideas for how the design could look.
It has a clear contrast to the world, to be easily spottable. It also gives us an excuse to make the goodies easily spottable. Red looks nice – so we’ll run witht hat, but we might have to use more colors for different goodies.
The last update is a while ago, but there has been nice progress. Most importantly the programmers have been very busy with the editor, as we planned after our Indigo-reviews. We have now a working tool to build levels without working only in abstract text files. There are bugs left to fix for sure, but new levels will pop up here soon.
On the art side there have been mostly changes to the existing assets. Lot’s of boring resizing. But it was necessary, since the whole setup in the demo didn’t quite work. The steps will be always in multiples of four – its easier, and more logical. (Interestingly – after figuring this out with lots of number crunching, I learned that four is a recurring number in “Scaling Laws In Biology And Other Complex Systems“.)
Some gameplay tweaks are in already and just need tweaking and extending. For example the spin idea mentioned in earlier posts.
A new gameplay mechanic: the spin ball.
And some features we’re planning still, if we get around to it. One of them is to let the people in the game run away from the ball. Should make it a bit more livelier, relatable… and fun! Who doesn’t like chasing little scared humans with a wrecking ball?
The other week the Caromble team met up to exchange the experiences from the Indie-event and think about where to go next. So now is the perfect time now to reassess before committing to a more final direction in development: Our prototype is far enough to judge the players reactions, but still early enough to change direction if necessary. And we had a lot of input.
The main things we want to figure out now is how to move on commercially: We all agree that we would love to make some money out of it. Maybe early investments (not just after we’re done), so we can put it in the development.
We also want to try some more gameplay tweaks – we have the chance now to still test around. The main mechanic is too simple, we should at least allow more interaction for better players.
Taking aside the problems that result from presenting a prototype (missing content and features, lack of consistent quality, not much guiding of the player), here are the points we agreed on from the feedback.
It is already a lot of fun, so the basic idea can stay. In my experience early prototypes are often more of a drag (because of the mentioned shortcomings) – Caromble is a positive exception.
It ran really stable. After some trouble setting it up, I don’t think we ever had a crash or performance problems.
The art style can stay. Also the decision of the scenario with the cities got really positive reactions.
The music worked well.
Indigo - yet another picture
Since that is the last roundup: A thanks goes again to the game garden for letting us show our game at thier event.
The art is too inconsistent. The idea with making it comic-style is not getting across enough. Funnily it seems I put too much work into it. All the assets I rushed for the event got the most positive feedback. I could write a whole article about the state of confusion and dilemma that puts me in – but I spare you.
The sounds: There was not enough variation. They were not convincing enough. But we knew it, since it was a bit rushed but still there is much work ahead for us.
Several things caused confusion, that we ourselves didn’t even see anymore: The pink blobs that fly to the player. We should remove them or make them useful. We have to add walls to the level, to make clear what the ball reflects from.
The slogan has to change – heh I liked the joking “yet another breakout” – but some people took it seriously. So we’ll have to come up with something more positive. No ideas yet.
So the plan: Fix the problems, add a deeper layer of gameplay and get the level editor going. Then we can test around more, and create a playable version with more levels. Once that all works, we can show it to publishers or even publish it as beta on the website.
We’re working right now on the content for the Indigo – that means getting the first level nicely playable. One thing we will have to do (possibly later though), is to rescale the layout of it. My concept just totally underestimated the size differences between the small scale and the big scale (we want to go from small crates up to destroying skyscrapers).
Here is a sketch just visualizing the size progression:
So instead of this:
We have to do something more like this:
This is very different from usual breakout games. They are very “top-down” usually – not going into height at all, even if 3D. So this will be a gamedesign challenge, to get a more vertical gameplay working. It has advantages though: The top-down camera is not very impressive – so if we can manage to change the angle, then the look of the game will improve. It will also set us apart of existing games.
On a team meeting we decided that we should set a proper goal. One level that we aim to finish as a prototype. Taking gameplay and style into account, I’ve made a sketch of a bigger level. It should show the size-progression well, and also use for example some custom physics shapes – in this case it is a twisted ramp (the road in the picture).
We decided to go for this. Also Pascal found this photo you see below, and suggested to use it for the style. This really nailed it – somehow totally what I imagined too. So from now on I took this as my main reference.
Later just by chance I came across the picture again – it’s the Chicago industrial area, from the flickr-account of the library of congress.
Also somehow in my head the style had a much more desperate and kafkaesk look to it – and this image fits so nice to that. But the first version of the level concept fell short of it. So I redid the design – and made the following two color versions, so the team can decide which way to go.
I love the white look – and one day I wanna make a game with that. But for now we all agreed to go for the colored one.
The idea is that that you would start in the little corner where the farm is. And first clear out food-boxes and helpless chickens. In the next step you break out of the wall, then progress to the next wall. After you destroyed the city below, you can unblock the ramp, and finally attack the skyscrapers on the very top.
…which at the very end leads to some nice special effect. I sketched out how flowers overgrow the whole rotten city. We will have to see if we can actually pull this off in the final version.
I’m not 100% satisfied with the look. It should get more of a Metropolis or Gotham City feel. So I will work on this in later concepts.