postmortem
Latest
Sanctum 2 postmortem talks big ideas, low console sales
When the standard challenges of game development combine with advancing a series and learning to port to consoles, it's easy to imagine how things could become overwhelming. Sanctum 2 developer Coffee Stain Studios persevered from building the sequel to its first-person-shooter tower defense hybrid, but co-founder Johannes Aspeby's postmortem on the game, posted on Gamaustra, covers what was learned along the way. Coffee Stain initially envisioned a "free mazing" system, which would have let players set their own start and end points for mazes, but the concept was ultimately scrapped six months into development due to the team constantly discovering new flaws. Aspeby explained that changes weren't just limited to pre-development, either - at launch, Sanctum 2 spawned materials in the team base rather than automatically allocating them between players. This was meant to encourage sharing and to avoid making one player build every round, but it resulted in teammates racing each other to horde materials for themselves. Coffee Stain's internal testing didn't catch the problem, but the team is now hyper aware of the difference in atmosphere between an acquainted studio and a bunch of strangers playing a game online together. Bringing the game to Xbox 360 and PS3 meant dealing with the Technical Certification Process, which Coffee Stain allotted a few weeks for in order to find and fix any problems. Realizing the process' time sink led the team to hand off testing to another company, allowing Coffee Stain to solely focus on fixing problems, not discovering them. Performance issues also surfaced with the console versions, resulting in enemy and tower limits, as well as alterations to Sanctum 2's environments, like building walls to limit draw distance. This affected the PC version as well, as Aspeby noted the studio wasn't able to just make a different version for Steam. Aspeby estimated that a third of Sanctum 2's development time was spent getting the game ready for consoles, but added that in terms of sales, the payoff "hasn't been anywhere near the work." Sales on PS3 were particularly low, keeping the studio from even considering bringing Sanctum 2's season pass content to that console. Aspeby still seems optimistic about the experience though, concluding that the team "still had a hell of a good time, learned a lot, and made enough money so that we could continue making video games." [Image: Coffee Stain Studios]
Monaco tops 750K sold, makes off with $215K in Humble Bundle 11
Sales of the neon stealth game Monaco have hit 750,000 following its inclusion in Humble Indie Bundle 11. During the bundle bonanza, Monaco earned approximately $215,000, developer Andy Schatz writes in a rundown on his blog. "That's a nice hefty sum," he adds. Monaco was one of the "beat the average" games, meaning customers had to pay more than roughly $4.70 to get it. The entire bundle earned $2.3 million from 494,000 units, and of those, 370,000 were "beat the average" purchases that included Monaco. Most customers chose to distribute their payment with the default settings of 65 percent to developers, 20 percent to charity and 15 to Humble, and with six developers plus three mid-week additions, Schatz walked with 8 percent of the total payments. During the Humble sale, Schatz tracked Monaco's Steam numbers to see if sales there would drop – and they didn't. "Despite the huge number of units that we sold in the Humble Bundle, it doesn't appear that our presence in the HIB affected our day-to-day Steam revenue," he writes. "Why is this? My guess is that customers tend to be loyal to sales channels." Schatz told Joystiq near the beginning of Humble Indie Bundle 11 that he'd never been disappointed with Monaco's sales, even though XBLA numbers fell below his expectations. "Prior to HIB11, we had sold about 375,000 units across all platforms, with XBLA accounting for about 10 percent of those," he said. "Part of the strength of our PC sales have been the huge free updates (of which we have planned one final one, which will wrap up the storyline of the Gentleman and his crew). No plans at the moment for a sequel; I'm actually just beginning work on our next title." [Image: Pocketwatch Games]
Race the Sun earns $7,400 in first month, struggles on Greenlight
The intro to Race the Sun's one-month numbers breakdown begins on an ominous note: "Launching a PC game without a major distribution platform, such as Steam, is asking for trouble." In its launch month, developer Flippfly sold 771 copies of Race the Sun for a total of $7,400. "This may seem like a pretty big number to some – but keep in mind there are two of us, with families to support and bills to pay," Flippfly writes. "Additionally, the game's online features require a back-end server, and there are monthly costs associated with that, as well as our web hosting and other expenses." Race the Sun challenges players to outpace the setting sun by flying toward the horizon at breakneck speeds, avoiding obstacles in a procedurally generated world. In July, Flippfly described it as Temple Run meets Star Fox, and said it was already struggling on Greenlight. In 2012, Flippfly changed its focus from mobile to PC gaming, and at the time it saw Steam Greenlight as a great opportunity. On year later, Race the Sun is still on Greenlight and it's currently outside of the top 100, "seemingly a ways off." Most potential players tell Flippfly that they'll buy Race the Sun either when it's on Steam or when it's in a bundle. "I'm just not sure it's realistic to expect to be able to support yourself solely with self-distribution via your website in 2013, unless you're Minecraft," Flippfly says.
GDC 2013 classic postmortems: Myst, X-COM: UFO Defense, more
The classic postmortem sessions at GDC are always good for some fun, inside stories of old-school game development, including the likes of GoldenEye 007, Doom, Maniac Mansion and Out of this World. GDC 2013 will add a few more games to the list, with postmortem panels scheduled for Myst, X-COM: UFO Defense, Pinball Construction Set and Crystal Castles.Each panel will feature speakers involved with the development of each classic title, and plenty of secrets and anecdotes are bound to come up. You can bet we'll be attending as many of these as we can once GDC gets rolling in March. Who knows, maybe we'll get lucky and stumble upon another game designer's adorable, prescient childhood video.
Schubert to dissect Meridian 59 at GDC Online [Updated]
Those darn GDC organizers! They're still using the term postmortem for games that are very much alive. In this case it's Meridian 59, and former lead designer Damion Schubert will take the stage at GDC Online 2012 for a special Classic Game Postmortem lecture focused on the 1996 title. A GDC press release says that Meridian 59 was the first MMO to charge a monthly fee and use 3-D graphics and that it "began an era that set the stage for the MMORPG genre as we know it." Schubert went on to work on titles including Shadowbane, The Sims Online, and Star Wars: The Old Republic. [Source: GDC press release] [Update: Reader Scotty also tipped us off to the fact that M59 is slated to go open source.]
The Care and Feeding of Warriors: A Cataclysm postmortem for fury
Every week, WoW Insider brings you The Care and Feeding of Warriors, the column dedicated to arms, fury and protection warriors. Despite repeated blows to the head from dragons, demons, Old Gods and whatever that thing over there was, Matthew Rossi will be your host. And thus ends the Cataclysm postmortem series with a look at fury. Finally, we get a breather from Mists of Pandaria news and get a chance to look back at fury over this expansion. While summing up a whole expansion is pretty difficult, it's why they let me out of the box and at the keyboard for a few thousand words before tricking me back into it with a banana and a dart. So my thoughts on fury over this expansion, in easily digestible bullet points: SMF fury surprised us by being very competitive, even sometimes better than Titan's Grip fury, in the first tier of raiding and the heroics that launched with it. This was before the mastery nerf, so SMF could get enough mastery to make Raging Blow worth hitting, while its Bloodsurge slams still hit like angry, angry trucks driven by swarms of bees that mistook you for a bear. Trust me, that's not fun. After the mastery nerf, TG fury climbed ahead, especially once Firelands launched in patch 4.2. I don't think it's hyperbolic to say that TG fury was quite firmly ahead of SMF (which never recovered) or arms in Firelands. As you all remember from literally hundreds of screenshots, I was a tauren fury warrior in Firelands, and I freaking loved it. Dragon Soul ended the hegemony of fury and moreover, pushed it down below just about every single melee DPS spec. There was nobody doing as poorly as fury. The combination of directly nerfing the spec's break and butter Dual Wield Specialization and indirectly nerfing Deep Wounds by fixing a long-term bug pushed fury under the water and held its head under until people just plain gave up on the spec for progression raiding. To a degree, it's a shame that fury became no one's choice of specs in heroic DS, because once a fury warrior starts to accumulate that heroic DS gear, a familiar pattern starts to reassert itself. A fury warrior in full heroic DS gear is once again an effective fury warrior. Especially on certain specific fights, fury can actually be very very competitive. So let's talk about fury -- specifically, fury right now at the end of the expansion.
Developing my first iPhone game: the inside story
Editor's Note: From time to time, TUAW does cover commercial apps developed by our staffers, although it is relatively rare for individuals to write about their own projects (with some notable exceptions). In this case, Mike's experience of his app development process -- going from a code-naive start to a spot in the App Store -- is definitely worth sharing. Last Tuesday, having covered the App Store for TUAW since before there was an App Store to cover (remember the "sweet solution"?), I finally did something I've been thinking about doing for a couple of years now: I released an iPhone app. I write about lots of apps every day here on TUAW, but I'm a writer by trade, not a programmer. I used to code as a kid in BASIC, but before this app, hadn't ever written anything in an object-oriented language, or put together a piece of software with a graphical interface at all. I don't have a computer science degree or a background in coding -- I have what I call a "BS" degree, in media production. But last Tuesday, thanks to Apple's App Store platform, I became a published app developer. From start to finish, I've learned a lot. My app, Antithesis, is a simple affair, a twisted take on an old arcade form with (hopefully) just enough depth to keep it interesting. But even that simple app has taught me lots and lots of lessons, about everything from game and art design to how to develop in Objective-C and Xcode, and just what kinds of challenges and questions independent game developers on iOS face every time they come up with a new title. It would be impossible for me to convey everything I've learned in just one blog post, huge as this one is -- this whole process, of learning iPhone development to the bare minimum point that I now know it, has taken at least a couple of years, and just working on this app specifically took a period of about eight months. I originally started Antithesis back at the 360iDev Game Jam last year (while attending the conference for TUAW), and I wrote up my earliest thoughts about the game over on my personal blog. To convey everything I've learned in that time would probably take just as long. But I did want to try and share a few different big lessons I've learned here, and hopefully give you a glance at some of the insights and experience I've picked up from my (admittedly still very limited) foray into app development. Here's a few things I've learned from publishing an app on Apple's App Store. 1. It's not easy. But it's doable. There is a kind of a mystique to being an app developer, apparently. By far, the number one question people have asked me once I tell them about the app is, "How did you do it?" Unfortunately, looking back, I can't really recommend the path I took. I basically learned by trial and error, by jumping into the process of development at different points, seeing if I could do what I wanted to do, figuring out that I couldn't, and then stepping back in the process even further. So given all of that frustration, here's how I recommend you learn iPhone development, if you want to: First, learn Objective-C. This is the language on which all Mac and iOS development is based, so it's very important to know the ins and outs as best you can. If you already know C or C++, this will be easier, though there are quite a few quirks to deal with (or so I'm told -- I never learned either of those languages independently of Objective-C). I will echo Aunt TUAW's great advice (to me, actually) and say that if you want to learn this language, Stephen Kochan's "Programming in Objective-C" book is the way to go. Read that book a few times, learn what code objects are and how to manipulate and deal with them, and that will give you a good foundation. Then, learn how to use Xcode. Xcode is the IDE (integrated development environment) that Apple provides its developers to use to create apps, and even in my limited scope of knowledge, it seems to be to be the best way to go about core development (if you want to do cross-platform development, there are lots of other options, but that's not what we're talking about here). Aaron Hillegass' book "Cocoa Programming in Mac OS X" was helpful here for me, but it's not strictly about iPhone development. It does, however, teach you the structure of iOS and Mac apps, and it will let you in on all of the little hooks and levers Apple has built in to its operating system code for you to manipulate in your own apps. Honestly, the biggest education I got in just how Xcode works with the iPhone was browsing through all of Apple's sample code, and seeing what worked and what didn't there. The documentation for Xcode and the iPhone is top-notch, so if you ever have a question, there's usually an answer on Apple's site. For non-programmers, some of even Apple's walkthroughs can be a little intimidating (it's a lot of code jargon all strung together), but all of the answers are there, even if you sometimes have to ask questions in the very helpful developer forums. You get full access to all the developer forums with a $99 annual membership in Apple's iOS developer program. Finally, I used Cocos2D to make my game, and the great "Learning Cocos2D" book is primarily responsible for that one. Cocos2D is an open source framework that makes game development much simpler, allowing you to reuse code for standard objects like sprites and text labels, without having to build those things yourself. Ray Wenderlich is one of the authors on that book, and his site has an incredibly helpful and well-kept list of tutorials for working with Cocos2D. There is a lot of math involved in programming, and I am not good at math. There's also a lot of object-based thinking, and I've learned that I'm not too good at that either. So I won't say that development was "easy" at all -- it was often very frustrating, and there were many times when I'd spend hours trying to fix something simple, or I'd work hard on a chunk of code only to never actually use it in the game. But it is very doable. If you are interested in development, and passionate about making an app, and you keep at it even when the impulse to quit arrives (as it probably will many times), it is very possible to make and release your own iPhone app. Apple has lowered the barriers to entry on the App Store so much, so that even if you have a (more than) full time job, like blogging on a popular website, you can build and develop an app in your spare time on nights and weekends. 2. The iPhone succeeds because it's so frictionless. I could probably write books on what I've already learned about game design, and I'm sure there are still whole libraries left to learn. But the biggest lesson I took away from actually making a game (even after writing about them for so many years) is that iPhone users want and even expect direct, immediate access to whatever they're doing on that touchscreen. When I first put the game together, I did it using Apple's iOS simulator, which is a little app that comes with Xcode that lets you run iPhone software for testing on your Mac. So for most of development, I ran the game using a mouse or my MacBook's trackpad, not the actual touchscreen. Once I actually paid the $99 to join the developer program and gained the ability to run my software on my iPhone, however, the experience was completely different. I was surprised by just how intimate and direct the touchscreen is. And my "beta testers" (friends and family who I gave my iPhone and told to play my game while I silently watched) had the same experience. When I first made the game, I designed it so that the onscreen "paddle" (that the player controls) had to be touched directly. But from the first person that played it, I realized that didn't work: Users sometimes couldn't hit the relatively small paddle with their fingers, and having to connect with it was just a chore. So I changed the game, allowing the player to touch the screen anywhere to control the paddle, and that little fix removed that friction and made it much more accessible. Later, I added the ability for your paddle to fire a projectile, and a button to fire with, but players didn't get that you had to first lift your finger up and then touch the button -- they just expected multitouch, so I had to implement that as well (a little difference, but one that caused some headaches for me in code). In short, users expect direct, clear interaction on the iPhone. I'm sure that's a software rule in general, but on that touchscreen especially, I was surprised by how simple, clear, and direct everything really had to be, and how when I made changes in that direction, how quickly and clearly users responded. In the end, I strived for an experience without any instruction at all -- something that anyone could pick up, and eventually figure out without help. Even developers can learn a lot there, I think: Apps like Angry Birds, Jetpack Joyride and Temple Run succeed in large part because they are so exceptionally clear and straightforward. Everything you put in your game or app that impedes that connection between what users want to do and what they're doing will cause problems. When my beta testers played with the app for thirty seconds and then put the iPhone down and told me, "Well that's fun, good luck with that!" I knew I had things to work on. And when I got the game going so that people were playing for three minutes or more without taking their eyes off the screen, I knew I was doing it right. 3. Play to your strengths and weaknesses. This is one of the most surprising things I have heard about my app: People really like the graphics. My biggest drawback as an app developer (aside from the fact that I'm still a beginner, of course) is that I have no real sense of design or style at all. I've never been good at putting visuals together, and that's been a source of frustration over the years, given that I've worked on the web so much. So it's very interesting to hear that people like the graphical look of Antithesis. The night before I started putting the app together, I went to a bar in Denver full of old arcade machines, and I kind of marveled at those, at the experiences that old-school game developers were able to create with just a few pixels and one or two colors. That's what fueled my design more than anything else: How could I, as a guy with no artistic skill, still create something that was visually interesting. In the end, Antithesis only uses about four graphics (and -- spoiler -- three colors), but I tried to put them together in a way that got people interested. That visual choice turned out to be one of the most striking things about my app. So this is good advice for any endeavor, I think: Know yourself, know your weaknesses and strengths, and work in harmony with them. 4. Apple runs the show (but does it well). I haven't ever developed software for other platforms, but I can tell you that on iOS, at least, it's Apple's game. I've heard many stories over the years about the app submission process, and how closed-box it all is, and as far as I can tell, the stories are all true. When you're finally done with coding and designing your app in Xcode, you enter the world of iTunes Connect, a separate site which serves as the backstage, so to speak, for the App Store. This is the clearinghouse where you sign all the documents you need to set your app's price and make sure you can get paid when the app sells, and then create all of the screenshots and the metadata required to go on the App Store itself. The whole process is actually surprisingly rote at this point -- you realize just how much of an equalizer the App Store is when you find yourself writing up an app description, entering up to only five screenshots (it doesn't matter if you're EA, a one-man shop, or Rovio; five screenshots per listing is all you get), and setting up localization data for all of the various App Stores you might sell your app in around the world. Once you have entered all of the required metadata for your app, you upload what's called a "bundle" (created by fixing exactly the right settings in Xcode and then uploading what's basically a zip file of your app through Apple's software), and then the waiting game begins: Your app is boiled down to an icon that's yellow, green or red. If it's yellow, the app is waiting for approval -- either you the developer or Apple's submission team needs to check and approve it somehow. If it's red, the app's been declined, and you the developer need to go fix a problem somewhere, and possibly resubmit. And if it's (finally) green, then app is finally good to go. My whole experience here was relatively painless -- I submitted my app on Sunday, March 18, and it finally went under Apple's reviewing eye last Monday, the 26th of March. Then, about eight hours later, Apple approved the app, and about 12 hours after that it appeared on the App Store. That's a pretty typical cycle, as I understand it. It can vary quite a bit (some developers say that if you've had multiple apps approved before, the process goes faster, and if it's a particularly busy time of year at Apple HQ, the process can be even longer), but it all ran smoothly enough for me. So there's two lessons here: First, it's Apple's show for sure. I could have asked Apple to hold my app, post-approval, for me to release when I want, but if I wanted to get it out early or somehow speed up approval, there was no chance of that. Once you submit an app, it's in their hands entirely, and though my app didn't get rejected, from what I've heard, all you get is an email asking for a fix. The App Store is Apple's game, no matter who you are, and every developer with an app out there is just playing along as best they can. But the second lesson is that Apple also has this whole thing down pat -- from start to finish, I never wondered what was wrong or got confused about what was happening with my app. I did grow impatient waiting for it to be approved, but Apple never passed off any mixed messages or let me feel lost in the system, somehow despite the fact that the App Store team is now overseeing millions of apps around the world. I was incredibly impressed with how smooth the entire process was. Yes, it was complex and complicated (there are an astounding number of settings in Xcode for export, and even the metadata setup in iTunes Connect has to cover every possibility for security), but the system is there, and it works. 5. It's a jungle out there. So: Sales. Originally, I was going to release my app for free, just because the only goal was to see what the development process was like. But the more time I put into development, and the more I thought about that $100 development fee, the more I decided I should really get something back for my time. Not to mention that I wanted to see how sales worked on the App Store, and see how well I, after covering all of these apps and their sales for so long, could convince users to spend a buck on me and my work. As it turns out, not very well. (I agree, sharing sales after only a few days of release is probably a little early. However, I'm about to head out on vacation for a few weeks, and as you can see above, there's already a trend. I will update this post if anything changes.) As you can see above, I had a nice big start in sales, but since then, as the app has slowly moved out of everyone's consciousness, sales have steadily dropped. You can count up the numbers on the side there, if you like, but so far, I have sold 511 copies of the app. At 99 cents a piece, that's about $506. Not bad, right? I might even be able to pick up that new iPad! Not so fast. 30 of those copies were from promo codes - I gave out quite a few to reviewers and press, as well as a few on my Twitter and Facebook accounts for promotion. And not all of those sales were in the US -- quite a few of them were overseas, which means that they actually sold for less than $1, especially after Apple takes out conversion rates and various charges there. Of course, Apple takes its 30% cut, so by the time I actually get my check (which I probably won't for a week or two at least), total gross profits to me probably won't be too much more than $300 or so. Which is great -- again, the goal for me was release, not to make a bunch of money. But after taking out the $99 developer fee, and remembering that I put in about eight months of work on this thing, that's not very much at all. I am lucky enough to have a job blogging here, but if I was an independent developer who'd quit his job to try and support a family by making iPhone apps? I'd probably start browsing the help wanted section, or at least start work on a Tiny Tower clone of my own. And here's the most interesting part of my sales: These are sales from a very successful launch. Because of my story as a "blogger who made an iPhone app," Touch Arcade kindly posted about Antithesis, as did 148Apps and a few other great app and iPhone sites. The buzz on my app has been great -- almost all of the reviews are positive, and I built up a nice chunk of Twitter talk as well. My app's even been featured by Apple -- after showing up in the charts in the Arcade and Puzzle sections of the App Store (I even cracked the top 200 chart in Germany for a few hours after some favorable press appeared over there), I was featured at the top of the App Store's Arcade page alongside much bigger releases. In short, as app releases go, this one's been about perfect. I've been very lucky, and everyone, from the press to my users to even Apple, has been very generous with their support. But that hasn't translated into sales at all. Certainly, the quality of the app could be better, but my best conclusion here is that even buzz isn't enough on the App Store any more. There are so many apps out there, and so many ways for users to split their attention, that you really need to hit it out of the park on everything from presentation to release timing to advertising in order to get those sales numbers moving. In that sense, then, as I understand it, the App Store is growing more and more similar to game development in general. (One aside about sales as well: As journalists, those of us who cover apps will sometimes use listings in Game Center or even iTunes ratings or reviews as ways to determine actual app sales. But as I said above, I've sold 511 copies, I've currently got only 19 ratings in iTunes, and Game Center lists 278 players on my leaderboards. So the next time you see a blog extrapolating sales from either of those stats, know that they don't have access to the whole picture.) I'm not quite done yet. I wasn't necessarily planning to update the app at all, but my biggest bug is that I accidentally put the wrong sorting setting on the Game Center leaderboards, so it turns out the lowest scores are appearing at the top, instead of the other way around. People have also asked for universal support, so I'm going to combine both of those things (and some other updates) into a version 1.1, which will be out as soon as I can get it done (probably in a month or so -- again, I'm about to head off to vacation right now). And I'll continue to watch sales; I think I'm done with promotion for now (and I haven't spent any money on advertising, obviously), but it'll be interesting to see if there's an audience wandering around the App Store itself, and if just having an app listed will bring users in. So there's lots more to learn for sure. But this has been quite an experience already. It's been invaluable for me as a writer to work on this project, and stay tuned -- I will do my best to share lots more of what I've learned in posts here going forward as well.
Ghostcrawler talks game systems in final Cataclysm post-mortem
Blizzard's Cataclysm post-mortem blog series has seen Dave "Fargo" Kosak discuss quest design and Scott "Daelo" Mercer discuss dungeons and raids; today, Blizzard wraps up the series with a look at Cataclysm's game systems. As with Fargo and Daelo, Greg "Ghostcrawler" Street, WoW's lead systems designer, talks about what worked (the 1-to-60 revamp, choosing a spec at level 10) and what didn't (a long list of other things). GC is surprisingly candid in this particular blog entry, and it's definitely worth a read to get a bead on what Blizzard learned from World of Warcraft's third expansion. The full interview is after the break.
One reason Fez has taken five years to make, has already won awards
Seeing Fez's technical postmortem directly before a screening of Indie Game: The Movie offered a jilted experience, one from developer Renaud Bedard, who presents the game's pitfalls in its most practical terms, and the other from a dramatic 15-foot projection of Phil Fish's muttonchops, who assure us that re-re-creating Fez was and continues to be a truly personal, life-altering experience.Fez has been in development for almost five years and is now officially undergoing Microsoft certification -- the most the public (or press) has played is in demo form, yet Fez has been widely anticipated since its IGF win in 2008, a scenario that Indie Game: The Movie explores on a deeply human level. Bedard explains it in more technical terms. Way more technical terms.Bedard and Fish created their own editor for Fez, called the Fezzer, and designed what they deemed "trixels," blocks like voxels but at 16x16x16, or as Bedard described it, four 2D views creating one 3D world. Instead of a standard 2D tile set, Bedard built 3D "triles" -- 302 of them -- in 17 trile sets. Fez will have 157 isolated levels, and these triles make up all of them.Fez stars Gomez, a 2D character wandering a 3D world, and it also features a 4D character, Dot the tesseract. Dot is a 4D hypercube fairy that Bedard created using faux 4D to 3D projections with 96 vertices and 144 triangles, lending her the feeling that she knows more about the Fez universe as a whole, which she does.Both Bedard and on-screen Fish agree that Fez has been a long time coming."The fact that Fez was such a long project means that we kept upgrading," Bedard said. "Fez is our first game, our first project. It's hard to manage the fact that you want the game to be perfect."
Blizzard's post-mortem on Cataclysm dungeons and raids
Blizzard recently released a blog from Dave "Fargo" Kosak that acted as a post-mortem for Cataclysm's quest design. Following on its heels is this entry from Scott "Daelo" Mercer, the lead encounter designer for World of Warcraft. In it, Scott talks successes (Dungeon Journal, Raid Finder) and failures (difficulty level of launch heroics) in the dungeons and raids portion of the game's third expansion and shares what he's looking forward to with the release of Mists of Pandaria. I'm definitely with him in anticipating challenge modes and PvE scenarios. Read the full interview after the break.
360iDev: Lessons from the design of Postage
Developer Chris Parrish hosted a talk this week here at 360iDev in Denver looking back on the development of Postage, RogueSheep's Apple Design Award-winning virtual postcard designer and sharing app for the iPhone. He walked the developers in the crowd through a few of the lessons he and his team learned during development and a few of the principles they stuck by as they built the app. Parrish said the first principle RogueSheep stuck to was focus. "Cut, cut, and cut some more" was the slide up on the screen. Parrish said that when they set out to make what's basically an image-editing app, there were a lot of things they could have done, like including lots of tools and items to edit images in intricate ways and help users line them up just right. But it turned out that none of that fit the app they were trying to make. Instead, RogueSheep decided to boil the experience down so the user could go from image to postcard to pressing send in just 60 seconds. Parrish called it "putting the user on rails" -- not limiting options, but guiding and rolling users along so the process is as quick and easy as possible. Instead of the desktop model (which is what the team might have done if it really wanted to create that full tool-based experience), the focus of the app became the postcard itself. Parrish said the team worked to make sure that at every step in the process the postcard was always in view and clearly being built. Instead of moving from screen to screen, the interface slides around the virtual postcard, zooming in and focusing on whatever part of the area the user is working on. Even sending the postcard brings up an envelope instead of going off to some separate email screen, so users are always acutely aware of what they're doing in the app and why. That email sending feature led to one of the biggest compromises the designers had to make with the application. When it was first introduced, they had to cook up their own solution to send an email with the image directly from the app, a solution which came with its own pros and cons. They were able to use a custom HTML form for the email, but some users -- and their spam filters -- wondered about the email address the message apparently originated from. After the app was released, Apple allowed apps to send email through the OS, and the Postage team eventually decided to create their only preference option: Letting the user decide whether or not to use the custom emailer or the official one. Even that preference was hidden, however. Old users of the app just kept the old feature, while new users got offered the choice. The team wanted to make things as seamless as possible. Parrish said that devs dealing with whether an option should be offered or not should make the best decision they think possible; 80 percent of users will be grateful, even if the other 20 percent would rather have made the other choice. Parrish also said that whenever you make an app, it's always worth it to go the extra mile on the interface, using custom animations and doing it "right" whenever possible. The team worked for a long time on the "bounce" that the postcard first does when it drops into view, making sure it felt correct and natural. The buttons on the app were sized so they clipped off of the screen in order to inform the user that the button bars were actually scrollable. Parrish encouraged developers to make it look good, blending animations together and making them move in a natural and real way rather than just snapping into place because it's easier to code. That said, Parrish also recommended making use of Apple's UI classes as much as possible. All of Postage's interface buttons are subclasses of the official UI elements, though they're styled and customized to fit in with the rest of the design. Parrish said that while it's worth working on making things look right, it's not worth writing up your own options only to have them break when Apple changes the system. Use Apple's elements and work hard on the code, said Parrish, but then design it so it works for you and your users. Parrish's insight was really excellent, and it was great getting a look behind the scenes on Postage's award-winning design.
Left 4 Dead making-of feature recounts Survivor evolution, other odd stuff
Edge has an extensive and rather interesting look back at the development of Left 4 Dead that touches on design philosophy and how people behave while playing. "Some people would declare themselves the leader and bark instructions, whether they were qualified to or not," said Mike Booth, then CEO of Turtle Rock Studios, where the game originally began development. "Other guys just wanted to help out and make sure everyone had health kits. A few would just wait for the moment to stab you in the back." Other interesting anecdotes include a foursome who decided to just end it all by jumping off the rooftop at the opening of "No Mercy," and the Counter-Strike veterans who protected a gaming-illiterate father. The article also looks at how Turtle Rock and Valve initially got together, the technology that produces the 30 zombies populating the game world at any given time and, our personal favorite, the evolution of Louis from "a religious nutjob" to the likeable office worker based on Faliszek and Wolpaw's pal from Cleveland. "I remember helping him move house," said Faliszek. "He dropped something, ruined it and still made a joke about it. That's the perfect guy you want in the zombie apocalypse." Who else is going to help you find all those pipe bombs?
Okamiden producers discuss planning around Pokemon and 3DS
The producers of Okamiden realized they were in a pickle, marketing-wise, when they were finishing up the Western version of the game just as the 3DS and Pok émon Black and White were being announced for the same release window. Capcom decided to thread the needle and send Okamiden out right between these two. "Even though the news of the Nintendo 3DS was a bit earlier than we had expected," said producer Motohide Eshiro and director Kuniomi Matsushita in a postmortem on Gamasutra, "we decided that releasing the pan-Western versions of the game after Pokémon and before Nintendo's 3DS would be our best bet." The developers also revealed the inspiration behind Okamiden's partner system, which pairs the tiny Chibiterasu with young swordsboys, mermaids, Moon Tribe aliens, and others. "A child version of Amaterasu would only have half the abilities of the adult Amaterasu," they said. "It would be rather difficult for half of a god to save the world, but if there were a partner, then the two of them could work together to save the world."
Monsters (Probably) Stole My Princess was almost The Waterfall of the Dirty Gods
On Gamasutra, Mediatonic's Jim Griffiths and Paul Croft wrote a postmortem for Monsters (Probably) Stole My Princess, the amusingly-named jumping vampire game that started on PlayStation Minis before, yes, hopping to Xbox Live Indie Games. When the game was first conceived, there wasn't even the faint possibility of monsters having stolen any princesses. "The Waterfall of the Dirty Gods was our original concept pitch," the developers explained, "where the player needed to climb to the top of several different waterfalls and ring their bell to stop the gods from washing their filthy bodies in the water and polluting the waterfall." The player controlled a monkey with a bell that could be used as a grappling hook. Once the concept was in place, the team prototyped in Flash while simultaneously building the PSP game. After its launch, Mediatonic decided to rebuild it in XNA for release on the Indie Games platform. "A big benefit of doing a 360 version is that we could use HD assets and remain within the file footprint restriction, making it the "prettiest" version, Griffiths and Croft said. "Ultimately, though, the prime reason for the 360 version was simple curiosity in adding another platform to our portfolio." And now you (probably) know the rest of the story!
Jordan Mechner on Prince of Persia, respecting game writers
In 1985, Jordan Mechner was thinking about baggy pants, arches and columns -- images that could be clearly conveyed in a low-resolution, pixelated computer game. While delivering his Prince of Persia postmortem during GDC earlier this month, Mechner delved into his memories, his journals (which you can read online) and his temporary departure from the game midway through development to pursue a screenwriting career in Hollywood. Mechner's interests and techniques have always been embedded in cinema. He filmed his brother David running about in a Reader's Digest parking lot with a VHS camera, and layered drawings on top of those movements (in a process called rotoscoping) to capture the protagonist's movements in Prince of Persia. You've heard that part, but you might not know about the fate of the camera that captured such iconic scurrying. According to Mechner, he purchased it, recorded the necessary footage, and then returned it within a 30-day guarantee. "I felt a little guilty about it, but I was trying to keep costs down," he said. Initially dubbed "Thief of Baghdad" (and inspired by the film of the same name), the game continued to come together in a modular fashion, at one time incorporating a full level editor that Mechner had to persistently test, making sure users couldn't introduce game-breaking bugs. "My job title was programmer, all those other things were extra."
Super Meatmortem: The almost-death of Team Meat
Crunch time is just part of game development. When the deadline is looming, it's not uncommon for developers to pull 12-hour shifts (or longer). For Team Meat, crunch time nearly killed half of the duo. Tommy Refenes (pictured left) told GDC attendees that he would "be dead if we put Meat Boy on everything," explaining one of the reasons why Super Meat Boy has only been released for Xbox Live Arcade and PC thus far. In the two months leading up to SMB's XBLA debut, neither took a single day off, let alone slept for more than five hours a day. Refenes recounted feverish "development dreams" -- a sort of Groundhog Day scenario where he was squashing bugs only to wake and discover more.
GDC 2010: Canabalt postmortem
"What kinds of games do you like?" Adam "Atomic" Saltsman asked of his panel audience at the Canabalt postmortem during the Game Developer's Conference in San Francisco. "Role-playing" was yelled out, as was "puzzler," and eventually Saltsman picked "platformer" as the genre. Without another word, he quietly went to work on a laptop. Then, his partner at Semi Secret Software, Eric Johnson, took the podium to tell us all about what it was like to make one of the App Store's most popular games. He started by saying that the game was originally developed in just "five very long days," and was created for the Experimental Gameplay Project and based around simplicity -- it only uses six colors and, obviously, the one button. For a game that's so simple, it actually had a lot of complex influences. It drew from older games, like Another World and Flashback, as well as modern works, like Half-Life 2 and District 9.
GDC 2010: Call of Duty: World at War Zombies postmortem
Russell Clarke of Ideaworks Game Studio hosted a post-mortem report near the end of the first day of GDC 2010 about Call of Duty: World at War Zombies for the iPhone. The game was one of the first big brand hits on the App Store -- it successfully brought a game mode from one of Activision's Call of Duty console games (originally developed by Treyarch) to Apple's handheld device. After a quick joke about how a "post-mortem" was an appropriate exercise for a game about zombies, Clarke got into the nuts and bolts of how Ideaworks went about adapting the game for the iPhone. The most major feature of the game's development, he said, was the decision last year around this time to sit down and work on prototyping for about six weeks. Nowadays, there are a few successful first person shooters around the App Store, but last year, FPSes were still a new genre for the iPhone, so the team decided to really brainstorm how one would work on a touchscreen.
Aion gets a post-launch discussion in Game Developer magazine
With a couple months under its belt and a more stable playerbase, Aion is no longer in the state of just-launched new hotness any longer. You might be one of the game's still-numerous fans, or maybe you stepped away from the game because of the grind. Either way, there were a number of innovative and interesting features in the game, which was designed from the ground up to appeal to gamers on both sides of the pond. The latest issue of Game Developer magazine has a lengthy feature on what went right and what went wrong from the Aion team's point of view. The CryEngine and the game's overall level of polish are both cited as decisive positives for the game, helping the game feel more vital and engaging. The limited amount of flight early in the game is also pointed out as helping to simplify the learning curve, as navigating combat in three-dimensional space can get overwhelming for first-time players. On the flip side, the developers also talk about the amount of pressure on the frequently-changing team, as well as the technical and conceptual troubles with working on the Abyss. If you're interested in reading the full article, you should pick up a copy of the magazine, which is only around $4 for a digital copy.
iPhone Top Gun game takes highway to the postmortem
Top Gun on iPhone is one of the device's many hidden treasures. Not only does it have cool, After Burner-esque gameplay, it's also got one of the best easter eggs of all time (as you can see above). Unsurprisingly, nailing the unintentional humor of the movie is one of the things that Freeverse designer Justin Ficarrotta says his team got right in a new postmortem published on Gamasutra. The dev's top mistake? Using the wrong plane, or at least a different plane than the one fans were counting on. But again -- and we don't think we can stress this enough -- you get to play volleyball with the disembodied heads of Maverick and Ice Man. Doesn't that grant some sort of perma-forgiveness?
