Decision Tables (was: sparse components)

Some of these items hit or skim past some of my other findings, particularly
funny for me was reading 14 - 17. This is what hit me hard and opened my
eyes. After realising that existence base processing was linked to the
database courses I took at uni', I spent weeks trying to find out what else
married up. I thought that the SQL programming I'd done over ten years ago
would never be applicable again. Although SQL itself might not be 100%
applicable, a very large subset of the technology and techniques seem very
applicable to games development once you start thinking transform oriented.

For one thing, I came to the conclusion that each use of existence based
processing could be considered to be a replacement for a single bool in an
entity, thereby getting rid of another branch, and if you extended that idea
of primitive replacement, you could instead replace an enum/int and have an
exclusive set of components for an entity's state. This gave birth to the
general recognition of components as state (and behaviour). If the mutually
exclusive set of components could be given the power to delete themselves
and create their kin, then you have a very generic starting point for a
whole set of finite state machine techniques. The only problem I really had
with this was that for a finite state machine to come up with a decision for
whether or not to change state, it would normally have to do some data
gathering, and that was always cache hell on projects I'd worked on, so
wanted to know if there was another way to gather data.

It turns out that there's a database technique I hadn't heard of before
called "decision tables", and they are really useful for writing out your
decision logic in a simple to read manner. When written in SQL, these tables
are not as simple for the code to understand (some of them are defined as
column values in ranges such as greater than or less than), they aren't that
hard to turn into game dev values (I just collected the different range
requests and invent new columns for them ad hoc). The benefit of this was
that data gathering could be done in a transform oriented way, and therefore
not suffer the data gathering overhead.

After the data is in it's final table format, actually running through the
info and making decisions is the easy part. Dropping the decisions into todo
lists (one for deletions, one for insertions) provides another optimisation
and opportunity for concurrency.

I feel that every transition doesn't need to just move from one state
component to another. I like to see multiple entities emerge from one
transition on an entity (because that would allow a level of detail system
to be implemented in the FSM) but at the same time, any advanced activities
could be managed by having a more complex state do more than expected before
dropping through to a more basic state. I'm worrying about the trade off
between keeping transitions simple and keeping states pure even though they
are also behaviours.

On 28 May 2010 19:07, Warrick Buchanan <[email protected]> wrote:

>  Perhaps this summary may aid yours and others thinking:
>
> 14) Notice how efficiently a component/aspect/state/whatever entity system
> can be implemented in tandem with this and how well this maps to relational
> database tables (and ignore object orientated databases from now on)
> 15) Organise data into tables of actual data and sets of different indices
> into that data - and think in terms of queries, adds/removes and updates
> 16) Just have structs of data with the only functions allowed being
> initialisers and those that can compute values from the data in an immutable
> fashion
> 17) Read up on dataflow/flow based programming and model your programs by
> data flow and transforms on the data rather than ANY CLASS HIERARCHY AT ALL
>
> I hope that helps!
>
> Cheers,
>
> Warrick Buchanan
>
>
> --
fabs();
Just because the world is full of people that think just like you, doesn't
mean the other ones can't be right.

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com