Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Sluggy

Pages: [1] 2 3 ... 7
Design Lab / Re: Mudlib Design Specs: pt1
« on: February 04, 2013, 09:10:27 pm »
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.

Design Lab / Re: Mudlib Design Specs: pt1
« 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.

Design Lab / Re: Mudlib Design Specs: pt1
« 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. 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.

Design Lab / Re: Mudlib Design Specs: pt1
« on: February 03, 2013, 01:35:35 am »
Hmm, I'm no security expert either but I mislike the idea of chopping down to a lower access level. I'd fee less prone if it were built up. Just, I'm not sure how to go about doing it. However, I agree on that third point - never allow an instance to have an access level higher that the directory/file from which it came. And the first point is basically what I was proposing with the 'core' directory.

On the topic of components. I mean specifically component-oriented design (also using a composite-pattern in this case). Favoring composition of objects over inheritance to apply features or behaviors to the core entity. A couple good resources that show its practical use can be found here:
I've used these techniques in non-mud related games with amazing success and I'd like to apply it to a mud now too.

Design Lab / Re: Mudlib Design Specs: pt1
« on: February 02, 2013, 06:23:00 pm »
Ok so I'm getting a bit lost here. First, are you suggesting permissions data being stored for each object where 'object' is the code file, the blueprint object of a compiled file, or the individual instances of each object? I took it to mean instance but now I'm not so sure.

This system has some interesting properties when applied to a message-based component system as well. If each component has its own access rights there will be potentially many layers of access within a single user's hierarchy. Care will have to be taken that creators don't subvert components with more access by inheriting them and/or rerouting code through the messaging system thereby allowing components with less access to send data/commands to components with more access.

Design Lab / Re: Mudlib Design Specs: pt1
« on: February 02, 2013, 01:51:57 pm »
@Camlorn: Don't worry about the documentation. I'm the kind of guy that can't write a function without providing autodoc info for every parameter. Heck, even my players get documentation!

Since you brought up the topic of what this mudlib is about I figure I can answer that more clearly for the record. Components. That's it. I've used them, I like them, and I think they are an ideal construct for MUDs and games in general. But there don't seem to be any LP-based mudlibs that use them. I'd like to try to change that. Systems and features can be written using any technique you can imagine so I'm not so focused on anything beyond the bare bones right now. But I want it to use component-based design from the ground up. Since I just went through Melville and Phantasmal last night and discovered they are both public domain, I'm sure I'll be 'borrowing' bits and pieces for my purposes. I'd just like to wrap it up with components.  8)

Oh, one other thing.  Everything in an LPMUD mudlib is accessible from inside the mud.  It has to be.  Now, you can always ensure that some parts of it require root/system privs which no actual player/wizard/whatever has.
That's the plan. Does that seem too extreme?

I would suggest putting ACL's on every object
Ah, you've answered my next question then. I'm not too familiar with this sort of thing though. Obviously the info carried needs to be lightweight. Would you suggest group ids attached to each object and then keep the actual permissions for each group in a separate database?

Design Lab / Re: Mudlib Design Specs: pt1
« on: February 02, 2013, 01:31:43 am »
Sorry, the 'sefuns' word is a specific term for MUDs but I was using it as a generalized shorthand for 'globally accessible utility functions that provide the capacity to mimic and/or override built-in driver functions (efuns) but are written at the mudlib level'. Basically I was asking if folks prefer just a loose collection of functions or if they like to have them grouped under a warpping object depending on their purpose. That all. XD

I have indeed though about security quite a bit but was planning on making a different thread since I still am working my way through DGD and am not sure how well it will work (I'm quickly learning that almost everything I knewabout FluffOS is going to be of limited use). As I said, this is still all paper-n-pencil stuff so far so I'm trying to make broad ideas that are mostly platform agnostic.

I've considered a basic layout that is likely similar to most mudlibs but with one major twist. Its a combination of ACls (Quix, I hadn't considered attaching the ACLs to every object, only directories. Which were you suggesting?) plus a directory stack underneath that. I was considering having three root folders for the mudlib: core, secure, and public. The public folder is where most of the game-specific code would end up as well as domains, creators' private work spaces, and shared mudlib code. ACLs would be most useful in this region. The second level is the secure folder, it has a nearly identical layout to the public folder but is used for central mechanics of the game, save data, permissions lists, etc. This region would be off limits to anyone not belonging to a particular group. So far this are pretty normal right? So here's the last and likely most controversial one: The core folder. It would contain the 'to-the-metal' mechanics that drive the mudlib as well as interface with the driver. This would not be accessible from within the mud. Crazy huh? But I figure there are a few good reasons for this 1) It's code that will rarely change. 2) On my mud there is only one other person I would trust to touch such and not without my supervision 3) This stuff is used by every major and minor system in the game so it would likely require a reboot anyway. 4) I'd want to test it fully offline before ever consider using it. 4) All of the above makes it ideal to simply use a code repo to clone / edit / test locally / and upload such code. Technology and resources for this are abundant these days so why not just do it that way? Heck, that's how the driver works anyway so is it that big a deal to extend it to some of the mudlib.

I'm perfectly willing to admit that I haven't thought this out all the way but I'm generally under the impression that I don't need to provide access to anything until proven otherwise. Any views, anecdotes, or examples that might make me reconsider?

On the topic of gods with bodies, I realized by reading your responses that I've answered my own question with my mudlib's core idea - components. Since the body will just be a hierarchy of components attached at runtime it's really not even worth worrying about I suppose XD

Design Lab / Mudlib Design Specs: pt1
« on: January 29, 2013, 06:28:43 pm »
Since I've previously mentioned on another thread that I am going to start work on a new mudlib I've been scribbling lots of things down onto paper. Before I really get into the code I want at least a rough sketch of what it should look like once things are in a working order. Since then I've come across a few considerations that I figured might warrant other opinions. Since its likely that many of these 'considerations' might pop up I've decided to label each such thread with a part number- hence the 'pt 1' in the title.

Sefuns: Do people like them? I generally like the idea of common functions just being available without having to include special headers or accessing wrapper objects. However, there is something to be said about the organization of placing hundreds of function prototypes and #include statements into a single sefun object. And that something isn't very nice.

User Accounts: This one seems to have a lot of merit both ways and tends to spark quite a few arguments. How do people (both developers and players) feel about parent accounts that hold all of their separate characters? It seems like a bit of a security risk and many of my players actually argue that it would be less convenient than just having multiple passwords. Anyone else have a thought?

God Characters: My initial idea was to simply provide 'creator' accounts that did not have any 'physical' player avatar. However, it does seem that a lot of folks feel cheated by that. Players like 'seeing' their creators walking about and talking with them within the virtual world. And creators find it easier to simply upgrade an existing character rather than make a new account that seems to have fewer capabilities. I've read Crat's comments on this in regards to DS and I'm starting to come around to the idea.

General / Re: Starting a mudlib. Which driver?
« on: January 22, 2013, 06:04:56 pm »
Well it appears that the general consensus is that DGD is the way to go if I'm going to write a new LPC-based mudlib. To that end I'll try to wrap up this topic with a link to the other thread so that anyone in the future can try to follow the line of reasoning.;topicseen#msg7451

That being said, I might play the devil's advocate for Camlorn here. It sees that DGD is mostly just a sandboxed scripting engine for LPC so taking it just a step further entails using newer technologies to create basically the same thing but with a different language for the scripts. My curiosity has been piqued and I might go off the trail a bit here. I think I'll spend the next couple weeks investigating this angle just to see what I can come up with.

Sluggy puts on a dirty, well-worn, brown crush fedora.

Licensing / Re: Starting a new mudlib
« on: January 21, 2013, 01:17:36 pm »
Quix: I agree with the first comment. Ultimately, the game itself is what matters not the technology. And being able to write and embed code on the fly is technology that aids in game play development. Especially on a central server that multiple creators can access at any time from anywhere.

However, compiled options are possible to a degree. Many managed languages come with support to compile themselves. I have a secret to admit. While I've been doing all this driver talk, just to be sure, I went ahead and tried out the idea of running C# within C#. Turns out there are quite a few hurdles to jump through and a serious bug in the .NET (and probably mono too) CLR makes it less than ideal but the end result is that with managed languages that use intermediate compilation you can sorta get the best of both worlds: The speed of JIT combined with the flexibility of updating code on the fly. Plus all the goodies that come with using a well-known and supported language like third-party libs and tools. The downside is of course that sandboxing is much harder and not just built in like with LPC.

Crat: I've spent a lot of time rummanging through DS due to the mods my mud required. And that was fun! But I like to work on the high-level systems - gameplay stuff. Working with the driver just doesn't appeal to me. The sooner I can get away from it and emerse myself in the mudlib itself the happier I will be.  ;D

General / Re: Starting a mudlib. Which driver?
« on: January 20, 2013, 05:41:02 pm »
Dangit Camlorn! Every time I think I want to dismiss DGD you give me pause. That's ok though. I'd prefer it if everyone had a bias. It tends to bring out the best in their arguments. One thing that doc pointed out to me was the difference between the upgrade methods. I didn't realize that I could upgrade all live instances of an object. I have whole folders full of scripts dedicated to copying edited files of core systems, shutting down my test dev mud, rebooting it, and then logging back in and running various checks and it's one of the biggest bottlenecks in my work flow.

Another thing is that I like the idea of the driver having absolutely no assumptions about how my mudlib is going to work. I mean, I might perform objects composition by placing objects inside of other objects - then the traditional relationship between rooms/environment/inventory breaks down. I'm actually willing to write my own verb parser for that price. I've even have code that already does a lot of it.

So it seems to whole LDMUD angle stems from the idea that if I would use FluffOS then I might as well use LDMUD? Are the features more-or-less then same?

Licensing / Re: Starting a new mudlib
« on: January 20, 2013, 05:39:18 pm »
I'm sure he has. He's probably referring to the fact that there is a) no official standard for LPC constructs b) no official standard for how it interfaces with the driver and c) just about no information on how to actually write a lib from scratch - in other words interface with the driver.

The best I've found is a few creator references that mention standard functions like create() and reset() and of course the awesomeness that is opening up a bunch of mudlibs and hunting down their driver interfaces and then comparing them. That last one really sucks because its hard to know if the person writing it really knew something I didn't or if they just had a different way of looking at the problem or if they just hacked together code until something popped up on the console.

General / Re: Starting a mudlib. Which driver?
« on: January 20, 2013, 01:29:12 am »
Ouch. I like mah closures. They are one of my favorite features. That and being able to do call outs for non-existing functions. I think I'd better do some more considering. Also, how does DGD stand up in terms of bidings and shadows?

Licensing / Re: Starting a new mudlib
« on: January 19, 2013, 11:23:36 pm »
Yes, I understand that Public Domain means I give up everything. Period. That's fine with me.

Well most of my basic questions were already answered so I think the license issues have been worked out. From here it seems to be more of a technology argument which I have moved to this thread:;topicseen#msg7429

As far as your Lua argument I had already considered it albeit using Lua in C#. I mean really, if I'm going to use some big league tech let's go with something NOT C++ ;)  I've also considered running C# as the scripting language in a C# driver. Not too bad since there is already such a project and it seems to work well with the built-in sand boxing library. All I'd need then would be a command buffer/processor/parser, object life manager, and networking connection state/protocol. Actually... that's still a lot of work.  :-X

General / Starting a mudlib. Which driver?
« on: January 19, 2013, 10:46:40 pm »
So I've been considering the possibility of starting a new mudlib for a while and recently decided that I had the time and energy to put into it. However, before I really get into anything code-wise it seems I still have some research and consideration in terms of drivers. Admittedly I'm not that well versed on them so I'm hoping that others will have input that can aid me in making a decision.

There is one basic goal I want to focus on. A message-based, composite-patterned, component-oriented architecture for the higher-level constructs. The will of course necessitate a much higher object count than most mudlibs as well as more overhead and processing to pass information around. It will probably also rely on more taboo LPC constructs like shadows or function binding.

So knowing that, I am left with the next step - picking the driver. The way I see it (and it is very limited I'll admit) the two big choices are FluffOS and DGD. Initially I was leaning towards Fluff because it is something I feel safe and comfortable with.  I'm used to it and I generally know what to expect. However, many people have been recommending DGD and I'm starting to take a liking to the idea. My biggest problem here is that DGD seems to offer features that are not found in other drivers. I usually like to go with the option that is more standards-compliant. Not surprisingly, as far as I can tell there really is no such thing for LPC. Not in any official capacity anyway. So perhaps the best metric is features rather than standards? Is that a fair assessment? If so are there any other drivers with interesting features I should consider?

The best features I see coming from DGD (if I understand them properly) are:
  • Light-weight objects - might be useful for composition?
  • Extension interface - can I do it with DLLs or do I need to edit the driver itself?
  • State dumps / persistence - not the most important thing to me but hey, I won't complain
  • Does not necessitate telnet communications - did I understand that one correctly?


Pages: [1] 2 3 ... 7