[MUD-Dev] How much should be offloaded to Scripting?
elanthis at awesomeplay.com
Tue Feb 10 22:25:43 New Zealand Daylight Time 2004
On Feb 10, 2004, at 6:05 PM, Dan Larsen wrote:
> A little backstory...
> I'm working on a hobby game atm, text-based and driven by an
> object-oriented scripting language. I'm sure I'm not the only
> one, but my scripting language is now up and running, as is the
> network layer of the server itself.
> Now, my question is this. How much of the game should I offload
> onto my scripts, versus hard-coding it in the server? If any of
> you are familiar with TADS (Text Adventure Development System),
> the language is comparable to that, which means I could implement
> my entire parser via script, as well as my world and interactions.
> Basically, my server could be totally ignorant of what a 'room' or
> an 'actor' or the command 'say' is.
> But does it make more sense, both architecture and
> performance-wise, to shift at least some of the logic to the
> server itself (written in C)? For example, letting it parse and
> dispatch commands, the vast majority of which simply trigger
> script events. This saves the scripting language from having to
> parse, and doesn't cost much flexibility, but it is limiting in
> some ways.
The simple answer is to evaluate each module's implementation
language based on how well the language suits said module. I.e., if
it is easier and more efficient (by this I mean development
time/cost efficiency) to program the module in C, do so, or if it's
more efficient to do so in your script language, do that. Obviously
in performance critical sections of code, C may be necessary vs the
script language even if C makes the task far far more difficult (and
thus increase development time greatly). Script languages can often
be much easier to develop logic in and such, but many script
languages can be difficult to use for architectural sorts of things.
You're more familiar with your script language than me, of course,
so I'll leave judgement of its particular strengths and weakness to
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev