[vworld-tech] VWorld Ontology

[Richard]

 > -----Original Message-----
 > From: ceo [mailto:ceo at grexengine.com]
 > 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).

Thanks for the advice, but I am fine with OpenCyc for now.  I
imagine when I get to the point where I have a set of rules
which I am happy with I'll consider sticking with it, writing
my own or looking for another.  I've set myself what I
consider an achievable goal to start with and for my needs
OpenCyc so far looks to be satisfactory and sufficiently
user friendly.

 >> What kinds of patterns are you expecting that make the
 >> standard optimisations used insufficient?
 >
 > ... 
 > 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.

Ahh.  This is what I was overlooking.

The reason it did not even enter my mind when reading what you
wrote is that I had already decided to keep all my game-state
out of the ontology, at least for now.  To simplify things
the ontology is just going to be common-sense rules and
static information.

 >> What engines have you evaluated and exactly what do you do as a
 >> benchmark in order to determine if an engine suits your needs?
 >
 > 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! ;)).

In terms of what you generally do to benchmark your product
it is interesting to hear this.  I never really thought that
you would have to go to this length, but of course it makes
perfect sense.  It sounds like a lot of work, but also like
something very interesting to do for a living.

But it does not shed any light on what use you make of the
engines you are benchmarking.  Understandable of course.

 >> 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 :).

I am under the impression that creating an ontology is something
that is hard to do right.

So, that OpenCyc comes with thousands of 'common-sense' assertions
to provide some degree of a model of the world out of the box,
which have taken hundreds (or thousands) of man-years (or whatever)
to compile, seemed like an advantage.

When I had finished building my set of rules, I was hoping that
when I tried to shoehorn it into the OpenCyc ontology, it would
link right into these assertions in a broad selection of 
suitable places giving me that underlying foundation of
knowledge which would make the reasoning deeper.

I'd be able to take advantage of refering to the existing
constants, like the ones that immediately spring to mind:

 #$Animal
 #$Person

Then my queries could benefit from being able to include
the knowledge that dogs are animals and have six sides and the
reason they have six sides.  Without me having to provide
that information through my own efforts.  Obviously, I
cannot and I doubt I know anyone who can provide a case
where knowing this exact fact (that dogs have six sides)
would be of any help at all.  But in the thousands of
assertions, I am sure there are at least a few which have
obvious benefit.  I would attempt to provide some but given
my lack of experience with this technology, which ones would
actually be helpful in practical situations is not something
I feel up to picking a selection of.

 >> 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

I am not sure you have, given the lack of context I gave.

The assumption I made was that your inference engine usage 
would require that base of "common-sense" assertions to
some degree.  And that given the monumental effort put into
it by Cyc to come up with this base, you might provide something
similar for those that use the facility you provide to build
their ontologies on.

But on reflection, I have as much as said that I cannot think
of any of that "common-sense" which I expect to benefit from
other than the easily recreatible rules that there are things
that are people and animals that are dogs.

And if speed were to become an issue, I imagine that all these
thousands of extra assertions would more than likely be more
of a dead weight than a help.

I do not think I have any understanding of the extent or
way in which you use the engines in your test case games.

 >> 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.

Taking the time to write tools to make my job easier is just
the same to me as taking all the time I need to abstract the
code I work on in order to facilitate future changes.

Its another trade off in terms of time spent.  And given the
scope of our game which I work on, going back and forwards
between a large number of areas in it, more often than not
I choose not to write those tools.

I would love to take the time to write tools to make my job
easier.  Or to improve the ones I have written to the extent
I know I could take them.  But its a judgement call.

I cannot really address much of the rest of your email I am afraid.
Perhaps I was a little too vague about how extensive the problems
I encounter are outside the context of using an inference engine
as an alternative approach.  In any case, that vagueness seems
to have led to a misunderstanding.

 >> 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.

We have several layers of real testing of changes beyond this.

Testing is not my job and when I say that I test my changes
it is to the extent that I am satisfied that the actual testers
will not come back telling me that it or another part of the game 
does not work because of my changes.  It is more for the purpose
of not wasting their time and having personal pride in knowing
best I can that I have done quality work.

 > 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;

My situation and the one you describe are different.  In my case,
it simply comes down to a wide range of varying responsibilities
and a desire to personally test my changes to the best of my ability.

The framework we use, based on stackless python makes a lot
of things very easy and python code is naturally very readable.

>  > 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

No, what it means is that the use of an inference engine as a
fundamental part of our game, is not something I would recommend 
a switch over to, or experimentation with or have any intention to
experiment with on my own behalf in my own time.

The range and nature of things I work on within the scope of our 
game is unique, even if the problems I described for the
purpose of showing how I thought an inference engine might
change the nature of my job, were more than what I consider
an acceptable part of what doing my job requires, there is no
relationship to how anyone else working on our game goes about
their job.

I consider them to be an reasonable part of my day to day job.

Richard.