Re: Storing data and code in a Db with LISP-like interface

Marshall Spight wrote:
> Alvin Ryder wrote:
> > Marshall Spight wrote:
> >
> > Thanks for your reply.
>
> No prob!

Hello again,
Sorry about the delay.

> > > The RM is the pinnacle of data management.
> >
> > That might be so but I need it spelt out to me. How is it
> > relevant to games and ai?
>

> I am happy to provide some headlines and/or discussion, but

Thanks.

> you have to admit the limitations of the medium. (As an aside:
> could you post a message or two that will tell me what I need
> to know to implement my own 3rd person shooter. :-)
>

Sure, I have posted that aside at the end of this reply.

> The first thing that jumps to mind is "physical independence."
> You have algorithms that manipulate data. There are two
> facets to these algorithms: correctness and performance. In
> the tools you are used to using, these two *independent*
> considerations are so woven together that you (if you are
> like others I've spoken to) will have trouble even considering
> the idea that they could be split apart. But wouldn't that
> be amazing if they could?
>

I believe I am familiar with concepts of logical and physical independence, I appreciate the beauty of such independence but the burning question is how much time will any extra hokey pokey cost? The enemy is the clock.

To achieve a good frame rate, lets say 60 fps, you only get about 16milliseconds to do probably millions of calculations, user io, network io, any ai ...then bang the next frame.

> Another thing that jumps to mind is managing assets, even
> during the runtime. You are making extensive use of collections
> in games, yes?

That's right, pretty much like most OO programs. (Of course you can write games in C but I think you know what I mean).

> Do you write all your own collection classes?
> Wouldn't that time be better spent working on the game itself,
> or the renderer, or whatever? Don't these collections classes
> have to be debugged? How do you handle atomic updates?
> Ever have race conditions? Deadlock? (Or maybe games can
> get away with being single-threaded, and I'm on the wrong
> track.)
>

Yes I have written my own collections and memory managers, this buys you a good performance boost but of course it costs time to develop.

> Wouldn't you just rather write less code? If you could code at
> a higher level of abstraction (for much of the time) it would
> mean less code and more time spent on the problem domain.
>

Of course but sometimes you have to work with the bare metal yourself.

>
> > During my post-graduate studies I worked with the RM and some of its
> > extensions for spatial, temporal, object and logic databases. Why would
> > the RM be extended if it already covered everything?
>
> Ignorance, mostly. In some cases, philosophical differences.
> In a few rare cases, adding functionality (only logic databases
> would qualify for that, I would expect.)
>

I'm sure the reasons you have provided hold true in some cases but the RM has been extended in various fields because it has well acknowledged weakness. For example it isn't good at representing geographical or spatial data.

With the RM it's easy to say "list all customers with blue cars", not easy to say "list all monsters within shooting range", or "list all houses within 50 miles of me".

I'm not talking about issues with "sql", I mean issues with the RM. Not saying its bad but like everything it has its boundaries (no pun indended).

Sorry I cannot find my old papers on the subject, I'm sure they'll turn up somewhere (no doubt when I'm looking for something else).

> And anyway, I wouldn't say the RM is the best tool for
> *everything.* Just the best tool for data management.
>

Only certain kinds of data, it's not very good for: temporal, spatial, logic, oo, multimedia, unstructured and document libraries, ... but yes it has some strengths too.

>
> > Spatial databases held some promise but tried and
> > tested binary space partition trees kill them everytime.
>
> You're mixing logical and physical considerations. The idea
> that the RM means a row store is a common but false idea.
>

Yes I am mixing the two considerations, I'm obviously bent on the physical side.

And I know the RM is about "relations" and set theory but just as soon as Codd defines relations, he's jumped to tables, tuples, keys and attributes.

>
> > > One day the application programming world will wake
> > > up and realize that data management is a big part of
> > > what programs do, and that there are vastly better tools
> >
> > I agree data management is a big part of what we do but do you agree
> > algorithms are also a big part.? It is not just data but data+code.
>
> Certainly! In fact, my expectation would be that for games,
> the algorithms are the more important of the two.
>

Yay, we agree ;-)

>
> > > out there than coding up a first-order-only, unsafe,
> > > barely-statically-checked procedure using an antique
> > > type system (C) or a powerful but byzantine one (C++).
> >
> > Games need speed, C and C++ are fast. Fast is good.
> > We grin and bare with weaknesses.
>
> Did you read the pdf I linked to?
>

Yes, thanks. I'm always looking for more info. Epic games sell that game engine, its pretty good but mucho $$$ (Actually its a bargain compared to doing your own).

> If speed was the only consideration, then you would necessarily
> be writing in the fastest high-level language ever made: Fortran.
> For raw calculating power on large datasets, C++ simply cannot
> compete.
>

Fair enough, performance isn't the only critieria but it is crucial.

>
> > > Our programming languages themselves would benefit
> > > from directly incorporating even the simplest of facilities
> > > from the relational algebra. Libraries should begin to
> > > include data management engines. Doing this in a
> > > principled way would be much better than the kitchen
> > > sink approach that existing libraries take.
> > >
> > > Bob asks, directly to the point, "Do games programming
> > > or ai realms need to manage data?" Clearly they do; all
> > > programs manage data to a greater or lesser degree.
> > > Anything that manages data could benefit from the
> > > relational model.
> >
> > The obvious answer is "yes we manage data" but we don't want our data
> > normalized, in the form of tuples with key and non-key attributes. OOP
> > yes, RM no.
>
> Oh, I see. These are requirements, eh? So I'm sure when you
> put the packaging together for your next game, it will trumpet
> "non-normalized data" and "OOP" on the cover? :-) Or perhaps
> these aren't requirements, but rather just the way you are
> used to doing things.
>
Ok, you got me ;-)

> And anyway, I disagree that you "don't want [your] data
> normalized."
>
>
> Marshall

Cheers.

ASIDE - What is required to make a 3rd person shooter?

You need:-
o. to be comfortable with 3D math, vertices, matrices, quaternions, trig, geometry,...
o. ok with physics, ai helps,
o. familiar with common graphics techniques/structures/algos, BSP trees, zbuffering, A*algo, path finding ... o. familiar with OpenGL, DirectX or both, o windows api or whatever console,
o OOP helps,
o be willing to read a lot, in many domains, o to write or buy a game engine,

o. need to create 3d worlds (levels), interiors, exteriors, game objects, characters, ... using packages like 3D Studio Max, Maya, Blender, Milkshape, Quark, Worldcraft ... this data is exported/imported into format suitable for engine,

o. animations - another big topic,
o. scene management, collision detection, ...
o. networking,
o. most game engines employ a scripting language, "if button hit open

o a good story line, characters, music, "game play experience". I think the last point is the most important.

End aside. Received on Mon May 01 2006 - 09:52:17 CEST