A board game.
The goal is to trap the other player on a single square.
On each turn, the player can move their piece one square, causing a hole to appear beside their opponent, or jump their piece two squares (possibly over a hole), leaving a hole where their piece was.
There are different options for play:
- two player, one controller (pass the controller back and forth between turns)
- two player, two controllers (each player has their own controller)
- one player, easy AI
- one player, challenging AI
You can choose from a number of board layouts. If you download the cart is easy to add your own board layouts with the sprite editor.
In the menu, use the direction buttons to move between menu entries, and the X and O buttons to cycle through the options of menu entry, or perform a menu action.
In the game, use the direction buttons to move your piece, or hold down the X or O buttons and use the direction buttons to jump your piece. Use the pause menu if you want to abandon a game and return to the title menu.
Gameplay screen shots:
Drawing a board layout in the sprite editor:
I’ll see what optimisations I can apply within Pico-8’s limitations.
The more options I add to the gameplay (to make the game more fun), the more time the AI has to spend searching for the best move. But the AI doesn’t search in an optimised way at all, and may evaluate the same game state multiple times.
I'm not sure of the actual mechanics behind the brain but may I suggest that before the game begins, the opponent has invisible scores placed on the board based upon accessibility and maneuverability.
Only adjust the scores slightly based upon missing tiles.
Then the brain-work is already done and moves can be instantaneous and intelligent.
The AI is implemented using the negamax algorithm with alpha-beta pruning and a heuristic that tries to estimate maneuverability without using too many virtual CPU cycles. This algorithm lets the AI player select what it considers the best move in reaction to the human player's moves.
There are a whole bunch of optimisations that can be implemented. Whether they result in a speed up in practice will depend on the way that Pico-8 constrains the program's use of memory and CPU. I'll have to experiment to see what works best.
Reading about NegaMAX. That's a bit of a brainweave. Seems like you're quite knowledgeable on the implementation.
How about this ? Is it possible to speed up the algorithm by seeking only the surrounding tiles of both player and computer as they can only each move one tile ?
[Please log in to post a comment]