The Great Porting Adventure: Day 3

Yesterday was spent in Mac land, which is an unfamiliar and glossy place. Fortunately I found a nice set of blog posts to guide me on my quest. If you want a tutorial, go read those posts. If you want to see what happens when someone tries to go from zero to Mac port, read on.

Here’s a recap of my experience. This is more for my own benefit rather than a tutorial for others, though it may give you an idea of what’s involved.

  1. Download XCode 4.2 for Lion, MonoDevelop and the MonoFramework.
  2. Watch some videos on how Macs work (seriously) and set up a user account for myself since my Mac is borrowed.
  3. Try to install xcode. Discovered that my version of OSX is Snow Leopard, not Lion and thus I have downloaded the wrong version. But the version for Snow Leopard is only available for paid Mac or iOS developers! I need to either upgrade to Lion or purchase a Mac/iOS developer membership in order to get xcode for Snow Leopard.

    This cat is too old.

  4. Decide I’ll need it eventually anyway and purchase a Mac Developer account for $99 + tax.
  5. Lunch!
  6. Purchasing doesn’t grant access immediately, but I receive my activation within about an hour.
  7. Download XCode 4.2 for Snow Leopard this time!
  8. Download and set up Git
  9. Fork and clone MonoGame. It’s still under very active development, so I choose to fork rather than just download a copy. Maybe I’ll be able to contribute!
  10. Install Mono itself (which is the analog to the .NET framework SDK in my head)
  11. Install MonoDevelop (IDE analog to Visual Studio)
  12. Don’t install MonoMac Add-in for MonoDevelop, because it appears to already be installed!
  13. Download MonoMac samples for playing with later from Github
  14. Download MonoGame samples for playing with later from Github
  15. Build some of the MonoMac samples and play with them. No problems there! That’s .NET on a Mac then. Easy peasy!
  16. Build some of the MonoGame samples and play with them. Some strange changes are needed in order to make them work, but nothing too absurd. XNA on a Mac! Easyish peasyish!

    PerPixelCollision sample, running on a MacBook. Nifty.

  17. Running an already ported sample is nice, but it’s time to try my hand at porting something “from scratch”. My target is the SpriteSheetSample, which is a relatively small and simple set of projects for a Content Processor, a runtime class and a sample game putting it all together. Should be easy! Roughly:
    1. Create a new solution file
    2. Add in the existing MonoGame framework and Lidgren projects, ensuring the former properly references the latter.
    3. Create new MonoMac projects for the SpriteSheet (runtime library) and SpriteSheetSample (sample game) projects. Make sure they reference MonoGame.
    4. Add some compiler defines like MONO and MAC so I can conditionally compile everything and only keep one copy of the files
    5. Set up the new Program.cs to launch the game the Mac way
    6. Copy over the already-built .xnb files from my Windows machine (I don’t keep these in source control)

    This is a bigger hassle than it sounds. I need an automated solution (“Create Copy for Mac”).

  18. Build and run! Doesn’t work. Or even crash.
    Eventually discover the “Application Output” window and see “Unable to load nib file MainMenu”. Turns out I’ve missed one of the steps in the tutorial and didn’t add an empty interface called MainMenu. This is one of those strange things I was talking about earlier.
  19. I use Mercurial for my projects, so update .hgignore to include:
    – *.DS_Store
    – *.pidb
    This is another thing to automate.
  20. Compiles! Yay! Runtime error! Boo! It’s an error drawing the spritesheet. Looks like the SpriteSheet object is non-null, but fields are null. WTF? Clearly something went wrong during the content load.
  21. Crisis! The debugger does not work! Stepping through code highlights nonsensical lines like comments and destructors when the callstack clearly shows otherwise. This is not workable at all. After restarting and googling the debugger problem, I come up empty.
  22. I decide to check if I can solve the content load problem itself. After some more googling, I find some misleading info about a lack of ExternalReference support in the ContentManager of MonoGame. This eventually proves to be a red herring and is a lesson in making sure your tools work so that you can properly identify the true problem.
  23. Eventually, I manually clean all the projects in my solution (the “Clean All” command was/is failing) and the debugger resumes working. Victory!
  24. From here, it’s a straightforward case of stepping through the content load methods. I discover that non-public fields are not being populated even when marked with the [ContentSerializer] attribute. Easy fix!
  25. Victory!

    It's a cat! And a spritesheet.

  26. With everything in place and working, I push my changes to my repository.
  27. Then I pull them down to Windows machine and check that everything still works.
  28. Everything still works. Done!

A little bumpy, a bunch of rough edges, but I ported something written in XNA to the Mac. What’s more, I kept it in one set of files, so it’s essentially the same as working with a copy for Xbox 360. There are definitely some opportunities to streamline the workflow though.

So the next steps are:

  1. Port another small library/sample to get the hang of what needs to be added/changed/reference/etc in a Mac copy of a project.
  2. Devise some way of automating this part of the process. Maybe.
  3. Come up with a good solution for keeping content in sync for Mac builds. I’m find with building everything on my Windows machine, but I don’t want built content in source control. It would work if I was using something like Perforce, but Hg (or Git for that matter) just isn’t suited to the task. Perhaps a simple rsync script. Moving forward, maybe a Dropbox solution.
  4. Find a desktop layout that works. As in, my physical desktop. Working on Macbook is uncomfortable, especially when it’s in front of my PC’s monitors.

For giggles, I’m going to try to keep a running total of time and money invested in this little adventure.

Running total: 2 days, $112.87


The Great Porting Adventure: Day 2

Where's the Start Menu on this thing?

Yesterday, I spent a chunk of time looking into various possibilities for porting my XNA-based game to non-Microsoft platforms like iOS and OSX. In the end, it seemed like learning Unity would be a prudent move and now would be a logical time to start that process.

In true indie fashion, I’m calling an audible.

I wrote off MonoGame rather quickly without much justification, other than saying it felt too much like magic and I would have trouble resolving any roadblocks I encountered. While that may be true, I think the benefits outweigh the small price of experimentation.The biggest potential upside, other than reusing 95% of my codebase, is that I can maintain a single copy of the game moving forward.

After all, if the MonoGame solution works I should be able to get my game running on something like OSX in a very short time. I figure that’s worth trying out. I’ll spend today setting up my borrowed MacBook, getting my environment in order and running through some MonoGame examples. I figure the OSX port will be a good first test, since it will play identically to the Windows version.

Maybe the first 99% of porting with MonoGame will go smoothly. Maybe the last 1% will prove impractical or impossible. Let’s find out.


There comes a time in every XBLIG developer’s life when they ask themselves, “How can I put this”

“onto one of these?”

This year, I want to hit more platforms than just the Xbox LIVE Indie Games market. My first priority is PC, specifically Windows. In this context, XNA is fantastic. I basically get a Windows build of my games for very little effort (some resolution management and key binding support). But what about OSX and Linux? The Humble Bundle (and the feedback I’ve received) has shown that these are non-trivial segments of gamers.

And then there’s mobile. Even I own a smart phone now, so that means pretty much everybody has one.

So if I’m going to go through the trouble of porting, I figure I might as well shoot for the stars and try to hit as many platforms as possible.

Of course, XNA doesn’t “just work” on these platforms. Porting XNA games has been done before by developers like Radian Games (Super Crossfire) and Fun Infused Games (Hypership Out of Control iOS), so it’s not completely foreign territory. Here’s a quick look at my current thinking:

Goal: Port DLC Quest to as many of the following as possible: iOS, OSX, Android, Linux

Approach #1: Native iOS Port

Rewrite the game from scratch for iOS.

  • Pros:
    • Free (other than iOS publishing fee, but all approaches will include this)
    • Potential for good/great performance, as this is as close to the metal as I can get
    • Learn a lot
  • Cons:
    • Most work. Total rewrite.
    • Have to learn Objective-C
    • Doesn’t directly allow for publishing on Android or Linux
    • Not sure how to port to OSX either

Thoughts: This is the most work, to hit only some platforms. But there’s no “magic” – I would know how everything works.

Approach #2: Port to Cocos2D or similar engine

Rewrite the game using Cocos2D as a base.

  • Pros:
    • Free
    • Save considerable time rewriting engine
    • Works on iOS and OSX
  • Cons:
    • Have to learn Cocos2D engine
    • Still have to rewrite game in Objective-C
    • Still does not directly publish to Android or Linux

Thoughts: Similar to above, but cuts out considerable engine work. But I already have an engine anyway.

Approach #3: Convert using ExEn, MonoGame, etc.

Use a MonoTouch based library/framework to do the heavy lifting and keep my codebase mostly intact.

  • Pros:
    • Use existing codebase, kinda (game needs adapting for touch devices/screens anyway)
    • Might be easier to maintain multiple versions in one solution
    • Write in C#
  • Cons:
    • $400 for MonoTouch (and an additional $400 for Mono for Android)
    • Does not directly publish to OSX orLinux
      • Whoops, apparently OSX is supported. Wizorb also managed a Linux version, so that’s a ‘maybe’.
    • Likely won’t work perfectly, require learning how MonoGame works to fix it

Thoughts: This feels like a magic bullet approach. I’m wary of things not working perfectly and then having to grapple with an unknown technology to try to fix it.

Approach #4: Unity

Re-write the game with Unity and reap the multiplatform benefits.

  • Pros:
    • Write once, hit iOS, Mac, Android, Flash. Possibly even Linux soon.
    • Get experience with Unity, which seems like a sensible business choice
    • Write in C#
    • Can potentially reuse some code
  • Cons:
    • Need to rewrite at least some of the game
    • $400 each for iOS and Android publishing. Potentially $1500 for Unity Pro + $1500/iOS/Android if needed.
    • Large learning curve for the “Unity way” of doing things
    • Likely have to invest in SpriteManager or similar library
    • Basically magic

Thoughts: Unity seems to make the most sense, but I’m also reluctant to use it because it feels like I give up too much control.

And the winner is…

Looking at this (and having slept on it), it seems like all signs point to Unity as the way forward. I’m not a big fan of the “magic” involved with Unity but that’s likely largely attributable to a lack of understanding. I’ll give it a shot and see if my reluctance is warranted or not.

I think the last time I used a Mac for more than 5 minutes was with an iMac in computer class over a decade ago. This oughta be interesting.

You said it dog.

Going Loud Studios: 2011 Indie Dev in Review

Well, that’s 2011 finished. This marks the end of Going Loud Studios first full calendar year of business, so I feel it’s time to take a glance back before moving on.

2011 Review

The Games

I released two new games in 2011:

Lair of the Evildoer (June 2011):

DLC Quest (November 2011):

Both games were picks for “Kotaku’s Favorites” list on the dashboard, which was sweet.

Zombie Accountant WP7 goes free

It might also be worth noting that the Windows Phone 7 version of Zombie Accountant quietly (very quietly) had its price slashed from $1 to $0 in… July? To be honest, I did this just to see what would happen – the game was long dead anyway. I kinda forgot to follow up on it though, so here are the stats:

The Awards

Frankly, I think it’s awesome that I even have anything to write here. DLC Quest won Official Xbox Magazine’s Indie Game of the Year 2011.


I’ve been making indie games for over a year now but I only looked into my city’s “indie scene” in the past few months. Turns out, it does exist! I started attending the monthly meetups put on by the fine folks at Dirty Rectangles which has been a ton of fun. Locking myself in a room to make games has been reasonably successful, but it’s great to meet new people and talk about making games in person. I look forward to doing that a lot more this year.


Or, “Why you came here”. Here are some stats!

Quick analysis: pretty acceptable! Granted, it’s pretty much all on the back of DLC Quest at the end of the year, but I’m okay with that. Not taking a loss on the first year of business? Sounds good to me.


Interviews! Podcasts! Print coverage! Youtube views! Twitter subscribers! 2011 was a great year for establishing myself on the internet. A few highlights include having some featured blogs at Gamasutra, coverage at big sites like Kotaku, Game Informer and Games Radar, a brief spot on Attack of the Show on national freakin’ television, participating in a few podcasts, and numerous interviews, including one in print in the January 2012 issue of OXM. I made some great contacts along the way too. The Going Loud Studios Twitter account (@WeAreGoingLoud) and Facebook page have also seen a nice bit of growth, sitting at 410 and 156 followers respectively. Oh, and the trailer for DLC Quest has racked up over 31K views so far.

So not quite famous, but it’s a nice start 🙂

Looking Ahead

We’re already three days into 2012, so enough with the retrospective! Here’s a quick look at some thoughts for the upcoming year.

More games

This is a no-brainer. Everything above comes from making fun games that I want to play. That’s the driving force that has gotten me here and it’s the passion to continue making games that will take me forward. I’m itching to make something new right now!

More platforms

If you study the releases above carefully, you’ll notice that 100% of all games I published in 2011 were for XBLIG. That’s a market that has its fair share of problems and has a bit of murky future. Even without that, it just makes sense to spread my games to more places where people can play them. PC is my prime target – heck, I have PC ports of both 2011 releases essentially ready to go. 2012 will be the year when I start publishing beyond the Xbox.


More platforms is great, but I’m thinking of ways to take diversifying a step further by exploring things beyond just making games. Don’t get me wrong, making games will always be first and foremost for me. But there are some complementary things I could be doing to spread myself out. At the moment, I’m thinking along the lines of more blogging and YouTube videos. There are benefits to that kind of exposure that might not directly generate income, but are useful for expanding your contacts, popularity and so forth. I don’t have any concrete plans just yet, but it’s something I’d like to experiment with this year. For science.

Game jam!

Can you believe I’ve never participated in a game jam? Everybody always says you should do that. I’m going to do that.

More learnin’! More seat-of-my-pants adapting!

As always, I plan on continuing ‘being indie’ in the philosophical sense. I picked up some great books on game design and engine architecture over the holidays that will be going to good use. Always learning, always trying new things, and always willing to throw out all of my plans if the need arises.

It’ll be nice to revisit this post a year from now and see how 2012 measured up. Now, follow me on Twitter @benkane!

Xbox Dash Update Holds Out Olive Branch to Indies, Twists Knife

New dashboard update! Has the sky fallen on Xbox LIVE Indie Games? Let’s take a look at what changed:

What We Got:

Bing Search

Indie games show up in Bing search results. If someone knows your game, they can find it relatively easily. A big addition that could change the effectiveness of advertising online and word-of-mouth.

Rate from Library

It’s now much easier to rate indie games since you no longer have to go back to the marketplace. I think the percentage of users that rate games will increase, and hopefully the effect of “ratings manipulations” is diminished.

Related Games

Each game now has 3 (expandable to 10) additional related game suggestions. Should help the service as a whole, though you see a lot of the same titles being suggested. Still, this is a really nice addition.

Included in “Picks”

The Games Marketplace now has 3 (expandable to 10) “picks” based on a user’s history. This could help expose more indie titles – the picks seem to include indie titles surprisingly frequently. However, the selections seem pretty bizarre. If the suggestion engine can settle down, this could be a nice win for a small subset of indie developers.

A High Level “Indie Games” Tile

The current “Indie Games” tile is actually in a pretty good place, even if you have to wait for the carousel to rotate (or do it manually with RS). If this was a permanent tile, I’d be happy. As it stands, it feels like it’s only a matter of time before another promo is rotated in.

Included in Quickplay

I think this is new. The Quickplay tile on the main page of the dash (and in the guide popup) now includes indie (and AppHub-deployed) titles. A nice-to-have, but it cannot be seen by anyone but you.

New Releases List Now Has 100 Entries

I suppose this is good. I’m referring to the “Games -> Games Marketplace -> Games -> Indie Games -> New Releases” list here. There’s also “Games -> Games Marketplace -> Games -> Game Type -> Indie Games -> New Releases” that has ALL indie games sorted by release date. Yikes.


This is the new indie games section! Well, one of them.


What We Didn’t Get:

Cloud Storage

No big surprise here. Would have been nice, but really not necessary. Probably would have made peer review a bigger headache anyway.

Beacons & Activity

Beacons may have helped fledging mulitplayer indie games maintain some sort of community. Activity would have been a nice way to spread the word about popular games in a viral manner. Indie games do not exist as far as these features are concerned.

Included in New Releases, Most Popular, Genre and Title A-Z list with Other Game Content

As before, indie games are not lumped in with “real” games, XBLA, DLC, Games on Demand or Xbox Originals. Not surprising, and I don’t genuinely expect Microsoft to give indie games the same status.

This is the other, permanent indie section. It's just one big list, with four sorting options.

What We Lost:

Ability to Filter by Genre

Genre is simply gone as far as indie games are concerned. There is a Genre list in the Games Marketplace, but it does not include indie titles. The only way to see an indie game’s genre is by looking at the full game description.

Ability to Quickly Sort by Title

If you want to browse indie games, you get one big list of all 2000+ titles. You can sort that list by Release Date, Most Popular, Rating or Title – but that’s it. Want to find Zombie Accountant? Sort by title, scroll through almost 2000 games and presto! No more jumping to a letter.


Indie games used to be a category on par with XBLA and Game Demos. Those categories have changed, but indie games didn’t get an equivalent spot on the virtual shelf. No game content has as little visibility as indie games.

If the Carousel Tile Goes Away…

The “top-level” tile in the carousel is probably what people think is THE indie section. To me, that’s the temporary section that will disappear as soon as Microsoft decides to run a different promo in its place. Then what? We have one big, sortable list. And that’s it. No Kotaku’s Favorites, no contest finalists. Why the “Game Type -> Indie Games” tile doesn’t link to the same section as the carousel tile is beyond me.

Update: Apparently the top-level carousel tile is not going anywhere anytime soon. Its existance is a fairly big gesture from the dashboard/marketplace team – thank you to whoever pushed to include it.

My Thoughts:

While I think there are some great wins for indie game discoverability (Bing, related games, picks), the usability of the indie games section has taken a big hit. There’s nothing to browse anymore. There’s no reason to visit. There’s no sense of there even being a place to visit at all, even if you do manage to find it.

Frankly, I’m surprised and impressed at what we got. I think that what we lost is overwhelming though.

Update: To clarify, I think older titles in the catalog will suffer since there’s no real way to browse them effectively. Then again, the marketplace was never really strong in that regard. Support could be better (it can always be better), but if the carousel tile sticks around as indicated, things might not be so bad for new and top performing titles. The lack of Genre filtering stings, but is frankly the one I feel has the best chance of getting resolved.

As always though, time (and data) will tell. But hey, at least it’s not in the Speciality Shop.

What’s Next:

Make a post in this thread in the official feedback forums. Even if it’s just to say that, yes, you do care about indie games:

DLC Quest and the Opposite Approach to Indie Development

(also posted to Gamasutra)

“If every instinct you have is wrong, then the opposite would have to be right” – Jerry Seinfeld

Last week, I launched DLC Quest. It’s my third release for the Xbox LIVE Indie Game Marketplace and it’s already outsold my other two titles. This isn’t quite a post-mortem, but I do have some thoughts to share about how I switched up my approach making the game. Enjoy!

First off, here’s a trailer so you know what I’m talking about.

Back? Good.

Last time I wrote here, I described how I spent six months on Lair of the Evildoer with minimal results. I decided that if I was to have any real success on the indie marketplace, I would have to change something about how I was doing things. I had a lot of ideas for experiments, so in true scientific fashion I decided to try out a bunch of them at once thereby preventing me from attributing any change in success to any one thing. Wait, that doesn’t sound right… In truth, you can never vary just one thing at a time since every game will be different anyway. Might as well mix it all up and see if anything sticks.

Dev time: One month instead of six months
This is probably the least controversial change to my approach. Spending six months on a game, especially without a ton of experience, is a big risk to take as someone trying to make a full-time job out of indie game development. It makes sense on a lot of levels to make smaller, more focused games. I didn’t hit my goal of one month development time, which was probably a bit optimistic, but I did manage to start and finish DLC Quest in under two months.

Make a press kit
Okay, this is a strong contender for the least controversial change. I had prepared press releases, box arts, trailers and screenshots before, but I never took the extra step of bundling everything up along with a basic fact sheet and some company info. You might not think you’ll catch the attention of a big journalist, but you better be ready if you do. My press kit has been downloaded about 30 times, which is 30 more times than my previous “nah, nobody will bother downloading this” estimate.

What’s better than being at the top of a dashboard list? Being on three of them.
Last time, I said that the ideal situation (as far as the dashboard is concerned) is to be at the top of the New Releases list during the Friday/Saturday rush. To do so, I released early on a Friday. One big downside was that it was incredibly difficult to get the attention of the press before everyone went home for the weekend.

So rather than releasing during the high point of the week, I released during a lowpoint – Wednesday. This gave my game chance to get some ratings and squeak onto the Top Downloaded list. So now instead of great placement on one list, my game had decent placement on New Releases, Top Rated and Top Downloaded. Not too shabby! It also gave me a chance to try and get some coverage, which peaked on Friday with an article on Kotaku.

Build on past efforts. Or don’t.
After spending six months making Lair of the Evildoer, I had a relatively robust twin-stick shooter slash RPG engine. The “wrong” thing to do would be to walk away from that and make a platformer instead. Which is what I did.
Now while this sounds a bit silly, it was driven partly by burnout. Sure, churning out a sequel or a spin-off would have been a safe and easy approach but being an indie developer is all about flexibility. I wanted to do something different, so I did. This kept me motivated throughout the project and was key factor in being able to be productive for a solid two months.

Games should have enemies, health bars and ways to fail
At one point in development, I realized that there was no real adversarial challenge in the game. The player had no enemies to defeat, no pits to fall in, and no spikes to impale themselves upon. As I started to think up ideas for enemies to add, health bar displays, and continue/retry mechanics, I realized that I was only going through the motions because those are aspects of similar games. They’re expected, they’re intuitive, but they’re not necessarily fun. DLC Quest was never meant to be a “normal” platformer – there would be nothing to gain by throwing in ways for the player to fail. I hesitate to say the game is more cerebral than others, but the driving force is really the desire to see the next obstacle and the next joke that comes with it. In the end, I simply chose not to add in mechanics that weren’t needed and I think it’s a better game for it.

If you can’t sell the game for what it’s worth, make it worth what it sells for
The Xbox Indie marketplace is notorious for having a big barrier to success at its $3 and $5 price points. Most games get a disproportionately small number of trials and conversions at anything above the lowest $1 price point. In Evildoer, I created a game that had a few hours of gameplay, along with enough random and procedural elements to give the game some honest replay value. But I was afraid to charge anything more than the bare minimum out of fear that it would be ignored entirely. Getting a few (or potentially “many”) hours of entertainment for one dollar is essentially unheard in most markets – with a notable exception of mobile markets. Even then, many of the larger games now sell for more than just 99 cents.
So if customers ignore games above 80 MS points, why not make the game worth what you can successfully charge? The plan from the beginning was to make a game that delivered a half hour to an hour long experience, nothing more. Obviously you can’t get away with making a paper-thin product, but you can deliver value that’s more in line with what you get in return. It’s tough to nail a short experience without leaving players feeling ripped off, but quality can make up for quantity. Feedback thus far has been very positive. Players have expressed a desire for more content while still saying that it was absolutely worth the price of admission.

Don’t talk about it
Last time, I devoted a fair amount of effort to blogging about development and making videos about how things were progressing. This time around, I didn’t even mention the game until it was essentially finished and ready to be reviewed. Surely this was madness! Perhaps, but I wanted to test the theory that titles on the Xbox indie marketplace are essentially unaffected by the buzz they garner on the internet. It goes against all intuition, but it felt like there was a grain of truth to it. Many XBLIG titles succeed by virtue of their boxart and ratings alone, prospering on the lists of the dashboard and remaining essentially unknown to the rest of the world.

Make a funny trailer
I almost made a bog-standard “gameplay and music, with features called out between cuts” trailer for DLC Quest. I caught myself starting to plan out the trailer without really thinking about what I was doing. I realized that if my game was meant to be funny, the trailer should be as well. In the end, I was really nervous about releasing it because of the approach I took. I still cringe whenever I see it, but the amount of positive feedback has been fantastic.

You can find check out my company Going Loud Studios at and follow us @WeAreGoingLoud. I also keep a blog and a development twitter account of my own @benkane.

And now I’m going to go have a chicken salad sandwich and a cup of tea.

XNA on Windows 8 -gate

There’s been a lot of buzz from the BUILD Windows event about XNA not being available in the next version of Windows. Overall, there’s a huge amount of confusion and a lack of information.

Here’s a rough paraphrasing from the Q&A session of the “Introduction to DirectX-style for Metro style apps” (around 36min):

Question: You said XNA wasn’t immediately supported, but would you be able to take a Metro UI app, download a Metro UI project in C#, download XNA 4 and still be able to use it? Or would it just not compile/not work?

Answer: The bits for XNA aren’t really there. XNA is supported for desktop games, but for building Metro-style games you should use D3D.  We’ve brought some of the functionality that XNA has into the APIs for Metro-style apps and there’s a couple of talks on how to do things like audio and input. … But the “drop a project in”… that’s not something you can do.

Question: And just to follow up on that: since Windows Phone 7 supports XNA, is there going to be any future planned support for XNA? Perhaps in V2?

Answer: Yeah we’re not going to talk about what’s happening in the future. We’ve got a bunch of stuff  that we’re doing now and we’re excited for you guys to use that.

So the worst-case scenario of XNA “not working” on Windows 8 is false. This makes sense, since Windows will retain backwards compatibility as it always has. However, it looks like XNA is not going to be supported for Metro-style apps. This potentially has a few important implications:

First, XNA games might not be available in the upcoming app store.

Second, XNA games might not have access to Avatars, Leaderboards, Achievements and all the other LIVE goodness. To be fair, there’s a good chance this will be limited to approved partner-style Metro apps the way it currently is on Windows Phone.

Third, the XNA framework itself may not have much development time left. If everything Windows is heading to Metro/D3D, where does XNA fit? Does it still have a place on WP7/Xbox/desktop Windows?

All of this is rampant speculation during a time of much confusion and little communication. But it’s fun!

Maybe today’s “Building Xbox LIVE games for Windows 8” will shed some light. My prediction is that it will cover lightweight games using XAML and heavyweight games using D3D, with all the LIVE features requiring you to have a partner deal to be an official LIVE app.