Re: [OO question] Single container, multiple types
Tim Conkling wrote:
> I've run into a problem [...]
> I can't think of any way to do this except to create a stupid
> SpriteSector interface that declares two methods, isSprite() and
> isSector(), have sprites and sectors inherit from this class, and have
> the container store SpriteSector pointers (or I could just C++'s RTTI
> functionality but that would essentially be the same thing). This just
> seems so ugly and poor and I like elegance and was wondering if anybody
> could point me to a nice design pattern or something.
Have you ever visited comp.object newsgroup? Seems right up your alley.
My point here is that you might have a design problem on your hands, not
just a language problem.
What I'd do is create some kind of "Collidable" interface and make all
my classes that represent objects with boundaries to inherit from that.
As to 'isSprite()' and 'isSector()', it doesn't seem necessary. You just
put pointers to those in separate containers for the purpose of doing
other, class-specific, operations.
[OO question] Single container, multiple types
I've run into a problem with a game I'm designing -- I (think) I need
to do something ugly, for speed reasons, and I'm wondering if people
here might have any ideas about how solve my problem more elegantly:
I'm using a templated container that I created for this project that
sorts objects based on a numerical value. That is, each object in the
container has an integer value associated with it, and objects with
lower integer values come before those with higher ones. If an object's
int value changes, it is moved in the container. This allows me to do
quick collision detection in the game's 2D world -- objects that need
to generate collisions insert themselves into the container twice, once
for their leftmost coordinate and once for their rightmost coordinate
(actually, there are two containers, one for each plane, and objects
insert themselves twice into both containers). When it comes time to
check collisions, only those objects that are between an object's left
and right positions in the container can have collided with it.
Originally, there was just one type of object that would generate
collisions. But now there are two types of objects that collide with
each other -- sprites (characters that are visible onscreen), and
sectors (regions that are not visible but which cause events to occur
when a sprite moves into them). It would be great if I could stick
these objects into the same containers, because they both need to do
collision detection. The problem is, there is no common interface
between them -- no mixin class that they can both inherit from or
anything like that. Their collision detection needs to occur at two
discrete times -- first all sprites check for collisions with all other
sprites, and then all sectors check for collisions with sprites.
Sprites never check for collisions with sectors and sectors never check
for collisions with other sectors. I need to know, when handling
collisions, whether an object in the container is a sprite or a sector.
I can't think of any way to do this except to create a stupid
SpriteSector interface that declares two methods, isSprite() and
isSector(), have sprites and sectors inherit from this class, and have
the container store SpriteSector pointers (or I could just C++'s RTTI
functionality but that would essentially be the same thing). This just
seems so ugly and poor and I like elegance and was wondering if anybody
could point me to a nice design pattern or something.
|All times are GMT. The time now is 02:37 AM.|
Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.