UnigineScript and C++/C# API

[ulf.schroeter]

Sorry to say this, but once again this illustrates that sticking to Unigine script since years is a dead end: it simply wastes enormous amount of limited Unigine work resources for reinventing the wheel...there are endless mature compilers/interpreters with perfect debugging szpport available since years and most professional game developers in the area of simulation prefer c++/c#/java/... anyway

 

Of course it's not possible to drop Unigine script immediately,but a clear strategy is definitely missing or at least is not announced/discussed to/with the Unigine customers...from my point of view one of the biggest faults since years.

 

Most important rule for every commercial company: listen to your customer requirements

[binstream]

Ulf, I personally agree that we need to focus on standard languages, but previously it was not very popular idea inside the development team.

It has finally changed this year (with a lot of other major changes inside the team), so we are moving towards C++/C# APIs now. However, we still need to support UnigineScript at least to keep the legacy code working. I wish we did it earlier, but it's good that we are doing the right thing now.

[p.arrighi]

Hi Binstream,

 

could you please develop this announcement ?

- Does it mean that unigine script will be sooner or later deprecated ? 

- Or simply that you will catch up some gap between C++/C# and Unigine script API

 

We are currently starting new project and we don't want to fall in a dead end using unigine script.

 

Regards

[binstream]

We focus on filling the gap between APIs now.

It is not planned to abandon UnigineScript, however we don't plan to put much resources into its further development as well.

[ivan.cuevas]

I want to share my point of view.

For our needs we feel much more confortable producing with UnigineScript than other languages. Specially in multiplatform development because, it's true we lose a lot of possibilities debugging and editing the code, but in the other hand it gives us some important advantages for us:

• We save a lot of work setting up projects in CMake, SCons and others. We don't have to spent time supporting deifferent configurations for x86, amd64, double, single, etc.
• Usually everything tested in one platform works in the others without modifications (specially in desktop application).
• Very short compilation time compared to the other languages.

We are agree with C++/C# API improvements because it's good to add new features to the engine just developing a plugin, but the scripting language it's one of the best advantages from our point of view, I hope you don't abandon it.

[ulf.schroeter]

Ivan, excellent arguments from a different perspective. Indeed UnigineScript with state-of-the-art debugger would be a different situation, but unfortunately long-lasting feature requests for such debugging support haven't even made it to the Unigine roadmap. But without such debugging support the always increasibg UnigineScript language complexity quickly leads to a maintenance nightmare (=costs) for larger code bases.

[ivan.cuevas]

I think debugging is the main weak point of UnigineScript.

When it comes, Unigine team could consider to develop a UnigineScript debugger as a QtCreator plugin (excuse me if this idea was already proposed). In addition, an excellent integration with the new Qt-UnigineEditor could be achieved in the same way as Unreal/Unity and VisualStudio.

[ulf.schroeter]

I don't think that it's a technical problem. As Denis stated above it's much more a problem of mindset and misperception of real-world customer needs even though there has been continous feedback from users for years. Unfortunately most of this feedback has been ignored (e.g. script debugger) or has been implemented far too slow (e.g. full c++ interface)

 

I am a little bit sorry for my continous criticism, but somehow it's quite frustrating to see that many obvious opportunities for significant technology and business improvements have been missed in the past.