My 3 year experience with MonoGame

1

3 years ago I graduated and decided to start making simple mobile games solo. I had to make a choice between MonoGame and Unity, and I went with MonoGame since I already knew XNA well and thought MonoGame will do fine for my simple 2D games. To be perfectly honest, which is the point of this post, I have come to regret this decision and am looking for a time break anytime soon to start learning and switching over to Unity. I am willing to put up with all sorts of development issues (no content pipeline, thin documentation, relatively small community, having to make many foundation stuff myself such as GUI and basic engine) as long as the final product worked well for the end user, but after much investment into the platform, I finally found many underlying issues, too many to list here, but here are the most major ones that are most apparent on iOS and Android, and least on WP:

1- MonoGame is slow: I develop on a 2011 iPhone 4, which quickly shows any performance issues. Simply drawing a full screen blank texture in MonoGame drops the FPS from 60 to 40. For my latest arcade game I was forced to use the Graphics clear color as my background to improve FPS, and still the game is basically unplayable on older devices, since after adding a few textures, it runs at sub 20 FPS. Meanwhile other games such as Badlands and Angry Birds, which utilize high res multi-layered backgrounds and tons of foreground objects run at a smooth high FPS on my iPhone 4. It is impossible to recreate this good performance in MonoGame.
2- MonoGame stutters a lot: These periodic frequent freezes simply kill any time sensitive arcade game, and this is the one that is absolutely the most devastating to my games. Doing a simple memory profile on MonoGame WP will show it creates a lot of garbage each frame. This is most apparent on the Android platform where my games keep having noticeable ~100-200 ms freezes every few seconds, even after all my efforts to create zero garbage on my part by reusing all game objects and object pools and abstaining from using LINQ. On the iOS platform, instead of frequent mini/micro pauses, I get 1 huge 1-2 second pause every couple of minutes or so. These problems seem least apparent on the WP platform though.
3- Cross platform MonoGame+Xamarin isnā€™t cheap: I am too used to Visual Studio and Resharper, which means I had to get the Xamarin Business edition that costs 2k$/year for both Android and iOS to keep developing within VS, and if I stop paying, I lose access to my projects from within Visual Studio (Xamarin unloads them) and so I cannot even do a small update for my games in the future unless I buy a whole year subscription again. In addition, Xamarin iOS + VS2012 is plagued with many problems, too many to list here, but the major one is that I was never able to debug my app on iPhone due to connection problems between the Xamarin and the mac build host, and instead I have to guess what caused a crash when testing.
4- Development is slow: Each time I want to tweak a variable and test how it affects the game, I have to redeploy to device and sit waiting ~30 secs at best (much more time if deploying to Android or iOS).

These are not facts, just sharing my own experiences, yours might differ. Many people have put a lot of effort into MonoGame for free and I greatly appreciate that, but I dont think that a few good folks will be able to compete with the big guys offerings. At this point I see little reason to recommend to anyone MonoGame over Unity for example. I feel bad that about 1.5 years investment into basic game engine utilities will go to waste when I leave MonoGame, and many hours of misery troubleshooting Xamarinā€™s iOS problems.

1 Like
2

My experience is quite different.

Whilst it is true that MonoGame lacks the ā€œpolishā€ of a paid-for product such as Unity, it allows the developer much more creative freedom in how games can be written.

I have released games using MonoGame on Windows Phone, Android and iOS, and have had no significant development issues or bugs with the platform, nor any performance issues that were attributable to MonoGame code (as opposed to my own). All my games run at 60FPS on WP, iOS and Android - including thousands of Draw operations, backbuffer rendering, music and multiple concurrent sound effects. I have noticed no significant issues with garbage collection; where there have been some they were a consequence of my own coding style (e.g. excessive use of lists rather than arrays) rather than MonoGame-related.

Where there have been MonoGame issues - e.g. sound effect issues on Android - the MonoGame community have always quickly come up with a workaround or a patch that has enabled me to continue.

Sorry to hear that MonoGame has been so problematic for you.

1 Like
3

For #2, I donā€™t see these issues. If you can post a good reproduction case on github we should be able to track down the problem.

4

@pauliharman well you can get 60 FPS on the later iPhones, but these hide the performance issues. Just draw a full screen blank texture on iPhone 4 and see the FPS drop from 60 to 40, that alone should signal that something is really wrong. A MonoGame developer once gave me an explanation for this, but I just donā€™t accept it, as I already said, I have seen way more advanced games such as Badlands run flawlessly on my iPhone 4. This is impossible to do with MonoGame if a single drawn texture does 20 FPS damage alone.

@daveleaver I dont have any open source games I can share. I currently finished an arcade game with an original and very promising concept that I am putting a lot of hope in. I was planning on releasing it this week. But just today I tried it on my friendā€™s latest model Sony Android phone and the performance was abysmal, stuttering every other frame, it was just comical how bad performance was, Sony phones showcase more severe problems with MonoGame than Samsung ones. It runs almost fine on iPhone 4S and above (iPhone 4 is slow with about 20 FPS) and any windows phone runs very well. They all share the same code and its a very simple concept with only a few textures drawn. I am sure it has nothing to do with my own code but with MonoGame. If it was my code the problems should show up on every platform, but they donā€™t, only Android and older iPhone devices. I have decided to delay the launch and go out today to start learning Unity and converting my project to it because I cant risk it with such a promising game. I dont stumble upon a good original idea everyday.
While I dont have open source games to share, you can check out a flappy bird inspired game I made a few months back that illustrate my complaints. I spent a month full time just optimizing performance and zero garbage as I can. The results is that it runs well on all WP (even tho the profiler says MonoGame creates almost all the garbage and a lot of it), bad to very bad on all Android phones (frequent periodic stuttering even on later phones with desktop like processors, Sony phones are the most severe), and choppy low FPS on iPhone 4 but better with later models. Notice that the background of the game is just the graphics clear color, I couldnā€™t afford to use a full screen textureā€¦ this game really should be 60 FPS solid on iPhone 4. Everything you see in the game like pillars for example are all recycled and nothing is garbage collected with the use of object pools.

Get it on iOS: http://goo.gl/2TiQ0U
Get it on Android: http://goo.gl/Iwpvea
Get it on Windows Phone: http://goo.gl/Q6LbGn

I would like someone to share their MonoGame game which isnt a puzzle game, but rather arcade style with moving objects so I can see if its possible to have a smooth MonoGame game on Android, and also good performance on iPhone 4.

5

#1 Old devices have really low fillrate, the first WP7.0 for example had a fillrate of about 1.5 @30fps. That means drawing a fullscreen texture you allready used up almost half of your GPU power. I am not used to iPhon/Android but here are some recomentations from working with XNA on early windows phones. Use a 16bit backbuffer instead of 32bit. Use compressed textures or R5G6B5 (http://konaju.com/?p=33). Lock to 30fps, it is better to have smooth 30fps than iregular 40-45. Try to batch most of your drawing called.

#2 Garbage is a real issue on low perf devices. Can you apply those changes and report back? If you are using DrawingSurfaceBackgroundGrid On WP8 there are also garbage coming from sharpDX.
https://github.com/mono/MonoGame/pull/2902
https://github.com/mono/MonoGame/pull/2963
If those changes dont imrpove the situation on iPhone/Android it means there are other sources on platform specific implementation. Are there any profiling tools to locate those? Hopfully, the owrst case on those platforms is just a case of mono vs .net.

#3 Yap, I totally agree on that. It brings the cost of MG on the same level of unity for cross platform development. It would be better to have a striped down version of xamarin for use with monogame and also to fix itā€™s licence terms.

4# Make a windows project for testing. It builds and run faster, have edit&continue, etc.
For device specific code i believe the situation is much worst with unity. Comunicating between code in unity and code in your project is not straightforward and you have to backup/restore your code every time unity rebuilds your project.

I donā€™t know if my game would play smooth on iPhone,Android, but on WP i manage to have 60fps along with physics and skinning. That of course was not easy, includes lot of batching, hacking SharpDX to remove garbage, etc.

6

The problem is mostly with Android whose severe performance problems show up on even the very latest powerful phones, and that is a big deal since Android is ~70% of the market. Secondary is the iPhone, where performance issues only start appearing on iPhone 4/4S if the game is tiny like mine, these issues are hidden in later more powerful models which is fine for small games. I actually have almost no major problems with WP though, even though it creates a lot of garbage, but somehow windows phone manages to almost hide the stutters (GC collects) or make them sufficiently uncommon.

Unity is actually pretty much free for all platforms now unless you need access to advanced features and custom splash screen.

7

I havenā€™t noticed any significant issues with my games, though I lock to 30fps rather than 60fps. I use a lot of large textures for backgrounds, parallax scrolling etc.

Go to www.bitbull.com and you should be able to find my games on the AppStore and Google Play (only a couple of them at the moment).

cheers

8

I believe on iPhone, mono builds a statically compiled native code.
Same thing is comming to Windows with Net.Native.
GC is still present but at least this eliminates any interop/Marsal cost.

9

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.

10

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 :slight_smile: 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
11

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.

12

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 :smiley:

13

Hi ramsayamarin

No idea about the xamarin new policy, that really sucks because Iā€™ll enter that situation on January :frowning:

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!

14

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.

15

Like the OP, I really really wanted MonoGame to work out for me. I greatly dislike Unity for four core reasons:

  1. 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ā€¦

  2. 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

  3. I disliked how expensive it was originally

  4. 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 :slight_smile: )

16

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.

17

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
18

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.

19

ā€¦ 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
20

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