Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
auth_update crash
Dec 23, 2017, 10:15 pm
By Remcon
check_tumble
Dec 18, 2017, 7:21 pm
By Remcon
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Users Online
CommonCrawl, Yandex, Bing

Members: 0
Guests: 10
Stats
Files
Topics
Posts
Members
Newest Member
478
3,708
19,242
613
bastian
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » Coding » Elysium Custom Codebase
Forum Rules | Mark all | Recent Posts

Elysium Custom Codebase
< Newer Topic :: Older Topic >

Pages:<< prev 1, 2, 3, 4 next >>
Post is unread #1 Jun 23, 2009, 9:00 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Wow, I really stirred up the hornet's nest with that reply. :P

Let me first say, that an affects revision for SmaugFUSS is out of the question. To make it work in a non-klutzy way, is going to be way more work than anyone here needs to be devoting. I don't want to waste months on reworking this, only to have to turn around then and update a whole lot of snippets to work with the new system. If people want to see a new base that works similarly to Smaug with a better design, sure, I'm willing to work on it. But like David said, it's not fast. And it is by no means a simple task.

I'm with David. The license has always bothered me, because the way it's worded it makes it seem like your work can never be your own. I'm currently debating restarting my Elysium codebase from scratch. If there's enough of a demand, I'd be more than willing to release it once it's closer to completion.

The more I dig through the code, the more I realize what a convoluted mess the innards of Smaug are. And the more it makes me sick of working with it. The Affects are a perfect example. Something this basic, shouldn't have needed to be interwoven into everything. And I'm really tired of things like this, and they're everywhere in Smaug.

A couple of things to note though:
Elysium will:
- Use Lua as a scripting language (No MobProgs).
- Make heavy use of the STL and other C++ features.

Elysium will hopefully:
- Be able to read SmaugFUSS formatted areas.
- Be as close to Smaug as possible without becoming a convoluted mess.
- Have the option to write most of your core game logic in either C++ or Lua.

Elysium will not:
- Be a convoluted mess.
- Be restricted by a ridiculous license.

I was going to reply to some of the points people made but there were so many, and the discussion so vibrant I decided to just leave it alone. :P
       
Post is unread #2 Jun 23, 2009, 9:39 pm
Go to the top of the page
Go to the bottom of the page

Metsuro
Apprentice
GroupMembers
Posts68
JoinedSep 2, 2006

The problem with that kinda thinking Kayle, is that starting from scratch is a hard process. I personally like the idea but something like this is gonna wear you down specially if your the only one working on it. Your gonna burn yourself out before getting much down and your gonna hate it. I've always wanted to learn more about programming and the like and used playing around with smaug as kinda a learning hobby. Now that my life is stable enough to learn more, I though about trying to start a mud from scratch just for the experience. Its just a big project to do something like this solo and while I dont personally know you well, I dont think I'd wish that kinda torment on even Vash... <.<
       
Post is unread #3 Jun 23, 2009, 10:24 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006


Metsuro said:

The problem with that kinda thinking Kayle, is that starting from scratch is a hard process. I personally like the idea but something like this is gonna wear you down specially if your the only one working on it. Your gonna burn yourself out before getting much down and your gonna hate it. I've always wanted to learn more about programming and the like and used playing around with smaug as kinda a learning hobby. Now that my life is stable enough to learn more, I though about trying to start a mud from scratch just for the experience. Its just a big project to do something like this solo and while I dont personally know you well, I dont think I'd wish that kinda torment on even Vash... <.<


Uh.. I fail to understand what you're trying to convey at my announcing that I'm writing a base from scratch... >.>
       
Post is unread #4 Jun 23, 2009, 10:34 pm
Go to the top of the page
Go to the bottom of the page

Metsuro
Apprentice
GroupMembers
Posts68
JoinedSep 2, 2006

"Don't do it.", "Save yourself!". To much work for a single person makes a project long and hard to complete. Do you think by yourself you can fully complete it?
       
Post is unread #5 Jun 23, 2009, 10:49 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Wouldn't be working on it by myself.

MW's Wizlist said:

Sovereigns of Eridanus

Forerunner
Kayle

Overseers
Venia Scoyn Aldar

Historian
Mikon

Myrmidons
Rose Dimension Syrax

Demagogues
Nyssia

Ambassadors
Thannie Khoryna

Artificers
Jandice Kaytone

Architects
Rilgore Vratis Renji Sindra

       
Post is unread #6 Jun 23, 2009, 10:51 pm
Go to the top of the page
Go to the bottom of the page

Metsuro
Apprentice
GroupMembers
Posts68
JoinedSep 2, 2006

Well... Good luck sir... I wish you best of luck and uhh... keep me updated... and uhh k..
       
Post is unread #7 Jun 23, 2009, 11:34 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Kayle said:

I'm with David. The license has always bothered me, because the way it's worded it makes it seem like your work can never be your own. I'm currently debating restarting my Elysium codebase from scratch. If there's enough of a demand, I'd be more than willing to release it once it's closer to completion.


Which part of the license? The one where you have to credit those who came before you? You can't even escape that in GPL utopia-land.

If you're going down this road for your codebase, craft your own license. Don't use GPL, BSD, or any of the current viral open source licenses. They can only lead to as much of a loss of control over your own work as you perceive with the Diku family of licenses. Someday if you decide to charge for access to your code someone else can come along and buy a copy, then turn the GPL against you and release it for free. In that respect I beleive the GPL to actually be MORE evil than a proprietary license with no-profit restrictions.

The more I dig through the code, the more I realize what a convoluted mess the innards of Smaug are. And the more it makes me sick of working with it. The Affects are a perfect example. Something this basic, shouldn't have needed to be interwoven into everything. And I'm really tired of things like this, and they're everywhere in Smaug.


Indeed. Part of what soured me on AFKMud was the fact that I kept running into roadblocks of the same type. Systems that were rotten to the core and massively invasive. It has some advantages, which in my case also made Overland much easier to implement, but at the same time demons which will come at you when you least expect it and cause you much pain and frustration. Like converting flags to std::bitset and then running into the affect system head on.

It also didn't help that nobody gave a crap that a ton of effort was going into pushing toward more use of C++. People said they wanted it, but as more and more got done, less and less people were supportive. Eventually it just wasn't worth putting up with the complaints some people had about how it was too hard, too confusing, and that I was a supreme jerk for having done it. The timing of most of that coincided with the community's decision to savage me on the forums, and, well, now you have apathetically lazy Samson who refuses to devote that kind of effort ever again for the ingrates of the community.

Elysium will:
- Use Lua as a scripting language (No MobProgs).
- Make heavy use of the STL and other C++ features.


Both of those right there would be more than enough to place you into what this community considers innovative and groundbreaking. And while definitely worth the efforts, I feel for you when the same people who currently say they want it turn on you later and whine about how difficult it is to understand :P

Elysium will hopefully:
- Be able to read SmaugFUSS formatted areas.
- Be as close to Smaug as possible without becoming a convoluted mess.
- Have the option to write most of your core game logic in either C++ or Lua.


Enter the idiot squad who will claim you're pulling a Medthievia.

Elysium will not:
- Be a convoluted mess.
- Be restricted by a ridiculous license.


Admirable goals. Especially the part about the ridiculous license :)
       
Post is unread #8 Jun 24, 2009, 7:25 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Which part of the license? The one where you have to credit those who came before you? You can't even escape that in GPL utopia-land.

If you're going down this road for your codebase, craft your own license. Don't use GPL, BSD, or any of the current viral open source licenses. They can only lead to as much of a loss of control over your own work as you perceive with the Diku family of licenses. Someday if you decide to charge for access to your code someone else can come along and buy a copy, then turn the GPL against you and release it for free. In that respect I beleive the GPL to actually be MORE evil than a proprietary license with no-profit restrictions.

The difference is that if it's your own proprietary license, you can still do whatever you want with it. When using SMAUG's, you have to have huge community debates any time you do almost anything ever so slightly out of the norm.

It also didn't help that nobody gave a crap that a ton of effort was going into pushing toward more use of C++. People said they wanted it, but as more and more got done, less and less people were supportive. Eventually it just wasn't worth putting up with the complaints some people had about how it was too hard, too confusing, and that I was a supreme jerk for having done it.

I think that trying to support snippets and moving forward technologically are incompatible goals. If one's goal in life is to make sure that every snippet out there still works, well, one isn't going to be able to change much in the codebase!

As for C++, well, frankly, it is a little harder to understand parts of it because it requires you to understand more about what programming actually means. Eventually you have to decide who you're writing a codebase for, I guess. Personally, supporting snippets are extremely low on my list. If you can't adapt a snippet for an older version to the newer version, well, you have a few other things to tackle and learn first. Not sure how to say it more gently, it's just that supporting snippets continually is a major problem in terms of being able to move forward.
       
Post is unread #9 Jun 24, 2009, 8:41 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

So, Samson, You're gonna come out of hiding and help me work on writing a base from scratch yes? :P
       
Post is unread #10 Jun 24, 2009, 10:51 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Not sure if I have the energy to help a lot, but I'm happy to bounce ideas around and poke at things. :)

These are suggestions that I'm tossing out which I would do if this were MY project. You are, of course, welcome to ignore them... but it might be helpful to start the ball rolling.


1) Design your game with OLC in mind from the start. If you can, make the OLC system as modular as possible, so people can use it via commands (like smaug), via menus (IE: oasis), or even via a GUI using ZMP or something of that sort.

2) Try to make use of the concept of a "thing" wherever you can. One of the problems that's always plagued DikuMUD is that there are hard-and-fast rules about rooms/objects/mobs, and they're all special cases. If you think about it, a room is just a container whose environment is the zone. A zone is just a container whose environment is the world. A sword is a container whose inventory is sized 0.0 and has no enterances or exits.

Seriously, think about that. If you can derive all physical objects in the game from a single "thing" class, and put most of your physical properties there, you will be able to do all kinds of things later on that would need a bunch of special case code now.

3) Mobs and players should be interchangable! I can't tell you how many times I've cursed the Diku folks for having their data structures be different. If you make them the same, it's dirt simple to switch control from an AI script to a command interpreter. That lets people choose how they want to handle things at the game layer... if you want named NPC's to show up in the who list, done. If you want players to become NPC's when they log off... done.

Related to this... split the body structure away from the control structure. If you can just create a new body and swap pointers, things like polymorph/possession/reincarnation, all become simple.

4) Don't limit yourself to TELNET. Sure, you'll want to code a telnet state machine to be compatible with most current users out there. Just don't limit things to only line-mode, or make it impossible to add SSH support later. Make it easy to add ports for other services, as you may find yourself wanting them later.

5) Integrating Lua is fantastic. I would suggest embracing that language and if people want support for mprogs or similar, they can alwasy write Lua code to handle it. :)


All these are just suggestions. I'm not trying to steer anything, but if you always think in terms of what some crazy person like me MIGHT want to do 5 years from now, you'll write code that's easier to extend later.
       
Post is unread #11 Jun 24, 2009, 1:51 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

Congratulations and good luck wih this decision, Kayle. I'll be happy to be there for you how I can, but given that I know no C++ at all, I can't exactly offer to help you with any of the actual code unless it's something easy like the typical "where'd I miss the damn semicolon or parenthesis or bracket/brace in this??" sort of issue.

As seems rather usual of late, I'm in full agreement with Quixadhal's suggestions.

I think I understand well enough the goal of the new license and I think that Samson may be right about the issues with being smaug-like and able to import/translate smaug area files, but I also think it's a good idea to try anyway. On the other hand, I'd only partially agree with David's comments regarding snippet compatibility. I do think that it's going to be unreasonable to maintain full compatibility with all the Smaug snippets out there, especially given the scale of change you're talking about, in fact, it may be entirely impossible. I, instead, think it'd be a good idea to incorporate as many of the concepts that the snippets out there embody as possible with some sort of admin option to enable/disable them individually. How ever feasible that may be.
       
Post is unread #12 Jun 24, 2009, 3:27 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

FWIW, I didn't say that a system shouldn't be modular with the ability to add/remove optional features via plugins or things like that. I was saying that the idea of maintaining snippet compatibility as they're currently thought of (as in, go to this line, replace this with that, etc.) is a bad thing for future development.

In fact, I'll make a slightly stronger statement, and say that a good codebase really should support modularity of various features to whatever extent possible, unless it means going through unacceptable contortions.
       
Post is unread #13 Jun 24, 2009, 5:47 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

I hadn't really stopped to think about all the things I'm going to have to write that I'm not very good with. Anything dealing with Strings really. Although, std::string might make things a bit easier...
       
Post is unread #14 Jun 24, 2009, 6:19 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Quixadhal said:

1) Design your game with OLC in mind from the start. If you can, make the OLC system as modular as possible, so people can use it via commands (like smaug), via menus (IE: oasis), or even via a GUI using ZMP or something of that sort.

Everyone keeps mentioning this ZMP thing, I might actually have to start reading up on it, and poke at elanthis and see if I can't get my head wrapped around it. On the subject of OLC, I had definitely planned to have it as easy to use as possible. And actually already had plans to make everything both command line, and menu based. Thought of setting a toggle option for people to switch on/off depending on whether they wanted to use the menu-based systems.

Quixadhal said:

2) Try to make use of the concept of a "thing" wherever you can. One of the problems that's always plagued DikuMUD is that there are hard-and-fast rules about rooms/objects/mobs, and they're all special cases. If you think about it, a room is just a container whose environment is the zone. A zone is just a container whose environment is the world. A sword is a container whose inventory is sized 0.0 and has no enterances or exits.

Seriously, think about that. If you can derive all physical objects in the game from a single "thing" class, and put most of your physical properties there, you will be able to do all kinds of things later on that would need a bunch of special case code now.


Agreed. If a good inheritance model can keep things easy to modify, and track, I'm all for it. I just need to brush up on inheritance a bit first, among other things... (sockets and network programming being the biggest.)

Quixadhal said:

3) Mobs and players should be interchangable! I can't tell you how many times I've cursed the Diku folks for having their data structures be different. If you make them the same, it's dirt simple to switch control from an AI script to a command interpreter. That lets people choose how they want to handle things at the game layer... if you want named NPC's to show up in the who list, done. If you want players to become NPC's when they log off... done.

Related to this... split the body structure away from the control structure. If you can just create a new body and swap pointers, things like polymorph/possession/reincarnation, all become simple.


I agree. I never really understood the need to split them apart when they all had basically the same fields anyway.

Quixadhal said:

4) Don't limit yourself to TELNET. Sure, you'll want to code a telnet state machine to be compatible with most current users out there. Just don't limit things to only line-mode, or make it impossible to add SSH support later. Make it easy to add ports for other services, as you may find yourself wanting them later.


I hadn't really thought of this. And to be honest, a lot of it never would have occurred to me, mainly because I've never really concerned myself with the different protocols we rely on so heavily for these games to work. But, that's all hopefully going to change soon. :)

Quixadhal said:

5) Integrating Lua is fantastic. I would suggest embracing that language and if people want support for mprogs or similar, they can alwasy write Lua code to handle it. :)


The plan for Lua was going to be to provide a flexible, yet powerful alternative to MobProgs, and at the same time allow for game logic to be programmed inside the game, without the need to copyover/hotboot all the time. The C++ side will be available for those that don't feel comfortable with a scripted game, but at the same time, for those LPCers out there that are more comfortable doing everything from inside the environment, the Lua might be a viable alternative. :P

Conner said:

Congratulations and good luck wih this decision, Kayle. I'll be happy to be there for you how I can, but given that I know no C++ at all, I can't exactly offer to help you with any of the actual code unless it's something easy like the typical "where'd I miss the damn semicolon or parenthesis or bracket/brace in this??" sort of issue.


Noted. ;)

Conner said:

As seems rather usual of late, I'm in full agreement with Quixadhal's suggestions.


Quix has some pretty mean ideas when the muse strikes him. ;)

Conner said:

I think I understand well enough the goal of the new license and I think that Samson may be right about the issues with being smaug-like and able to import/translate smaug area files, but I also think it's a good idea to try anyway.


The only way the licenses would affect me would be if I actually used the code from Smaug to load the areas directly from the base. My plan is to get my file saving/loading written, get formats for all that stuff worked out. Then write a program (or find someone in the community willing to write a program) that will read in all formats of areas (ROM, Smaug, Merc, etc...) And spit them out in the Elysium format.

Conner said:

On the other hand, I'd only partially agree with David's comments regarding snippet compatibility. I do think that it's going to be unreasonable to maintain full compatibility with all the Smaug snippets out there, especially given the scale of change you're talking about, in fact, it may be entirely impossible. I, instead, think it'd be a good idea to incorporate as many of the concepts that the snippets out there embody as possible with some sort of admin option to enable/disable them individually. How ever feasible that may be.


Snippet compatibility will be really really low on my list, but I'm going to try and keep as many of the bigger ideas from some of the bigger snippets in mind as I build the base. Currently planned are Copyover/Hotboot, Something akin the the DNS replacement for SmaugFUSS, and of course, I'll be making use of my weather system. Well, some form of it. I might rewrite it.. again. >.> Any other suggestions for major things welcome, I'm having issues with remembering all that right now. :P
       
Post is unread #15 Jun 24, 2009, 7:11 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Oh yeah, one other thing... you mentioned being able to read SmaugFUSS area files. That's actually something you have a choice on.... you could embed support for that OR you could include a converter application that translates Smaug areas to whatever target format you are using. I have a beastie I wrote for my own game that you could poke at if you want (although it's not pretty).

You might want to consider what you DO want for a storage backend as you get started too. Are you happy with flat files and the loading/saving routines? You could also use an object database and just directly load/save things. You could use a relational database as well. They each have their pluses and minuses. Object databases are simple, but they are a mysterious black box that you can only really interact with via the MUD. RDBMS are powerful and let you do all kinds of statistical analysis (great for balancing!), but you have to plan your data structures and handle writing queries. Flat files are... simple and dirty quick.

If you do go with flat files, you might consider making the format something that would be database friendly, just because if you can easily upload your data to a database, you can run the statistical analysis queries on it -- and you don't need it to be real-time live, to be darn useful.

Oh, by database friendly, I mean sticking to simple key/value syntax. None of this multiple-values per key nonsense!
BAD!
Attr 3 18 7 12 10 13

GOOD!
Str 3
Int 18
Wis 7
Dex 12
Con 10
Cha 13


David Haley said:

FWIW, I didn't say that a system shouldn't be modular with the ability to add/remove optional features via plugins or things like that. I was saying that the idea of maintaining snippet compatibility as they're currently thought of (as in, go to this line, replace this with that, etc.) is a bad thing for future development.

In fact, I'll make a slightly stronger statement, and say that a good codebase really should support modularity of various features to whatever extent possible, unless it means going through unacceptable contortions.


Also, in an unusual stance for me, I find myself 100% in agreement with David on this one too. :wink:

I think the whole concept of "snippets" has held back development of quite a few codebases for years. The fact that people expect snippets to apply cleanly as a diff, and that they won't even do things like run the source through indent for fear that it will break "all the snippets", screams bad mojo to me.

Using C++ means you can't rewrite half the game directly from inside (which is fine, we have LPMUD for that!), and so the idea of having things be module and easy to add at compile time is a good one. However, if the code is written cleanly and has well documented API's, any reasonable programmer should be able to see how to change what they want without needing to pray to the diff/patch gods.

One example that comes to mind is a recent discussion of the "nanny" function, which is simply the plate of spaghetti code that handles what to do with input over the sockets, based on player (or descriptor) state. Right now, DikuMUD's have a very messy function that lets program flow meander up and down a huge case statement. It would be far nicer to write this as a dispatch table, so you simply name your states and call the appropriate function. If that is done cleanly, it becomes easy to add things like an account system, or an extra menu input system.

Kayle said:

I hadn't really stopped to think about all the things I'm going to have to write that I'm not very good with. Anything dealing with Strings really. Although, std::string might make things a bit easier...


Strings are a PITA in C, and they're still mildly annoying in C++. Personally, I'd be tempted to write the whole mud in Lua (or perhaps ruby) with an embedded Lua scripting engine. :) However, C++ is probably the right choice for a codebase that will achieve a broader audience and it also makes it simpler to convert chunks of existing code (such as the combat system), from your existing game. I use "you" there to refer to the potential adopter, not just you as the author.

So yes, I would go so far as to say to use std::string everywhere, and only fall back to char *'s in those few places you MUST interact with OS routines. In fact, if you can find good public domain socket classes, use them!

I've looked at a couple small C++ codebases (SocketMUD++, Nick Gammon's tinymudserver), and while they all do the job, they also have a lot of C in them. I'm going to guess that means it's not easy to find public domain socket classes, otherwise I can't imagine why anyone would willingly leave ugly select loops at the heart of their main program loop.

Lastly (for now), don't be overwhelmed by the flood of ideas and things to think about. Writing a codebase from scratch is a big undertaking, and you shouldn't write ANY code until you've sat down and at least sketched a bit of a roadmap for yourself. That said, start with the basics. Get a server process running that catches signals and starts up/shuts down cleanly from SIGTERM. Then add config files and command line options, keeping it simple. GNU's getopt() works well for things like "--port 3000". Then add sockets and see if it all still feels modular and clean. If it does, you can head for the command dispatcher and parser, if not... refactor and ponder a bit more.

Because people will ask... you should consider what development environment(s) you plan to support now, at the start. Classic hand-rolled Makefile? Autoconf/configure script generated? MS Visual Studio project files? That last one is probably a pain, but there are Windows folks out there who will ask for it. It's fine to tell them to bugger off (or ask them to provide one), but don't be surprised by it.

Anyways, it should be fun! :)

Sorry for the book-length posts... we're gonna need our own index if this keeps up!
       
Post is unread #16 Jun 24, 2009, 10:24 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Kayle said:

So, Samson, You're gonna come out of hiding and help me work on writing a base from scratch yes? :P


Not if it's just going to me me, or just the two of us, no.

Seriously, if this is going to get legs I'll offer what assistance I can. Hosting space, SVN repository, whatever. Just don't expect me to be terribly enthusiastic about getting hands dirty on large chunks of code. It became clear a long while back that this sort of thing just wasn't for me. All the structured design, formal development, laying out plans, all that's just boring as hell to me. I don't work well under those conditions. I tend to be much better off just jumping in head first and flinging something out at random, then fixing it later if it's broken. What I'm not going to do though is try and make this a one man band. There needs to be a solid team that's interested in the project that is willing to contribute real stuff to it.

Snippets? In a custom codebase? Nonesense. I agree with David. Ditch them. Ignore them. Whatever. Incorporate the ones that are useful, drop the ones that aren't.
       
Post is unread #17 Jun 25, 2009, 9:03 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

quixadhal said:

I've looked at a couple small C++ codebases (SocketMUD++, Nick Gammon's tinymudserver), and while they all do the job, they also have a lot of C in them. I'm going to guess that means it's not easy to find public domain socket classes, otherwise I can't imagine why anyone would willingly leave ugly select loops at the heart of their main program loop.

It's an interesting question. I wrote socket classes that work nicely for me, maybe I'll publish them some day, although they were written 7 years ago and I don't think of them as terribly good code anymore. :wink: It's still a select loop under the hood, of course.

--

The hardest part in writing a codebase is figuring out how the big picture is going to fit together. Actually, to be honest, I think that this is the vast majority of the work. Once you know what the pieces are going to be and how they'll interact, actually writing the code is (usually) pretty straightforward.
       
Post is unread #18 Jun 25, 2009, 9:04 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Here's a quick one to think about....

What do you want to call your fledgling new codebase? Will it be named after the MUD itself, Elysium? Once you've got that settled, it might be time to create a new forum entitiy, since this single thread will get pretty messy if you get enough interest to start rolling. :)
       
Post is unread #19 Jun 25, 2009, 9:20 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

David Haley said:

quixadhal said:

I've looked at a couple small C++ codebases (SocketMUD++, Nick Gammon's tinymudserver), and while they all do the job, they also have a lot of C in them. I'm going to guess that means it's not easy to find public domain socket classes, otherwise I can't imagine why anyone would willingly leave ugly select loops at the heart of their main program loop.

It's an interesting question. I wrote socket classes that work nicely for me, maybe I'll publish them some day, although they were written 7 years ago and I don't think of them as terribly good code anymore. :wink: It's still a select loop under the hood, of course.


Of course, although you could use poll(2), if you wanted to be diffrent. *grin*

The main thing is that you want a container that holds all the connected socket objects, so they can be processed neatly. I would probably have them handle reading/writing themselves, and let the player object just access the I/O queues, rather than the raw sockets. That way, if you're using TELNET, the socket objects can deal with packet fragmentation and the whole state machine bit, and if you're in line-mode, they can even split things into lines for you. The player object then only sees an array of lines, which makes things like editors/pagers simpler as well.

Functions like act(), send_to_char(), etc, become methods in the player/npc object (yes, npc's may want to see messages so their lua scripts can trigger on them!), and those methods could automatically split things on lines to shove into an output queue (which the socket object would pluck out, or the lua objects could examine).

I just had to rewrite my own mud's 10 year old pager because it wasn't compatible with the imc2 code I added, and I found it easiest to have that lowest level output routine split things into lines and shove them onto an output queue (linked list, in this case). That way, my pager always got the line count right, no matter how the output got generated. :)
       
Post is unread #20 Jun 25, 2009, 9:27 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006


Quixadhal said:

Here's a quick one to think about....

What do you want to call your fledgling new codebase? Will it be named after the MUD itself, Elysium? Once you've got that settled, it might be time to create a new forum entitiy, since this single thread will get pretty messy if you get enough interest to start rolling. :)


Codebase is called Elysium, the mud is called Malevolent Whispers. :P
       
Pages:<< prev 1, 2, 3, 4 next >>