RE: [Algorithms] Game Entities - avoiding inheritance / fixedpool allocation

[Clinton K. <ck...@sa...>]

Chris Hecker wrote
> However, the key is that emergent systems (really all game designs,
but 
> especially ones encouraging emergence) need iteration during their 
> development.  You don't just type up the big spec and hand it to
somebody 
> to implement, because we've all found
> that doesn't work if you're trying something new, and it barely works
if
> you're just trying to do a no-brainer sequel.  So, you need to iterate
the
> design, and the best way to do that for emergent gameplay designs is
to
> empower your designers and use a data-driven property system, in my
> opinion.

This is absolutely true, but we've found you can go too far with
data-driven systems.  Either extreme has major technical drawbacks, but
the main problem we've seen with taken data-driven design too far is
that you end up giving the designers far too many knobs to control.  Try
to make a modern driving game that exposes all the data and you need to
get designers that can understand a lot more about physics than they
really can handle (I've seen over 200 parameters per vehicle for
tuning).

The same goes for component (aggregated behavior) models.  We had a
system with a "spring force" component that was intended to act upon a
limited number of objects (e.g. platforms).  Before you knew it, the
designers were putting spring components on every imaginable object in
the world and expecting them to bounce controllably.  Not going to
happen.

The best system is somewhere between "programmers going off and coding
up a fun game in a class hierarchy" and the "designers going off with a
blank-slate and a ton o' components and making a fun game".
Communication is key.

--
Clinton Keith
Lead Programmer, Engine and Tools Group
Sammy Studios
ck...@sa...