I'm sorry that I'm interested in a toolset which I currently have no time for to explore. To me all this stuff is "just" a hobby.
Of course lite-C is not professional at all and Unity looks interesting because of C#.
But still thank your for explaining everything so detailed. I'll consider checking out Unity when I have some spare time.

I am not familiar in components, but one senior software head from headquarter said we have functions, later we group functions into objects (at this point I understood), then we group objects into packages (?), and findally we have components. I am not sure I am understand fully what he means.

In many programming languages you can find components. They are indeed some packed data and functionality. They often contain code but can also contain other resources like bitmaps, buttons or text. All this is like a black box, could even come without source in many cases. You get an interface to talk with such an component. Many of them even have real-time feedback. I worked with some very advanced ones like a complete word processor. So you can change parameters for behaviour and appearance. You can read values (like the currently selected text) or you can write values (insert a text at the current position). And then you have functionality like saving with just a single call of a method.

To make it short: A component can be very powerful while only exposing a structured and documented interface to you. It often allows to use lots of functionality in a couple of minutes.

I tried Unity , and now I see myself using Unity and leaving Gamestudio.

WHY? Because JCL is too lazy to hire new programmers

Your'e kidding ?




gri

it certainly is advantageous to work with non-proprietary languages like c#, boo, python or lua. they are usable in many other fields and so experience in them is a much more worthwhile skill to have.

with proprietary languages like lite-c, unityscript (it's not javascript!) or torquescript you are totally locked in. they also often can't compete feature-wise because they don't have the same manpower and communities behind them. in the case of lite-c i think the problems mainly are lacking oo and very weak debugging (not even a stack trace, crashes take sed down,...).

Close enough to give you some skills that you can use in normal javascript too. And it`s a good entry level into programming.



I want to make games only. And i want to make it as fast as possible. Javascript for Unity is easier and faster to learn and to use than C# or BOO. And speedwise there is no difference in the result to C# or BOO. So i`m fine with that

Well, SED doesn´t seem to crash anymore, at least it didn´t for me for a long time, but debugging could be improved of course. But doesn´t unity have nothing for debugging other than log messages at the moment? The language in my opinion also shouldn´t matter as you should be able to get the basics of any new language in a few hours if you know one quite well and have a basic understanding of how things work.

The component system of Unity is actually very nice if you just accept it, which is a bit hard if you aren´t used to something like that.
I am probably completely wrong, but currently my following explanation on how it may work was capable to explain me all behaviour and syntax for the work with components, I got to know so far:
The base component is called "GameObject". It has a list where you can add new components to, where each component is the pointer of the components classes instance. If you attach a script component, it always gets the pointers to the other base components set if they exist and otherwize null. Most components actually get this information so that you can easily access another component from each other. If you don´t have such a direct pointer, you can just search for the component in the components array attached to your object using GetComponent().
So you basicly just have those components, can link them together and get reach each other component from each component.
This system is clean, quite comfortable, well organized and basicly usefull for the one working with the editor But it makes you code quite modular and if you aren´t coding modular, it can easily get a bit messy But you often want moduls anyways to be able to reuse code.
I haven´t yet gone into unities shader system, but the editor seems to dislike it if you open windows forms. It crashes most of the time for me, but works well in the published version...

i don't think javascript and unityscript are very close. the syntax may look quite similar at a first glance but javascript is dynamically typed, oo is based on the concept of prototypes and there are many other differences.

WHY? Because JCL is too lazy to hire new programmers

No that's a matter of business, rentability.

3DGS is outdated in terms of interface and tools.
They need programmers indeed to redo all editors and make only one and a modern one.
And with Unity now being free , 3DGS feel very outdated also.
I like it, but i don't feel to spend money for the future commercial version of A8.
In Unity free version, even without shadows you can do lot of things if you use ligthmaps and some blob shadow for characters.

One way fo A7 (future A8) would be to make it open source like Ogre3D and perhaps with a special license to use it ?

Ogre 3D is very powerfull :
Ogre3D user project
It would need a all in one editor to compete with Unity easily.

I think A8 will remain an engine for programmers mainly , and programmers don't mind about workflow or a complete all in one editor !