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

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.

Shh guys, you speak to a guy that made the network architecture of the future [media][/media]

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..

Where are we and when are we and who are we?
How many people in how many places at how many times?

[quote name='flodihn' timestamp='1333300720' post='4927215']

• 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.
[/quote]

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.

Shh guys, you speak to a guy that made the network architecture of the future [media]

[/media]

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.

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?

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[/quote]
So is everyone else, what is your point?
[/quote]

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.