Re: Modeling events that occur in a game world
- From: topmind <topmind@xxxxxxxxxxxxxxxx>
- Date: 27 Apr 2007 14:13:02 -0700
Jordan Marr wrote:
But you would avoid constantly accessing the slow hard drive!
DB != disk. A good DB only goes to disk when RAM is not available.
Which DBs can you imbed completely in memory like this?
Completely? Is that really the goal? Anyhow, relational theory does
not dictate implementation. Whether there is an existing
implementation that uses RAM exactly the way you want, I don't know.
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.
I see what you're saying, and if you had a small footprint /
completely in-memory DB, this could work nicely. Still though, it
seems easier to me to just objects and strategy pattern. This would
be all in memory, and it would avoid the chore of hooking up to a
database.
In biz apps a database is usually available and assumed available. If
one is not used to such in a game system, I suppose it could be time-
consuming at first. But if you wish to make lots of games with the
same engine, then the up-front config time may pay off.
I would rather use objects that represent the problem
domain than table structures that represent a database. After all, my
ogre is implementing a strategy, not a table!
You assume they are mutually-exclusive. I find apps easier to manage
when the stuff that can readily be represented in a declarative form
is put into a declarative form. Behavioral coding is then reserved
mostly just for the *exceptions* (oddballs) that need custom
fiddling.
When stuff is tablized, I can search, sort, and sift it as I please to
study any given aspect or relationship I want. Code is much more
difficult to do that. If people had such good memories, we wouldn't
need databases. If you are a structure savant who memorizes where
everything is and who doesn't need analysis and sifting tools, I
applaud you.
Plus it is easier to do many collection-oriented operations with a DB
than hopping around pointer loops in code. It is easier to do "math"
on declarative info than behaviorally-encoded info. To me, the
navigational/OO approach reminds me of Go To's.
jordan
-T-
.
- References:
- Modeling events that occur in a game world
- From: Aaron J. M.
- Re: Modeling events that occur in a game world
- From: topmind
- Re: Modeling events that occur in a game world
- From: Jordan Marr
- Re: Modeling events that occur in a game world
- From: topmind
- Re: Modeling events that occur in a game world
- From: Jordan Marr
- Modeling events that occur in a game world
- Prev by Date: Re: Modeling events that occur in a game world
- Next by Date: Re: Dependency Management (Was: Mixing P/R philosophy with OO)
- Previous by thread: Re: Modeling events that occur in a game world
- Next by thread: Design question: Multiplying singletons
- Index(es):
Relevant Pages
|
