Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
December 10, 2018
arrowPress Releases






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


The chilling tale of the development of Costume Quest 2

The chilling tale of the development of  Costume Quest 2
October 29, 2015 | By Gabe Cinquepalmi

October 29, 2015 | By Gabe Cinquepalmi
Comments
    2 comments
More: Console/PC, Indie, Programming, Art, Design, Production, Business/Marketing



This in-depth post mortem of last year's Costume Quest 2, independent studio Double Fine's first-ever sequel, comes courtesy of project director Gabe Cinquepalmi -- just in time for Halloween 2015.

Double Fine doesn't traditionally do sequels. Of our 15 catalogue titles, only Kinect Party could be accused of being a sequel, but that was really more of an expansion and rebranding of Double Fine Happy Action Theater. Double Fine's lack of sequels is not necessarily due to a lack of desire to do them.

In fact, we have pitched them for Psychonauts, Brütal Legend, Once Upon a Monster, and Costume Quest throughout the years. Some of them got off the ground a little, but none of them went into full production. They just weren't in the cards for various reasons. The clamor didn't die down, though. At one point, Greg Miller (Kinda Funny, formerly IGN) was so jazzed for a possible sequel to Costume Quest that he gave Tim a giant $5 check on his show to seed some crowdfunding money for it. Would this monstrous foamcore check make the difference?

In the fall of 2013, we pitched some of our Amnesia Fortnight prototypes to Midnight City, an upstart indie label for Majesco. They had just gotten the console rights to publish Gone Home, and they were looking for some more titles to grow their brand. Since it was a fledgling label, they were a little more risk-averse and didn't bite on any of our new ideas. We asked if they'd be interested in a sequel to Costume Quest since it is one of our most frequently requested follow-ups. Midnight City loved the idea of being part of our first sequel, and it was enough to get the ball rolling. They actually recalled Greg Miller's giant check gag, and felt that they could work that into their marketing plan...  "cash in" on it, if you will.

All of this was happening unbeknownst to me, so it seemed out of left field when one day after a leads meeting Tim asked me if I would be interested in running Costume Quest 2. That is... if we could get it signed. I was excited and humbled to be asked to lead the project, but my mind started calculating the time until Halloween and my mood quickly turned to panic. We were already less than a year away, and the contract hadn't been signed yet. It would probably take a month or more to get things solidified, and then we'd have to figure out how to staff it with everyone already assigned to a game. I said yes anyway. I knew it would be tough, but if I turned it down, there was a chance we'd still do it, and then someone else would get to have all the fun!

I had produced and helped with design and writing on the first game, and then designed and wrote much of the Grubbins on Ice DLC. With the original creator and project lead Tasha Sounart no longer at the company, it felt like a natural progression for me to shepherd the sequel. I felt like I understood the concept and mood of the game intimately enough to do it justice. I also knew all the production pipelines and game systems, which would be key for anyone trying to get this thing done in less than a year. Would the game feel different with someone else at the helm? Probably. But I felt like I could sprinkle my flavors in it and still ensure that it would taste like Costume Quest.

It wasn't long before a deal was reached with Midnight City, but when I saw the contract, I had even more reservations. The overall budget was smaller than the original two-platform Costume Quest budget, and they wanted us to ship simultaneously on eight platforms in less than a year! (PS4, Xbox One, PS3, Xbox 360, WiiU, PC, Mac and Linux were all stipulated.)

We were sure that last-gen platforms were not worth the effort. Not only were sales declining for downloadable titles at the time of signing, yet another year would pass before we would ship. It also didn't make sense to invest in resurrecting our Costume Quest engine on 360 and PS3 when we would likely never use that tech again. The last-gen platforms became a sticky issue. We pushed back as hard as we could to get them to drop, but eventually had to relent or walk away from the deal. We signed, already thinking about how to outsource that work.

Now that Costume Quest 2 was happening, we needed a real plan! Usually we have a pitch or a demo before we start on a game, but this time our four-year-old game was our demo. We didn't have anything representing what CQ2 might look like. We did have that old CQ2 pitch from a few years earlier, but after exhuming and reviewing it, it was no longer viable. It was intended for a much bigger budget with a longer schedule (voice, deep skill trees, etc.) We would need a new design, mostly from scratch, and it needed to be something we could legitimately pull off in 10 months.

The Grubbins on Ice DLC was the template that showed us what could be done with the engine once it was in place. It was a bigger level than any of the three in the original game, and we knocked it out in three months with a smaller team, mostly pain free: Two months to build it and one month for alpha/beta/certification. We had metrics for how long each element took to create and implement, since all those tasks were still in our production tracking software. I felt that a sequel would have to be at least the same scope as the original game for it to be accepted by fans, but we had to figure out areas where we could push even more within our constraints to make it feel fresh and new. It was definitely possible, but there was absolutely no room for error.

Tim and I had lunch with Tasha to talk about CQ2 and find out if she might be able to be involved in some way. We wanted to make sure that any changes we made didn't veer too far away from her original vision. She was excited at the prospect but was unfortunately not able to get involved with the project due to her current working agreement. She gave us her blessing and reminded us of some of her original design tenets while making the first game, helping to ensure that the sensibilities of the sequel stayed true to the original.

I had a few discussions with Tim about stories and locations before Christmas. By the time Christmas vacation rolled around, we at least had a direction. I hoped it would be enough to get us going, because when we returned in January, we were off to the races whether it was figured out or not!

What Went Right

1. Amazing team!

The biggest concern at the outset of this project (once we came to grips with dates) was staffing. We not only needed to get asses into seats pronto, I was hoping we could get as many Costume Quest veteran asses as possible. Even with a solid schedule and design, if we didn't have the right people at the right time we'd be dead in the water. The more people we had that already knew the game and engine, the better our chances of success. Double Fine was already working on a full slate of titles at the time: Broken Age, Spacebase, Massive Chalice, Hack n' Slash, Grim Fandango, and a few ports of library titles. Almost everyone was tied up.

Our first big break was that we had a really strong lead programmer available right out of the gate. Ben Burbank was finishing up work on the final port for The Cave and was able to jump on early to start integrating the old, crufty Costume Quest code into the latest version of Double Fine's internal engine, while I continued trying to figure out what the game would be. Aside from lead programmer duties, Ben is a huge fan of Earthbound, one of the original influences for Costume Quest, and he understood what CQ was all about. He was invaluable on the combat design and had great sensibilities in general to help in design talks.

Kee Chi joined shortly thereafter to helm our gameplay programming. He's a DF veteran who's been cranking out gameplay code since the Psychonauts days. We'd recently worked really closely on his baby, Middle Manager of Justice, and I was super happy to keep that relationship going. CQ2's code was in good hands now.

The next nut to crack was concept art. We had to figure out what this thing was going to look like. All of our concept artists were busy painting Broken Age backgrounds or Massive Chalice doodads. With those games getting close to milestones, no one was available internally. My first thought was to see if our esteemed, long-time DF collaborator, Peter Chan, was available. I also wanted to make sure the characters didn't veer too far away from the look of the first game, so I checked in with Scott Campbell, the company's first art director and the designer of the original CQ combat characters, for his availability. Luckily, both of them had time available! Soon after, Emily Johnstone moved over from the Broken Age team to bolster our concept team. Our good start was turning into a great start!

After a couple of weeks, we finally started staffing up for production. The rest of the core team fell into place: Bert and Panya joined Kee to help make the gameplay fun, Freddie, Lindsay, Jeremy and Kristen gave us the beautiful landscapes, Jeremy and Drew were wizards with the VFX, Paul and Camden tickled our ears with their audio, and Chris, Chris, Dave, Dave, Tyler, Tyler, Adrian, Frederik and Elliott brought the characters to life. Then David, Matt, Oliver, Paul and Joe did crazy things to make the game look great across all of the platforms, Joe and Silvio enslickened our UI, Raz painted up the Creepy Treat Cards, Dan bolstered the production team, and Malena made sure people who spoke different languages could understand the game! Thankfully, almost everyone that touched the original game had some impact on the sequel. Even composer Peter McConnell was able to schedule in a fantastic soundtrack between Broken Age milestones!

We didn't have room in the budget for a full time art director, but the look of the game was set the first time around, with the help of Lee Petty, our Studio Art Director. We also had a lot of senior artists on the team that knew how to maintain a look. Lee was even able to take a little time out from Broken Age here and there to help us ever so often during CQ2. He made sure we didn't go off the rails, and helped us with problem areas when we got into a visual bind.

We had to resort to a moderate amount of outsourcing, but were lucky to work mostly with ex-Double Fine employees that had previously worked on the game or had a solid working relationship with us. It all went swimmingly. (Well, there was a contract or two that weren't swimming, but this is the "what went right" section!)

The only real hiccup I recall is when our lead animator and co-writer took a leave of absence early on in the process that kept him out for the remainder of development. We had collaborated to write Grubbins on Ice together, and we were planning on splitting the load for CQ2 similarly... so his departure meant that I would have to either write the game by myself or try to find someone else to work with. The latter option didn't seem viable, as everyone internal was tied up, and I didn't have time to screen new writers. This was a huge workload on top of everything else, but I really love writing, so I was up for it.

We did have to deal with the usual musical chairs throughout the year as teams ramped up and down, but overall, staffing was the least of our problems. The final team we ended up with was composed of motivated, multifaceted people that worked well together. We didn't have one moment of drama on the team from personality clashes or high-stress conditions. Quite a rarity when working with homo sapiens!

2. Design Direction Established Early

Costume Quest is a perennial favorite with its fans. Every Halloween, there seems to be renewed interest in the game, and activity on forums and Twitter reignites. We've gotten tons of requests for a sequel over the years along with recommendations for what they'd like to see. I also dropped in on a Grubbins on Ice playthrough from our Double Fine Game Club (a fan group that plays adventure games online with an IRC chat going, often with developers of that game joining to chat). I joined to watch them play, but also wanted to pick fan brains for wishlist features and beefs with the first game that we might correct. Surprisingly, I could barely get feature request ideas from players. They mainly reiterated that they wanted "more Costume Quest", which was a good sign that the main formula didn't need an overhaul. Aside from that, the only common thread I could find was a feeling that the combat was monotonous and seldom challenging... they wanted to do more than button mashing.

Combat was also my main area of concern. I already knew that I wanted to do something closer to Paper Mario, with button presses tied to the moments of impact rather than in-air pauses to waggle the joystick. It keeps the animations snappy and feels more like your button presses are tied to the character's actions. We tried this in pre-production and were happy with the feel immediately. We had the basic combat controls set early on, but we still needed to add some depth to the decision-making.

In the original game, combat decisions were along the lines of "kill the healer first" or "take out the Grubbin with the damage buff", but there wasn't much strategy other than that. There also wasn't anything at stake from fight to fight, since stats fully reset after each battle. You simply had to clear the current fight to get your health fully restored. If a player unlocked a special attack during a fight, it would disappear when the fight was over, so players were encouraged to just burn them as soon as they got them, rather than saving them for strategic situations.

We wanted to raise the stakes from fight to fight, motivate the player to target specific enemies, and give the player multiple customizable actions to deal with each situation. We also had to take care not to let these additions raise the complexity so much that we'd alienate the original CQ audience.

To handle the enemy targeting issue, we added "types" to each enemy (magic, monster, and tech), and "resistances" to the costumes. If a costume was strong against magic, that character would do more damage to, and take less damage from, a magic enemy. If a costume was weak against tech, that character would take more damage from, and deal less damage to, a tech enemy. Basic rock paper scissors stuff, but it was enough to make the player think twice about which enemy to attack, as the repercussions for ignoring it could mean defeat.

Once we finalized these changes, it still didn't feel like enough. It needed another layer. We had a floating idea about using the Creepy Treat Cards as a new system to modify combat rather than the old fire-and-forget battle stamps. Rather than setting your battle stamps up before the fight, you would be able to set three Creepy Treat Cards that could be played during the fight. Using them in combination could bring about interesting effects, and give the player something other than the special attack to ration out and use strategically. Once we got this feature in, it wasn't 100% clear whether it was successful, but we didn't have any more "new feature" time in our tight schedule to go back to the drawing board. We had to continue to polish it in the hopes that it would eventually feel solid. We were, luckily, pretty happy with the finished product.

It took us a little while to figure out which costumes we wanted, but we only needed three at a time every three months according to the production schedule. We knew we'd probably have to extend some existing abilities due to time constraints, and we had some ideas for new ones that would feel different (like the clown horn). Costumes are such a huge part of the appeal of this game. We were glad that the schedule afforded us some breathing room to let our ideas percolate... not something we were able to do often on this project.

Story-wise, we were working with a few level ideas leftover from the original game that were cut due to time constraints, as well as a few ideas from the CQ2 pitch. Only one of those levels, a Bayou, really appealed to us to continue developing. It felt appropriately creepy and even had a main character (Monty) already designed and concepted for the area. I thought it might be fun to give the story some time-travel-ly Back to the Future stylings, and Tim was into the idea. After talking about it for a bit, we figured that rather than writing a story from scratch and figuring out levels from that, coming up with three compelling levels that would be fun to play, and then tying a story around that would be the better approach.

The next challenge was figuring out what to do with the cliffhanger in Grubbins on Ice, where we left the kids trapped in an alternate dimension filled with portals. This ending to the DLC was meant to leave things open-ended in case we secured a sequel. But now that we had one, we had to decide whether to cut that off and just start a new story, or to treat it as a continuation of Grubbins. We ultimately decided for a little of both.

Going into pre-production, I had a framework for the story. It wasn't final by any stretch, but it defined the three levels that we would need to build, and it was enough to move forward. A huge load off!

3. Sequel Benefits!

Some obvious perks of doing a sequel are the presence of a completed game, proven engine, established design rules, tuned asset and tool pipelines, and an existing content library. We could iterate rather than invent in most instances, which allowed us to devote more time to content creation -- something we often dreamed about, but rarely got to experience.

Since we built the game on our Buddha engine, we were able to get free features from every game that utilized it since the original CQ. We gained graphics engine improvements and some free publisher requirement fixes from other games. Anna Kipnis was able to take some time off of Broken Age to develop an improved dialog system for us. This allowed us to get a lot more scripty at the dialog level than we had in the past. I set up many missions on my own through the dialog system without having to overload the gameplay programmers, saving an insane amount of time. As a bonus, Anna integrated the improved version back into Broken Age to upgrade their dialog system. Win-win!

I think the biggest savings overall was our library of art assets. Many of the kid models, rigs, and animations were pre-existing, so we just had to model new accessories for them. We had props from the older levels like garbage cans, cars, mailboxes or trees that we didn't have to remodel if we just needed filler objects. We were also able to reuse some characters to add depth and callbacks to the original game.

One case is using the bulldozer driver boss from the first game (Metxel) as the teacher(s) in the Tooth Academy. In this case, we wouldn't have had time to model a specific character for the teacher, but since we had this established character lying around, we were able to create a new race of characters and paint him in a new light. We still created a boatload of new art content, but we were able to focus our time on big, impactful set pieces and combat characters because of this creative repurposing.

Having experienced developers from the first game was indispensable. Half of our team already knew how the game worked, and were around for our original trials and tribulations. This made it far less likely that we'd make the same mistakes twice. We knew how to make this game already. Now we just had to execute.

4. Hands-off publisher

Midnight City was a new arm of Majesco, and had a lot on their plate. They were figuring out their identity, managing new business, and trying to get the word out about their brand. Their staff was mostly experienced, but they were sparsely staffed and spread pretty thin. Whether it was intentional or not, they gave us a lot of rope. We would get feedback on our milestones, but there weren't any of the traditional, heavy-handed comments or requests for copious documentation that we'd come to expect from publishers. It made them a joy to work with early on, because we were free to focus on development without interruption. I like to think this was a conscious choice by them to trust us to make the game we wanted to make... Either way, this was crucial for us with our tight schedule. It was also quite similar to our relationship with THQ on the first game.

What Went Wrong

1. El Ocho

Getting CQ2 up and running on PC and then porting it to seven other platforms was our number one source of woes (not to mention localization in five languages!). Everyone on the team was adamant that this was too tall an order, regardless of our timeline. We had never shipped more than three SKUs day-and-date before, and we were jumping that up by five, with our shortest production schedule in company history. Each platform adds a percentage of mindshare, specific rendering code, platform-specific UI needs, marketing assets, test requirements, etc, especially at the end of the project. Our internal team was not large enough to shoulder the burden. We pushed back as hard as we could, but to no avail. Either we did all eight platforms or there was no deal for the game.

So how to make this work? Since we hadn't yet developed any games for the next-gen consoles, we were excited to do those internally. PC would be our lead SKU, and Mac and Linux weren't a huge delta from that from a rendering standpoint. Our engine hadn't been brought up to snuff on the Wii U, 360, and PS3 in some time, but our internal programmers were chomping at the bit to dig into the next-gen hardware. We knew that we would have to outsource this work, so our producers got busy trying to figure out who could take it on.

We found a contractor to help with the last-gen ports, and it was everyone's assumption that they would be able to handle the ports without much oversight. That didn't turn out to be the case, as it eventually required our lead programmer and one of our graphics programmers to decouple themselves from their scheduled work to help work through the problems. Losing our lead programmer to whittle down issues on our last-gen ports meant that combat features did not receive as much polish as they could have, and some were even cut. A tough pill to swallow.

Our intuitions about how the ports would impact our team were well-founded, but it hurt us even more than we expected. Many months of gameplay polish were lost as a result.

2. Technical Debt

Costume Quest used the Buddha engine, which was created for Brütal Legend. Since Brütal shipped, we've used it for all of our 3D games, adding features and tools as we went. Since it had been a few years since we'd touched Costume Quest, we had to integrate it into an engine that had grown for those years. This tied up our lead programmer for most of pre-production and some of our early production. We also had lingering port issues for various projects that chipped away at his time for the first few months. This is one of the downsides to small teams. Support for your past projects follows you around as they overlap. Moving to another team is rarely a clean break.

After digging into the combat system in the original game, it turned out to be so specific and idiosyncratic that it wasn't easily extendable. It had been written under duress with tight deadlines when we were trying to ship. Unfortunately we didn't have enough time for a full rewrite, so we had to continue to hack around it. We were able to rewrite some crucial portions, but continued to get bitten by this inefficiency throughout production.

CQ's original UI was developed using Flash/Scaleform. Our lead programmer was familiar with Flash, but didn't have bandwidth to add this to his list. Everyone else that knew how this worked had either left the company a while ago or was tied up on another project. We ended up having to outsource development for this as well. It was a bumpy ride for most of the project until we hired Silvio late in production, and he smoothed everything out again.

3. Testing

Our internal test team is fantastic, but we only had a few on staff at the time. We had multiple games shipping on multifarious platforms, so there was no way they would be able to cover everything in the hopper. Majesco had their own test solution, but as we found out late, they outsourced much of it to India. Initially, our first few hundred bugs were typos or grammar bugs. Nothing addressed gameplay or crashes. We were getting nervous about performance, stuck-in-the-world bugs, or showstopping gameplay bugs, and we were lulled into a false sense of security going into the home stretch with a low bug count. Good bugs didn't come in until the 11th hour, meaning our hurry up and wait was followed by crunch.

Every system has a unique set of requirements they test to certify your game for completion (TCRs/XRs for Microsoft, TRCs for Sony, Lot Checks for Nintendo, etc). They often conflict, so you have to modify your UI and write a lot of special case code to deal with them. There are many console features you need to comply with, even if they don't apply to your game. And there are many issues that probably affect less than 1 percent of your players that you will spend beaucoup time on. The only real silver lining with this stage was that some of the hold ups of releasing the game due to certification delays allowed us to squeeze in a little more polish... despite the risk of making changes this late in the game.

4. Keep it Simple, Stupid

I personally got a little overzealous with a few things in my quest to make this the best game possible. One misstep was the front end UI. I was trying to come up with a nifty way to segue from Grubbins on Ice to CQ2 without costly cutscenes. We decided to have the game start in the portal world where Grubbins left off, using the portals as actual menu portals. We were able to get the concept up and running quickly, giving us confidence that it would be easy to finish, but game scripting in the core game always seemed to trump it on the priority list, and we kicked the can all the way to the end.

It never got the love it needed to be the experience I was envisioning. I think the end result is confusing, especially to uninitiated players. In the long run, it ended up costing us more time and effort than the cutscene I was trying to avoid. This might have been a fine idea to attempt in a longer schedule, but I should have known better than to burn energy on something other than the core game while our tiny hourglass was hemorrhaging sand. Reusing the original CQ menu system would have been just fine and cost almost no time.

There were a couple of other areas of the game where I kept pushing to add depth. We added secret fights with giant moles and snails to have more combat variety. We added a super long, byzantine mission to unlock the Solar System costume that took you through time and a giant tree into space. This mission turned out to be visually cool, but I would have liked to spend more time writing it. Another spend was when I found a pocket of animation time. We animated unique responses for every enemy in the game for Jefferson's special attack (The Declaration of Destruction). There were other time travel Easter eggs here and there, and post-credit epilogue dialog.

While I think each of these enhancements were generally successful, they also expanded the amount of work we needed to do, which reduced the amount of polish we were able to give the whole. I am used to being the guy waving the schedule in faces to get people to scope appropriately, but I found that when I am responsible for creating content, the devil on my shoulder was drowning out the angel. If you don't say no to the candy dish every time you pass it, you'll end up with a muffin top. I'm not saying CQ2 has a muffin top, I'm just saying that it doesn't have chiseled abs.

At Double Fine, One of our keys to success is that we often wait to ship games until they are ready. I always harken back to Miyamoto's famous quote: "A delayed game is eventually good, but a rushed game is forever bad." I think I wanted to have this mindset, but it did not apply to our game. CQ2 had no chance of being delayed. It had to be out for Halloween come hell or high water.

5. Shipping

Costume Quest 2 had a strong showing at PAX, keeping all 10 kiosks occupied at all times during the show, and getting some solid coverage from all the major outlets. We came away from PAX invigorated and ready to close things out! As we got closer to shipping, we were still dealing with late bugs and test requirement violations. Our Xbox One SKU was ready to go, but we held it back, as Majesco decided that we would ship on Sony and Microsoft platforms simultaneously.

That certainly made sense from a marketing standpoint, but as we got closer, it became clear that we weren't going to get through Sony cert for Europe in a timely fashion. This ended up meaning that none of the console SKUs would be out on time. We did go ahead and release the PC/Mac/Linux versions as scheduled (October 7). It became a growing concern that we might not be out by Halloween for the remainder of the SKUs. This would be a disaster for sales.

To exacerbate the problem, right around this time Majesco communication died down, and things went mysteriously dark. Much of the launch process is gated by the publisher, so having little to no contact with them made it impossible for us to get builds all the way through the process, or route bugs in a timely fashion. The delays begat more delays, as passing deadlines would cause us to redo other steps in the process. This seemed to be affecting the marketing push for our PC launch. They set up one press interview for me, and then after that there was nothing. What was happening?!  It was a frustrating time for us after getting to the end of so much work.

We still managed to launch our US builds three days before Halloween. Europe's build was never properly submitted because there wasn't anyone around on that side to push the requisite button. After the dust settled, we found out that Majesco was having financial trouble and had laid off most of Midnight City. This was the stage in the process where we needed them the most, and we knew that they were excited to be a part of it. We were sad for our friends at Midnight City, and sad for our game.

A few weeks after launch, Majesco recovered a little and hired on a new producer who began the cert process anew. Further delays were added as we tried to sync up with a marketing opportunity on Sony's website. As we worked towards that deadline, a new PS4 SDK requirement became necessary, and we had to resubmit. It seemed like every time we were ready to release, something new would crop up. We had also created Sackboy content for Sony the platforms, and even though it was ready at launch, the build saw so many setbacks that it wouldn't see the light of day until April 15 of the following year.

Everyone was trying to do what was best for the game, but it takes a lot of mindshare to track eight platforms. Shipping so many versions just bogged us down in a quagmire of cert requirements, bug tracking, and communication between the myriad publishers and our small team. I wouldn't recommend simultaneous launch on this many platforms to anyone shipping a game without a triple-A budget.

Conclusion

I had a lot of sleepless nights, waking up in cold sweats from dreams of tidal waves sweeping over me, but somehow we managed to keep our head above water in our waking life. If I have one regret, it is not pushing harder for more time. I looked at this game as an opportunity with a specific constraint, and made it a puzzle to work within those constraints... however unrealistic. That is the approach I'm used to with my production background: getting the proverbial pounds of shit to fit in the bag, no matter the bag's capacity. In the role of project lead, I needed to get help from another senior producer while I put the creative blinders on. Having someone next to me belaboring scope could have kept things more in balance.

Also, it may have been futile to fight for more time, but is it crazy to think that CQ2 could have come out the following Halloween instead, with a ton more polish? Or that maybe it would have been better to drop a few platforms or stagger their launches a little more? Perhaps it wouldn't have made a difference to beat those dead horses, but the fact that I don't know the answer, leaves me with some regret. We should have beaten at least one horse. C'est la vie.

My biggest takeaway is that the people at Double Fine are passionate about making great games, and will work together to overcome any obstacles you put in their way. I still can't believe what we were able to do in the short amount of time we had. Despite our limitations, we were able to fill this game with oodles of incredible art, animation, music, ideas, and personality, and somehow get it all to gel together cohesively. To me, Costume Quest 2 is a standard that represents Double Fine's infectious spirit. I couldn't be more proud of the team and the game that we shipped.

Data Box

Developer: Double Fine Productions
Publisher: Midnight City (Majesco)
Development Time: 10 months (1 pre-production, 9 production)
Development Team Size: Fluctuated between 12 - 25 people (2 - 5 during pre-production)
Platforms: PC, Mac, Linux, PS4, PS3, Xbox 360, Xbox One, Wii U
Release Date: October 7, 2014 (PC/Mac/Linux), October 28, 2014 (Sony Consoles), October 29, 2014 (Microsoft Consoles), October 30, 2014 (Wii U)
Development Tools: Buddha Engine (proprietary), Scaleform, Bullet, FMOD, Flash, Maya, Photoshop
Development Burritos Consumed: 4.7 x 10-9



Related Jobs

Wargaming Sydney
Wargaming Sydney — Broadway, New South Wales, Australia
[12.09.18]

Gameplay Programmer, C++ - Vehicle Physics
Cignition
Cignition — Palo Alto, California, United States
[12.07.18]

Game Programmer
Wombat Studio
Wombat Studio — Santa Clara, California, United States
[12.07.18]

Mobile Engineer
Charlie Company
Charlie Company — Culver City, California, United States
[12.07.18]

Senior Unity Programmer/Artist









Loading Comments

loader image