Roadmap 2014

[binstream]

Here is the current version of the development roadmap for 2014, there will be definitely a lot of other features and enhancements (most of them are based on your feedback), which are not listed here, as always: http://unigine.com/devlog/

C++ API
- introduction of ObjectExtern - Q1 - delivered
- access to materials and shaders - Q1

Terrain
- >4 layer shading - Q1 - delivered
- improved data import - Q1 - delivered

Mesh formats
- unified format for static and animated meshes - Q2 - delivered
- improved precision - Q2 - delivered
- morph mesh support - Q2 - delivered
- vertex color support - Q2 - delivered

UnigineEditor
- asset browser - Q2/Q3
- UI restructuring - Q3 - delivered
- improved undo/redo support - Q3
- deep integration of Skinner - Q4
- deep integration of Tracker - Q4

Samples
- character - Q1 - delivered
- different vehicles - Q1
- ship - Q2
- helicopter - Q2 - delivered

Mobile version
- improved SDK - Q1
- improved deployment - Q3
- more samples - Q2

Game framework
- FPS sample - Q1 - delivered
- RPG sample - Q2
- RTS sample - Q2 - delivered

Documentation
- how to make custom materials/shaders - Q1 - delivered
- detailed guide on GUI layout - Q1
- revised documentation on tools - Q2/Q3
- a lot of other useful updates - every week

[ivan.cuevas]

Thanks for the road map.

Just two questions, in ship sample , do we shall see effects such as:

 - ship trail projected over the water?

 - bow splahes based on ship speed and collision with water waves?

[nat.harrold]

I am looking forward to this years advancements.

[maimonides]

more terrain textures per map!

[ulf.schroeter]

Just my personal feeling, but except Terrain with more than 4 texture layers additional "killer" features still seems to be somehow missing in the roadmap for 2014...all planned improvements for sure required and appreciated, but were are the next-generation "wow" features ? Already announced render engine refactoring, improved long-distance shadows, virtual textures, full-fledged script debugger, ...., some big "appetizer" still missing

[maimonides]

Mesh morphing, better import, asset browser, ship movement. All good things.

Except mobile.

[ulf.schroeter]

BTW will planned ObjectExtern allow plugin-based extension of UNIGINE core render object model from C++ ?

[binstream]

BTW will planned ObjectExtern allow plugin-based extension of UNIGINE core render object model from C++ ?

 

Yes, it is intended to introduce custom rendering for some specific objects.

[binstream]

Just my personal feeling, but except Terrain with more than 4 texture layers additional "killer" features still seems to be somehow missing in the roadmap for 2014...all planned improvements for sure required and appreciated, but were are the next-generation "wow" features ? Already announced render engine refactoring, improved long-distance shadows, virtual textures, full-fledged script debugger, ...., some big "appetizer" still missing

 

We are considering these features as well, but at the moment there are still some architecture issues to be resolved with the rendering part, so we refrain from making loud promises.

[ulf.schroeter]

Good new !

[steve.brodie]

Exciting times.   After working with tracker a lot last year, Im keen to see some basic functional improvements that will stop artists from exploding.  Primarily undo, flatten bezier handles

and focusing on the selected node when choosing a node to apply a parameter to.

 

Also some enhanced implementation of NPC logic and first person interaction with objects would make 1st person simulation more feasible.

[ernesto.argote]

Hi,

that there the river system simulation?

 

Regards!

[anton.stetz]

what about scaleform integration?

[scott.richmond]

So I assume Unigine is going to stay with C++ and UnigineScript for the foreseeable future? I had hoped to see a C# wrapper in there.

[snow_zhangy]

Hope there is a multiplayer fps game sample

[ulf.schroeter]

So I assume Unigine is going to stay with C++ and UnigineScript for the foreseeable future? I had hoped to see a C# wrapper in there.

 

I don't think it would be a good idea to add additional language bindings as this would further extend the maintenance overhead (as already present due to the support of multiple platforms and render APIs).

 

Even the C++ interface is a wrapped interface which introduces some code overhead (both runtime and maintenance). Nevertheless with latest UNIGINE C++ API improvements usage of C++  for high-performance node/object manipulation and rendering now is a viable and long-awaited option.         

[scott.richmond]

I don't think it would be a good idea to add additional language bindings as this would further extend the maintenance overhead (as already present due to the support of multiple platforms and render APIs).

 

Even the C++ interface is a wrapped interface which introduces some code overhead (both runtime and maintenance). Nevertheless with latest UNIGINE C++ API improvements usage of C++  for high-performance node/object manipulation and rendering now is a viable and long-awaited option.         

 

I don't disagree with any of the above reasons as to why it would be a hard thing to do. But you just can't develop a game in the environment Unigine provides anywhere near the efficiency you can any of the other leading engines, which is why Unigine continues to loose marketshare (At least in the games market). Prototyping and production costs are much higher than that of the other top engines. We're all really just lucky they make truly awesome tech that no one else does (primarily in the sim space). But its a battle they'll loose eventually. And of course the slower they grow the less features we'll see at every roadmap.

[ulf.schroeter]

Scott, your productivity argument is a very good point and this is really a real UNIGINE flaw (I simply have to state it that harsh) which has already been heavly disussed here on the forum since years:

 

missing integrated code editor with syntax high-lighting and auto-completion, missing asset browser, completely inadequate debugging support for Unigine script while the language gets more and more complicated language features, at the same time - at least until latest release - fully insufficient C++ API where at least powerful Visual Studio debugger can be used and C++ usage is in general standard in the game industry, ...., .....

 

All these aspects are real productivity killers for customers (= cost drivers). I think UNIGINE crew knows all of these critics due to continous complains from users here on the forum, but still priority is given to other aspects like support for all kind of plattforms and operating systems and further script language blow-up (UNIGINE script shouldn't be like C++, especially without any usable debugger).

 

I have to admit that this is really hard to understand, especially as more and more UNIGINE resources have to be spend on maintenance, problem resolution and bug fixing instead of cool feature development (focus of most forum posts is a clear indicator for this tendency)  

[scott.richmond]

UnigineScript needs to go. It was a great idea years ago, but not now. Developers don't want custom scripting languages - They're a waste of time to learn and it looks like its just as complex as C++ in this specific case. Since Unity released C# and to a lesser extent Java have become the main languages to develop games with. C++ is still used but only to a much smaller extent with small subsystems being coded in DLL plugins to be used in C#.

That is where 70% of the game developer community are right now. And it will get bigger as I know Unreal 4 engine is looking at doing the exact same thing and moving to C#.

Unigine are asking too much of the developer to write in the environment they give us. The sad thing is that the only reason developers put up with it is because Unigine have unique technology features that their project needs. But how long will that last? Over the past year I've already seen major features get put in other engines. Unity even has a Unity Sim version of their software with special plugins and features.

 

I know the Unigine crew knows all this too. Which is why I was sad to see nothing on the 2014 Roadmap about it. I did however see that they're trying to patch this gap with RTS and FPS demo games. Unfortunately it is a shallow attempt to help developers learn a flawed development environment.

 

I really hope these guys turn this ship around because I fear its heading for rocky waters.

[ulf.schroeter]

Well, good points, although I dont think it's a question of programming language (technology), but general concepts and development focus (strategy).

 

When UNIGINE started their development years ago it seems that one design focus was to provide out-of-the-box materials allowing easy parameter customization but without thinking of customer own material/shader development. Therefore the whole shaders are more or less undocumented. No problem for frustum, as he is used to it since years, but extremly difficult for customers. Also by design the engine wasn't designed for in-depth customer extension e.g. unlike OGRE or Leadwerks engine.

 

Also by initial design UNIGINE scripting was meant to be the only programming environment. I think the key motivation was the assumtion, that this is both more easy and stable, than allowing/forcing customers to use 'traditional' C++ coding with higher probability of screwing things when not done correctly Therefore the C++ API only provided minimal functionality, but never provided complete and practical C++ engine access, forcing customers into much more complex and error prone hybrid C++/Uninge Script coding greatly increasing code complexity and total debugging headaches due to missing usable script debugger.

 

While UNIGINE script engine really is very powerful (except debugging) the concept of a proprietary scripting language might be - as you stated - nowadays in a way obsolete, as there are other powerful interpreter/compiler alternatives (C#/Java). Usage of such environment could provide very powerful development environments/IDE (e.g. Visual Studio/Eclipse) out-of-the-box. At the same time this could for sure free huge amounts of UNIGINE development capacity now used for proprietary script language extension and compiler maintenance.

 

The same is true for the support of all kinds of rendering API and all kinds of different platforms (mobile to high-end PC). Just by having a look into the shaders it is obvious that each shader has to be implemented for OpenGL/ES, DirectX9/11 and in simple/default variant. So focussing is for sure the key to spend limited resources on new feature development instead of overblown code base maintenance.

 

This is especially true as UNIGINE just stated that 80% of their customers are in the professional simulation/VR application field. This simply means absolutely no need for consoles, smartphones, etc and I would also think that Linux, MacOS and DirectX9 support is not really required by these key customers.

 

But of course this is something UNIGINE crew has to decide, which way is the right business approach.

[scott.richmond]

All true. The thing is, you need a niche in the 3D engine world to succeed. Unigine did that and made an engine that had a whole bunch of technology features no one else had on the market. Unfortunately I think that niche is slowly being stripped away from them. More and more sim-specific features are being put into Unity and UDK in their simulation packages. On the game side the feature list Unigine don't have is growing bigger and bigger.

Can these guys keep up? I hope so. But looking at the 2014 roadmap I worry that its slipping away. :/

 

Anyway, good discussion Ulf.Schroeter. All we can do is trust these guys know best what to do. :)

[binstream]

The key question to solve this year is that introducing a new iteration of the engine takes about a year, while we have to support the current technology as well with its legacy. This is number one priority and we are working on the solution, but until we get additional resources we refrain from any loud claims.

 

Anyway, thank you for your feedback, we are on the same page here.

[demostenes]

This is especially true as UNIGINE just stated that 80% of their customers are in the professional simulation/VR application field. This simply means absolutely no need for consoles, smartphones, etc and I would also think that Linux, MacOS and DirectX9 support is not really required by these key customers.

 

 

100% agree. Trying to support everything is what killed Unity3d. Nowdays it is almost impossible to make bigger game on Unity3d without source core, it is very unstable, full of memory leaks and slow.  We re doing PC game on Unigine, so we really dont need mobiles, consoles, macos, dx9 etc. From our point of view mobiles are bubble. If you look at Unity3d, vast majority of published mobiles games there is 2D. So whats the point of supporting this? Better to do less things and well instead of doing everything and loose advantages of fast/stable developement. From out point of view Unigine should stay rock stable/state of art engine for serious (big) games/simulations and leave Unity3d to kids.

[christian.shiel]

100% agree. Trying to support everything is what killed Unity3d. Nowdays it is almost impossible to make bigger game on Unity3d without source core, it is very unstable, full of memory leaks and slow.  We re doing PC game on Unigine, so we really dont need mobiles, consoles, macos, dx9 etc. From our point of view mobiles are bubble. If you look at Unity3d, vast majority of published mobiles games there is 2D. So whats the point of supporting this? Better to do less things and well instead of doing everything and loose advantages of fast/stable developement. From out point of view Unigine should stay rock stable/state of art engine for serious (big) games/simulations and leave Unity3d to kids.

 

Interesting points and agree. Unity3D is not quite so unity at all nor useful to large sim as we found. Furthermore I'm happy to see Unigine have the appetite and ambition.

Still a ways to go however but I think out of any engine I've used so far this is my favourite. With sim there will always be another feature that desperately needs adding :)

[manuel.gysin]

All together Unigine is a good and stable engine. There are some points that decrease productivity, I think a big problem is the small community. If you have a problem there is usually no community response to it or community made tutorials are non exists.

 

I can only speak for the code part of the engine but currently usage is good. Yes, debugging is horrible and a good code completion for IDEs is missing. (extern_info.h does not provide all and is missing type information)

 

Maybe it's because I developed assembler stuff but I like the API and debugging is not that bad. (Back some years the interpreter errors were useless, in the meantime this improved a lot)

 

The biggest problem in my eye is a very poor GUI framework. It took us months to implement something good looking. Things are not scaling well if resolution changed and so on. Currently it's just pita to work with the GUI part.

 

My opinion is that the future should aim primarily to fill the usability gaps and then moving forward to new fancy features.