13 Jun, 2014, quixadhal wrote in the 21st comment:
Votes: 0
That's not actually how multiple inheritance works, although I have seen it abused that way quite often.

Multiple inheritance says every object should be composed of code and data, and that the code should be factored into the simplest reasonable components.

If I make a spoon and a fork, those are two different tools. The spoon has a shallow bowl to hold liquids. The fork has sharp tines in a parallel row, to hold solids and also to stab them. Both tools have handles. In terms of their code, both the spoon and the fork have shared functionality. They can both hold things. They can both be lifted to transfer things from a plate or bowl to the wielders mouth. The spoon has a "dip" functionality, where it can be slid into a liquid to gather it. The fork has a "stab" functionality, where it can impale solids to gather them.

So, what would these tools inherit? Both would likely inherit the lift method and the hold method. You could put those in the same module and both could inherit it. Now, suppose you wanted them to both be made out of metal, and thus you wanted them to react the same to magnets, or to being heated? You'd want to code that functionality into another module that deals with those things, right? Because a wooden spoon and a metal fork wouldn't inherit the same material properties, but would inherit the same usage methods.

But, you WOULD want a metal spoon and a metal fork to inherit both the usage methods AND the metal properties, wouldn't you? That's multiple inheritance.

A lot of modern languages try very hard to pretend they don't do that, by making you only officially "inherit" a single parent, and then writing interfaces to "mix in" methods from other modules that would normally be inherited too, but can't be because it's all too common for people to not factor their modules very well, and thus end up with overlapping methods… and that's the only real issue with multiple inheritance. If you inherit several things that have "hold" methods, which one do you call?
13 Jun, 2014, Sorressean wrote in the 22nd comment:
Votes: 0
What multiple inheritance is, in theory is vastly different from the way it is used. Maybe it should only be used for smaller logical bits of code, but there are issues with that from my perspective.
1) Templates would have to have some form of inheritance. e.g: every time something new is added, in order to make an object you have to essentialy recode the new object and then add what you want through multiple inheritance. This requires everything being part of one object (yay diku!) or splitting everything into modules as was already stated. Either way, this means modifying code per object, or per object type.
2) There's not a way, given the first point to actually do this from within the mud itself. With the component method, scripts can create their own components eventually and it will be the same as if it were created in c++. I'm going for flexibility here, not massive inheritance chains.
13 Jun, 2014, Sorressean wrote in the 23rd comment:
Votes: 0
On another note: I notice a lot of Quix's suggestions are really really bias toward LPC, which is fine. I have a couple points though.

While I did like LPC, it seems you have two options: code everything yourself (LPUni and fix "security issues," or use something like dead-souls, which looks a lot like diku in it's ideas that you can grab an engine and play right away. The second solution would be soemthing like DGD (which until sometime recently costed thousands of dollars if you wanted to accept donations and which is now licensed under AGPL to prevent such, from what I understand).

1) Aspen is barebones, but not barebones to the point where you will need to reinvent a lot of systems that you can build on. Serialization and everything is handled (it all goes to XML). My goal is to provide enough for anyone to use the engine but to still encourage people to be unique. Only time will tell if this actually happens.
2) Aspen is licensed under MIT. Go forth and accept donations or pay-to-play perks.

The second point is the best for me because I feel that if mud admins can accept donations or make their muds pay-to-play it will start driving the usage of muds a bit more. I believe that if an admin can make a bit of money off of a mud, they will keep their interest on the mud and it won't become one of the thousands of muds just running for the sake of running with no development happening. It's also a great way to help people out that are coding and just want to pay for server costs and I do not want to hinder that. I wanted to leave the license as open as possible.

As to my first point, I really like the idea of barebones; as I mentioned, it requires people invent their own content, which will be useful to a smaller nitch of developers than something like a ready-to-play mud will. My hope is that this will help create a new flavor of muds: one where you log in and perhaps see the Aspen engine and aren't ready to select your top 5 skillgroups and a diku race.
13 Jun, 2014, quixadhal wrote in the 24th comment:
Votes: 0
You're correct in noticing my bias towards LPC. :)

Part of that is that while not perfect, LPC does things in a way that makes a lot of sense to me. It isolates the game driver from the game in a way that allows you to develop any kind of game system you want, being as similar or different from the other muds out there as you want, without having to muck about with driver code.

There have been several attempts to make barebones mudlibs for various LPMUD drivers. The real issue that is that everyone has a different idea of what they want a barebones mud to do for them.

For some, a barebones mud is something like Lil (mudlib for FluffOS) or SocketMUD (Diku-clone). They let you log in, do a few commands, but it's up to you do make everything else.

For others, they want a toolkit without the game… the LIMA mudlib, and perhaps the TMI-2 mudlib, are good examples from the LPMUD world. NakedMUD is also a decent example, and hopefully Aspen is aiming to be in this space as well. :)

For someone wanting a tookit LPC mudlib, I encourage people to look at LIMA and TMI-2, but realize that they both have issues. LIMA isn't finished, and never will be unless somebody else picks it up and runs with it. The guys doing LIMA were heavily invested in the "verb" system, so the design is centered around that… it used to be ZorkMUD. TMI-2 was a great mudlib, built around the idea of making it easy for builders to extend the game… but it's also very OLD, and because of their heavy use of properties, it can be difficult to make things react when a property changes.

Personally, I'd like to see a system where there are working examples of most of the kind of core systems that people tend to want in their muds (combat, spells, mounts, virtual wilderness areas, etc), but done in a modular enough way that you can either expand the basic example or cleanly rip it out and replace it. To date, this hasn't been the case since systems tend to intertwine pretty tightly.
13 Jun, 2014, Sorressean wrote in the 25th comment:
Votes: 0
That's pretty much where Aspen is aiming to go. I'm basically looking to do what Nakedmud dreamed of doing before it was tossed and made inactive.

Regarding modules, I'm already there to a point. I'm looking for ways to keep things as modular as possible (e.g: make stats so that the player can add their own). rather than include this in the mud base itself though, I've created a repo called aspen-modules. The idea is that when releases of Aspen are made, I can package the modules up separately and provide patches when aspen is released for people to upgrade their modules. So you pull down the modules repo and then drop in individual modules. Each wiki page on the github repo will have an installation section if anything is different or extra work needs to be done. To keep things simple for example, I might just have a stattype.h file in which the developer adds an enum with the stats they want to make available to the stats module.
16 Mar, 2015, Sorressean wrote in the 26th comment:
Votes: 0
The post above my last mentioned working examples of systems.
So, question for all of you: What systems do you want to see in a mud (combat etc)?
I'd like to provide these as external modules as I already stated, but I'd love examples of what people would like to see.
Ready, set, go.
17 Mar, 2015, alteraeon wrote in the 27th comment:
Votes: 0
Quixadhal, the problems you're describing with exits being linked incorrectly and not being findable aren't the sign of a broken system, they're a sign of an immature OLC:

>rset find exit 3301<
Room 3308 west -> Gravel path between hedges
Room 3349 east -> On a crunchy gravel path
52103 rooms searched.
2 rooms found with exits leading to room [ 3301] A branching of the path.

On area stat:

Links to/from zone [330] 'The Jo'Kerin Gardens'
Linkage out - room [ 3317] links to room [ 16605] at level 33 (diff 2)
Linkage out - room [ 3348] links to room [ 16698] at level 33 (diff 2)
Linkage in - room [ 16605] links to room [ 3317] at level 35 (diff 2)
Linkage in - room [ 16698] links to room [ 3348] at level 35 (diff 2)

And this is in addition to the more immediate checks of 'you've just linked outside this zone', 'you don't have permission to link there', 'nonlinear return exit already exists in target room', 'the map looks broken', and other miscellaneous checks. While I understand your point that other systems of setting exits would eliminate this issue entirely, it's foolish to think that it wouldn't expose different but related issues - after all, you can never get a null pointer crash in Java, but that doesn't in any way solve the problem of Java systems crashing due to null object exceptions.

The simple fact of the matter is that building is, and must be, complicated. A minimum base level of complexity is required for building to be interesting, and that minimum level of complexity is going to allow builders to make mistakes. A good olc will find ways to expose the most common mistakes via heuristics, and a poor olc will result in broken areas no matter how your building system is organized internally.


Alter Aeon MUD