I guess locking to 30FPS rather than variable 60 helps a lot since since less garbage generated and GC collects will be harder to notice. Though on the down side I did sense that your game is at 30 FPS before knowing it, somehow not as smooth as 60, it is noticeable to me at least.
After testing on more devices I have come to realize how varied MonoGame’s performance is across Android devices. While Crazy Cupcakes works in a passable condition (single stutter every ~10 secs) on Samsung Galaxy Note 4, on an HP tablet and Sony Phones it is unplayable.
I’ve been working for about 3 years with XNA/MonoGame, and my experience is quite different too. I was able to quit my “day job” and I owe MonoGame a lot, specially for the Windows Phone 8 version.
I don’t agree with #2, at least with Windows Phone and Android: I’ve done games which are average on cpu/gpu and the garbage collection problems are minimal (they indeed exist, but are not a ‘breaking problem’ at all, and of course not every few seconds) Most GC problems are my fault.
You’re right about #4 but … why do you develop directly on iOS? Personally I do 99% of the code on PC, where deploy time is 0, and everything just magically works on Win8, WP and Android (my platforms of choice right now). #3 and #4 it’s a Xamarin problem, not MonoGame, and despite they’re tied togetter, it’s too harsh to tell that it’s MonoGame’s problem.
If I were to complain about anything about the last years experience, it would be the inhability to release something in Android and iOS which isn’t buried between shovelware, even with decent projects. And that has nothing to do with MonoGame at all 
Package size (android/ios) would be a distant second place (Xamarin problem again)
Unity3D is more performant, you have more things ready to use, and it’s more robust (obviously, with a staff of ~500 dedicated ppl against 2-3 part time hobbyist developers + some users submitting patches from time to time, it’s obvious the product will be better) but the paradigm is completely different. I understand that lots of people love it, but personally I prefer having full control over the code rather than using a GUI to make the game. But that’s a personal opinion, of course.
p.s. About #3 and the license… I think that Xamarin stops allowing you to update your Xamarin version for iOS and Android, but you’re allowed to keep using the “non-updated” version forever (I may be wrong though)
1 Like
I’ve just ran Crazy Cupcake on my Xperia Play. It lagged hard the first try (Might have been loading the ads? Nothing had appeared in the ad space yet anyway). But after that was very smooth.
There was one frame drop on about my 7th play, otherwise I played for a few minutes with no issues.
Do you disable your ads when they aren’t visible? If you are doing background image decoding that’ll cause issues on single core devices.
If you are doing perf testing try completely disable the ads and see if that helps?
On some devices the first time you render a texture or play a sound it’ll cause slowdown as the device is doing some hidden processing (iOS does this with textures, which is really dumb)
Other than that the game ran really smooth.
That was Xamarin’s past policy, now you no longer have access to the “non-updated” version or any version. Meanwhile unity now is free for all platforms, which is hard to believe. I am still waiting to find out whats the catch with this too good to be true offer, because the paid pro version only enables advanced stuff that most indie games would never need to use.
Issue #2 is a problem for me. Here is the top 5 WP8 garbage generated during a 1 second period, that looks like almost 0.5mb for each second, my code’s garbage doesnt come anywhere close to this figure. I couldnt find profiling tools for Android or iOS. As I mentioned in previous posts, Android’s performance does vary between each model, but I was a bit shocked at how bad it is with my friend’s Sony phone (Android lollipop) and HP tablet, the game was a consistent slideshow. Meanwhile on a Galaxy Note 4 I get a varying amount of no stutter to 1 every 30 secs or so. I also did get unsolicited complaints from other friends about stuttering/freezes, while dave says he encountered almost none, but even a single hiccup while flying between the pipes can make the player lose. I only set my ads to be hidden when playing, which is in accordance with the manual, ill checkout your tip though dave.
I develop on WP device or emulator during core game development (20-30 secs deployment), but then I develop directly to iOS or Android for the many platform specific features such as Facebook learderboards, push notifications, in app purchasing, advertisements and layout on different screen sizes. Me and many other Xamarin users are unable to use debugging on iOS, only debug-less deployment is possible for me now.
Overall while MonoGame can be used to push out games alright, the final result tends to feel unreliable/unpredictable, especially when combined with the seemingly weak 3rd party SDK support for this platform. On WP8 the admob SDK causes my game to randomly freeze when combined with Parse, and so does the Parse SDK by itself which I use for the Facebook leaderboard. The Parse SDK 100% freezes if called immediately on startup and I must add a mystical 1 second delay after startup which solved the issue. For my newest unreleased game on WP8, after a while of playing the sound starts to get distorted with clicks and pops as if something got overloaded and I must restart the game to get a clean sound again. Every time the song loops a loud white noise is emitted. I can keep going on and on, and thats just for WP8 specific problems. I am hoping this is MonoGame’s/Xamarin’s/SharpDX’s fault and that Unity will have none of this, but maybe I’ll find out that these issues exist with all tools and its just the nature of our jobs to hack around them. Am still learning 
Hi ramsayamarin
No idea about the xamarin new policy, that really sucks because I’ll enter that situation on January 
Admob on android is bad and degrades the framerate in about 10-20% when the banner is being shown. It’s bearable on fast devices, but very sluggish on old devices.
However, avoid AdMob banners in WP8 like the plague. The SDK is full of bugs which degrades the framerate exponentially. Each time admob on WP8 shows a new banner (as of 6.5.13), more and more CPU is used (there’s a message in a forum I can’t remember explaining that the banners not only are not freed, but they keep running on the background… all of them).
Second, is it possible to post the piece of code which generates the garbage you are showing? It is very weird that so many pieces of 32 bytes are allocated in just one second. The garbage is indeed generated in MonoGame, but this doesn’t mean that it’s a MonoGame problem: it may be a misuse. To put an example of an average complexity game, this game of mine uses MonoGame WP8 and hasn’t got that problem: http://www.windowsphone.com/en-us/store/app/zombie-doom-hd/49464c77-5eb1-49ab-8574-39d682f49d2e (game stutters a bit when using adverts, but the ad-free is rock solid 60FPS on most WP8, GC comes every 1.5-2 minutes)
About the specific features, the best way to solve that is using wrappers. In example, you can have a wrapper for in app purchases which use the same interface for all platforms, and you game use that wrapper. This way you can code everything about the in-app purchases without even leaving your PC environment.
Of course you have to create the wrapper for each platform you use, but it’s a one time work (which you probably already have done). Facebook, and in apps can be wrapped. I’m not sure about push, but I’m sure it can. Adverts won’t.
Also, different size layouts can be simulated on PC without problem. Setting up your projects on PC correctly would probably shave 90% of the times you have to deploy to iOS/Android, speeding up things a lot.
I hope it helps!
I didnt use Admob at all due to the freezing, but thanks for the tip to never consider it.
yeah I did most of your tips to stream line the porting process recently and stay mostly within windows phone. I dont have a specific piece of code that I can share. That was a profiling I did of the whole game months ago. And the source of this garbage wasnt from my code anyways, but from the MonoGame dll so I couldn’t see what code exactly caused it, just the calling function name.
Like the OP, I really really wanted MonoGame to work out for me. I greatly dislike Unity for four core reasons:
-
I dislike coding visually. I think in code. I like Intellisense and a powerful right-click menu. Unity encourages you to break encapsulation by making public links between objects which are then hard to rediscover later: Spaghetti-code is bad, but the same thing within a GUI is a nightmare…
-
I dislike having no access to the source code to be able to (a) find out what something does when the documentation is unclear (b) fix a bug (or prove the bug is elsewhere) © make an optimisation for my particular use-case
-
I disliked how expensive it was originally
-
I dislike how it is tied to an out-of-date, slow version of Mono
While the first two reasons largely remain, the third reason is now gone. And the killer blow for me was when I discovered you could build and release an ios app from start to finish entirely on a Windows computer via http://www.pmbaty.com/iosbuildenv/
Suddenly my entire cost to release a full iPad game was $99 for the Apple Dev Licence (which has to be paid no matter what) plus $40 for iosbuildenv. No need for the annoying purchase of a Mac just to build (or the complication of acquiring a Hackintosh or VM OSX)
I can even do all my coding and run-time debugging in Visual Studio via www.unityvs.com (which is now free thanks to Microsoft acquiring the company). That means I can keep using Resharper, NCrunch (for continuous unit testing) and so on.
Reason 2 (closed source) has come to bother me less over the years as it’s obviously a trade-off; They are wanting to monetize all the features and polish they’ve put in. And they are open-sourcing parts of Unity’s internals anyhow.
Reason 1 (the GUI), well, I will just avoid using the GUI (and indeed GameObjects and MonoBehaviours) as much as possible… Basically just leverage the graphics and other low-level features of Unity and skip the higher-level ones as much as is feasible.
Unity does, imo, have two other killer advantages too though.
One is the breadth and depth of assets for sale in the Asset Store (and elsewhere). There is some seriously high quality open-source code for sale and given away. For example, some guy has created Smooth.Slinq: a version of LINQ which avoids any run-time allocations (so no GC) and manages to outperform the official port - and it’s available for free(!)
And back in my XNA days I found serious issues trying to source high-quality 3D animated models. There were hardly any around and when I got them I usually found they wouldn’t animate properly… Obviously there’s no shortage of high-quality art at rock-bottom prices to be found for Unity.
Finally, that fourth reason (an out-of-date version of Mono) isn’t going to be an issue forever. They do have an exit strategy which is outlined in a blog post: http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/
(I’m not holding my breath on that one though as that is probably another year to eighteen months away at best )
This is a really interesting topic. My story with MonoGame is a little different.
I used MonoGame for around 2 years I guess. I made a few little games for Android and published them on Google Play. MonoGame served it’s purpose but like some of the others in this topic I had similar frustrations with the framework. For me, it was more about the workflow involved.
Before MonoGame I briefly had the pleasure of using the Java framework called LibGDX. I’m not really a Java programmer but one part of the experience really resonated with me. It was the way LibGDX handles multi-platform code by putting 99% of the code into a library and referencing a single DLL from each platform project. Each platform specific project only has the bare minimum code and switching between builds becomes trivial. It turns out you can kinda sorta do it with MonoGame, but it’s a huge pain to say the least.
Long story short, it drove me to start working on my own game framework. Crazy I know, but if you really think about it how many MonoGame features do you really actually use in your games? Sprites, sounds, textures and input usually.
Here we are 5 months later and the framework has a pretty good set of features.
- most of the code exists in portable class libraries (PCL’s)
- it is designed the be inherently cross-platform (I’ve prototyped Android but only Windows is complete)
- it’s open source (as of 5 mins ago I just moved the code into a public repo) https://github.com/craftworkgames/Astrid.Framework
- renders sprites
- plays sounds
- loads textures
- handles input
- supports farseer physics
- comes with a component based entity engine
- basic particle system
- basic GUI system
- can load scenes from JSON files
- oh, and I’m working on a scene editor in WPF (closed source)
I’m not going to pretend it’s complete; it’s not. I’ve b-lined the features to get a decent vertical slice working so that it can be used to make actual games. I’m just one guy with limited spare time after all, but I spend a little time on it nearly every day and now that it’s open source, maybe, just maybe someone else might be interested in helping.
Anyway, I just thought my story might be interesting. I’ve also considered using Unity a few times but I just love working with code too much and after reading through this topic it’s interesting to see how many others feel the same way.
I think a few people have discussed the specifics like performance issues so I’m going to come at it from a different perspective. OP said:
…but I dont think that a few good folks will be able to compete with the big guys offerings.
I think that’s a simplistic comparison. Keep in mind that MonoGame is offering an abstraction layer to remove much of the differences between lower level hardware access (audio, graphics, input), and that’s it. Unity has to do this, but also has to maintain:
- IDE (their version of MD)
- Debugger
- .NET framework and core C# language
- Visual editor
- “Game engine” interface
I think the visual editor is not bad, but as far as the rest go it’s all pretty bad. Their IDE, debugger, implementation of .net/C#, and interface are severely lacking compared to the competition.
MonoDevelop can definitely compete because they’re not biting off more than they can chew - they’re letting Microsoft/Xamarin handle the IDE/Debugger/C#/.NET, they’re letting game engine implementers like CocosSharp/FlatRedBall/etc handle engines and tools. In short MG is specializing in what they do well, they’re letting other specialists handle complementary technologies.
2 Likes
That is all nice in theory, but in practice each one of these components (SharpDX, MonoGame, FlatRedBall, Xamarin…etc) has its own set of bugs and issues, combine them together and you get the mess I went through those past years, and I only used Xamarin + MonoGame, add more layers and the whole structure will collapse. For example, part of the garbage created each frame has to do with a bug in SharpDX that as far as I know still isn’t fixed. Its common thing with these small community platforms to regularly run into issues and be the first to post about them, and even with bigger products like Xamarin, every other update breaks something. As with Unity, you have a single product on an industrial scale where the probability of running into a bug that hasn’t already been reported and fixed in much lower, and having the paid team behind it controlling the whole thing means we don’t need to be dependent upon other people to fix their components, at least thats my hope and I will be able to confirm it soon as I already did 2 practice projects the past day, so far so good.
… but in practice each one of these components (SharpDX, MonoGame, FlatRedBall, Xamarin…etc) has its own set of bugs and issues
Whether the layers are owned by different teams under different names or under the same corporate name the layers still exist and are subject to the same programming pitfalls. I have a bit of Unity experience and I could drown this thread with bugs and very poor design decisions made by he Unity team which have had real productivity impacts on myself and coworkers.
add more layers and the whole structure will collapse.
I’d say “Add more layers and the system is more difficult to maintain”, which is again going to be the case for anyone including Unity. This is not unique to the MonoGame setup. I’m sure dozens if not hundreds of games have been released here with the aforementioned layering (I’ve done a few myself personally).
…and even with bigger products like Xamarin, every other update breaks something. As with Unity, you have a single product on an industrial scale where the probability of running into a bug that hasn’t already been reported and fixed in much lower…
How is it that Unity is in a unique position of having no bugs (or only known bugs) while Xamarin seems to be in a perpetually broken state? In reality I’ve used both and can tell you Unity is not even close to being as rock solid as this statement makes it sound. Editor crashes and freezes are a common occurrence. Colleagues of mine claim that restarting Unity multiple times a day to eliminate accumulated issues that eventually lead to total freezes is the stanard.
I’m more concerned that future readers may come across this thread and be misinformed about using Unity vs. a MonoGame foundation by someone with lop-sided experience with the technologies.
As I view it it comes down to this - Unity and MonoGame will both continue to improve, and which stack you like depends on which approach you happen to like. Personally I dislike the architecture that Unity forces you into, and their shaky foundation on a decade-old Mono branch.
3 Likes
Oh Unity definitely has its share of quirks and bugs - especially in the editor. The answer for the likes of us who are code-orientated is simply to avoid using the editor. That’s not Unity’s strength from my point of view; It’s strength for me is all the low-level stuff and how well so many third-parties support it.
Monogame’s strength and weakness is that it is free and open-source. That means if you come across a bug you can fix it yourself. But it also means if you come across a bug you might have to fix it yourself. Unity has the benefit of millions in revenue and dozens of employees so, while you can’t fix it yourself, you wont have to.
Ultimately, if all you’re going to create is some simple 2D app, there’s literally a hundred x-platform frameworks - some of which need Xamarin and some of which don’t - and you wouldn’t really go wrong in choosing any of them; Or you could even roll your own like craftworkgames did. Personally I spent the last couple of years neither on MonoGame nor Unity but another third-party framework called http://deltaengine.net/ (which is currently somewhat stalled). I did get paid for that though.
If you don’t care how long your game takes you to make, or it’s something that you’ll never release, then, again, it doesn’t really matter what you route you choose. It’s the journey that’s the fun part for that, not the destination.
But if you want to produce and sell a polished 3D game - if the destination is the all important thing rather than the joy of reinventing the wheel - and if you’re a solo-developer who wants to get a return of greater than minimum wage for hours invested - then there are very few workable choices in the market right now.
Wish it weren’t true but there we are.
1 Like
Really?! To be honest I’m more concerned that future readers may come across MonoGame at all, I personally wish I saw this thread 3 years ago. Give Unity to one beginner and MonoGame to another, come back tomorrow and see who has a basic prototype going and who is still searching for a solution to the namespace conflict of Microsoft.XNA. Come back a year later and see who has a few games already released and who is still building a GUI system from scratch. Case in point, I cancelled the release of my game a few days after finishing it, and now am switching to a new platform where none of the engine code that took me 1.5 years to develop or the game that took me 6 months to make is going to transfer over, only the game idea. That is how desperate my situation with MonoGame has become. But your right, I am someone with a lop-sided experience with the technologies. Lets go and ask someone more established in the mobile industry, how about Rovio? did they use Unity or MonoGame to make Bad Piggies? How about the developers of Threes? Monument Valley? Hitman GO? Assassin’s Creed? all these great games that millions of people have been enjoying across all sorts of devices without complaints about stutters/lag or crashes. But lets assume that the lag and stutters are my fault(not), well then it seems that after years of development and a software engineering degree I still cant manage to unlock the secret mysteries of MonoGame. Meanwhile some other hobbyist with little experience is able to push out a game through Unity in a weekend that has no lag or stutter what so ever, you can check it yourself with the tons of Unity prototypes that get reviewed on YouTube.
If you are really concerned about new users being misinformed or misled (I am an example of one), then you should ask for MonoGame to be either shutdown entirely until its developers bring it close to perfection, or as an collaborative project, have all its known flaws be prominently displayed to potential new users on the main page, otherwise months or years might get wasted by the time they figure out these flaws themselves (me again). For example, I wont release my engine code which took me 1.5 years to make, because I am not sure that it is the best it can be, and I dont want to have any users regret using it. If I were ever to release it as open source, I will clearly state that its alpha, what worries me about its implementation and other strong warnings. The software world would be much more efficient if everyone was upfront about their products.
If you are really concerned about new users being misinformed or misled (I am an example of one), then you should ask for MonoGame to be either shutdown entirely until its developers bring it close to perfection, or as an collaborative project, have all its known flaws be prominently displayed to potential new users on the main page, otherwise months or years might get wasted by the time they figure out these flaws themselves (me again). For example, I wont release my engine code which took me 1.5 years to make, because I am not sure that it is the best it can be, and I dont want to have any users regret using it. If I were ever to release it as open source, I will clearly state that its alpha, what worries me about its implementation and other strong warnings. The software world would be much more efficient if everyone was upfront about their products.
Go in with your eyes wide open about Unity too though; It’s not some panacea. If MonoGame has to be shut down due to falling short of perfection Unity has to be too. And they aren’t exactly ‘shouting from the rooftops’ about their failings either…
A common refrain I hear about it is that it’s great for prototyping, but less great for anything beyond that. Anything to do with GameObjects or MonoBehaviours in particular can be very sloow.
Unity is easy to get started with but there’s still a learning curve and tricky pitfalls to avoid if you want to minimize the ‘lag and stutter’ (heavy GC) that can befall you with any engine. Still, it’s a common enough complaint that there’s plenty of blogs entries written about it - each offering their various nuggets of wisdom and advice.
… but this is also a liability. I recently came across a post on an indie game promotion Facebook group that I’m a member of for a guy’s game in Unity. Basically, he’d downloaded the 3D runner starter kit from the asset store, slapped his name on it and pushed it to the marketplaces. He hadn’t even bothered reskinning it!
So yes, as the OP points out, a hobbyist with little experience can push out a game through Unity in a weekend - but is this a good thing? The price we all pay is discoverability - with stores inundated with shovelware, such as match-3s and Flappy clones, potentially great games are often drowned out by this flood of quickly produced, unoriginal crap that’s just looking to make a quick buck.
Yes exactly. MonoGame never promised to be anything more than an open source implementation of XNA. It does that reasonably well, if that’s what you’re after. It is kinda ridiculous to compare Unity (Apples) with MonoGame (Oranges) anyway.
So yes, as the OP points out, a hobbyist with little experience can push out a game through Unity in a weekend - but is this a good thing?
- Is it a good thing that anyone with an opinion can create a blog instead of having to get hired by a newspaper with all their worked filtered through an editor?
- Is it a good thing that anyone with a talent (or not) can record a song and publish it on Youtube rather than being at the mercy of a publicist and their cd distribution chain?
- Is it a good thing that anyone with a talent (or not) can write an e-book and self-publish on Amazon rather than having to find a publisher to fund print-runs and distribute through bookshops?
I’d argue it’s unashamedly a good thing that barriers everywhere are coming down for creative people. However, marketing has always been important - and that fact that barriers are virtually non-existent now does not change that fact; If anything it’s more important than ever. Creative people hate to think that publicity is an important part of making money from a game. The ‘business’ side of things feels ‘dirty’ somehow - like that the quality of our product should speak for itself - but that’s rarely true. (There’s also the possibility that the product that we think is original and brilliant actually isn’t quite as great as we think it is…)
Unfortunately, the very first question you should ask yourself when embarking on a project which you actually intend to sell is ‘how do I monetize this’. If you can’t think of how you can, then you should either accept the fact you’re leaving it all up to chance, or realize that you’re embarking on the project for the pure love of it.
Now there’s nothing wrong with that. I’ve embarked on a lot of projects just for the love of it. But I’ve reached the point in my life that’s not enough; I need a ‘return on my investment’. That doesn’t mean compromising on your principles and making an exploitative ‘freemium’ game which is anything but, but it does mean identifying a market and how you’ll manage to reach them.
If you do your research up front and have a well-identified plan of attack - or hire someone to do that for you - then the 100th clone of Flappy Bird released this month will not feel like a threat to you.
2 Likes
Just to add: I guess for me it’s the difference in mindset between someone who writes games as a hobby and someone who writes games as their livelihood.
For me, MonoGame is still firmly in the ‘hobbyist’ sector of the market.
I wouldn’t put Unity all the way over to the ‘pro’ side of the market though. There are better choices out there for AAA studios with six-figure budgets. But I do think it’s a decent choice for a solo-developer on a shoestring budget who has a dream of delivering a game that aspires to AAA quality. I don’t think even the staunchest advocate would believe that MG offers that right now (for 3D anyhow; for 2D you can make virtually anything work ^^).
After reading through this thread I’m starting to think that I should take what I’ve done to “roll my own” and combine it with MonoGame to create a kind of MonoGame extension project so to speak. One thing that bothers me, and seems to bother other people is that you have to roll your own everything when using a framework like MonoGame.
Sure, we can always choose Unity instead, there’s nothing wrong with that. But for those that prefer using frameworks there’s another option, we can help each other by writing libraries for all that other stuff (GUI, animation, map loading, etc).
I’m going to have a go at rebuilding my Astrid framework as a MonoGame extension tonight and see how it goes.
1 Like
Yes. As well as polishing lower-level stuff to squeeze out every possible bit of performance, that definitely has to be the direction a ‘maturing’ MG heads in the years to come.
If Astrid is the future then great. But imo MG does needs to ‘officially partner’ with some higher-level framework or other to free everyone from having to forever replicate a whole lot of boiler-plate code. Could be closed-source and for-profit even! I mean, Xamarin being those things doesn’t mean MG has to eschew that on principle.
I suspect a whole lot of people have ported over the various pretty good XNA libraries out there - but by never publicly releasing their work noone is ever able to build on it and take it forwards; They doom others to forever repeat it…