Jump to content
  • Advertisement
Sign in to follow this  
Luke Miklos

organizing your level class ???

This topic is 5409 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

I was wondering if anybody has some spiffy organization ideas for their Level_Class ? The way I see it, a Level contains Terrain & Entities. In fact... if you wanna get picky about it, Terrain nodes are Entities. The Game_Play_Class only passes the Level_Class user events & updates the Entities & draws the Terrain & Entities (not terrain nodes though). The Level_Editor_Class actually has access to the Terrain_Node_Entities & can pass them user events & update them. So perhaps a psuedo code header file for the Level_Class might look like this:
class Level {
  Level(char*& m_levelFile);
  vector<vector<TerrainNodeEntity>> m_TerrainNodes; //only accessible in the Level_Editor_Class
  vector<Entity> m_GameEntities; //accessible from both Game_Play & Level_Editor Classes
  bool receiveUserEvents(userEvent& e); //mouse clicks/drags & keypresses
  void updateEntities();
  void drawLevel();
  void drawEntities();
  void drawTerrain();  

I guess this assumes that the TerrainNodeEntity class has 3D-space coordinates, texture coordinates, & a normal vector all within itself. Perhaps there is room for other things such as a 2D-array of terrain squares, each having: 2 terrain triangles (each with its own normal), pointers to 4 terrain nodes (that already exist, no duplication) any ideas or suggestions for me as I begin to design/write my first 3d level editor ??? thanks

Share this post

Link to post
Share on other sites
Guest Anonymous Poster
Instead of using a vector for both your entities and worldnode, use a quad-tree. You'll still need an index for quick access from the outside to your entities and worldnodes, but for rendering, collision, and visibiliy a quad-tree will speed execution. Entities should be referenced in the smallest worldnode as possible that they fit in.

As for the editor, if your intent on making one yourself, use a more GUI oriented language such as visual C# (M$ assumption). Or just make your editor in the form of a dll that uses your engine to do graphics. That way your engine is seperate of your editor, but they can still interact.

Reverse engineering another game tool's format is a possibility if your making this program on your own.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!