Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

xjussix

Should I store the enemies etc. in lists / arrays? (2D game)

This topic is 5666 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Or where? Is it ok to to create a vector / linked list of say CGameObject. Then derive all the enemies, the player, energy boosts etc. from that CGameObject and place all of them in that list. That way I could do the following thing (Not real code btw ):
CGameObject* poGameObject;
poGameObject = oList.GetNext();
poGameObject->Render();
 
Something like that. Is this a stupid way of doing things? To me it seems like a handy way of drawing all the objects (sprites more specifically) nice and cleanly. Comments are welcome. =) Oh and if I have that list of CGameObject pointers, should I place that list in my CGame class as a private member?
CGame oGame;
oGame.RenderObjects();
 

Share this post


Link to post
Share on other sites
Advertisement
Enemies will often die, and depending on your game, new ones may often be created (especially true for other sprites such as projectiles). Therefore arrays are a bad choice. I have written games using arrays, but that was before I learned of linked lists. Linked lists are a much better alternative.

Note that for permanent sprites, like static objects placed in the level, arrays are best.

~CGameProgrammer( );

Share this post


Link to post
Share on other sites
Yup, that''s probably very true. After all, I don''t know or want to limit the amount of objects/sprites. Thanks for the advice.=)

Btw, what do you mean by static objects?

Share this post


Link to post
Share on other sites
Static objects = objects that you know will be there, objects you know will not change/die/spawn in a random fashion.
Like bakgrounds, terrain etc.

Share this post


Link to post
Share on other sites
That trick is quite valid in OO programming, in fact it involves polymorphism and specialization.

(Note: in VC++ 6.0 it involves changing a setting in the project to activate ''RTTI information'')
As an example, this is how I built a whole GUI system...


  
class GUI{
virtual bool IsOver(int X, int Y)=0; // returns true if given screen coordinates are over the GUI

virtual void MouseEvent(DWORD dwEventType, DWORD dwEventData)=0; // Called when the manager detects mouse events for this GUI

virtual HRESULT Render()=0; // Renders this GUI

virtual HRESULT Update(float fDeltaT)=0; // Updates this GUI (call each frame)

};


Look up virtual classes and pure virtual classes. The trick is that when creating a specialized ''GUI'', one can still use a basic GUI pointer yet use the specialized functions. Making it ''pure virtual'' ensures you don''t accidentally use a simple nonspecialized GUI.


  
class GUIRectangle : public GUI{
GUIRectangle(...){...} // involves coords and color

virtual bool IsOver(int X, int Y){...} //rectangle detection

virtual void MouseEvent(DWORD dwEventType, DWORD dwEventData){...} //depends on implementation

virtual HRESULT Render(){...} //render a quad

virtual HRESULT Update(float fDeltaT){} // depends on implementation

};


Obviously, a circular GUI would be specialized in a different manner than this. But keeping a list of GUI pointers, one can do this (with RTTI active):

GUI *ptr[2];
ptr[0]=new GUIRectangle(...);
ptr[1]=new GUICircle(...)
ptr[0]->Render();
ptr[1]->Render();

That''s the beauty of inheritance and polymorphism. Don''t be afraid to use it!
Oh, question two is about keeping that list of object as a member... Well, I''d advise that you should expect to -vary- that list a lot according to an active ''scene'' (or loaded level, or whatever). So a manager that can easily handle your variety of game objects, load new lists and possibly reorder them according to godknowswhat might be a better thing than a simple ''member list''.

One last tip: LEARN STL! ^n.n^ And use your std::list with pointers rather than whole objects to save on recopy constructors.

=^.^= Leaders and teachers should remember: It is best to offer others what they Need, not what they Want.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
You''ll want to be careful with linked-lists. Jumping all over memory isn''t good for the cache and very bad if a new page needs to be loaded. Perhaps clever use of a vector would be more in line.

Share this post


Link to post
Share on other sites
Thank you guys. I''m by no means a newbie to OO but I''m very new to game development thus I had to make sure I wasn''t approaching this the wrong way.

Share this post


Link to post
Share on other sites
quote:
Original post by Spacecat
That trick is quite valid in OO programming, in fact it involves polymorphism and specialization.

(Note: in VC++ 6.0 it involves changing a setting in the project to activate ''RTTI information'')

Why does it have to be activated? Never knew this. Oh and where do I activate it?

quote:

Oh, question two is about keeping that list of object as a member... Well, I''d advise that you should expect to -vary- that list a lot according to an active ''scene'' (or loaded level, or whatever). So a manager that can easily handle your variety of game objects, load new lists and possibly reorder them according to godknowswhat might be a better thing than a simple ''member list''.



So you''re saying I should create a manager class which contains the pointer list(s)?

Share this post


Link to post
Share on other sites
Make a typedef, and try both! It''s really not very hard to do. Spontaneously, I would favor a deque over a linked list, because there is going to be much more access than deletion/insertion, but only profiling could tell which one is really faster.

Cédric

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!