Unity is a dic*

I finally "stress-tested" (wasn't my intention) Unity 3 together with Richi007 and here is our result:

We love Gamestudio. Really!

When I first opended up Unity, it was like "Touch me, drag me, design me, I am so fresh, light and easy to use!". I bought a model from Turbosquid because I knew "Unity is for designer, it basically can import anything!". Well, after 1hr I managed to get the animation from FBX 2010 to Unity (2009 wasn't working, 2011 is to new for the lastest Unity version). Okay, the whole model was black, even if Unity at least showed me the right texture in the "Inspector" on the left side. The animation was named "Take 001" instead of "fly". How to deal with 50 animations from all different models? o.O Anyway, let's go on!

I started to use Javascript because I had the strange feeling, C# isn't that easy in Unity (also if C# itself is great (don't even think about bashing!)). Unity crashes while moving the camera upwards, Unity even crashes while doing nothing (Visual C++ Runtime: Crash -> Unity isn't working anymore -> Close -> Loose progress).

I opended up MED. Chose FBX Import. Selected my Model. Imported it. Skin...Check! Animation...Check!

It just works!

I <3 you, Gamestudio

That's called OOP, it may looks cumbersome at first, but once you get a hang of it, you'll realize that 3DGS could get more benefits from it.

Yeah, Unity su*ks, especially if you get a hang on 3DGS for a long time. Shadow baking takes forever even on simplest scene. Material importing can(or always) get messy, you need to assign each texture to material and you got no clue "which texture is this material".

I guess Unity3D is really for those designers that want to get their design up and running fast, it's like learning in high school, just follow what your teachers said and you'll graduate. 3DGS in the other hand, is more suitable for those who want to take everything deeper. It's like learning in University, here's the books, here's the classes, do whatever you want, learn whatever you want, if you do it right you'll graduate.

Actually that's encapsulation -- a design decision that any object should only be manipulable using its own methods. It's relatively "safe", but sometimes a fella just wants to use good old-fashioned addition on a component he understands.

Jibb

Probably something is wrong on your end. We are using it daily, I released dozens of packs already on their asset store and programmed 2 little games. I imported tens of thousands of models and textures in DAE and FBX, with and without animations.


So you base your experience on one model from Turbosquid, maybe exported with a bad FBX tool? I tested FBX files coming from Lightwave, Modo, Ultimate Unwrap 3d and from many of our artists working with Max and Maya. They all worked, without an exception, old FBX versions as well as newer ones. We have very old files here and they still import into Unity.


First it can be that the diffuse color of the model is black. Change it to white or grey and you will see the texture, that has been already applied automatically.
I guess this is another problem with your FBX.

Also when we split an animation in UU3D into several sequences and name each sequence then all these names and sequences transfer via FBX into Unity. We have all animations already split in one file, perfect and easy workflow. Even Blender can save such sequences in a FBX file.


This is no usual behaviour. It must be a problem on your side. I use it daily and there are hundreds of thousands of developers using it regularly. Most of our customers at Dexsoft are Unity users.
A mere movement of a camera cannot crash it unless there is something badly wrong with your drivers or with your installation.


I am sure, MED does not split the animation automaically into sequences, it also cannot recalculate vertex normals with a smoothing angle of your choice and it does not optionally merge similar materials (using the same diffuse texture).

So really, when working with a hundred models in a pack, it does not just work. It would take me a couple of days in 3DGS. But in Unity I put everything in a folder and let Unity do the work in minutes. I can even create an editor script to re-scale all models during import at once.

And when it comes to serious programming then object oriented code will lead to less code in the end. It might look like you type a couple more letters in the beginning, but later, when you have a more complex system it will be a time and a code-saver.


This depends on your system. On a multi-core system like mine I could bake shadows for a complete level with several sci-fi corridors in just minutes. It takes more time when you change your rendering options to max of course. You have to chose quality setup and texture size as well as your second uv-set wisely of course.


Then something is wrong with your model. When I copy 100 files into a project folder, they all appear correctly with materials and textures applied. All textures using bricks01_d as an example get (optionally) merged to a single material. This is extremely helpful and optimizes rendering in the end. I only drag normal maps to each material, change spec values and a new Unity package is done.

I made models, textures and maps for different engines like Unity, 3DGS, Torque, C4, Leadwerks, Lawmaker, Neoaxis, Vision3d, Irrlicht and UDK. I often got paid for projects like that and dealt with hardcore-users of these engines. We have a customer support at Dexsoft and get feedback from different users. So this is quite some unbiazed information I can give you.
And yes, there is no doubt, that Unity has the best automated workflow. Even the big ones like Vision and UDK cannot beat that. There are things for critics when you compare with Vision3d or UDK, especially when it comes to performance, but the import workflow and the mere number of options and tools is the highlight of Unity.

Of course I just used my own experiences. The model was avaible in FBX, 3DS, MAX and OBJ. I know there are thousands of satisfied Unity users where I am sure they've got great experiences, I just wanted to bash a bit in order to show my Gamestudio love

At the end of the days, I don't care if it is a Unity problem or a problem on my side: Unity messes my things up, MED doesn't.

I don't have a particular problem with the OOP camera code but Unity crashed everytime I tried to assign the camera as var attached : Transform to another script, so this was the only method for me to get it working.


I didn't wanted to bash against Unity more than showing my love for Gamestudio.

This attitude sounds ok for a consumer, a gamer, maybe a guy, who wants to play on a console without any tweaking, it should just work there.

But we are developers, we want to create something. And when there is a problem with a driver or with a missing tool or whatever, then we should be able to look a bit more into that to find a solution, to create games for the consumers. Bashing and ranting is what gamers do in Gamestar or 4Player forums. We are the good guys intelligent enough to look behind the scenes.

That's one thing I love from Unity.


But it still uncomparable to WED's lightmapper.


I exported the model from WED, so, yeah, I guess it's all messed up.

You guys know that A8 also uses an object oriented way, right? Its okay if you write only procedural code in Lite-C but still, A8 uses an OOP approach.

Yeah, the engine uses objects with data structures consisting of data fields, but there are no encapsulated methods, no data abstraction, no polymorphism and no inheritance.

There are tricks you could use to implement class-like behaviour (for example, polymorphism through a struct full of function pointers) but these won't be strictly type-checked. And good luck implementing inheritance through custom vtables.

C, or better Lite-C, is procedure-oriented programming.

[EDIT] I would like to see a real OOP C++ or C# SDK in the feature for A9 or so for Visual Studio, with a wrapper, that exports the functional behavior, so that it is still compatible to Lite-C. And I don't mean a wrapper that adapts on the current engine interface (like that from Stromausfall), I mean a rewrite and a wrapper for Lite-C.

...because it is more powerful.

Unity has a very sophisticated lightmapper, they integrated a professional tool that has been used for games like Mirrors Edge as an example. It renders not only simple lighting, but also radiosity and ambient occlusion. It can use HDR image as light source. I can even do the entire lighting only from textures, where a texture contains light emission channels. For instance some of my sci-fi textures have lights painted in and I have additional glow maps make them bright even when no light is around. These glow maps can be the source to calculate the lightmaps and create amazing soft lighting.

Besides that you can combine shaders and dynamic lights with your lightmaps.

There are way more examples. You can believe me, this technology is far behind the WED lightmapper. Also there will be directional lightmapping in the next release, similar to UDK, Source and Vision. This means that normal and spec mapping will read the lighting directions from the static lightmaps and will be more realistic when moving around.

Also some light probes will be in the next edition that allow to influence moving objects by the static lightmaps. So even a flying object gets correct light, color and lighting direction without a trace to the ground, just by moving through a volume with lighting information attached.

Yep, but I still wish that I can control the lightmapper the way I control WED's lightmapper. I mean, if I was just trying to quick test a scene, not for the final render, I'm hoping that I can turn off all those powerful(and power demanding) stuffs and leave anything basic intact.

Yes, you can do that. I mean, I can do that so you can do it as well. Just watch one of the millions of video tutorials or look into the manual and you will see how easy and how powerful it is at the same time. And when you have a little bit experience with 3d rendering tools like I have, then you will appreciate the power it offers to you, not worse like a big 3d rendering application.

And really, when I bake lighting in a 3d rendering application (still renderer) for a complete level, then Unity calculates it much faster. There are many optimization included.

But when the speed of the lightmapper is your most important issue, then I would suggest to switch to the Vision engine from Trinigy. It is really the fastest, faster than UDK, Unity or whatever, even with cranked up multisampling and other high-quality options. And yes, it is also technological way more advanced compared to WED. You can use directional lightmaps with up to 3 lighting-directions stored and you have cells with volumetric lighting information for dynamic objects.

Maybe I am not cool enough to be a developer like the rest but I prefer to work with programs that are working too. Of course I've read all FAQ's, checked the reference, checked the forums and the file formats. But I don't get the point, why I am a just a gamer because I don't want to fiddle with Unity for hours instead of using a software that works like I want it to.

Taking that quote into account it is quiet funny that you are using Gamestudio

Somewhat

Unity is sucks !!!

well i have checked out unity and all i know is that to make a game on unity would take me two years longer than ong amestudio simply because i would need to re-learn everything.
furthermore i would need to re-socialize with the community there and i am really bad at those things anyway.

i stick to 3dgs because i am lazy. i am sure unity is a great tool but i am just too lazy to adapt...

@spike

no offense here man , but @ every turn you show us how little your "customers" (and i say that loosly) mean to you. learning new tools helps make better games , and i know i would not buy a game from someone who is simply to lazy to learn something new.

and again no offense intended here,i just wanted you to understand how your posts here , can affect your business

I like Gamestudio because you can program a game from scratch without any editor. If your imagination is good enough you can make a game without the need of touching the horrible MED or WED.
In Unity you always have to use the (for my taste, lame) editor with it's stange interface.
I don't like the behaviour approach. I like a clear structure where you always have the complete overview about your project.
I love classes, so I only use the c# wrapper for anny projects.

I like Game Studio. I own two other commercial Engines.
I don't have Unity Pro !

But i don't say :
Hey , i failed to import a model on that engine, so it's trash really !
And sorry but lot of people make games each day with the engine : just browse showcase forums to see all games that are successfully made.
And people are 3D artists, so why don't they have your problems ?

And each engine can have bugs like ALL ENGINE IN THE EARTH !
An engine with 0 BUG DON'T EXIST

So come to a more professionnal level : MAKING GAMES !

- Step 1 : Test and buy the engine that suits your goal
- Step 2 : Make a game
- Option 1 : You tried another engine, but you don't like it
or you failed using it : No problem : leave it
or try again, or choose another 3D engine

But don't start saying some professionnal engine is trash when people behind is making a amazing work and with passion

Could it be Torque 3D, Ogre3D, the dead Truevision3D , LeadWerks Engine , C4 engine or other ....

I like a lot A8 , really, so easy to get into , and so much tutorials and great members community indeed

But well saying Unity is bad ... well ... it's an army of developpers behind, with really serious business and multiplatform, consoles , conferences, advertisments everywhere .... Well ...

-------------

I tested UT3 engine, i don't have succed to import a simple model, texture was black ... i made it in 5 seconds in MED ,
so UT3 Engine is really buggy and bad

Don't take it personnaly , i have nothing against you, but learn to be relative, don't be hard with others.

They sell an engine, lot of games are made wih it, they have a demo !they have a free version !
You like , you use !
You don't like , you pass, they have nothing to do and zero interest with a customer that don't like their engine
They would just say :"Go and use whatever you like we have our own business to manage !)

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

Yes, there is a difference. I don't know what you're saying, though. I previously thought you were saying I was wrong in saying that one of the differences between "camera.x += 1*time_step;" and "Camera.main.transform.Translate(move*Time.deltaTime);" is that the latter demonstrates encapsulation, the use of which is not intrinsic to Object Oriented programming.

Now it appears you just want to explain components. That's great, but why quote me?

Jibb

camera.x += 1 * time_step;

but this can also be encapsulated in modern languages that support properties.

http://msdn.microsoft.com/en-us/library/x9fsa0sw%28v=vs.80%29.aspx

First of all for encapsulation I mean :

"Encapsulation is the process of combining data and functions into a single unit called class "

If so

Camera.main.transform.Translate(move*Time.deltaTime);

It is not, in my opinion, a case of encapsulation

Translate is combined into the class Transform (Upper case)
transform (lower case) is some how similar to the pointer "my" which is used to link the method Translate() to the Game Object Camera

In other engines Camera is a class which encaspulate all the camera related data and methods , such as Translate()

This is a very limited view of encapsulation, from what I've been taught.

Encapsulation can be broken in some languages. Consider the use of an Abstract Data Type in C, for example. The programmer/client shouldn't have to worry about how something is done, just that it gets done. You might implement linked lists and provide a "lLists.h" with headers to a whole bunch of functions you've written to manipulate your linked lists. The client should never open "lLists.c", nor be aware of how they are implemented, instead interacting with them only through the functions whose prototypes are provided in "lLists.h". This way, the implementation can be changed (to be more memory efficient, speed efficient, remove bugs, etc) without affecting the client in the slightest. When you manipulate its values directly, you "break encapsulation", and implementations of the same ADT are no longer necessarily interchangeable.

Object oriented programming languages like C++ and Java often provide means to enforce encapsulation (private), but encapsulation isn't restricted to OO languages.

Jibb

Well I am not professional programmer so I dont argue with your extended definition of encapsulation

However let's assume that estabilishing a link to an external set of functions is also Encapsulation
What I did not agree was your claim " its own methods "
Nope in component based engines there are generic methods only

Only non component based engines supply methods which are custom made for the category (class) of entities they refer to.

Indeed, "its own methods" was too specific a definition for me to use, as imperative languages don't have objects with methods but it is still a common convention to recognise a relationship between some functions and a data type for the sake of encapsulation.

But I think I still don't understand Unity, or perhaps I don't understand you properly. Perhaps I just don't understand components.

Here is the manual excerpt I quoted before for convenience:The camera (or, in the code example, "Camera.main") has a Transform called "transform", and we call transform's method Translate. Is this not the case?

It appears to me that any and all objects in Unity have an object in them called a Transform that, in the rendering pipeline, will be called upon (likely through more of the Transform's methods if they maintain encapsulation) in order to construct the matrices of each object. The same would happen during physics calculations.

I'm not sure I understand component based programming, but it appears to me that it is a paradigm dependent on object oriented languages by which objects are constructed from many other pre-fabricated objects, but those objects still have their own properties and methods.

Jibb

Components in traditional programming are not just objects, they are more, like a motor/engine is a component of a car, like a potato is a component of your soup, like a printer is a component of your office hardware. A component is often built from many objects, functions, data and whatever belongs to do a certain job. It can be replaced (new printer in your office, new engine in your car). It has a predefined interface. It is similar to an object but often bigger and often comes with wrappers. So many software companies sell the same component working in many program languages.

But in game development components are also often used to get a higher grade of flexibility. They split components into smaller units. They dont add everything into classes but often use components to add certain functionality on the fly to each object/class where it makes sense. This is not as easy and not as comfortable as when you work with classes who use their own built-in methods. But it can be more flexible and classes are more leightweight, have smaller memory size and thus work better in systems like mobile phones or other low end hardware.

So often, even when we personally dont like a certain style of programming, it still can make a lot of sense why this style exists.

Yeah, potato similes are great and all, but my problem here is this: is component-based programming simply a different style of programming in current languages, or is it an alternative syntactic sugar to classes that relies on it being written in particular "component based" languages?

Because "often bigger" isn't helpful, since there's no standard for the size of objects. "Can be replaced" isn't helpful, because as with ADTs in imperative programming languages, abstract classes are common in OO as well (you might replace an array list with a linked list, but it will make no difference to the rest of your program if you are only interacting with it through an abstract "list" class or interface). "It has a predefined interface" doesn't differentiate it from an object (except that this is perhaps enforced in component based programming [as you implied], but an OO language may also have that requirement and still be useful in a strictly OO paradigm).

Basically, what AlbertoT and I appear to have come down to in our discussion is his position that the phrase "its own methods" does not apply to component based programming, and I fail to see how that can be the case, particularly given the short code example Liam gave in the original post and Unity's documentation regarding Transforms.

It appears to me that component based programming is simply a style you might use when writing in C++, Python, Go, or any number of other OO languages, but you'll still have instances of classes and call their methods.

Jibb

Article about game entities composed by components: http://www.gamasutra.com/blogs/MeganFox/20101208/6590/Game_Engines_101_The_EntityComponent_Model.php

There is nothing special to components in game development, it's just a software design pattern where the goal is to simplify certain tasks just like all other software designs patterns out there.

Components allow your entities to be composed of several parts, where each of them get updated independently, probably by a manager. The goal is to get more modular code where you can plug in and out different sort of functionality and behaviour for your entities.

Could be a HealthComponent, adds health functionality to an object so it can get damaged. Now anything that shoots at that entity will damage it. Could be JumpComponent, any entity who has this component can jump now.

Think of it as an extension.

Just some examples

Yes Jibb this has nothing to do with languages at all, it's just a software design pattern.

Great article, and great response. Thank you, Enduriel

So the answer seems to be that it's a design decision in development (EDIT: confirmed in an Edit I missed on the first read -- thanks!) -- a programming paradigm that is relatively language agnostic (I say "relatively" because it doesn't appear to be a reasonable approach in an imperative language [although technically possible since classes are just syntactic sugar]).

I've never done a course on the OO paradigm, and so I always called any instance of a class an "object" regardless of the paradigm used. It appears objects and components are both instances of classes under different paradigms (or different intentions under the same paradigm).

Correct me if I'm wrong in any of that, but I feel a lot has been clarified for me.

Much appreciated

Jibb

Well I guess you could say that every class is a component (in a way), but not every component is a class.

Actually it is both. But you don't need a special language for that. In Delphi as an example it is similar to a class but you need a few additional data. You need an icon to represent the component in the component palette as an example.

I bought many components. It can be a library of internet functions, it can be a complete word processor or just a zip compression component including reading and writing to files. These components have to work indepentently to fit to each project. So they are some kind of an independent package of a single class or even of a complete program containing many classes or no class at all, except the component wrapper class.

So a component is an external addition to extend the functionality of your software. Game developers often use very small components to even extend single classes while other developers try to use complex components to design a complete software architecture from it, sometimes even for drag and drop programming with the help of a visual editor.

in fact in Unity you can go full programming using C# also.
There are at least two plugin products made by programmers for Unity allowing to make a game using visual components (somewhat like the old Virtools).
It's sepcailly destined to pure 3D artits i think, and there are people asking and buying them ... So ...

In Unity i've seen a comment forpm a 3D artists having very little programming skills, but enought to do some basic things.
He said, if it wasn't Unity pre made templates (third person cameras, collisions controller etc ...) he would never had done so fast it's game to sell it on Apple Store.

In fact Unity is very versatile, allowing 3D artist to produce something fast , and programmers to go deep !
Just my point of view

But i find their mobile licensing too much expensive for the pro version :
Android or Iphone each Pro license asks a lot fo money.
Compared to that Shiva 3D offers Iphone and Android support for one license cost only !

yeah, i wish i could get my hands on an android unity license... im using papaya mobile right now, but its not super full featured.. so for that industry they pretty much rock aside from price.

To explain a bit better the original meaning of compoments in the software industry we also should look back to what Microsoft did with this approach:

"Component Object Model (COM) is a binary-interface standard for software componentry introduced by Microsoft in 1993. It is used to enable interprocess communication and dynamic object creation in a large range of programming languages. The term COM is often used in the Microsoft software development industry as an umbrella term that encompasses the OLE, OLE Automation, ActiveX, COM+ and DCOM technologies."

Just like I already wrote above, it is an external addition to your software and can be written in any language. So I could use an ActiveX in my Delphi program written in C++. I just need a little wrapper around it to define the interface.

You will find similar approaches when you look at component based programming like here:
http://en.wikipedia.org/wiki/Component-based_software_engineering
Web services and service oriented architecture (SOA) are built that way.

In game engines like Vision 3d or Unity it has a lot of advantages as well. So you can add components via their visual editors to any game object. That way you can add functionality like physics, triggers or just a blob shadow via simple drag and drop. So it is again an external addition for an object. The additional functionality is not built in these objects or classes. So these classes are smaller. Not every game object class has to come with complete physics built in.
But the syntax to adress the attached components needs a few more words as when you just adress a built in class. This is what beginners especially in this forum complain about most of the time.

For a professional explanation of components , see the article
My naive game related explanation is the following

Generally speaking, the key difference between a traditional and a components based engine is ,the following :

a) Traditional engine

It supplies a set of "concrete" classes focused on "entities" such as : Camera, Light, Character , Mesh etc
Each class includes methods which are class related

You write

cam.SetRotation() and stone.SetRotation()

whereas cam is an object of Camera and stone is an object of Mesh
The former method is a pitch / jaw/ roll rotation while the latter may be a rotation about x,y,z axis

b) Component engine

It supplies a set of "Abstracted" classes focused on "functionalities " such as : Transform, Animation, Collision
You must write a script (s)( component(s) ) which you attach to the entities in the scene
The methods must be as generic as possible since you dont know in advance what kind of entity they will be attached to

About Unity
A pure component based engine is a nightmare , try for example Torque X ( not to be confused with Torque3d)
Unity is an hybrid to make the engine more user friendly

Camera is a very common entity so it is handled separately

Every entity in the scene has a position, a shape etc thus the class Transform has been added by default

You dont have neither to instance the classes nor to link the component / methods to the entities
Unity makes the job for you

Yes, thanks guys. I believe I understand since Enduriel's very concise response and the excellent article he referred to.

AlbertoT, I see what you mean now -- how even though the components do have methods, they are stateless and manipulate data stored in the Camera itself.

I can see usefulness in components, and can see myself adopting a similar paradigm in future (obviously when using languages other than Lite-C), but probably wouldn't go so far as to use the "generic data bucket" implementation, and instead let each component/sub-object store its own relevant data.

Jibb

I feel akward. I just installed Unity. I even registered at their forums. Thanks guys, thanks

<3

If for awkward you mean "confused" or "worried" or "disppointed" well I am partially with you
I have alwayes been amazed to read that Unity is supposed to be a user friendly engine, for artists
WHATTTTTTTT.........?
First of all component based engines are, in general , less intuitive than traditional ones , moreover Unity,in the attempt to smooth the intricacies of components, made it even more confused
It seems a paradox, but the point is that it is hard to grasp exactly what happen...behind the curtain
Sometime you must simply follow the instruction
I have never been confortable with this , since the old school days

I can understand you. I personally never felt comforable with C++ but yet there are many professional projects around there made with that language. I found object oriented programming at its beginning very confusing, since I already mastered the procedural programming style at that time. But in the end I learned it and found it good in many situations.

I learned so much languages in my life and in the end I realized them as tools to do the job. If I personally feel comfortable or not, the result matters. There are advantages and disadvantages for many approaches and component based programming proved to have many advantages not only in game development.