Dungeon Delver is a project that I have given a great deal of thought to. I have also had several false starts. This is something I try to avoid with projects, as I have a tendency to have a great amount of zeal for a project for a week or two, only to abandon it when something else goes along.

In this, I am like the crow Jeremy from the Secret of N.I.M.H. in that I say "ooh! sparkly!" when something newer/neato-er comes along.

But Dungeon Delver, Midieval Micromanager, and Island/Interstellar Interloper never "go away". They just get pigeonholed for a while, to be brought out again later and tinkered with.

For Dungeon Delver, I consider the following to be the primary influences:

Dragon Warror I
Final Fantasy I
Zelda I
Heroquest
Fighting Fantasy Books
Zork
Old text adventures for the TRS-80 CoCo2
Adventure Construction Set for C-64
Diablo

So, the methods of presentation that most occur to me are text-only and simple sprite based graphics.

Methods of implementation range from WIN32 binaries (utilizing anything from the PopCap framework to my homebrew SDL library) to Flash to Active Server Pages with an MS Access or SQL backend.

Thinking more about the old Fighting Fantasy books, and merging the idea with old computer text adventures and thinking about ACS for the C-64, I came up with the following:

Dungeon Delver might best be implemented as an online resource for creating and playing text based adventure games in your web browser.

So I've tentatively done some work on such a system.

You can find it here.

Currently, I have my user system at 90% complete. It still lacks the user being able to change his own account information.

With the new system, I stand by my firm belief that a user's login name should be his e-mail address, and a "display name" stored along side of this e-mail address should be displayed next to data associated with that user. And, naturally, there is no way for a non-administrator to get the e-mail information.

The basic user information includes a login name (e-mail address), a display name, a password, whether or not the user is verified, and whether or not the user is an administrator for the system as a whole. In addition to this, there is a unique userid for each user account.

But of course, the user will only know about the login, display name, and password. The rest is transparent to him, as it should be.

Everything in the system is based on POST data, so that you can't just pass things on the commandline. I will have to think more about this later, as it prevents users from being able to directly link to things(a mixed blessing).

The top level data unit is the "Adventure", which has a unique ID, a name, a description, a flag for being publically listed, and a flag for being locked from editing.

There are also records that relate adventures to users. A user can be flagged to administer, build, or play an adventure.

Administrators for adventures have the right to change anything about it and additionally can give others permission to administer, build, or play.

A builder can change any of the data within the adventure, as long as the adventure is not locked by an administrator. In this way, building an adventure can be a collaborative effort.

A player can play the adventure, even if the adventure is not public. This allows some users to beta-test before the adventure is "published" or made public.

Thus far, I've got the database structures and pages for managing users, and some portions of adventures. I do not yet have a page for changing passwords, display names and so on.

Next up, after finishing up the user accounts and adventure management subsystems, I've got various dungeon entities to take care of:

Directions, Doors, Locks, Items, Traps, Rooms, RoomDoors, RoomTraps, Monsters, RoomMonsters, RoomItems.

But, of course, I'm not in any hurry to finish this. This is a "spare time" sort of thing. Make a system here and there, and eventually I'll have enough to actually make and play adventures.