Babble Mud

Just looking over the New C++ Codebase thread, Nick brings up tons of questions in regards to designing a new codebase. I have tons of questions and suggestions, but let's take these a few at a time.

Rooms

On your webpage, it seems you have a fairly decent design laid out. I don't know how much of that has already been coded as you state you are back to a design stage. I'm curious how the system works for location within a room. The design basically says each room is a grid system itself, and that one might have to path to move to an enemy. Are you worried about this complicating code?

If you could see where you were within the room, I can see tactical aspects to gameplay, but with a pure text game, I am guessing you won't be displaying the layout of the room, or will you do it nethack style?

Will movement/pathing within a room be aware of flying/levitation/etc? Will certain mobs like ghosts be able to move through objects?

What are the advantages of this system, and why did you go with it?

How are you handling surprise/awareness?
How are you handling ranged combat?

Scripting

How do you plan to implement scripting?

Can we script in new skills, races, commands, etc? Or will scripts largely replace progs?

I'm glad to see you're implementing a crafting system. Is most of this going to be hard coded, or will people be able to create new resources and items via online editting or scripting? While a good mud team will require a coder, I am all for taking as much out of the core code and implementing it via external data files or scripts. The reason is simple. Every single copy running is going to become forked code. Every mud wants to customize the game. When you have new bugfixes and updates, people have to manually apply these and continue to fork their code. If the core server code is modular and universal, then people can easily apply these with a simple patch.

Resets

For resets, I'd like to see a system where the resets are handled differently for different mobs. A boss for a quest might only be available to you once. One mob might spawn sporadically in a zone, not necessarily always in the same room. This spawn/reset could be timed X minutes after the last time it was destroyed. Other resets obviously have to be very specific to one location.

Actually, we're not worried as much about code complexity as we are about game design and control. Displaying coordinates and interacting with them in a purely text-based manner is exceedingly difficult. In fact, we decided to scrap the grid per room idea. Most of the 'engine specs' you see are actually proposals, some of which got implemented part-way, others of which got scrapped completely.

Also, Nethack style doesn't really work since you need full terminal cursor control. But that's not supported very well by MUD clients so we can't depend on it.

Besides, a MUD might have many people and mobs in a single room. How are you going to represent all that textually? Will you give each character a number/letter and force the player to look it all up in a key of sorts?

All that being said, we're probably going to keep extremely simple notions of room sizes, directions, etc. For instance it might be possible to take cover behind a table, which faces east, which could protect you from ranged weapons coming in from the east.

The advantage to a grid system would have been enhanced tactical possibilities. But again, since this all is text, we decided it would be too complex. If we had a custom client to display it all, it could work, but that doubles the load of work right there. We figured we'd like to have a very good text-based game instead of a half-assed semi-graphical game.

We don't know yet. Combat rules are one thing we're working on at the moment... they are very complex to think about.


That first question isn't terribly relevant, only in the sense that the bulk of the code will in fact be Lua. We're debating at the moment whether to write a C bootloader of sorts, that launches the Lua and provides support, or to just start directly in Lua with the interpreter, and load C modules dynamically as needed.

As for scripting in new features, we have not yet discussed details of how we'll do that. Of course, though, we plan on making things very modular. Races would be a good example of modules that could be loaded or turned off. Commands are another excellent example.

One thing that we're wrestling with is how to implement logic in a modular system. The more modules you have, the less centralized control logic is. So, if I have a wand of reveal plug-in, and then I put in a potion-of-invisibility plug-in, how do the two know how to interact? The wand of reveal must have some knowledge of what it means to be invisible. But does the potion have any knowledge of how it can be cancelled?

Generally speaking, we're currently leaning towards solving this by putting logic on the victim in question. That is, I decide what something does when it happens to me, not you. I might "ask" you questions, e.g. are you evil, a warrior, etc., but the control is on my side. This would all be implemented with call-backs of sorts so would lend itself well to modules.

(continued)

(continued from above)



Since almost everything is in Lua it is hard to say what is hard-coded and what isn't. In principle, you can edit the game itself online, and just re-interpret the edited scripts. So yes, that would make for a very dynamic environment.



Yes, that would be very nice. But the more you decentralize, the more trivial the core is, and hence the more bug fixes will be out in the modules to begin with. And chances are, people will be customizing the modules. What I mean is that to some extent, forking is inevitable. What is important is containing it, at least. That is, containing the forking in a well-defined, delimited zone, so that a snippet won't go stomping over code all over the place -- to, of course, whatever extent that is reasonably possible.



I have to double-check our design wiki, but I think we've pretty much agreed that we're going to scrap the SMAUG style of resets, and instead have everything be scripted. If a mob dies and wants to reset itself, it'll register a timed event to respawn itself. So, you can handle things differently for different mobs, or even the same mob at different times, depending on how it was killed, . . .




Let me add to all of the above the following disclaimer: this is just my take on things, and we haven't yet finalized our design. We're still working on it quite intensely, in fact. So, all this is subject to change, and doesn't necessarily represent a team consensus (since it's being shaded by my bias), even though I tried hard to stick to things we all generally agreed upon.

What we're doing at the moment is the very lengthy job of going through that list of tons and tons of questions Nick lists, and answering them. Of course, each answer has the potential for spawning many sub-discussions, which can then spawn new discussions and might go reach into other subjects... We've done a fairly good job of covering general ideas of most areas of the game. Now we have to start hammering things out, being precise, and writing down the actual rules, not just general ideas. And of course there remain a number of areas where we have extremely vague ideas that aren't nearly ready to be formalized.

Thanks for the replies. I'm not expecting answers set in stone as this is still in a design phase.

I'd really love to offer feedback and suggestions on combat/attributes/formulae specifically. I love such things.

I think it is a good idea to remove the grid system with a room.

As far as the logic goes with scripts, I really enjoy what Legend of the Green Dragon does. It is a PHP based game that recently completely overhauled itself to be more modular. What it did was create "hooks". Mind you the game is in PHP as opposed to C, but the logic remains the same. When newday.php runs (when the player gets a new set of turns, and things "progress" in game a day), it goes something like this:

Add turns
ressurect people
spawn stuff
etc. etc.
<Insert Hook Newday Here>
Continue to main game functions...

At the hook portion, the game checks the SQL database and looks to see what hooks are activated for Newday.

When you install and activate a module that might interact with a Newday (Let's say there is a class module, and we want to give you new class skill points to use each day, which reset here), then said script puts in an entry in the database. When you deactivate or uninstall the script, it removes the entries from the DB.

From a logical standpoint, by placing hooks in specific places, you are prompting the scripters to write specific type of scripts that have very specific functions, yet allow for the scripter to move beyond those bounds if they wish.

During character creation there is a hook to check which classes and races have been installed as modules. Likewise, in the combat section, before displaying a menu of available choices, it checks to see which skills you might have to choose from.

The scripts are classified in logical groups. You write a class script, or a race script, or a forest event script, etc.

As far as one script interacting directly with another, we make one script a prereq for another in certain cases. Perhaps a forest event requires a specific race to be installed and active. I wrote a script for an alignment system, and other scripts which depend on the alignment system. If said system isn't present, the other scripts can't install.

In the live environment, you can install, activate and deactivate these on the fly without any interruption to the game. As code is being executed, it is constantly making fresh new checks at each hook.

This puts a little load on the DB (not to mention requires a DB to begin with) but allows for great flexibility.

Going back to crafting for a second, I would like to see the basic mechanic hard-coded, but allow for the creation of new resources/items/recipes online.

Whatever data format you use, you should be able to create new items in an item table, and have a flag to mark said item as a resource. Then have a table for recipes. Recipes would have a basic struct listing the skill requirement, how many items, and then list each item.

When you use the armorer skill as an example, it looks down the list of recipes and grabs armorer recipes. It then checks if you have resources for those recipes, and if you do, it lists it as an option.

Combat

As far as combat goes, I'd love to jump in the heart of that discussion. I have worked with countless tabletop/pen-and-paper roleplaying systems, so I've seen a great variety of combat rules. I enjoy combat rules discussion and lean towards streamlined/balanced rules.

In the TinyMudServer thread I discussed my idea for a simple ranged/melee combat scenario and how to handle range and fleeing.

What happens if a player loses his/her connection in the middle of combat, intentionally or otherwise? Does their character keep fighting (or being attacked) until it is dead? It is removed from the game after 30 seconds?

Perhaps the best way to handle this is within the player record table. There should be a flag to track whether the character is engaged in combat or not. Futhermore, there should be a bad guy/mob entry in the player record table to show who they are currently facing. If they log off to try and exploit out of combat and come back, when they log back on, they reenter combat. However, what happens when a player logs off, someone else enters the room and then kills said mob?

Magic

I'm curious how magic will be handled. In addition to the standard spell-slot and mana type systems you could do something fairly unique and allow for unlimited attempts at spell casting, but have a drawback. For instance, the Shadowrun rules (while cumbersome on the whole) came up with a neat concept called drain. The more powerful a spell you attempt the cast, the greater potential of drain. You make a drain roll against an attribute, and if you succeed you're fine. If you fail the roll, you take a certain amount of damage. Actually manipulating the forces of the universe by your will requires channeling powerful energy. Doing so is a dangerous undertaking.

Legend of the Five Rings also has a great system of elemental magic. You have different ratings in different elements (or you could do schools) so that your spells are more powerful within said element or school.

Will there be an alignment/karma system? Will certain spells or schools of magic be inherently good or evil? I suggest that you don’t fully limit access to certain spells based on alignment, but you receive a significant penalty or bonus to a spell based on your karma/alignment.

How are area effect spells being handled?

Will there be status conditions, and if so, which ones? Fatigued, Drunk, Poisoned, Immobilized, Berserk, Silenced, Blind, Hidden, Flying, etc.

For attributes, we're looking at: Strength, Constitution, Dexterity, Agility, Intelligence, Willpower, Wisdom, Personality, Luck. (We're not sure if Luck is an attribute that behaves quite like the others). These do the fairly standard things. Personally I would like an attribute for perception, but that complicates things a lot. Still, it would allow for very alert warriors who aren't necessarily smart or wise.


I like the hook system you describe. It's similar to what I had in mind. We wouldn't have an SQL database, since Lua provides a table mechanism already. And Lua oh-so-nicely allows you to create functions on the fly, and pass them around as proper data values. So, it's extremely easy to create hooks, callbacks etc. and link them together.


Prerequisites are tricky, because some might be of a very general type. Let's look at a module that adds a new spell. It would require a mana module of some kind, right? (That is, it assumes the existence of a spell framework.) We can't really list one particular magic module as a prerequisite -- well, we could, but that wouldn't be very good. We would probably have to list particular callbacks as prerequisites. That is, require the existence of a "DrainMana" callback on character objects. This assumes that your magic module provides such a callback. But then, if I make a magic module and you make a magic module, as long as we follow the same conventions for callbacks etc., our spell modules can work together very nicely.


I think that for crafting it's pretty much a given that recipes can be created on-the-fly, much like online construction. But again, the distinction between hard and soft coding is blurry in my mind, since almost everything is probably going to be Lua anyhow.


For combat, we're not in a position to talk about it until we hammer out our general goals first. We need to discuss things like: how does magic work in combat? How do groups work? How do skills work? Do players lose stamina? Basically, we haven't yet decided what the rules act upon, much less what the rules do! :-)


For link-deads, we haven't decided fully yet but the easiest to me seems to have them keep on fighting, and if they win the fight -- or die and respawn -- simply have them quit after 30 seconds, assuming nobody else comes along and fights them. Our quit action will have a cool-down and all that, so that you can't instantly quit; and auto-quits will be the same way, except with a longer cool-down. So we don't really need flags; we would just have a timer on the link-dead player that, at every round, attempts to quit. If the character is free to quit, it'll start the quit process.


For magic, we were looking at some kind of hybrid mana/memorization model. Basically you would have to choose a subset of spells you could cast, which you can cast using mana (i.e. relatively quick recovery rates). But if you want to change the subset, you have to spend much longer retranscribing spells etc. (i.e. AD&D-like spell memorization times). I like your drain idea, though; I'll throw it onto our design wiki.


We decided against having an absolutist alignment system for several reasons. The foremost is that it's incredibly difficult to quantify programmatically. Instead, we decided to implement a form of moral relativism. Your "alignment" is perceived by others simply as what factions you're aligned with. If I, as a character, consider Orcs to be evil, and you are aligned with an Orcish faction, then you must be evil. Within a faction, characters have rank and reputation, so you can also consider members of your own faction as bad, if they have, say, a negative reputation. But, this alignment is for RP and interaction purposes only. NPCs might react based on your "alignment". But objects, spells etc. won't be affected by it. Perhaps certain spells will cause you to gain/lose favor with certain factions. Casting big bad death spells won't get your brownie points with the nice healer's guild, for example.


We're not yet sure how to do area effect spells. Haven't really thought about it, actually. :)


Finally, for status conditions... Well, this is a tricky one. It would be nice to have status conditions be modular like everything else. Flying, or floating rather (since flying can be complex) for instance is a fairly good example since it doesn't (necessarily) have far-reaching consequences. Fatigue however can affect things all over the place, which makes it hard to modularize. But, it's ok to have modules that have a certain amount of cross-dependency -- again, as with my magic module example above, as long as the general framework is the same, everything's happy.

It all sounds good. Your attribute system seems fairly balanced as well, with 4 physical/4 mental and 1 unique attribute.

I like your idea of generalized alignment more as an reactionary thing. Did you ever play the Fallout PC games?

You had Karma which is a standard good/evil scale, as well as reputation. You had specific reputations to various factions and towns. Perhaps for the effects of magic, it would be much simpler to have a standard good/evil/karma-type system, and then have a reputation type system as well. In that, you may not be liked very well by Orcs, but well regarded by Dwarves.

The design listed on the website mentioned skill-trees.

I had an idea that you could have standard ranks, and a branching skill tree at the same time.

Let's say at character creation, you have a very simple set of skills. You invest 2 points into Melee combat. Once Melee combat reaches 10 points, to progress you must pick a more specific skill branch. You pick Swords. So now, your Sword skill starts at 11 for purposes of comparing skills. At 20, you must specialize again, and you choose Two-Handed Swords. At 30 you might choose to specialize in Katanas. At 40 you might specialize in Togashi Katanas. Now let's say you find an uber-magic Halberd, and you want to use it. If you do not have the Halberd specialization, you use your Melee skill, which is currently at 10. If you want, the next time you have skill points to distribute, you can start Polearms at 11, and eventually Halberd at 20.

Thoughts?

I think you loosely decouple the character from the TCP/IP connection. For one thing, mobs won't have one. If a player tries to escape combat by disconnecting, the game would keep the character in combat (as if he was still playing it) for a while. After a minute or so the lost connection might force the character to log out.



You may as well ask, what happens if a player simply runs away and someone else kills it? You could probably argue that if a player doesn't cause damage for (say) 30 seconds they relinquish the right to the mob to whoever else is hitting it.



I think statuses are a fundamental part of the design. You probably need to distinguish between positive and negative ones. For example, you cast positive statuses on yourself or your friends, and negative ones on your enemies. Also, you can choose to remove positive ones if they are unwanted for some reason.

If implemented in Lua, statuses could simply be entries in a status table. A simple table lookup would see if a status was present (eg. drunk). The corresponding data item for that status could record additional information (eg. how long it has to go, what it does (eg. +5 strength) ).