20 Mar, 2007, Sandi wrote in the 1st comment:
Votes: 0
Anyone done it recently? Any thoughts? Cautions? Stories of glory?

I have to admit, the current tenor of the MUD community is giving me second thoughts, although that's been my objective since I started, back when the only descendant of ROM was ROT.
20 Mar, 2007, Guest wrote in the 2nd comment:
Votes: 0
I haven't done it recently unless you count AFKMud 2.0 in that. I've had mostly positive results, people are evidently reading the license and making an effort to comply. With a few exceptions of course which got dealt with. So I guess my experience overall hasn't been that bad. Then again it's not exactly a wildly popular codebase :)
20 Mar, 2007, Omega wrote in the 3rd comment:
Votes: 0
my recommendation is to if your going to release your code-base, ensure that it is full of good features, balanced, and decked out, with non-snippets.

Most people are sick of downloading mudbases that claim to be unique and cool and full of features, and then downloading a completely snippet filled codebase. Personaly that drives me nuts when I download something and 90% of the work in it was snippets, and their 'cool feature' list consists of the circle skill for thieves.

Just my two cents, but if your going to release a code-base, make sure its decked out with things that are not-common in the mudding universe, or atleast, uniquely coded.

When i release my mudbase (which is coming soon once i get authorization from the other devs that had contributed to it) i suspect that most people will either download it in mass amounts, or avoid it like the plague.

500k lines of code, C++ decked out with features that are non-common, and are common, tons of game-play options, and a plethora of bugs ;) but hey, thats just me.

In anycase, you get my point, make sure its decked out.
21 Mar, 2007, Sandi wrote in the 4th comment:
Votes: 0
Well, take a look at this webpage, and you can tell me if it's "decked out". :wink:

DeepMUD Changes

BTW, I noticed you're starting over with Sandstorm. You're welcome to start over with DeepMUD instead of ROM.
21 Mar, 2007, Skol wrote in the 5th comment:
Votes: 0
Might also look at ours, one day, I'll see about releasing it.
Ansalon Changes 1999-2007
Of course some are the usual 'dual wield' etc, but those were actually done in 96-98. The main goal other than obviously improving the gameplay, was to keep the familiarity of the game. So newbies and people used to the Diku line would feel at home still, then learn the additional commands and so on.
21 Mar, 2007, Omega wrote in the 6th comment:
Votes: 0
sandstorm is using a really old backup, bout 7 years old.

features from the newer sstm are being pulled into it, also rocs is being developed in sstm now, so it is more of a focal point for myself.

no need to use any other base, not going to sacrifice the work that myself and nick did. For those of you whom don't know, nick scaffe helped design sandstorm, back when it was called the dark forgotton, samson should remember that name. in anycase, he came down with a slight case of leukemia and passed away, i continued all the projects he wanted, thus why sandstorm got to be about 500,000 lines of code, which is also why i dropped back down to the older code, just made more scense to work with 170,000 lines, though its over the 200,000 mark now cuz of the features i've been pulling from the bigger sstm. but meh.

In anycase, my reason for dumping backwards was to make sandstorm exactly how i wanted it, apposed to being decked out with features and no balance between them, which was a big issue with sandstorm. I also figured, hey, why write rocs on it, since it was basicaly a mud full of uniquely written bits and pieces with only afew snippets, it seems like the right idea, plus, its schedualed to be released when rocs is finished. Going to be my first released mud-base, also going to contain the rocs editor, which in my humble opinion, its going to be well worth it.

On that note, i'll also be releasing stock rom with rocs aswell.

anyways, back to the subject at hand.

if you want people to respect your codebase and like it, you gotta have good features, balance, and thoughtful design. Just my opinion.
21 Mar, 2007, Sandi wrote in the 7th comment:
Votes: 0
Skol, I read through your changes back when we reviewed you for MudQuest. I was impressed. Looking at my notes, I was also impressed with the way you responded to a complaint from a player about high-level aggies. Funny how the process works. Anyway, we've been trying to get in touch with you. I know it's been a long time, but if you'd like to be listed on MudQuest, send us an email, please.

I took the same approach with DeepMUD, trying to maintain the feel of ROM. Trouble is, while you can play my game like ROM, if you do you're gonna die a lot. :)
22 Mar, 2007, Sandi wrote in the 8th comment:
Votes: 0
Darien said:
On that note, i'll also be releasing stock rom with rocs aswell.

I'm waiting…. :)

That's one thing I don't have, is OLC. Are you going to have something like copyover?
22 Mar, 2007, Omega wrote in the 9th comment:
Votes: 0
rocs is just an online creation system, no copyover in it.

sofar there is a great security module, a basic string editor (working on advancing it) a web-module (install at your own choice/risk – allows for editing through webpages)

all an all, rocs is coming along slowly, there is allot of work that goes into making online creation, there is even more when your trying todo things like, avoid using the same name or syntax as someone else because they'd claim it was derived from them if it did. So allot of work is being done to avoid this issue. Which is another reason why rocs is taking so long.

rocs has its own build-in logging system, so you'll get a rocs.date.log in your log-directory, this goes from everything from bugs, to if you are logging olc-usage (which you can do in a series of levels)

those are just some of the things you can expect with rocs. but truly, there is more. But you'll have to wait and see them :)
22 Mar, 2007, Guest wrote in the 10th comment:
Votes: 0
Honestly I don't think you should be worrying about "copying command names" when people can't copyright that to begin with. My personal advice would be to just code what feels natural instead of forcing it to be something else. At least that's how I'd do it and distribute it if I were writing a new OLC.

And I'd tell certain pigheaded members of the community to stuff it when they came to claim I ripped them off :)
22 Mar, 2007, Kayle wrote in the 11th comment:
Votes: 0
I think many of us here would. :tongue:
22 Mar, 2007, Conner wrote in the 12th comment:
Votes: 0
I thought many of us here did.. well, the telling of "certain pigheaded members of the community to stuff it when they came to claim" we "ripped them off" part anyway. :wink:
22 Mar, 2007, Omega wrote in the 13th comment:
Votes: 0
command names aren't the big worry, function names however, are, case and point

AREA_DATA *get_area_data(int vnum); thats the ivans olc.

AREA_DATA *find_area(virtual_number vnum); thats rocs.

Completely differen't code within them, as i've structured rocs completely opposite of it.
but you get the point.

if i called it get_area_data, he would bitch saying i ripped his code and modified it. I'm not wanting to battle over something so stupid. So i'm avoiding the stress by doing things alittle differently. besides, it'll look cleaner and crisper :)

and it'll be something new for people to work with, don't want someone going 'hey, this is just like ivans' cuz its not.

besides, theres allot more going into it then staving off things like that, allot of work is being done to create a new generation of tools for builders to use, that will give the average mud far more ability to build a more detailed area then ever before.

Which is a big part of what this is all about. We want to enhance the existance of the online creation not by creating something that does the same damned thing, we want to have something that builds better, is more stable, has more functionality, and does the job with ease of learning. No learning by Squads. Some may get that, some won't.

In anycase, rocs is coming along, i'm almost at the test-phase to test out the templated editor and all the functionality of the string editor. once i've tested it and debugged it and it works, then i get to build the rest of the editors. else-wise, most of the features are complete. just a matter of developing the editors once everything is tested.
22 Mar, 2007, kiasyn wrote in the 14th comment:
Votes: 0
you could just use a different naming convention

AREA_DATA *getAreaData( int vnum )

22 Mar, 2007, Omega wrote in the 15th comment:
Votes: 0
indeed, but i'd prefer to avoid similarities where possible.

but meh, its all good :)
23 Mar, 2007, Davion wrote in the 16th comment:
Votes: 0
Sandi said:
Anyone done it recently? Any thoughts? Cautions? Stories of glory?

I have to admit, the current tenor of the MUD community is giving me second thoughts, although that's been my objective since I started, back when the only descendant of ROM was ROT.

The closest I came to releasing a codebase is ShadowStorm. But! I'll be releasing a codebase in the very near future here on MudBytes.

I think if you're going to release a codebase, how many "mods" you have made to it isn't always the key feature. Think about it- When a person sets out to find a codebase, usually they have some ideas on how they want it. Obviously, it's very rare you will come across a codebase that is in the exact form you want it in. I think the key to releasing a codebase relies on usability, uniqueness, and documentation.

Usability entails that the code you wrote is easy to use. I'm speaking from a programmers point of view, purely. Being able to read functions and understand the flow of the code is huge. Most people don't want to spend a year trying to figure out how the code works, so a steep learning curve is a must. You should also be able to mod the codebase to work how you want it fairly easily without having to change hundreds, even thousands of lines of code to get your result.

The uniqueness is obvious. Obviously we don't want another ROM codebase. We already have one (or ten). Give us something new! Interesting features no other codebase can claim.

And documentation is also obvious!

I simply would not use Sandstorm in any incarnation, simply because it's not very usable unless you know it backwards and forwards (good luck learning 500k lines of code!) This goes for ShadowStorm as well (even though it's 120k, a newbie trying to pick up on it isn't likely.)
23 Mar, 2007, Omega wrote in the 17th comment:
Votes: 0
hey, sandstorm is very usable, you never put the time or effort in mr.davion.

You took on the project of sandstorm, then you took on like 40 more projects, and barely touched it, atleast from what I saw when i got back from my basic, so no claiming unusability :P

and yeah, i know it backwards and forwards, i wrote it. As with any base.

A LP dev ganders at rom and goes 'WTF' just like a rom dev looks at LP and goes 'WTF' any base takes time to learn, and anyone who downloads a base, cannot simply gander at it and be like, 'oh yeah, this is awesome' meanwhile they have stock rom…. not so awesome..

my point is, anyone who wants to use any base, needs to take the time to actualy learn it, atleast the basic setup and layout of it.

case and point, sandstorm has every file-name labeled to give an idea of its contents, and has several directories of source, such as olc, skills, utilities, and ofcourse, my favorite, snippets(guess whats in that one)

but key point here, every directory has its files named to its contents.

directory C has 70 some-odd files, in C you will see information.cpp immortal.cpp wizlist.cpp clan_raid.cpp clans.cpp update.cpp…. you get the picture, things are named appropriatly to their contents.

I'm not going to put the wizlist code in the clan_raid file.. plain and simple.

Ofcourse, it has been along time since you've seen sandstorm, and i did ofcourse leave you with a shitty job todo in it… porting those damned in_room->people lists to stl…. which btw, hurt my brain when i did it, but it works :P

but yeah, thats just another example of how a mud should be layed out, structured so you know the file-contents.

don't name the files lkhasdlkh.c i hate muds that do that, makes me always go 'BORING' and read the entire mud because, well, i'm lame, and its what i do, so shutup :P

anyways, i've ranted long enough, so i'm done.

btw, davion, love that string lib :)
23 Mar, 2007, Sandi wrote in the 18th comment:
Votes: 0
Interesting views, Davion. DeepMUD isanother ROM codebase. Although, the const.c owes more to Merc. But, I've gone in a different direction than the other offerings I've seen. And, as it was conceived as a codebase from the beginning, I haven't done all the things that most IMPs do. Rather than put 8 years into new skills, spells, races and areas, I put the time into changing the essence of the gameplay. DeepMUD is more realistic than ROM. You can hold or wield things with either hand. You can attack a wolf with a steak if you choose, though the wolf will likely snatch the steak from your hand and eat it. You can set lights down to light a room, and builders can make a light for any wear position. The nutrition system was recently described in another thread. Combat is not turn based, and a skilled fighter won't rely on automatic strikes. The biggest difference though, is the game is hard. Combat advantages apply to the mobs as well, and you won't be killing things 3 levels above you.

I suppose the whole question hinges on whether or not Tir na nOg will become popular. I suspect I'm getting the cart before the horse here. Though, as you mention, documentation is important and I don't feel like writing docs for others if they'll never be used. Hence, my attempt to decide now if I should persevere with plans for release.
23 Mar, 2007, Guest wrote in the 19th comment:
Votes: 0
I simply would not use Sandstorm in any incarnation, simply because it's not very usable unless you know it backwards and forwards (good luck learning 500k lines of code!) This goes for ShadowStorm as well (even though it's 120k, a newbie trying to pick up on it isn't likely.)

This right here has been reported to me as both a major hurdle and one of AFKMud's greatest strengths. Depending on who downloads and uses it. I'm hovering somewhere around 160K lines of code and some people have told me that's just too overwhelming, while others who are more familiar with Smaug say the organization of the codebase is much better and easier to follow. So I can see how 500K lines of code would look truly daunting. I'm not sure I'd want to wade through that much either. :)
24 Mar, 2007, Omega wrote in the 20th comment:
Votes: 0
man, its all in the eye of the beholder.

i can sitdown with any mudbase released, and traverse it, and get to know it in a matter of weeks, if i'm interested, less then that.

i used to scalp features from mud-bases, so i got quite adept at finding my way through the various bases. tis how i taught myself to code. That and building snippet farms. (not so much anymore)

but still, anyone who invests some time in a large mud, will beable to traverse it quickly.