Jump to content
  • Advertisement
Sign in to follow this  
cozzie

Engine design v0.3, classes and systems. thoughts?

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

Hi all,

 

Last half year I've been learning D3D11 and I've now decided not to refactor my existing D3D9 engine, but instead develop a new one from scratch (reusing modules/ components where possible). But before I run off and start creating classes, I've made a high over design as a guideline, with the systems and classes I'd like to use.

 

I really like to hear your thoughts on this approach and design.

Any input is appreciated, better now then further in the development process.

 

Side note; the design is a guideline and will be a 'living document' as I progress through development.

?

 

crealysm11_design_v0.1.jpg

Edited by cozzie

Share this post


Link to post
Share on other sites
Advertisement

It's a pretty picture, but at the level-of-detail you've shown it looks basically like any other generic engine high-level architecture.

Share this post


Link to post
Share on other sites
I'm not going to point out the problems in your design but I encourage you to search here on the forums about "game engine architecture". It is also recommended that you read Jason Gregory's Game Engine Architecture book to understand the details of each game engine system.
 
Roughly speaking, for your first game engine I recommend a source tree that looks like this:
 
External (Dependencies)
imgui
PhysX
...
Tools
ModelConverter
ModelEditor
...
Engine 
Core
Allocation
File
Math
Platform
Win32
Linux
iOS
Standard
Template
...
Rendering
GpuDevice.h
GpuContext.h
OpenGL
OpenGL_Device.cpp
OpenGL_Context.cpp
D3D11
D3D11_Device.cpp
D3D11_Context.cpp
...
Animation
...
Physics
...
Audio
...
Game Object
...
Game_1
Game_2
Game_3
...
 
Each module (e.g. Core, Rendering, etc.) being a static library that gets linked into the game. If you're really organized then you might consider using UML's Class Diagrams instead of paint sketches to model the relationship between each system.
Edited by Irlan Robson

Share this post


Link to post
Share on other sites

Agreed, drop the useless C in front of every class.  You will just kill that key that much sooner, what did that key ever do to you?  Plus, every decent editor has intellisense these days.  Forget setters and getters, I prefer my code to read like English.

 

class Window {
public:
    // ...
    // Why do you need Get/Set, it's pretty explicit this way:
    void        Title(const std::string& text);
    std::string Title() const;
};

Share this post


Link to post
Share on other sites

Thanks for the valuable input;

- as for the prefixes, this is and will always be a matter of taste. I'll take it in consideration :wink:

 

@Josh: thanks, this is a good thing, because I've made it myself based on own insights and the d3d9 engine I've created before this.

Regarding high-level, I fully agree; maybe I will make a separate dependencies overview, because combining both will definately not make it better readable.

 

@Irlan: thanks, this helps in defining the systems and what will belong where. I'll definately go for LIB's per system. This also helps readability of the projects further on. I'll also have to create a smooth build proces, because there will never be a moment that a system/ LIB is final :)

I'll think about the UML's, I did this once before, when I made a game with my d3d9 engine, this helped in that specific case.

https://www.crealysm.com/downloads/documents/booh-game-design-final.pdf

 

@Mike: I'm not sure that I can read your example better then a Set/ Get function, but I understand the point, maybe it's a matter of getting used too.

Share this post


Link to post
Share on other sites

Separating out classes based on API like D3dSkybox and D3dLight is something I'd avoid. For example what does D3dLight have that CLight doesn't? It's a structure that has a position+/orientation, colour, type etc. In terms of interfacing with D3D, all you'll be doing is setting some constants or other buffer type - that can be abstracted efficiently at a much lower level. Abstracting buffers and entire blobs of data (buffer + state) makes porting to other platforms much easier too (and fits well with modern rendering APIs).

T

Share this post


Link to post
Share on other sites
Thanks, that's a good thing to think about. For some classes for me this sounds easier then others.

For example, where would you store a mesh's vtx buffer? In my case it's the Cd3dMesh class, because CMesh is API/ platform independent and just an IO/ data thing.

Share this post


Link to post
Share on other sites

Why are you making platform dependent lights, skyboxes, and etc? What is the different between a model drawn in directx and a model draw in vulkan? There isn't one. The whole point of a model is to hold vertex buffers and index buffers, so just make platform specific vertex and index buffers. The same with everything else under CSceneManager. But in reality, you will spend years if you keep trying to make the perfect uml diagram for an engine. You don't know what you need until you need it.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!