Is Unity 2017 going to be big or just a new numbering system?

There are lots of beta projects in nearly all aspects of Unity and then there is the 2017 release.

So will Unity 2017 drop big changes in Unity or just be a new numbering / payment / subscription scheme?

What would be the most...

Radical ...
Helpful ...
Amazing ...
Naff ...
Worst ...
Best ...​

... thing Unity could introduce for Unity 2017?​

 

Based on GDC nothing will change except the number from 5 to 2017. Since this is the last month for the remaining perpetual license holders to jump aboard to new versions I would assume they would have shown every possible shiny thing there or in blog posts to get remaining people in the subscription boat.

 

"It costs way too much time and energy for most people to upgrade their projects, and we see no reason to artificially not give you features as they come out just so we could justify a new major version. "

And yet by switching to the yearly versioning people kind of expect each yearly version to actually have the big feature updates.

Bladobe and Autowreck do it, and its lame, infact the only thing I can recall from there versions now is each yearly version is bug infested mess with generally mediocre improvements. Where they break things that worked fine before. Then they get to 2016.5 and the .5 update is usually a bit better. But still broken things to be found, then you have the update1 or ext update.. what a mess honestly

Not saying it can't work maybe Cryengine will catch up with its 5.x releases and we can compare their 7.0 release too what might be Unity 2020 hindsight edition

 

/thread

 

At least you won't be getting two to three years of big features all at once.

 

I like what I've seen so far. Not super keen on subscriptions in general, the only one I currently have being Allegorithmic, but I do like the iterative process Unity is settling into. There are still bugs, nothing is perfect, but they're iterating at a faster pace (more frequent patch & dot releases) than most subscription companies I see.

No company is going to release a perfect bug free product, and the smaller incremental changes introduce less risk. Look, for example, at the people that upgraded from Unity 4.x to 5.0. There were a lot of wholesale changes, broken (reworked) APIs.. and even with the script updater it was a significant amount of work to upgrade projects. Only after all of that work was done did some of them realize there were some showstopper bugs in 5.x.

With an iterative approach, you're hopefully upgrading more frequently, spending less time doing the actual project changes (if any), and it's much easier to abandon the little bit of work to go between dot releases than it is to give up weeks of man-hours to do a full suite release upgrade.

 

The whole point of going to 2017 was to get away from the big release model. So expect nothing big.

The most dramatic thing that should happen is the huge flood of perpetual users claiming they've been cheated on the forums. Including a couple who somehow never knew subscriptions were coming.

There still will occasionally be breaking releases. PhysX will need updating. Graphics cards will be able to handle better lighting models. API will change. But these should be predictable and well telegraphed.

 

IMHO the...

UI/UX could do with some major work, e.g. just look at the size of the menu's now or 3D artists going from blender/<3d package> to Unity's controls.

Unity API, still we have the monolithic MonoBehaviour class with it's array of disparate On<Action>() method calls on top of a GC system that you then have to strap a Pool Management System to... does anyone else just want a PooledMonoBehaviour class or even better a Pooled, Mono, Scripted and Behaviour classes.​

2017 could also usher in a new .net platform with improved game friendly GC.

What about AI, this has to be one of the most lacking areas of Unity at the moment and they did just hire a Deep Learning AI Guru?

 

What you said doesn't make any sense because they don't really do that anyway, its already been how how they intend to keep doing things supposedly.. only now its a year version number scheme.. I can look at 5.0-5.3 as buggy and glad we are past those versions, as it was only 5.4 onwards when things got better in the bug/performance department.

Now when its 2017.x or update x, instead of 5.x, or 6.x...doesn't sound as as good to me..ofc it could be like unreal and go past .10 to 4.15 which yknow when do they get to 5.x at 4.99?

So I guess it gives marketing something new to work with. Ooh 2017.2 is out. or 2017 update 2 this is really good release.. even if it needs to have an extra 3digits to represent the year standing out... see at least with 5.x I can be like well it was only 5.0,5.1,5.2,5.3 that were not so good, while 5.4,5.5 and 5.6 have been good. With the year used in the number scheme it kinda taints all releases in that year if one update wasn't that good. I point it out because I think sticking in a year number on a product while releasing updates constantly over that year doesn't make any sense at all. Where I can look at 5.4 being a good release, I don't expect I'll look at equivalent of a 2017.4 as good.. so to me it makes even less sense than how they do things already, at least a Unity 2017 tshirt covers the entire year and not just a few months

also your uninstallers are broken Unity, my startmenu folder has some remains leftover from past versions where its not removing everything it put on...

http://i.imgur.com/7dY5lAH.png

interestingly can see from 2016 5.3-5.6 was covered.. so about 3 big updates in a year, will that continue?

#if UNITY_2017_1 UNITY_2017_2 UNITY_2018 UNITY 2019_3 ooh great extra numbers to add to the clarity..
#if UNITY_2020 Unity CTO comes down on unite stage in a pair of angel wings high as a kite

anyway its another one arowx topics, they should probably be locked before ppls to start saying things in them, all that matters is good tools and features to use really

 

Sure they do. By "big features" I meant introducing new systems or completely replacing existing ones. Switching from Beast to Enlighten would have been big regardless of whether they used the old system or the new yearly system. Unless they kept them in the code base at the exact same time but that could have introduced it's own problems.

Remember "big release" is not the same as "big feature".

 

They used too. 5.0 came out with

• A change in the lighting engine
• PBR
• An upgrade to PhysX
• Breaking changes accords the API (removal of shortcut methods)

Moving away from this is a good idea.

It's not a marketing push, it's a legal one. Changing the version number gives them a clear end to their obligation to perpetual users.

And the drive to subscriptions is an engineering push, not a marketing one.

 

Maybe.
However, I have to say Unity's support plans for the "final" perpetual version 5.6 are exactly what I hoped for.
Unity 5.6 including all patch releases will be available to perpetual users and a promise to support 5.6 with bugfixes for a 12 month period really is all one can ask for. Thank You, Unity.

Maybe some day the "Special Offer" in the forum header even will link to some nice deal instead of a Sorry page...

 

Most games don't need or want to have deep learning in games, so why would they waste their time\money doing that? I think when the improved path-finding comes in then it will be fine. As a cherry, they could add some basic AI state machine but I would rather leave that up to us to do.

 

Forget it. That hire is for marketing and analytics.
AI in games is one of those areas where you have to know what you're doing to get anything useful, even if the whole architecture is built for you.

 

So he/she could probably help setup a simple AI framework that could provide fuzzy logic, genetic algorithms, neural networks, behavioural trees in an agent based package with a visual node development system without even breaking into a sweat.

 

Most helpful for me at this moment in time would be to remove all obsolete stuff from the manual. I've lost a lot of time as a new user thinking "that sounds like what I want" only to find that it was only in an older version. If something is obsolete, it seems pointless having it in the current manual except maybe on a "Things removed page" that has links for the obsolete stuff to the older manual. I really don't want it teasing and misleading me when all I'm looking for is the current way to do something!

 

Are you sure as I've just searched for Obsolete and only found around a dozen hits in the API documentation?

It should be as easy as adding a legacy toggle to the manual to prevent searches finding obsolete or soon to be API calls.

 

Yeah I'm sure. I tend to browse the API and follow links rather than searching so often find myself on pages like:

https://docs.unity3d.com/ScriptReference/Component-rigidbody.html

which doesn't appear in a search for obsolete!

Not sure if they have all been subversions of 5.5 or whether they went back earlier, but it's sure annoying..

Edit: It's probably not helping my retention being exposed to a wrong and right answer in close succession either. Maybe there's only a few pages I see a lot of!

 

That simply won't happen.
Sure, maybe the new GC comes out eventually... and yeah maybe it will be a bit faster / more efficient.

But I can absolutely guarantee you that you will never be able to skip "defensive programming" (meaning really looking out for what you're allocating).

 

What Unity needs is an incremental GC that can be time/bandwidth limited to prevent GC spikes that hit performance to the detriment of player experience.

Even with a GC bound to 1ms a frame you would still need Unity or your own game to minimise allocations and de-allocations of unused items to prevent your game from overrunning your available memory space or the GC from having to reduce your frame rate.

That's why I think Managed Pools should be built into the Unity API, then the API and developers could tag objects depending on their usage frequency.

For instance a Usage/Recycling/Lifetime scale that helps the GC, this information can reduce GC scanning frequency/bandwidth and aid the GC in deciding what pool of memory the objects should be stored.

It could even be fine tuned from test runs of the game, or dynamically as the game is played via a cloud service.

 

Incremental, generational and multi-threaded GC would be great.

 

Can a GC be incremental and multithreaded? As I understand it even the latest .NET GC hits the entire program in one go, and all threads pause execution during a GC event.

Running a GC through a live heap seems to me to be inviting it's own set of nightmares.

 

The words 'until the end of the 5.x cycle' exist somewhere in the marketing materials. In many jurisdictions marketing materials are as relevant as the EULA. So from a legal stand point a number change is prudent.

I'm not sure anyone would have gone to court over it. But changing the version number is a relatively cost effective way to ensure no one can.

 

I apologize for making you the target of this post, but you happened to be both staff and voicing the exact issue I have with this decision.

I was given Unity 4 educational as part of my degree program. Unlike many developers, my company did not purchase Unity 5 for me. It was not something I purchased using the profits from my current projects. I bought Unity 5 out of my own pocket using what little money I could pull together before beginning to pay off hefty school loans because it sounded promising. Not long after, everything I purchased it for became free. I stuck with it, mostly because the cost would be justified through Level 11 and the hope that Unity 5 would have a similar lifespan to Unity 4. Unity 4, as I am sure you know, was still actively being updated long into the release of Unity 5.

Unfortunately, here we are. I passed up the chance to refund my purchase, have yet to pass the sales requirements for Unity free, and will soon lose both Level 11 and future updates. The idea, in theory, is great. Convenient updates are always a plus. The biggest problem I have is that I am not being left with a complete product. It is something that still has bugs, experimental features, and other issues that don't sound like they fit into "security updates" or whatever the heading for any updates that are absolutely required to prevent legal issues was given.

I do apologize if Unity has finally adjusted the original statement to broaden the description of "bug fixes" to something more than vital and security updates, but I don't see placing a time on such a thing being very realistic. If Unity were confident they could locate and resolve any remaining bugs, the beta program for 5.6 would not be advertised as a way to provide bug reports, but just an early preview of current progress.

What about finishing Unity 5 before moving on to the next sale? You could easily say the subscription benefit is relabeling "patch releases" into something that can be given a price, which sounds to be "only good for marketing reasons" when Unity 5 can't really be called finalized. If it is to be completely halted, shouldn't it at least be complete?

 

You're never going to see completion by this definition. There are simply too many variables in a software product to have every single bug removed. If by some miracle it is achievable it would certainly not be affordable for indie developers.

 

I seriously doubt that, do you know anything about deep learning research and development? Better off ignoring genetic algorithms and neural networks as well.

Hiring a game specific AI developer would be a lot better.

 

Browse his thread history. We've all suggested the same thing at various points.

 

I was starting to think this thread would proceed without anyone taking the bait.

 

LOL Guy's and Girls TLD'R you. I'm talking about basic AI features something a AI Deep Learning Guru would have learnt in their basic training for BSc, MSc, PHd study of AI systems that even simple modular FSM, Fuzzy Logic, Neural Network components combined with a Behavioural Tree or Agent Based system (+visual tool) could provide a great set of tools that designers could use in Unity to make much more believable NPC characters and interactions with.

Throw in a genetic algorithm development kit and you could grow your own cities, dungeons, lands/worlds (low population density).

Check out The Train algorithm an incremental GC with massively reduced GC scanning times it's already been done.

 

​

This. The editor feels clunky and looks seriously outdated, especially on a 4k screen.

 

How does it look outdated? How does it feel clunky?
Nothing wrong with the UI at all in my opinion. I don't want larger controls, its fine like it is.

Genuinely trying to understand what you guys mean

 

I'm not sure how Unity can be blamed for this.

Yes. Incremental and Generational are pretty closely related... There's no reason it couldn't make a pass on a separate thread to identify objects whose links no longer exist. It may miss some things that get released during that process but that's not likely to be a big issue, and if objects have been dereferenced there certainly wouldn't be an issue with clearing them up from another thread as concurrency wouldn't be an issue either.

Where concurrency becomes an issue really is in allocation and compaction of memory. Running it asyncronously would make compaction difficult and would lead to fragmentation of the memory space if I understand correctly how it works. At the very least though, it could run the reference checks asyncronously and only block threads for release and compaction. Especially on Gen1 and Gen2 cycles which happen lesss frequently.

 

See here: https://blogs.msdn.microsoft.com/do...ctor-enhancements-for-client-and-server-apps/

And here: https://msdn.microsoft.com/library/ee787088(v=vs.110).aspx#background_server_garbage_collection

And the TLDR:

 

Me, either. There was really no need to respond if you didn't want to read the post. You are welcome to skip over it.

To clarify the statement, finishing was meant to imply a somewhat high level of stability. A good example of unstable releases would be adding VR features, but breaking skinning on Mac. My fear is that we will hit the deadline, and something as ridiculous as that would be considered the final version. It was good enough to call a release build, but hardly anything from which I could make a release build of my own product.

I purchased Unity 5 under the false belief that pro provided more than just a removal of the revenue cap, but apparently that was a misunderstanding. I did buy the software, but cannot afford to transition into subscribing to the updates simply because Unity decided to rename the version for the purpose of putting a monthly fee on them.

By your definition? Maybe not. I do not expect it to be perfect, but also not just semi-functional. It is hard to say that something I already purchased would not be affordable if that were achieved, given the fact that a past purchase cannot become unaffordable after it was paid.

 

You may not have intended for the post to be taken as if you did, but it definitely read that way.

 

You do realise that under the old perpetual model you would have needed to buy Unity 6 around now anyway. And the cost of 6 would be higher then the current cost of a plus subscription.

 

Additionally, just like every previous perpetual release, Unity 5 would have reached end of life regardless of whether Unity choose to go with a subscription or stick to perpetual. Continuing to receive updates for about six months past the next major release is pretty standard for them too.

 

I don't understand why you would have that "belief". The features are spelled out very clearly on the product page, and more importantly, that was a huge part of the Unity 5 release that all engine features were now the same across the board.

You never, never, never, never, never upgrade your critical software near a release without personal extensive testing and having a critical, show stopping need to upgrade. If Unity adds new VR features, for example, and you are near release, there is absolutely no need to upgrade. A game engine isn't photoshop. The norm is to lock the version you start with through to release. With the rare exception of critical bugs, or hardware eco-system changes. And even then only after extensive testing. I have been on projects that were over 2 years in development, and only upgraded once or twice prior to release, and those usually only to support new devices or device software changes.

 

The feature parity wasn't announced until the actual launch of Unity 5.0. Anyone who preordered Unity 5 did so on the assumption that there was a feature difference.

On the other hand electing not to get a refund was done under full knowledge of feature parity.

 

Right, exactly. The feature breakdown was clearly laid out when Unity 5 launched, and they provided options for refunds for quite a while to address the pre-orders. Pre-orders specified that additional details would be announced at release. Granted the license change was a significant change, and clearly driven by other things going on in the market, but one that was addressed.

 

There will be a MASSIVE feature coming: Scriptable render loop: https://github.com/Unity-Technologies/ScriptableRenderLoop

Will allow people to take Unity's graphics system never before seen heights.