The night before hopping on a cruise last month, Filler finally went live for the XBox (September 13th). Coming up on almost a month of data, I wanted to take a look back at the XBox version’s development process and comment on Microsoft’s Indie Games in general. I actually had a solid prototype working on the XBox over a year ago, before the service even launched. I had way too many other projects on my plate, so the XBox version kept getting pushed to the back. After finishing up the Batman: Brave and the Bold contest game in early July (I’ll do a post-mortem on that one as soon as I get a thumbs up), I felt it was finally time to clear the XBox version from my to-do list.
From each time I’d worked on the game for a week or two at a time, there was quite a bit of code in place. I’d completely stripped down APE (Actionscript Physics Engine) and the original Filler codebase to be as abstract as possible, then moved that code directly into XNA. I won’t say I got it 100% MVC, but it was pretty damn close. The majority of work, then, was all about building up the actual display and menus for the XBox version. Building the interfaces was pretty easy–though the lack of an interface builder means it’s a lot of “tweak, compile, check, and repeat”–not so dissimilar from coding Flash games in pure AS3.
Having played tons of Indie Games for WorthThePoints, I also had a pretty good list of things about the service (and the XBox 360 in general) that bugged me. Top among that is the prevailing idea that one profile directly maps to one human player. While I know why they did it that way (more Gold accounts), I personally think the profile system in the XBox is terrible for multi-user households. Content is attached to profiles instead of machines, which means we’re always logging different profiles in and out to figure out which profile has the proper permissions or features unlocked in a given game (that’s directed at you, Rock Band). Because Indie Games are even more rigorously locked to single profiles, I wanted to build my own system which would function more like the “save” slots of the old SNES and Playstation games I used to play.
Besides adding a co-op multiplayer component, I really didn’t want to just release “another Filler” for the XBox. The original Filler was only tuned through about level 15 (the highest I thought anyone would make it), so I was totally unprepared when people were up in the 60’s and 70’s a couple of days after I released it. Besides the physics breaking down, the difficulty of the game itself completely plateaued past around Level 15. Both the number of lives and the number of balls allowed spiraled way out of proportion to how many were actually needed to beat a given level. For Filler 2, I tried to correct this by combining the lives and balls into one value. The problem with this approach was that experienced players need way less balls than new players. Starting the game with 10 balls was reasonable for a first time player, but it gave expert players such a huge cushion to work with that there was never really any danger in losing.
The limit on how many balls could be placed was mostly put in place to put players from “cheating” and simply filling up the board with hundreds of tiny balls. To move towards making that the core win/lose state, then, was promoting a feature that was only added for convenience’s sake. For the XBox version, then, I wanted to get back to the notion of lives while thinking of a better solution to limit how many balls could be placed on screen. I tried lots of things: a power meter that depleted, holes in the floor that let small balls slip out, special enemy balls with a variety of powers (including popping small balls).
While playing with the notion of special enemy balls, I actually stumbled onto a pretty fun game mode which I may code up and release as a standalone version at some point. One of these special balls had erosive powers–every time it bounced into a filler ball, that ball would shrink a little bit. It was this mechanic which finally provided the difficulty curve I was looking for–though not as originally implemented. By making all the filler balls shrink at a constant rate (like filling, the “shrink” rate is proportional to the area instead of the radius, which means big balls shrink slowly and small balls shrink quickly), I actually solved three problems for the price of one.
The “fill the board with small balls” strategy became worthless–before the screen is even half way full, the first balls dropped in this manner start to “pop” and take lives away. Second, even when playing in the “proper” manner the new shrink rate adds a time-crunch component which was missing from the first two versions of the game. Most importantly, the shrinking balls smooth out the difficulty curve–they’re practically a nonfactor in first ten levels and don’t really start to have a major impact until around level 15… where the difficulty was previously plateauing. From a pure gameplay point of view, then, I firmly believe the XBox version of Filler is the most well balanced version to date. If I ever do another Flash version of the “core” game (and not a spin-off), it’ll be nice to have that part of the equation “solved.”
I submitted Filler to peer review for the first time on August 8th. It would go on to fail twice–both more for quirks in the framework than what I’d consider bugs on my part. The SpriteFont class takes an optional parameter when instantiating it, a single character which is used in the event that your code tells the SpriteFont to render a character which isn’t contained in that font (i.e. a character with an accent on it). Rather than doing something sensible like defaulting to a space (or simply rendering nothing), a call to render one of these characters causes the whole game to crash. Again, this is something that’s part of the XNA framework and not something inherent to C# itself. The fix? Adding a ‘-’ to the initializer for my fonts, which took about 30 seconds. The penalty? Besides the five days it spent in review before the crash was found, it had to spend another eight days in review “jail.” The published cooldown for a rejection from peer review is seven days, but your jail time doesn’t start until the day after you pull it from peer review (or get rejected, I assume). So if you pull it at 5 AM, it’s practically an 8-day wait.
After resubmitting the game on August 21, it took only a day for another crash to show up. If you try to open the marketplace menu with a silver account (i.e. a non-paying XBox Live account), the game crashes. All the accounts on my box are Gold, so I never even thought to create another one to test from. For a framework that does its best to handle all of the transactional details for you (trial modes are automatic, purchases are handled completely outside the game), it boggles my mind that the framework itself doesn’t pop up an alert with something to the effect of “You must be a Gold member to access this content.” The fix? Testing to see if the acting player is Gold or not and popping up an alert if they’re not–about five minutes of coding. The penalty? Another 8 days in peer review jail.
I’m not trying to say I’m completely without blame–if I’d spent another couple of weeks reading every detail of the framework documentation I might’ve been able to find these crashes before submitting. And I don’t think the “7-day” jail is a bad thing. The idea of it–to prevent people from dumping buggy games onto the service with no QA is noble, but I think it does more harm to well-intentioned developers than the “lazy” developers it was meant to stop. A better system might take into account the severity of the bugs and the submission history of the developer.
I was traveling when Filler failed the second time, so I was unable to submit again until September 2nd. Right around the time I submitted it for the last time, I posted some of my thoughts on the review process to the XNA forums:
What are essentially two framework quirks have cost the game nearly three weeks (it usually takes a few days before anyone bothers to review). These are mistakes I’ll know to look for next time (if I choose to continue developing for XNA), but the end result is that the submission process is unnecessarily cumbersome to first-time XNA developers–the very people Microsoft should be bending over backwards to court! I hope that there’s enough backlog some day for MSFT to actually hire someone to wade through it–a community relations job or a full-time tester.
This may sound douchey, but I have absolutely no interest whatsoever in playtesting or reviewing a game that hasn’t come out yet. I honestly believe I add more value to XBLIG by spending my time on development of new games and reviewing published games than by wading through unpublished games. Zman mentioned how few people are trying to make XBLIG a real business, and that’s because no one expects EA to playtest Call of Duty before it’s released (especially Activision!). You do your best to make your game, get it bug free, submit it to MSFT. If there are bugs you release patches.
Those sentiments were met with nearly universal scorn by the “main players” in the forum, but I stand by them 100%. At times it seems as though the Microsoft employees and most of the MVPs which frequent the forums (though certainly not all) have had rose-colored glasses permanently attached to their heads. There seems to be an overwhelming belief that if they hold hands and sing “Kumbaya” for long enough that the community will magically come together in a supporting environment where everyone does peer reviews. By voicing my opinions, though, the most common response was “don’t expect me to ever review one of your games. Good luck getting anything released.”
They claim that there are legal reasons Microsoft itself can’t approve apps, but that argument just doesn’t hold up–Apple has approved almost 80,000 apps since the XBox Indie Games channel launched (last November), and all without peer review. After pretty much giving up on ever getting the game out, some more reviewers checked it out while I was on the east coast and it finally got approved on September 13th–over a month after “finishing” the game.
Sales so far have been pretty tepid, which hasn’t been too surprising given other games’ lackluster sales. Though there are still a few days left, it looks like the game will sell less than 100 copies in its first full month (currently sitting at 83 with 4 days left). More disappointing than the actual sales, though, are the trial downloads: in almost a full month, only 2,520 trial copies were downloaded. 2,000 of those were in the first three days (while on the New Release list). In the last week, daily downloads have ranged from 2-6 trials per day. I’ve stuck with it for a couple of years now, so clearly I’m a fan of Filler’s gameplay–but I certainly don’t think it’s the greatest game out there. Still, it’s rated in the top 20% of all games on the service (at least, last time I checked). For sales to fall so flat so soon tells me two things:
Though I considered the work I put into the challenges, multiplayer, and profile systems enough to bump the game up from a $1 game to a $3 game, I get the sense that players (and customers) don’t actually give a crap about those features and would rather just have the core gameplay for $1. As an ecosystem, the Indie Games Channel only has enough traffic to support the top 25 or so games in the system. The iPhone has enough users that even an “average” game can see several purchases per day, whereas an “average” game for the XBox will be lucky to get 2-3 trial downloads per day. The breakout success of “I MAED A GAM3 W1TH Z0MB1ES!!!1″ has shown that there’s a place for content without any “extra” features at $1. If I had to go back and do it again, I would’ve just released the game without profiles and challenges months ago for the lowest price point. Extra work on the game doesn’t really get you anything on the Indie Game Channel (versus what we’re seeing in “Premium” flash games that can command user payments), so if I release more games for the platform they’ll definitely fall within that $1 “throwaway” style game.