### How We Envision Using the DungeonMaker

The DungeonMaker has very general capabilities, and we expect it to be used in a wide variety of ways: An earlier version is being used for pen-and-paper roleplaying, and it can certainly be used for traditional computer role playing games where MOBs just stay at their spawn point and attack when a player approaches. However, we envision the environments created by the DungeonMaker to be populated by a new generation of smarter MOBs which have a life of their own, and move about on their own business. They might already be in a defensive stance when the player enters, with patrols looking for intruders and heavy guards in their treasure rooms, or they might be unsuspecting and peaceable, sleeping in their bunks and socializing in small groups in their anterooms. However, when a player attacks or steals their treasure, all the inhabitants of the dungeon will eventually hear about it and make it their business to hunt down that player. alifegames.com's next project is the development of this type of AI.
While the dungeons and labyrinths can also be used with more traditional AI, they are geared to work optimally with the realistic MOBs described above. For one, the DungeonMaker works best when it can make fairly large dungeons - we do not recommend its use for creating really small places. In large dungeons as we envision them, a group of players will not be able to take on the entire population of MOBs in one huge battle. We intend to make sure of this by adjusting, during dungeon creation, the level of MOBs to the level of the player party entering the dungeon. (In a MMORPG where players can keep entering a dungeon where a battle is already under way, we would have spawnpoints in very protected locations, and teleport suitably powerful MOBs into the dungeon when powerful players enter.) So the players will not be able to just systematically kill every MOB and loot every bit of treasure in a dungeon - they will have to make a raid: Go in, get as much experience and treasure as possible, and then get out before they are overwhelmed.
The layout of the dungeons on a square grid makes it possible to have very effective AI - in particular, the pathfinding is quite easy to handle, and MOBs will not just amble around at random, but follow purposeful paths that make sense. Many of these paths will be precomputed during dungeon creation (after the playability test has been passed) and stored in the map, so that no computation is neccessary for a MOB that wants to follow a path to an exit, a chokepoint , or the largest treasure room. The map already has other built-in intelligence, so MOBs will know whether they are in a labyrinth, a tunnel, an anteroom, or a room, and if they are in a room they will have access to a list of all the squares in the room. The intelligent map will also deal with player locations, and all this will enable MOBs to appear very smart before they even run any serious AI-algorithm. Of course, even though the map is grid-based, the rendering can still be in 3D, possibly stretching and bending the map so as to get rid of all the straight lines and regular measurements.
While all this can be done on isolated maps such as the Single Tunneler, we envision the players to run raids through a series of connected dungeons, using these rules: When you enter a dungeon, the door closes behind you for good, and you will have to make it to an exit in order to survive. The exits lead to other dungeons, or to the surface, where you can do trade and buy supplies. If you go through an exit at the bottom of the map, you will enter a dungeon with more dangerous MOBs than the one you just left, if you leave at the top things will get easier, and if you go sideways they will stay the same. The lower down you go, the better treasure you can get. Every dungeon has a number of magical artefacts and one major treasure. When you steal one of these, the AI will mount a serious attempt to corner and catch you, while they might otherwise have been content to just see you leave. If you steal the major treasure, the alarm will even go out to neighboring dungeons, and they will already be in an alert hunting stance when you enter them. Such neighboring dungeons could be created in a separate thread when the players are approaching one of the exits, so there would be no need for loading times. On the other hand, it might be cool to show the dungeon-creation-movie while the graphic engine loads textures and stuff. It would be unneccesary to store maps, because random seeds and design files alone would allow the recreation of the dungeon landscape the players had passed through.
We envision the normal mode of play for our dungeons to be on a fully revealed map, where all MOBs are visible except those inside rooms with closed doors. This makes for exciting play: Players will not only have to run their combat, but simultaneously watch the overall map to see whether bands of MOBs are approaching, and whether their exit route is in danger of becoming blocked. This is really two games in one, the traditional hack'n'slash, and a very challenging game of strategic positioning played out on the global map-view. It will often be the best choice for a player to abandon a winning fight and run in order to avoid becoming boxed in and forced into a losing fight. The players will have a strong incentive to deny the MOBs knowledge of their location, and will constantly have to re-evaluate their best paths through the environment. In single-player games, we consider it best if players have the option to pause the game in order to evaluate the situation at their leasure and give orders to their party members. For use in MMORPGs, we would prefer if a group of players that had decided to go on a dungeon quest were given their own personal key to enter a dungeon where nobody could join them afterwards, though other options are possible. An interesting possibility would be if players had the first dungeon guaranteed for themselves, but could meet other players when going down deeper.