23 Jul, 2010, Deimos wrote in the 1st comment:
Votes: 0
So, I've recently gotten back to work on my MUD after a lengthy hiatus and last night I thought to myself "wouldn't it be immensely cool if anything and everything in the game could be inhabited and controlled (at least on some restricted level) by a soul (a soul being either a player connection, or an AI module) instead of just creatures?" This got me thinking about really weird and interesting scenarios; things like maybe a warlock trapping a player's soul inside, say, a helmet, which then could be worn by another player, and hilarity would ensue. Or an unfortunate encounter between a player and a medusa, leaving the player turned into an actual statue, which could then be acted upon as an item, rather than simply a player with some kind of flag or spell effect. Things of that nature…

I know it's probably not a new or unique concept (though, I've never played a MUD with this kind of behavior), but I just wanted to run it by you guys and see what you thought. I spent a good deal of time last night restructuring the class hierarchy to accommodate this, and it seems to be working just fine in the limited scope that I've tested.

Anyhow, thoughts/criticism?
23 Jul, 2010, Davion wrote in the 2nd comment:
Votes: 0
It'd be also cool if multiple souls could occupy the same object. it'd support possessions'n such, where one would be forced to watch the other do horrible, horrible things!
23 Jul, 2010, David Haley wrote in the 3rd comment:
Votes: 0
I think if you search for 'brain' or 'controller' you will see this issue discussed here.
23 Jul, 2010, KaVir wrote in the 4th comment:
Votes: 0
In GodWars1 players can be transformed into objects. If you get decapitated, you become your own severed head - and demons have the ability to roll from room to room in this form. Demons can also transform themselves into potent demonic weapons, and back in the old days of the original God Wars mud it wasn't uncommon for strong demon players to bully weaker demons into serving them as weapons to aid them in PK.

When I demonstrated the first demon character, I did it by transforming myself into a demonic sword and jumping into the hands of a newbie. He wielded me in combat, and I would talk to him and cast spells to help him. Another player saw this and decided to kill the newbie for the sword, thinking it was some amazing new weapon. However the moment he killed the newbie, he was rather surprised to see this wonderful sword leap from the corpse, transform into a demon, and chop his head off. His severed head then witnessed the demon transform back into a sword, and leap back into the newbie's corpse.

Once, when I was at University, I asked over the public channel "Who wants to be a tree?". Quite a few players said they did, so I turned them into trees…then went on an extended lunch break. I felt a bit guilty when I got back, as the forest of players were still there waiting for me to turn them back.
25 Jul, 2010, Deimos wrote in the 5th comment:
Votes: 0
That sounds really interesting. Were there many bugs and unintended behavior that came about as a result of allowing that kind of thing?

I've also thought about treating areas and rooms like objects as well, in which case it would be possible for scenarios like a soul in control of a room (haunted house?), areas inside items (maze trapped inside a sorceress's crystal ball?), or things of that nature. That seems like it would cause more problems than what I've already done, though, and I can think of various other ways to accomplish things like that without restructuring. Shrug.
25 Jul, 2010, KaVir wrote in the 6th comment:
Votes: 0
Deimos said:
That sounds really interesting. Were there many bugs and unintended behavior that came about as a result of allowing that kind of thing?

Only a couple I can think of, both in combination with other spells.

The first was the 'preserve' spell, primarily intended to let players keep severed limbs as trophies. Some players would preserve the severed heads of their enemies, effectively trapping them (because their head would no longer rot) - on one occasion, a player went on a mass killing spree because I wouldn't give his girlfriend her own clan. He killed about half the players on the mud, preserved their heads, and stored them in his bag. The heads were trapped for a few hours, although they could at least chat with each other inside the bag.

The second was the 'transport' spell, intended to let players transport items to each other across the mud, to make trade easier. This was sometimes done after preserving a head, sending it to a particularly tough mob, so that several players would need to work together to free them. However the demons would also use it to transport each other (in sword form) to enemy clan guardians, allowing them get into enemy clan headquarters and kill their idling rivals.

Deimos said:
I've also thought about treating areas and rooms like objects as well, in which case it would be possible for scenarios like a soul in control of a room (haunted house?), areas inside items (maze trapped inside a sorceress's crystal ball?), or things of that nature. That seems like it would cause more problems than what I've already done, though, and I can think of various other ways to accomplish things like that without restructuring. Shrug.

In my current mud, Creature, Object, World, etc, are all derived from the Thing base class, which may be connected to a Brain. A HumanBrain is used for players, and encapsulates socket data, while a MobileBrain is used for mobs and encapsulates mob AI. In theory I could connect a player's Brain to a World or Object, although I don't at this time. I've also considered creating a Brain for Worlds, to handle weather and such.
25 Jul, 2010, Idealiad wrote in the 7th comment:
Votes: 0
I think most game objects can be treated the same in the code, as a generic 'code object', especially if you create game objects by composing code objects. However I've heard arguments against pure composition as well (mainly that it can get messy, hard to keep organized or understand how the control flow and code execution is working).
26 Jul, 2010, Deimos wrote in the 8th comment:
Votes: 0
Idealiad said:
I think most game objects can be treated the same in the code, as a generic 'code object', especially if you create game objects by composing code objects. However I've heard arguments against pure composition as well (mainly that it can get messy, hard to keep organized or understand how the control flow and code execution is working).

I'm opposed to composition where it isn't necessary and doesn't make things easier to understand (which is most places, in my experience, but ymmv).

KaVir said:
In my current mud, Creature, Object, World, etc, are all derived from the Thing base class, which may be connected to a Brain. A HumanBrain is used for players, and encapsulates socket data, while a MobileBrain is used for mobs and encapsulates mob AI. In theory I could connect a player's Brain to a World or Object, although I don't at this time. I've also considered creating a Brain for Worlds, to handle weather and such.

That's pretty much exactly how I have it set up, sans some of the names. Currently, I'm toying with the idea of having body parts as Things while they're still attached to Creatures (rather than being created when they get lopped off). This would allow for demon-controlled hands and could also make for very interesting combat (something I haven't even started on yet… sigh).
27 Jul, 2010, Igabod wrote in the 9th comment:
Votes: 0
Deimos said:
That sounds really interesting. Were there many bugs and unintended behavior that came about as a result of allowing that kind of thing?

I've also thought about treating areas and rooms like objects as well, in which case it would be possible for scenarios like a soul in control of a room (haunted house?), areas inside items (maze trapped inside a sorceress's crystal ball?), or things of that nature. That seems like it would cause more problems than what I've already done, though, and I can think of various other ways to accomplish things like that without restructuring. Shrug.


As for areas inside items, that's already possible if you make the sorceress's crystal ball a "portal" object type but then you couldn't make it another item type such as weapon. I like the soul possessing a room idea, that wouldn't be too hard to add in to the code. Would only certain rooms be capable of being possessed or would that be possible for all rooms? And what would a player be able to do in said possessed room? Would they be able to move items around without other players seeing anybody do anything? Would they be able to physically damage players in the room?
27 Jul, 2010, Deimos wrote in the 10th comment:
Votes: 0
Igabod said:
As for areas inside items, that's already possible if you make the sorceress's crystal ball a "portal" object type but then you couldn't make it another item type such as weapon. I like the soul possessing a room idea, that wouldn't be too hard to add in to the code. Would only certain rooms be capable of being possessed or would that be possible for all rooms? And what would a player be able to do in said possessed room? Would they be able to move items around without other players seeing anybody do anything? Would they be able to physically damage players in the room?

Right; that's what I meant when I said that there's a lot of different ways to accomplish those things, but they usually all have minor disadvantages like the one you pointed out that prevent them from being ideal.

If I went ahead with the changes, all rooms would have the ability to be inhabited by a soul (or multiple souls), but I would likely restrict it based on the type of room, and the area that it's in. As for what they could do once inhabiting a room, it would be pretty restricted, just like inhabiting an inanimate object is. I imagine they could open and close their own exits, move items around, creak and groan, etc. The concept probably wouldn't be very desirable for the player in general, and used more as a curse than anything. Maybe if a player died in some kind of haunted area, his soul would be trapped in the room he died in until another player set him free somehow…
27 Jul, 2010, KaVir wrote in the 11th comment:
Votes: 0
While it may not be as nice from a design perspective, I actually found it easier to treat destructible buildings as Creatures. For example in one quest there are load of farmhouses, which are actually mobs - when you kill them, their "treasure drop" is a peasant or two. I also have a nightwasp nest Creature which has only one attack - the ability to summon nightwasps.

The only time this doesn't work is for things like dungeons, as Creatures don't have internal maps. However in this case it would probably be better to treat the dungeon and its entrance as separate things anyway - collapsing the entrance to a cave is unlikely result in a complete cave-in. Thus the entrance could be a Creature which can be entered like a portal, transporting you to the appropriate Dungeon thing. Attempting to leave the Dungeon if the Creature is dead would give you a message about the entrance being blocked, but perhaps you could use some sort of "dig" ability to create a new entrance.
27 Jul, 2010, Deimos wrote in the 12th comment:
Votes: 0
I'm not sure I understand how creating destructible objects as Creatures makes things easier. Are Things attackable in your game, or only Creatures?

Though I haven't begun work on combat yet, I've been designing around the idea that any Thing can be targeted and attacked. If you didn't particularly enjoy looking at the statue of Zeus in the courtyard, you could start beating on it until it was destroyed, for example. Should I decide to make Rooms inherit from Thing, as well, that would mean that they would also have condition and could be "attacked" (maybe the process of "digging" would actually be a sort of player-vs-room combat, as amusing as that sounds). I'm not sure this is very practical, though, since there are a ton of key differences between the interaction between a player and a Room when compared to a player and a Creature or Object - perhaps the most important being that there would be really weird consequences for allowing a Room to be "killed."
27 Jul, 2010, 3squire wrote in the 13th comment:
Votes: 0
Well, we could all use interfaces and stop this madness… (j/k of course)
27 Jul, 2010, KaVir wrote in the 14th comment:
Votes: 0
Deimos said:
I'm not sure I understand how creating destructible objects as Creatures makes things easier. Are Things attackable in your game, or only Creatures?

All Thing can be targeted and attacked - that was one of the original design concepts.

However in most cases the process is pretty simple. You execute your attack command, which calls the Damage() method. In the case of most Things, this simply describes the attack bouncing off them, although I did overload it for Objects to describe them becoming dented/notched/etc.

Creatures have far more functionality though. They can have different body shapes (allowing for far nicer combat messages), complex combat-oriented attributes (ideal for making buildings vulnerable to fire attacks but resilient to physical attacks, for example), they can respond to attacks (eg creating some people with a spawn message describing them running out the door, or even performing an actual attack - described as archers firing arrows from the windows), they can be affected by spells (eg causing a wooden hut to rot), they can drop "treasure" when defeated, they can have custom death messages (such as exploding when hit by a lightning bolt, collapsing when hit by a crushing attack, etc), they're affected by environmental conditions (eg becoming more resilient to fire when it rains), they can have custom spawn messages and sounds, they can even wear "equipment" if so desired (eg a drawbridge 'worn' by a keep which protects its portcullis).

Of course you could move some or all of that functionality to the Thing base class, but you probably don't want it for most Things. You could also play around with inheritence and composition, and I do do that for some things…but in this case I just found it easier to use Creatures to represent destructible buildings.

Deimos said:
If you didn't particularly enjoy looking at the statue of Zeus in the courtyard, you could start beating on it until it was destroyed, for example.

Sure, but what's the difference between a stone golem, and a statue of Zeus? The statue doesn't fight back…probably…but that's a Brain issue, not a Thing issue. I would represent the status as a Creature.
27 Jul, 2010, Deimos wrote in the 15th comment:
Votes: 0
KaVir said:
Sure, but what's the difference between a stone golem, and a statue of Zeus? The statue doesn't fight back…probably…but that's a Brain issue, not a Thing issue. I would represent the status as a Creature.

Really, I guess it boils down to how much functionality you have in your base class. Assuming a more traditional structure, there's a lot of Creature-specific behavior that I wouldn't want a statue to exhibit (like the ability to be charmed). On the other hand, there's a lot of that kind of behavior that I might want the statue to exhibit that a traditional Object couldn't provide (like the ability to wear armor). So, to satisfy both, we need to either move some of that behavior up the class hierarchy or start mixing and matching flags and conditional logic. Personally, I'd rather the former, for sanity's sake, but then where does it end? :p
28 Jul, 2010, KaVir wrote in the 16th comment:
Votes: 0
Deimos said:
Assuming a more traditional structure, there's a lot of Creature-specific behavior that I wouldn't want a statue to exhibit (like the ability to be charmed).

But you probably don't want people charming the stone golem either - or undead, or oozes, or swarms… So the chances are you're going to need a way to indicate whether a Creature can be charmed, regardless of whether or not you treat statues as Creatures.
28 Jul, 2010, Deimos wrote in the 17th comment:
Votes: 0
KaVir said:
But you probably don't want people charming the stone golem either - or undead, or oozes, or swarms… So the chances are you're going to need a way to indicate whether a Creature can be charmed, regardless of whether or not you treat statues as Creatures.

What I meant was that I wouldn't even want the possibility of that happening. I don't want it left up to the builder to remember to set a flag in order to prevent what shouldn't be possible in the first place. Charming an imp that's supposed to be charm immune isn't really that big of a deal. Charming a keep, though? lol. And it's not just charming, either. There's a whole slew of behaviors for mobs that are undesirable for objects. If I have to explicitly set a bunch of flags to prevent all this behavior, it doesn't seem like I'd be taking the easier route. But hey, if it works for you, that's cool. :)
28 Jul, 2010, David Haley wrote in the 18th comment:
Votes: 0
What does the name truly matter? Call it animate object rather than 'creature' – what matters is the provided functionality.
28 Jul, 2010, KaVir wrote in the 19th comment:
Votes: 0
Deimos said:
What I meant was that I wouldn't even want the possibility of that happening. I don't want it left up to the builder to remember to set a flag in order to prevent what shouldn't be possible in the first place.

The same is true for the stone golem. That's why its shape defines "mind" as "none" - it ensures the golem can't be targeted by lust, mindblast, mesmerise, etc.

If I wanted a humanoid statue, I'd simply give it the stone golem shape and the "inanimate" property. Piece of cake.
28 Jul, 2010, Deimos wrote in the 20th comment:
Votes: 0
David Haley said:
What does the name truly matter? Call it animate object rather than 'creature' – what matters is the provided functionality.

It doesn't matter at all, and that's not what I'm trying to say. A keep is not animated. It's inanimate. KaVir is only making them Creatures as a creative way to get Creature-like functionality on an object that wouldn't normally have it. What I'm trying to say is that you get both desirable and undesirable functionality as a result of that. As I pointed out before, though, there are ways to negate the undesirable functionality, but it just seems too much like trying to ram a square peg into a round hole to me :p I'd much rather move the functionality up the class hierarchy and keep things a little more logical.

KaVir said:
The same is true for the stone golem.

It isn't, though. A stone golem is animate. Therefore, it's up to the designer as to whether he wants his stone golem to be immune to charm or not. As far as the system is concerned, a stone golem is animate, so it should be allowed to be charmed. A keep is not animate. It makes no sense for a keep to be able to be charmed, whether the designer wants it so or not. Just because the designer could make it charm-immune to "solve" the problem doesn't change the fact that it shouldn't even be a decision for him.

And I chose the keep example intentionally, since it seemed easier to make my point than it would have been with the statue (because animated statues are actually rather common). Though, I don't think all statues should be animate things. So, in my system, an animated statue would be a Creature, but a normal statue would just be an Object. That is, unless I decide to move some of that functionality up to the base class…
0.0/104