27 replies to this topic

[jusCurious]

I am curently having a problem deciding on a broad scope how my game engine will be structured. One important thing that i am looking for is separation of logic and rendering. In order to do this my first idea was to to have a Engine base class and have two composited classes, Logic and Graphics. This all works until i try and implement a state system. I do not like the common state systems that are allowed a single state and use switch cases to decide what to do, so i got the idea of a Screen or Canvas class to encapsulate the rendering of a certain screen along with screen logic. The problem with that is that logic is now under Graphics:

Is there a more elegent/flexible way to implement a Frame or Screen type class that has the ability to handle its own state without having to mix rendering and logic? Would it be fine to implement the array of screens in the Engine and call their logic and Rendering separate?

The other thing i am curious about is, where is it that most game engines store the bulk of game data? In my game i was planning to put the game date in the engine class so all subclasses can be passed a pointer to the game data. Is this the most efficient way of doing this? I have heard quite often that most games use singleton instances for subsystems, is this the best way to declare subsystems and is this the best place to store a game data manager class?

Thanyou for your time
-Ryan

[yckx]

In my initialization, I create an instance of each subsystem which are all owned by the Game object. I also have a State class, and instantiate a State object for each game state I want. The Game object is passed to the State objects in the constructor, and can be queried for needed subsystem interfaces. Each state owns it's own game entities, pushes the ones that need updating to the logic subsystem during Update() and those that need to be drawn to the Graphics subsystem in Draw().

Ideally, the logic system will call lua scripts instead of having hardcoded routines. And I haven't yet implemented Begin() and End() methods for my State class to better handle state changes. But those are the plans.

I hope that gives you some ideas.

Edit: I don't use singletons. I instantiate a Game object, which owns the various subsystem and state objects. The Game object serves as a Service Locator so the states can acquire an interface to the subsystems as needed. In my game loop, I call current_state->Do(), and check to see if I need to change state. The game is small enough that I create each state once at startup, because each one is it's own scene and I didn't want to load/unload a (minimal) level whenever the player opens up the options menu. But I could theoretically create and destroy state objects dynamically as needed.

[jusCurious]

My game is set up similar, i have all my subsystems under the Engine class. You say that your state objects hold all data for a given state and hand the objects to the logic system and Render sysyem every frame? does this mean that your calling a State.logic() and State.Render() call every frame?

-Ryan

Edit: just read your edit and that clarified things a bit, this system seems very similar to my Screen system with screens being under Engine instead of Rendering, Thanks for the help

[yckx]

You say that your state objects hold all data for a given state and hand the objects to the logic system and Render sysyem every frame? does this mean that your calling a State.logic() and State.Render() call every frame?

Yes. In Do(dt) The State object compiles a list of entities with a Logic component, and pushes it to the logic system. Right now, the logic system doesn't do much more than call each entity's Update(dt), but I intend to have the logic component specify a Lua script for the logic system to call. Similarly, the State object compiles a list of entities with a Renderable component and pushes it to the Graphics system, which acquires handles to the various resources needed to draw the entities, batches them, and then calls Renderer::Draw() for each batch. A lot of the hatching process is specific to the game, so it's nowhere near as nicely generalized as it sounds. But I'm working on getting it there.

[L. Spiro]

The same screenshot I posted in another topic may help.


I have 15 modules/libraries. The way in which things depend on other things is entirely logical.

At the bottom you have LSStandardLib. It provides a lot of macros for general use by the entire engine and all other modules, including LSE_CALL, LSE_INLINE, LSE_WINDOWS, LSE_APPLE, etc.
Additionally it provides general-purpose functions such as CStd::StrLen(), etc. These functions can usually be optimized beyond what you will find in the standard C library, but you don’t have to do it.
It also provides CTime, CLargeInteger, CSearch, CCrc, and a few other general-purpose classes that rely on nothing else. It is the lowest level in the engine.


Just above that you have LSMathLib and LSThreadLib.

Next up is LSMemLib. My memory manager. It relies on threads and CStd.

Next up is LSTL, which is my game-oriented replacement for the STL, and it relies on memory allocation. You don’t really need to do this probably, but if you do it would be here.

Next up are LSCompressionLib, LSFileLib, LSNetLib, and LSPhysicsLib. These rely on standard macros/functions, memory allocations, templates, file access, math, etc.

Next is LSImageLib. Textures may use these, but this class has no idea what a texture is. It knows what an image is and how to manipulate and load them. The reason it is not on the next level down is because it relies on LSCompressionLib and LSFileLib.

Next is LSGraphicsLib. It relies on LSImageLib for use with textures.

Next is LSModelLib and LSTerrainLib. They need to render themselves, so they need to know what a renderer is.

Finally LSEngine needs to know what everything in the engine is and how they should be connected. It is obviously at the top.


For ideas on how to manage states and the data in each state, you can read my article about it.
http://lspiroengine.com/?p=351


L. Spiro

[Eric Lengyel]

This diagram of the C4 Engine architecture might interest you:

http://www.terathon.com/c4engine/architecture.php

[flodihn]

This diagram of the C4 Engine architecture might interest you:

http://www.terathon....rchitecture.php

Jesus, that looks like mess.

I used a mix of MVC and three-tier for my engine and it works great. I tweaked it slightly so that the logic is torn out from the controller into its own tier.
Here is some background information, hope that helps:
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
http://en.wikipedia.org/wiki/Multitier_architecture

[L. Spiro]

Jesus, that looks like mess.

What exactly are you expecting from a fairly complex engine?
And where exactly do you think your own engine is headed with just a modified MVC/three-tier system? You might want to think about that.


L. Spiro

[flodihn]

What exactly are you expecting from a fairly complex engine?

I was expected a more visisble structure/code organization, also a decent level of abstraction in something like class diagram, so that you don't 100 classes thrown in your face.
Also, when looking at an architecture, I expect to see some thought behind the design, things I can identify as isolated packages with a purpose. I don't see that in the c4 architecture, just a bunch of managers with arrows all over the place.

And where exactly do you think your own engine is headed with just a modified MVC/three-tier system? You might want to think about that.

Well, with my engine, I am heading towards a tight integration of the game design document and the game code. The modified three tier system is just the way I organize the code, keeping the data, logic and graphics separated.


Also, having a complex system is no excuse for it being an architectural mess. There are tons of faults in the C4Engine class diagram, even if the guys at terathon software seems to be good programmers, they don't have a clue about software engineering.

[L. Spiro]

In general, if you are going to call something a mess, especially twice, you should have something substantial to back your claim.

You called it a mess twice. We are all waiting for your reasons why it is a mess and what could be improved. All you have done until now is call his engine architecture a mess and provide almost 2 whole sentences on your “superior” method, without explaining why it is superior or why the alternative is a “mess”.

You keep data, logic, and graphics separate. Great. That is quite the common practice these days, and I don’t quite see where C4 Engine violates these practices. Why don’t you provide more details on this “mess”, such as where it violates this principal?


I think part of the problem is that you missed the question being asked.
If I walk up and say, “Hey, tell me about game-engine architecture,” and you say, “Use a modified version of MVC and three-tier system,” I would follow by saying, “Well, data, logic, and graphics are always separate. So what about game-engine architecture? Can you tell me about that?”


The point is that people generally appreciate specific examples of anything that is right or wrong.
If you want to talk trash on someone’s engine design you should probably give us some specific examples of that trash to back your case.
If your design is superior you should probably explain the pros and cons of each alternative so that we the readers—but more importantly the original topic starter—can see your side of things and make our own considerations.

I generally get straight to the point and speak frankly, so I will tell you frankly and directly that I think you are making your own engine and have your own ideas as to how it should be done, and it somehow offends you when someone else does things differently. You like your way so much you consider most alternatives to be “messy”.
You have twice called C4 Engine an architectural mess and even gone as far as to call the developer(s) clueless in regards to software development, even though you yourself are not a published author (if you don’t understand why I mentioned that, do some research).
You are obviously offended.

My advice: Get over it. You will be so much happier when you don’t think you are awesome.

I am making a next-gen engine too. I am not offended by his architecture and never thought it was a mess even though I wouldn’t do some things the same way. It didn’t offend me that some people might do things differently than I do.

So if I think one way is better than another, I am going to explain why. And that is fairly important on a forum whose purpose is to share knowledge.
If you think you can do that, you are welcome to reply one more time to this topic.


L. Spiro

[flodihn]

In general, if you are going to call something a mess, especially twice, you should have something substantial to back your claim.

You called it a mess twice. We are all waiting for your reasons why it is a mess and what could be improved. All you have done until now is call his engine architecture a mess and provide almost 2 whole sentences on your “superior” method, without explaining why it is superior or why the alternative is a “mess”.

Ok here it goes:

• Looking at the diagram, I don't see that it follows any standard, when I see a non standard diagram I am looking for an legend or some explanation to what for example arrows and, boxes of different color/shape means.
• Looking at top left corner, the "Utility Library", it has 3 green arrows to something called "System Managers", what this means is not as I said not defined, so I have to "guess" it means some sort of abstraction, that things in the "Utility Library" access "stuff" in "System Managers", probably in a very nested way that they could not draw it.
• To make this worse, looking at their "Job Manager" in "System Managers", it has three green arrows pointing down to nothing... I would consider this as an error in the diagram because I can not see what that notation is supposed to explain.
• They have green boxes, which seems to be classes and grey boxes which seem to be something abstract like an event or data. This is even more confusing since some of the classes are connected with arrows to these abstract things.
• Looking at the higher level, they seem to have divided the engine into different layers, such as "Low level library", "System managers", "Base Services", "Large Scale Architecture", "Plugin Modules" and Application".
• So "Low level library" access stuff in "System Managers", which seems a bit wierd since in my world, high level code, like a "Manager" for would call the low level stuff to get brute work done, while keeping the decision making in the "Manager" classes. Here it seems like the "Low Level Library" seems to decide what the "System Managers" are doing.
• Looking the "Scene Graph" in the "System Managers", it somehow has a grey box called "Sound Sources", i wonder what sound has to do in the Scene Graph, in my world, sound sources does not make sense to have in a Scene Graph, perhaps you would want sound objects in there to trigger sounds in relation to events and proximity, but this the architecture does leave the intepretation in the eye of the observer, I really don't feel I am getting the information I want from this diagram.
• The "Resource Packager", "String Importer" and "Sound Player" does not seem to have any arrows connected from or to anything else, are these things even used? I don't understand.
• What is the difference between the green and red arrows?
• What is the difference between the managers in "Base Services" and "System Managers", why is for example "Resource Manager" a part of "Base Services" and not "System Managers".
• Looking at a class like "Physics Manager", it seems to access the "World Manager" which also seems to access "Game", however it also seems that "Physics Manager" accesses the "Game". I can undestand that "Word Manager" access the "Game", but why does "Physics Manager and "Interface Manager" also need direct access to it?
• There are tons of these questions and ambiguties, this so called architeture diagram gives me an idea of the code layout in general, but it does very little explaining how the engine works, which is what I assume an diagram over the architecture should do. For example, saying that the "Low Level Libraries" access the "System Managers", the "System Managers" accesses the "Large Scale Architecture", the "Large Scale Architecture" access the "Application" and "Plugin Models", the "Base Services" access the "System Managers" and "Plugin Modules" and finally that the "Plugin Modules" access the "Application" tells me just as much of the engine architecture as much and could be depicted on a much smaller package diagram.

I could go on here, hopefully I made my point.

You keep data, logic, and graphics separate. Great. That is quite the common practice these days, and I don’t quite see where C4 Engine violates these practices. Why don’t you provide more details on this “mess”, such as where it violates this principal?

I never made such claim that the C4 Engine does violate practice.

I think part of the problem is that you missed the question being asked.
If I walk up and say, “Hey, tell me about game-engine architecture,” and you say, “Use a modified version of MVC and three-tier system,” I would follow by saying, “Well, data, logic, and graphics are always separate. So what about game-engine architecture? Can you tell me about that?”

No, data, logic and graphics are not always separate, if you played a game that forces you to restart the game because you made some graphical changes, or does not allow you to do some graphical changes while playing, you can be pretty sure the game suffers from mixing graphics either into data or logic.
My modified MVC/three-tier system is basically the high level architecture of my engine, if you go down on a lower level, examining the logic, you will see stuff like a scripting module in inside that, a state manager a number of states etc.
For someone intrested in my engine architecture, I would of course show first the high level design, explaining the purpose of the model, presentation, controller and logic layers and how they interact, and then for each layer show a more detailed view.

The point is that people generally appreciate specific examples of anything that is right or wrong.
If you want to talk trash on someone’s engine design you should probably give us some specific examples of that trash to back your case.
If your design is superior you should probably explain the pros and cons of each alternative so that we the readers—but more importantly the original topic starter—can see your side of things and make our own considerations.

Yes, that would be a good idea, however I am a busy man, so just saying what I could and provided the sources to wikipedia for the OP to read up on the subject him/herself.

I generally get straight to the point and speak frankly, so I will tell you frankly and directly that I think you are making your own engine and have your own ideas as to how it should be done, and it somehow offends you when someone else does things differently. You like your way so much you consider most alternatives to be “messy”.
You have twice called C4 Engine an architectural mess and even gone as far as to call the developer(s) clueless in regards to software development, even though you yourself are not a published author (if you don’t understand why I mentioned that, do some research).
You are obviously offended.

I did not call the developers clueless about software development, I called them clueless about software engineering on very loose basis, perhaps they are awesome software enginners but it does not show on that diagram.

My advice: Get over it. You will be so much happier when you don’t think you are awesome.

I am I just a concerting software engineer. If you think I am being awesome, perhaps you should take a softare engineering class?

I am making a next-gen engine too. I am not offended by his architecture and never though it was a mess even though I wouldn’t do some things the same way. It didn’t offend me that some people might do things differently than I do.

It does not offend me either, but if I think something is wrong, i am not afraid to say so.

So if I think one way is better than another, I am going to explain why. And that is fairly important on a forum whose purpose is to share knowledge.
If you think you can do that, you are welcome to reply one more time to this topic.

L. Spiro

Yeah I agree, I could have explained why I think my architecture is good.

[Kyan]

I could go on here, hopefully I made my point.

Not really. Honestly, reading comprehension and some common sense go a long way. No, it's not a standard UML diagram but the entire thing is pretty self-explanatory at a glance. To name a few:

• Items with "library" in their names are obviously not classes. They're libraries, most likely similar to those YogurtEmperor describes in his post(s) above.
• Items with names like "threads" and "OpenGL (PC/Mac)" are features, not data. Features are grouped around the libraries they reside in.
• The arrows are obviously dependencies. The controller system depends on the input system to tell it what the user has done. The utility library is potentially used by everything as befits something called a "utility library".
• Base services are directly linked with the hardware - they deal with the services the hardware is expected to provide as opposed to an architectural view of a "service".
• String importing is for internationalization.
• Resource packaging is for packaging resources at release. Most people do not bother to fully package test or trial assets.
• Red vs. green arrows most likely denote external dependencies, which is fitting given where they reside.
• Sound sources denote the entry point for the scene graph to manage sound. There are plenty of scenegraphs/game engines that utilize sound in the graph itself (usually as a leaf or a separate node), kindly explain the technical reasons why this is unwise.

The entire diagram is an overview, far more detailed than you'd find in a number of well-published books. I'm completely lost what precisely you find objectionable.

Furthermore, "because I do it differently, neener neener" is never an acceptable refutation. This is a technical forum, use technical arguments. Looking at the screenshots of their project, C4 appears to have done quite well for themselves - I would think the OP would be very pleased to emulate those results even if it meant using an, apparently, "incorrect" diagram.

It is a nice project, slandering them without reason is uncalled for.

I am a busy man

So is everyone else, what is your point?

[Davaris1]

• Looking at top left corner, the "Utility Library", it has 3 green arrows to something called "System Managers", what this means is not as I said not defined, so I have to "guess" it means some sort of abstraction, that things in the "Utility Library" access "stuff" in "System Managers", probably in a very nested way that they could not draw it.

You really don't know what Lists, Arrays, Maps, Strings, Hash Tables, Smart Links, Reference Tables, Graphs and Trees are???

This is basic 101 stuff, all programmers know.

[noizex]

Shh guys, you speak to a guy that made the network architecture of the future http://www.youtube.com/watch?v=1zNAT6ma_dc

Engine has probably the best architecture and most clean UML diagram documentation ever made by a human. I think it gives him full right to call any existing engine complete mess.

Sorry, I just couldn't help it I just don't like wise-guys, down vote me whoever feels offended...

PS. And he probably did it in Erlang which is superior and can achieve things we, C++ crowd, can only dream of. Umm okay, enough sarcasm, I think I said all I wanted concerning flodihn already..

[flodihn]

• Looking at top left corner, the "Utility Library", it has 3 green arrows to something called "System Managers", what this means is not as I said not defined, so I have to "guess" it means some sort of abstraction, that things in the "Utility Library" access "stuff" in "System Managers", probably in a very nested way that they could not draw it.

You really don't know what Lists, Arrays, Maps, Strings, Hash Tables, Smart Links, Reference Tables, Graphs and Trees are???

This is basic 101 stuff, all programmers know.

I was not talking about the lists, arrays, strings etc. I was talking about the three arrows that point from the Utility Class and points to the System Managers.
So my point is still valid.

[flodihn]

Shh guys, you speak to a guy that made the network architecture of the future http://www.youtube.com/watch?v=1zNAT6ma_dc

Engine has probably the best architecture and most clean UML diagram documentation ever made by a human. I think it gives him full right to call any existing engine complete mess.

Sorry, I just couldn't help it I just don't like wise-guys, down vote me whoever feels offended...

PS. And he probably did it in Erlang which is superior and can achieve things we, C++ crowd, can only dream of. Umm okay, enough sarcasm, I think I said all I wanted concerning flodihn already..

No worries, I do not feel offended.

I have never done a network architecture, I have done server/client architecture, however it is not very unique, many people before me have very done very similar designs, EvE online comes to mind.

As for that, my engine (game engine as in client side) has is being refactored into a stand alone product. At the moment, the engine has only requirements in our Software Requirement Document. The software design document will be done hopefully by next month since we are just entering the design phase in our software process.

Erlang is superior to C++ when it comes to writing distributed, scalable and robust server software. However, when it comes to game engines, C++ is far superior to Erlang. Why is I choose Erlang/C on the server and C++ on the client side, it is just a matter of the best tool for the job.

[Eric Lengyel]

I provided a link to the C4 diagram just because I thought the OP might have been interested in seeing how one example of a professional game engine is put together. Nothing more. I'm not telling people that's the only way to do things, and I'm not saying that other solutions are wrong. The diagram itself is just a big picture of how a bunch of different systems are related, and there is nothing exact about it. The green/orange boxes represent large collections of code, and the gray boxes represent features. The green arrows loosely represent dependencies, and the little black arrows simply show where in the engine specific features are handled. Red arrows are the same as green arrows, but come from plugin modules as opposed to the main engine. Arrows that are not connected to anything mean that a collection of code is used throughout the engine and that it would be silly to connect arrows from that box to almost all the other boxes.

flodihn, some of your comments are way out of line, and you've shown a complete lack of respect for people (not just me) who clearly know a lot more than you. I have a Ph.D. in computer science, I've written or contributed to 9 books on the topics of game programming and computer graphics (and my game math book has been a bestseller for over a decade), I designed the graphics driver architecture for the PlayStation 3 (see patent #20090002380), I've worked in the industry for 16 years at companies including Sierra, Apple, and Naughty Dog, I regularly speak at the Game Developers Conference, and I've been running a successful game engine company for the past 7 years where I am the sole programmer for the C4 Engine. The C4 Engine architecture and source code are widely regarded by professional game programmers as some of the cleanest design in existence. Now tell me, exactly what qualifies you to say I don't have a clue about software engineering?

[flodihn]

I could go on here, hopefully I made my point.

Not really. Honestly, reading comprehension and some common sense go a long way. No, it's not a standard UML diagram but the entire thing is pretty self-explanatory at a glance. To name a few:

• Items with "library" in their names are obviously not classes. They're libraries, most likely similar to those YogurtEmperor describes in his post(s) above.
• Items with names like "threads" and "OpenGL (PC/Mac)" are features, not data. Features are grouped around the libraries they reside in.
• The arrows are obviously dependencies. The controller system depends on the input system to tell it what the user has done. The utility library is potentially used by everything as befits something called a "utility library".
• Base services are directly linked with the hardware - they deal with the services the hardware is expected to provide as opposed to an architectural view of a "service".
• String importing is for internationalization.
• Resource packaging is for packaging resources at release. Most people do not bother to fully package test or trial assets.
• Red vs. green arrows most likely denote external dependencies, which is fitting given where they reside.
• Sound sources denote the entry point for the scene graph to manage sound. There are plenty of scenegraphs/game engines that utilize sound in the graph itself (usually as a leaf or a separate node), kindly explain the technical reasons why this is unwise.

The entire diagram is an overview, far more detailed than you'd find in a number of well-published books. I'm completely lost what precisely you find objectionable.

Furthermore, "because I do it differently, neener neener" is never an acceptable refutation. This is a technical forum, use technical arguments. Looking at the screenshots of their project, C4 appears to have done quite well for themselves - I would think the OP would be very pleased to emulate those results even if it meant using an, apparently, "incorrect" diagram.

It is a nice project, slandering them without reason is uncalled for.

I am a busy man

So is everyone else, what is your point?

First of all, why would you emulate someone else design/software? Perhaps for learning?
However, if you want to create a game engine, I suggest that the OP studies C4 Engine, the links I sent and possible other designs, make his own decision what would fit his needs the most, and make a design choice out from that.

If it appeared as I did slander the C4 engine team, it is my bad. However, everyone's designs should be able to stand critique. For example, even if everyone loves Linux, one should still criticize why version 2.6 is 30% slower than version 2.4.

[Davaris1]

I was not talking about the lists, arrays, strings etc. I was talking about the three arrows that point from the Utility Class and points to the System Managers.
So my point is still valid.

From your block comment, you started out by demonstrating, you don't know what Lists, Arrays, Maps, Strings, Hash Tables, Smart Links, Reference Tables, Graphs and Trees are, or how and where they are used. I am not going to explain them to you, you need to take a basic programming class for that. This is stuff everyone knows.

I don't mean to be rude, but its pretty its obvious you haven't the faintest clue, what you are talking about. I am not suprised you don't understand this diagram.

[flodihn]

I was not talking about the lists, arrays, strings etc. I was talking about the three arrows that point from the Utility Class and points to the System Managers.
So my point is still valid.

From your block comment, you started out by demonstrating, you don't know what Lists, Arrays, Maps, Strings, Hash Tables, Smart Links, Reference Tables, Graphs and Trees are, or how and where they are used. I am not going to explain them to you, you need to take a basic programming class for that. This is stuff everyone knows.

I don't mean to be rude, but its pretty its obvious you haven't the faintest clue, what you are talking about. I am not suprised you don't understand this diagram.

I am sorry, the first time the word lists is mentioned, it is in your post, not mine.

Here I quote myself:

Looking at top left corner, the "Utility Library", it has 3 green arrows to something called "System Managers", what this means is not as I said not defined, so I have to "guess" it means some sort of abstraction, that things in the "Utility Library" access "stuff" in "System Managers", probably in a very nested way that they could not draw it.

I think it is pretty clear I am referring to the green arrows as an sort of abstraction thing, and not the grey boxes that is the lists and maps etc.