You are absolutely right in that regard - there's no member methods in 3dgs, because lite-c is not an object oriented language. Still nothing to do with components though.
The approach you seemingly prefer sits between 3dgs and Unity - classes with encapsulation, but with deep hierarchies instead of aggregation.
That used to be the common approach (3dgs doesn't have something like this because it's horribly outdated), until game engines went mainstream, and today, component based approaches are the common way because they empower the non-programmer as creator, be it an amateur using Unity or an artist or game designer at a triple A studio. Most of the time, the people who write gameplay code simply are no educated programmers, so those who are create systems and architectures that enable other people to create stuff without having to struggle with low level code.

I do apologize for this last offtopic post.

If you mean that component based engines are more flexible than traditional ones thanks to aggregation, that's right but just in theory


From my experience as hobbyst game programmer if an engine comes with a reasonable number of classes : Actor - Vehicle - Camera - Terrain - Math - Ray etc and each class contains a reasonable number of methods and variable then you can develop 99.9 % of the games while using an elegant and intuitive programming style

The only real advantage of components based engine is the natural multitasking, you dont need to use threads, not that easy

However higher flexibility and multitasking are important only for large projects
For casual games I dont see any reason for using components, just an horrible code nothing more

Thanks Sivan
at a first glance UE4 architecture seems quite smart

Well yes they are more flexibel, but the core point is they give non-programmers and high level coders/scripters more power to create stuff that's outside the tight specification of, say, given actor and vehicle classes. This is important if you don't want to mix up engine code and gameplay logic.

And how exactly do you get "natural multitasking" with components? Oo

maybe he means coroutines? like wait() in gamestudio and yield() in unity?

for me both concepts can be ok. sometimes the difference isn't that big. but what i don't like that much are extremely convoluted OO hierarchies.

In fact "component"-based system is a better object-oriented style than stacking your classes until the stack collapses

Loose Coupling and Composition are two common practices to keep better code and this works pretty well with "component"-based systems...
Why should i refactor the whole world interaction of a character if i can just replace the fitting loose component with another?

But i think we should move posts related to this topic into another thread, so UE4 discussion can go on here...

a new Unreal Tournament development starts with UE4, for free: https://www.unrealengine.com/blog/the-future-of-unreal-tournament-begins-today

These are great news, let's see how they'll do when it comes to content and community management of such a Project.

As far as I know Unity loops through the Update() functions of all scripts somehow like 3dgs wait(1)

getting back to UE4
It seems rather a traditional oriented architecture
see the code posted by sivan
Maybe many people are not that happy of components

maybe the component system's main purpose is to present a very flexible editor, where artists and non-professional or even non-programmers can assemble complex objects easily, do a lot of simple game logic, e.g. door openings, character control, and other stuff like a complete unique sky and weather system, or trigger started effects by the new Kismet called Blueprint. it makes life really easier and game development faster, not only a toy, and can be combined with C++ classes. unfortunately the C++ programming part is not really well documented currently, only a few starter tutorials are available. so I'm just discovering it very slowly, not leaving my 3dgs stuff behind...

In principle you are right
However you must distinguish between a weather system and a character

The former is stand alone the latter must interact with other entities
This is the weak point of components based system
The code gets ugly and consequentely also the game logic sucks ,in my opinion

The (supposed) advantage of components is flexibiliy thanks to aggregation
Pre made classes can lack some methods and / or be redundant

Getting back ( once again ) to UE4
It seems that the engine comes with pre made classes but the developer can customize them and/or create his own classes
Am I right ?
If so , it would be the ideal compromise