102
« on: March 16, 2013, 10:27:42 AM »
I have a serious question for you guys and am curious what you think.
Throughout the development of NGUI I have been hamstrung by maintaining backwards compatibility. As I discovered new things to do something (better way to handle events being one of them as an example), I couldn't simply change NGUI as it would break backwards compatibility with existing projects. Because of this NGUI hasn't changed much at its core since a year ago, and the fact that the Free version of NGUI built in May of last year is still able to open projects made with the current version of NGUI is a testament to that.
In retrospect, Unity itself is stuck in a similar boat. When a question is raised about keeping something backwards compatible, or changing it to be much better, the former always wins.
With that said, as many of you know, my work at Unity involves the creation of the "next" UI system -- the followup to NGUI. In order for it to be as awesome as I can make it, I have to make some compromises, such as changing the event system (which in itself will ship separately in a future version of Unity). To give you one example of this, as you likely know one of the events NGUI sends out is the OnPress(bool isPressed) event. The new system sends OnPressEvent() and OnReleaseEvent() instead, which plays better with tools like Playmaker. The new event system also has additional events such as OnDragEnterEvent / OnDragExitEvent, which make it possible to react to the touch sliding off one button and onto another easily. With this event system also being native to Unity (it's built-in on the C++ side), it's also naturally a lot faster as well -- and it even plays well with the OnGUI buttons, in case someone still uses them for debugging.
Other examples of the changes: replacing the UISprite, UIFilledSprite, UISlicedSprite and UITiledSprite with a single sprite that will have an option for how the content is drawn, depth vs Z issue fix, complete replacement of the event notification system (onSubmit, on value changed, etc) with a drag & drop delegate solution, visual placement functionality (drag / rotate / scale widgets with the mouse instead of adjusting inspector properties), and more.
So they are all obviously better systems, but these improvements come at the obvious price of backwards compatibility. I can't simply change NGUI to make use of these changes because doing so will completely break backwards compatibility with all existing projects, and with 100,000+ developers using it today, that would obviously be... quite bad.
Another issue here is -- if I was to make such sweeping changes to NGUI and release NGUI 3.0, simply replacing the existing version in the Asset Store is not a good solution, as there is no way to download an older package when you need it, and I can't possibly force it on all the current customers. Likewise, #ifdefing out the new system is not a good approach either as it would double the code and complicate the $^&@ out of it -- something I am not willing to do. I also can't release it for free either, even verifying an existing NGUI purchases -- processing and verifying 100,000+ requests would mean an insane amount of time which I don't have.
So it would have to be a separate product that people can choose to buy.
And so comes my question. If I was to ditch the backwards compatibility out the window and create a version of NGUI now that would allow developers to easily migrate to the upcoming UI system when it's finally released later this year -- would you use it? And more importantly -- do you believe it would be a viable product for me to invest my free time into?
Personally, I am a bit hesitant about this and am leaning towards a "no", simply because some people will inevitably expect all this work to be done for free... but I am curious about what you guys think.
Yay or nay?