Getting Started

Hmm, levels. I can''t say it''s the best approach but being a very object-oriented programmer I have (for a game project our company is working on) developed a fairly simple frame for our ''levels'' which simplified loading/changing levels very much:

class CHighLevel{
HRESULT Init()=0;
void Update(float fDeltaT)=0;
void Render()=0;
DWORD Message(DWORD dwMsgType, DWORD dwMsgData){return 0;}
}; // This is a grossly simplified version

It''s a pure virtual class that works well for a game that looks at the time counter and gives the time difference between the last two frames to the update cycle. (Everything in our game would update according to time advancement, not according to framerate). So every frame we''d have an update with the time difference and a render cycle. Why the message function? Well since this is a pure virtual class, you never know what object you''re really calling thanks to polymorphism. But Message is a common ground to ask a CHighLevel to ''do'' something.

On to levels: ''Levels'' are comprised of a heck of a lot of ''things'' that need updating and rendering, right? Well we''d just hook them all up in a given specialized CHighLevel object, and have a game manager just call the update/render of a single active CHighLevel object. Then to change level, the gamemanager would destroy one level, create and init the other, then set that new guy to get the update/render loops. Easy enough.

About the boxes: Most people would advise keeping -one- Mesh with your box, and several instances each with their own transformation. (All pointing to the same mesh)

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