[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Collider and Mover code
From: |
Gervase Lam |
Subject: |
Re: Collider and Mover code |
Date: |
Mon, 20 Jan 2003 23:20:44 +0000 |
> Date: Fri, 17 Jan 2003 19:11:53 +0100
> From: David Philippi <address@hidden>
> Subject: Re: Collider and Mover code
> > In any case, I think pingu_collider needs to be changed to just
> > collider.
> > This is because the abstract class pingu_collider should apply to any
> > object, not just Pingus.
>
> What other objects do you think should collide with each other? Defining
> = the=20
> scope of the class is required to answer your next questions.
>
> > But does this mean that collider should not have a getpixel() method?
> > Does getpixel() apply to all other objects? Should the class
> > hierarchy be
> > collider<-pingu_collider<-upright_pingu_collider or
> > collider<-upright_pingu_collider?
May be I should have asked a better question here. If getpixel() were
moved to collider and pingu_collider added, pingu_collider would be a
class that would add no functionality. It would only add a possibly more
future proof hierarchy?
For example, something in the future could be added to pingu_collider
because it is something in common with all pingu_colliders. Having
pingu_collider would (could!?) make this easy.
Also, if the former class hierarchy were to be adopted, does this mean
that there should be a directory structure like
"Games/Pingus/src/colliders/pingu_colliders"?
With regards to the hierarchy question you asked, I'll quote from what
Ingo wrote last year.
> Subject: Re: BUG #1589: The whole concept of
> forces/move_with_forces/forces_holder needs to be rethought From: Ingo
> Ruhnke <address@hidden>
> Date: 28 Nov 2002 19:57:42 +0100
>
> Gervase Lam <address@hidden> writes:
> > The problem with function objects is that it deviates away from the
> > object orientation idea of implementation and data being in one
> > object.
>
> PinguAction itself already 'deviates away' from that in much the same
> way as the collide stuff.
>
> > That is, a function object is a separate entity from PinguAction and
> > classes derived from it.
>
>
> Yep, and thats good for a number of reasons, keeping everything in the
> same objects just leads to a whole bunch of inter-dependencies and non
> reusable pieces of code. Keeping the collision stuff seperate will
> result in something that is reusable in a number of situations (for
> example some worldobjects might use it).
> > Also, how should things be set up if Function Objects were used? I
> > suppose the function objects would be in two files called
> > collision_at.hxx and collision_at.cxx in the source root directory?
>
> Something like that. Beside the collision stuff we should also keep
> track of a generic terrain-traversal engine, currently its all in
> walker and duplicated more or less in climber and sooner or later in
> the slider. But keep in mind that all code changes need to make the
> situation better and not worse, breaking actions is just too easy.
--
Thanks,
Gervase.
- Collider and Mover code, Gervase Lam, 2003/01/12
- Re: Collider and Mover code, Gervase Lam, 2003/01/16
- Re: Collider and Mover code,
Gervase Lam <=
- Re: Collider and Mover code, Gervase Lam, 2003/01/24
- Re: Collider and Mover code, Gervase Lam, 2003/01/25
- Re: Collider and Mover code, Gervase Lam, 2003/01/27
- Re: Collider and Mover code, Gervase Lam, 2003/01/28