hi guys

i've been learning about d3d11 for a while by following tutorials now. and i am at the point wehre i want to convert all the prototype stuff i put while learning to a super basic game engine(just the structure and basic draw calls etc... no sound, no special effect, no physics, no fancy stuff.).

the problem is i can't figure out a way to lay the design / logic correctly as to my understanding there are two thigns that contradict. i have a game class that should supposedly run game code and contains a graphics class object that would contain the graphics objects... wait what??? so if you have a player "bob" and "monster1" how would they be layed out? would they be graphic objects with pure graphical stuff(geometry, indecies, shaders, constant buffers, graphics methods) or would they be game objects(movement actions, health etc,) if one or other then how should the game class and the graphics class interact in a cleanly way since all the graohical stuff must be affected by game logic?

any helpful comments, resources or even an answer to the question... i take it all with open arms.

thanks.

Usually there are interrelated systems.

They generally have a rendering system that handles all the manipulation of graphics and displays it on the screen. These typically involve graphics models and textures.

They generally have a spatial system, often coupled with a physics system, that handles where things are and how things move. Note that physics models are often different than graphics models.

You have a simulator system that contains game objects and simulates them. Game objects often have references to their graphics representation and their spatial representation, but not always.

There are often many other systems, all loosely related. Large established engines invest a lot of effort to allow reuse of items within systems. These days that means building small components and then attaching them to logical objects. You might build a collection of AI components that can be attached interchangeably to many other objects, you might build different physics components that attach interchangeably, and a collection of steering components that attach interchangeably.

Systems are best designed when you think in general terms and broad verbs. For example, "MoveVertex" is very specific and only applies to some things, "PlayAnimation" more broad and can be applied to almost anything.

Building good systems requires experience. Experience is gained by building bad systems and making mistakes. So don't worry very much about doing things right at this point, go gain some experience.

Building good systems requires experience. Experience is gained by building bad systems and making mistakes. So don't worry very much about doing things right at this point, go gain some experience.

thank you for your advice. while i do believe that i need more experience and when i have dived in more hands on some aspect will become apparaent. i disagree that this is a generally good way of doing things in teh long run. it can take years... tens of years to build something decent using this approach. yes it is an iterative approach which means you continuously improve, but it is too slow and we are all aware of multi-million sofware engineering projects that burned out all their budject and failed because the maintainability and design were flawed to begin with.

rather than figuring out how to bypass a wall by beating my head against it, maybe i should do some research to build on solid theory that has been developed over the years by many people. i am sure you are talking from experience, or perhaps giving me advice to build a fun little project, but my intention are beyond a fun little project. by all means i could be wrong and open to critisism.

but my intention are beyond a fun little project.

a super basic game engine(just the structure and basic draw calls etc... no sound, no special effect, no physics, no fancy stuff.).

Sorry about that, I was going off your description that it should be:

There are many excellent books on game engine design, I recommend reading many of them to gain a broad exposure. There are also thousands of papers presented at various game-related conferences that discuss facets of game engine design.

In that regard there are many books, many conference proceedings, many research papers, many post-mortems, read everything you can find.

For the scope of what you are asking about, have a look over at the C4 engine's architecture overview.

A modern game engine is not a simple thing. There are hundreds of interrelated modules. As this (hopefully showing correctly) linked images shows, the rendering system is just a single minor box among many other very large systems.

if you know of any, could you link to resources online keeping in mind the specific part of the game engine i asked about in the post?

Many conferences make their papers available online, often for a fee. The GDC vault, assorted IEEE and ACM conferences, there are many to review. If you already know a few paper names then CiteSeer may help you find related works. Frequently the paper authors put them on their own web sites rather than behind paywall, so sometimes you can find ways to get them without needing dead-tree or paid editions.

That will still be limiting if you cannot access regular books, but that's one source if you want it.

That will still be limiting if you cannot access regular books, but that's one source if you want it.

you make it sound like this is some arcane area that isn't as well covered as everything else.

Nope, not arcane.

It is ENORMOUS.

Their small summary of C4 above covers 140 major areas of a game engine, and each one of those tiny boxes contain broad topics that are widely researched, many with bunches of PhD thesis and conference reports and commercial tools and more.

It is like asking for a small online tutorial on how to build a 787 airliner, or a small online tutorial on how to build a modern skyscraper, or a small online tutorial on how to build a modern nuclear power plant.

That is why the best advice is still going to be that you gain experience. After you've worked with real engines for a decade or two, and you've read many books and hundreds of articles and hundreds of conference papers, then you'll have enough experience that you can begin to architect a modern game engine.

Until then you can build your own smaller game engines, you can build systems that can integrate with game engines, and you can work with other people to build up parts of modern engines. But the task of actually architecting a major game engine that performs well is an enormous undertaking that requires lots of experts to get right.

It is like asking for a small online tutorial on how to build a 787 airliner, or a small online tutorial on how to build a modern skyscraper, or a small online tutorial on how to build a modern nuclear power plant.

That is why the best advice is still going to be that you gain experience. After you've worked with real engines for a decade or two, and you've read many books and hundreds of articles and hundreds of conference papers, then you'll have enough experience that you can begin to architect a modern game engine.