I'm writing a small game in Java for undergraduate students in an Artificial Intelligence class. The game does not have direct player interaction; instead the students program bots in Java (by implementing a Bot Interface I wrote) and the game pits bots against each other. One of the requirements for the game is that it be fairly simple. The idea here is a lesson on implementing some simple AI concepts, not to have students figure out complex game mechanics. The problem I've run into is that the designs I come up with usually have a very obvious dominant strategy. For many of them, you could write a simple expert system in like 20 lines that would be extremely successful. So I've sort of gotten lost in trying to balance simplicity and requiring some interesting decisions. I'd love some advice on where to go with this game so that it's simple, but some interesting bot strategies still exist. Here's the basic design, which I'd prefer to stay fairly close to: -Only 2 bots compete at a time. -The bots are placed on a world which is just a grid (probably 50x50) of squares. Each square can either be an empty space (which permits the bot to occupy it), or a wall (blocks movement). -Bots play ~100 games against each other and the game reports the results. -The world is randomly generated at the start, but the map doesn't change between games (so all 100 games are on the same randomly generated map) -The game is turn-based, but bots take simultaneous turns. That is to say, each bot receives the current game state and then returns an action to take. The game resolves both actions as if they happened at the same time. This process repeats until one bot loses (or X rounds have elapsed; probably 1000+ rounds) -Bots can take a series of pre-defined actions. These include moving (up/down/left right), shooting (up/down/left/right), or doing nothing. -Bots don't have a facing direction. -There is some time restriction on how long a bot can consider their next move, probably close to 1 second. Here are the details in the current design, which I'm not really confident about: -Each bot can only see the area immediately around it (5x5 or 7x7). -The map loops like pacman, so you walk off one side and appear on the other (this isn't indicated to the bots at all, they just see the squares around them like normal) -There are 3 "classes" of bot, which can be selected at the beginning of the round: One shoots lasers, one lays bombs, and the third is an explorer. -Lasers instantly travel in a straight line from the bot, in the direction fired, until they hit a wall. Any bot in the path loses that round. -Bombs are dropped on a square adjacent to the bomb layer, in the chosen direction, and an enemy bot stepping on that square loses the round. -Bomb layers can only lay 2 bombs; laying a third makes the first one disappear. -A laser-firing bot only has 4 shots. Once it shoots 4 times, it has to wait 4 turns before it can shoot again (like a recharge. this is to prevent hiding in a corner and just shooting every turn) -A bomb-laying bot has to wait 2 turns after placing a bomb before placing another. -Explorers win a round if they occupy every empty square once (traversing the whole map minus walls) -Bots can change which class they are between rounds if they like. -Not quite sure if bombs are visible to other bots or not. -Lasers destroy bombs if the shot passes over one. Originally I wanted to limit the game to just shooting, no bombs or different classes at all. But I couldn't figure out how to make it interesting. For example bots would just wander around, and when they see each other they can either try to shoot or dodge shots. Either bots would be able to run away too easily, or it would be impossible to run and trivial to get a draw every time. Some other things I've considered are having collectible power-ups spawn on the map which grant powers like being able to see the entire board, or having your shots occupy 3 rows/columns instead of just 1. But then the game turned into a "figure out where powerups spawn and get there first" when spawns are static, or "explore the map until you happen upon the powerup first" if spawns are random. Maybe I'm thinking too hard about this? Perhaps having dominant strategies is fine? Maybe the powerup system is fine, even if it's just an exercise in mapping and/or pathfinding? The current design with the laser/bomb/explorer system is kind of like a rock-paper-scissors situation I think. Lasers beat bombs, bombs trivially beat explorers, and explorers beat lasers. So after implementing the basic strategy for each class, the meta-strategy would be to figure out how your opponent is picking jobs and beat them at it within the ~100 games. Anyway, sorry for the length. I just thought I'd post this here to elicit some feedback. Any advice at all is much appreciated. If anything needs clarification, don't hesitate to ask. Thank you.

There was an old game called PCRobots that I played (and learnt to code in C with). The idea of this game was similar to yours. You could program the robots to move around a map and fight each other to the death. You had various attributes and functions of the robot you could use to these ends (scanners, missile launchers, invisibility cloak, batteries, solar cells, etc).

There is a more modern (and open source) version of this called Roboships (http://roboships.sourceforge.net/).

In both of these, the game was "real time", in that the game would continue on even if the robot didn't do anything.

The main problem with your design I can see is that you have to pick your robot before the round begins and before you can know the strategy of your opponent (what bot they picked). Then once the match has begun you can no longer change your strategy.

the game is no longer about what the bots are doing, but which one you picked, and as this is up to the person, the bots can have no influence on the outcome.

So as a player, if I pick mine layer as my bot, and you pick explorer as your bot, then the outcome of the game is already decided and there is nothing the bots can do to prevent it. All I need to do is drop a mine somewhere before your bot as been there (on my first move) and I win. There is no AI code that can prevent my winning that match.

What it means is everything that you ahve designed for the operation of the bots does not influence the game at all. The same game could be done with a Scissor/Paper/Rock selection of a menu.

What you need to do is to allow the bots to make choices within the match that will allow them to influence the outcome of the match. this way the AI code that is written for your students will effect the outcome of the match and thus create a real test of their knowledge and coding ability.

What about this idea:

Each robot has:
- Powerplant which produces power

- Engines which allows movement, the more power put into the engines the faster the robot moves

- Electro Pike: this weapon delivers an electric jolt like a taser to the target robot but can only be used when next to the target robot. This is an instant hit weapon. The more energy put into this attack the more damage it does.

- Plasma Launcher: This weapon fires a slow moving bolt of plasma towards the target location passing over robots but not walls which explodes in a 3X3 area burst doing full damage to each square in the area. The more energy put into it the faster it moves and/or the more damage it does (robot's/player's choice).

-Shields: These constantly take energy to use and only protect against one side (but multiple sides can be put up at a time - essentially it has 8 shields). the more energy put into the shields the more damage they can absorb. When they absorb damage it reduce the amount of power assigned to the shield which means they need to be recharged by moving power to them which takes time and means the robot can't do anything else because of the limits on power movement).

- Radar: This sends out a radar pule that lets the robot now what is around it. The more power put into the pules the greater the range of the radar. The pules returns on the turn after it is sent and the player/robot must make a call to detect the radar pules to be able to detect it. Sending out a radar pulse may alert a robot to your location up to twice the distance you can see if they check their radar when you send out a pules.

A robot can move power from one system to another as an action (power can only be moved from a single system to a single system and only at a certain amount each turn), activate a system (eg: fire a weapon, send a radar pules), move (a distance up to the power in the engine system) or detect radar pulses.

Robots can now change their strategies during the match to adapt to the strategies the other robot is attempting to use. the restriction on changing power from systems means that it takes time to change from one strategy to another. This allows the robots to change strategies, but at a cost.

Now the AI programming of your students can have an effect on the outcome of the game.

Thank you for your reply. I think I've played that game before a long time ago, but I remember not being able to figure it out at the time.

I may have been unclear, but in the design I proposed the bot is able to change which class it is between rounds. The player does not make that choice directly. There are 100 (or 1000, not sure yet) rounds played in a game, and at the beginning of each round the game asks the bot which class it wants; the bot can use whatever logic it wants to make this decision.

Yes, an explorer cannot beat a bomb-layer, but if your bot only plays mine-layer, it would be easy to win a majority of the time by simply having your bot switch to the laser-firing bot once it sees the opponent's strategy. The AI of the bots absolutely have an effect on the result of the games.

Regardless, I am very open to suggestions about changing these dynamics, which is why I posted in the first place :) I don't like the idea that an explorer stands no chance against bombs, I just couldn't think of some mechanic to defend against it without being overpowered.

As for your suggestion about different bot sub-systems, I think that it's a little too complicated for this game. I want students to be able to fully understand even the nuances of the game in as little time as possible, as they may not even have an interest in games. Though I'm not totally against the idea of making the game real-time instead of turn-based.

I will spend more time considering the game, and I'm very open to, and grateful for, your suggestions.

What level of complication and sophistication you want/expect to see in the bots? A simple model-based reflex agent, a utility-based agent and minmax searching, or what?

I would drop the rock-paper-scissors metagaming (unless that specifically *is* the focus).

How about using a pre-existing, demonstrably compelling game for this?

A discrete variation of Bomberman where you move in one block increments would be very close to the simple block world you are envisioning. There are only six actions (directions, lay bomb, idle) but an interesting balance between staying safe, setting traps for the opponent, and rushing to grab more powerups (blast range, simultaneous bombs). If you choose to stick with limited field of vision, then there are tactics like setting bombs outside the opponent's vision and using them to trigger the ones the opponent sees faster than expected. With enough range powerups you could also eventually be able to blast the other player directly from outside their vision. (Interestingly, human players also fall to these things due to tunnel vision - the easier the more stuff is happening close to them - though they technically have perfect information.) A player's blast range, bomb count and the fuse remaining on an individual bomb could either be public information, or the bots could attempt to deduce those things from what they see.

Quote:

I may have been unclear, but in the design I proposed the bot is able to change which class it is between rounds. The player does not make that choice directly. There are 100 (or 1000, not sure yet) rounds played in a game, and at the beginning of each round the game asks the bot which class it wants; the bot can use whatever logic it wants to make this decision.

This is actually what I was talking about.

Whether a bot wins a round or not is based only on this decision. Everything else about the game does not influence the outcome, so why go to the trouble of including the rest of it. The game is a simple Scissors/Paper/Rock game and you could do exactly the same thing with a bot that chooses Rock Paper or Scissors.

Also, as the choice is absolute and hidden, it is essentially a random choice. The mathematics of it states that a robot that chooses randomly between the strategies will be as good and any other method of choice. SO to win (or at least tie for first) all I have to do is use a random number generator. Any other algorithm can only be as good or worse than this.

I don't need any AI at all.

But, as this is supposed to be an AI exercise, it kind of defeats the purpose of it.

You need to have the outcome of the round, not based on a single choice, but on a series of choices and that changing what choices you have planned should cost something.

What you need is to have it so that in each round both bots have the same chance at winning, but that this is influenced by how clever the AI of the robot is (in other words, random choice should be the worst possible choice rather than the best - as it is with S/P/R).