Weeks
Fledgling
Group: Members
Posts: 7
Joined: Sep 5, 2007
|
#1 id:12465 Posted Sep 21, 2008, 9:38 pm
|
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?
|
|
|
Midboss
Conjurer
Group: Members
Posts: 248
Joined: May 18, 2006
|
#2 id:12468 Posted Sep 22, 2008, 12:53 am
|
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.
|
.........................  Successful Troll is Sucessful
Last edited Sep 22, 2008, 12:56 am by Midboss
|
|
Fizban
Wizard
Group: Members
Posts: 619
Joined: Jan 8, 2007
|
#3 id:12469 Posted Sep 22, 2008, 1:00 am
|
I hate you. Not just you though, anyone that posts anything that small.
|
|
|
The_Fury
Sorcerer
Group: Banned
Posts: 485
Joined: Jun 1, 2008
|
#4 id:12478 Posted Sep 22, 2008, 2:28 am
|
Fizban said:I hate you. Not just you though, anyone that posts anything that small.
Thank Firefox for Ctrl++
|
......................... bMUD: Custom server written in Ruby.
The Oriental Dojo Mud
The_Fury: Coder and Designer.
|
|
Fizban
Wizard
Group: Members
Posts: 619
Joined: Jan 8, 2007
|
#5 id:12479 Posted Sep 22, 2008, 3:17 am
|
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
|
|
|
|
|
|
|
Weeks
Fledgling
Group: Members
Posts: 7
Joined: Sep 5, 2007
|
#8 id:12517 Posted Sep 22, 2008, 8:22 pm
|
lol, wish granted, kia. :)
|
|
|
Vassi
Conjurer
Group: Members
Posts: 182
Joined: Sep 24, 2008
|
#9 id:12618 Posted Sep 24, 2008, 12:15 pm
|
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
|
......................... Vassi no Diem et Tharin
< ramble/>
Last edited Sep 24, 2008, 12:16 pm by Vassi
|
|
|
|
Vassi
Conjurer
Group: Members
Posts: 182
Joined: Sep 24, 2008
|
#11 id:12626 Posted Sep 24, 2008, 12:55 pm
|
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
|
......................... Vassi no Diem et Tharin
< ramble/>
Last edited Sep 24, 2008, 12:57 pm by Vassi
|
|
|
|
Vassi
Conjurer
Group: Members
Posts: 182
Joined: Sep 24, 2008
|
#13 id:12645 Posted Sep 24, 2008, 5:58 pm
|
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
|
......................... Vassi no Diem et Tharin
< ramble/>
|
|
Weeks
Fledgling
Group: Members
Posts: 7
Joined: Sep 5, 2007
|
#14 id:12721 Posted Sep 25, 2008, 8:52 am
|
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, the event handlers are invoked synchronously when an event is raised.
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.
|
|
|
Vassi
Conjurer
Group: Members
Posts: 182
Joined: Sep 24, 2008
|
#15 id:12722 Posted Sep 25, 2008, 9:10 am
|
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, the event handlers are invoked synchronously when an event is raised.
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
|
......................... Vassi no Diem et Tharin
< ramble/>
|
|
