In my game right now, I''m mulling over my class decisions. Originally when I designed the game, for reasons of speed and simplicity it went something like this :
(I don''t know what the best way to represent relationships is, I''m using -> to mean "inherited from")
Bitmap
Sprite->Bitmap
Ship->Sprite
Bullet->Sprite
FX->Sprite
Particle->Sprite
however, several times I''ve pondered whether or not the subclasses of Sprite should be derived from Sprite or not. Specifically, A Ship is a kind of Sprite.. is a true relationship, seems more true than A Ship Contains a Sprite.
But now that I''m adding sound, its obvious that A Ship is not a kind of sound, but merely contains a sound. And that''s making me wonder if it wouldn''t be better to cut the relationship between Ship and Sprite, and make a ship merely contain a sprite.
I''m thinking of reforming the classes more like :
Sprite->Bitmap
Sound
Actor (CONTAINING a Sprite and Sound(s))
Ship->Actor
Bullet->Actor
etc.etc.
What do you guys think?
- Remnant
- (Steve Schmitt)
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
An OO question...
I might do something like this
ISurface(your bitmap)
IDrawableObj holds a ISurface
ISprite is an IDrawableObj
if I want ISprite to handle key events, I can do this too
IKeyEventHandler
ISprite is an IDrawableObj and IKeyEventHandler
ISurface(your bitmap)
IDrawableObj holds a ISurface
ISprite is an IDrawableObj
if I want ISprite to handle key events, I can do this too
IKeyEventHandler
ISprite is an IDrawableObj and IKeyEventHandler
I would do something like this:
Class Sprite has image, x,y coords
Class AnimatedSprite extends Sprite has image2
Class PlayerCharacter extends AnimagedSprite has keyboardEvents
Class VehicleSprte extends Sprte has sound, passengers
You wouldn''t actually make any Sprite objects, it would just be a common thread for all the other classes in case you needed to cast. That way, anytime you needed to do necassary sprite things, like collision detection, you can be assured that anything that extends Sprite, has the necassary components.
Class Sprite has image, x,y coords
Class AnimatedSprite extends Sprite has image2
Class PlayerCharacter extends AnimagedSprite has keyboardEvents
Class VehicleSprte extends Sprte has sound, passengers
You wouldn''t actually make any Sprite objects, it would just be a common thread for all the other classes in case you needed to cast. That way, anytime you needed to do necassary sprite things, like collision detection, you can be assured that anything that extends Sprite, has the necassary components.
I think you are on the right track. I belive it''s very good idea to separate media from actor code. This allows an Actor objects to share media resources. You only need to load one bitmap/sprite/sound set for those 64 alien ships you have on the screen.
Remnant,
Yeah, your second idea seems better than the first one. Just remember about ISA and HASA relationships.
Should it be Ship ISA Sprite or Ship HASA sprite? If you think about it for a second, you can obviously tell it''s the second one.
Also, pdown is right on track. You don''t want to store the same media over multiple objects that use it.
Yeah, your second idea seems better than the first one. Just remember about ISA and HASA relationships.
Should it be Ship ISA Sprite or Ship HASA sprite? If you think about it for a second, you can obviously tell it''s the second one.
Also, pdown is right on track. You don''t want to store the same media over multiple objects that use it.
Deep inheritance trees make me tremble in fear.
I would suggest a hasa relationship here.
For instance, a simplified example from the game I''m working with currently,
An actor
has a sprite
has a sound engine
has a decision engine
sprite is just the graphical portion of an actor, no different than its sound portion, etc. players vs non players are the same objects, a player has a user input decision engine, the others have some ai engine or just a basic pathing engine.
Notwen
I would suggest a hasa relationship here.
For instance, a simplified example from the game I''m working with currently,
An actor
has a sprite
has a sound engine
has a decision engine
sprite is just the graphical portion of an actor, no different than its sound portion, etc. players vs non players are the same objects, a player has a user input decision engine, the others have some ai engine or just a basic pathing engine.
Notwen
Author
I''m glad to see you guys agree with the second method, because that''s what seems cleanest to me. I guess the whole reason I inherited my Ship, etc from Sprite in the first place was that I was viewing the Ship as simply an extension of an on-screen sprite.. but as my game is getting more sophisticated, its very clear that the sprite is merely incidental to the ship. (Ship exists in map space, makes decisions, etc)
Thanks for the opinions!
- Remnant
- (Steve Schmitt)
Thanks for the opinions!
- Remnant
- (Steve Schmitt)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
