Re: Modeling events that occur in a game world

On Apr 28, 1:29 am, topmind <topm...@xxxxxxxxxxxxxxxx> wrote:
Alvin Ryder wrote:
On Apr 25, 10:19 am, topmind <topm...@xxxxxxxxxxxxxxxx> wrote:
On Apr 21, 10:24 am, "Aaron J. M." <ajm...@xxxxxxxxxxxxxxx> wrote:

I need a way of representing and tracking different events that occur
in a game
I'm working on. I have a world composed of one or more Maps. Each
Map location
(coordinate) may or may not have a Creature. A Creature is controlled
by an AI,
which may also be the player's UI, though the Creatures themselves are
not
necessarily aware of their AIs. Creatures may move to different
coordinates or
attack other Creatures.

Right now the two events I know I'll want to keep track of is when a
Creature
attacks another Creature and when a Creature dies, and I see myself
coming up
with new events as my game grows more intricate. Different parts of
my game
would be interested in different kinds of events. The graphical
display would
be interested in all events so that it may display an appropriate
animation.
More importantly, the different AIs would need to observe recent
events to
modify their behaviour. If a Creature is attacked, the AI controlling
it has a
vested interest in knowing about it.

I'm having trouble modeling this because the different kinds of events
would
keep potentially arbitrary information, making it hard to generalize.
An attack
event would know the attacking Creature, the target Creature, and the
amount of
damage done. A death event would just know the Creature that died. I
might
also implement Creatures grabbing and throwing other Creatures, so a
throw event
would need to know the throwing Creature, the thrown Creature, and
where the
thrown Creature landed. For this reason I can't really make them
subclasses of
a single Event class, since they hold such different information.

So how would I model these events and let my system handle and respond
to them?

Thanks

With all that to track, have you considered using a database? I
realize that performance with a database might not be as predictable
as a RAM-only solution, but depending on the game, it might not matter
much. Maybe bats or lightning can fill in the times when the DB is
slow doing garbage collection etc. I would try to make the DB
processing and game engine be somewhat indepedent processes so that
something can still be visually happening while the DB is "thinking".
SqLite is a light-duty DB open-source C-based engine that may be
embeddable in a game.

While great for business applications, the biggest issue is the
relational model itself. It is not good at representing every domain.
For instance it struggles with temporal, spatial and multimedia
databases.

Are you talking relational *theory* itself, or current implementations
(Oracle, etc.)? I will agree that many DB vendors focus too heavily on
cloning Oracle, but I have yet to see a problem with the concept of
relational itself.



Set theory and predicate logic go a long way, especially for biz apps
but for geographical and spatial databases the theory needs to be
extended. You'd want to, at least, add a "spatial join" operator to
the relational algebra. While you're at it may as well throw in a heap
of graph theory.

Ironically Oracle do have a Spatial DB but I've never used it.


Try these queries with your RDBMS. Create a simple 2D world using
points and lines, let there be areas. One area could be a poison pond,
just a simple polygon like (1,1), (1,7), (7,7), (7,1) will do.

I was not considering geometrical construction, but more game
character management, which is what the original post was concerned
with. Although I think a relational engine could probably be tuned for
geometry and CAD, that is not what I had in mind here.


Oops my mistake. When I considered the subject, years ago, I was
thinking about all or at least most aspects of game engine design.

I suspect that gaming chips will eventually take over this role
anyhow, similar to having dedicated graphics chips but with an
expanded role. Gaming chips will start to process physics also, not
just rendering. It does not make a lot of sense to me to have one
model of a scene in the CPU and another similar model in the GPU for
rendering. From a performance and abstraction standpoint, it seems to
me that the "physics engine" should be with the rendering engine. The
CPU would then handle only general proximity and orientation, and
events like "player stepped on (made contact with) Panel 7", analogus
to "onClick" or "rollOver" events in GUI's. The calculations of actual
contact would usually be in the "physics chip".



Yep, those chips are all available now.




Now answer queries like:-

-1. "Have you fallen into the poison pond"?
is point (0,0) within the pond, is (3,3) within it?

-2. "There are two polygons do they intersect"? (collision)

-3. Create a road with corners; "how far is it from
point A to point B if you travel only via the road"?

Without a spatial join things are a tad awkward.

Graph theory has been mixed with set theory and predicate logic, there
are Geographical Information Systems (GIS) and there are Spatial
Database, these push in the right direction but practically probably
not enough at this point.

I wonder what those NavMan or in-car navigational gizmos use. Does
anyone know?

Do you really want to build a complex interrelating structure(s) with
objects instead of a DB? You would end up reinventing a lot of DB-like
idioms from scratch if you did it with classes.

Just an idea.

-T-

This is a case of jumping out of the frying pan into ragging fires.
It's not a case of DB versus OOP, there is a third player, the
graphics pipeline.

Games are built on mathematics, API's like OpenGL or DirectX, GPU's,
art, animation, ai, characters, plots, physics, sound, music and a
heap of other disciplines. The least of your concerns are DB-like
idioms versus interrelated structures ;-)

You still have to manage all the characters and their attributes such
as energy level, goals, etc.



Actually that is not a bad idea at all. An alternate and perfectly
legitimate way to describe a relational database is "a collection of
true valued predicates". Leaning more in its predicate logic roots you
could form the basis of an ai engine. Games are wanting more and more
ai so the idea has merit IMHO.


For biz apps I let the relational model serve as the cornerstone and
OOP as the subservient technology. Many OO programmers invert this and
suppress relational technology but if you don't treat the database
nice, it'll bite back hard.

Similarly for game apps I let the graphics pipeline rule and OOP is
yet again subservient. Again inverting that relationship leads to
nothing but trouble.

Attempting to drive games by relational thinking is another example of
letting the wrong technology lead. There's different horses for
different courses.

I think you misunderstood the role I suggested for a DB.


Yes that's true my apologies. The keyword is "role", in that case I
agree the relational model can certainly play a part. Game engines are
like technology pigs, they gobble up just about any and every theory,
there's plenty of room for set theory and predicate logic in there.

Cheers.



.

Relevant Pages

  • Re: Modeling events that occur in a game world
    ... may or may not have a Creature. ... with new events as my game grows more intricate. ... have you considered using a database? ... SqLite is a light-duty DB open-source C-based engine that may be ...
    (comp.object)
  • Re: Perception and AI (and log messages)
    ... Where do the messages that describe events in the game come from? ... In the case of damage reports, ... AIs friendly to the player and the rest ... would make its creature run away if it has too little health, ...
    (rec.games.roguelike.development)
  • New project.
    ... ancient computer game called Chaos*. ... players are allowed to cast one spell. ... Each player starts with ten spells in his hand, ... The number of wounds required to kill this creature. ...
    (rec.games.miniatures.warhammer)
  • Re: Modeling events that occur in a game world
    ... may or may not have a Creature. ... attack other Creatures. ... with new events as my game grows more intricate. ... have you considered using a database? ...
    (comp.object)
  • Re: Furry Dragons and Storylines...
    ... > i do a save game, this is what i would do. ... > then items the ground and then creature(s) (only one creature will ... > objects that hold other skills! ... The best OO way to do that is to have one single argumentless constructor ...
    (rec.games.roguelike.development)