Maybe but Transform is an obligatory component and thus can't be seen as a component of an object but just a fixed part of it.
In Gamestudio there are similar concepts of "Components", but are called "action" here. Only thing is that those actions aren't really controllable compared to modules / components.
A system with a single class per actor also isn't really viable because it is too limiting. You have to write a lot of code in order to share code between two classes (e.g. an actor. you would need the same code for input in a character, a vehicle, but for NPCs you need a different "input". This is much more complicated than a component based system.)

Imho the best way is to use a mixture of both (In fact, Unity supports such behaviour: Just create a base module for all your classes you want to have for your game and use this as a base class, not MonoBehaviour)

I'm far from having a solid point of view but I can see some benefits on using a not fixed transformation component while it defines the way the draw call data is computed. I mean, imagine a 2.5D render chain where the rotation part of the transformation matrix is specifically computed with a single degree of freedom instead of the three. Would this issue be a noticeable benefit?

It is an obligatory component only for a "component based engine "

If you define a class Actor which contains a variable such as " position " or a method such as " Move " then you dont need to have a class Transform
You simply write, in the Loop() function

myBot.position;
myBot.Move();

instead of attaching a script to myBot :

transform.position;
rigidbody.Move();

You are right 3dgs is basically a component based engines but in the past there were engines with a different archictecture
,ex TrueVision
Having said that , I dont mean that components are bad, I mean that in my opinion they lead to a ugly code

I did hope that UE4 resumed the old fashion programming style

I never even looked at UE4, but from what I read at different places, it seems to be based on classes and inheritance. So you got a base class with some properties, another classes inheriting from it adding some more properties and so on.
But they could still provide a way to also attach components like a physics body or something. Also it could make sense to have a special transform object holding the transformations, so you would still have something like:

As stated before, having actor classes with variables such as you list is fine, but a component oriented design does in fact lead to better code in the long run. Imagine you have another class that needs a position, a move method or similiar, but isn't in any way linked to your actor class so deriving is not an option - that'd lead to a lot of duplicated code. Say for example you want skeletal animations - believe me, you'll love to have a reusable transform class then.

You're right in that it's somewhat strange at first, and the component system was one of the reasons why I didn't like using Unity when I just came from Gamestudio (which imho doesn't have any characteristic of component based design, or any solid design whatsoever), but once you get used to it it does make work easier. A nice balance is good, though - I don't like the approach of stuffing EVERYTHING into components, either, there are cases where inheritance is a better solution.
However, with UE4, if all you want to do is create gameplay logic, you won't have to deal with much C++ anyways.

actually this is the main advantage of component based game engines " over traditional game engines
You attach to an entity just the methods / variables which are strictly needed

The weak point of "components" is the interaction between entities
As I said in my first post, you would accept that it is more elegant to write :

Actor john = new Actor()
Actor Bill = new Actor()

distance = John.position - Bill.position

Rather than in John's script

GameObject Bill = GameObject.Find("Bill")

distance = transform.position - Bill.transform.position

3DGS in principle use components
Have you never been fighting with those bloody void pointers ?
This is typic of components

It doesn't have to be. This is not a problem of component based style but of the strict programming languages:

E.g. you could write similar code with lua:


So you see this is just a matter of language

uhmmm....I have never seen a Unity tutorial made by Unity experts using such coding style
maybe it works but for sure it is not a standard
The interaction among entities is a well known weak points of components

Void pointers have nothing to do with components, they're just a (rather handy) part of C. You can use them to set up a component system in lite-c I guess (as there are no templates in C), but they don't indicate any component based design in the engine at all.

You do have a point about the interaction, that can seem kind of unintiutive, and finding the desired object may even seem like undesired overhead, but I do actually prefer that over having all my objects in a global scope.

Yes they are related items
3DGS is , in principle, a component based engine

"Actions" are components which you attach to the entities in the scene
my is a pointer to the associated entity
you is a pointer to the entity you want to interact with

if you write :

john = GameObject.Find("John");

john is a pointer to the entity john , same as "you" in 3dgs

Same as in all component based engine the interaction among entities is a weak point
Scripts must continuously Exchange information

This makes Unity and even worse 3DGS code so ugly, in my opinion

Leadwerk engine seems to have found the right compromise
It is a mix between traditional and components engines

I wonder whether UE4 offer a similar or even better solution