22 Sep, 2008, Weeks wrote in the 1st comment:
Votes: 0
So I'm currently having a great time building a C# MUD from the server and driver up, currently able to connect, execute commands, create a character (MS SQL db enabled) and such. What are some features you'd want in a Windows-based .Net MUD codebase? I dunno if I'll ever release it, but for my own curiosity's sake, what kind of shiny cool features would it take for you to want to download and play with it?
22 Sep, 2008, Midboss wrote in the 2nd comment:
Votes: 0
Encrypted pies.

Or, if that's not your thing… For me, I'd seek a clean design. As far as any game mechanics you'd install, I'd like things to be organized in such a fashion that it's nice and painless to remove whatever I don't like and add my own features – digging certain things out of ROM, for instance, is a very large headache that isn't worth the time.

Beyond that, all the usual amenities, OLC, some form of scripting accessible from within the game, a shiny banhammer… You know, the must-haves.
22 Sep, 2008, Fizban wrote in the 3rd comment:
Votes: 0
I hate you. Not just you though, anyone that posts anything that small.
22 Sep, 2008, The_Fury wrote in the 4th comment:
Votes: 0
Fizban said:
I hate you. Not just you though, anyone that posts anything that small.


Thank Firefox for Ctrl++
22 Sep, 2008, Fizban wrote in the 5th comment:
Votes: 0
The_Fury said:
Fizban said:
I hate you. Not just you though, anyone that posts anything that small.


Thank Firefox for Ctrl++


You mean Chrome :P
22 Sep, 2008, Conner wrote in the 6th comment:
Votes: 0
There are still browsers that don't support some sort of page zoom?
23 Sep, 2008, kiasyn wrote in the 7th comment:
Votes: 0
Weeks said:
So I'm currently having a great time building a C# MUD from the server and driver up, currently able to connect, execute commands, create a character (MS SQL db enabled) and such. What are some features you'd want in a Windows-based .Net MUD codebase? I dunno if I'll ever release it, but for my own curiosity's sake, what kind of shiny cool features would it take for you to want to download and play with it?


abundant c# events :D
23 Sep, 2008, Weeks wrote in the 8th comment:
Votes: 0
lol, wish granted, kia. :)
24 Sep, 2008, Vassi wrote in the 9th comment:
Votes: 0
Weeks said:
lol, wish granted, kia. :)


Actually,

You have to be careful with events because events and event handling is essentially introducing multi-threaded elements into your code. I know this because my first iteration on the C# server used events for some of the timing code and I ran into some trouble once I had more than 10 testers in doing things. Handling 'events' is best done via a priority queue the old fashioned way.

On the other hand, delegates, interfaces, generics and reflection are incredibly powerful language features that can do tons and tons for MUD-type code. They're not exactly unique to C#, but they're very easy to use in that packaging.

Edit- That isn't to say you shouldn't use them, but I wouldn't use them for game-important code. I'd use them for like triggering database saves, or something that can safely be spun off in parallel.

V
24 Sep, 2008, David Haley wrote in the 10th comment:
Votes: 0
How is introducing an event-based model multi-threading? Unless C# events mean something different, you would still process events sequentially without several things happening at once. You do need to be careful about handlers not triggering events in a circle, of course, but that's not really multi-threading.
24 Sep, 2008, Vassi wrote in the 11th comment:
Votes: 0
Events are caught and processed in a separate thread than they're raised if you're not careful about how you handle them\don't marshal them back to their home thread. This is mostly true if you're catching timer events, which I have found are the most common types of events that 'first' builds of MUDs on C# go after. The timers are created on separate threads so naturally catching those events happens on a different thread.

I didn't mean to imply that an event-based model meant multi-threading, I just wanted to throw up a caution flag regarding the way it's implemented in C# when using some built-in classes. Any of your own events should be fine, if they're designed appropriately.


V
24 Sep, 2008, David Haley wrote in the 12th comment:
Votes: 0
Oh – I didn't realize that C# had a special built-in mechanism for events that involved different threads. That makes sense, then: you would have to handle synchronization etc.
24 Sep, 2008, Vassi wrote in the 13th comment:
Votes: 0
DavidHaley said:
Oh – I didn't realize that C# had a special built-in mechanism for events that involved different threads. That makes sense, then: you would have to handle synchronization etc.


Mostly it was me being an idiot and trying to type quickly while in the middle of something. It's not really anything special, just not something you might think about right off the top of your head or take for granted. If you use one of the built-in timers, such as the server timer, every Elapsed event is raised on a different (the counting) thread and so any event handling code that you use will be handled on that same thread. Therefore, any events you raise based on a timer elapsed event are also now running on a different thread.

Pretty obvious when you think about it, but I made the mistake once, so I figured I would try to share. Relying on the timers is usually a bad thing, unless - like I said - you're tying to raise events that happen in parallel to the game stuff.


V
25 Sep, 2008, Weeks wrote in the 14th comment:
Votes: 0
DavidHaley said:
Oh – I didn't realize that C# had a special built-in mechanism for events that involved different threads. That makes sense, then: you would have to handle synchronization etc.


It doesn't.

When an event has multiple subscribers, ...

Sorry, unless you're using BeginInvoke() on an event or its delegate instance subscribers, you're not spawning or processing on any new threads. There are other mechanisms in C# and .Net that DO, however, and you may have run across one of those. Specifically any method that starts with "Begin*" will generally fire off the process on a new "fire-and-forget" thread, results of which to be handled by an IAsyncCallback method once it returns control to the main thread.

And sorry to call you out on this, but bad information needs to be corrected.
25 Sep, 2008, Vassi wrote in the 15th comment:
Votes: 0
Weeks said:
DavidHaley said:
Oh – I didn't realize that C# had a special built-in mechanism for events that involved different threads. That makes sense, then: you would have to handle synchronization etc.


It doesn't.

When an event has multiple subscribers, ...

Sorry, unless you're using BeginInvoke() on an event or its delegate instance subscribers, you're not spawning or processing on any new threads. There are other mechanisms in C# and .Net that DO, however, and you may have run across one of those. Specifically any method that starts with "Begin*" will generally fire off the process on a new "fire-and-forget" thread, results of which to be handled by an IAsyncCallback method once it returns control to the main thread.

And sorry to call you out on this, but bad information needs to be corrected.


Except for I already corrected myself twice, though I suppose perhaps I wasn't specific enough to your liking.


V
25 Sep, 2008, Weeks wrote in the 16th comment:
Votes: 0
I apologise, I didn't see that.

This was me, literally, this morning, only it was "Shouldn't you be at work??"

http://www.xkcd.com/386/
25 Sep, 2008, Vassi wrote in the 17th comment:
Votes: 0
Weeks said:
I apologise, I didn't see that.

This was me, literally, this morning, only it was "Shouldn't you be at work??"

http://www.xkcd.com/386/


lol, I hadn't seen that one before. That's a good one.


V
25 Sep, 2008, Conner wrote in the 18th comment:
Votes: 0
Thanks for sharing that lovely cartoon, now Dragona is trying to accuse me of having inspired the artist… :rolleyes:
02 Oct, 2008, Vassi wrote in the 19th comment:
Votes: 0
Midboss said:
Encrypted pies.

Or, if that's not your thing… For me, I'd seek a clean design. As far as any game mechanics you'd install, I'd like things to be organized in such a fashion that it's nice and painless to remove whatever I don't like and add my own features – digging certain things out of ROM, for instance, is a very large headache that isn't worth the time.

Beyond that, all the usual amenities, OLC, some form of scripting accessible from within the game, a shiny banhammer… You know, the must-haves.


Holy crap, that was tiny and I totally missed it on my first couple of read throughs on this thread. Anyway, I have a question about this. I've been thinking of releasing my code as a kind of 'baseline' (as barebones isn't quite enough) but my concern with it not being accepted is that it ties you in to a certain structure.

To elaborate, It isn't as simple as just handling sockets, it requires you to implement at least two other interfaces: a protocol, and a handler. I'll be including an implementation of a protocol (Which is a Telnet session tracker and negotiator ) so that one is kind of free for most people, but the Handler needs to be implemented as well before you can really use it. A handler essentially receives queues from the socket nuts&bolts such as Enter(), Leave(), HungUp() and Process(string) the last happening when user input comes in and is translated by the protocol.

There is some sugar I'm working on adding, such as Python support, a game-command architecture that works by 'discovering' commands at startup so you can just create the command class and forget about it, rather than having to reference it in two+ different code files so that it's recognized, and a priority queue for timed actions that is easy to use. Not sure what else you might want in a base-line implementation.

There's also a universal one-size-fits-all OLC system that works off of a decorator and a static function so that you can make your item class and then decorate your setters rather than having to make an unwieldy OLC function for checking all possible key values and converting strings to value types and then checking them, etc.
[CanEdit("^mle$")]
public byte JoinLevel
{
get { return minLevel; }
set { minLevel = value; }
}


I guess my question is, is being tied down to a handler-based system too restrictive as it is? It's really just the point where the Transport layer meets the logic layer, the way I look at it, but I'm not really sure how some of the C 'barebones' codebases work. I think Teensy supplies actual structures, like zones\rooms, while Tiny doesn't and SocketMUD definitely doesn't.


V
02 Oct, 2008, David Haley wrote in the 20th comment:
Votes: 0
Vassi said:
I guess my question is, is being tied down to a handler-based system too restrictive as it is?

If you're just talking about networking, then FWIW I think it's perfectly reasonable to define a callback interface of sorts to handle events from the sockets. If the interface is general enough, it's hard to imagine somebody wanting something else. After all there are only so many events that occur on sockets…

If you're talking about generic handler interfaces for other events, then things get more complicated. Clearly, the space of available events might be quite different from game to game. Still, a generic event handling mechanism would be fine, as long as the events themselves are left fairly open-ended.
0.0/33