01 Oct, 2010, Quarlash wrote in the 21st comment:
Votes: 0
(Off Topic, Sort of)

The initial post, though somewhat longer than I wanted to read at 7am (Sorry, just woke up, but it definitely made me think :smile:), gave me the impression of releasing a codebase that allows an administrator to do less(or none at all?) programming/scripting and more administrating/content development. I'm not sure that was the intent, but it did put me to thinking, any there are codebases right now that have a "choose as you go" framework? (Prebuilt systems that through config files [written through mud commands / external utilities] give you the ability to build a working mud)

I could see potential in this, if there was enough effort placed into the idea of customization through configuration (And the potential for a community based around releasing pre-build configuration files, and a nifty editor for those files), and at a low enough level that the major systems (movement, direction, space[3d, 2d, not implied, 4d{?}], combat, life, spawning, development, 'areas'/'zones'/'regions'/'locations', …, etc) could have many different potential prebuilt scenarios all required to be chosen from the barebones "mud" itself (Which would encourage the development of a community as certain combinations would be inherently better than others and those who take the time to tweak the configurations and release such configurations would begin to take authority in such a community, which then lowers the barriers for entry).

The thought of this would also mean installing mud based protocols (MCCP, etc) to the core system and allowing the owner to choose which they'd like enabled. This could also potentially build a community around an open source client which could support new (open) protocols, as this type of codebase may see a large following (Even if 90% aren't of a strong developmental value, the urge for open source contributions [outside of, generally, the authors themselves] comes from a following / interest in a project and/or the perceived value of the project).

In a way, this could (very obviously) lead to more 'stock' muds, but there are also ways around this. Pre-programmed dynamic mud-content generation with some randomness in the pre-built options (And yes, the ability to tweak via code or by hand in configuration files to force identical outcomes) may as a start (obviously, more thought is required here) help avoid 'generic' muds. Even if two people used the same pre-built configuration script, it's possible to add inherent differences in the foundation of the starting project without negatively(I suppose this is subjective to an individual's perspective) impacting the outcome of the project.

… I should go back to bed.

… more thoughts. While this following idea may not be a good idea (It's too early to judge), this would also allow an inter-mud protocol which would allow muds to annex or bridge together, allowing players to essentially interact (Obviously, levels of restriction chosen by a central authority [Such as simply as the codebase developer themselves, with the potential for prebuilt configuration modules to extend / restrict] as well as by the individual muds themselves). This could potentially fend off the idea of early muds without high playerbases dying / losing interest due to slower developmental times (Though this idea definitely.. Absolutely needs far more thought than 7am coherency :wink:).
01 Oct, 2010, Dean wrote in the 22nd comment:
Votes: 0
Asylumius said:
Rudha said:
I'm not trying to come off as aggressive…

You do. Quit being a heckling, argumentative cunt and let the OP do his thing.

Consider this your warning, do not attack other posters in this manner.
01 Oct, 2010, KaVir wrote in the 23rd comment:
Votes: 0
There are a lot of barebones codebases out there, but it seems most newbie mud owners want to start out with something a bit more feature-rich - while those who don't seem to favour languages like Python or Ruby.

I've certainly no objections to someone creating another codebase from scratch, but there are so many other choices out there that I can't see it picking up much interest. You might be better off turning it into a game if that's what you're after (then when the players decide to create their own games, they'll be more likely to download your codebase as a starting point). But if you're just having fun creating a codebase, and don't care whether other people use it or not, it's not really a big deal. Muds are all about fun, whether that comes from playing them, running them, or developing them.
01 Oct, 2010, quixadhal wrote in the 24th comment:
Votes: 0
I guess one question that probably jumps to the forefront, and I apologize if you answered and I missed it…. what is the licensing of Aspen? Quite a few developers would probably be more willing to jump on board to help develop something that can be freely used and where forks can be made at will (if the core goes in a direction someone doesn't prefer). I know both the Diku license and the GPL have restrictions that make them unappealing to many.
01 Oct, 2010, Mudder wrote in the 25th comment:
Votes: 0
quixadhal said:
…I know both the Diku license and the GPL have restrictions that make them unappealing to many.

What restrictions does the GPL have that people dislike? I read over it and it seems pretty… Well, non-restrictive.
01 Oct, 2010, chrisd wrote in the 26th comment:
Votes: 0
Mudder said:
What restrictions does the GPL have that people dislike? I read over it and it seems pretty… Well, non-restrictive.

The GPL is copyleft, which broadly means that if your project uses GPL code it must also be licensed under the GPL.

EDIT: Just to be clear: many people do not like copyleft licenses.
01 Oct, 2010, KaVir wrote in the 27th comment:
Votes: 0
chrisd said:
The GPL is copyleft, which broadly means that if your project uses GPL code it must also be licensed under the GPL.

It also means you can't incorporate code that uses an incompatible licence - which rules out the majority of mud snippets.
01 Oct, 2010, Sorressean wrote in the 28th comment:
Votes: 0
I had origenally went GPL, but I might consider changing that since people don't like it; any ideas?

As to why I went c++, there is one big motivating reason for me. I am not comfortable enough with python and others to use it to get the sort of design and speed I want out of an engine.
Where engine here consists of the basic mud framework, coupled with the game logic. (I should really redefine my term, but…)
I am most comfortable with c++, and that's where I am able to make things happen.

I would of course like to see people using this, because community effort would mean that this would get pushed along faster as a result. Maybe with design ideas and other input that I would otherwise miss.
01 Oct, 2010, Rudha wrote in the 29th comment:
Votes: 0
After having researched some, I like the apache license myself. The MIT License is a pretty minimalist attribution license if you just want to make sure you're attributed and that's you're only concern, however.

01 Oct, 2010, hollis wrote in the 30th comment:
Votes: 0
Sorressean said:
About three years ago, Nakedmud was c and you had the option of going c or python. About a year and a half ago, maybe more Hollis seems to have decided to jump for Python, and Nakedmuds core isnt being developed much, with everything being made in Python. This sort of defeats the purpose of it for me, as I wanted the engine and its core in a language like c or c++, with all the cosmetics being done in a scripting language such as Python or Lua.

Not a promotion, just a correction since I've heard this exact same comment from a few people now. The recent work being done on Python has just been exposing functionality from C to Python, and rewriting the interface and cosmetic features in Python. There hasn't been nor does there intend to be a massive rewrite of the base in Python. There hasn't been much development on the core, because it's basically done (barring a couple minor features, better documentation, and cleaning up some of the source code, like you say).