Help me define which features have been abandoned.

Not at runtime. The built in terrain is too slow to work with at runtime.

 

- Dynamic / Runtime stuff for procedural games ( Lights / GI / Navmesh) - at least rebake apis, runtime doesn't always imply realtime !

- Charactercontroller that's not using a hardcoded gravity vector

 

Has anyone mentioned video playback?

Last time I used it anything more complex than playing a movie file from beginning to end required an unfortunate amount of hacking. Admittedly that was quite a while ago, so maybe it's had some love since. If it hasn't, though, I think it's a prime contender. (Example from memory: You can seek to a new point in the video, but it doesn't update the texture, so you have to tell it to play, but you can't play just one frame. So you tell it to play, wait for one frame in your game, then tell it to pause. Remember though that the video's frame rate probably doesn't match your game's frame rate...)

I think this is going to need some attention anyway, considering Apple's plan to discontinue support for Quicktime for Windows (and Quicktime being required by Unity to use videos).

 

The workflows are also not especially scalable, and the available tools are somewhat limited.

 

I am also a lot for improving upon the character controller (character controller 2D?) and the navmesh also finally being able to work in 2D. Since the navmesh is apparently already being worked on I didn't bother to mention it, though.

Also it's too easy to cross the line from "neglected feature" to "wishlist item", here.
Character controller 2D is probably more of a wishlist item.

 

Which was completely overshadowed by Unreal's own ingame vr editor that allowed you to any of its engine build in tools within the game.. I mean I wouldn't mind being able to access what few ( :/ ) built in Unity editor tools/panels etc from within the compiled game like a God mode of sorts, but doesn't seem to be an easy way to do that without having to build and make it work ingame yourself.

And while I'm at Unity standard provided assets are dissapointing.. like the fps controller doesn't have crouch or was it jump.. I dunno its useless, I'm kinda sick of updating those example assets everytime I grab weekly patches just because Unity hardly does eff all to improve or update any of them anyway.

 

Excellent point and exactly that, when I saw this thread: it feels like here we go again!!
How many of these threads does Unity need?
There plenty of stuff in the RoadMap to be getting along with? no?
Maybe this is a different Unity team in another country and hence communication is not best.

 

Thanks for the info, didnt know about it. One thing to look forward in the future!

 

How did that meeting go?

 

Oh yeah, is NavMesh also specifically tied to the "main" loaded level? I once tried to use it with LoadLevelAdditive and was told by Unity support at the time that I couldn't do it that way.

I don't know if that's still the case because I haven't used built-in navigation for anything major in quite some time.

 

What do you use and what are the pros/cons?

 

Legacy Animation, while does not need any update, wouldn't want to see it disappear. Mecanim is a very welcome set of features, yet Legacy gives you direct scripting control that some of us would miss.

I wished it was named "Classic" Animation or "Basic" rather than Legacy.
Legacy makes it sound like it's a pirate prisoner being pushed towards the ocean full of sharks :-B

Legacy Particles are being swept under the rug already lol

 

Just tell us when and how many pages of ranting you want, and I'm sure the forum will deliver ASAP .

 

Re: Legacy, I think it should be removed. The reason for this is the playables api pretty much duplicates what legacy can do, it's essentially capable of the same feature set. It's for this reason I'd like legacy particles and legacy animation to be removed, but only when the replacements can operate to the same functionality.

Because the more bloated an engine becomes, the harder it is to bug fix and get help. But only if the new versions are just as good obviously... seems like not quite there yet?

 

Eep!!

Actually if/when Mecanim could work in same way as Legacy I'd agree it's pointless to keep Legacy. Though it seemed like the whole point of Mecanim was not having to animate like you do in Legacy.

 

More Neglected Bits

@Matt Roper
I spent this weekend using UE4. It has come a long way and I probably would have used it instead of Unity in the present state, but I had a lot of faith in Unity 5, so I evaluated it quite heavily. It looks like Unity is willing to address a lot of the shortcomings though.

Shadows
I wanted to point out a major disparity between the two engines, one where UE4 has an unbelievably clear advantage: Shadows. In UE4 you can specify which shadows are static, which are dynamic, even tweaking the types of shadow. It's shadows are higher quality AND higher performance than Unity's shadows, and handles long distance without a problem. It also has fantastic capsule-based shadows if you want them (for performance, or if you prefer a diffuse look for outdoors).

I would like a complete performance overhaul for Unity shadows

Physics
And in other cases, UE4 has higher performance physics. They run faster, and do not require fixed update. Instead, UE4 allows sub stepping where needed. This is a much, much nicer design than confusing all your users with legacy Fixed Update. I advocate the removal of FixedUpdate entirely in future versions of Unity, instead keeping physics at the same rate as update or allowing like UE4, to specify the update step per physics object. In 4.11 they also did work to make it much lower level in the engine, and thus faster. You could update your debris at a lower rate for example, than your main player by having a low overall stepping and ramp up the others. Unity's design requires much more coding complexity than UE4's design. Dump Fixed Update.

Animation
UE4 has very fast built in physics-based animation. Engines have had native physics and animation blending since far back as 2009 possibly before. Every major engine now supports blending physics and character animation except Unity. In Unity I have to have two separate rigs, one for ragdoll, one for animation, and a further controller setup. In other engines, it is one rig. In Unity (which has no support built in and thus no optimisations) I have to use partel lang's puppet master and final IK to fill these voids and (no fault of partel's) - it's simply not as good as UE4's nor even on the same page in performance as it is not native to the engine. It definitely should be native to the engine. Blending partial physics with characters is utterly normal in this day and age, and present in all AAA titles.

This isn't a UE4 vs Unity thread, but comparisons do happen for a very good reason. I have omitted mentioning the great parts of Unity because that's not what the thread asked for.

I have more to add but those are major points.

 

From the clunky disorganized rendering pipeline to the lack of proper tools (eg: terrain, splines, oceans, sky, cinemactic tools, you name it) to create modern games faster.
Frankly, I won't bother mention what specific features needs urgent attention in Unity, most systems (if not all of them) requires immediate attention.

 

I've used Aaron Granberg's A* Pathfinding, APEX Path and the navigation system built into RAIN.

I haven't used any of them extensively, particularly RAIN. Of those I used Aaron Granberg's the most and was pretty impressed with it. Easy to use, straightforward, allows runtime generation, offers multiple types of navigation data (navmesh, grid, point network) and, importantly for the project in question, allowed us to cover a huge (though sparsely populated) area.

From memory, the generated nav data is also just data, like any other, and can thus be treated like an asset if need be. That means that you can use additive level loading and it just works. I don't understand why the built-in pathfinding handles this differently, in a way that's both limiting and inconsistent with most of the rest of Unity's workflows. (There may be a good reason, I've not implemented such a system myself to be familiar enough to say.)

Excellent! I have yet to check this out.

 

1. When you click 3D/2D as the player settings sometimes it just randomly picks the other one...
2. When making a canvas it's annoying that I can't just make a worldspace canvas with defaults that make sense for that, it's always like 1000 units wide and I need to play around with the settings. It's pretty clear that it should be 1 or 10 units wide.
3. Shadows are super ugly and slow.
4. Standard shader doesn't have performance options and requires hacking the low performance mobile one to get a higher performance one for PC/VR.
5. VR renderer could be greatly improved with support for vertex displacement and tessellation allowing for full resolution VR with no render textures.(Also fixed foveated rendering option would be great and easier for Unity to add then users)
6. Lighting workflow doesn't just work, it's a pain and requires too much knowledge to get a good looking scene.
7. Unity Events: Need to be able to just drag an object in and it automatically adds a slot for it. It needs to be able to set variables either from a constant value or from another object (IE set material.color to the background color of a camera at runtime). Better ordering of events, it's pretty hard to look through and find what I actually want like if they were ordered with inheritance taken into account it would be much nicer.
8. Terrain, just needs a whole new replacement... but adding support for Enlighten should be done like.. well when Enlighten was integrated.
9. Cluster Rendering: A cool feature, we do real time stereoscopic 360 video capture and also run our game in VR(For gameplay capture) and it's mega intensive so cluster rendering could potentially save us(Or we'll need to add networking)
10. VR Samples, not really in the editor but they just are not very good and could be much better with some more general interaction design(A room scale package would be great with buttons and other interactions as people get this wrong all the time and it's pretty important) Getting a small team to make some good examples of how buttons and leavers and UI and stuff like that can work with Vive/Oculus/PSVR and GearVR/Cardboard would be great.
11. VR Everything... the best way to support VR is just to use the packages from the headset makers and the way Unity has done the support is really not helping. It's also not being communicated when features are added/taken away... The current implementation feels poorly thought out and will be subject to being replaced in a years time.(Sorry for harsh words )
12. The community needs tonnes of work, integrating more with Made With Unity would be cool.

 

To build onto the statement of wheel colliders, there really needs to be an option to disable collisions on joints for them. The Kerbal Space Program guys ended up needing to destroy any wheel colliders that were clipping to prevent phantom forces, which overall, makes their new wheel system even more buggier, and therefore even worse.

Terrain, again, definitely needs a good deal of work. Maybe even giving the ability to make planetary terrain with it? That one's a big if, though. I also think that the water could use a bit of updating. It's not completely abandoned, but it just doesn't work for something outside of YouTube tutorials.

 

The biggest overarching issue IMO with Unity is stuff just isn't game ready/battle proven like the character controller just isn't good for a bunch of games. The FPS controller just doesn't feel nice and isn't robust enough for use in a game.
Over at Epic they have done a pretty good job(not perfect for example I'd not use the FPS stuff they have either) of making everything game ready.

Unity has like 900 employees I really think that they can do a much better job of making robust assets and systems... I think it's just that management doesn't value having an employee spending a year making the perfect FPS controller due to the investment with no direct return. A game studio wouldn't mind at all due to people caring about this stuff when they play a game. What is being ignored that having more robust assets would actually help Unity indirectly via higher quality games being made with the engine.

While I used the FPS controller as an example this is an issue with nearly all the standard assets or Unity created assets from VR samples to the 2D character controller.

 

I don't know if there's much point making a "battle-ready" demo asset, though. Every FPS worth its salt is likely to have some kind of custom character controller, probably built from the ground up. Having a better one in the box won't change that.

That's not specific to the character controller, either. The main area I can see the standard assets being useful in production is with the post process effects (there could be other things too), since with a good implementation it's the settings and parameters that change from game to game rather than the implementation itself.

 

Why? I write my own for nearly everything but I don't think it's the right way. Obviously if you have tens of millions of dollars it makes sense but on a smaller game like walking sims and other first person games why not just use the same one? Not to mention dodgy FPS games that rip off COD or BF could benefit from a more robust FPS controller.
The current one is not even good enough for prototyping as it's just horrible doesn't support moving platforms or anything like that. If you want more complex behaviours like Mirror's Edge then you'd need to extend it but not totally rewrite it, but with the one currently in the standard assets bundle it's just not good.

The 2D character controller is even worse, it's not even worth the time importing. With something like that you want a high quality platforming controller that is easily extendable. Unity has said they are making a new one so hopefully that will be better.

The VR samples are just strange because they are just some sample games that clone games that are easy to clone? Pretty much none of the content is widely usable in other games except for the UI stuff (But that's kind of dated) so it's not even that helpful. The demo package does not even include any locomotion demos and that's the part most people struggle with.

(Full segway into VR here because that's what I work on)
Unity should look at and identify areas developers struggle with and create demo assets that fix those issues. I look at lot's of VR games and the biggest issues people have are locomotion, interaction and attention. Some points that Unity demo material could focus on to fix issues that are widespread in VR development:

• Locomotion, this is one of the biggest issues developers have to deal with in virtual reality, due to players being in a small scale environment on the HTC Vive and Oculus or being limited to rotation on a Cardboard & GearVR. Generally people do the teleport room concept but it's a bit boring TBH and kind of annoying so focusing on how not to do it that way would be good.
• Interaction, I think this is the most important aspect to VR especially with high end VR like the HTC Vive and Oculus Rift + Touch as it's the main interface between the user and the world they are in. Things like pressing a button and you controller stops moving once it pushes it all the way in are not good. Designing with the concept of replication how the user expects an action to work is good I think. Making sure that these interactions update exactly as the controller updates is also important and giving haptic feedback to replicate the actions done by the player are also important.
• Attention, lots of VR games just get boring because you just have to treat the player like such a delicate thing. In a regular game you can shoot the player with rockets and stuff like that and they get screenshake or fly off into the sky and it's all quite exciting but in VR either of these things will make the user sick. The way of solving these issues in games like Aperture Robot Repair are just to focus on dialog to mask the lack of player feedback, but that requires lots of $$$ for audio. Working on fixing these issues is really difficult and Unity could help out a lot by making some demos.

 

It's not like tons of FPS "worth their salt" are being developed in Unity. But all the first person horror games or walking simulators that get thrown onto steam could benefit a lot from a controller that doesn't suck.
But I agree that this ranks pretty low on the list of important things.

 

I'd also like to have a better FPS controller if not just for easier prototyping.
But regarding your argument of "horror and walking sim on Steam" - the plattform is overrun by cookie cutter systems as it is already. If people can just use the default protoype asset and throw another sloppy game in the Steam store ... I don't know. People who have enough know how to make game for steam should also be able to code a better FPS prefab. Otherwise I'd fear for the updates and tech support.

Then again I also don't want to derail this thread into a prefab discussion. Better Prefabs are always appreciated (always!) but I'd really like to see some of the more severe things in this thread first.

 

This.

Vídeo it's been abandoned from 2009 or so.

- Only works on desktop platforms. It needs to work on mobile platforms. Handheld.PlayMovie it's a joke. That it's something that was implemented in one day. We need to be able to integrate videos in a scene.
- We can't seek.
- We can't get current time.
- Dynamic loading of external vídeo sources tied to OGV on desktop and MP4 on mobile. There is no cross-platform vídeo format. That forces us to have 2 instances of a vídeo file.
- Quicktime with serious critical vulnerabilities. We need a replacement.

We need something like AVPro asset in Unity Core.

 

Do I understand that correctly that this means you can set how detailed the physics are on a per object/group basis instead of one fixed update for all objects in the scene?
That sound cool and very useful for a lot of optimization.

 

@Matt Roper I know this isn't a Unity feature (maybe a meta feature for customers )but maybe Unity could work a bit more on keeping us up to date with what is going on? The road map was a great first step!

Came here to also mention the NavMesh (especially 2D) and saw that a lot of people already did. But this is a good example of communication that sometimes irks me.

Here's a timeline on the updates for this:

• The request for 2d NavMesh was made in 2D 2013 (probably around the release of Unity2D but can't exactly remember..): https://feedback.unity3d.com/suggestions/make-2d-work-with-navmesh-and-terrain. Judging by the number of votes (and this thread and a lot of google results), I'm by far not the only one wishing for this.
• In June 2014, Will Goldstone mentions in a tweet that they're working on it: https://twitter.com/willgoldstone/status/475441492124004352
  
• The next update on this I found was an issue opened in April of 2015: https://bitbucket.org/Unity-Technologies/2ddemos/issues/12/navmesh-should-work-in-2d
• In the Bit Bucket Issue Paul Thom writes in July of 2015 that "2D navmesh is being done by the navmesh team. It is probably not called 2D Navmesh. But I believe it is 5.3. Stay tuned."
• Mr. Thom got asked about an update over two months ago but sadly didn't reply yet.

We haven't heard anything ever since (at least my google-fu didn't turn up anything) and it definitely wasn't in 5.3, nor can I even see it on the road map at all.

I don't mind waiting for features. I'm patient. I also get that problems and other priorities can arise at any time. But what I really think sometimes gets neglected (although it isn't an engine feature) is keeping your customers in the loop. It just be nice to get a short update every now and again on how things are progressing; especially if the predicted release time went by without the feature being released.

A simple "Hey guys and gals, sadly feature xyz didn't make it into this release and got delayed because so and so. We won't make any promises but the current plan is to try to get it eleased in release y.z/within the next x months/years."

I think, this would get rid of a lot of the frustrations that arise when much wanted features get delayed for years without a real update.

Also, I'll have to make a shoutout to Mr. Goldstone! When I researched the progress of 2d NavMesh this morning, I dropped a short message to Mr. Goodwill asking about any news and he got back to me incredibly fast, was super friendly and told me he'd check in with the responsible people to hopefully being able to give me an update on the issue. A great customer experience I really appreciate!

Thanks!

 

QA!!! I mean, I know Unity 5.4 is being delayed to fix bugs relating to the 5.4 release, but there are some really old bugs that just stay open for years. And even though some bugs aren't in-your-face showstoppers, they are still kind of a big deal to try work around.

Unity should just release their source code so I can fix the bugs myself. Then I'll sell the bug fixes on the Asset Store

 

nooo do not remove legacy animation! It is soo much faster compared to mecanim. Try animate 200 characters or more in one scene and you'll see!

 

I understand it's faster but this optimisation can likely be applied to playables api, so we need to ask Unity if it's possible it can be optimised to within a good enough margin.

Did your testing happen with an optimised Animator, because it's quite possible to slow it right down passing strings to it and having complex trees.

 

I haven't really been tracking Mecanim since maybe 5.1/5.2 so I'm not sure if this has changed or not, but the main reason I use the legacy animation system is that it allows for more modifiable animations. It's a bit hard to explain in pure concept so I'll give you an example of what I'm working on.

In our game, each weapon type (pistol, rifle, shotgun, sword, spear, staff) has a "move set" that determines the animations that get played and the behavior for certain situations. The MoveSet class uses several tiers of inheritance as the weapons become more complex. ​

The AnimatorOverride is great for switching out what animations are played by the Mecanim graph, but it doesn't allow you to alter the behavior of those states. I'm opening this part of the game up to modding, so players will theoretically be able to create their own weapons and move sets to be used with them so this is something I need to be able to adjust post-build, dynamically.

When last I used Mecanim, most of the functions/properties were not exposed via scripting, which is fine if you're determining everything you need and want before you build the game. Making complex animation behaviors is also difficult as the graphs tend to get tangled and unwieldy as you add more nodes and transitions.

If the animator graphs were optional and everything was exposed via code, I'd have no issues with it. But until Mecanim actually can do all the things legacy can do (add clips on the fly, change mixing transforms/weights/layers/speed dynamically, add/remove/edit animation events at run time) then it wouldn't be the best thing for them to get rid of.

As it stands removing the legacy animation system would effectively destroy our game's animation implementation and force us to start from scratch. Again, I'd be all for it if my concerns were addressed (and maybe they already are, if that's the case please let me know).

Something I have noticed though is a lot of these new systems (sprites/UnityUI/Mecanim) all seem to favor a more static/baked workflow versus a dynamic or modular approach. I'm assuming that's to suit mobile, which is great, I'd just like to see some options for people looking to do things differently.

 

Did anyone say Terrain?!?!

Also, I've seen posted that the TreeCreator has been officially abandoned, and that Unity wants everyone to switch to SpeedTree, but SpeedTree integration still seems like it needs a little work before it falls into the category of "so good that no one will mind we stopped supporting the old trees". Of course SpeedTree is also interwoven with the Terrain engine, so that's a problem too. But SpeedTree is supposed to be, well, speedy, and so far it generally seems much slower than the old tree engine.

Also, CharacterController seems to be woefully abandoned. I think I've seen conflicting posts about whether it has been "officially" abandoned and that Unity wants everyone to use Kinematic RigidBody + Capsule Collider now, but if so, then I think there needs to be more work on the Standard Assets first+third person controllers before officially scrapping the CharacterController.

 

"You could update your debris at a lower rate for example, than your main player by having a low overall stepping and ramp up the others." (((

That note about physics in unreal 4 makes me annoyed now, I have a problem with unity physics and fracturing objects, much of the gameplay and 3d mesh has a broken mesh counterpart that is modeled separately, you can adjust the global step for all physics, but increase it too much and it ruins the smoothness of much of the main gameplay objects and thus the game, while things like fractured object debris which certainly bumps up the total rigidbodies those objects don't need such smooth updates especially not when they've settled on the a surface, that lack of fine tuning that UE4 has now is annoying. My experience of 5.x has had physics performance all the over place aswel.

And the note animation is just another nail in unity, not worth buying these not so cheap assets when the performance isn't there and worse its built in natively in another engine that more than makes up in built in features and performance for some to overlook the lack of an easy to use c# component framework, it starts to be less appealing when you're constantly compromising on the actual game you set out to make in the first place.

 

Yeah you can do that.

Regarding my earlier comments about physics, I wasn't quite correct about some things. I guess the main thing needed are more optimisations really, and more control.

 

Another thing that could use some love is the documentation. All the new features in the last year or so have mostly only been explained on the blog, which I don't remember to read. Half of the documentation for Unity currently only exists in blog posts and forum posts, sometimes with conflicting information from different Unity devs. I'd say any time you guys write a blog post or something it should go into the main documentation as well. Or at least put links to the corresponding blogs in all of the documentation pages.

 

This! Blogs are cool, but they should be supplemental reading.

 

What I tend to notice is that they end up making a couple of good (well, verbose) manual pages, but the API side is barren. EventSystem is an example, last I recall.

 

I tested it with switching between 2 or 3 animation clips, nothing fancy no complex trees.
Even Unity says that the legacy Animation is faster from the documentation:

Playing a single Animation Clip with no blending can make Mecanim slower than the legacy animation system. The old system is very direct, sampling the curve and directly writing into the transform. Mecanim has temporary buffers it uses for blending, and there is additional copying of the sampled curve and other data. The Mecanim layout is optimized for animation blending and more complex setups.

Anyway, before ripping the legacy system out they should definitely try to match the performance of the legacy animation. In my opinion:
Better performance, less bugs > new features.

 

Nested prefabs

Alternative non-legacy graphics setting/mode for mobile/vr/basic/stylised-rendering - not entirely sure on this one but...
Often don't want to use standard shaders and have to turn off all the GI effects and [ignore?] the probe settings on mesh renderers. Then I end up using so-called legacy shaders but they are fine for what they do - simple lighting.

 

Tree Creator must not be abandoned. It's best free alternative to speed tree and so on, so unless SpeedTree becomes free for Unity users, TC needs to stay there.

Unity shouldn't depend on third-party, non-free services for things that they already have code for that just need a bit of updating every so often.

 

I agree but I think half the reason they deprecated their own tree system was because they made some kind of deal with SpeedTree. If there was a super-simplified SpeedTree editor built in to Unity, that just let you swap in and out some meshes or textures, I'd be fine with it. Assuming they finally get those SpeedTree performance fixes in, I think it would look better and would be worth some futzing around to convert trees. But needing to buy a monthly subscription just to change a leaf texture once in a blue moon seems pretty obnoxious. It would be like if they got rid of Mechanim and required everyone to sign up for Mixamo.

 

I guess the input editor man we need like something like rewired native. I wish unity would you know just start buying up something third party devs pay em like a million bucks or something -- you'd get a gold rush of high quality asset store devs and blow unreal out the water.

 

Or like removing Unity materials and require everyone to use Substance, which is exactly my point. Either they change their deal with SpeedTree so TreeCreator can legally output SpeedTrees (SpeedTreeCreator), or leave TreeCreator in, only fixing bugs in it (from what I've seen done with it, it's pretty feature complete IMO) and have SpeedTree as an option for those who want it.

 

Input is already worked on and already support some kind of control rebinding at runtime, but complete control rebinding as I understand it, requires also changes to C++ side of thing.

What I'd really like is Unity buying out ProCore and integrating it into Unity. All of it, not only ProBuilder.

 

The whole Animator needs refactoring I think.
What's the benefit of it being a object not in the scene except for limiting what it can do? IMO Animators should be a regular component and thus have access to anything in the scene without having to get it at runtime... I can only see this being a negative for people who are doing more complicated stuff or any game logic.

This should totally work IMO(character being a object only in the scene)

Code (CSharp):

1. using UnityEngine;
2.  
3. public class KillCharacter : StateMachineBehaviour
4. {
5. public GameObject character;
6. override public void OnStateEnter(animator, stateInfo, int layerIndex)
7. {
8. Destroy (character);
9. }
10. }

Also right clicking a transition should have a "delete" option... having to go to the section within it to remove all options to delete is just sooo counter intuitive.

 

I guess I'm a bit late - but the fact that no one mentioned one specific point I'd consider really important... *shudder*

1. Terrain - I think it has been told enough already

2. Serialization - Especially important for Editor devs; I mean, REALLY important

3. Action-Based Undo - Really no editor devs here? This is truly essential IMO, and not too much of a pain to add for you! I'm working on a hacky reflection-based integration into the default system, really the only thing that does NOT work right now is that the actions (potentially anonymous) get lost on assembly reload. I think it's related to...
... serialization? Wasn't that a point before?

I mean, please! Also, mentioned before - Feedback is total crap IMO. Needs some love

 

Sweet Jesus... I forgot there even was a character controller. Have some mercy here, either update it or put it out of it's misery.


Just look at him. That's the face of someone who just want's it to end. Do the right thing and make his suffering stop.

 

I'd like to see the wiki make a revival.

And I'd REALLY like to see a wiki style entries and links at the bottom of the API and Manual pages. Too often I'll look something up then not understand what it means and have very little to go on. Wouldn't it be great to have stuff right there to further understand it?

Also, you can count me in on the terrain camp. Streaming terrain especially.

Lastly, I'm pretty sure with the NX coming out soon that support for the 3DS is quickly becoming moot. I was shocked that Unity started to support it so late in the life cycle, and I really doubt that any games will be made for it.

Not to be mean, but is there anyone seriously developing for the 3DS with Unity?