class Level {
public:
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();
};
organizing your level class ???
September 24, 2004 02:36 PM
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:
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
Whatsoever you do, do it heartily as to the Lord, and not unto men.
September 24, 2004 03:06 PM
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
