I presented this evening at the ACC. I think it went well. I’m definitely out of practice. The slides probably won’t be interesting without the talking, but in case anyone is curious: The Craft of Gamemaking.

If you saw the presentation, I’d love to hear from you in the comment section.

The Flash Player provides vector-perfect collision detection with the hitTest() method. The drawback of this method is that if you use Bitmaps it sees just the bounding-box of the Bitmap, i.e. it ignores alpha. This is pretty frustrating when it comes to a sprite-based game.

A bit of digging on the web found a quick and simple solution from Andre Michelle [.zip]. A slightly more robust version was written for AS2 by Grant Skinner, then ported to AS3 by Boulevart. I grabbed their version to start with...

First, I cleaned up the code and commented it. It's pretty straightforward: you render two display objects to separate color channels, combine the color channels, then search the resulting image for any overlapping color (the previous two sites have deeper explanations).

I found two problems with the code. First, it unions the bounding boxes of the two display objects. This is unnecessary, we only care about the pixels in the intersecting rectangle. And since performance hit of this technique grows with the size of the overlap, this is a critical optimization (you're allocating significantly less BitmapData each test).

Second, the code doesn't account for a display list of any complexity: it assumes the two display objects have the same parent (and are thus in the same coordinate space), and it assumes the display objects do not have any scale or rotation (it only considers linear transformation, i.e. the objects' positions). I fixed both of these.

So, the new code will determine if two DisplayObjects are visibly overlapping with pixel precision. Enjoy!

Have I mentioned how much I like Flex? The ActionScript3 (EMCAScript/JavaScript) language is a pleasure to program in (garbage collected, dynamic *and* static typing, single-inheritance class hierarchies and built in XML (E4X) manipulation). Flex Builder 2 (which is Eclipse) is a spectacular IDE (trumping, dare I say, VS.NET 2003, my prior fave, but only with Visual Assist -- Visual Assist still trumps all). And the inclusion of declarative (MXML) programming hits a perfect sweet spot in my long time HTML coder's heart. It just seems perfect.

You know, kinda like exactly what I said would be the perfect game development environment back in March 2006. I sung the praises of the mindshift in software development brought on my "web 2.0" where production-quality development truly is agile: they divide the problem into structure, behavior and styling. Of course. The Holy Trinity of Interaction. You find it time and time again when you dissect anything one would describe as interactive: model-view-controller, input-process-output, listen-think-speak... structure, behavior and styling.

To recap: structure defines the layout of things, their relationships, both spatially and conceptually; behavior consumes the structure, plays on the structure like monkeybars, moves through it. And styling determines how the structure is presented, provides feedback, expresses.

In practical software development terms, I've discovered that means one needs a declarative language (MXML), an imperative language (ActionScript3), and support for skinning and/or style sheets (Flash, CSS). Flex bundles all three together.

Of course, it has a good application framework provided out of the box (that's free, in fact, along with the compiler... you just pay if you want the IDE, which is Eclipse, so you're actually just paying for the visual MXML editor, which is probably worth it, but certainly not required if you're patient or are experience with HTML/CSS). I can't imagine if there was a gamedev framework for it... that'd be sweet.

Chalk up one for Adobe (via Macromedia): Adobe Flex 2 is the finest software development kits -- nay, platform! -- that I've ever had the pleasure of dealing with. And this coming from a guy who's spent the last five years convincing game studios to adopt a commercial SDK (RenderWare), so I can smell my own kind... and I don't smell Flex at all! Clean as a whistle...

I think they will seriously give C#.NET a run for its money. Sure, C#.NET is probably faster on a Windows box, no doubt about that... but is it that much faster? And .NET certainly doesn't have the Flash graphics engine backing it up (your toolchain is already finished!). And it only really works on MS devices. And you have to download and install (and in Vista, enter an admin password!) because its a native EXE with all of the potential problems.

While Flash... well, Flash is ubiquitous. Hell, it's more standardized across user machines than Java or web browser and most certainly operating system. And your input, output and everything in-between is identical on whatever platform your user is using.

And, and, and... it's all sorts of integrated with and designed to a leverage the always-on-net-connection world that many, many of us live in.

Go now, you can buy it off the shelf. I did. Best $500 I've spent in a long time. No regrets.

I'm now firmly back in Austin, Texas. Feels good to be here. Warm weather, breakfast tacos, NPR, pancakes and all of the local businesses... it certainly feels like home. Of course, there is still a mountain of boxes to unpack (amazingly, unpacking boxes goes pretty slow with a six-month old and a new startup!). Oh, and Christmas shopping... So, I'm really looking forward to getting to the other side of the holidays so life can somewhat return to a normal pace...

People are asking what I'm working on, and I've given some veiled hints. And there are a few folks I've actually explained it to offline. The reactions have all been positive -- dare I say, excited -- so far. Of course, my powers of persuasion are legendary (why do you think EA acquired Criterion? ;-)).

Here's the big, big, big picture goal: to make game making a purely creative process, to eliminate the drudgery of engineering that it currently requires. If technical neophytes can create web pages and edit videos, then why can't they make games? Because we're special? I don't think so. Because it's interactive? Folks get board games, and when they were kids, they certainly made up alot of games on their own. So, as educated adults who can use a computer well enough to surf the web and download music to their iPods, how come they can't make a PacMan clone?

It's time to stop approaching the problem from the engineeer's perspective, which is exactly what XNA does... it's an SDK. It's not the YouTube of video games... it's the RenderWare of hobbyist programmers! Not a bad thing, not an unwanted thing, but not everything it could be!

It's time to throw off the shackles and storm the gates... the audience will only grow in relationship to the number of creators, and the number of creators will only grow if we mature the tools and lower the barrier of entry. Anyone can pick up a paintbrush... anyone can make a game.

So, now what? That's the question many folks have been asking me over the last few weeks, since I announced my departure from EA. I've had to be understandably coy about the whole thing as to not ruffle any feathers at the mothership... I've got enough going on with an international move and such to not have to fight one last political battle.

International move, you say? Yes, we (me, the misses, the baby girl) currently live in Vancouver (well, Burnaby, but that's besides the point). A week from now, we'll live in... well, in limbo, as it takes a while for all of our belongings to make the long trek from Vancouver to Austin, Texas. We'll hang around our parents' homes in Northwest Arkansas, enjoy Thanksgiving (American-style), and introduce our baby girl to all of her uncles, aunts and cousins. Two weeks from now, we'll be sitting in our new home in Austin, unpacking what I'm sure will be several million cardboard boxes (now, where's my crowbar...).

So, that's the physical "now, what?" over the short term. But what's really going to happen? What are my next steps professionally?

Well, it's still a little too early too say. It's not that I don't know... I've known for nearly six months! But, due to my employment contract with EA, I was unable to act on my plans for world domination. It'd be no good if I went and created the "next great IP" and it defaulted to the folks who paid my bills, now would it? Thus, these next few weeks will see the creation, tangibly in copyrightable form, lots of IP.

What is this IP, you ask? Well... I can't say now. I've spoken to some offline about it, to make sure I'm not crazy, and responses seem to favorably indicate that, at least in respect to this idea, I am not crazy. In fact, it sounds as if I may be providing an honest-to-goodness service for my fellow developers.

Service, you say? Games aren't services! No they're not. I am not making a game. You are. We all are. Have fun!

Can we apply David Allen's Getting Things Done process to software development? If it can organize the hectic life of a Fortune 500 CEO, couldn't it help out the lowly software developer? A recent blog post from a coder in the Google trenches, "Good Agile, Bad Agile" suggests to me, "yes."

This morning, I read a post over at King Lud IC that seems to indicate I'm not the only one who read "Good Agile, Bad Agile" and thought, "hey, this could apply to gamedev!" Of course, there are already folks applying the Agile process to gamedev (notably, the folks over at High Moon Studios). From the sounds of it, they're happy and successful. But, I know Clint (High Moon CTO) and Noel personally, and those are two guys who I'd expect could make any process successful. They're dedicated, meticulous, and above all clever. How about the rest of us?

Like many web professionals and software developers, I've been lured by the cult of personal productivity. It's rather ironic, then, that I'm also infamously considered a procrastinator and referred to by my parents (when speaking to their friends) as "extermely laidback." Of course, I own up to both of those descriptions. Perhaps they're the underlying motivation for my constant pursuit of a "better system"?

I've found Getting Things Done (or GTD as its referred to by those in the trade) to be an ideal system. It has some basic rules, some lose theory around those rules, and a whole ecosystem of software and blogposts guiding anyone wishing to embark on the journey. For purposes of this discussion, here are the basic tennets (cribbed from the 43Folders linke above):

• Identify all oustanding issues (close all open loops).
• Get rid of everything that doesn't need your attention right now (delegate, defer, delete).
• Create a central repository for everything that works for you.
• Put stuff in the right place, consistently.
• Work based on time, effort and context (do the right thing at the right time at the right place).
• Repeat, and refactor mercilessly.

So, how do we apply these tennets of GTD to the software development process? Or more interestingly for the readers of this dear site, how do we apply this to game development (thinking of the indies)?

Identify all oustanding issues (close all open loops).

I find this one to be the most satisfying, the most fun. It's the carrot that really gets the process moving along. It's brainstorming, but with more depth and detail. You'll want to make an exhaustive list of all design features, technology hurdles and content requirements. Don't stop and do anything, and don't spend too much time thinking. The goal is to make as complete a document (list) as possible of what needs to be done. Try to be as specific as possible, but don't worry too much about the granularity (as that will solve itself later). You should be telling yourself, "if I don't write this down then it's basically like it doesn't exist." Make your thoughts tangible, or they'll never happen.

Get rid of everything that doesn't need your attention right now (delegate, defer, delete).

The three D's: delegate, defer, delete. There are lots of details you won't have to worry about. If you just starting your design for a new game then don't fret over how you're going to collect credit card payments when its finished. You can worry about that if and when you finish the project. If you're the programmer and you're not quite sure how the artists are going to produce all the content for the game, stop, delegate that to the artist and have them worry about that. This is all in an effort to save you from the fourth D, distraction.

Create a central repository for everything that works for you.

I'm using activeCollab, a web-based project management app (a free, self-hosted competitor to Basecamp). Basecamp is a great option as well. Large organizations often use Microsoft Project. I'm sure there are other options as well. A simple to-do list could work as well, but the less structured it is the more onus is on you, the user, to keep things organized and useful. The critically important thing is that the repository is something that you'll use, and use often and regularly. As a result, I'd suggest using a piece of software that you're in love with, if possible, and you want to have an unreasonable desire to go and use it at every chance (to close those open loops).

Put stuff in the right place, consistently.

If you think of a new idea, put it in the repository. If you run across a bug, put it in the repository. Whatever you do, don't have multiple places for these things to be kept; keep it all in one, centralized spot. Don't keep a notepad on your desk and promise yourself you'll type the stuff up in a few hours or at the end of the day. Do it now. The advantage is that you get these "open loops" out of your brain so that your brain can be used for more productive things. Computers are great at "remembering" things, let them do the grunt work.

There's one exception to this: the two-minute rule. If you can act on something in less than two minutes, then do it. The overhead of "using the system" isn't worth it for something so small. Two minutes isn't an absolute, but don't stretch the exception too far or you defeat the purpose of the rule (as you start to get distracted!).

Work based on time, effort and context (do the right thing at the right time at the right place).

Multitasking is trivial with modern computers. While context-switching is one of the most expensive "atomic" operations a computer can perform, it still is well under a second. For people, on the other hand, context-switching is expensive, very expensive. It breaks "flow." So, instead of just plowing through your lists of tasks in the order they come, divide them into "contexts" that dictate when the appropriate time is to work on them. This is particularly useful for the one-man-gamedev-shop where you wear the hat of programmer/artist/designer/producer. I'd recommend having contexts like: Photoshop, Websurfing/Research, Visual Studio, Level Editor. When you're in a specific context, look to that "list" to see what you should do next.

Also, if your "master list" tracks such useful information such as estimated time required for a task, use that information to as a secondary criteria for context. Have 15 minutes while you wait for some software to download? Do a little websurfing/research. An hour while your significant other is getting ready for work in the morning? Finish the icon for your application in Photoshop.

Iterate and refactor mercilessly.

Consistency in applying these policies is what makes them successful. Refactoring is also a big win.

Now, I don't mean refactoring in the software sense. I mean refactoring the process. Part of the advantage of the simple process and the whole GTD system is its kind of introspective nature, where GTD practicioners are always looking for ways to refine and enhance the GTD system while still embracing the fundamentals of GTD.

But there's an even more particular way in which you should apply the ideal of "iterate and refactor." In the case of your master list, you'll inevitably have items on it that the GTD crowd calls "projects." Projects are tasks that are in fact meta-tasks, something like "Organize the Closet" which aren't really directly actionable. When you hit upon a "project" in your list, you need to look at it and determine what the "next action" is, i.e. what can you do tangibly to move this forward.

In fact, GTD has "reviewing" as an important element of its process. One should regularly (daily, twice-daily) review all of the meta-level stuff, like projects, and determine where they stand (completion, timing, etc.) and populate their master to-do list accordingly. Again, this is an aspect of the "refactoring."

Well... there's a ton more I could write on GTD-as-software-process, and I certainly plan to do that. This post is somewhat vague in areas, a bit hand-wavy in others... it's my first shot at getting these ideas down, but I'll definitely revisit it in the future.

Big announcement today from Apple. Along with all of the nice enhancements to the iPod line, and to the iTunes software/store, Apple made two announcements that stood out to me. First, they announced that you can now download games to your iPod. Second, they announced that in early 2007 they'll release a settop box for your living room.

Games on the iPod isn't too surprising, and actually I'm a bit surprised they haven't embraced that before now. Sure, they had a few very simple games, even on the early iPods, but they couldn't compete with the even the trivial games on my mobile phone. Apparently, the 5G iPods (iPods with video) have enough muscle for some custom versions of very popular casual games, such as Zuma and Bejeweled. Looking at some "animated screenshots" of the games, it appears that they translate very faithfully, even including Bejeweled's cool level transitions (though I suspect they're video clips on the iPod, whereas on the PC they're 3D tunnel effects, but I'd love to be wrong). Of course, the games have been tweaked for the clickwheel interface. I've yet to find any more details, such as whether Apple will be opening up the iPod to other developers or what their future catalogue will look like.

Update: Apparently, some folks have already done a bit of reverse engineering on the games...

I've also not yet found any details on what the processing power of the 5G iPods are. Sure, they can play some pretty high quality video and decompress various codecs on the fly, so they're doing better than my old 286, but they've likely got specialized chips optimized for decompressing streaming data -- chips that are likely not appropriate for general purpose software (much like the vector units on a PlayStation2). If anyone has any pointers to some specs, I'd be interested (the Apple site, not surprisingly, is crawling right now).

The settop box is very interesting. Very small profile (half the thickness of a Mac Mini), and it eliminates all the "clutter" normally associated with media center devices. There's no powerbrick, and the network connection is wireless (with an optional wired connection). I assume it has the same electronics inside it as a video iPod since it can do all the same stuff and doesn't require a powerbrick or fans. I'm curious as to whether they used a standard harddrive instead of the smaller drives used in the iPods to save some money (but it is pretty small!). The price is great ($249), and the usability looks to be flawless (as expected). I look forward to grabbing one, particularly if the iTunes movie service really picks up. (I'm crossing my fingers that they do some kind of rental option, or Netflix-like subscription service.)

But let's put two and two together... they've got games on the iPod. Great casual games, fine-tuned for the super simple click wheel interface. And soon they'll have a settop-iPod in the living room, hooked up to your TV, controlled by a little white remote with the same click wheel interface. While Steve Jobs didn't mention playing games on the "iTV" ... I can't see why one couldn't! It looks to be the same hardware (or at least equivalently powered hardware).

So, my question is this: will Apple bring casual games to the living room? Microsoft is trying to do that with Xbox Live Arcade on Xbox360. And sure, the Xbox360 has all those media center elements like the iTV will. But, this is Apple, and the footprint is significantly smaller, and the interface more dedicated. Could we be seeing the birth of the casual games console?

Just finished reading GBGames' latest blog entry, Facing Reality. In it, he speaks about his guilt for once again having nothing to enter into the IGF, and in general laments the fact that he's accomplished so much less than he expected in regards to indie gamedev (though he has gotten a real, full-time job in gamedev, so he's obviously been doing something right).

I see myself in a similar situation. I've been a judge for the IGF for the last four years, and will be returning as one again this year. Every year I have told myself, "next year I will submit something." And each year passes with nothing to show.

I call myself a "game developer" or "game programmer" because that's what I do professionally, and it's what I pretend to do as a hobby. In fact, professionally, I don't spend any time developing games. I work on game technology (RenderWare, et al). But I don't even develop technology, I support it. So, in reality, I'm a "game technology debugger," practically nothing more than a post-release QA specialist. Sure, I've got a spiffy title (Solution Architect), but that just reveals that I do even less programming and more planning, which just serves to move me ever further from actually making games!

So, while GBGames is lamenting his inability to finish a game, I find myself reminded of how I have utterly failed to start one.

In fact, I used to be more in GBGames' shoes... I started many a game that never was finished. And much like GBGames, what I really was doing was starting a game engine, not a game. I think this is a problem affecting the majority of our community, i.e. indie gamedev, amateur gamedev, hobbyists, etc. In a community largely dominated and driven by programmers the goals (and their solutions) are often framed in terms of technology. I guess it's simply a matter of having a hammer and seeing only nails.

I've tried to break myself from this technology focus as evidenced by my recent forays into Flash and Game Maker. I've forced myself to step away from the 3D that I stare at all day (and arguably have the most expertise in) and limit myself to 2D technology. Even before then, I accepted the fact that I personally was not going to be crafting the next Doom or Source engine, so why participate in that age old arms race? I've also long accepted (and been very vocal about) the fact that technology really means zilch at the end of the day if the game isn't finished. In other words, I am more impressed by a finished game running at 5fps than a tech demo running at 60fps.

Like GBGames, we all underestimate the time requirements. He's made a huge step forward by tracking his personal time with the detail of a professional game producer. At first glance, the 170 hours devoted to his personal gamedev project sounds like an admirable accomplishment. "If only I had devoted that much time to my projects..." But when you break the numbers down, it works out to a little over 3 hours a week. In other words, it's very likely that myself (and most others) are already spending that much time on this hobby of ours (if not much, much more, for those without family obligations -- I'm looking at you, students!). Besides, many decent titles have come out of less time than that, and given the out-of-the-box tech we have to leverage these days, many "classic" titles could be recreated in that amount of time.

One comment in particular hits the nail on the head: "the biggest issue is you’re still working on an engine, not a game." Programming is hard enough when the end result is an executable that someone runs. Programming is even harder when the end result is something you have to turn around and use to do more programming. Most people who call themselves "game developers" or even "game programmers" are neither; they are "game technologists." If you pick up a book on gamedev, 9 times out of 10 the end result after completing the entire book and working through all of the sample projects is a half-assed 3D game engine that would have been crap 5 years ago and will always look crap. While this may be an accurate representation of the work of many in the professional game development circles, it certainly does not represent the ideal (or even the good).

In my book, if you're working on a game engine you've not yet started making a game. You're making middleware. And, as someone who has had their bread buttered by the middleware industry for the last five years, I can say that's there's absolutely nothing wrong with making middleware. It's needed, by everyone in the game industry, and by everyone in the indie scene, and there needs to be more of it. But, don't tell yourself that you're making a game -- at least not yet -- or you're simply going to be disappointed.

A few days ago, EA announced that they were adopting Unreal Engine 3.0 for several titles. Now, that is someone wanting to make a game and not wanting to make game technology. It's the best decision they could have made, and honestly, they probably should have made it a year ago (or two). If you're making a shooter (first- or third-person, the tech is essentially the same these days), you should not be writing the tech. You should be using Source, Unreal or Crysis. They're all cutting edge, and they're all better than anything your team will be able to produce given any amount of time. The same goes for indies: go out and grab Torque, or Ogre3D, or CrystalSpace, or whatever... there are plenty of groups whose only goal is to produce game tech. If your goal is to make a game, then don't make tech.

I'm tired of tech. I tired of fighting it. I'm tired of writing it. I'm tired of debugging it. I'm tired of finishing a piece of tech and having no actual finished product because all I did was build a better hammer (or more likely, a worse one that only works on brass nails and not steel ones, and no, it can't pull nails out, only hammer them in). I'm tired of failing to finish my tech when all I'm really doing is failing to start my game.

I'm really surprised by some of the negative comments on Microsoft's decision to open up Xbox 360 to indie development. I would have expected a great fanfare from the indie crowd, but most of what I've heard has been suspicion and derision.

For example, Greg's thoughts on the subject. Sure, it was basically what I expected, but that still doesn't mean I wasn't disappointed to hear it. I realize that his bread is buttered these days by indie *PC* game developers, but he does seem to miss the f*cking point... as do many of the commentors on that post. Here's what I had to say (carried over from my comments on his blog):

First, Greg attributed the Net Yaroze to Sega. Of course, it was actually Sony. And it was an incredible pain to work with. And it was basically like having a cheap-ass devkit. And it severely limited the resources you could access on the machine. On, and your game had to run completely in-memory. Details @ Wikipedia.

Second, several folks suggested that the service should be completely opened up, truly a "YouTube of Video Games." Of course, MS (and the media, hook-line-and-sinker) loves a soundbite like that, but what they're offering really isn't YouTube (yet). The obvious caveat is that MS has to keep the quality bar high for "official" titles (as I explained in my previous post on the topic). Folks pointed at Amazon.com as an example of an "open system with filtering," but they are being disingenous (or naive) if they think the barriers to getting a book listed on Amazon are equivalent to me uploading some random code to a website (or a video to YouTube). Perhaps, with the recent growth of on-demand publishing, perhaps the barrier is a bit lower, but there's still an incredible amount of relative filtering that happens.

Besides, how do you make money off of that? There's several, several orders of magnitude more videos out there on YouTube and they still don't have a clear path for monetizing that. Do you really think it'd be easier on the Xbox with code?

Oh, and I really like the excellent point someone made: "Greg, will Manifesto be publishing any title that comes their way, regardless of quality?"

Of course, Greg's (and some commentors') perspectives are very different than that of the consumer MS is targetting. MS is targetting that high school kid who knows some programming and wants to do some stuff on the console in his living room. They're targetting hobbyists who want to "play" on a console. Of course, these same people already know (and already do) this stuff on PC's.

Craig Perko echoed this misconception I've seen elsewhere (which demonstrates GarageGames' very effective marketing surrounding this):

I had the same reaction as Greg, especially since the actual software you get to use is literally a port of GarageGame's existing middleware.

GarageGames is offering the Torque X package on top of MS's XNA framework. It is a separate purchase, just like if I sold you a C# class library for you to use. Users are welcome to use Managed DirectX and C# to their fullest (and basically have full access to the hardware).

Unbelievably, someone actually raised the "but C# is crap" objection:

XNA Express only works with C#. Whilst it isn't a bad language it certainly isn't going to go up against C++/asm for performance. [...] You have to create your game on a PC first, erm, at that point you can either distribute it to lots of ppl on PC, or a few ppl on the 360. This is much less 360 development then PC development with 360 development tacked on. But then WTF you develop games with C# and managed directX when you could just develop with C++ and directX, with only a tiny loss in your potential audience? [...] XNA is a solution looking for a problem IMHO.

Let's dispense with the whole C# vs. C++ crap. I applaud finished product, not the tools used. I could give a flying fuck if some kid in his bedroom (or the guy in the office next to me) used VisualBasic or assembler to craft his Pong clone (or his WWII FPS or his epic fantasy MMO). We'd all be so lucky as to be able to use a nice high level language like C# to make all of our games. Besides, the performance is as good or better than most programmers can do in C++ anyway. I only wish that the performance difference between C# and C++ was the barrier to indie gamedev nirvana...

I was excited when I heard about this, but that's because until I read this post by Greg, I didn't realize that the developers wouldn't be seeing a cent of the game's sales. Why couldn't M$ just split the profits 50/50 with the developer? (Of course any such arrangement is probably confused by the fact that the games will be bought with M$ "credits" or whatever they call them, rather than with any real-world currency.)

Which is utterly, completely false. While you can't make any money off your games, neither does MS. Folks pay a flat fee to have the opportunity to download and run managed code on their console. That's the only financial transaction. You can't charge for your game, MS doesn't charge for your game. If they like it and want to distribute it on XBLA, then count your blessings, because you just got a spectacular calling card for your next title. Oh, and some steady income (based on the current conversion rates). (BTW, credits have a linear exchange rate with US dollars, so there's absolutely no confusion there even if they were in play.)

I think that if M$ was mostly staying out of the revenue side, and letting people just use XBLA as a market to sell their games at whatever price they wanted, and M$ was just taking a relatively small cut, then Greg would have an extreme positive positive reaction to this. Instead the pricing is still screwed up, and he has an extreme negative about it. (If you haven't figured it out by now, he's very rarely lukewarm about anything.

As I mentioned in my previous post on the subject, there's no way that it would be fiscally sensible for MS to open up the Xbox like this. Not yet. There's not enough high quality software to stand out from the crap. They make money off of software sales. If there's a huge market for software that they don't get a piece of, then they'll have to shift their profit to the hardware, which would mean consoles would become even more expensive than they already are. If they just took a fixed percentage off of each sale (like eBay, for example), there's a whole bunch of responsibility that lands in their lap in regards to quality and support. Basically, opening up the Xbox as requested at this time would be a huge liability and money sink for MS, and would really gain very little for the indie gamedev crowd.

And finally, to sum up Greg's (notably biased) opinion on the matter:

Whoop ti fuckin doo.

Be fucking happy for this new opportunity for indies, hobbyists and amateurs! No one is forcing you to make Xbox games, no one is focing you to sign-up for the Creator's Club. But previously, it wasn't even an option. Now, there is another door open, another platform to develop for, one that is significantly different in context than the traditional PC. This will only make the indie gamedev community stronger, and will serve to increase the numbers of game developers out there with some decent skills.

Why waste the effort on tearing it down? Why all the hate?

People would think strange of me if I failed to mention Microsoft's new XNA Studio Express and Creator's Club. I'm excited to see DIY gamedev brought to the consoles, and it looks like Microsoft is doing everything right.

Sure, folks will say that Sony did it first with the Net Yaroze. But if you think they're the same thing then you just don't get it. XNA Studio Express will allow C# developers to target the Xbox360. Retail Xbox360's. That's the first big difference between this and Net Yaroze (which required a custom console). The second is the XNA toolset is a really high quality toolset (unlike the usual half-baked Sony developer tools). Visual Studio is arguably the best IDE (undisputed for C# in my book). The C# language is a wonderful compromise between C++, Java and higher-level dynamic languages like Python. The Managed DirectX API (which is the hardware API for XNA) basically eliminates all of the irritations of the traditional C++ DirectX API (which is already orders of magnitude better than any API Sony has ever released), leaving you with an ideal system library to work. The .NET Framework is very, very full-featured (much more so than the STL, and more appropriately so for games than something like BOOST).

In fact, I'm already in line to get this beta, and look forward to writing C# on the Xbox360. I think we'll see a spectacular influx of indie gamedev. Seriously, the only drawback for C# for indie gamedev on the PC was always the client machine: fluctuating hardware specs and the requirment for a bulky framework download (potentially). Lots of barriers on top of the built-in indie gamedev barriers (for distribution). But C# on the 360 eliminates that: guaranteed hardware. And with the addition of automatic resource management in C#, you've practically eliminated all of the low-level programming worries. All of the focus is on creating the game.

Bravo, Microsoft. Bravo.