Maze War [75D]

Contributed by Nikolai Borissov

Here I want to introduce my own idea about the application that could be used to learn C++. Ok, legality first. I state that this idea is absolutely free and you can use it whenever you want without limitations. However, there are no warranties. I'm not sure that this idea is suitable for your purposes, or easy to implement or worth it at all. Just something that came to my mind, without any history of practical experience. May be it's not even unique.

This is a game to be played in a labyrinth, but played not by students, rather by programs written by them. The labyrinth may contain obstacles, pitfalls, gates, weapon caches and so on. Players, initially positioned at various parts of the labyrinth move in whatever directions they decide in a search of some special thing, say treasure, hidden in the labyrinth. The first player who finds (and perhaps unlocks) this treasure is a winner. The players are supposed to have some senses and be able to collect information about their environment. They can "see" (but not through walls), "hear" sounds, and perhaps "sense" various dangers.

This game is 100% competitive and players actively interfere with each other in attempt to obstruct, harm or even kill competitors, while trying to escape these dangers for themselves.

The central module of this game should be implemented only once and separately from regular assignments. This module controls the entire game. Let's call this module John (in some spiritual teachings name John is used for Natural Order of Things or God, in other words). Students will be given assignments to implement players, with each student implementing his/her own player. Players are implemented as a functions with a specified interface. All these player functions will compile and link to John.

The game starts by John generating a particular labyrinth and placing players at randomly chosen locations. Then John initializes each player by calling its function and passing some initial general purpose information about playing field. The game proceeds by repetitive steps. At each step John calls each player's function (order is not important) and passes an individual information about the environment of this particular player, including results of previous actions. Based on this information as well as information from previous calls each function makes decisions about what actions a player should take. The list of actions is returned to John. Possible actions may include moving in a particular direction, jumping, attacking another player, picking up a weapon and so on.

As John has finished calling player functions and collected the requested actions, he makes appropriate changes on the playing field. These changes follow requested actions but subject to some natural limitations. For instance, a request to move towards a wall would fail. Finally John redisplays the updated labyrinth and starts a new cycle of calling functions and collecting actions. Steps should proceed with some reasonable speed to achieve a good animation of the entire game process on the display.

Game stops when either winner is determined or all players are killed or made incapable in some way. To avoid endless games a time factor could be introduced. For example, from time to time a terrible beast, the Guard of the Labyrinth, would wake up and eat 1 or 2 players, who happened to be not smart or lucky enough to escape. At the end of the game, when the winner is determined, the beast would come out and eat up all the remaining losers :))

Well, this is an idea. Hope it might be of some interest to you.

Program elements

Extensive. Indeed this kind of project is far more suitable to a team willing to work together for quite some time. Alternatively individual elements can be tackled separately.