WiiWare: Innovation and mistakes

I bought a Nintendo Wii earlier this year. I've never actually owned a console before, but have a reasonably strong loyalty to Nintendo. They appear to publish the best games (of course, that's entirely subjective). My game catalogue now includes the following titles:

• The Legend of Zelda: Twilight Princess
• Super Mario Galaxy
• Metroid Prime: Corruption
• Wii Sports
• Mario Kart
• Super Smash Bros Brawl
• Star Wars The Force Unleashed (this game barely makes it into the list, I'm thoroughly disgusted with this title, and am considering using it as a coaster)
  

You may have noticed that I'm not a big fan of the more lighthearted "party" style games out there - I prefer the more focused, single player games.Once I had purchased those titles I began to look for something else, but quickly found that there's not a whole lot of choice out there right now. Most new Wii games tend to be in the "party" category.

Thankfully, Nintendo have launched WiiWare. WiiWare is a collection of titles created by third party developers. There are many different titles to choose from, and each title costs around £10. I ended up purchasing two titles:

• Final Fantasy Crystal Chronicles: My life as a king.
• Lost Winds.

These are both splendid games. However, once again, the pool of good games in the WiiWare collection is very limited - the main reason for this as far as I can see is that it's incredibly difficult to get your hands on the tools required to develop games for the Wii. For a start, Nintendo are only selling their development kit to well-established development houses (you need a registerred business, proper offices, previously published titles etc.). Their application form states that:

The Application includes a NonDisclosure Agreement (NDA). Once the Application and NDA are
submitted by you, we will email you a copy of the Application and NDA for your records. Please
note that your submission of an Application and NDA does not imply that your company is approved,
or will be approved, as an Authorized Developer for the platforms above.

...
If the Application is approved by Nintendo, we will notify you by email. At this point, your
company will be considered an Authorized Developer for the platform(s) specified. If your company
is approved for Wii, this also includes WiiWare. If approved the appropriate SDKs can be downloaded
from Warioworld, and development kits can be purchased from Nintendo of America.

So First you need to sign an NDA, Then, if you are accepted you need to purchase the development kit (priced at over $1000 USD). All this makes is increadibly hard for "joe programmer" to start cutting code for the Wii.

I really think Nintendo have missed a trick here; imagine the community that could form behind a free development kit. Think about the success of the Apple AppStore for the iPhone, but with games instead. The Wii is a revolutionary platform, with a unique control interface: surely lowering the barriers to entry can only be a good thing?

There's another side to this as well: The Wii Homebrew team have already done a lot of work reverse engineering the Wii, to the point where there is already an SDKs available for use. Is it usable? I haven't tried it myself yet (perhaps when I finish some of my current projects I'll play with it), but there are already a fair number of games available for the homebrew channel: I count more than 70 games listed, as well as a number of utilities, emulators and other bits and pieces.

The free development kit is based on the gcc PPC port, and comes bundled with everything you need to start development. GNU gcc has been a well established payer on the compiler scene, so it's not like we're playing with untested technology here.

Given that many of the secrets of the Wii are out (or are being reverse engineered even as you read this), wouldn't it be prudent for Nintendo to officially welcome third party developers to the fold? More importantly, for other, future consoles, imagine a world where:

• The original manufacturer (Nintendo, Microsoft, Sony or whoever) use an open source toolchain from the beginning. I assume that Nintendo have spent a lot of time and money developing their toolchain, which seems a little wasteful to me, when an open source solution already exists. Sure, it may need to be tailored for the Wii, but I'm sure there are plenty of people who would embrace these changes. An open source toolchain lowers development costs, and lowers the barrier to entry for third party developers.
  
• Third party developers are encouraged to write applications themselves, and the cost to entry is kept as low as possible. The manufacturer supplies the hardware, points to a pre-packaged toolchain of open source applications, and provides a development SDK with decent documentation. If all you need to test your games is a copy of the console itself, that would be great. However, why not build an emulator that can run on a standard PC?
  
• The manufacturer provides bug-fixes for the SDK when needed, and creates a community-oriented website for budding developers.
• The manufacturer provides a free (or very cheap) means of distributing third party applications via the internet, and offers the option of DRM routines, should the initial autors wish to make use of them.
  

I believe this setup could bring about a number of beneficial changes to the console gaming market:

• An overall increase in the diversity and quality of available games.
• A vibrant community of developers who help the manufacturer maintain the platform SDK and development toolchain by submitting bugs, feature requests and other suggestions.
• Increased popularity for the platform (I'd buy any platform that offered all of the above).

Unfortunately, I can't see it happening any time soon. It seems to me that the big three console manufacturers are still engrossed in the "proprietary hardware, closed source" paradigm. Still, a guy can dream, right?

On C++ programming IDEs

I've been doing a bit of programming work under Linux for the last few days, and I'm very disappointed with the selection of integrated development environments on offer. Read on for my complaints.

First though, a bit of history. I usually write code under Windows for my job. I use Microsoft's visual studio 6. For those of you who haven't tried it, compiling code with the VS6 C++ compiler is a bit like pulling teeth. For example, Microsoft thinks that the following is perfectly valid code:

for (int i = 0; i < 10; i++);
printf("After loop, i = %d", i);

However, The scope of the variable "i" is limited to the contents of the for loop (in this case it's en empty loop), and so shouldn't be available to the printf line. This becomes even more painful when you want multiple for loops within a function, and you want to be able to use the "i" variable for each loop. Under windows, you can do this:

for (int i = 0; i < 10; i++)
{
// do something
}


for (i = 0; i < 10; i++)
{
// do something else
}

Note that I don't need to re-declare "i" in the second loop, since it already exists? If you try and compile this code under a compiler that observes the C++ standard, you'll get compilation errors. So, how do you turn this into cross-compiler code? AFAIK the only way is to use a second variable inside the second for loop, OR to wrap each for loop in it's own additional scope block, like this:

{
for (int i = 0; i < 10; i++)
{
// do something
}
}

{
for (int i = 0; i < 10; i++)
{
// do something else
}
}

However, I digress from the true subject of this post. For all it's compiler digressions, the user interface actually isn't that bad. Sure, the toolbars seem to move to random positions on your screen every time you debug a project. Sure, you can't use it on a second screen because all the tooltips draw themselves on the first screen, and yes, if you want decent code completion you need to use a plugin like visual assist X, and no, there's no code folding either. But apart from all that, the UI is just right. It's not overcomplicated, it's easy to use.... simple!


So, let's look at KDevelop, KDE development environment. I have several problems with it:

1. Code completion requires the user to jump through waaaay too many hoops. As far as I'm concerned it should be turned on by default, or, if that ruffles too many feathers, have one checkbox to turn it on. I shouldn't have to root around in the KDevelop settings, and project settings, add the library include directories I want to use for the project, exit KDevelop, install ctags, re-load project, tweak settings, and then find that code completion is actually not that brilliant.
2. The User interface is way too cluttered. Many of the menus are so full of entries that they cascade off the bottom of my screen. There are so many toolbars and sidebars that I can barely see my work. Many of the sidebars don't even work properly! The documentation sidebar seems particularly useless. I could probably find out what I have to do to get it going, but my point is that it should work out of the box! When I fire up KDevelop, I want to write some code, not mess about with the environment.

The best development environment should be completely transparent to the programmer. OK, so none of the IDEs I've used to date achieve this, but a man can dream, right?


In the mean time, I'm going back to my old IDE: Kate, with the scons build system, activated from the console, and gdb as a debugger. What more could you want?

Maintaining Binary Compatability

It seems to be common practice for software development companies to patch individual parts of a released product. Usually this means distributing a second installer that creates new shared object (.so or .dll) files, so the next time the application in question runs it loads the new object files, and thus runs the new code.

In practice this is a great idea - it means that companies don't need to re-release and re-ship the entire product. Unfortunately, it's not always that easy. The biggest problem is that the new libraries must be binary compatible with the old ones. Essentially this means making sure that all objects within the library are the same size as they were, and that things like vtables haven't changed.

For a while now I've been looking around for a definitive list of guidelines to help me maintain binary compatible libraries. I finally found it on the KDE website.

Behold: Binary Compatible Issues with C++

Anyway, I thought that might be useful to some of you. Enjoy!