[Rpge-devel] On grids, generality, tables and generic stuff in general.

[Remco Bras]

Hi,
as some of you might know, RPGE now has an experimental branch (named tilework 
due to its relevance to my original experiments in tile grid stuff...), which 
should be used for all experimental stuff (well, doh). Also, since tilework's 
recently been merged into master, we now have a.. gasp.. tilegrid.

Michael de Lang however suggested that my current implementation of tilegrids 
(essentially a simple width by height tile matrix, i.e. a width-sized array 
of stuff pointing to height-sized tile arrays) is indeed deficient in the 
fact that it allows only for rectangular tile grids. I do know that... 
essentially... most tile grids will be rectangular (play Super Nintendo Role 
Playing Games for examples, almost zero exceptions) and in fact, I don't want 
to get into some weird discussion about whether or not our grids should be 
rectangular or any shape we want as, quite frankly, any shape we want can fit 
inside a rectangle anyway (and besides, if we want to start a discussion like 
that, we might as well start discussing whether flat 2D surfaces should be 
flat). However, the discussion does have SOME merit as it's a case of 
a "generality vs practicality" discussion.

For example, we could extend sprites to be larger than a tile if they want to 
be, but is this practical? We could allow for different-sized sprites by 
having every single mob specify how large it is, or we couldn't.. If we did, 
we might be able to cook up some unbelievably awesome ways to do sprite 
animation (case in point: A guy transforming into a dragon and dynamically 
taking on new, larger sprites as opposed to scaling the old sprite and 
warping it a little ) , heck, we could even use them for some crazy 
perspective-like tricks. Sure, it all sounds rather cool, but isn't it a pain 
in the ass both to make and to use this stuff?

Similarly, we could have guile do stuff like items and all and provide a 
standard library, for which we'd have to do stuff with global data supplied 
by guile in C space. Personally, I guess we could use some extremely crazy 
hierarchical tree for this kind of stuff, but would that be practical? 
(Specifically, I'm worried it might be far too slow to actually be feasible, 
especially with oft-used stuff )

Or, we could even have guile extend our structs with lists whenever the heck 
it wants, or we could just provide a standard library to emulate that on top 
of the tree from the last paragraph or.... we could go insane before actually 
even getting this to any usable level.

Once again, I think the engine should keep state and automate rendering and 
all actual gameplay logic should go into guile, but if you start thinking 
about this, you arrive at some sort of utterly insane freedom we're giving 
the user, namely the freedom to build insanely amazing abstractions on top of 
our basic engine and basic libraries. Of course, that's the whole point of 
this project, but especially with that database or a struct-extending 
mechanism (we could just tack on an SCM in every single struct ya know), this 
can get rather amazing. 

Either way, in my opinion, the urgent task list is now as follows:

-Get tile stuff done
-Get video subsystem done so we can render some things
-Finalize the basics of the engine
-Start on a concept of the C/guile interface
(We could branch out a second branch for an experiment with struct extending 
and do the database way in another... but, on my test system, detecting any 
performance differences might be quite hard, unless we botch either one 
terribly... Also, we cannot test for edge cases since we have no idea what 
kind of insanities users will unleash upon RPGE one day.)

P.S.:Michael, I do agree that we shouldn't waste unnecessary space on empty 
tiles, but should we add more data just so we can keep track of where there 
are no tiles at all? Of course, that in itself warrants a few more 
e-mails....

Well, that's enough for now.

-- 
If I have any talent at all, it's merely the talent of having extremely bad 
luck.