Among the many projects put onto the backburner for until when I find enough time/money to go about implementing them, there also is an RPG engine. Here's what I've thought of, some of this is also available pre-canned as badly formatted XML from my unofficial directory on a student operated machine which might be up or not.

The language

Regarding the scripting language, I've come up with two requirements to it, easy things should be easy, and complex things should be possible. Translated, this means first, the language should be convenient to use. In my opinion, Perl is not necessarily useful, as Perl mostly has intrinsic operators for string manipulation (the RE operators), and you won't be manipulating strings much in your RPG (at least, I won't in mine). The other side is, that you will want a turing-complete language, preferably with support for scope, recursion and maybe even threads and synchronisation, depending on how your game/scripting will be implemented and what the requirements are. The turing-completeness is necessary, since you will need the language to implement the stuff that the data dosen't provide and initial design didn't anticipate.

Other people I've been talking to (on irc mostly) have thought about using and embedding Python, since it is easily embedded, has a clean object system (at least, cleaner than Perl), and has a strict syntax. The strict syntax makes it suitable for the intended user base, which are more likely content-creators than programmers.

Using a Java JVM as the scripting engine is also interesting, but in both cases (Python and Java), it's the object model that makes or breaks the ease-of-use of your engine. The object model should reflect how your users think within the confines of your engine.

Other other people have implemented their own JavaScript scripting, but I shy away from implementing my own toy language, since it's (too) much work or useless.

FedEx vs. Scripting

My own idea, as outlined in that XML document, is to try to get away almost completely without scripting by simply allowing only one metaphor, the FedEx metaphor. The FedEx metaphor (FedEx quest" == "Get item A, go to place B and give it to person C, receive item D) stays until now, as I can implement with it almost every test case I've come up with relatively elegant.

My XML document also (should) outline some of these test cases and how the FedEx metaphor should solve them, my favourite case being the BadCitizen problem and the Door / entrance fee problem :

• Door / Entrance fee : You have a door and a person you have to pay to get entry to that door, but the person and door are not in the same place. How to permit the player only after he as paid the fee entry through the door ?
• BadCitizen : A player attacks a peaceful non-player in a town. How will the attack of the guards and the response of the rest of the townfolk be modeled ? The most interesting case would be to allow murderers to get away with it, if there is no (townfolk) witness.

The "solutions" with the FedEx metaphor are easy, if you allow "attributes" to be attached to the player, where "attributes" are simply invisible items which the player cannot influence.

• Door / Entrance fee : When paying the entrance fee, the player gets an "attribute" DoorPaid attached. The door is a "filtering" door, which only allows world-objects with the DoorPaid attribute through and removes this attribute on leaving the door area.
• BadCitizen : This one is a bit more tricky. A two-component attribute set is needed together with some rules for the guards : If a citizen (NPC) is attacked by the player, he attaches the attribute Murderer.NPCHandle to the player. If that attacked citizen "sees" any other citizens, he attaches to them the attribute AttackedBy.PlayerHandle. If then those two attributes meet, guards will have a rule to attack the player.

The Client

If your game is to be anything multiplayer, you will need some separation of the game logic between the central server and the connected clients. The client cannot be trusted. As long as this premise holds, the client has only the function of presenting a more or less funky UI to the user, all game logic must be finally decided by the game server. As the (at least my) game will be hard turn based (even if the user dosen't perceive it as such, e.g. Baldur's Gate II), a http based interface is the easiest starting point, as there are plenty of libraries to use and connection persistance, security (if necessary) and reference implementations are already there. After a plain HTML interface, or parallel to it, I would consider a Java client, which does offload some of the UI interaction to the clients machine.

Games to look at

In my opinion, no cool engine does make a good game. The main thing that makes a good game is the same thing that makes people come back to a website, it's good content. Quake had almost no success, and was at its time a success because of the new gameplay idea and the multiplayer features. Half-Life, a game based on (almost) the same engine as Quake is, had even more success (with me) becazse it had a long, well thought-out gripping story and much better design to it. Quake ]I[ Arena is basically a engine demo and/or proof of concept of id Software to sell their engine to other content developers. The Infocom adventures had the maximum of story, because they were almost purely text based, but people expect more entertainment of a game today. If you are so inclined, you could also consider /. and this site as a massively multiplayer RPG, in which the players themselves create most if not all content. If you go through some old articles on GamaSutra, you will also find some post-mortem articles on RPGs and multiplayer-RPGs, recounting what was good and what went wrong with the development and merchantability of the game.

^{Parts of this node have appeared before on the chatterbox.}