Re: Modeling events that occur in a game world


Jordan Marr wrote:
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.

But you would avoid constantly accessing the slow hard drive!

DB != disk. A good DB only goes to disk when RAM is not available.


Gamers have always gone out of their way to avoid hard drive access as much
as possible. Virtual memory == choppy game play and low framerates! That's
why most gamers who know anything about computers go heavy on the RAM to
avoid hard drive access as much as possible.

But this tends to model how humans and animals think. Outside of raw
instinct (run like hell!), we tend to stop for a second or so to think
and sometimes get confused temporarily. I did not suggest that
everything be hooked up to the DB. The general strategy and planning
would sort of be processed in the background, in an independent
process from the here-and-now game engine. The primary (visable)
process would generally take care of instinct-oriented behavior, but
strategy etc. would come from the DB-driven strategy engine. Even
though your enemy might be running for cover at the moment, he/she/it
should still be working on a counter-attack strategy.


Maybe if the OP was programming solitaire.. no wait, i'd still choose OO /
RAM over RDBMS / HardDrive for solitaire!

Jordan

-T-

.