© epikur version 1.1

Designing a kfc computerplayer


(press ctrl+home to get back to the menu)


A discussion of how a kfc computerplayer could be designed.
The intention is to design a strong computerplayer, that doesnt cheat.

The computer should be as 'human' as possible to make it friendly for the human
because a human prefer computerplayers that think and plays as a human.


Although kfc uses the chess movementsrules and share many strategy aspects 
there is a big difference in designing a computerplayer in kfc vs. in normal chess.

Because a player can move multiple pieces at the same time, 
each piece should be thought of as an independed teamplayer. 

This is a big difference from a traditional chess computerplayer. As the game in kfc is in real-time,
the kfc computer should be designed analogically as a realtime teamplayer-game where each piece is a bot.

A bot should play as

Much of the positioning-strategy from a chess game can be adopted in kfc. 
Good piece development, controlling central-area, protecting each other, etc.

A turn in kfc is some x millisec value.
About 10 millisec should be suiteble, 
people react to events in about 20 millisec as the minimum reactingtime.

As the game progress, the kfc computer shouldn't calculate a deep decision-tree and choose a best path
as normally done with chess computerplayers.

Instead the bot should work together as a group, and the calculation of how many moves (when in time) 
it take a certain piece to get to a certain spot should be known. 
Some group of bots could work together at one area, 
And other group at another area. It depends on the situation at the chessboard.

A small, decision-tree could be used to see ahead in time.
It's best to use this technique when there are few pieces on the chessboard 
to minimize cpu-overhead from the calculations.

The computer is allowed to know all aspect of the timings on the chessboard. 
And where the entire pieces are exactly at the board and where they are moving at. 
e.g. when pieces can move again, is there enough time to safely capture, etc.

When a new move is made by a human, the computer should 'discover' the moving
after a certain small delaytime.

It shouldn't know the destination of a moving enemy piece. 
This would be cheating in the eyes of human player.

- Exception to this rule is the knightmovvemeent, this is always known.
- Exception to this rule, is if the humannplayer can't tell the difference and if this feature
is important for the computer to know in advance.

The computer should move at a rate of an average human player. 
It shouldnt be simultaneaously moving 6 pieces at once.

It should never be allowed to move two pieces simultaneaously.
The min delaytime between two piecemovements should be scaled of where these two pieces are.

The min delaytime for moving a piece at a1 and h8 should be larger than moving a piece from e4 and d4.


A piece should have a value to differentied the strongness of the piecetypes.  
The traditional values from chess could be used. But the value-status is strongly biased by the quantity factor.

The power of having more pawns than the opponent shouldn't be underestimated.
Quantity is better than quality when it comes to pieces in kfc. Three pawns can be deadly vs a queen in kfc.

There is no undoing for pawn-movement in kfc. Therefore the movement of the pawns should be wisely chosen.

Three good documentations about kfc strategy should be studied, 
to support bulding a good 'brain' for the bots. 

These articles are chosen, because they are the best of the few documentation about kfc strategy 
and the authors has used much effort to make a good wellthought documentation.

The hard part is building the teamplayer mechanism, where key aspect of kfc-playing is based upon.
e.g. combo-moving, take-and-defend, discovery attack, etc.

It's important that every bot know where the friends and the enemys are at the chessboard.
And what they are doing (moving, static or have an active delay).

A master bot, which is the teamplayer-brain
should issue orders to the bots when a teamwork action need to be done.

The bots could then either be in a 'make_your_own_decisition_mode' or 'teamplayer_mode'.

The master bot issue teamwork task to some bots, when the teamwork task is finished, 
they will be resetted to 'make_your_own_decisition_mode'

The master bot knows the kfc gameplay concepts such as combo-attack, discovery-attack, etc.
The mentiend docs above should be the guide to design the teamplayer-brain.

Knowledge of graph-theory and algorithm should be the big help to design this part.

It's a good idea to store some opening-moves in a database, where an random opening is selected.
This could be done by making the first move of the pieces be chosen from the opening-database.
Then after e.g. 4 sec, the computer is out of the opening-move state.