Category: Game Design


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?

 

 

Evolution of Caromble!

Last week, we stumbled upon some old gameplay videos of Caromble!. It is fun to see how the game has progressed over time. Some feature changes I couldn’t even remember. For example, I forgot we ever had red bumpers. This made me curious and I looked for even older footage. The oldest video I found was from INDIGO 2011, where Caromble! was playable for the very first time. To show the evolution of Caromble!, I created a small video to show the different versions side by side, with the same levels being played:

The most striking difference are probably the graphics. The paddle is different, some better lighting is added and of course, newer textures. Also, we’ve improved some of the feedback to the player: the paddle reacts to its own movement and ball collisions, we’ve added camera shake and there is an effect when a ball hits a wall. Gameplay wise, you can see that the camera is positioned higher in the newer version, which gives a better view of the action.

I must admit that I kind of liked the very fluorescent yellow boxes in the older version. Because of the higher contrast with the floor, they really stand out as something you need to destroy. However, with a more ‘realistic’ style in mind, we felt that those kind of boxes wouldn’t fit in anymore. Mmmhh… perhaps we could still squeeze them in somewhere:)

We are working steadily towards the next step in the evolution of Caromble! and expect to bring Caromble! ‘Sapiens’ into your living room in the beginning of 2014. Stay tuned!

Creating Challenging Challenges

Nowadays, games cannot be taken seriously without having unlockable challenge levels. Ok, it’s probably not that extreme, but it can be a great addition to your game for several reasons. It can present extra content for hardcore gamers that want to unlock everything, encouraging multiple playthroughs. It can also help to engage players and spice up the gaming experience by deviating from the core gameplay. But for us there is an extra reason…

What all game developers probably recognize, is that you can think of too many cool features for your game. When we were in the beginning (read: ‘more than a year later’) of the development of Caromble!, we realized that we had too many features planned for the game. Almost every new level would introduce a new gameplay feature. Finally we became smart enough and decided to choose a list of features to implement and just leave the rest be (I miss you so, oh ‘gravity switch’ and ‘teleporter’). This turned out to be a good decision (still I’ll never forget you…). There is so much more we can still do with our current set of features, that I believe we could make a hundred more levels with these, without becoming repetitive. It is a pity though, that some of the cool features we ‘invented’ are not in the game. But thank goodness we have some unlockable challenge levels!

Caromble! features 24 story driven levels, these are at the heart of what Caromble! is. When certain targets are met in the story, a challenge level is unlocked. A challenge level is a small simple area, in which the player gets one specific task. These levels can be crazy strange and each one stands on itself. No rules, just fun! This allows us to introduce a new feature only for that level. And why not, everything is possible in the HAVEFUN (Hypnotically Abstract Virtual Environment For Unconventional Needs (name suggestion pending)); the simulation room in the mothership designed for training purposes (story pending).

The tasks in the challenge levels range from: ‘hit as many blocks in 1 minute’ to ‘survive as long as you can with a single ball’. These challenge levels provide small ‘snacks’ (as Mark Overmars (professor and creator of Game Maker) once called them in one of his lectures on game design) that allow for a quick play, but are very entertaining for the thrill of beating the highscore. Some examples of ‘snack’ games that are very addictive, partly because of the highscore aspect, are: Jetpack Joyride, Super Hexagon, Super Cratebox and (why was I addicted to this?) Bookworm Deluxe. If the challenge levels in Caromble! provide some of the fun and addictiveness that these games have, I’ll be very happy.

As challenge levels are not part of the ‘core’ Caromble! experience, we work on them in our spare spare time (first spare time is reserved for core Caromble! tasks). Last week I had some of this precious time and created 2 challenge level prototypes. For now I call them WallSafety and BallFrenzy.

In WallSafety the player gets one ball, and one ball only, and is burdened with the task of surviving for as long as possible. The score is given by the seconds survived. The catch? The level sides are made of blocks that are destroyed by hitting it with the ball 1-3 times. Behind these blocks awaits nothing more than emptiness, thus death:

 WallSafety

 

In BallFrenzy the task is to have as many balls in play after 45 seconds. Each block that is destroyed creates another ball:

 BallFrenzy

These challenge levels provide a different gaming experience than the core gameplay and hopefully give Caromble! extra appeal. They are fun to create (because it is so simple) and fun to play (because it is so simple). The objective and scoring mechanic are very transparent and perhaps this simplicity makes it so fun. Games have become much more complex over the years and I think that sometimes we long for the simple gameplay of the old days. In that way, games are a nice analogy for life.

 

Long Lost Code

A while back we hinted about it: Boss Fights. Originally, the idea was that the virus shards were items you would collect to progress through the game. But after a long discussion we felt that this was typical behavior seen in so many other brick-breaker games. We didn’t want the virus to be stationary, we wanted it to take the fight to you!

So about that fight, well, I really do not want to spoil everything before you get a chance to play the game… Previously we got inspired by games like Pinball, this time though, we looked at SCHMUPS (Raptor!) and even games like Pong. While Arkanoid will always have the most evillest boss out there (DOH!), after a few days of programming, our (still nameless) boss is shaping up to be a pretty good challenge.

When we started building our game engine, many, many years ago. We were trying to build it as generic as possible (trying to be able to support fps/race/etc -basically all games). For some part, this was a waste of time; When we started working on Caromble! we quickly gained a lot more focus and improved the engine on areas needed for Caromble! -finally making some serious progress.
But not all was lost, because for the boss behavior we could reuse code from years back that still proved to work just fine. For programmers like us, that feels awesome!

But enough with the sentiment, we finally got our Etoo London interview online, check it out!

And again, if you’re going to Gamescom and want a go at Caromble!, just let us know!

Like a Boss

“DOH”!

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 BulletJBullet, 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.

Are both words that would give you a lot of points if you were allowed to use them in Scrabble. They are also (amongst many others) the building blocks of Caromble!.

For most of us, Caromble! has been the first real game we have ever worked on. The Caromble! editor is also the first level editor most of us have ever used. Since we are not using an off-the-shelf game engine, we are also not using an existing editor. We would have to create our own editor as we went along.

A screenshot of the editor. The red boxes are actors, which control the game-play  The lines indicate the relations between the objects. This system will make the camera switch position as the ball shoots over the ramp.

A screenshot of the editor. The red boxes are actors, which control the game-play The lines indicate the relations between the objects. This system will make the camera switch position as the ball shoots over the ramp.

The editor (as we call it) grew (and grows) along with the game. I would say in terms of age the editor is now in its puberty. To be more precise, the editor is in that stage of puberty where body parts lose track of each other and start growing at their own rate.

For a piece of software this means that some functionality is mature (like the stuff Raymond wrote about two weeks ago), and some other stuff not so much. It wasn’t until about a year ago that we added some sort of actor system, that allows you to control object interaction from within the Editor.

The late addition of such a core system lead to an explosion of all sorts of exotic actors with even more exotic names. Those in the title are firmly among my favorites.

To return to my analogy, puberty is a crucial phase of development, although it can be challenging at times. Because we needed the actors, this part grew a lot and right now is  a bit out of proportion. As the Editor ages and eventually will reach adulthood, everything will grow back into proportion.

Right now we are focused on creating game-play, and the editor doesn’t get all the attention it deserves. We’ll give it that attention before (and if) we release it (after we release the game).

 

 

Heavy stuff

Using a physics simulation to drive important parts of the game can have some unexpected consequences. Caromble! levels often start small, and the size increases throughout the level. Initially we had the ‘bug’ that at large scales, the physics felt very slow. Almost like buildings would collapse in slow motion.

Easily fixed I thought, if the buildings don’t fall fast enough, I’ll just make ‘m really really heavy. Simple!

Except that it didn’t work. After a good afternoon blaming the physics engine, I finally sat down and did some thinking.

What if we take two imaginary, identical balls, and a 100m tower on a wind-still day. We fill the first ball with lead, and leave the second ball empty. At the exact same time you drop both balls.

Now the question is, which one will hit the ground first?

Quite unlike I expected, they will hit the ground at the exact same time.  Why? Because of Newton of course.

The formula for the speed of a falling object (on Earth) is v = gt . So the velocity is the amount of gravity, times the time the object has been falling. The mass of the object doesn’t come into it at all.

So to come back to Caromble! Heavy buildings don’t fall any faster than light buildings. But increasing gravity will do the trick.

Proof:

Q.E.D.

Charge me up Scotty

In Caromble! it is possible to charge the paddle and give the ball a boosting power such that it will not bounce off objects, but goes right through them. Adding the charging mechanic would make the gameplay more interesting and gives high-score hunters more possibilities. However, we have been struggling with the implementation. How can we strike the right balance between a powerful powerup and not making the game too easy?

In our first implementation, the paddle could be charged in a continuous manner; the more the paddle was charged, the more boosting power the ball would get. If the power was maxed out, we would not only boost the ball, but also give it the ability to crash through objects, instead of bouncing off them. As a trade-off for using this power, we reduced the movement speed of the paddle significantly, making it far more difficult to reach the ball.

For some reason, this did not feel right. Blocking the paddle was too annoying, and it seemed impossible to find the right speed for charging. Either players would charge all balls, or none at all.

Also it felt a bit gimmicky as it was not needed to complete any levels.  To solve this we introduced hitable blocks that could only be destroyed with a charged ball.

Now, after several tries, we finally found an implementation for the charge mechanic that feels in place. Instead of boosting the ball proportionally with the amount charged, we only have two possibilities now; the paddle is either fully-charged, or it is not charged at all.

Pressing the charge button (LMB or SPACE) fills the charge meter. While  charging, the paddle cannot move at all. When the button is released, the meter empties quicker than it was filled. If the ball hits the paddle when the charge meter is not full, nothing  happens.

However, if the charge meter is full, the paddle is charged, and stays charged until the ball is hit. The charge button can be released, and the paddle can move freely. Having the possibility of aiming the ball whilst being charged, seemed to be the missing piece of having a good charge mechanic. It works and feels good. Now all we need is an awesome graphics effects for charging the paddle and boosting the ball.

Because pictures tell more than a thousand words, here is also a video of the Charge mechanic (charge meter in upper left corner):

Meaning of Life

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.