Monday 15 June 2009

Dynamically bringing the dungeon alive

Its been a good few years since I played Everquest 2, but one of the gameplay ideas that struck me as easily transferrable into the typical dungeon of a roguelike is that of the infamous (if you've played EQ2 that is) "distressed merchants".

To summarise, a distressed merchant appears near other groups of mobs, begging you to help them. Once you have killed the surrounding groups of mobs, then they change into a "gratified merchant", from which you can now interact with (and buy/sell items as the reward for killing the mobs).

They are an example of what in general terms EQ2 called "dynamic adventure camps":


"Dynamic Adventure Camps (DACs) can be found throughout the lands of Norrath, especially in the large overland zones. They are usually structured around an object in the world such as the gnoll tents in Antonica, or the orc siege towers in the Commonlands. DACs are dynamic because the same camp can have many different types of events happen at the same camp, and new events can be added by designers into the mix of the other events already in place. An event is decided at the spawning of the entire camp and will stay in place until a group has completed all the stages of the chosen event. Upon successfully completing the chosen event, the entire camp will despawn. Some camps choose to respawn in the same spot, while others have multiple spawn areas to choose from."

Implementing such a concept in a typical roguelike shouldn't be too hard - since most roguelikes, unlike some MMOs, don't have to worry about the concept of phasing. It does require, as a minimum, that the map layer is able to store and associate data, and that the map can execute triggers based upon some conditional logic.

The problem comes when you end up making allowances for such events across your entire dungeon, perhaps as a result of adding handling for such events to every map cell, and you end up massively inflating the amount of memory (and hence disc space) required for such functionality. The alternative approach of hand-crafting such logic (so beloved of programmers in the days when 64K was a big deal) is obviously not extensible, but with judicious implementation of null pointers (or rather, nil pointers, to be pedantically correct in terms of Object Pascal syntax) mininum overhead can be achieved.

No comments: