This game has been in our plans for quite some time. Initially it was just a platform game, with a lot of  jumping and running, which I like quite a lot, and there are some emerging games coming out with this sort of gameplay. I never thought of a character but one day I was doodling around in my sketch book and came up with an image of Bruce Lee wearing boxing gloves and like a firework of ideas exploded in my head. I could see him punching his enemies, kicking them away, and basically running really fast on the scene.

So after some thoughts I started roughing out an idea of what the gameplay would be like, and what setting would it be, the theme as well as the graphic style. I had some ideas, and the task now was to merge them all together in order to get them to work, and not be a mash of game ideas that really don’t go along at all.

Vlad had that concern when I explained to him the idea. He asked “is it a fighting game or a platform game” and really I didn’t know what to tell him, so I just went “erm… well… the… hum… let me get back to you on that one”. And I didn’t. I waited a bit more to let the idea grow and look like something that was plausible in terms of fighting and also in terms of platforms.

But the platforms weren’t really a gameplay element as much as they were obstacles to gameplay, until Vlad said “you know, if we had some physics in, it would add to the overall experience, if the player could interact with the scenery to progress”. And like the rug on big lebowski, that idea tied the game together.

Bruce Ali, a mix between Bruce Lee and Mohamed Ali, will be able to kick enemies off buildings, make stuff fall on them, and other fun stuff that I don’t want to disclose just yet.

As an appetizer, here’s a bunch of sketches from the Bruce Ali Sketch book.

What you see below is a simple FSM ruling the behavior of two fighters. Each fighter selects one of six attacks randomly, moves into position, attacks and steps back. If the fighter is attacked before starting his own attack, it has a 50% chance of dodging and then proceed to attack. If hit, after being in slight pain, it steps back. Everytime it steps back, a new attack is chosen.

The discussion I had with myself is if it would make sense to make a round based combat disguised to create the illusion of real time combat or a real time combat directly. Funny enough, I found it easier to make it real time directly.

More can be done in terms of complexity layering, but as a learning experience done with just some hours, I’m more than happy, so see you all later! Vlad is out!

p.s.: oh and cheer Marco for this character! It’s a long time favorite of ours, waiting for the right opportunity to pop up into the web!

User interaction grows on me in a weird way. Experience should make it easier, but as time goes by I tend to put more and more variables to the design stage. I want the player experience to be flawless.

Flawless interaction

In my humble opinion for the interaction to be flawless, the following requirements must be met:

1. Minimal interaction

The player’s effort to get something done must be minimal, except if that effort is part of the game’s mechanic.

2. Perfect feedback

The player’s effort to get something done must have its counterpart in the game that must perform the player’s order but also inform the player that the order was received correctly. If the player’s order is not accepted by the core rules of the game design, the player must be undoubtedly informed that it was not possible to perform the action and why.

3. Seamless integration

Both interaction and feedback must be integrated in a way that is natural to the game. For instance, if you have a very simple mechanic and the player action is not allowed, you shouldn’t pause the game and give the player a huge chunk of text explaining why that is happening. A simple sound and some red markings on screen should make it obvious for the player.

Our rules

With all of the above in mind, I look at our current project and decided on the following…

1. Mouse Hover

Every time the player moves the mouse on top of some meaningful element (usually a game token) the game will always produce feedback about the element. The feedback will always be presented in the same screen space. Information formatting will be as similar as possible to all elements, respecting the smaller differences between each element type.

2. Mouse Click

GUI buttons were created to remove unnecessary effort. As an example, given a large playarea where you’d need to find a game token, click it and choose a task by another click would involve the player searching for the game token in the map, clicking it, analysing a set of options and clicking one. We created GUI buttons where the player simply has to click the option he wants.

From the feedback point of view, the button will only be available if all conditions are met to perform the action of the given button. More, if the player hovers the button, information will be given in the determined info space to why the player cannot perform that action.

The only elements that involve two clicks are elements that interact with other elements. In this case, we opted to make the first mouse click select the element and make the element information fixed and then the second click on the element to interact with will create a contextual decision.

Conclusions

What is described above is already implemented in our current project. I predict some tuning of some issues regarding user interaction with the game but the results make the game feel ridiculously simple to play. My biggest question is if this feeling is only ours or if the players will feel the same.

See you all soon,
Vlad

Original AK Logo

This is really weird to write… because… Atomik Kaos, the original, was a bit of an accident. The whole design was ad-hoc without any kind of formalism. Each token was designed as it was needed.

So what worked and what didn’t mechanics wise?

Worked

1. The twist to the chain reaction genre: let’s face it, it’s a genre where A LOT can be done. Most games are about either angles or position of the game tokens. Atomik Kaos picked up in both angles and position. Angles by putting that variable attached to each token type; position by randomizing each token in the level.

2. Variety: here’s something that often lacks to these games. As far as I can remember only Starshine offers some variety. A bunch of special tokens were created for this game. They couldn’t be played directly but rather activated by the chains.

3. Goals: Each level had a different goal. Either destroying everything, destroying part of something, not destroying more than an amount and others. Sometimes it was just a matter of words and the rules underneath were the same.

Didn’t work

1. Black Holes are special atoms that suck up chain reaction particles. People just hated it and my guess is that it was not for the negative impact, as there are more negative tokens, but because it was not absolutely obvious how the black holes were sucking the particles.

2. Randomness and luck factor: I don’t believe that Atomik Kaos is a luck based game, quite the opposite. Problem is I’m not my audience and I played it a lot, something most if not all players won’t do. So the random factor of the game became a luck factor for the players and this worked as a downside of the game since on one hand it was frustrating, on the other hand it made the game too easy.