Jump to content

Roadmap 2014


photo

Recommended Posts

Chiming in here. I don't have a problem with Uniginescript. If you come from a C++ or C# background you should be able to pick up Uniginescript with minimum hassle. That is to say that learning the specific api dwarfs the time learning the language.

It is quite a pleasant language to use other than tooling. To that end I suspect picking an IDE and adding plugins for editing and debugging would be a big step forward.

I am honestly surprised that C# and Java are so popular given that they require bolting fairly large runtimes and neither is designed with soft realtime requirements in mind. I think that Unity has gotten away with it because people don't do large projects in Unity. Perhaps Unreal and Unity combined can whip mono into shape for this perpose.

The advantage of a custom language as I see it is much more control over the performance of the back end side of things. I can see the arguments for a standard language but I also think that this comes at a cost.

 

Link to comment

Hi Danni,

 

your last statement is a nice starting point for a fundamental discussion as I fully disagree :)

 

Unigine script has a value for primarily content-driven use-cases with some scripting needs, but for targeted high-end games/serious application requiring complex engine integration/interfacing/modifications a complete C++ engine interface is definitely a must-have feature. It is ridiculous that Unigine is since 5 years in the process of step-by-step C++ interface extension...also this is a waste productivity for Unigine crew, as they have to implement C++ Proxy classes for every exposed class. If you have the source, look at all the redundant proxy code....

 

Unavailability of a powerful script debugger is high-cost productivity killer for customers with more complex logic requiremens...has been mentioned since years, but no improvement at all...debugging mixed C++/Script code ? I would prefer going to the dentist...

 

At the same time Unigine script has grown more and more complex by trying to imitate full-fledged OO languages. Effect: Unigine crew spends time on own compiler development, bug fixing and optimization (which already has been done for C++ since decades...reinventing the wheel) instead of concentrating on high-end graphics features (the strong point of Unigine engine in its early phase...)

 

My personal feeling (sorry to say this): completely wrong strategy since years...other opinions highly welcome :)

Link to comment

Fair call, marshaling is a pain but as I see it you need it for integration for just about any language (I would be surprised if this wasn't the case for C#).  Of course Unigine could go pure C++, is that what you are suggesting?

My main point though is that the objection of having to learn a new language is a moot point. For me Uniginescript functioned more or less like C++ without the bits that make C++ programming painful and built in functionality for the stuff you would expect to see in a game engine. It is not dissimilar to learning Qt in that way. I can point to point to maybe 2 instances over the last 7 years where I got stuck because I didn't understand a language feature other than that picking up the language felt very organic.

In my own personal fantasy world I would like to see D integration, but I will wait to see if Remedy can do it successfully before pushing it.
D has the properties of functioning reasonably well as a low level systems language and a high level scripting language, It has a syntax very familiar to anybody using a C family language, it produces native code, compiles really fast and is binary compatible with C and mostly binary compatible with C++ meaning that you don't have to marshal (as long as you are a little bit careful with your C++ code).

The downsides are obviously that the language is relatively unknown, immature and the tooling although a lot better than what we get with Uniginescript is still leaves something to be desired (visual studio integration at least is good though). 

Link to comment

Of course C++ and something analogous to Unreal's blueprint system might be enough to keep most people a lot happier than they are now (I still think you would require marshaling or something of equivalent effort).

Link to comment

Unavailability of a powerful script debugger is high-cost productivity killer for customers with more complex logic requiremens...has been mentioned since years, but no improvement at all...debugging mixed C++/Script code ? I would prefer going to the dentist...

 

Absolutely agree.

Link to comment

The incompleteness of the C++ API also resulted in that certain custom extensions that we made were made within the engine project itself rather then as a plugin what would be the preferred way for custom C++ extensions. And in order to combine C++ and UnigineScript components we also had to make certain engine extensions, which work reasonable but not perfect. And debugging code that crosses over the C++/UnigineScript border is painful yes.

Link to comment
  • 3 weeks later...

I would like to ask how does it look with new release? Nice habit to have relase +- each month is not kept enymore (it was huge competitive advantage from our point of view). Is it planned to return to this model, or release period is changed/prolonged forever? If yes, how long is release period now?

Link to comment

Polishing here and there, can't stop.

Frankly, we were to release 2.0 beta 2 last week, but our QA dept said no to the idea.

 

So it is good QA. Far better than "Unity quality" release with hundreds of bugs in basic functionality.

Link to comment
  • 5 weeks later...

Ok I am moving in favour of dropping uniginescript in favour of a more complete C++ API.
Reason being is that I have had more of  a chance to play with D.

interfacing D with C and most C++ is trivially easy. If you want to call a C/C++ function for example you just have to write a function prototype for the C function and tell D to mangle the names the same way that C does.
for example:

extern (C) { int the_function (int a, int B); }

This allows you to directly combine C/C++ code and D code in the same executable.

D compiles a lot faster than C++ and seems to have all the modern conviences that uniginescript has as in (I would be happy to put D in front of anybody I would put Uniginescript in front of while I would be more hesitant with C++).
Having bindings would be nice but I could do it myself if I needed to, I am still waiting for information from a group of people who are using D in a commercial game engine to see if they still have any showstoppers.

Link to comment
  • 3 weeks later...
  • 2 weeks later...

Hello Sirs,

 

I am wondering what the ETA is for the next SDK.

The integration of PBR with DX would be of a massive interest here.

 

As well the terrain improvements and a new water? (was this in discussion?)

 

Cheers. Werner

Link to comment
×
×
  • Create New...