It's understandable, but there are different ways around having to rewrite the game, plus since they are indie it would be a rewrite into C# or possibly java, and they all have their own messy aspects to the process, so it would be like rewriting the game. C# is used in programming for the Unity engine and java is usable for HTML5 but I don't know the particulars to Nintendo's HTML5 framework, which are the only two tools available to indie development. But in short it would be a pain in the rear messy project that most indies would rather avoid.

Between this news and the Sega/GameFreak crossover not coming to Nintendo platforms, it's a pretty disappointing afternoon.  Oh well - I knew what I was buying into when getting a Wii U.

Middleware engines have become the norm and if Nintendo wants to improve third party support next time around they need to make sure those engines are on their hardware.  It's like a new wrinkle that didn't exist prior to last gen.  It's not like "oh company X didn't release their game on our system".  Now it's "company X didn't release their development tool on our system so this big chunk of games is just cut out".  Japanese companies tend to create their own engines inhouse, which created a lot of problems for them last gen and is probably a big reason why Nintendo's Wii U output was initially so slow.  Since Nintendo doesn't use these sort of third party dev tools they have likely failed to realize why it is important to have them on their console.  We all know that Nintendo designs their hardware primarily for themselves.

When designing the Wii U successor they need to work with the companies that make the game dev middleware.  They should be going in with the approach of getting these engines on their hardware.  10 years ago Nintendo would make little isolated deals like having Sega make F-Zero GX and offering Silicon Knights to port Metal Gear Solid.  That kind of stuff in small potatoes.  You make those deals with the middleware guys and then with a low barrier for third parties to port their software the lineup should just naturally improve.  Or even if it doesn't improve right away it is NECESSARY for it to have any chance to improve.  A third party is not going to do a full on port conversion these days.  The Wii sold better than anything and yet still hardly anyone was willing to put in that kind of work.  The only solution is to make it easy to include the Nintendo console in multiplatform development.

In this case it even seems like the dev would be happy to release the game on the Wii U, they just CAN'T.  It just isn't feasible for them to jump through Nintendo's hoops.

They can't--not any more than they could force any other game developer to develop for the Wii U.  This is a decision that each developer makes for itself.

These aren't hoops that Nintendo have set up.  This is like learning German and then being upset that no one can understand you when you fly to Spain.  German's a fantastic language and has many intriguing features and so on, but if you can't speak German in Spain, it's not because Spain set up hoops for you to jump through.

To a certain extent, having a different architecture is going to create more work for developers who may only want to optimize for one or the other.  That's not a malicious design decision either, but it does mean that a developer somewhere is going to have to make adjustments and compensations.  Where middleware is involved, the middleware developer is responsible.

The success of Steam on Linux (two years in advance of the SteamOS-based consoles coming this Fall) has encouraged more and more developers to consider cross-platform tools when they develop new games.  With luck, this will have a spill-over effect on consoles as well.

Judging by name alone Monogame is based on Mono which is an OpenSource port of Microsoft's .NET technology.
It's likely it's already written in C# or something like that.

Ian is exactly right in this case. Engines like Monogame and Unity are already multiplatform development platforms -- designed to be compatible with the largest possible array of systems. That is exactly why independent developers want to use these platforms; you get the biggest bang for your buck. Of course, they require cooperation from closed platform holders like Nintendo, Sony, and Microsoft to develop tools for porting from the common code base to those particular platforms. This isn't a new problem. Look at the problems Sony had with PS3 until they could get Unreal Engine 3 fully supported on that system, and also consider all the games that Wii couldn't get at all because there was no hope of running UE3 on that hardware.


The good news is that Monogame, like Unity and HTML5, is almost certainly capable of being friendly with Wii U. But Nintendo has to engage with the engine developers to make that happen, and the quoted tweets in this article show you how that has been going so far.

It's a shame, really. Working to support middleware engines doesn't immediately pad Nintendo's bottom line, but does make porting to Wii U easier for third parties and ensures more games can be released.


Last I've heard, having more games on a console never hurts the bottom line - Nintendo takes a cut from all sales because they are the platform holder, and more games makes the platform more attractive when people are trying to decide if it's worth buying.  So while the benefits might not be immediately apparent it seems like early support for popular middleware could pay off nicely over time.


Maybe that's an oversimplification though?

We were talking about back in 2012 or 2013 when I first called Dan about porting to Wii U and there wasn't a Monogame solution.  That was before I'd even signed on with Sony's Pub Fund.  Monogame may very well becoming to Wii U but it's not something we can launch on until next year.