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.

so you're:

1. making a custom engine for a particular game that no off the shelf engine can do?

2. making a generic game engine to compete commercially with the likes of unreal and unity?

3. something else?

in case #1, studying generic engine design will only be of limited use, as much of the way generic engines are designed is due to the fact that they must be generic. IE they do a fair amount of stuff a custom engine doesn't have to and are therefore more complex.

in case #2, studying generic engine design will be time well spent. just don't piss away years of your life only to never succeed in competing with the big boys.

the old school way to learn engine design is trail an error, nowadays its more like buy frank luna's latest book and just copy it. - of course that still doesn't get you a commercial grade engine - but it gives you something you might be able to turn into one.

but my intention are beyond a fun little project.

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

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

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, hopefully this inlines correctly:



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.

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

i'm sorry i wasn't clear enough. it's hard to get across a point that i need only very basic stuff at the moment, yet it will be used or built upon in a larger scope.

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.

books have never worked well for me as i tend to dissect information from online. 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?

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.

it is an interesting picture, but it doesn't help as much as i would have hoped. it just lists the numerous modules that are used in teh overall engine. many of them are not relevant at the moment and / or i should know how to deal with. it is the [graphics + game logic + physics] that i am worried out getting right. although my question is about [graphics + game logic] i assume that [physics + networking] is also interwined in there to modify those vertices at the end of the day. so if i could get a mockup / template of the design focused on my original question, general relating resources or design advice that would be nice.

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.

surely there should be some tutorials and guides that are well received and / or regarded?

you make it sound like this is some arcane area that isn't as well covered as everything else. what is the reason behind you not refering to any free online resources, do people deal with this area the old academic book and paper way and it has been done so up until these times? is the material so complex that only few can cover it? do catfish overlords manipulate people into behaving this way from their deep ocean kingdoms?

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.

true, but then again i asked about this specific(and small compared to all those major areas) core subset of dealing with graphics + game logic objects. i guess you could say that if i don't figure out this myself now, i will keep returning asking about other subsets of teh game engine... this was the one that is actually giving me a hard time compare to others which can be forced down with time and research, i just thought it'd be a good idea to ask people who presumably have done this many many times.

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.

that is sad. while i realise it won't be a day, a week, a month, or even a year.. i don't believe it should be 10-20 years...

whatever the case i guess i have no time to waste and should go practise then.
thanks fob.

if anyone has anything to add, know that i am fanatically watching this thread.