30 Mar, 2014, quixadhal wrote in the 41st comment:
Votes: 0
Heh, well, I just cut and pasted the file… obviously the saved data won't have any since the mudlib formats descriptions later. :)

Maybe the forum should enforce a maximum width (or add a horizontal scrollbar to the code window widget)?
30 Mar, 2014, Davion wrote in the 42nd comment:
Votes: 0
Idealiad said:
Good comments quix, but please throw some newlines into that ExternalDesc, or I need to buy a new monitor :D.

I fixed it up. It's just the code prettifier has problems wordwrappning really long words. The Saved field had no spaces in it. It does now.
30 Mar, 2014, Tyche wrote in the 43rd comment:
Votes: 0
Methinks the "game" of designing a game would be more fun, if you'd pick the most unlikely, surprising or interesting design choices.

Telnet, websockets, vnums, areas, exits, network, database… What's that got to do with the game?

What about wizards? How does magic work? Where do wizards get their power? How do they cast spells? Where do they learn them?
30 Mar, 2014, Idealiad wrote in the 44th comment:
Votes: 0
Good question, I hadn't thought about it. Do we even have classes?
31 Mar, 2014, quixadhal wrote in the 45th comment:
Votes: 0
Thanks Davion! :)

I think if we want to discuss the game part of the game, that's a whole different pseudo-code thread (which incidentally lends strength to the argument of seperating the driver and mudlib)!
31 Mar, 2014, Idealiad wrote in the 46th comment:
Votes: 0
It would be better organization, but I think it'll be easier to keep the discussion rolling in one thread for now. Also at this stage keeping talk of gameplay and code close together makes sense to me since they inform one another. I don't mind doing some bookkeeping of ideas.
31 Mar, 2014, quixadhal wrote in the 47th comment:
Votes: 0
On the gameplay side of things then, if we're talking about a fantasy style game, I prefer a more dynamic system than traditional classes.

My own design would use a tiered system of "guilds". Players would enter the game as an "adventurer", having a basic set of skills that anyone would have, and being able to level up with just that if they choose to do so. The would be their physical level, if you like. And it's this level which would control attribute gains, hit points, whatever other metrics players expect to get more of as they level up.

At any time, a player might discover a guild. A guild would be something akin to the traditional "class", but its membership would be voluntary and not a permanent choice. The pre-requisites for joining a guild would be set by that guild, and may also include anti-requisites… that is, things which would prevent an otherwise valid candidate from being accepted.

As an example, perhaps the player finds a mage guild in the starter village. The pre-requisites might be very simple, maybe a minimum intelligence score. The player joins and learns a few basic spells and gains a slight boost to the attributes that best serve that guild (intelligence, memory, mana pool). Later, they wander across town and find a small warriors camp. This guild might have a minimum strength prereq, and maybe they only teach males. The player qualifies, so they also join Bob's warrior guild and learn how to use new weapons, and a couple of new moves to use.

Now, a while later, the player has leveled up in both their physical form and their guild skills. They've left the newbie area and wandered into another city, where they find a mage guild that specializes in fire magic. Fred's Frying Pan is a tier 2 guild, and requires that applicants have a minimum intelligence (higher than the newbie mage guild did), and that they already belong to a tier 1 mage guild. In addition, Fred's guild will NOT allow members to belong to any cleric's guild, unless that guild worships a god of fire. Nor will they allow membership in any other tier 2 mage guild.

The reason I like this kind of system is that it offers more structure than the "skill based" systems do. You still have a class hierarchy, but it's not rigid. The player can freely mix SOME classes, but the more powerful each guild is, the more restrictive they are likely to be.. and the more specialized. Maybe you can join several tiers of fighter and mage guilds at once, but at some point, the highest level skills will require you to devote yourself to that one discipline.

You can freely renounce your guild membership at any time, but you will lose whatever skills it offered, plus there may be side effects. Maybe the thieves guild doesn't take kindly to being deserted, and perhaps you might find yourself the target of an assassin's contract. :)

In a related subject, one of the old MUD's I used to play (BatMUD) had a good way of handling experience. You'll notice I suggested that the player would have multiple "levels" at once. Their "body" level would be the main gate for content, offering the improvements to health, action points, etc that players expect as they level up. The various "guild" levels would act as gates to the skills offered by each guild, and perhaps guild-specific content. On BatMUD, each time you did something to gain experience, it was put into a free pool, which you could then spend to raise various things as you liked. You could focus on your physical level, or on a guild level, or specific attribtes or skills. If you dropped a skill or guild, you were refunded the XP you had spent, so you could try things out and redo them as you liked. The catch was, any unspent XP in your free pool was lost on death.

That made for interesting strategies… did you spend your XP as quickly as possible to minimize the risk, or did you save it up for big purchases? In addition, if you were ressurected by a player, you got some percentage of that XP back. The person who ressurected you ALSO got some of it (there was a healer guild whose members got XP primarly from healing, not killing things).
31 Mar, 2014, Nich wrote in the 48th comment:
Votes: 0
I like Quix's idea, and it's fairly close to the system that I had in mind, which was to have several "tall" (as opposed to broad) skill trees that the player can fill out however they want. By tall skill trees, I mean skill trees where there may be 10 or so skills, each leading to the next, with little branching, and very little requirements shared between trees. The trees correspond roughly to classes, with skills within the tree helping with the overall "feel" of the class, but players can dabble in whichever trees they want. The trees are built up of skills that have prerequisites (and anti-requisites, if preferred). In addition, there can be cross class trees, but I prefer to think that the trees will only have requirements from two others, to avoid making the trees too broad. The big problem with open ended systems, I feel, is the loss of flavour due to generality. We should allow in our design to nurture specialty.

For comparison's sake, I think that the main difference between my idea and Quix's is that I would take more control over the number and depth of the guilds available in order to provide a more consistent experience. This isn't bad, since it seems like you could implement my design as a true subset of Quix's idea, so if we vote on and implement Quix's system, we get mine for free just by being a bit more rigorous in the design of the guilds. I don't know if this is necessarily true, but Quix's design seems to imply a multitude of small skill trees (in order to let the player bail out of or integrate more), where I would prefer few, but deep, skill trees, that reward sticking with one choice.
01 Apr, 2014, Tyche wrote in the 49th comment:
Votes: 0
A suggested general feature of the game without a solid specification.

Feature: Magic
Magic comes from a mineral buried very deep within the crust of the earth. This mineral is both concentrated in certain distinct spheres and veins (earth nodes and ley lines). In order to use magic, a character has to have the training/skill to draw that power out. The magical power available in any given place in the world can be calculated by the game driver based on the distance from the source. Casting a given spell requires a specific amount of power and effort on the part of the caster. The cost of this effort is reflected in fatigue on the character. The power is deducted from the source be it a line or node. So eventually the sources will be used up. Luckily because the interior of the fantasy earth is in constant flux, new nodes and lines will occasionally appear….or existing nodes and lines will be replenished. This is handled by the game driver. Very rarely this magic mineral appears in a directly accessible place where it can be mined and stored in specially created magical items… either acting as a battery for the spell caster or powering specially created magical devices.
01 Apr, 2014, Runter wrote in the 50th comment:
Votes: 0
@tyche I like that suggested idea. Do you think it would create a problem for non-magic users being more consistently powered vs magic users? I guess these considerations only really matter depending on what other systems exist to interact with it.
01 Apr, 2014, Nich wrote in the 51st comment:
Votes: 0
I like the idea, but I'd prefer it if it were a central mechanic, and all classes (for lack of a better word) were affected by it.

The mineral could also attract monsters, with larger, more powerful monsters gravitating to larger concentrations of minerals over time.
01 Apr, 2014, Idealiad wrote in the 52nd comment:
Votes: 0
Got to run to work, but I like the guild skills, XP idea, and magic idea. I can dig it! (rimshot)
02 Apr, 2014, Idealiad wrote in the 53rd comment:
Votes: 0
So if there's a global tick restocking the magic mineral and/or creating new resource points, that raises the question…what is the global tick? Is every game object in a queue with an action timer counting down? Are there pub/sub events? At the small scale, are there combat rounds? Action points?

In general, how is time handled in code? At the same time, how does time affect gameplay? I've always thought that there are three big concepts in a mud. Multiplayer (obviously), how you handle space/geography, and how you handle time. I think it'd be interesting to have time be an element of gameplay somehow. Nich had an idea about time travel; how could we make time a factor in this fantasy H&S magic mineral mud?

While I've done event-based systems in games before, I've never really been that satisfied. With events bubbling out and different handlers catching them it's always seemed quite difficult to reason about event paths and make sure handlers are working correctly.

I think at the small scale we should arrange things so players can have a chance of understanding in what order actions will happen. Making complex action systems is cool but I think tactical gameplay can suffer if players can't reasonably predict what's going to happen when.

Big picture I like the idea of having time affect gameplay with some kind of day/night cycle (different mobs popping then, or affecting travel, etc.), or emphasize the magic replenishment cycle, and so on.
02 Apr, 2014, Tyche wrote in the 54th comment:
Votes: 0
Okay let me refine, simplify, expand, and/or horribly complicate this idea.

Feature: A magic system.
In most of the mud games that I've seen magic is stored in a character. It's almost totally disconnected from the game world itself.
This is an attempt to make magic into an actual game economy of sorts. It's also an attempt to add a level of tactical or strategic
decisions to the game based on the caster's environment.

* The source of magic is anodium which is a mysterious mineral buried very deep within the crust of the earth.
* Anodium tends to concentrate into spherical deposits known as anodes.
* Anodium comes in several varieties or species (elemental magics).
* Characters with (special training | natural ability) can tap the power and transform the energy using spells.
* Anodes exhibit properties analogous to both magnetism and water aquifers.
Like magnetism they can be sensed at a distance and power drawn from them.
Like aquifers they have a replenishment rate.
* The power of anode is transferred into the energy to cast a spell.
* Some spells can create items specifically to store magic (batteries) or to create magic gear.
* Magic gear and storage items are drained or wear out over time.

Anodes have..
* Magnitude - ranging from 1 to 9. This is a power of ten (like the richter scale) This determines the radius, range or area of effect.
* Power capacity - The maximum amount of power points the anode can hold.
* Replenishment rate - The number of power points replenished over time.
* Species - Color? (clear|diamond - general magic, red|ruby - fire, green|emerald - water, brown|garnet - earth, blue|saphire - air)
* A current power - level.
* Deep or surface anode (surface anodes can be mined for the mineral itself)
* Static or random - If random the anode can gradually move around the region.

The magnitude of the anode produces a radius which is subdivided into ranges which modify the effort to cast a spell.
immediate - (-1/2 X Effort) (normal power)
short - (Normal effort) (1/2 power)
medium - (2X effort) (1/4 power)
long - (4X effort) (1/16 power)
distant - (16X effort) (1/256 power)

[] The above are just random guesses at formulas for such a system

* Builders can define and place Anodes when they are building a region.

Anodes tend to attract people and magical critters. Perhaps major cities are built on top of high magnitude anodes.
Wizard towers, etc. Perhaps some towns are built as far away from any anodes as possible because the people fear magic.
Perhaps there's a class of critters (anodites) both general and elemental anodites that are made of certain types of anodium.
Or critters that are anti-anodites, the bane of adventurers who love their gear, that drain or eat anodium. :-)

Some possible (spell lists|progressions|skill levels) with very generic names that relate to using anodes.
As a character progresses they can (learn|buy) higher levels of (spells|skills).

Sense Anode I
Sense Anode II
General spells for detecting anodes with increasing distance and skill.

Tapping I
Tapping II
Spells that allow a character to tap one or multiple Anodes at a time.

Power Manipulation I
Power Manipulation II
Spells that decrease the effort required to transfer power.

* At a minimum anyone using magic would need to have the beginner level of all of the above

Runter said:
@tyche I like that suggested idea. Do you think it would create a problem for non-magic users being more consistently powered vs magic users? I guess these considerations only really matter depending on what other systems exist to interact with it.

I have no idea of what some or all the possible side-effects might be. It might produce a terrible game. :-)
On the other hand there's a good deal of fiddling one might do with the density of anodes, the magnitude and replenishment rate in order to "balance" it.
Having magical gear dependent on the magic economy might create problems for non-magic users.
Mages might have to plan on bringing storage items or raw anodium with them more when adventuring into low-power areas.
Strategies of draining local nodes or certain elemental species of nodes might develop.

Nich said:
I like the idea, but I'd prefer it if it were a central mechanic, and all classes (for lack of a better word) were affected by it.

The mineral could also attract monsters, with larger, more powerful monsters gravitating to larger concentrations of minerals over time.

I think the idea might be independent of a class or guild system. That is it works with either system, that either magic skills can be learned by everyone via a guild system or only a certain classes. I don't see how you make it a central mechanic… players may not want to buy magic skills or cast spells because they want to play a straight up thief or fighter. Of course just the existence of the magic system is going to affect non-magic users indirectly, through facing magic-using adversaries or with the gear they acquire and use.

The way I personally approach playing a game is with the idea of playing a certain archetype. If I suddenly get the notion to play a thief. I'll start a new character. I suppose I'm somewhat annoyed at games that support the player who is a combination druid/ranger/wizard/vampire/ghoul/changeling/cleric of thoth/thief who is working on their 4th and final list of elemental spells.

One could devise a very similar system for clerics. Instead of magical energy, they channel power from their gods. Gods have temples. Temples operate much like anodes for channelers. Portable channeling power can be stored in holy artifacts. The more temples to a given cleric's god the more power they can channel in certain areas. Power is replenished and/or increased by sacrificing loot, gold, items, or live critters at their temples. A high level end game for cleric characters might be in temple building and destruction across the realm. :-)
02 Apr, 2014, Idealiad wrote in the 55th comment:
Votes: 0
The magnitude is the range at which the caster interacts with the anode, right? Or you mean the range of the spell the wizard casts?

I agree that this doesn't have to touch every guild – it will interact directly or indirectly though.
02 Apr, 2014, Nich wrote in the 56th comment:
Votes: 0
Well, my idea for making it central would be to make everyone a mage of sorts… thieves are stealth mages (using magic to enhance their sneaking skills, turn invisible, or teleport/phase through wall), fighters are melee mages (possibly using magic to enhance their strength and durability), clerics are healing mages… etc. So all classes are in some way dependent on this system.

Though we could use the flexibility of the guild system to make this not the case - we can create a duality of systems, one dependent on this rock and the other not, and as Tyche said, whole societies can be built far away from these nodes where magic is weak. The fighter who doesn't enhance his power and fights using only base stats might do better than the magifighter in low magic zones, with the magifighter being forced to burn resources just to maintain a standard level of power. But I feel like if we're going to spend a lot of design capital on this magic system it should take a central role in the game, with most things being defined by the presence or absence of it, and not have it be a small side system that only ~10% of the MUD cares about (because then we still need systems for the rest of the MUD).
02 Apr, 2014, Nich wrote in the 57th comment:
Votes: 0
More thoughts:

I like the idea better that anodes form spontaneously and randomly, and that they can be depleted to exhaustion, rather than builders manually placing them. However, I'm a sucker for that sort of thing, and I can see reasons to design it, rather, since in the former case I would also like to see a robust player driven settlement system (so that groups of players can capture, defend, and form cities around spontaneously formed nodes, and also the mud would develop ghost towns - places where people moved in, built up an economy, exhausted the local resources and left). We might not want to open that can of worms, however, and it might be better to say that, lore wise, the nodes form spontaneously, but then place them manually and build up the world's history and lore around these "spontaneous" events.

I would like to see the concept of groups of players exclusively capturing nodes, creating the impetus for end game pvp. The obvious balance issues need to be worked out, though.

Edit: Sorry for the double post, wasn't thinking clearly
02 Apr, 2014, Jhypsy Shah wrote in the 58th comment:
Votes: 0
Wow, Interesting thread. :)

It seems like ya guys have found a pretty cool way to make running a quest (or series even) more strategic, unique and understandable at the same time.

Hope ya find a way to balance the energy and character builds. Hallowing it vs channeling it through sorcery seems interesting. Maybe a more tech (anodium punk) minded player could use it to create the items, power something or build with it. Maybe a druidical kinda character would rather see the source unclaimed? Maybe the death of a character resembling more of an elemental or construct would drop some?

I think ya definitely got something with some serious crafting potential here. GL. Way Cool. XD
03 Apr, 2014, quixadhal wrote in the 59th comment:
Votes: 0
Idealiad said:
So if there's a global tick restocking the magic mineral and/or creating new resource points, that raises the question…what is the global tick? Is every game object in a queue with an action timer counting down? Are there pub/sub events? At the small scale, are there combat rounds? Action points?

If the game logic is kept in softcode, the two ways such things are generally accomplished is via callbacks.

In the case of magic minerals, you could either have each room/area/whatever generate minerals every so often, or you could have a central "mineral" daemon do it. Remember when I was throwing around the word "daemon" up there in LPC? That's a singleton LPC object that doesn't correspond to any physical game things, but has functions that can be called and may have functions called at startup.

The daemon route, would have a MINERAL_D object someplace, and in an LPMUD, it would likely be in the preload list of things that get initialized by the driver after everything else is up and running. Nothing magical here. Every object has a create() function that gets called when it is created, and that function would do the setup for the mineral system (restoring state from files/database), and then schedule a call_out() for some time in the future to update the mineral values again.

If you chose the each room does its own maintenance route, then each room's create function would do the same thing, but only for itself. The daemon route is more efficient, since the rooms don't need to be loaded.. it can just tweak values and when the room loads, it will pull the updated value. The per-room route is more robust and simpler, since there's no need to register your mineral node with any central system.

Combat was typically handled by a driver-enhanced version of this. Namely, the heart_beat() function. It worked just like a call_out(), but the driver called heart_beat() in any object marked as "living", on a fixed timeframe (typically every 2 seconds). It was more efficient to make heart_beat() functions in things, because the driver could call them all at once, rather than having to manipulate the call_out() stack for each one.

Nowadays, with Gigahertz CPU's and Gigs of RAM, it may not matter so much. :)
03 Apr, 2014, Idealiad wrote in the 60th comment:
Votes: 0
@Nich, I also like the idea of anodes forming randomly. This makes me wonder how areas are integrated into the game map overall. I have some vague thoughts on that but I'm going to think more on it.

In general though, I think the magic can still work alongside/with the guild skill system. I'm with Tyche in that if I want to define a character as a no-magic fighter, that's what I want to do. Perhaps there would be a more compelling reason not to use anodium. Some kind of magical corruption? Then choosing to be a mage or choosing to be a fighter will be a more interesting choice in itself.

@quix, Is the call_out() a callback passed from the game thing to a central object? And heart_beat is instead an update function on the game thing? That seems more straightforward to me.