Author Topic: Mudlib Design Specs: pt1  (Read 3902 times)

Offline Sluggy

  • Friend
  • **
  • Posts: 91
    • View Profile
    • Stellarmass
Re: Mudlib Design Specs: pt1
« Reply #15 on: February 03, 2013, 01:33:46 PM »
@Quix: Ok, that helped cleared it up for me. So even if Joe were to inherit an object from Ted's workspace when he cloned it it would be under Joe's permissions. And I can assume if the object is cloned by the game it would have even more restrictions placed on it by the fact that the owner is now the 'public space'. Now as for groups, would it make more sense to apply all of Ted's group ids to the object as well or would I use Joe's  uid at access time and see if he belongs to a group that is allowed to perform X at location Y? I'm thinking that in a component scenario I might save myself a lot of headache if I just use the permissions from the root object.

@Camlorn: To be clear, component-oriented code isn't going to magically make a better game and it can't do anything you can't do using other techniques. The players will have no concept of how it affects them. It is entirely a developer-side thing. But from my experience it is easier program, debug, test, and well... compose in order to make complex objects. I had a lot of trouble over the years trying to finagle DS into dong what I wanted for my mud and at lot of it stemmed from two things: multiple-inheritance and the lib's assumptions about what an object was based on its inheritance chain. Perhaps there is some other lib out there I have not seen that doesn't suffer from this?

While working on Stellarmass I was and still am heavily influenced by sandbox style games  that allow the player to create their own solutions to problems within the game. I'd like to take this sort of thing to an extreme within a mud environment as a large-scale crafting system in a high-technology setting. The core concept would be that most objects within the game would be decomposable into raw materials and all raw materials would be re-composable into useful tools and supplies. The end result is the ability to build, customize, and pilot player-made space ships. A good example of what has influenced me can be found in Gmod + Spacebuild + wiremod. http://www.youtube.com/watch?v=9-9iSO21C80 as well as Minecaft. Hopefully that will at least provide some concept of where I'm going with this. To be sure, this can be done without components, I just see them as a natural way of performing such a task. You could also argue that I could simply strap such a component mechanic onto an existing mudlib. But if I'm going that far I'd likely be throwing out most of the core mechanics that describe items and rooms (and likely even mobs) anyway. Over the last few days I've grown more fond of DGD and using something like Phantasmal to get started. It would let me get the boilerplate stuff out of the way and I could work on removing the pre-existing idea of rooms as they are and start building the 'game' so to speak from the reasonably early stage within the mudlib design.

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: Mudlib Design Specs: pt1
« Reply #16 on: February 03, 2013, 02:35:32 PM »
I did more reading, and I don't know how well that will work out.  It could be fine, but...I have a feeling it's going to be uglier than you think it will be, and there may be performance issues.  Non-dgd drivers do not do much optimization of your code, and Dgd may not either.  Given that lpc isn't Jit, idk.  It depends on other things that can't be answered yet.

    The other points I want to make are these.  First, Lpc does not have a concept of interfaces.  You can turn on static type checking, and there's probably tricks to get around this, i.e. an object with empty functions, but there's no such thing as an interface that you can use as a contract for your component to follow, and therefore you can not guarantee that it is a valid component.

    The other point is this.  Unless you're throwing out the room and going down the road of Godwars2, there's not really that many options for components.  I could see why this is appealing so that you can have, say, the drill-sword of holding, but when it comes to player input and core mechanics, there's really only one.  You could, I suppose, have multiple combat systems, but if Player a has one combat system and player b has another, you have to figure out how they interact, and now you've got a combinatorial explosion.

    Can you provide an example of what kind of components you would have, and what they would make up?  I'm trying to understand how you can apply this to a mud; the example articles assume that you're going to have a few different sources of input and a bunch of unrelated systems, i.e. graphics, physics, and sound, but muds don't have physics, not really anyway, or sound.  I'm not going to say that this is a bad idea until such time as I see it being a bad idea in practice, but I don't see how it helps.

    If you want to rely on inheritables for determining what an object is, that makes things easier, and thus most mudlibs use it.  You could still use them for your components, so long as you don't want to be swapping components at runtime.  What I would do, for example, is have the container inheritable function have an is_container function and the room inheritable an is_room function.  The mudlib then has a magical function that determines the capabilities of an object by calling the is_ functions.  Perhaps a better option is to have each inheritable store its capabilities in a mapping of capabilities, i.e. key is_room, value 1.  This probably has problems that I'm not thinking of at the moment.  I could optimize that by having an item inheritable that container and weapon and all the rest inherit with an is_item function, and the is_item function implies that I need to determine what type of item it is.

    You are giving me ideas, though.  I could see this working out very, very well in Scala.  In Scala, it should be possible to even work out a system that makes calling components look almost like calling method calls, and where adding a component just transparently adds more methods.  But that probably introduces its own design headaches.  Just as a point of interest, I'd do that by making a new operator and using case classes, i.e. myItem .> move(directions.north).  Scala lets you do fun things involving the creation of new operators out of thin air like that--notice how similar that is to the classic myItem.move(DIRECTION_NORTH).  I keep trying to convince myself that I don't have time to start coding a mud--all of my previous attempts failed before they really got started--but I am slowly failing at that, so who knows.  With scala's applyDynamic and related stuff, recently added in Scala 2.10, I could even go so far as having components that look, to the programmer using them, *exactly* like classes.  If you now google Scala, beware for it will melt your brain for the first few minutes, until you start to get the awesome.

Offline Sluggy

  • Friend
  • **
  • Posts: 91
    • View Profile
    • Stellarmass
Re: Mudlib Design Specs: pt1
« Reply #17 on: February 03, 2013, 02:56:02 PM »
Heh, a quick look at scala tells me why you like it. It's kinda like the goodness C# and python but for the JVM. On the C# note I've looked into a sandboxed and dynamically compiled option and the CSScript library along with threaded AppDomains seems to be just the ticket. I've had a couple e-mail exchanges with the creator and he even just released a new update yesterday that makes it even more viable.

I think you're starting to see where this is going. My original post a while back brought up the fears of performance since it inherently requires a lot of objects to be floating around. You've also stumbled onto something I hinted at in previous posts in the form of attaching methods to the root object. It's the reason I was asking about bindings and shadows - though they might not really do what I want in this case anyway sadly. A messaging system can often be cleaner and more future-proof since all components in a hierarchy can potentially respond to specific mesages in their own way but makes it harder to get property-read access from components. It is also a lot slower. The issue of interfaces isn't that big of a deal. I've gotten into the habit of adding 'IsSomeSpecializedThing()' methods that simply return '1'. This lets me see if an object is of the appropriate 'interface' pretty quickly. Also, don't count out inheritance entirely it is still use a lot but in this case it is used for specializing components in a linear chain rather than adding multiple features into a single object.

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: Mudlib Design Specs: pt1
« Reply #18 on: February 03, 2013, 06:21:02 PM »
My point wasn't about that being a problem.  My point was that a newbie coder, potentially who you're targetting, now has no support to check the component for validity.  Presumably you know how to code components for the system you wrote; presumably I do not.  There is no real way to make sure that my component matches the interface for what it needs to do, save to test it; if there is some functionality that is used once an hour, for example, the maximum test time before a problem even shows up is one hour.  I can check by hand, but that's just prone to errors.  That said, it's quite possible that FluffOS/Dgd have hooks that I don't know about, or reflection capabilities.

    I like the idea of not having objects depend on what they inherit at a mudlib level, that is, the mudlib shouldn't be interested in what the object inherits.  If the object claims to be a sword, treat it as a sword, that's great.  I don't think that dynamic component adding/removing will end up working well in Lpc, but I could be wrong: too much overhead, possibly, mainly if more than a few fights get going or if you abandon the idea of a room in favor of something else, ala Godwars 2.  I know that FluffOS provides some sort of static type checking, but without the associated optimizations you still have to look up methods, potentially at every call.

    Dgd would work out better, for this, because you can transform code before compilation, and use, perhaps, something similar to objective-c syntax.  Dgd also has a few problems, mainly that you're going to have to write your own object manager if you want to take advantage of the reasons for using Dgd in the first place.  You now need, not only a list of what clones exist for an object and what uses what inheritables, but also what objects use what components.  Not only on Dgd, but on all drivers, I suspect that you'll have to reboot anytime a component gets updated, at least if you want to be absolutely safe.  This may not be true for non-Dgd drivers, but I think it's not a bad idea to reboot anyway if you want to plug in a new sword component.

Offline Sluggy

  • Friend
  • **
  • Posts: 91
    • View Profile
    • Stellarmass
Re: Mudlib Design Specs: pt1
« Reply #19 on: February 04, 2013, 09:10:27 PM »
Quote
Dgd also has a few problems, mainly that you're going to have to <do a bunch of really not cool stuff>
Ouch. I didn't realize that. I only just got DGD up and running last night and I spent the last couple hours going over the docs about the kernal lib. That really really changes things... a lot. Part of this is due to my experience with transient objects to begin with. I've generally worked on stuff with the assumption that an object will be around for a short time and will have plenty of opportunities to destruct and reset state when reconstructed.

Ok, so I didn't realize how compulsory the persistence was for DGD. I mean, you don't have to use it but the lack of an object GC means I might as well since it would likely take as much work to write my own as to manage all the stuff that will be floating around the void.

At least there is good news on the 'shear numbers' side. There are several conversations on the Phantasmal site that suggest DGD would have no problem pushing around lots of objects attached to each in-game entity. Heck, in a smaller way they even recommend composition.

Regardless I'm really going to have to sit down and work with DGD for a bit to see if that really is what I want to do. The Kernal Lib's restriction on cloning vs inheritance really puts me down, but I can see why it is that way and it might actually not be that bad anyway.

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: Mudlib Design Specs: pt1
« Reply #20 on: February 05, 2013, 12:02:08 AM »
Well, I'm not going to say that Dgd doesn't have a garbage collecter, and all open muds using Dgd do not use persistance.  If you turn persistence off, it may very well have a garbage collector.  I'd say that this isn't a problem at all--even if Dgd doesn't, it swaps things to disk, so it won't overflow ram.  It's optimized to run on computers with megabytes, not gigabytes of ram.  That said, if you're not using persistence, Dgd may not be the right driver for you, though for what you want to do, being able to easily (by some relative definition of the word) write what amounts to a special cleaner syntax for your component system would, at least in my opinion, give it some points.  Btw, and I don't have sources or verification, apparently even what is now Yahoo used Dgd at one point.  I'd say look into how dgd functions without persistence enabled.

    All that stuff I listed, yes, it's annoying.  You may not need the bit about listing components and what uses them--I'm not 100% sure.  It's probably not that hard to do it, though, not if you make all component hookups go through a register_component function or similar, and just modify the objregd in phantasmal to handle that.  See above, because i'm only qualified to talk about dgd and persistent mudlibs, as that's all I looked into.  The point, though, is this: I can write an action-driven mudlib.  I don't write one single line of save/load code, anywhere.  I don't even worry much about ram--it overflowed ram? No problem.  I've got a slower-than-ram 1 terrabyte ssd, or something ridiculous like that.  You just refactor algorithms that are going to need to examine all mud objects to account for the fact that the driver needs a chance to swap out every now and then.  You basically get player city-building, persistent wilderness, player treasure hoards hidden in obscure locations, all for free.  I can drop an item on the ground on a persistent mudlib,  and walk away for 6 months: assuming no one touched it, it'll be there when I go back for it.  Said item will never be loaded into ram, unless you simulate decay--and there's smarter ways of doing that that don't involve iterating through everything every tick.  You don't have area resets, you've got monster breeding, for example, and you get rid of objects by simulating the aforementioned decay.  It's a unique way of designing a game, and I wish someone would hurry up and use those features for something really cool and open to the public.

    Finally, do note that you can dump state without persistence.  If you just want to reboot real quick without losing state, you can do so.  Again, sketchy on details.

Offline quixadhal

  • BFF
  • ***
  • Posts: 619
    • View Profile
    • A Waste of Time
Re: Mudlib Design Specs: pt1
« Reply #21 on: February 05, 2013, 05:37:53 AM »
That's also part of why I suggested looking at Gurbalib.  It implements persistence and all the "fun" associated with it, but does NOT use the kernellib as a basis, which Phantasmal does.

I'm not saying one is better than the other, but they go about object management in different ways, so looking at both might be useful.