Archive for the ‘Mechanics’ tag

A small fighting AI test

Although me and finite state machines are good friends for sometime, implementing a more in-depth artificial inteligence algorithm is something I’ve been looking forward to test for some time. I did manage to take sometime to do some learning and testing and I’d like to share the results with you.

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!

Thoughts on user interaction

Doesn’t matter how many games you’ve made or how many tests you’ll perform, you’ll always have a lot of doubts when it comes to how to put the interaction in your game feedback loop.

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

Atomik Kaos Mechanic Post Mortem

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.