Jeff On Games

One of the most frequent questions I get from high school and college students, especially after they read my school article in GCG, is "What programming language should I learn?" Generally, I reply to this question privately over email, but I figure it's something that I should have written about a long time ago, so here it goes. The answer is… it depends.

Now, I'm sure everyone was thinking the answer would be C++, and for the most part, you're right. But you're thinking I get this question from ONLY programmers, and only programmers that are at the level where they'd be able to work with C++ and not get intensely frustrated. Certainly, all people looking to be programmers in the game industry MUST learn C++ and MUST learn it well. But I'm getting ahead of myself. We should first look at the different type of people that ask this question and first ask them a key question: What do you want to be in the game industry? The answer to this isn't always a game programmer. Believe it or not, some artists ask this question, and I don't blame them. The more technical skills any artist has, the better they're going to be at their job. So, I've broken this down into three groups:

Programmers

If you want to be a programmer, and I mean a "real" programmer, and you're at least fairly comfortable with a computer, I recommend you start with C++. A lot of people are going to yell at me for this, because they think C++ is prohibitively hard to learn, that it's on its way out, that it will be taken over by more interpreted languages like Python or C# and that a programmer learning C++ is wasting his or her time. I don't buy it. Almost all AAA game companies still use C++ when it comes to systems level programming, and I don't see that changing any time soon. And even if I did, I'd still recommend C++. Why? Because you are always more comfortable in the language you start in, and C++, through its many idiosyncrasies (and, honestly, poor language design) forces you to think about things like memory management, simple optimizations, side effects, const variables, const methods, references, pointers and (as you get more and more advanced) things like v-tables, performance of virtual methods, memory layouts, and memory trashing. More modern languages do all they can to protect you against some of this stuff, but even they have weird performance pitfalls that, unless you have a sound basis in "close to the metal" programming, you won't fully understand and that you won't be able to optimize away.

In addition, many, many languages, are based off of C++ in some way shape or form. Regardless of whether they carry over any syntax or keywords, far too many languages are classified as "C-like" (including many scripting languages) for you to ignore it and think you'll be able to slide by without a full understanding of it.

That said, if you're in middle school or early high school, I will say there is no problem learning other languages that make your programming life easier, like VB, Python & PyGame, DarkBasic or C#. By the time you hit college, through, regardless of whether your school teaches it or not, you should be learning C++ on your own and some of the libraries that are used in game development with it (either OpenGL and / or DirectX, with a smattering of Win32, just for fun ;)).  Just be aware that if you're starting in a higher level language, that you may be forming some bad habits that may end up being hard to break.

Designers

Okay, so you want to be a designer. Join the club. Now, everyone wants to be a designer, and my advice for this was, not too long ago, think of something else to do. That is no longer the case. I now believe you can become a designer in the industry, just not the role some people think (aka, not the person who comes up with the idea for the game in the first place). Regardless, I won't go into detail about this in this article, suffice to say most designers should learn programming in some form. My recommendation is to learn the languages you will most likely use on a daily basis, and those are the languages that are used to automate tasks in Excel. This means VBA and VB.NET (and / or C#). You will be surprised just how powerful these languages are, and how much more effective you will become at working with Office after having learned them.

If you're really adventurous, you may also want to learn a scripting language like Lua or Python, and learn a game making framework like PyGame. Why? Well, cause, then you can make your own games pretty easily, and that's what you wanted in the first place right?

Artists

For your run of the mill artist, I say learn two languages: MaxScript (for obvious reasons) and Python. Unlike MaxScript, Python is actually used in other places than art, and is a more fully featured language. However, it's also integrated into most art tools, including Maya, so you waste no time by learning it. As a bonus, Python has PyGame, which means if you have even the slightest understanding of Python you can actually make your own games without programmer assistance. And if you can do that well, I hate you, as I have no art skills what so ever.

I also recommend that artists at least take a look at C#, as many game companies are starting to integrate C# into their tools pipeline, and a smart tools engineer will find ways to allow small C# "scripts" to be run on top of their tools (this is actually very easy to do, though it takes a bit of forethought in the tool's design, but I digress). Anyway, learning the language won't hurt you, and may help as C# becomes more common.

What about…

So, many people will read this and wonder what happened to their favorite tool or language. Flash and ActionScript in particular are missing, as are the scripting languages for tools like GameMaker. Well, in my mind these are specific tools, and if you want to use these tools (or you're forced to use these tools), then obviously you will have to learn their languages. The good part is that, as you learn programming languages, it becomes easier to pick up other programming languages, and the ones that I've mentioned as places to start are all languages that will give you a firm enough basis that you should be able to pick up other languages easily. I don't see the purpose of learning a specific language first. Their applications are so limited that their practicality is diminished.

So I hope that answers the question about what language you should learn. Hopefully this helps point some people in the right direction. Good luck everyone!

Thanks to a lot of help from Darren, today we're officially announcing the release of AngelXNA 1.0. For those that don't know, AngelXNA is a port of the Angel prototyping engine made by EALA and released open source not too long ago. The justification for making a C#/XNA version is that I, personally, like working with C# more than I like working with C++, at least when I'm trying to do prototypes. C# allows me to program faster and worry less about things like memory leaks, memory trashing, and weird side effects. By utilizing XNA, we get a lot of stuff for free, including input handling, sound, and music handling, along with the possibility (though it has not been tested) or running prototypes on the 360.

The interesting thing about creating / porting Angel was a question Darius posed to me while we were working on it, which is this: were there any decisions we'd made about the design of Angel that favored simplicity of creating games over speed / efficiency? Did we do anything that we wouldn't do in an actual game engine, just because it made programming games simpler? It\'s a pretty good question. Certainly, neither Angel nor AngelXNA take advantage of memory optimizations like object recycling or pooling, and there's no inline optimizations in AngelXNA. In addition, we didn't optimize any of the rendering or animation systems by doing things like pooling similar objects together, and AngelXNA ends up opening SpriteBatch blocks a bit more often than it should. But the question is could either version of Angel be optimized this way and still keep the same interface? It's a pretty good question, and right now I'm not sure. Regardless, I think AngelXNA is pretty easy to develop on and runs fast enough to make it a pretty nifty prototyping system, so at least that part is a success.

If you'd like you can grab the v1.0 tag from our bitbucket site (zip direct link), and Darren did a great job of creating some initial documentation on the wiki, so please check it out and tell us what you think! Darren and I (and anyone else who\'d like to contribute?) will be looking at moving on to version 1.1 soon, which should include some simple pathing using A* (something that\'s in the original Angel) and some other simple AI.

Gamasutra has an interview with VP of PR and Marketing for Bethesda Pete Hines about DLC. The article is pretty interesting (at least the DLC parts) and if you're at all interested in the subject I suggest taking a quick read. I wanted to make a few comments on it (as I'm interested in DLC models in games), but first I have to do a quick disclaimer first, so here it goes:

I am a former employee of Bethesda, but any comments I'm about to make do not reflect on the company's opinion of anything. I was never in any position to make any decisions about the design of their games, the business model of their DLCs or anything related to anything other than the lowest level system code. DO NOT ATTRIBUTE ANYTHING I SAY TO BETHESDA OR EVEN TO A FORMER BETHESDA EMPLOYEE PLEASE!!!

With that out of the way, I'd like to comment on Pete's stance on large expansions as DLC:

What we discovered was that we want to be able to do stuff that doesn't take a year to come out.

All these people are out there playing our game by the hundreds of thousands on a daily basis and we want to be able to bring those folks something they could do in a much shorter time frame, rather than just saying, "See you next year." That instantly ruled out doing a big expansion because those things just take so damn long to do.

I'm only partially with him on this one. I honestly think Oblivion got it right. Offer a wide gambit of stuff to get: small digestible chunks along with one (or two) big expansions. That way, you don't have to say "See you next year" and you still provide a big expansion, which increases the visibility of the game immensely (and encourages people to get more DLC). With the excellent design and art team they have at Bethesda, splitting the group into a set of small(er) DLCs and one large expansion just makes sense to me. It keeps the game fresh for those that are going to want things fast, but also increases the game's and DLC's profile when a giant expansion comes out.

I also think that there's one model that Bethesda isn't touching on, and I hope more companies think about as a future revenue model soon. That model is episodic DLC content; content that builds off of itself and is offered (say) once a month at a reasonable price point, then bundled together at the end. A game like Fallout or Oblivion (it seems to me) is the perfect place for something like this: a full game that's expanded over time with DLC. It strikes me as a better alternative to games like Gears, which were episodic, but at a full price point for each title, and on different disks. I think we're still placing too much emphasis on engine improvements when in some cases people just want to continue the game. Sure Gears 2 looked better, but couldn't they have released DLCs to continue the plot while working on the next engine in parallel?

Interestingly, it's been my prediction for a long time that more and more games will start looking towards DLC and episodic models to create games. This doesn't mean we'll see the end of "big blockbuster" games any time soon, but I think it will not only become more and more common to release things episodically, but almost an expectation of the audience. Already, you're starting to see games sell on the promise of DLC, or demands for DLC after a game ships (like Mass Effect). I think this is only going to become more common.

Right at the tail end of GDC, Microsoft released to developers the XNA Community Games sales figures. While many of the top sellers are keeping their data private (including Miner Dig Deep and the Masseuse products), many have released their data to Gamasutra, which has a very nice in depth discussion. The general consensus? Most developers are disappointed.

Now before I get into defending Microsoft and the XNA platform as a whole, let me say that the release of sales figures after GDC was certainly not a mistake. If sales had been going well, Microsoft would have done everything in its power to get those figures out either before or during GDC in order to bolster more developer support for the platform. As it is, they knew most developers would be disappointed with the figures, and thus waited until after GDC when the news would have the smallest impact. PR guys are smart like that. So trust me, Microsoft knew you'd be sad and is trying to cover up its mistakes on the platform.

Now I'm going to play the devil's advocate against the indies here (who I respect greatly), and just say that I think Microsoft is getting a bad wrap for poor sales figures. Most of the articles I'm seeing are about how Microsoft isn't promoting the platform, and how Microsoft isn't promoting their games, how Community Games are hard to find on the NXE (TRUE!!! I complained about this already!). No one's blaming themselves for the lack of good games on the system, which is relegating it to second class citizenship. No one is complaining about their own lack of marketing. In fact, some of the games that have pretty good sales figures (not great) are marketing themselves, and are seeing profits as a result. You can't expect Microsoft to do all of this for you, just because you're on their service that they provide you mostly for free. That said, even those with good marketing (like Weapon of Choice) aren't doing great, but at least it doesn't look like they're blaming Microsoft at all. They're just disappointed.

Of course, many are taking this opportunity to talk about how much better iPhone would be to develop for, but I can't stand these comparisons, mostly because the type of game that is going to sell well on the iPhone is going to be different from one that is going to sell well on a console. iPhone is all about the impulse buy. $1 for some small app that looks fun that I want to play right now because I'm bored on a bus, or that serves a need I have right now, but may never have in the future. If that's the game (or app) you're developing, you need to be on iPhone because your game isn't going to sell well on XBLCG anyway. Console sales just are not going to work that way, and you shouldn't expect them to. The amount of money, time, and polish that needs to go in to something that will be sold on a console is higher (IMO) than something sold on a mobile platform because it needs to capture the user's attention for longer. On iPhone you develop for a short attention span, and on XBLCG, you need to develop for the longer attention span. It's just necessary.

Lastly, I want to reiterate how Microsoft and Apple are the only people that are providing an open platform for development, and should be lauded for that alone. It seems both companies thought of the idea at the same time. The 1.0 refresh of XNA was released in April of 2007, a full year ahead of the iPhone SDK, and Microsoft announced Community games in February of 2008, a month ahead of Apple's SDK announcement (which included their app store announcement). However, Apple shipped first and with more features (including sales figures) starting in March of 2008, whereas the NXE (which included the CG store) launched in November of 2008, and didn't get sales figures until last week. In general, both companies deserve kudos for opening previously closed development platforms, and for giving the average person the opportunity to make money on the platforms, but when it comes down to it, they're still very different platforms with different concerns, and attempting to compare them (in my mind) is absolutely ludicrous, so much so that I won't even talk about the millions of features Microsoft HAS to offer in order to keep up with their own XDK technologies (including parental control) that Apple hasn't even touched on yet.

Really lastly, I have ideas on what really needs to happen for CG to really be a "quit your job" platform, but that will have to wait for another post.

I just finished watching this presentation from OSCON from the founder of Sxip on what he calls Identity 2.0. He also runs a blog by the same name.

I really liked this presentation, and I think he's moving in the right direction for creating an identity system for service / website authentication and online identity management (which, if you've been paying attention, has been a huge concern of mine recently). The one thing I'm not hearing is the ability to manage multiple versions of my identity. Dick talks about how he's a Canadian and he lives here and has x, y, and z. But what he doesn't talk about is how to handle having 3 email addresses, 4 sets of contacts, a business calendar, a personal calendar, and 3 shared calendars.

So, Sxip is an excellent step forward. Now I can verify who I am to any site. Now the question is how do I verify portions of myself? How do I tell the site to work with only a subset of my information without having to manually select small parts of it? How do I log into the same site 3 times without using different browsers (looking at you Google)?

These are not simple questions, and they don't have simple answers. I think online identity management is going to be the number one issue of the next 10 years, and I'll be surprised if it's solved even then.

My friend (and Microsoft employee) Steve shared a video with me that is kind of a concept video for what Microsoft sees interfacing with computers will be like in 2019. The original post for the videos is located here and is really cool. Cool enough that I felt the need to comment on it, at least a little. In general, I think the concepts are pretty achievable, if not by Microsoft than at least by someone by 2019. The general concessions throughout the video are that the future of interaction is:

1. Very thin, multitouch screens and surfaces, that will be prevalent in every aspect of your life.
2. Lots of portable devices, with screens and without, that will automatically detect each other and react accordingly
3. Lots of systems that use digital paper or some form of digital paper.

I think most of this is achievable, but there are a few things that stand in their way, even for these assumptions. For the second point, you HAVE to have a better networking protocol than Windows Networking, and a better discovery system than Bluetooth. mDNS / DNS-SD may be a start, but I don't know of any good protocols that exist to automatically detect new devices in close proximity to each other, and what services they provide. That's the first problem that has to be solved, sooner rather than later. For the third part, you first have to make digital paper affordable. That's an issue, as it's out of reach for most consumers right now. Maybe by 2019 I'll eat my words, but I don't see it being economically feasible any time soon.

In addition, there are a few things I have to say look cool, but I don't see being in the future.

Right at the start of the film (at about 10 seconds in) the system recognizes that a girl has drawn a dog, and what's there acts like a dog. I'd be surprised if that's actually achievable for everyone's version of a dog, especially for a 10 year old's drawing. The ball part is realistic, but having the system recognize "dog" and "ball" and have them interact… that seems a little pie in the sky to me, and this is coming from a game developer. Let's face it, even Spore had to seriously limit their drawing capabilities to enable their procedural animation system.

At about 3:46, we see somewhere where identity management becomes an issue. Would it be awesome for me to just carry around a device that had all my meeting notes on it, and have it automatically detect a co-worker's computer, network to it, and show communication history on a set of projects? Certainly. And it's certainly possible. But what if I store personal things on that same keychain? Or conversations with other clients? I don't want the business table showing that. I don't want it reading it, or attempting to read it. I don't want to have to specify to the table right there "This is what you have access to." In some cases, I just want it to know. Identity management is a huge issue there, and no one's solved it, let alone Microsoft.

Starting at about 4:10, we have that digital paper problem. Not only is it inexpensive digital paper (I assume) but it's touch screen, foldable, networkable digital paper. This seems a little far fetched. I look forward to hardware companies proving me wrong.

Aside from these problems, much of what's there gets me excited about the future of interactivity. I certainly think the future will look similar to this, but I think the larger issues of identity and task management are far from solved, and more important than the flashy ability to point at a piece of information and drag it to your tablet. This type of interactivity is going to require a new way of looking at how we want to share information, with whom, and when. It's going to require a new look at how we group pieces of information (Mozilla Labs is actually more interesting in this respect) and how we use applications together in tasks, projects, etc. That's solvable now (in some cases) but even Windows 7 (as cool as it is) only begins to scratch the surface. In addition, this goes beyond the Office team, and should be looked at by Microsoft as a new initiative, to break free of the start menu, task bar, quick launch, etc. and start thinking about how all of their applications work together to form a meaningful whole in this fashion.

I'd love to be a part of this, but I work on games right now… and I don't see that changing soon.

I apologize for being quite silent on this blog recently. I've been super busy with work, personal projects, and my new blog, the Toolsmiths. In general, I'm super excited about the success of the Toolsmiths. We've been hit on reddit twice (with HUGE traffic spikes both times) and the comments have been generally excellent. I'm hoping that the momentum will continue straight into GDC, when I'll be hosting the Tools SIG roundtable to discuss the various ideas for the direction of the SIG in the coming year. The blog was a great start, and I think it has gotten people excited about the Tools SIG again by making it visible. Now we need to leverage that into community projects that can actually help the community.

As a side note, I can really only act on all of these plans if I'm elected Tools SIG chair. If you haven't voted yet, please remember to vote soon, as elections close on Friday.

In addition to the Toolsmiths, I've been working on some small side projects, including a port of Sort to XNA, and a port of Angel to XNA. I know a lot of people are interested in the Angel port, and so far it's coming along very nicely, though it does have a lot of differences from the original Angel (especially in the rendering department, obviously). Hopefully I'll have my first alpha for that available after GDC, but we shall see.

I took part in the Global Game Jam this weekend, and I have to tell you, it was a lot of fun. Version 1 of the game we created, The Game Of Nom, is available from the Global Game Jam site, and was voted third favorite at the location we were participating in, and I think that was a fair place for it to be (Move Mouse To Fulfill Destiny and The Beat were really awesome). I'm really happy with how the game turned out. It had the right feel and I think it really extracted the emotions from players that we wanted. The rules were simple enough that you could easily sit down and play it, hard enough that you could play for a while before winning, and interesting enough to be fun. That all said, the game is fairly buggy, especially when you're moving around flocks or trying to combine them, and that's a huge detriment to the game. At some point, Darren or I may actually fix a few of the issues and post a new version on the game jam site, but don't hold your breath.

So, for my own sanity and for future reference for everyone, I thought I'd do a post mortem of my experience.

What Went Right

1. Enlisting the full time help of an artist. Amanda did an amazing job of giving us a feel for the game very early. I have no doubt that without her, the game wouldn't have been nearly as fun or interesting, and wouldn't have achieved this balance of fun and message that we wanted. By having a cute style to the game, we were able to present the dark message without seeming overly pretentious, which was awesome. My new rule is "artists make things look cool quickly," so get them involved early and things will look cool early, and get everyone really energized for the rest of the jam.
   
2. Having a team. The first game jam I participated in, it was just me. Now, that was great for rapid iteration, but not for making something really interesting. I didn't have anyone to bounce ideas off of, and no one to really keep me focused and in line. Working with Darren not only allowed us to do something a little bit more complicated than we would have been able to do alone, but also ended up producing a much better product.
   
3. Not sweating the small stuff. For the most part, I think we did a good job not worrying about some of our problems until later, and getting the game playable quickly so we could test it and refine it as needed, instead of spending lots of time doing things like improving the flocking behavior (which, I'll admit, I spent a little too much time on anyway ;)). The key to Jams is knowing when things are "good enough," and I think we did a pretty good job with that.
   
4. Tools choice. Although we had some problems with it, XNA/C# is a really great prototyping language. Right before the Jam, Darren and I were considering other options, including the beta of Unity that was made available to the jammers. The things was, we didn't want to spend lots of time fighting to get things on screen and working, when we could spend time on the game play. XNA didn't give us a lot of pain for our simple little 2D game, and for that we were pretty thankful.
   

What Went Wrong

1. Needing a prototyping framework. XNA is awesome, but it's not a great prototyping framework. As I don't do too much prototyping, I really don't know what I need and what's overkill. I found that the two things I really ended up wanting / needing were a simple object manager and an actor framework / state machine framework. We actually implemented states very late in the process and they were very hacked together. I found myself wishing we'd had OnEnter / OnExit / ChangeState for the little blobs frequently, but implementing states would have taken more time than hacking around them. In this respect, we maybe should have gone with Angel which has that stuff already built in, but it'd come out the day of the Jam, and I didn't want to try to learn it while Jamming (I've learned my lesson from the OLPC jam).
   
2. Clear message, not so clear implementation. We knew what we wanted to get across to the player early, but not how to do it, and trying to discuss it mid jam was hard. Another twenty minutes talking about implementation would have helped, though during our initial discussion I was itching to get things running. What we really should have done is a "stand up" style meeting when everyone arrived in the morning to discuss where we were, and where we wanted to be each day. I think it would have helped a lot.
   
3. Not enough testing / balancing. We should have pulled in more people to play the game earlier, and should have gotten things for Amanda to play so he should see the results of her art changes quickly. As it was, I spent most of Saturday and Sunday balancing, but was so close to the game that I missed little problems. Having just one person play mid-day Saturday would have exposed lots of problems that could have been fixed by the deadline.
   

I'd love to know what people have to say about the game. We're rating well, and I think if we get around to fixing the bugs, it will rate even better. Thanks to everyone who organized the Game Jam for this great opportunity!

So, if you haven't noticed, this blog has been a little quiet recently.  It's not because I don't have a lot to say, but because I haven't had the time to say it.  One of those reasons for that is because I've been spending a lot of time working with the IGDA Tools SIG (which I've talked about before) to launch a new collaborative blog: The Toolsmiths!

The new blog has two other great authors, Geoff from Insomniac and Dan from Robotic Arm Software.  I'm really looking forward to the content we'll have over the next year or so, and I hope anyone interested in game tools will take some time out to read our posts.

My first post, on continous integration and build systems, will appear on Wednesday.  Hope you enjoy the new blog!

So this post has nothing to do with games, and more to do with just real world usability of applications. It's a rant I've been talking to people about for a while, but I decided to get it up on my blog for people to discuss in the greater cloud of the web. Generally, the post is about the battle between Microsoft, Apple, Google and Open Source. Not from a doctrine perspective, but entirely from a usability perspective.

The Apple Approach

So, without a doubt, Apple has some of the best usability in the market. There are lots of reasons for this, but the one I want to focus on is their tight application integration. Apple products understand other apple products really well. Syncing an iPod or an iPhone through iTunes is ridiculously easy, because it's designed to be easy for 90% of the customer base. That's why people use it. And no other company can control the hardware and the software the way Apple can.

Then there's the other 10% of the customer base. People like me that would rather use other applications to sync their music collections to their iPod or iPhone. This is where Apple fails. In an attempt to make sure that you always use their software with their hardware, they've unnecessarily (and sometimes very purposefully) obfuscated the way an iPod sync works. Certainly, certain products can do it, but from my understanding these products have reverse engineered the iPod database, and this reverse engineering frequently breaks when Apple releases new versions of their firmware.

Now, Apple has a good reason for this. They want things to be as simple as possible for the 90% of people that own or want an iPod. But what they don't do is make it easy for the other 10% that want an iPod, but have use cases outside of the bounds of what they offer.

The iPod / iTunes integration is just one example, but Apple does this all the time. Very rarely does Apple offer a product that communicates in a standard way unless that standard is so ubiquitous that they have no other choice. So Apple is tightly integrated, with no loose coupling.

The Open Source Approach

Open Source has the opposite approach. Loosely couple everything and have the programmers sort it out. This means, a lot of the time, that the average user is completely screwed. Figuring out how to get two systems to talk to each other in the Open Source world generally requires some wicked voodoo magic. Everything understands everything else, but only if you're really careful and tell them where and how to contact each other.

Now, this is a blanket statement, and I know many applications have improved in the Open Source world concerning this, but the problem is that when you allow everything to communicate freely, you lose any possibility of creating a reasonable user interface that would have come about through two products having tight integration. It's great that every open source calendar product understands iCal, but if you can't get them to communicate easily, what's the point?

The Microsoft Approach

Now, Microsoft is interesting because it's schizophrenic when it comes to integration. Individual Microsoft products are tightly integrated with a strange variety of loose coupling (or at least have been in the past). Applications like Office, Windows Media Player, Visual Studio, and others, are very tightly integrated with themselves, and they offer the options for extension and integration with other applications, so long as you're working within a very tightly confined area that Microsoft has defined.

This is basically Microsoft's history: offer a lot of developer support and allow extensions for almost everything you do, but only so long as they're developing for your platform. Only in recent years has Microsoft opened their data exchange systems so that applications outside of the controlled Microsoft environment can potentially understand what's going on.

The problem is that outside of a single application, Microsoft doesn't integrate with itself at all, and depends on third parties to offer features that are prominently displayed in Apple software. Is this bad? Well, for the average user… absolutely. Say, for example, that I want to order a set a pictures from an album I've made in my favorite piece of photo software, or let's say I want to publish them online. This can easily be accomplished from both Microsoft's offering and Apple's offering. The problem is that Apple has an offering that it owns and prominently displays as an option. Microsoft, on the other hand, would allow you to sync to any number of picture website systems, but you'd have to do some searching. The average user can't be bothered with that, and even if they could, the number of options is way too overwhelming. The average user is more likely to get confused than actually published their pictures online.

In my opinion Microsoft's approach to letting 3^rd parties integrate into (almost) any piece of software they make is the "better" option, as it encourages independent development. The problem is that it only really helps power users, and hurts their general interface design. So, with Microsoft, you don't get the benefits of either the tight integration or the loose coupling.

The Google Approach

Just when you though Microsoft was schizophrenic, along comes Google. Google boasts over 13 products that integrate with your Google account, and they… well sort of, kind of, not really integrate together. Mail allows me to look at my documents and calendar (through a Labs extension), as well as allows me to add information to my calendar by detecting information in emails. But the whole system feels very disjointed. More importantly, the communication protocol between the applications is proprietary and hidden (so far as I know).

Things become more interesting when you talk about the new G1. Here's a phone that's based on an open standard for communication between applications and wants them to behave like they're tightly integrated without using tight integration. But apparently the first thing the G1 does is force you to sign in with a Google account, something you can't change. What if I want that phone, but not a Google account? Really, what was the point there?

The problem with Google is that it offers a lot to users in weird chunks. There's no unifying vision like there is with Apple, and its developer support (at least for its applications) is spotty. So you don't get external extensions and you don't get tight integration. It's the interface of any given application that draws you in, but is anyone really happy with how it works beyond that?

The End All Problem

This all comes to a head in one way: the management of your multiple personalities. My name is Jeff, and I have 3 identities on the internet: Jeff as employee and co-founder of Orbus Gameworks, Jeff as an IGDA volunteer, Jeff as just me. In some places, I want to have access to all of these personalities at once (say on my phone). In some cases, I want to share just select information with other people. I want to share my business calendar with my business associates, for example, and I want to share my personal calendar with my friends. I want my phone to have access to all my business contacts and personal contacts, and sync them to the proper places, and I want my music to stream be able to sync to my home computer and maybe my work computer without issue.

The problem with tightly integrated software is that it either can't or doesn't understand this concept. You are you regardless of what you say. The problem with loosely integrated software is that you don't get the usability of power of integration. You have to play the game tight and loose. Tightly integrate across platforms and across communication lines while communicating via loose protocols that anyone can understand.

Will this ever happen? Who knows. The problem is that each company has to fight significant hurdles to make a tightly integrated, loosely communicative application suite. Apple has to open up communications and fight against their urge to make integrated suites. Microsoft has to integrate more, communicate more loosely, and become less schizophrenic when it comes to application design. Google has to decide what they're doing, and Open Source has to get some user interface designers (seriously guys, you're killing me). It's an uphill battle for everyone.