Does anyone here use a good UI framework they would recommend?
I dont know what is your goal but maybe this http://developer.xamarin.com/guides/cross-platform/cocos2d_xna ?
Thanks. A lot of the game fundamentals and components are already written (using MonoGame). I’m looking for something that will allow the composition of menu/option screens using buttons, dropdowns, text areas etc.
Some time ago I was planning to work with Ruminate, https://xnagui.codeplex.com/.
Never got into it, and I don’t even know if it’s customizable. If you ever work with it please let me know if it is usefull.
Unfortunately the author mentions he’s not planning on MonoGame support because it’s too difficult: https://xnagui.codeplex.com/wikipage?title=The%20future%20of%20the%20XNA%20GUI&referringTitle=Home
A quote from the author of Ruminate GUI…
So about MonoGame support, I have found MonoGame very difficult to deal with. The second you vary from the basic functionality offered by XNA things start to break. Resizing behaves differently between platforms, form handles are handled differently between platforms, and lots of other things require a deeper knowledge of the underlying technolgies (OpenTK, SlimDX) and (MonoGame) than I have and am willing to learn at this point.
It’s unfortunate that the author feels that way about MonoGame because he is giving up multi-platform support in favor of only supporting Windows.
Of course, there are a few take-aways from this…
MonoGame is awesome, but it still has a lot of little bugs causing developers to shy away from it. The MonoGame team should pay close attention to feedback like this and focus energy into fixing those bugs in the core framework before working on new features (IMHO).
Ruminate GUI is open source. If the author is not going to port it to MonoGame, perhaps someone else could do it. I’m sure the author would be okay with that.
It highlights the need for a good GUI framework that works with MonoGame.
Interestingly, I actually started working on a project like this about 12 months ago. It was coming along very nicely, but at the time there wasn’t any interest in it and I found it too difficult to maintain. Unfortunately, I’ve also re-factored the code into my game engine, so it’s no longer just a stand alone GUI library.
There’s a great screenshot on this early blog post:
If there really is some interest in a GUI library like this, I might consider reviving the project.
Ruminate XNA is both MIT licensed and hosted on a git repository. Fork it!
This is the first time i’m hearing of Ruminate and the authors complains. Hard to pay attention to feedback that isn’t give to us.
That is a nice intention and we do try, but I personally can’t my bills or my employees paychecks simply by fixing bugs in MonoGame. The contribution I and my studio makes to MonoGame are mostly driven by our own needs on paying projects and we contribute them back in the hope that others do the same.
It isn’t to say everything is self serving. One example is the documentation project work I’ve been doing. It is mostly because I find it interesting work and it is something MonoGame sorely needs.
The MonoGame “team” is mostly just myself and @KonajuGames right now. And as much as I try to… I can’t fix everything myself. There just isn’t enough time in the day. We really have been lucky lately to have a few people like thefiddler, @daveleaver, and @Nezz contributing lots of fixes and features. We need more people like them contributing.
MonoGame is just like most open source projects. Most people submitting changes work on it because they use it as part of their work. For the rest game development is a hobby. But for all of them, MonoGame is something that works in their use cases. Most likely your use case will be a bit different, which requires some changes. Since this is open source, you just fork it on GitHub, make the required changes for your use case and send a pull request. This way MonoGame will support one more use case. But please, don’t expect us to work on things that are unrelated to our use cases, we are not paid for that
I have submitted over a hundred PRs I think. Most were easy and some where really hard. In the case of SongArc we needed a MedaLibrary implementation and the ability to play back those songs using the MediaPlayer. At first we ditched all the MediaPlayer functionality other than the playback of MediaLibrary songs, which resulted in a nice, clean and working code. But that way it was not possible to contribute the changes back, so once we had the time, we spent a few extra days and made our use case generally usable. In the end I believe it was worth it because MonoGame became better and we are happy to use it for a really long time now.
i kinda built my own little button-manager class its nothing like a framework
in fact it used polling sectional collision buckets and game modes instead of game screen components
but it worked, actually overall it was uber simple to use
at least within xna it did for all the basic stuff like clickbox’s toggle buttons textbox’s number box’s ect…
saved me tons of time on all my little editors i made, but its really in a sorry state i redid it so many times, i never really felt like i could get it to a point of even being fine with it.
well , ive been thinking about taking another shot at it.
what would a ui kit under mono-game realistically be expected to implement. ?
I just released beta version of Empty Keys UI Library - http://emptykeys.com
It’s PCL (profile259) so multi-platform and on top of that it’s multi-engine - MonoGame and SunBurn. It supports all cool features of WPF (limited ofc) like data binding, resources, styles, templates, dpi features etc. It comes with custom Code Generator from XAML to C# so you can use Visual Studio or any other WPF XAML designer. More info - http://emptykeys.com/Products
API Docs: http://emptykeys.com/EmptyKeysUI/index.aspx
Any feedback is appreciated
Sorry if I offended you @Tom. I completely understand that this isn’t your paying gig and I fully appreciate all the spare time you’ve put into MonoGame.
I’m probably a little biased at the moment because I’ve had a few frustrating experiences in the last few days trying to port my game to Android. I had lots of strange errors trying to use the NuGet packages and almost all of the MonoGame samples (found in various github repo’s) didn’t compile out of the box. It was kind of annoying to say the least, but certainly not your fault.
This isn’t the first game I’ve made using MonoGame and in the past the porting experience has been relatively pleasant. It just surprised me that so many things had broken since the last time I did a port.
I’m also a very small team (just myself and my sister) making games in our very limited spare time. I completely understand how much work it takes to make games and also maintain an open source project. Not easy. It’s actually pretty impressive how far MonoGame has come with so few contributors.
Perhaps I should fork the project and start running from source so I can help fix the bugs that annoy me the most. Although, I already run a pretty weird configuration with portable class libraries and so on. I’ll have a think about it.
@filcon The GUI library looks very impressive. Nice work.
Not at all. I was just explaining it from our point of view which I don’t think people fully realize.
Android is a very hard platform to support… so much odd ball hardware. I’m really not surprised you had trouble with it. We generally avoid it ourselves.
MonoGame has been going thru a lot of big changes in the last 4-5 months and because we don’t have a complete set of unit tests it causes breaks in features. Just report the issues to us and we’ll get to them.
That is highly recommended. Not only does it help you solve your issues quicker, but it helps everyone else that works with MonoGame. If everyone using MonoGame contributed like that we would be much better off.
Why do you avoid it? It seems strange to ignore it considering how many people use Android devices. Google recently announced that it hit over 1 billion active users! And although the numbers vary from article to article it’s not hard to see that Android’s market share is at least as much as iOS.
Besides, I’m using a Samsung S3, easily the most widely used Android device around. And the errors I experienced had more to do with rendering full screen sprites. Basically, the image is not scaling to the actual size of the screen.
Yep. I guess if there’s nobody in the MonoGame team regularly testing Android devices I can start taking that responsibility. Perhaps I can implement some unit tests to catch errors like the full-screen one’s I’ve experienced.
Hey, I’m the author of the Ruminate XNA 4.0 GUI library,
Anyways just a heads up I have resumed work on the project. The main issue was that I was hooking into the windows form which had the benefit of providing event driven input and handling the timings for repeat characters, double clicks, and the like. I’ve sidestepped the issue by using a 3rd party library that solves most of those issues for me.
Intend to add tables and some formatting tools in the near future.
You can try AltSketch if you like
@filcon Is the source for Empty Keys available? I love the look of it, though not sure I’d be comfortable using it if it isn’t open source. I see it is MIT licensed though.
Would be great if you could put it on GitHub or something!
There will be no sources avail for main library, but I’m preparing small modules (Game Menu UI, RPG UI etc.), which will come with sources. Those won’t be for free tho.
There is open source UI Generator https://github.com/EmptyKeys/UI_Generator , which is part of the library. So you actually don’t need the main library sources if you want to expand it’s features. You can always use ILSpy, I didn’t obfuscate styles, templates etc.
And if you are looking for some way how to do something, you can just ask.
I ported XNA simple Gui towards https://gui4u.codeplex.com/ , it works on my windows 8 pc for monogame 3.2.
Maybe its interesting for you…
Seeing as I kicked this thread off months ago I should really provide an update!
After filcon’s initial post I looked in to using EmptyKeys and soon began to create the UI my game needed. Got to say, it’s been great - it works really well, does everything I need and there are plenty of decent examples with it. I’m really glad I adopted EmptyKeys as, after months of searching for a good UI framework, it continues to be a solid choice.
A couple of months ago, I created a very experimental framework that used the syntax of HTML and CSS to modify and render different UI controls. It was quite flexible, especially if you’re familiar with the web. I think It might turn out pretty cool if I spend some more time on it. In the future, is this something that the community might be interested in?
Here’s a screenshot on some live action. Note: The menu design is quite flat, but you can create more complex stuff using the framework.