Where to split mudlib and driver?

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



Joined: 11 May 2005
Posts: 152
Location: Florida

PostPosted: Sun May 15, 2005 1:25 am    Post subject: Where to split mudlib and driver? Reply with quote

Recently I've been thinking about how much of our system we should implement in the implementation language (C#) and how much we should do in Python. There are a lot of different ways this is approached by various mud servers, ranging from no mudlib whatsoever, or just using some simple language to script mobs, through fairly specialized systems like LPC or the various MUSHes, MUCKs etc, to completely general purpose programming languages like ColdC that simply happen to be useful for writing muds. What we've been doing so far is implementing 'game systems', i.e. the basic mechanics, in the implementation language, and relegating the scripting language to handling the actual world implementation (including AI, abilities, minigames, etc). There are quite a lot of reasons I don't want to do everything in python, not the least of which is the fact that I like static typing and I like my code to run at least reasonably fast, and calls across the CLR-Python barrier are expensive. On the other hand, the distinction between game mechanics and content is not always clear-cut.

So what I'm trying to figure out here is which direction I should be leaning in. Going purely in either direction is out of the question, and right now I'm favoring the C# end of things. What do you guys think?
Back to top
View user's profile Send private message Visit poster's website
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Wed Jun 08, 2005 2:57 am    Post subject: Reply with quote

I would tend to think that one ought to separate them based on the game being in the script and separate from the engine.

Another way of thinking about it is that they ought to be loosely coupled enough that I should be able to update the driver at regular intervals and then continue running the same game code. Backward compatibility.

Maybe three parts. The engine, the library and the game and content. That which for some reason doesn't perform well and needs tighter coupling to the engine becaomes an efun or native function of the library, which doesn't preclude doing something the hard way (or slow way) in existing game script code.

We once ported a live mud from ROM 2.3 to ROM 2.4B6 and it was an awful exercise in refitting customizations and data conversion. I expect that isn't the case for those running a specific LP driver like MudOS or DGD and upgrading it, or upgrading or patching one's PennMush or Cold server.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Lindahl



Joined: 29 May 2005
Posts: 56

PostPosted: Wed Jun 08, 2005 5:27 am    Post subject: Reply with quote

I'm unaware of the effeciencies of cross-calls, but in the compiled language I intend on implementing for TCP, they aren't too bad, but they require a wrapper. The wrapper is templated off of the function (for auto-generation) and implements several virtual functions. First, the script pushes its arguments onto the stack, along with a type indicator for each and the number of arguments. Then performs a run-time table lookup (simple index) to retrieve the wrapper. Then the wrapper validates the arguments using the virtual function. If the validation succeeds, then another virtual function pops the arguments off the script's execution stack, performs the type conversions necessary and executes the function that the wrapper wraps, in the case of a return argument, the return argument is then pushed onto the stack along with it's type tag. So it's generally pretty efficient - just don't go doing any heavy recursion. For CPU time quotas, only a certain number of byte-codes are executed per pass. You'll probably want to have priority levels here - AI would be low priority, whereas commands would be high priority.

Anyhow, what I'd probably do (since you really to implement as much as possible in the scripting language while being CPU-aware). Is implement all game logic in the scripting language, but have a set of low-level utilities that interact at the system logic level, such as:
1) converting a string to a target, using a radius or room
2) sending messages to a radius or room
3) moving objects in and out of containers (including rooms or locations)

Basically, have the scripting language implement anything you'd describe in a player's guide. Things you'd omit from the player's guide, you would implement in the mud-driver - these are the low-level system details that will give you seperation of game logic from system logic. I think this is about as elegant as you can get for having a strict method of determining what is implemented at the high and low level languages - one that doesn't really require a lot of thought.

Of course, you'll want to get down and dirty and implement some of the high level stuff in the low level language for performance reasons - but very few things you'd describe in a player's guide would satisfy this requirement.
Back to top
View user's profile Send private message
Author Message
eiz



Joined: 11 May 2005
Posts: 152
Location: Florida

PostPosted: Wed Jun 08, 2005 7:31 am    Post subject: Reply with quote

Lindahl wrote:

...since you really to implement as much as possible in the scripting language while being CPU-aware...


Actually, that was precisely my dilemma. There are a lot of game systems that I'd really rather code in a bondage and discipline statically typed language like C#, which our script language (Python) is definitely not. CLR calls in Python for .NET are horribly expensive, but I'm not really too worried about that.
Back to top
View user's profile Send private message Visit poster's website
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