View Single Post
Old 01-03-2008, 01:25 AM   #3
bloviate
New Member
 
Join Date: Apr 2005
Posts: 9
bloviate is on a distinguished road
Re: Looking for design/builder oriented partners to develop a MUD from the ground up

I was going to flesh out my original reply, but had to dash off to the mall to catch a movie.

What is a quest system? To me it is the bare minimum of things. It might handle quest initialisation and completion, but the gameplay which dictates the actions involved in completing the quest would be data driven and only incidentally involved with the quest system itself. And by this I don't mean template entered data but instead crafted game experience.

Let's look at a command based interface approach. I'll describe making a fedex quest as a very simple example. The commands used are of course contrived, this system does not exist and I might not do it like this if I were to implement it. I have implemented systems like this before for graphical games and it took several days at most - doing the same for a text-based game would be simpler.

And a matching mocked up gameplay transcript:
Rooms, objects, npcs, triggers, events and whatever else are basic elements a game designer can employ to create an in-game environment and may as well be done with data than code. The quest system itself just exposes a couple of triggers and events to the selection available, and this expands the generic potential of the overall content development environment. In fact this is effectively equivalent to how quests are done in Discworld mudlib based LP mudlibs, except there of course the game play is authored with LPC code rather than data.

The data driven approach has one main difference which many may consider a disadvantage. When you can write code the possibilities are endless, you can implement anything which you have the imagination and skill to. With data you are limited to how you can combine the elements which you have available to compose.

However, I actually see the ditching of the need for code as an advantage myself. With code, you can end up implementing something which has been implemented countless times before in other code. For instance, before the popularity of command systems in LP muds which allowed things like the "search" command to be extracted and made generally available, any room which needed search functionality copied, pasted, adapted and used its own version. Also I don't know about you, but on the MUDs I have programmed, documentation and examples are scarce. Neither ever seemed to cover the aspects I wanted to know about half the time, and I either needed to go searching for use of features in the existing room code (grep), or I needed to dig into the code for the systems myself (grep again) and reverse engineer how I was supposed to use them (read and squint). Newbie builders were often left to their own to learn to program and work out how to use the existing game code to build.

Also with data driven, all the elements you can compose content out of are known to the game engine and can be described to you. Even if they weren't documented, you don't need to go searching for examples, you can just say "show me all the uses of the 'death' trigger" or "show me all the uses of the 'quest-completion' event". Or "show me everything which refers to the npc 'Norbert'". Or "show me all the triggers which are valid for use on this NPC" (this of course corresponds to a drop down list in the web page interface).

No. I would say that the better systems might involve scripting because perhaps the data driven approach has been eschewed for the familiar and known.

If anything I would say it removes the shackles which are currently weighing down the skilled builders and is preventing them from being as creative as they can be. What I described above is just a simple system, it can always be extended to allow the skilled builders to do the kind of things they used to do with code instead with data.

Why should the basic elements which make up a mud be coupled to code or to the contents of a file which has to be edited? To me that is a burden and a barrier, one which the data-driven approach done in the described way can do away with.
bloviate is offline   Reply With Quote