I could say Unity is trash, but well it's really non sense even for joking, they are somewhat professinnal behind the scene so ... !

IF i would have to make Mobile games, i won't choose Unity , but Shiva 3D that is really less expensive than pro version of Unity Iphone,and can publish to all mobile patform with indie version !
And it has real possibilities , just by seeing some great games (like some last 3D RPG) !

So you see , not one other is trash, it depends on your goals , points of view and money sometimes also !

Ratchet...This is a ranting forum...really.

Let me rant.

Liam... This is a ranting forum...really.

Let him rant about your rant! If you don't want responses, don't post in a public forum.

But truisms aren't ranting


Or are they? Really not quite sure.

[

you refer to :
Camera.main.transform.Translate(move*Time.deltaTime);

Maybe I misunderstood what you said
Do you mean that the above code is a typical example of an object being manipulated by its own methods ?
If so, nope
It is the direct opposite

In the above code the object is "transform" which is an object of the class "Transform"
the class Transform contains the method Translate()
Unity instance the object "transform" in the background for you

"Camera" is a redundant term you could even omit it

This an example of component based programming

Many 3dgs users find Unity easy to use due to the fact that also 3dgs is an essential "components based " engine

an "Action" is actually a sort of component

The engines you are speaking of are for example Truevision or Leadwerks or Esenthel

Personaly I dont like the ( Unity and 3dgs ) programming style but they have a great advantage over the other ones

They are natural "multitasking" engines , in other words you dont have to code your own threads
This is very important in game programming since the programm must continuosly switch among differnt routines
This is not the case for example of a word processor

In conclusion all modern engines are OO
The main diffrence is between :
Components and non components based engines

The former are (maybe) more efficient the latter more intuitive

I am not experienced with Unity, but manipulating an object through its methods and not direct manipulation of its elements is encapsulation. The complaint is that instead of changing the camera's properties directly, the programmer must call a function to do it. That's encapsulation.

In this case the camera has a "transform", which is being manipulated through its own method "Translate" rather than directly changing/assigning values.

Jibb

Its own methods, of whom ? of the Camera ,do you mean ?
That's the key difference

In a component based engine ,objects do not have their own methods
There are generic methods which are contained in generic "functional" classes such as Transform
The programmer must create a component ( a script) using these classes/methods
Then he must attach the components to the object ( entity)
As you can see there is not that difference between the 3dgs actions and the Unity components

A traditional game engine , for example Truevision, comes with "concrete" classes for example the class Camera containing all the methods which you would expect from a Camera
The programmer must instance an object , ex

Camera cam = new Camera();

Then he can use the methods of the class Camera

cam.Translate();

In my opinion the latter approach is much more intuitive even though the former is more trendy , having also many advantages

Every object in Unity has an instance of the class Transform called "transform", which has methods by which it is manipulated -- this isn't just a convenience, but because we can't access the components within the transform because of encapsulation. This object is manipulated using its own methods and its own methods only -- that is encapsulation. Technically, encapsulation is broken to a degree since we don't call one of the camera's methods to do it, but it still is a level of encapsulation.

Encapsulation and component based programming are not mutually exclusive.

Let me quote the Unity documentation again:The camera has a transform, and we access that component directly rather than through one of the camera's methods (breaking encapsulation to a degree), but we don't manipulate the transform itself except through its own methods (for non-native Enlgish speakers, "it" here refers to the transform, as made clear by "the transform itself"), because presumably its own components (such as world co-ordinates) are private, thus maintaining encapsulation and forcing us to manipulate it through its own methods.

Part of the original complaint was component based (Camera.main.transform...), and part of it was related to encapsulation (transform.Translate(...)).

Jibb

if you don't like to write this camera.main.transform.translate... stuff you can easily add properties that wrap the method calls and which make scripting look more like in lite-c.

Lets make an other example
Suppose you have a human Character , let's call it John
In Unity,If you want to move and to animate it, you must create a script ( component)
where you write

transform.Move()
animation.Play();

then you attach the script to john

transform and animation are instances of the classes Transform and Animation which contain the method Move and Play respectively

A traditional engine supplies, for eaxmple a class Entity
you instance the object john

Entity john = new Entity();
and than you call

john.Move()
john.Play()

Move() and Play() are methods of the class Entity

I suppose that the different approach is evident