|
|
Davion
Idle Hand
Group: Administrators
Posts: 1,441
Joined: May 14, 2006
|
#32 id:13250 Posted Oct 3, 2008, 12:25 pm
|
quixadhal said:What are we using as our baseline? Stock 2.4b6? The cleaned up version? The cleaned up g++ version? Some other variation that everyone likes? I hear QuickMUD is pretty nice and doesn't have too many bells and whistles added, but haven't looked at it yet.
That's probably step 1... deciding where we're starting from, so we can poke around and see what all needs changing. I'd hate to put time into developing OLC or a new editor if we start from a branch that has one already.
I think this is exactly where we should start. I also think it's a fairly simple answer. The g++ clean up of ROM. We are setting up to be a ROM derived codebase. Picking something like Quickmud, 1stMUD or any of the other attempts at ROM would mean we're not directly derived from ROM. The reason I say the g++ clean up, is because what we're attempting to do is modernize the codebase. Now, I'm not saying here that we should full on implement C++ into the codebase, but instead, allow the option for developers to do so if they please, without having to jump through the hoops of getting it to compile under g++. Once we decide on the codebase, we can move on from there and apply all the bug fixes and clean up of the code.
On to the systems. The OLC will definitely be a big step. But seeing as we're trying to keep the feel of ROM I think Ivan's OLC is probably our best bet (1.81 if I may suggest a version.) The system is mostly clean, and very few bugs (with the exception of the progs... I'll get to that later.) It's also very familiar to the builders and programmers a like. There's also a bunch of guides, and general information about it all over the community. Now, for additions to the OLC, I think we can't ignore the plea for a class and race editor. It's totally possible with the existing system. That said, you can't really just stop there. With those, you should also include an editor for the skill/spell table, as well as the groups, so one can easy modify the inner workings of the games without having to dig through the code. Also, for additions to the OLC, we could add ones for generic tables as well (like the bits, and pretty much everything in tables.c.) Along with that, we can remove most of the constants (like the OBJ_VNUM_*, MOB_VNUM_*, ROOM_VNUM_*, MAX_*) and put an online editor for those as well. Now for the progs. I think we can all agree that we'd need to move to something a little closer to an actually scripting system. The PROGs are buggy as -hell-. I spent a good year and a half debugging those pesky things and still didn't come out with a perfectly clean system. For that we have many options, we can write or own, or not reinvent the wheel, and use something like python, javascript or lua. I'm a huge fan of python, and Boost::Python allows for easy integration, and you aren't even required to write wrapper functions for anything really. You can expose already written functions and structs with ease. I know I'm getting a little ahead, but it's something we should atleast start thinking about.
Colour. Colour is a huge part of a MUD. Since we're releasing this as a codebase for the masses and not our own personal game, we should consider an easy way to customize the game appearance. I've used Lopes in the past, and moved on to write my own. I've also looked at a few custom systems, and one of the best was one that used keys for customization. The colour codes looked something like {[say_name], {[say_text], {[score_brackets], etc. It made it so you could totally customize everything, and not just at the implementor level, but all players could make the game the way they want. I've even gone so far as to implement the QSF templating system into the MUD so you could edit score, who, whatever, from a website and view the changes without even having to reboot.
That leads me to the database. Flatfiles verses and actual DB. Very hard to decide this one, as not everyone has the access to a db of any kind. But using a db gives us the ability to have a great deal of integration with a website without very much work. We are attempting to modernize though, so maybe it isn't such a bad thing. -Every- game has to have a website... it's just the standard now, so we should consider at least some level of integration for websites.
Now for the copyover. I think we should offer a little sugar on this one, and implement a seamless copyover that is barely detectable by players. I've gotten pretty close to this, to the point where there's almost no lag. You can view it in the MudConV codebase on this site. Just check acnt_cmd.c and comm.c for the meat of it. This comes -really- close to seamless, it only misses because it doesn't save mobs, combat, etc (mostly because the codebase lacks all these.) But I think it's a nice feature.
Infinite bits. This is a tricky one. I happen to very much enjoy Runter's bitmask code, for implementing infinite bits (also available somewhere on this site.) However, most implmentations of infinite bits introduce some sort of data structure or array to the mix. The problem here, is with the object values, as they use an array of ints to set many default bits. We'll have to tackle that one once it's infront of us, and decide which way to go.
Annnyways, that's my rant. I've obviously though a lot about this subject over the last few years (and have evne made a few attemps)
|
......................... 
|
|
David Haley
Wizard
Group: Members
Posts: 6,913
Joined: Jun 30, 2007
|
#33 id:13251 Posted Oct 3, 2008, 12:47 pm
|
Updating it to have it compile under the most recent version of g++ is essential IMO. It's not that hard if you know what you're doing w.r.t. common problems, I've done it for several codebases already.
Player-customizable color is also a must-have for me... I think that being able to color code information the way you want it means that you can maximize your ability to see the information you want.
I would recommend against any kind of database that involves a separate server. A database stored in a flat file would be ok, although I'm not sure it's necessary. A sane file format is obviously a must.
Personally I would refuse to use anything that doesn't have decent support for arbitrarily sized bitvectors. I don't believe that you need bitvectors that can grow at runtime, however, you should be able to create them with an arbitrary number of bits. This is an excellent place to use C++, incidentally, even if you don't encapsulate the whole codebase.
|
|
|
Fizban
Wizard
Group: Members
Posts: 619
Joined: Jan 8, 2007
|
#34 id:13252 Posted Oct 3, 2008, 1:19 pm
|
g++? I'd agree gcc is essential but g++ hardly seems so. (Yes, I am aware g++ will compile C code as well, but I see no purpose of sticking to its guidelines when it's not what most people will use and not even intended for the language the codebase is written in.)
|
|
|
|
|
Fizban
Wizard
Group: Members
Posts: 619
Joined: Jan 8, 2007
|
#36 id:13255 Posted Oct 3, 2008, 1:45 pm
|
Simple that if g++'s intended use was compiling C code there wouldn't be gcc, there would only be g++.
|
|
|
Davion
Idle Hand
Group: Administrators
Posts: 1,441
Joined: May 14, 2006
|
#37 id:13256 Posted Oct 3, 2008, 1:48 pm
|
Fizban said:Simple that if g++'s intended use was compiling C code there wouldn't be gcc, there would only be g++.
Well, technically, g++ is gcc, but with the -x default option set to c++.
|
.........................
|
|
|
|
|
|
Fizban
Wizard
Group: Members
Posts: 619
Joined: Jan 8, 2007
|
#40 id:13260 Posted Oct 3, 2008, 2:29 pm
|
Pedlar said:using g++ can very much so be useful in the long run, as a MUD progress and a coder sees more views into inheritence, methods, and other nifty C++ features, it will be readily avalibe.
And like DH said (Oh my god im actually gonna ggree with DH...SHOOT ME) the stricter guidlines promote better coding standards.
It's not so much that they promote them, they do. The problem to some extent is that they enforce them. A good coder likely attempts to adhere to them anyway, but most coders that use DIKU derivatives instead of going from scratch are relative newbies. Losing backwards compatibility and harming said newbies just doesn't necessarily seem like a fantastic idea.
|
|
|
|
|
quixadhal
Wizard
Group: Members
Posts: 1,473
Joined: Oct 17, 2007
|
#42 id:13279 Posted Oct 3, 2008, 5:44 pm
|
OK, here's my novel as the sequel to your novel! Hopefully it makes sense, I wrote little bits over the afternoon... :)
Davion said:I think this is exactly where we should start. I also think it's a fairly simple answer. The g++ clean up of ROM.
Sounds good to me. I'll unpack that one and start taking a look this weekend. It might be a good idea to get a small sample survey of what environments/compilers everyone is using, just so we can know what bugs show up where. I'm using Debian (Etch) Linux, and gcc is at version 4.1.2.
Davion said:Now, I'm not saying here that we should full on implement C++ into the codebase, but instead, allow the option for developers to do so if they please, without having to jump through the hoops of getting it to compile under g++.
I agree with this too. I'm no fan of C++, but there are very few thing (perhaps none!) that you can do in C, that a reasonable C++ compiler won't let you accomplish just as cleanly. Having the codebase be g++ clean also opens the door to use C++ wherever it's appropriate, such as the STL containers, the std::string class, and extensions for database access, etc.
Davion said:On to the systems. The OLC will definitely be a big step. But seeing as we're trying to keep the feel of ROM I think Ivan's OLC is probably our best bet (1.81 if I may suggest a version.)
I'll happily defer to you on this one. My antique MUD doesn't have OLC at all, so as long as it's clean and mostly bug-free, it sounds good. That's another one that, like editors, we could eventually have multiple frontends if it's desireable.
Davion said:Now, for additions to the OLC, I think we can't ignore the plea for a class and race editor. It's totally possible with the existing system. That said, you can't really just stop there. With those, you should also include an editor for the skill/spell table, as well as the groups, so one can easy modify the inner workings of the games without having to dig through the code. Also, for additions to the OLC, we could add ones for generic tables as well (like the bits, and pretty much everything in tables.c.) Along with that, we can remove most of the constants (like the OBJ_VNUM_*, MOB_VNUM_*, ROOM_VNUM_*, MAX_*) and put an online editor for those as well.
Fine with that too. I'm slowly migrating my own game to store everything in an SQL database, so eliminating everything that's hard-coded and allowing it to be modified on the fly sounds like the way to go here too. All that really means from the coder's point of view is that you can't get away with clever-but-ugly constructs anymore, but have to use thin wrappers for everything. if(ch->aff & AFF_BLIND|AFF_POISON) would become if(is_blind(ch) || is_poisoned(ch)). Sure, it's not quite as efficient, and it looks less hax0rzish, but we're not running MUD's on the C64 these days, and us old folks like things in big print. *grin*
Davion said:Now for the progs.
Yep, buggy mprogs are junk. We'd have to clean it up and keep them for legacy suppport, but if we implemented a proper scripting system, we could translate them as the area files are being imported. Python is fine. I know we have Lua folks in the camp too. I like Ruby. I'd say let's go with whatever will embed with minimal fuss, since anyone extending the codebase will likely have to add or modify the interface to the scripting langauge as well.
Davion said:Colour. Colour is a huge part of a MUD.
Heh, my MUD pre-dates colour too. :)
I do agree though. I helped do a rewrite of the colour code for AFKMUD a few years ago, and I think that's actually made it into the SmaugFUSS code as well. A discussion we had over at lpmuds.net a while back was interesting, as someone suggested a scoped color system, and I suggested using the diku color codes to make it less verbose.
I suppose, it would be quite useful to have some syntax (extension of Diku, or other) which allows for color class names rather than just hard-coded colors. Ideally, I'd like to be able to specify exact colors when I want them (&rRED&R text!), or specify class names when I just want things to be consistent (This will &(damage)hurt&R you!). Extending that to allow scoping too.... This &r(red text&) will &((damage)hurt&) you!
I would avoid using color tags for things like "say" or "tell" though. Those aren't properly things that you want to tag, those are things that want their own channel data. That channel may then be configured to be a certain color, or have a certain prefix tag, but it's a different purpose. Tags don't change the purpose of the data, only the presentation. If that makes sense.
Davion said:That leads me to the database. Flatfiles verses and actual DB.
I'd put this on the back burner. Personally, I'd love a database, and I'm a PostgreSQL nut (having spent 10 years or so working with it), but having recently spent some time trying to work with ODBC in C.... not pretty. Using a native API is a pain, because we then have to pick a database -- and you can't please everyone.
I would, however, encourage the idea of pretending we were moving to a SQL database. I'd be happy to (eventually) write up a schema based on the existing ROM file format too.
Why would that be helpful? See below for the bits part of the topic. :)
Davion said:Now for the copyover. I think we should offer a little sugar on this one, and implement a seamless copyover that is barely detectable by players. I've gotten pretty close to this, to the point where there's almost no lag. You can view it in the MudConV codebase on this site. Just check acnt_cmd.c and comm.c for the meat of it. This comes -really- close to seamless, it only misses because it doesn't save mobs, combat, etc (mostly because the codebase lacks all these.) But I think it's a nice feature.
Not a deal breaker, but I don't object as long as it doesn't introduce any complications. I abhor the idea of doing a copyover on crash though... it's bad enough that most people run their games in a script that loops regardless of how the game exited.
Davion said:Infinite bits. This is a tricky one. I happen to very much enjoy Runter's bitmask code, for implementing infinite bits (also available somewhere on this site.) However, most implmentations of infinite bits introduce some sort of data structure or array to the mix. The problem here, is with the object values, as they use an array of ints to set many default bits. We'll have to tackle that one once it's infront of us, and decide which way to go.
Here's where my SQL topic comes into play. I hate bits. They were great back when my MUD ran on a Sun 4/110 with 12Megs of RAM, and my game took up 7.5M of it. Now that even the refrigerator has 32M of RAM, and any decent site hosting will provide you with 128M+, there's no reason to pack lots of values into a single integer (or a cobbled-together set of macros to access an array of integers).
Well, in a proper SQL database, everything is stored as individual data elements. Part of the process of designing a database is called normalization, and it involves identifying what bits of data are properly seperate and making them distinct. For example, don't store the room flags as a single column, break it apart into seperate boolean values.
Code (text): 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28 | #3003
Cleric's Bar~
The bar is one of the finest in the land, lucky it is members only. Fine
furniture is set all around the room. A small sign is hanging on the wall.
~
0 CDS 0
D2
You see the entrance.
~
~
0 -1 3004
D3
You see the inner sanctum.
~
~
0 -1 3002
E
sign~
The sign reads:
Free instructions provided by the waiter:
Buy - Buy something (drinkable) from the waiter.
List - The waiter will show you all the different drinks and
specialties, and tell the price of each.
~
S |
by something more like:
Code (text): 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38 |
ROOM
Vnum 3003
Short Cleric's Bar~
Long The bar is one of the finest in the land, lucky it is members only. Fine
furniture is set all around the room. A small sign is hanging on the wall.
~
Area 0
Sector Inside
Flags NoMob Indoors Law~
EXIT
Direction south
Vnum 3004
Long You see the entrance.
~
Keywords ~
END
EXIT
Direction west
Vnum 3002
Long You see the inner sanctum.
~
Keywords ~
END
EXTRA
Keywords sign~
Long The sign reads:
Free instructions provided by the waiter:
Buy - Buy something (drinkable) from the waiter.
List - The waiter will show you all the different drinks and
specialties, and tell the price of each.
~
END
END
|
I would have had my example posted sooner, but I had to go paw through the header files to figure out what "CDS" meant. THAT is why bits are bad. :)
Note that Flags could have also been stored as three seperate lines, one for each bit that was set. In a Database, that's how it would have worked. If the room were a C++ class, it would also look like that, having separate accessor functions like room->is_NoMob(). In C, we'd have to use wrapper functions like is_NoMob(room).
To keep things dynamic at runtime, I guess we'd move to a property system, ala get_prop(room, "NoMob"). To be mutable at runtime, we can't use defines, enums, or the other usual ways to map ROOM_NOMOB into (C) or 0x04 or whatever, so we may as well use strings so the code is readable, and we may as well use the values we'd want in the files.
|
......................... 
Last edited Oct 3, 2008, 7:45 pm by quixadhal
|
|
|
|
quixadhal
Wizard
Group: Members
Posts: 1,473
Joined: Oct 17, 2007
|
#44 id:13294 Posted Oct 3, 2008, 11:39 pm
|
Ok, round 1 was the easy stuff. Do we have a place to upload patches/additions/etc yet? I have a nice fat diff that is the fixes I've done tonight to make g++ happy with all the warnings I have enabled.
Believe it or not, -Wall does NOT enable all warnings. It enables all the default warnings, but there are quite a few that you have to turn on explicitly. Don't ask me, ask the GNU people. In any case, you can see all the gory details in the Makefile. You can also see a running commentary in the file HACKLOG, which I try to remember to always create and keep up to date in these kinds of projects.
Until I know where to put them, you can download the diff here, and a full tarball here. At least, I hope so. My ISP isn't very nice, which is why you have to use https to get in.
I did try running the game, creating a new character, and logging in. That's about it though, so if anyone else wants to give it a once-over, please do!
|
.........................
|
|
Davion
Idle Hand
Group: Administrators
Posts: 1,441
Joined: May 14, 2006
|
#45 id:13312 Posted Oct 4, 2008, 6:29 am
|
quixadhal said:Quick question... I noticed the filename for the G++ clean version of Rom 2.4b6 comes up as CleanedG++Rom24b5.tar.gz. I assume that's a typo, but just wanted to clarify before looking at something that's a version out of date. :)
Yep. Good call on the typo. Eesh. I make far to many of those.
|
.........................
|
|
