Jump to content
  • Advertisement
Sign in to follow this  
DarkZoulz

game engine design

This topic is 3954 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 am planning how I should approach designing my engine code. I'm sorry if this has been discussed before, but I can't find much info on this subject. I want to have 3 categories of objects: Entities, Renderables and Resources. Entities are basicly containers for component-type objects that in turn use renderables for drawing. The renderables are objects that use resources to render graphics to the screen. And resources can be graphical assets that renderables use for to draw things. Textures, mesh data, heightmaps etc. I want to use a octree to sort my scene. Is it a good idea to gather a list of renderables from the octree and then send that list to the renderer? This would have to be done each time a renderable changes position, I guess. Any tips or suggestions?

Share this post


Link to post
Share on other sites
Advertisement
The octree and render queue generation should all take place inside the renderer. So the engine simply says "ok renderer, i've told you all you need to know, go render this stuff and tell me when you have the result" (the result is typically had when the function returns, if you're not using multithread).

You have a good idea about how the heirarchy should be. Resources should be generalized and templated. They should be asyncronous. So you can have a reference to this resource but it might not necessarily be loaded completely. So your resource handles should be smart enough to handle invalid or partially valid resources.

Entitys should have a reference to a renderable, the renderable lives inside the renderer and is reference counted. If the engine destroys all references to it then the renderer deletes it. The renderable is your interface for things such as activating submeshes, changing their materials, or querying the model which may contain non instanced data, such as skeletal information.

So your entities are not actively manipulating renderables, they are not submitting them everyframe, they simply persist in the renderer. You only access them when something changes, for example when a renderable is inserted or removed from the scene.

Share this post


Link to post
Share on other sites
Yes, this is somewhat how I envisioned my design :)

The render queue should only be updated when something changes with the renderables. What if renderables need to be updated every frame. Will this be a hugh performance hit? What container is recommended for this? Is it better to use a queue or a vector?

Share this post


Link to post
Share on other sites
What do you plan on using your game engine for? I find that once you have a specific game in mind, the game engine becomes easier to design. Plus it focuses development since you have a definite goal.

After making your first game, use the same source code to kick start your second game. After a few games, you will have a nice game engine to work with.

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!