hm... i think there is some confusion about components.

unity uses objects just like other engines.

this.transform.position = ...

"this" is the current object. i haven't used unityscript yet but probably "this" is implicit there and you can leave it away?

in gamestudio the pendant is "my".

my.x = ...

Now thats a picky non related question which should belong to unity forum lol.

But you can always use Screen.height - Input.mousePosition.y

Though i don't know right now if it's really inverted...


@Ventilator, yes you can leave the "this" away. I never use it.

It's just useful if use it like this way:



But this is not Unity related and you probably know it by yourself anyway.

yes, i just think that leaving away "this" can lead to confusion.

the zen of python:
http://www.python.org/dev/peps/pep-0020/
"explicit is better than implicit."

Kiyaku, it of course is picky, but it took me a lot of time to figure out why rect.Contains() returned wrong values for my mouse position. The worst thing was that it was only a problem for one rect, as all others where kinda mirrored...
What I basicly wanted to express was, that even Unity isn´t perfect even though quite close, as far as I got to know it until now
I also had a bit trouble to figure out that network view system, as I didn´t find much information about it (using the search through the answers stuff and the reference manual thingy), there are some more things which aren´t documented too great. I for example just searched for a way to adjust the speed of an animation. It is actually very easy, but the information on how to do it for just a single animation with example wasn´t really were I expected it to be.
But well, there really isn´t much to complain about

You want to have a character walking on the screen

3dgs

you load a model in the editor
You create an Action in SED :
ent_Animate(my,...);
c_move(my,..);
you assign the Action to the model

Unity3d

you load a model in the editor
you create a script :
transform.Translate(...);
animation.Play("Walk",..);
you assign the script to the model

Truevision3D

The engine supplies a TVActor() class

you instance your model
TVActor myModel;

You load the model
myModel = TVActor.Load(".."):

In the game play you write
myModel.Move(...);
myModel.PlayAnimation("Walk",...);

Are exactly the same stuff for you ? I dont think so

In my opinion TrueVision only allow a true traditional OOP
Unity3d is on Component side, Components are also classes, if it is what you meant
3dgs is something in between
Actions in my opinion are components created by developer
3DGS is probably more flexibile than other engines but I find the code style quite ugly...personal taste of course

yes, it's the same stuff to me. yes, components are just objects attached to other objects.

in unity it's:

this.transform.Translate(...); // "this" can be left away. internally "this" still will be used then.
this.animation.Play("Walk", ...);

or:

someotherobject.transform.Translate(...);
someotherobject.animation.Play("Walk", ...);



in gamestudio:

c_move(my, ...);
ent_animate(my, ...);

c_move(someotherobject, ...);
ent_animate(someotherobject, ...);

if gamestudio used object oriented syntax it would be (that's how it works with my python wrapper):

my.move(...);
my.animate(...);

someotherobject.move(...);
someotherobject.animate(...);



i don't see the big difference to unity there? and i don't think gamestudio is more flexible. the lack of oo rather makes it less flexible in my opinion (or maybe not less flexible but certainly more cumbersome in many situations).

C# together with unity is probably the most powerful solution.

Unity3d and 3dgs are about the same stuff but TrueVision3d game architecture is different
The formers are component oriented engines
The latter an OO engine

And wtf is the difference between

and

?

I quote from " The complete guide to Torque x " by John Kanalakis

Quote

Torque x promotes a new approach to game programming.
Unlike the classic inheritance model,objects share common components that provide reusable functionality instead of sharing a common base class.
For example when an object needs to process collisions, you simply add a collision component.
The aggregation methodology results in more code reuse and less copy and past code sharing "

and again

" Object oriented languages such as C++ and C# promote the practice of inheritance.In this case , new functionality is added to an existing object by deriving a new class and adding the functionality there.
....over Time it becomes increasingly complicated to add new functionality to an existing class hierarchy "

again

" Components are simply packaged element of game functionality.
In Chapter 2 we used the physics, Collision, worldLimits components...
In the following chapters we wil create several additional components from movement components to weapon components to AI components.
Each of this components will be designed to be as generic as possible to add functionality to a wide variety of games "

unquote

I do not know how to explain it better, to me the different game engine architecture is evident

In classic OOP you focus on objects and you add functionalities to your objects
C++ has not been designed for games
Suppose you want to develop a database for a Company
You declare a Class Employee which contains variable such as : id , name , salary etc and functions such as : CalculateSalary() etc
You can instance hundreds or even thousamds employees objects: Mr Smith, Mr John etc

This may not be the case of games

In games it may be better to focus on functionalities , I called them "task" in my previous post
Functionalities can be : Movement, Collision,Physics etc

Of course you must link the components to the objects thus you must use pointers such as "my" or "this" or such pointers may be even implicit