Releasing A New Codebase

 
Post new topic   Reply to topic    mudlab.org Forum Index -> Coding
View previous topic :: View next topic  

Should The Server Be Publicly Released?
Not Worth My Time
 0%  [ 0 ]
Worth The Time
 71%  [ 5 ]
Hate The License
 14%  [ 1 ]
Hate The Language
 14%  [ 1 ]
Too Complex
 0%  [ 0 ]
Total Votes : 7

Author Message
Shadus



Joined: 01 Sep 2007
Posts: 8

PostPosted: Sat Sep 01, 2007 7:21 am    Post subject: Releasing A New Codebase Reply with quote

I've been writing a mud and have been far far far removed from the loop of typical muds. In fact, I have little to no actual interest in actually playing and can't barely remember playing one myself. I started a small project like 6 years ago that has tested and frayed my nerves ever since.
I've layed it down, only to pick it back up again, only to drop the foolish notion, only to have it revived again. I have no friends that play muds, all my friends are personal actually (perhaps a side effect of being in the Navy).
I wanted to see what interest my project could generate, if any.

My first codebase release is imminent, in fact, this weekend. I'll be putting the codebase into sourceforge and updating it and taking bugs and patches etc. I've seen many people want to roll their own muds, and was wondering how many get to actual release, and if they do release it, is it to the public as well.
Well, I'm releasing mine to the public. It's a mud-from-scratch and written with developers, modularity, and the latest tech in mind. It's requirement heavy, if you consider Qt 4.3 and MySQL 5.1 heavy requirements. I'll give a list of features and see if anyone wants to see it released. Plus I haven't been able to test it on other platforms because I'm too lazy to virtualize it all out. It'll be interesting to see if this is even an issue of any sort.


    Language - C++
    Backend - MySQL 5.1
    License - GPL2
    Requirements - Qt 4.3, MySQL 5.1+


Sedios Library -
A basic (and slightly dated) function call library, a place for miscellanious things that are self supporting and don't require calls from other libraries.

    Color Handler
    Log Engine (colored, and database logging possible)
    Channel Abstract
    I/O Signal/Slot Abstract


Phoenix Library - Library designed exclusively for copyover and state restoring. Includes an abstract that maintains its own signal to the library and requires almost no support code beyond the inclusion of the abstract, what you want initialized/deinitialized, and how it handles the information when it gets it back. It works off a signal/slot setup and so the information doesn't need to be tracked. You can also leech information from other abstracts. It doesn't, however, create structures for you. Think of it more as something that dumps or retrieves the proper information on signal.

    Template Abstract
    Uses Signals/Slots for tracking
    Little support code needed
    Intelligent as to which information goes to what.
    Virtually any class can use it.


Encephalon Library - The databasing library that doesn't know anything. It's an abstract, and uses references and generates what it needs during runtime for storing, extracting, or deleting from the database. It has two main components, the actual database which handles the connection to MySQL, and the abstract for handling.

    Easy to use abstract.
    Memory efficient.
    Doesn't require support code beyond what variables you want databased.
    Can create its own database tables on the fly.
    Designed with performance in mind.


Nexus Library - One of my favorites recently because I changed how it used threads. It has an event loop which is tickless. It only queues events it receives from other threads (reads/writes). Meaning connections are spontaneously handled and not even polled for. It doesn't require any other library except Sedios and Phoenix (for a hot restore). The code is simple and minimalist.

    Nexus delegates ports out to servers
    Servers are created in a seperate worker thread
    Multiple ports can be opened
    Which descriptor is attached to which server is tracked by Nexus
    Very minimal code, easy to understand and modular.
    Tickless


Reactor Library - Reactor is do it all, state-engine, command interpreter. I noticed something about MUD command interpreters. They suck, they're slow, and they're monolithic. A quick explanation - StateEngines can belong to any abstract state, the state decides which commands the state-engine has access to (gee...). There is no tick, instead, commands have two types of wait timers. Active, and Passive, and have multiple states, for entry, execute, interrupt, cancel, and exit. When a command has an active timer, simply put, it blocks. When it has a passive timer, the passive timer counts down, calls exit, and then quits. Now there are also collisions and interrupts. While a command is queued for processing it can be interrupted and reprocessed by any opposing command. Why oh why has nobody ever thought of using this setup to say 'swing sword' and 'raise shield' and get a result, is beyond me. But say the command doesn't exist (if we want to handle arbitrary text), the state, and this is genius, each state has its personal command interpreter, if the command doesn't exist it goes straight to the interpreter. Mind you, to a command, a 1 is a 10th of a second. The tickless comes from the fact that it only does something when there is something to do. No poll.

    Not network dependant
    Abstract StateEngines for tracking states
    Abstract States for handling commands
    Abstract command structure for processing
    Tickless
    StateEngines get their own personal timer
    FAST and ACCURATE command interpreter (timing).


SoulCraft Library - This is a large and somewhat daunting module. It's everything for OLC. It interacts with the database and contains a lot of code. It contains editors for just about anything you can imagine. Aliases (no, they're not commands, they're alises damnt), worlds, zones, cubes, alias groups, help files, and a few other things I'm forgetting. It contains an abstract for MenuEditing and TextEditing things. The MenuEditing system is flexible enough to handle just about any sort of menu you want, even, including.. hmm.. SHOPS, or.. my login menu. I do need to expand it a bit though for allowing arbitrary sized lists that can be added or taken from, this should be short I just haven't had need or time for it.

    Can be used for almost any menu based need
    Integrates fluidly with the command interpreter and the database system
    Track all the world objects and ties them together
    Includes Worlds, Zones, Cubes, and SubCubes
    Cartesian coordinate based
    Includes a spellchecker.
    Includes a plugin-loader.


And the Core:
The core is where you store all the high level stuff. Accounts, characters, states, like login and in game, channels, commands and other things that flesh out and utilize the libraries to their potential. Oh, and some copyover code since phoenix deals not in the creation and destruction of objects, but the storing of their information and retreival when necessary. A surpisingly small amount of code goes into this portion.

I have a few plans, besides bug squishing (always consider this a plan). Next I'm adding scripts (JavaScript), and some basic physics stuff (probably a lot of line of sight things).

The thing I fear though, is maybe I'm so detached from the mud community that my well meaning goals are misplaced and little to no want or need for any of this is out there (maybe everyone wants to roll there own). Or maybe the code is too different and/or complex for people to easily add on to it. I want it to be publicly available because I wrote with coders and builders in mind. I didn't make it so flexible just so I could use it. I'll be posting the link probably this weekend.

PS: I'll be posting a socket mud version as well. I run one of these from my own codebase for testing purposes and it's no big task (like 5-10 minutes to strip the uneeded libraries out). Oh, and almost all of this is something someone else could replace with their own code for whatever reason. It's way modular, and way flexible, and this has paid off well for me so far.
Back to top
View user's profile Send private message AIM Address MSN Messenger
Author Message
Kelson



Joined: 18 May 2005
Posts: 71
Location: SC

PostPosted: Sat Sep 01, 2007 1:03 pm    Post subject: Reply with quote

I doubt anyone'll ever complain about another open source mud being released; I'd certainly be interested to see what the insides look like and see if you've pushed in any particularly elegant patterns / concepts. I'd probably primarily check over the OLC sections since I've not liked the majority I've run into and doubt the user friendly nature of my self-rolled OLC.

(I've had the same problem playing muds since I commissioned in the Air Force)
Back to top
View user's profile Send private message Send e-mail AIM Address
Author Message
ide



Joined: 21 Feb 2006
Posts: 105
Location: Seattle

PostPosted: Sat Sep 01, 2007 1:40 pm    Post subject: Reply with quote

I think you should expect interest to be somewhat limited, at least at first, because your mud is going to appeal mostly to people who can program in C++ (and a few people who aspire to do so), rather than some random dude who wants to open a fantasy mud this weekend. That said, I think your server will be a nice new addition to what's out there, so I'm all for the release.

Since you seem to be writing more of a base than a game I don't think that you not playing muds will be a problem. On the other hand, I wonder if you've overlooked things in your basic architecture because you haven't been thinking as a player or someone running a game. Just an observation.
Back to top
View user's profile Send private message Send e-mail
Author Message
Shadus



Joined: 01 Sep 2007
Posts: 8

PostPosted: Sat Sep 01, 2007 4:09 pm    Post subject: C and C++ Reply with quote

Yeah, I realize that there's a difference in C and C++. The thing is, it's written in really heavy handed C++ too. I show no shame when I go about coding, I use the tools at hand. I know exactly where people are going to have problems too, and that's how everything talks together. The signal/slots are a bueatiful thing I would not do without, but coders tend to have a hard time understanding how things flow beyond 2-3 points. Plus, the connection of signals and slots sometimes take place nowhere near where the signal/or slot are defined. I just grep for connect( and look for the appropriate calls or whatever, but I understand how it all goes together.

The biggest thing I think people will have trouble with, is how descriptors talk to their corresponding objects. The abstract I made is really good for not making you think too much about this, but still some people will wonder how an IOSocket becomes a descriptor and how an IOObject connects to it. Having that said, I couldn't code it to be any more simpler with the same functionality. The snoop attach/detach command is like, 15 lines long and contains no support code, so is force.

Once people understand how things talk to eachother, the rest is easy. I don't obfuscate any variable names, in fact, I have my own standard which makes things pretty easy to understand.
Back to top
View user's profile Send private message AIM Address MSN Messenger
Author Message
Kelson



Joined: 18 May 2005
Posts: 71
Location: SC

PostPosted: Sat Sep 01, 2007 11:16 pm    Post subject: Reply with quote

There are a lot of other issues that can make tackling a code base a challenge though; not just issues with poorly named variables. Large amounts of code to handle relatively simple tasks, complex interconnection, lack of information hiding, extensive multiple inheritance, unfamiliar control flows, etc.

One example in Adequise MUD is the use of IO Completion Ports; essentially an asynchronous Windows API for accepting, sending, and receiving from users. While I avoided multi-threading the game outside the player input phase, I doubt most people know the relevant libraries or are familiar/comfortable with multi-threaded handlers feeding into a single-threaded event-driven game loop.

Another example is the MetaModule which uses inheritance off IDModule, FlatModule, PropModule, ChildModule, and EventModule. All objects in the game inherit from this (relatively complex) base class. It provides unique object ids, serialization, property interface, object inheritance, and basic event interaction rules.

Especially with complex subjects though, as you mentioned a couple yourself, documentation can be a huge plus. What're these signals/slots all about? Do you have a link to where you've posted the code?
Back to top
View user's profile Send private message Send e-mail AIM Address
Author Message
Shadus



Joined: 01 Sep 2007
Posts: 8

PostPosted: Sun Sep 02, 2007 10:10 am    Post subject: Codebase Complexity Reply with quote

Understanding exactly how some code works isn't necessarily as important as understanding that it DOES work. A well abstracted set of calls and procedures can abstract certain complexities away with little to no hit. If you program for this from the beginning, at least as I have as much as possible, even though this may be delusional, its not always difficult to do. Other times it's nigh impossible and you end up spending time on an odd project where you're left asking 'why did I do this anyways?'

Having that said, the library is based off of Qt. You can find full documentation on all their work at http://doc.trolltech.com/. As for my things? I've actually stripped out all my loose ended comments, or most of them except for a few really important notes, simply so I CAN add in proper Doxygen based documentation. So no, the code isn't documented at all.. yet. But other mud codebases only benefit from the fact that everyone got so fed up from not understanding them that they wrote their own tutorials and FAQs. Quite a harsh world.

What's my obligation to write documentation? None. In fact it's a goal, not a requirement. Besides, if C was a bit more difficult to understand maybe it would scare away all of those that aren't interested in actual coding, just running Wink. Having that said, allow me to post the code tomorrow, I wanted a day off from things since I just got back from deployment in WestPac. Then maybe some people will pick it apart and see things that I missed.. or maybe I'll get no support whatsoever.. but that's what I'm doing right now.. dipping my toes into the mud community water and testing the temperature
Back to top
View user's profile Send private message AIM Address MSN Messenger
Author Message
Shadus



Joined: 01 Sep 2007
Posts: 8

PostPosted: Sun Sep 09, 2007 9:35 am    Post subject: My excuse. Reply with quote

I've been working 13 hour days in case any of you are wondering why I haven't released yet, so I created a configure script for MySQL configuration (from scratch, new MySQL and all) and something to ease the installation. Having that said, I want to add a few quick features which won't come until my day off on.. monday? At any rate, if anyone as of yet cares, I installed a virtualized version of Ubuntu and got the mud running, unfortunately it requires Gutsy because it requires Qt 4.3 and Feisty doesn't have Qt 4.3. SO, having that said, I now know it runs on systems other than gentoo. In case you're wondering what I want to do before I release, I'll show you my TODO list, it's actually pretty easy.

Set SIGHUP to be ignored instead of copyover.

Let Nexus accept a thread to thread signal for server creation/destruction (multiple ports are listened to via nexus, this is just saying open and close multiple ports).

Create passwords for ports (easier than it sounds).

Annnd.. RELEASE!
Back to top
View user's profile Send private message AIM Address MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Coding All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign