As we all know, the Wii U has struggled at retail across the board. One of the big factors many fans point to is the lack of 3rd party support, and how it appears on the surface like 3rd parties jumped ship before the console launched, leaving Nintendo out to pasture. We rarely get any actual insight into this period pre-launch until several years after the fact. That’s why we’re fortunate a developer who prefers to remain anonymous has spoken with Digital Foundry about the Wii U. This developer was responsible for developing a launch game for the Wii U, and one that was well received critically, although sales wise it may have just barely broke even with development costs.
Obviously before any development begins for a new platform, there is a presentation period where Nintendo would show up to explain what is so great about their new platform. Here is roughly how the meeting went that involved this anonymous developer:
It started off in the usual way with a look back on how successful the Wii had been and what their intentions were for the new hardware. They wanted a console that was the same size as the Wii and wouldn’t make much noise, so “mum wouldn’t mind having it in the living room”. It was during this statement that quiet alarm bells started to ring in my brain, but I ignored them and continued watching the presentation. The pitch then moved on to the usual “we need your help to ensure that the Wii U is a success and you can help us (Nintendo) along the way”. These words ended up having more significance than either we, or the presenters, could have envisaged.
Then the new controller was shown as a dummy prototype, complete with a glossy video showing how it could be used in games as a series of mock-ups, which looked exciting. By this point we were all considering how we could use the controller in our games. But then they revealed the internal details of the console and I realised the reason for my earlier alarm bells. If Nintendo wanted the hardware to have a small footprint and be quiet, they needed minimal fan noise, meaning that cooling was limited, which in turn meant that the CPU would have to produce a minimal amount of heat, which meant that the clock speed would have to be kept low. While I can’t confirm specific details, thecollective thoughts of the internet are presented for reference on Wikipedia.
So a basic comparison/calculation makes the Wii U look, on paper at least, significantly slower than an Xbox 360 in terms of raw CPU. This point was raised in the meeting, but the Nintendo representatives dismissed it saying that the “low power consumption was more important to the overall design goals” and that “other CPU features would improve the performance over the raw numbers”.
As you can see, it didn’t get off to a very impressive start. Concerns about the CPU were already happening before the specs had actually been revealed. Of course, there is a difference in theoretical hardware and reality, but more important than all of that is the ability to access the hardware itself through available tools. Unfortunately, Nintendo wasn’t helping anyone, including themselves:
Having worked on other hardware consoles, I suppose that we were rather spoilt by having mature toolchains that integrated nicely with our development environment. Wii U on the other hand seemed to be trying at every turn to make it difficult to compile and run any code. Nintendo had provided an integration of their development tools into Visual Studio – the de facto standard for development – but it didn’t work, not even close. So time was spent trying to get this fixed up, while reporting the issue to the platform holder. Eventually we received a solution from Nintendo via another third-party company who had also been working on this issue for a while.
So now we could make the code visible in Visual Studio and get it compiling, which was good, but the compilation times were really slow, even for minor changes. Then it had to do the link step, at which point you could happily get up, make a cup of tea, have a chat and get back to your desk before the link was complete. Link times were measured in multiple (four or more) minutes on Wii U compared to around one minute on other platforms.
Finally, when you had the code, you would deploy it to the console and start up the debugger, which was part of the toolchain that Nintendo had licensed from Green Hills Software. As a seasoned developer I’ve used a lot of debuggers, but this one surprised even me. Its interface was clunky, it was very slow to use and if you made the mistake of actually clicking on any code, then it would pause and retrieve all of the values for the variables that you had clicked, which might take a minute or more to come back.
Another curious thing to note at this point was that over the course of six months we received multiple different development kits in a variety of colours, none of which revealed why they were different from the previous one. We knew that there were some hardware bugs that were being fixed, but the release notes rarely stated what had changed – we just had to take the new ones and get them working with our code again, consuming valuable development time.
Now obviously the toolset to create games would be different from other consoles, but having it take significantly more time to do anything was helping no one. Sending out several dev kit versions and never explaining what changed is an extremely hard thing, development wise, to deal with. So, there were some issues that made things slower, but not impossible. So, let’s move on:
Now that the game was up and running on the console we could start developing features that would use the new controllers and make our game stand out on the platform. But soon after starting this we ran into some issues that the (minimal) documentation didn’t cover, so we asked questions of our local Nintendo support team. They didn’t know the answers so they said they would check with the developers in Japan and we waited for a reply. And we waited. And we waited.
After about a week of chasing we heard back from the support team that they had received an answer from Japan, which they emailed to us. The reply was in the form of a few sentences of very broken English that didn’t really answer the question that we had asked in the first place. So we went back to them asking for clarification, which took another week or so to come back. After the second delay we asked why it was taking to long for replies to come back from Japan, were they very busy? The local support team said no, it’s just that any questions had to be sent off for translation into Japanese, then sent to the developers, who replied and then the replies were translated back to English and sent back to us. With timezone differences and the delay in translating, this usually took a week !
One can understand how this is an extremely frustrating process. Waiting a full week at a time for a simple response that doesn’t answer the question you asked because of some translation team thing just doesn’t sit right. How hard can it be to have someone specifically hired to translate the emails back and forth on a daily basis? More and more however, it became obvious that Nintendo just didn’t have the answers for themselves, let alone others:
Alarm bells started ringing quietly in my head again, but I put them to one side for the time being. This is Nintendo’s new network infrastructure that they are basing their console around, they should make sure that it is complete and fully tested before sharing it, so I could forgive them some delay. We had the basics so we could at least do some testing and connect multiple kits together, but a lot of the Mii and friends content was missing and there was no way to test how the existing code would behave in a “retail environment” as there was no retail “flash” for the development kits. We had to code it all in the dark and just hope that it worked.
We were told that the features, and the OS updates to support them, would be available before the hardware launch, but only just. There were apparently issues with setting up a large networking infrastructure to rival Sony and Microsoft that they hadn’t envisaged.
This was surprising to hear, as we would have thought that they had plenty of time to work on these features as it had been announced months before, so we probed a little deeper and asked how certain scenarios might work with the Mii friends and networking, all the time referencing how Xbox Live and PSN achieve the same thing. At some point in this conversation we were informed that it was no good referencing Live and PSN as nobody in their development teams used those systems (!) so could we provide more detailed explanations for them? My only thought after this call was that they were struggling – badly – with the networking side as it was far more complicated than they anticipated. They were trying to play catch-up with the rival systems, but without the years of experience to back it up.
This is obviously troublesome. Nintendo apparently talked about making a system to rival competitors, but then blatantly state that no one on their team has any experience using those systems when asked about them during development. This is troubling times indeed. Of course, the network update did eventually arrive before release, but things we’re even more muddled
First up we had to flash the kits to the retail mode that had the Mii and network features. This was a very complicated manual process that left the consoles in a halfway state. In the retail mode we could test our features and ensure that they worked as expected, which would be a requirement for getting through Nintendo certification, but in this mode the debugging capabilities were limited. So we could see when things went wrong, but we couldn’t fully debug to find out why. As developers, we had to make a choice and hope that any issues that you found were due to the (untested) OS code and wouldn’t happen in the final retail environment. What should have been simple tasks were long-winded and error prone. Simple things like sending a friends request to another user were not supported in the OS, so you had to boot a separate program on the console manually, via a debug menu, so that you could send one. But if any error occurred there was no way to debug why it had failed, it just failed.
We started to ask questions about how they could possibly launch the console, which was a matter of weeks away, with a partially developed OS. How were they going to get the OS onto all of the consoles that had been manufactured up to that point? Was it just that we got it late, but they had pushed it into the production line earlier?
Launch day came around and the answer became clear: Nintendo was late – very late – with its network systems.
Essentially, our day one massive update was in fact the big network OS update developers had only gotten mere weeks before the console released. An update that was extremely difficult to develop for and it left you releasing a game on the platform where you just hoped things worked, because you couldn’t properly debug anything. Still, the game came out, so what now:
Well, we eventually released our game and it was generally well-received, so the management sat back to see what kind of sales figures we would get for all our efforts. Without going into detail it would be fair to say that the numbers we were seeing were less than impressive. In fact we would be lucky to make back all the money that we had invested in making the game in the first place, and although the management publicly supported the Wii U platform, it is unlikely that we would ever release another Wii U title.
After all of that, they still managed to release a generally well received game and still, probably just barely, recouped development costs. Understandably, future support for the platform was likely dropped. From his standpoint, he explained why he feels other studios have completely jumped ship, most before the console even released:
- Previous development experience using the toolchain and hardware put off development teams from making another title on Wii U.
- The technical and feature support from Nintendo were lacking for third-party studios. There was a feeling internally that if you weren’t a first-party development studio, you were largely ignored by Nintendo, as we were superficial to their profits. Internally developed titles would save Nintendo and we were just there to add depth to the games catalogue.
- The sales figures for the Wii U console were not looking that good soon after launch. There was a lot of confusion in the general population around the launch as most people thought that the Wii U was some kind of add-on to the Wii, they didn’t know that it was a new console. This lack of awareness probably contributed to the console not getting off to the start that Nintendo would have hoped and put off studio from developing on the hardware.
- Nintendo also fell victim to bad timing. A few months after the console launched the next-gen hype train stepped up a gear as Sony announced the PlayStation 4, with Microsoft joining the fray a few months later. Don’t forget that many of the larger studios would have known about the hardware months before it was announced, well before the Wii U hardware actually launched.
As you can see, nothing about the Wii U was all that encouraging for developers, and financially the ones that did release games ended up not fairing all too well, which really discouraged future releases. Many times we may be quick to blame third parties for their lack of support, but Nintendo plays the most pivitol role, and in this it appears they have dropped the ball. The real question is: How are they now? Will they have this same sort of toolset next time they release new hardware? Will they pay attention to competition more than looking at news articles but through actual experience?
I highly encourage you to read the entire piece at Digital Foundry. There is a lot of valuable insight to be gained from a 3rd party perspective when trying to work with Nintendo.