I didn’t have time to actually break down the requirements into the perfect API I would be interested in, but simply taking my use case, I would suggest adding the following:
auto button = ...;
button->setNormalBackgroundNode(/* Any node whatsoever */);
button->setSelectedBackgroundNode(/* Any node whatsoever */);
button->setNormalForegroundNode(/* Any node whatsoever */);
button->setSelectedForegroundNode(/* Any node whatsoever */);
Using the calls above, the developer can “transform” any node into a button. As long as the boundingBox() property is properly calculated on the node you pass, touches/collisions can easily be detected.
Here is the example from my game (Note that the icon image is separate from the background image):
Normal state:
Selected state:
Now that I think about it, this is very close to the decorator pattern. It think architecting a UI framework with the decorator design pattern in mind will prove extremely useful.
I personally like the way CSS handles transforms, but in my system, I use cocos’ terms and store them in an array. @zhangxm I’m busy with my other games but I’ll post a demo for you guys when I can. The implementation is basically a big factory that reads properties from JSON (with conveniences where possible like hex-string color notation), maps them to a corresponding cc2dx component/property, and applies it.
libRocket is the C++ user interface middleware package based on the HTML and CSS standards. It is designed as a complete solution for any project’s interface needs.
libRocket uses the time-tested open standards XHTML1.0 and CSS2.0 (while borrowing features from HTML5 and CSS3), and extends them with features suited towards real-time applications. Because of this, you don’t have to learn a whole new proprietary technology like other packages in this middleware space.
It’s also using the decorator pattern, which was suggested by Mazyod
I do think leveraging an already popular or commercial solution could be very fruitful. It’s just a matter of whether it’s worth tying ourselves to their API. With things like Spine coming out ahead with strong support, I think it’s worth considering.
No need to reinvent how to do UI, Web standards are there for us to use.
Maybe it will even be possible to use the same tools / UI code for C++ and javascript…
Cross-platform and CMake based is what cocos need I think.
Disclaimer : I didnt know about it, but it definitely looks interesting…
Yep. If it’s working and can be integrated easily into cocos2d-x, it should be used instead of re-implementing the wheel.
@Asmodehn
The only “bad taste” about it is the inactivity for a while now. But someone was suggesting, that they are just busy on their own games.
As long as javascript can deal with RML(there are already .js implementations to generate HTML out of RML), there is no problem to share the tools/UI code between different languages.
CEGUI, who does not know it, was used in some pretty successful commercial games.
Seems to be pretty stable.
Regarding “reinventing the wheel”. Wasn’t it announced, that cocos2d-x is getting a new sound engine?
Same applies here: Is it really needed or is integrating middleware the better approach?
The first sound engine that comes into mind, regarding those requirements, is fmod http://www.fmod.org/
It’s one of the best sound engines/sound middleware out there.
They recently changed their licensing requirements. They now have a FMOD Studio Free For Indies! License – Budget under $100k USD but they have a credit requirement in the docs or on screen.
I don’t know if those restrictions are against a consideration.
Usage: It’s very easy to use. Playing sounds is as simple as with
cocos2d-x now.
Application size: The mobile lib for example is about 1.5MB in size.
Cross platform: Nearly every platform is supported: Windows, Linux,
Mac, iOS, Android and consoles
Enhancement: It has plenty of features. From streaming music over the
net, to DSP effects and 3D sound.
Comes with an editor: Think of CocoStudio for sound/music
Also about UI there is a problem with RelativeLayouts. The example in wiki does not work. Here is the detailed description of the problem: Relative Layouts don't work on cocos2d-x 3.1? Please fix it too.
@iQD
Thanks for the information. fmod is good, but it is not free. And i think it is not problem to use it by yourself. Audio engine is not needed when developing cocos2d-x games. You don’t have to use it if you don’t like it and use the one you like.
@zhangxm I have found the problem with the relative layouts. It is necessary to change layout->setContentSize(visibleSize); to layout->setSize(visibleSize);. Please update the wiki: http://www.cocos2d-x.org/wiki/Containers
Just my 2 cents to the audio stuff: Of course you can’t use fmod because it’s not free but nevertheless the audio part is a big part which is important for developing games. It’s not only the UI what counts. And yes, it’s of course able to use a different audio engines. But I don’t want to do it, that’s the reason I am using cocos2d-x
And now the UI Stuff:
I would also like to see a UI System with a different approach (see the examples above this post). Would be also extremely nice if the system is based on a widely spread language like HTML.
While developing and improving the new system cocos2d-x could support both systems (legacy and shinyUI ). But that would be a lot of work.
