09 Apr, 2012, Kline wrote in the 1st comment:
Votes: 0
So, both just to learn something and in hopes of (eventually) having a useful end product I've embarked on the journey of writing my own server from the ground up and am trying to "get it right the first time" rather than hack and bandaid away at the Dikurivative games I normally like to tinker with.

I was trying to hold off on putting the code anyplace public until I had "at least a working talker", but I was excited at the progress I've made and all the extensive time spent of using only the great Google to figure things out as I go along. SLOCCount pings this at just under 1,500 lines so far. A lot of it is probably all the if ( !function() ) Error() checking, but if nothing else I've been able to get some very detailed backtrace-like error logs when I break things so far :)

I just finished typing up all of the "high level" view of things as I pushed it to GitHub. When I get further along I'm thinking about learning Doxygen or something else to make some nice docs to include, but in the meantime I hope the current docs are useful enough to anyone interested in poking around. I think with the fairly liberal amount of comments (for both the benefit of myself and others…) everything is pretty clear and easy to understand. Everything utilizes STL only container types to the extent I was able to, barring some low level system calls that require a char and stuff.

If anyone has feedback good / bad / ugly I'd like to hear it. It's easier to fix things sooner than have to deal with ripping apart a Diku from top-to-bottom to redo const char pointers all over the place. With all that said, the GitHub is here: https://github.com/Kline-/NAMS

What's working so far:
    * Boot
    * Bind / Listen to socket
    * Accept new sockets
    * Threaded hostname resolution
    * Send / Recv from sockets
    * Parse command files from disk to memory (no command logic yet)
    * Console logging (soon to setup logging to files)
    * Core loop (poll, kick exceptions, process input, process output)
    * 100% clean Valgrind – don't think I've ever pulled this off before :D


It's being licensed under GPLv3 rather than a roll-my-own. I didn't want to quite toss it out "public domain" MIT-license style, but still wanted something established and fairly open. I've only tested / developed this on Debian x86_64 6.0.4 (kernel 3.1.0-1-amd64). Hope it works on other *nixes, and maybe if I get it "fully working" as a barebones SocketMUD-like server I'll attempt to cross-compile with MinGW and port to let it run under Windows, too.

So, yeah, thanks for looking :) Any new updates will be pushed to my Git repo if anyone ends up following along with this.
09 Apr, 2012, Rarva.Riendf wrote in the 2nd comment:
Votes: 0
Quote
It's being licensed under GPLv3'

So basically all the users will be able to access the code of the game. Not sure that it is a great idea.
09 Apr, 2012, KaVir wrote in the 3rd comment:
Votes: 0
There was a recent thread on TMC concerning the GPL which may be of interest - although the GPL doesn't seem to be quite as bad as the AGPL.
09 Apr, 2012, Kline wrote in the 4th comment:
Votes: 0
Rarva.Riendf said:
So basically all the users will be able to access the code of the game. Not sure that it is a great idea.

This seems to be debatable under the auspices of "the content is not the code" (see the link KaVir provided, specifically). While IANAL, it was also my understanding that the AGPL was for "closing the ASP loophole" (SaaS). While a "MUD server" is not 100% the same as a "web server" it was my understanding that it is still "software as a service". See this excerpt from:

GNU Page on SaaS said:
Distinguishing SaaS from Other Network Services …
Multiplayer games are a group activity carried out on someone else's server, which makes them SaaS.
Here's also a smaller post over at the Ubuntu forums of similar opinion.

KaVir said:
There was a recent thread on TMC concerning the GPL which may be of interest - although the GPL doesn't seem to be quite as bad as the AGPL.

Thanks, there were some interesting points argued there. Personally I am looking at things in the manner Istarian is:

Istarian said:
Well, I could and might contend that stock functionality is not a bad thing. If it meant that everyone had cool stuff instead of codebases stagnating until someone saw fit to update the original, that wouldn't be so bad, would it?

Having to patch together a ramshackle collection of snippets to make a mud that is up to some standard that people expect might be informative and useful for learning, but it's probably a royal pain in the ass for someone who just wants to create a game world and run with it.

Also, your database isn't part of the code, and since the database is a huge part of what makes one mud different from another, I have a hard time seeing how this really constitutes a problem.

I feel many people who get into MUDs as a hobby spend a lot of time cobbling together "standard" features and dealing with the same long-standing problems. There are so many post here alone at MB saying "Hey, I started a new game! Come help! I need somebody to add in color support and the cool OLC snippet!".

I think SocketMUD was a great step in this direction, but when I last looked at it myself I still had reservations about how certain things were designed and it felt like the same song and dance of trying to strip out a lot of work just to rebuild things from the ground up to work "properly" (to me). Every time I've looked into different servers I've always felt compelled to "remove this" or "add that" just to get to a suitable spot for "designing the game world". I'm hoping to keep this project as decoupled from game logic as feasibly possible, or for any parts of game logic that are eventually written, to be offered as either script modules or compile-time config files. Game operators shouldn't have to spend much time and effort ripping apart the internals just to achieve their own vision of a good server core.

If this project ever gains any real traction past just me teaching myself things and it actually becomes an issue I'm totally open to re-licensing/dual licensing under something that allows modifications to be kept entirely private to support people who would like to run actual games with it but have reservations otherwise. For now though, beyond learning something, my primary philosophical goal was to help others learn as I did. I've never had a single day of formal software development instruction or paid work in my life. I don't think I've even read any books on the subject or followed any teach-yourself guides either; it's all been trial, error, and experimenting. With lots of Google and man pages to fill in the gaps I couldn't figure out. To that end, I'll be trying to add copious amounts of documentation as I go further along. It's a lot easier to learn and understand a system with well written docs detailing what, where, and why, rather than blindly flailing through it looking for one small piece you want to edit or learn about (hi Diku games, looking at you here!).
09 Apr, 2012, Runter wrote in the 5th comment:
Votes: 0
What's the argument against something more liberal like the MIT? I've always felt that GPL and their kin aren't actually open source licenses.
09 Apr, 2012, Kline wrote in the 6th comment:
Votes: 0
Runter said:
What's the argument against something more liberal like the MIT? I've always felt that GPL and their kin aren't actually open source licenses.

I don't have any true arguments against them. Honestly the first licenses I looked at were MIT and ISC, both probably the most open licenses I've seen aside from the WTFPL.

This early on though I really wanted to get things out of my local Git repo on my system and publicly visible to try and elicit some feedback, and so I can browse code or work on documentation if I get some downtime at work. Before placing it on the wide open WWW though I did believe I needed to attach some form of license to it and opted to go with the "more restricted" (depending on your point of view) and widely used GPL. Also, this being a new learning endeavor for me, selecting a proper license is as much of a learning process as anything else has been and I will say that the proliferation of GPL in most software I've learned from / played with / etc was probably a deciding factor to "stick with what's familiar".

As I've stated before I'm not at all against re-licensing/dual licensing or something else, and from my point of view if looking at a "game server" as "software as a service" I didn't see any harm in the GPL requirements to provide modified source on request when distributing a binary since a modified binary should not end up being distributed; but I'm not trying to start an armchair lawyer semantics debate about what constitutes "distribution", as I think we see enough of those on most MUD forums :).
10 Apr, 2012, quixadhal wrote in the 7th comment:
Votes: 0
While it sounds like you've already gone down the tried-and-true path of multiplexing, I'd offer the suggestion that if you're writing a new server from the ground up, you might consider threading for all socket connections.

Most folks on here will say it's not worth it, because MUDs don't have enough overhead, and having to do semaphore locking on all the I/O is annoying, there is a distinct advantage that you *MIGHT* want to take advantage of down the road. Namely, if you have a seperate thread for every connection (and thus every user), you can allocate a PTY for them and give them an instance of the curses library, thus allowing excellent full-screen terminal support, just like you get from logging into a shell.

NOT using threading means you can't use curses (it has global state info), and makes handling PTY's more annoying as well. You may not think you have any use for such a feature, but down the road you (or someone using your code) might think an in-game menu-driven editor would be a nice feature, or a UI with a real-time updated map and single-key commands would be fun.

Just my two cents, which aren't worth as much these days. :)
11 Apr, 2012, Kline wrote in the 8th comment:
Votes: 0
quixadhal said:
While it sounds like you've already gone down the tried-and-true path of multiplexing, I'd offer the suggestion that if you're writing a new server from the ground up, you might consider threading for all socket connections.


This is actually something I've strongly considered but was uncertain how to best implement. I've never dealt with threads beyond simple fire-and-forget stuff like the hostname resolution. I did a bit of reading last night while at work, but I still don't have a good feel of "what" to thread. Some games (and as you suggest) do it per-socket. Is this the best route? Part of the entire reason I placed all "Server" functions into a class of their own was to allow main() to spawn individual "game worlds" on unique ports, etc, via threads. Maybe even automatically spawned in response to connection count or something.

Also, while I did read some about mutex locks and condition variables, what would be a safe manner to handle interactions between two threads, like PvP? Threads fire "at the behest of the CPU scheduler" so what do I need to plan for to ensure that a fight does not turn into "Player A got 10 attacks, then Player B got 1"? I'm truly interested in doing threads, as I don't view them as a lot of overhead for the potential flexibility they can be offered, but this is definitely one of the low-level things I need to get right "now" and not have huge headaches later with locks or abnormal behavior.
11 Apr, 2012, quixadhal wrote in the 9th comment:
Votes: 0
MUD servers are typically too tightly coupled to really gain much from threading, beyond I/O. The idea of mutex locking is that whenever you intend to access ANY data which another thread might be accessing, you have to use a lock to ensure only ONE thread can actually access that data at a time. This is to prevent the case where Thread A reads a value, Thread B changes that value, and then Thread A uses the stale value, causing corruption.

However, if you're only using threads for I/O, such as each socket connection, you only need to lock when you are reading or writing to the buffers. Essentially, the game server does:

get lock, add stuff to output buffer, release lock
and
get lock, move user input for processing, release lock

each socket thread would likewise

get lock, push output buffer to socket and clear, release lock
and
get lock, pull socket data and add to input bufffer, release lock

Fairly simple, and since NORMALLY you only have the server and one socket competing for a lock, the wait times would be very minimal.

Trying to thread other components is MUCH more difficult. Consider the idea of threading each NPC, which sounds like a great concept. Every time the NPC moves, it would have to lock the room data for the room it is in and the room it is moving to. Every time it swings a weapon, it would need to lock all the data associated with everything involved in the combat. Very messy stuff.
11 Apr, 2012, Chris Bailey wrote in the 10th comment:
Votes: 0
Are you completely against using an external lib for this? Eventmachine ftw.
11 Apr, 2012, Kline wrote in the 11th comment:
Votes: 0
quixadhal said:
Trying to thread other components is MUCH more difficult. Consider the idea of threading each NPC, which sounds like a great concept. Every time the NPC moves, it would have to lock the room data for the room it is in and the room it is moving to. Every time it swings a weapon, it would need to lock all the data associated with everything involved in the combat. Very messy stuff.


That's the type of stuff I didn't want to end up involved with. So only direct I/O functions should be threaded out then? Also, given that, I don't quite understand your previous comment then (which may just be that I've never written software for the Curses library):
quixadhal said:
Namely, if you have a seperate thread for every connection (and thus every user), you can allocate a PTY for them and give them an instance of the curses library, thus allowing excellent full-screen terminal support, just like you get from logging into a shell.

NOT using threading means you can't use curses (it has global state info), and makes handling PTY's more annoying as well.

From my understanding threads share address space? I thought threadding was just to farm out any "heavy lifting" that would cause a block in your otherwise multiplexed environment; like a query that has to search every single NPC in a large world, or a socket still waiting to send data. Disk I/O waiting to write, etc. So if they share an address space then how does Curses fit into this? Unless you are saying Curses just needs its own local stack, which would be kept per-thread, until the socket disconnects?
11 Apr, 2012, Kline wrote in the 12th comment:
Votes: 0
Chris Bailey said:
Are you completely against using an external lib for this? Eventmachine ftw.

At the moment? Yes. I've already learned a lot more by forcing myself to read man pages on system level functions and how to properly deal with them rather than plug in a library. Even things that "should be simple", like a recursive directory listing, returned almost nothing on Google but "use Boost!". I want to first learn the how and why of making things work. Libraries are just hiding the details and force bending your software to suit the paradigms of a 3rd party API which "may change" between revisions and can't be guaranteed to exist on any system. The STL and system libs are pretty "static" in my opinion opposed to all the small independent libraries that are scattered everyplace with various levels of support, use, and maintenance.
11 Apr, 2012, Scandum wrote in the 13th comment:
Votes: 0
Anything that doesn't include a physics engine with a dynamic description generator as a front end is a pointless exercise in repetition.
11 Apr, 2012, Kline wrote in the 14th comment:
Votes: 0
Scandum said:
Anything that doesn't include a physics engine with a dynamic description generator as a front end is a pointless exercise in repetition.

I guess this includes your parents procreation efforts that resulted in you, too, then.
11 Apr, 2012, Chris Bailey wrote in the 15th comment:
Votes: 0
Kline said:
Chris Bailey said:
Are you completely against using an external lib for this? Eventmachine ftw.

At the moment? Yes. I've already learned a lot more by forcing myself to read man pages on system level functions and how to properly deal with them rather than plug in a library. Even things that "should be simple", like a recursive directory listing, returned almost nothing on Google but "use Boost!". I want to first learn the how and why of making things work. Libraries are just hiding the details and force bending your software to suit the paradigms of a 3rd party API which "may change" between revisions and can't be guaranteed to exist on any system. The STL and system libs are pretty "static" in my opinion opposed to all the small independent libraries that are scattered everyplace with various levels of support, use, and maintenance.


I've started (and given up on) about 40 from scratch codebases. Lately I've been leaning more toward Plazmi's approach of just focusing on the end-user experience and less on how I feel things should be designed. I cannot begin to explain how much more quickly development is moving. What I am getting at is that by using eventmachine (and other libs) I have been able to focus on what really matters in game development…the game. I can't dispute the need to understand what is going on behind the scenes. That is an excellent motive for making anything from scratch. I did the same thing myself, several times. Lately for me it has been nice to push some of that stuff off on the people who want to focus on that though; libraries exist for a reason.
11 Apr, 2012, Kline wrote in the 16th comment:
Votes: 0
Chris Bailey said:
What I am getting at is that by using eventmachine (and other libs) I have been able to focus on what really matters in game development…the game.

Right now my goal is explicitly to not have a game. The never-ending argument between Diku and LP games is "game baked into the code" and "game layered on top of a core driver". I'm trying to approach this almost as if writing a LP driver, I guess? I'm not interested in game mechanics; not yet anyway. I'm interested in building a solid framework for which myself and others can then quickly build a game on top of.

I've always like the idea behind LP MUDs, but not the implementation; having to learn a "MUD only" language with no other applicability. I know there are current games already entirely in Ruby, or Python and stuff, but I'm trying to get more separation than just writing the core + game design all in a modern / script language with similar inherent risks of "exploding the driver" with something like a faulty NPC module. Once I have a solid C++ core handling the heavy lifting and commonalities (sockets, command queuing, a help interface, etc) then I plan to focus on a module / plugin system to allow creating a game at that point.
11 Apr, 2012, Chris Bailey wrote in the 17th comment:
Votes: 0
Did you miss the important part of the post you quoted? I'll quote it.

ChrisBailey said:
I can't dispute the need to understand what is going on behind the scenes. That is an excellent motive for making anything from scratch.


Keep on keeping on bro. I want to make something that others can build on also. That is why I am here at mudbytes and not posting over at mudconnect.com. =)
11 Apr, 2012, KaVir wrote in the 18th comment:
Votes: 0
Chris Bailey said:
Keep on keeping on bro. I want to make something that others can build on also. That is why I am here at mudbytes and not posting over at mudconnect.com. =)

If you posted on TMC then you could get advice from Johah on the latest cutting-edge features that every modern mud needs…like…ASCII maps.
11 Apr, 2012, Scandum wrote in the 19th comment:
Votes: 0
Kline said:
Scandum said:
Anything that doesn't include a physics engine with a dynamic description generator as a front end is a pointless exercise in repetition.

I guess this includes your parents procreation efforts that resulted in you, too, then.

Evolution has a proven track record, nor did they pretentiously label the project 'NAHB - Not Another Human Being', though it's not uncommon for parents to feel their children are extraordinarily special.

It appears that at this stage the MUD community doesn't have the talent or motivation left to take things to the next level, there was a time people tried to build another LPMud, I guess we got to the point where people are proud to build yet another SocketMUD, or feel the need to display that their world is simple enough to be displayed by an ascii map.
11 Apr, 2012, KaVir wrote in the 20th comment:
Votes: 0
Scandum said:
It appears that at this stage the MUD community doesn't have the talent or motivation left to take things to the next level

Perhaps the mud community just doesn't share your view of "the next level".

In terms of interface I think there's been significant progress. How many muds a year ago supported out-of-band protocols, extended colour, etc, compared with today?

Even if someone were to release (yet another) public codebase, few existing muds would care - they've already invested too much time and effort to switch now. A few new muds might give it a whirl, but new muds rarely last long, or attract many players.

On the other hand, many of the muds that have improved their protocol support over the last year are fairly old with established playerbases. These are the muds that have already survived the test of time, and their decisions will have a far greater impact on the future and direction of the mud community.
0.0/65