[vworld-tech] VWorld Ontology

[ceo]

Richard wrote:
 >>From: ceo [mailto:ceo at grexengine.com]
 >>It's something we've used for a while now, and there's really
 >>only one major problem: speed.
 >>
 >>Inference engines these days are generally either very very
 >>expensive or very very slow :P.
 >
 >
 > This isn't a concern at all for me.  I am working on a hobbyist
 > project, and I am just as happy for it turn out to be a
 > simulation for as long as this would remain a problem.
 >

In that case, go get yourself a rete-engine (although to be honest most 
of the free ones truly suck, in terms of user-friendliness, performance, 
and overall design).

Do you have a preferred implementation language? (not that it 
necessarily matters, but a large number of them seem to prefer VM's such 
as java these days, for obvious reasons).


 > What kinds of patterns are you expecting that make the standard
 > optimisations used insufficient?

If you lookup "rete algorithm" in any good algorithms book/website you 
should find a pithy description of it's suitability.

 From memory, it's the only mainstream algorithm whose performance is 
demonstrably independent of the number of rules.

It's particularly suited to situations where the knowledgebase (data 
about your game) *could* change a lot, but in practice doesn't change 
much from cycle to cycle.

That's like saying that your game-state (the composition of everything 
that is in the game, all variables, etc) changes infrequently, but 
different parts change each time.

It should be clear that this is already a no-no for many styles of MMOG, 
although there are obvious tricks you could use to try and "mold" the 
behaviour of your game-state into fitting the preferred behaviour of a 
rete algorithm. You can get quite far in this way.

 > What engines have you evaluated and exactly what do you do as a
 > benchmark in order to determine if an engine suits your needs?

(limited by commercial sensitivity)

Basically, we build and maintain a range of different games representing 
different genres of MMOG (only one of which involves people running 
around on a landscape hacking each other with swords! ;)).

Although this is expensive and gives very little concrete data (and you 
have to be aware that a game which is only 5% of a real game has a 
potentially huge error margin on any stats you collate from it!), it's 
something we have to do anyway since we're supplying MMOG middleware to 
a wide variety of licensees (including mobile games, sports games, 
trading games, and RPG's). If we *don't* do something like this, how 
else do we check how adaptable our API's are to different genres?

 > The advantage of OpenCyc for me as a starter pack is that I
 > suspect the ontology which comes with it will be of use in

I haven't looked at OC in ages, so you'll probably have to explain a bit 
more about their pack before I can comment usefully :).

 > providing that common-sense foundation.  And by the extent of
 > its content would guide formation of further rules.  Are you
 > thinking of providing something similar?  Or is that something
 > for someone who uses what you are providing?  Or is the use
 > you expect out of it such that a similar base to work from
 > would generally not be of use?

*If* I've understood you correctly, then the last sentence is the one 
I'd go with. We do NOT provide a "look, I've done most of the work for 
you, you just have to decide how many hit points the giant-troll is, and 
what colour his skin is", i.e. a "pack" for each genre where the game is 
already written, you just fill in a few blanks.

OTOH, we DO provide a "look, all the systems-integration is done for 
you, all you have to do is work within the bounds of this architecture, 
and you can do anything.", and we *do* release "packs" for each genre 
where the game is NOT already written but a lot of the sub-systems for 
the game are *mostly* written (and typical licensees e.g. rip-out the 
pathfinding algo to replace with one of their own. As opposed to the 
former example, where the largest piece of customization a developer is 
going to do is change the names of the main characters).

 > I'd be interested if you could give an example of what you mean
 > by low-frequency game logic.

I.e. (re-)design your game so that the logic for the gameplay can be 
executed infrequently. Rather like designing your AI routines to produce 
partial results, and to refine to perfection - so that they can be 
called every X frames and give a meaningful answer that can be pumped 
into a monster-move even if X happens to be "1"; it won't be a great 
answer, but a hundred frames later the algo will have refined down to a 
much better answer.

Similarly, you can design your game so that you can get away with only 
invoking the game-logic checks infrequently. Obviously, you may not be 
able to do this and simultaneously retain enough of your core 
game-design for it to be worthwhile :), but it will work for some designs.

 >
 > Its a pity in terms of MMORPGs.  Because being a game logic
 > programmer, practically everything I do, I do thinking that I
 > could also do it using an inference engine with less effort
 > and stress if it were practical.  Theres a constant balance

Yep. As far as we're concerned, if a game-logic programmer is facing 
that then they're missing the tools they need.

Whether or not we can actually supply those tools, and to how large a 
section of developers (i.e. what the limits of it's applicaibilty are), 
remains to be seen.

 > It is of course possible for me to test all my changes on my
 > local game servers to the extent where I believe I know theres
 > no bugs but the whole process of being able to test the changes
 > to the extent they can be and having to always know the range of
 > influence the changes have wears on me.  I mean in the sense

One should *never* be testing a complex system like that; it's 
ultimately a doomed process (I'm assuming you are describing a 
theoretical situation, not something you'd actually do :)). There are 
certainly things you can do right now that are considerably better - 
Larry Mellon's talks on testing in TSO are one example.

 > I certainly don't mean to infer that our game logic is bad, to
 > me it is that there is such a lot of it.  The reason I qualify
 > this is that it is trying to post to our forum and then when
 > I return to read more about some problem, theres mainly a
 > multitude of posts reading something into what I have said :)

I think I understand what you're saying; I proposed a system a couple of 
years ago which would expose a tool that effectively predicted what 
effects your changes to the game-logic would have. This was born out of 
analysing the dev process and finding what you just described - the 
maintainability of game-logic in a complex MMOG can be entirely 
independent of the quality of code; this is because it's also dependent 
on the quality of inheritance system, which in turn depends on what 
function-despatchers you have available, etc. And these are things that 
developers tend not to ever think about after the point where they 
choose an implementation language.

 > Building a framework where an inference engine has a place
 > perhaps you have a more accurate perspective of how practical
 > using it actually is.  I imagine to determine how much use it
 > would actually be in our game would require experimentation.

So far, we've only a small amount of data on the effectiveness (limited 
by how complex an example game we can afford to build ourselves!). What 
would be really good would be if we could integrate our prototypes into 
someone else's game, doing whatever (probably considerable!) extra 
development was necessary to make the game able to run off the 
(modified) engine.

 > It is unlikely to ever happen, the experimentation to gauge
 > the actual usefulness and the intent to use it.

I assume this means that you've already got good solutions for the 
problems you described above? Seeing as ongoing code-development and 
maintenance are *the* biggest costs in a long-lived product (even more 
so with a service!) like an MMOG, this is where the greatest possible 
savings could be made. It's the area where you could most increase your 
profitability.

Admittedly, this is a business lesson that only the large corporates 
tend to have experienced before, so I could understand if your 
management weren't comfortable with it. I know of situations where 
reducing the maintenance cost of a single product to near-zero has been 
enough almost to fund R&D for an entire research-lab year-after-year for 
a decade or more: because the total revenue received increases ever 
year, and the only cost is maintenance/support/upgrades, over time every 
other expense shrinks in percentage terms.

Adam