That'll Larn You!

I've been idling over this for what seems like an eternity now - time to actually write something down.

When is the Player due a bonus?

To answer this, we have to first set out exactly what we hope to achieve by giving out the bonus.

1. We want to make the game more complex, by giving the player a new option. This effectively ramps up the difficulty.
2. We want the player to feel happy that he has accomplished something.
3. We want the player to continue playing, at least until the next reward.

Now, the first option needs to happen peridically - slowly at first, while the player has enough challenges getting used to the interface and the normal gameplay. Then we want to start adding new things more and more quickly - after a certain point, everything the player does should trigger off some level of sparkly effect; all of the old moves have been replaced with new ones, and the cycle can begin anew.

The second options suggests that they should be given as rewards for accomplishing tasks. Those tasks should at least appear difficult - as long as the player can never go and do deliberately badly and STILL win. Effectively, we want to reward trying. Perhaps the rate at which the player presses buttons should be a factor? As the player gets more frantic, the probability that their next success gives a reward should increase.

The third option is the most studied. Basically, the player should be rewarded with a resetting incrementing pyramid. 1, 1, 2, 1, 2, 3, 1, 2, 3, 4, 1, 2, 3, 4, 5 etc.
Thus the time between 'better than the best you have' rewards increases, but the player still gets something every now and then, which lets them count up towards their reward.

So - when are we going to reward the player? Firstly - after key events in the game. These 'timed' rewards give a reward for actually progressing, and they can follow the 'go more slowly' pattern. But together the first and second give my "Wow" award. If the player manages to do better than they have currently been doing, then you reward them.

I'll do this with a 'ramp multiplier' system. A multiplier is kept, which goes up whenever you do something good, and slowly counts down otherwise. This multiplier is then applied to any points scored. So the first shot scores 10, the second 20 and so on. Fairly standard arcade-style scoring. A particularly bad action might jolt the count down, or even reset it back to the start.

Then we keep a count of the players average 'score over time' - assuming that the player gets more proficient as the game goes on, in general this average should slowly increase. But it won't do so smoothly - instead it will jump up and down, with peaks. If we apply a reward just after each 'largest' peak then the player will see two things. First that they just did exceptionally well, and second that they just raised the bar for themselves - but have a tool to help them acheive it.

What should they Learn?

Well - it would be ideal if what they learn were related to what they just did. So - for example, if the player just took out a room full of enemies, and ended by jumping and then kicking one it might be good to apply a special effect to that kick, and add a new 'jump-kick' special.

Similarly, if the player is in the middle of a fight when they get the award, and are blocking an enemy fire-based attack, awarding an 'anti-fire-block' move would seem sensible.

In both cases, the benefit is twofold. First; Immediate feedback - the player can see what they got, and they know what they did to get it. Second; Synthesis - the award fits the players style.

So - keep a record of what the player just did; and award special moves based upon that. Or alternatively, after you have decided to give a reward, wait a while and watch for the players next action. Perhaps it would be wise to give the player some visual feedback that they are about to learn a new reward in that case (to preserve the immediate feedback benefit)

One alternative was given in the 'example of play' document. The player would fight a badguy that had a large number of moves - one of which was the 'new' move that the player was to learn. The actions of that badguy would then teach the player the motions required to control the new move.

Yes yes, but what should it Do?

This is actually a lot easier. The effect of a move is going to be partially based upon the trigger sequence (a block should not fire off a dash, a punch should not become a kick etc.)

The 'sepcial' effects can be largely decided by what other abilities the player has learnt. If the player has level 2 abilities in every element except fire, they should learn a fire ability.

This progression can be controlled as a plot - it doens't matter how slow or fast the player moves through the abilities, they will learn them in the same order (this order should not be entirely fixed, some randomness is appropriate)

Note: The best way to complete this would be to adapt the enemies to the player, rather than the other way around. A sensible (but short) time before the player learns a new fire defence - the enemies start using more fire attacks.

Try not to be as blatant about it as most CRPGs are though.

As for how it should look - pick a special effect or two, layer them together and forget about it. The player will usually be stringing special moves together one after another anyway.

The exception to this is plot techniques. Effects that are required in order to progress past a certain point must be awarded before that point. These will presumably be entirely scripted.

Also "speciality" attacks, awarded by using a single attack over and over and over {I am conflicted about these, I don't want to give players ANOTHER reason to be boring} should usually have an animation based upon the original - but capped with a BIG special effect.

Ok - that's what. Now how.

Well,actually adding the technique in to the "When in this state cause this effect" tables is easy for a one step technique - and as long as we only build on pre-existing moves to create new ones (ie. adding a single step) it stays easy. So let's do that.

One remaining problem is deciding how 'tight' the input position should be. If only a single frame accepts the new input, then it will be almost impossible to pull off the move. Conversely, if too large a range is chosen then the move will be too easy to perform; and may even be selected inadvertantly.

Humm. I don't have any easy answer for this. The game could keep a running count of how accurately the user triggers other moves, and use that to progressively tighten up the requirements for later moves, but that doesn't take into account that different sequences may be present for different lengths of time - some sort of scaling would be required.

Actually, maybe I do have an easy answer, and that was it. Goodness, can anyone tell how far ahead I plan these columns?

Teaching Moves

The "Gray man observes the player doing somethig spectacular, gets chased and inadvertantly teaches the player a new move" sequence I *like* But to support it I need one final thing. I need to be sure that the player can recognise the keystrokes required to duplicate an action.

This isn't as obvious as it sounds - the player is used to seeing his avatar mostly from behind and may not recognise the actions from a mirror image point of view.

One solution might be to offer a 'window-in-window' view of the opponent from behind.

Another would be to show icons as to which buttons to press - that would make the mini-game more arcade-like, which isn't really the intention. (Although a 'DDR style' minigame would be possile, assuming that direct duplication of an opponents actions would result in cancellation of damage) I'd prefer some more elegant solution.

Simle moves (jump, kick) are going to be obvious to the player. Shiny sparkly moves should also be familiar to the player. The only cases that are really going to be hard to notice are:

1. Moves that the player technically posesses, but rarely uses and does not remember the combination to trigger them.
2. The final 'trigger' to the new move - the player has no prior knowledge, and it isn't always going to be obvious that the enemy initiated (for example) a punch before all the sparklies happenned.

Case one is easy to avoid - simply monitor the players moves, and have the enemy mostly use moves that the player likes to use. With a properly set up matrix of attacks effectiveness, this would also tend to make enemies effectiveness level consumate with the players skill level. (ie. skilled player causes harder enemies)

Case two is harder - and I don't see any way to avoid the player guessing randomly except by giving them a visual clue. Perhaps overlay the sparklies with another image of the move that would occur if there was no special trigger? Perhaps have the enemy attempt the move several times during the battle, but muff the timing? The first might be too hard to see, the second might be too subtle, or give the player too many other opportunities to beat the guy.

I think perhaps it will be acceptable to give a clue on the HUD in this case.