[MUD-Dev] Middleware

[ceo]

Michael Sellers wrote:
> Raph wrote:

>> To broaden the discussion a little to the general topic of server
>> middleware/server codebases: what's the general feeling of the
>> list on this issue? My personal take is that middleware generally
>> makes too many assumptions that end up constraining the eventual
>> game design--plus, you have to rewrite most of it anyway or end
>> up with generic stuff. This has seemed to me to be true with muds
>> and true with MMOGs.

(At the risk of being perceived as blowing my own trumpet, I'm
responding with "the vendor perspective" :). Oh, and I'm
*definitely* not claiming "we've solved this problem"; we see it as
an ongoing process - like customer support, it's something you can
never sit back and say "There! It's Done!" - you just have to choose
how much you are going to make it a permanent high priority of your
development).

This is one of the three core USP's we've aimed at with the
GrexEngine from day one (I'm afraid I can't speak for other vendors
on this?): the ability for a developer to undo *any* assumption,
tweak *any* aspect of the system, and even replace *any* code at as
fine a grain as we can manage (which usually boils down to "replace
any instance of any class, even instances generated privately within
private code") and do all this without access to the source code.

  (the "without source code" requirement is a rather
  easy-to-understand way for us to check how well we're doing at
  achieving our aim).

It's worth noting that java's dynamic classloading and "all linking
is dynamic" behaviour go a long way to simplifying this task,
although we had to put in substantial effort to finish the job off
for class-replacement (java only provides very very low-level
routines for this; there are rumours it may provide high-level
features in this area in the next beta release, due in around 2006
(!)).

I would be surprised if this wasn't on the list of reasons why each
of the other middelware providers chose java as their implementation
language.

I'll be honest and point out that achieving the aim is a lot more
complex (though not necessarilly a lot harder) than simply
facilitating the hot-swapping of classes whilst preserving
performance. As a vendor you have to include a lot of architectural
support to get much traction on this - or else limit yourself to
providing the basic mechanisms to support it ("tart up" the java
low-level features into a toolkit) and leaving it to each games
developer to hang themself with the rope provided, unless they are
skilled or lucky enough to fashion a very powerful system from your
toolkit.

As far as implementation goes, we've shifted a lot of the burden of
code developed by game-studios into higher-level coding
areas. That's a bit of a crummy description, but I'm trying to say
that we don't simply say "script the lot" nor do we say "do it all
in a Rete" (which is an inference engine for those not familiar with
it) - we use our control of the base platform (i.e. the wider
execution environment) to provide a spectrum of places where you
write different code, blurring the lines between "scripts" and
"compiled code".

The effect is that some things you (as a game developer) would
traditionally expect to implement as imperative code you actually
implement as a series of directive to grexengine subsystems - the
"programming language" has been redefined for those tasks to be a
merging of a concrete language with a complex black-box system which
is effectively extending the language.

One example is where we use the fact that every method call in a
distributed system must eventually indirect via some form of
"locator and router" service provided by the cluster. This is a
perfect opportunity to provide a language-independent customised
function despatcher (one of java's major let-downs to 3rd party lib
developer is it doesn't allow you to in ANY WAY customize function
despatch :(, unlike C++ ).

Of course, that's only suitable for a particular set of
use-cases. For instance, it would usually be a bad idea to try and
divert every single method-call in your traditional scripted part of
your game in such a manner - the performance overhead would be
debilitating.

IMHO, the kind of work done by inference engines is the best way
forwards to solving the "my middleware provider made an assumption
that all players were subject to collision-detection, and I want a
game with a billion collionless ghosts; their assumption means I
can't get that many ghosts in the game on the hardware available"
problem. We have done a not inconsiderable amount of research into
customized inference engines (and hope to do some side-by-side
benchmarking with optimized CLIPS derivatives to see how ours fares;
basically, we were able to shortcut a lot of things by using
different engines for different problem areas).

Unfortunately, the real-life problems of financial management in the
midst of a 3 year VC drought have put such research on temporary
hold whilst we concentrate on getting our first 5 licensees games to
market (and this, incidentally, is the reason why a lot of my
promised extra info on the GrexEngine for 2003 never materialized:
it was all hands to the pump on the capital-generation side of the
business). We've had a few VC's cold-calling us this Spring, so
perhaps 2004 will turn out to be what we'd expected for 2003; but
I'm not promising anything :).

Adam M
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev