postmortems_notes.md

Postmortems Notes

Double Fines Brutal Legend

1. collaborative development [1]
   • The MUE (Multi-User-Editor) is our collaborative open world building tool which forms the backbone of our world production process. Its primary function is to allow designers and artists to work simultaneously on our large world.

• automated tests [2]
• testing farm [2]
  • One particularly crafty programmer came up with the idea to borrow idle Xbox 360s and PlayStation 3s to run automated tests. Team members could always end a test and take their machine back, but it was useful and efficient to use idle machines to run tests 24/7. We estimate that automated tests in the bot farm ran for a combined total of 147,000 hours.
• scrum [3]
  • After research into methodologies, we were drawn to the advantages of agile software development and decided to adopt Scrum. Within the first few months of Brütal Legend development, the team was practicing Scrum, and the initial payoffs were impressive.
• rapid prototyping [4]
• cross-disciplinary teams [11]
• people over process [12]
• continuous delivery [13]
  • Scrum's emphasis on features over systems, on rapid prototyping and iteration, on cross-disciplinary teams, on people over process, and on the creation of a potentially shippable piece of software every sprint/milestone made the game playable at a very early stage in development...
• acceptance test [5]
  • We tested our progress in periodic "Mandatory Hour of Fun" sessions, where the entire team played the latest build and then met as a group to discuss what was working well and what was frustrating or could be made better.
• pitch [6]
• trailler [6]
  • After shipping Psychonauts, Double Fine created a collection of concept work, a pitch document and a game trailer intended to capture the spirit of Brütal Legend.
• continuous iteration [7]
• concept refinement [7]
  • On Brütal Legend, the practice of continuous iteration and concept refinement led to a number of prototyped ideas, many of which survived to ship in the final game...
• middleware [8]
• continuous integration [9]
  • We recognized the advantages of middleware use early in the game's development. Selecting the right middleware to integrate allowed us to get the game off the ground early and facilitated the rapid testing of new ideas.
• tools creation [10]
  • From the start of development, we recognized that good tools needed to be a priority to ensure faster iteration times for our team.

Kingdoms of Amalur Reckoning

1. usability testing [14]

• feedback from real players [5]
• usability lab [15]
  • We made sure that getting feedback from real players was high on our priority list from the very beginning. Since we couldn't just release work-in-progress builds to the public and take surveys, we did the next best thing and took advantage of EA's usability lab very early in the development process.
• recorded videos [14]
  • Since EA's lab recorded videos of the wrap-up sessions, we were also able to show our team what the player thought of their part of the game.
• multi-functinal groups (pits) [11]
  • As part of our development philosophy, we have cross-departmental teams working closely together.
  • We did eventually break down the walls (literally) and start sitting larger functional groups together in what we called "pits" around the office. For example, the combat pit has animators and designers all sitting side by side.
• pure scrum [3]
  • I don't think that Scrum is the only way that people should be developing games these days, but after running pure Scrum for the entire development of Reckoning, I'm a firm believer in its methods.
• estimate his/her own work [16]
  • ...the basic element of Scrum that made it so successful at BHG is the ability for the individual developer to estimate his or her own work.
• old-fashioned waterfall scheduling [17]
  • With a basic understanding of our time metrics on content development, for example, we were able to do some good old-fashioned waterfall scheduling as well.
• sprint planning sessions [18]
  • The actual planning of what would go in to that base set and how long it would take, meanwhile, came from the sprint planning sessions where the artist would come up with his own tasks and time estimates.
• minicrunches instead of death march [19]
  • If something came up (and it always does in game development) the team knew that not completing what they had already committed to meant that it was in danger of being cut. That resulted in lots of minicrunches throughout the entire life cycle of the game instead of one humongous death march at the end of development.
• day-to-day accountability [20]
  • You understand within 24 hours of a change what is going on.
• feedback from publishers [21]
  • They gave excellent feedback throughout the development cycle and did what you really want from a publisher: They offered excellent support where we needed it most.
• preproduction too short [22]
  • Even though we had a lot of production time during the false starts before Reckoning, our preproduction time for Reckoning itself was entirely too short. ... we jumped in to full production with a lot of questions unanswered.
• tools construction overhead [10]
  • I'm truly amazed that the tools team did as well as they did with such limited time and manpower.
• too much demos [23]
  • Doing a demo for us was a pretty major undertaking, like it is for almost everyone in the business. You're basically taking content and systems that were meant to be first or second pass at a certain point in the schedule and bump it all up to shippable quality long before it's supposed to be shippable quality.
• demo extra work wasted [24]
  • This results in a lot of work that is just thrown out because the real content and the real systems end up changing a few weeks or months later.
• too much job for a small team [25]
  • Much like most of our teams on the project, they have to produce more content than would normally be expected for a team that size.
• cinematics cuts [26]
  • The cinematics we have in the game are awesome, and we got all the major beats that we wanted, but we definitely wanted more.
• upper management shuffle [27]
  • In July 2010, about a year into the development of Reckoning, five of the most senior studio management team at BHG left the company. This easily could have ended Reckoning in a lot of different ways -- the studio could have closed, or the game itself could have become a mess of unrecognizable trash.

Llopis and Friginals Caseys Contraptions

1. requirements and goals [28]
   • We wanted something that met three requirements: The game had to be creative in nature as opposed to using destruction as the main gameplay element, it had to be something we were excited about, and it had to be something with the potential to sell reasonably well on the iOS App Store.

• prototyping [4]
  • We prototyped game idea after game idea, and even though a lot of them were not bad, none were a complete standout. Eventually, after seven or eight different prototypes, we settled on the concept of creating physics-based, Rube Goldberg-like contraptions to solve different puzzles.
• team of two: design + programming [11]
  • We structured this project as a pure 50-50 partnership, and without any external funding or publishers. Miguel quit his full time job (as a web programmer no less!) to do the art for Casey's Contraptions, and Noel took care of the programming.
• service rather than a product [29]
  • games, are becoming more of a service rather than a product. Development and launch are only the beginning of the story.Games today, and especially iOS and Facebook
• iterative development [7]
  • For Casey's Contraptions we used a very stripped down and relaxed form of iterative development. We had short iterations and in each iteration we aimed to fully implement what we considered the most important features at the time.
• next iteration planning [30]
  • The most important concept is that at the beginning of each iteration we would make decisions about what to work on next, and those decisions were made with all the knowledge leading up to that point.
• list of possible features instead full list o game features [31]
  • we didn't start the project by coming up with the full list of items we were going to have in the game. Instead, we had a list on the wiki of possible items (to which we would add more whenever we thought of a new one during development), and we only decided which new items to add to the game at the beginning of each iteration.
• early announcing [32]
  • We started out by announcing the game more than six months before release (25 percent of the way into development).
• fixed release date [33]
  • We decided to set a fixed release date three weeks after the submission, which would give us enough time to do all the PR work: creating a video, putting together a media packet, contacting media outlets, etc.
• poor release planning [33]
  • Our initial plan was to ship the game by Christmas. It wasn't based on any rigorous estimating, just an off-the-cuff estimate. It just "felt" like we could be done by then. Obviously we were wrong.
• time to refinements [34]
  • We also gave ourselves sufficient time at the end for polish and style. [34]
• remote team [35]
  • The fact that we're working remotely didn't really affect most of our day-to-day development, but it definitely made hashing out these situations significantly harder, dragging them out for far longer than they should have.
• same revision [36]
  • However, we had a few parts of the game that we had to revise a few too many times.
• test feedback [21]
  • Some other times feedback from our testers made us realize that a screen wasn't clear enough as we had designed it and caused us to rework it.
• mock up [37]
  • Instead of starting by completely implementing a screen, or completely creating a perfect mock up with all the graphic elements, we need to start by laying out a screen with simple boxes and buttons and implement the basic functionality.
• incremental development [19]
  • Then we can make a first pass at a real layout and some graphical element, implement some of the new functionality and animations suggested by that, and continue iterating until it's done. We got much better about this in the last third of development, and it's something we want to carry forward to future projects.
• TDD [38]
  • Noel is a big fan of unit testing and test-driven development (TDD). Those are some techniques we used in past projects to very good effect and something we definitely wanted to carry into Casey's Contraptions as well.
• third parties [39]
  • By the time we noticed those problems and wanted to start adding tests, it was too late because some of that code relied on non-unit test friendly APIs like UIKit or Box2d.

Stardock Entertainment and Ironclad Games Sins of a Solar Empire Rebellion

1. limited number of art staff [25]
   • Stardock's other internal projects limited the number of art staff that would be available to us.

• tools contraint [10]
  • Additionally, engine memory constraints limited the number of assets that could be added.
• quality over quantity [40]
  • We ended up taking a quality over quantity approach, both as an intentional design choice and out of necessity.
• mvp program [31]
• feedback community testers [41]
  • Since the development of the original Sins, an "MVP" program was used to mitigate these problems. Through this program we invite some of our most active community members to receive regular builds throughout development and give feedback on the balance of new gameplay features.
• cutting features [26]
  • We decided to cut the feature, while leaving in the underlying tech for modders to experiment with post-release.
• update art and content on the fly [10]
  • The ability to update art and design content and see the results on the fly was invaluable, especially in a game where single play sessions can last in the tens of hours.
• stay on plan [17]
  • We knew from the start that switching engines or making major overhauls was out of scope for the time and budget we had to work with (as is usually the case with expansions).
• introducing new technology [42]
  • While the core tech worked great, the game was beginning to show its age. Instead of major overhauls, we identified graphics features that would keep us visually competitive with recent releases while staying within the scope of the project. Some examples include dynamic shadows, anisotropic filtering, and improving anti-aliasing quality.
• beta test [41]
  • For three months leading up to the final release, we ran an extended beta that ended up as one of the keys to success for the entire project.
• digital over retail [43]
  • Compared to the benefits of a digital-only release, both Stardock and Ironclad didn't think the date commitments and low cut of boxed product sales were worth the hassle anymore. That choice paid off.
• responsabilities overhead [25]
  • For the first six months of production, one person was juggling design, project management, and a number of significant project-external responsibilities.
• poor communication [44]
  • It led to a lack of communication on scheduling between studio management and the development team.
• poor estimates [16]
  • Initial estimates for the number of artists required were too low, and the project was starting to fall months behind schedule.
• backlog tasks [16]
  • After the tasks were organized into a backlog, team members in each department met to give rough estimates for these tasks.
• task estimation [16]
  • was broken down into more detail. Tasks were typically estimated as one day, three days, one week, or two weeks. Any task over two weeks
• daily standup [45]
• sprint review meeting [46]
• sprint planning meeting [47]
  • Once the project review was complete, we kept things on track with a daily standup and weekly sprint review/planning combo meeting.
• prioritize tasks [48]
  • Verify priority of upcoming tasks is still accurate
• staff departure [27]
  • Further complicating early development, a key employee we planned to assign to the Sins: Rebellion art team left the company.
• documentation before departure [49]
  • When they left, we had not yet staffed the art team, and there was no obvious person to transfer that knowledge to. Additionally, they were still assigned to another project within the studio, which took priority over documenting their pipeline knowledge in the weeks before departure.
• learning with documentation
  • When we finally did hire and free up art staff to come onto the project, much of the first month was spent re-learning that pipeline. Thorough documentation (or not losing the team member to begin with) could have saved time early on as well as making technical hiccups in the art pipeline easier to resolve later in development.
• separated teams [35]
  • Coordinating approval of game mechanic designs, UI visuals, and other art assets by email was a slow process. These "done pending approval" elements of the game multiplied the uncertainty that goes with most production estimates.
• in-house technology
  • One of our engineers was tasked with implementation of this major graphics feature, despite being unfamiliar with Iron Engine's graphics tech.
• bugs list [51]
• test scenarios [53]
  • In reality, we had introduced a number of new desync bugs that had a reproduction rate of nearly 100 percent if you were playing the right type of match.

The Chinese Rooms Amnesia A Machine for Pigs

1. pitch [6]
   • The game [YouTube trailer] was originally pitched as a short two-to-three hour experience entitled We are the Pig, although this initial design went through numerous changes and expansions during its development.

• company collaboration [44]
  • This project was however theZack Zero first time that either company had collaborated with another company on a project and this would have very noticeable consequences throughout the development process.
• crative freedom
  • FG took a very hands-off approach during early development, allowing a high degree of creative freedom amongstthe TCR team.
• ideas pool
  • This invitation to experiment meant that in terms of both gameplay and story, time was spent during early development throwing around a lot of different ideas for plot, puzzle scenarios, game mechanisms, enemy designs and enemy encounter scenarios. These
• technical limitations
  • While technical limitations of the HPL2 engine prevented the inclusion of the more complex ideas, a number of less technically demanding ones, encouraged by this creative freedom, did make their way into the final game.
• no repeated formulas
  • The aim was to bring a fresh approach to the established Amnesia gameplay.
• comunity feedback from previous project
  • The response of the community to these early media releases was instrumental in fueling further creativity during the game's development, as a number of forum posts discussed ideas or different plot interpretations that had not been considered.
• game design document
  • However, throughout a long period of the game's development (approximately the first 6-7 months), and as per the game's original design document, the sanity system was to be replaced by an "Infection" system.
• cutting features [26]
  • After many attempts at integrating the system more convincingly into the game, the decision was taken to remove it. This removal, while certainly not trivial, allowed much more focus to be paid to the core essence of the game -- the story, and the environments through which it is told.
• third party tools
• early assets development
  • The HPL2 engine is certainly not without its quirks, and a long time was spent during early development working out appropriate asset pipelines and the most efficient ways of implementing different features.
• T skill profissional
  • For a small development team particularly, it was important that everyone should be able to make use of the most critical tools, such as the level editor and be able to understand and make changes where necessary within the level scripts.
• everyone's source code
  • The accessibility of the source code for the toolset meant such changes could be completed with little or no assistance from FG, which meant minimal delays during development for tool-based problems.
  • Similarly, the accessibility of the AngelScript-based API used for writing the game's level scripts meant that basic events could be implemented or adjusted by multiple team members rather than relying solely on the scripter.
• debugging
• rapid creation and testing
  • HPL2 also already contained a number of useful debugging tools. While not being comparable to more established game engines for obvious reasons, the included features were targeted specifically at the rapid creation and testing of Amnesia style gameplay and worked very well.
• cohese team
  • The core development team's ability to work well together with minimal man-management required was one of the most obvious successes of the development, and without doubt influenced the quality and cohesiveness of the final product.
• ideas exchange
  • The combination of experienced staff and fresh graduate staff provided a catalyst to a number of useful if sometimes rather heated debates about the best way of implementing a particular feature, of lighting a particular area or of scripting a particular enemy encounter.
• remote team [35]
  • Throughout development, the entire team was working remotely with staff working from the UK in Portsmouth, Brighton, London, and Winchester, along with others in Belgium and FG based in Sweden. Communication was carried out primarily through Skype, with email used when paper trails were necessary.
• team's excitment
  • Lastly in this section it is necessary to mention the team's passion, and the belief in the story TCR were trying to tell.
• short deadline
  • While FG provided TCR with a high degree of creative freedom in terms of the game's content and design direction, the deliverable milestones requested were much less flexible.
• complete level instead of grey-boxed game version (prototyping)
  • Whether the decision to request a completed level rather than a complete grey-boxed version of the game as the first milestone stems from FG's lack of prior experience acting in a production role is difficult to say.
• prioritizing tasks [48]
  • While the team were fully aware of the major tasks that needed completing at any given time, and were adept at prioritizing appropriately, there was no central documentation that kept track of tasks, internal milestones or game bugs.
• testers' team
• feedback of deliverables
  • Many areas of the game were reworked two, three, or even more times based on different and often conflicting feedback on deliverables.
• extended development time
• delayed release
  • However, from this early success later media releases were too few and too far apart given the extended development time and delayed release.
• midias' release review
  • The early release of a review copy to YouTube personality Pewdiepie was an unexpected decision by FG made without TCR's knowledge, and demonstrates the difference in aims for the game between the two companies.

Intelligence Engine Design Systems City Conquest

1. AI-focused development
   • But there was an unexpected revelation along the way. I had not expected that AI would change everything I thought I knew about game design.
   • The more I learned about AI and game design, the more I began to understand that they are two sides of the same coin.

• limited time scope
  • The goal was to limit the scope to a one-year development cycle while ensuring that it was a serious game development effort with genuine potential to grow into a franchise, rather than a quickie game for the sake of "learning."
• cost-to-quality ratio
  • Our goal with City Conquest was to optimize the "cost-to-quality ratio": the best possible product at the lowest possible cost. Our years at Retro Studios / Nintendo imbued us with an obsessive focus on product quality and polish and a conviction that this diligence pays serious long-term dividends.
• risk management
• minimizing overhead
• outsoucing
• small team
  • At the same time, we were determined to reduce our risks by minimizing our overhead -- we would avoid growing the team any more than absolutely necessary, and we would outsource all of our art and audio needs while handling the design and production and the majority of the engineering ourselves. In large part because of this risk-centric attitude, IEDS maintained a very small team throughout development of City Conquest.
• prototyping
• gameplay driven development
• find the fun
  • We had a basic playable prototype running within a month. The concept worked better than we had any right to expect. Our decision to use a fundamental gameplay to drive the game's development, rather than any particular narrative arc or artistic "high concept," went a very long way toward ensuring that the game would be fun and playable.
• refinement time
  • City Conquest was completed several months later than expected, but most of this delay was for the right reason: because we were determined to optimize for quality and had the time to make the game better.
• AI-based design
  • Our AI-based approach to design paid off in spades. There is no question in our minds that this exceeded our expectations and improved product quality and time-to-market.
• decision modeling process
  • The defensive towers and unit types in City Conquest were not based on arbitrary creative decisions: nearly all of the decisions around their functional aspects were guided by an explicit decision modeling process.
• automated test tool
  • Evolver was an automated balancing tool based on coevolutionary genetic algorithms. Every night, it would run a huge number of simulated games between red and blue opponents, with each opponent evolving a "population" of scripts (each script being essentially a fixed build order of buildings within the game).
• otimizing for test
  • We optimized Evolver by disabling the rendering, adding task-based parallelism, and hand-optimizing the gameplay logic. This allowed us to achieve roughly 1 million simulated games per 12 hours.
• human playtesters
  • We also benefited enormously from having a large number of playtesters in our TestFlight team for eight months leading up to release giving us the invaluable aesthetic, usability, and other subjective feedback that Evolver could not.
• fix bugs immediately
  • Our approach is to fix bugs immediately. We don't work on any new features or continue any other development until all known bugs are fixed.
• discovery-driven planning (DDP)
  • The discovery-driven planning (DDP) process is explicitly tailored toward innovation-oriented projects and focuses on reducing uncertainty. For all the changes we know are inevitable in our designs, developers don't typically factor that learning into our planning or use planning methodologies directed toward identifying and reducing uncertainty.
• agile
  • We adopt Scrum and other "agile" methods, and we adjust our plans as circumstances change, but we generally make no effort to quantify our uncertainty from the outset or to plan in a way that will ensure that we focus on the most important risks.
• performance matters
  • City Conquest places huge performance demands on mobile hardware, including some relatively modest devices such as iPod Touch 4. It required extensive optimization and careful attention to performance at every level.
• Third party
  • We chose to build the game with Marmalade precisely because it was not an engine, but only a thin, high-performance cross-platform API layer.
• careful cost management
  • Our tiny studio size and careful cost management ensured that we minimized our overhead and kept our breakeven as low as possible.
• teaching by conceptual elements
  • Ultimately, there was no choice but to take a deep breath and refactor the mission design completely. We separated the game into five different conceptual elements -- attacking, defending, expanding your territory with Skyscrapers, using game effects, and swapping dropship pads -- and built at least one specialized mission to teach each of those five core gameplay elements and use them in an entertaining way.
• release strategy
  • We released City Conquest on iOS as a free download, with a single $4.99 in-app purchase for the full game. The free version contains the full multiplayer experience plus the first five missions of the single-player campaign (out of 14) and the first of the six bonus "challenge" missions.
• funding strategy
  • There were two City Conquest Kickstarter campaigns. We set the initial goal at a modest $12,000. When it moved too slowly, we canceled it, worked on extensively polishing the game, and returned a few months later with a better pitch, a better product, and an even more modest $10,000 campaign.
• testers' team
  • We brought on the Full Cycle Engineering team to replace our proof-of-concept netcode with a serious multiplayer implementation. The multiplayer undoubtedly is a far better experience now than it could ever have been without their contributions.

Overhaul Games Baldurs Gate Enhanced Edition

1. modding community feedback
   • Early on we knew one of the key elements to succeeding with the Enhanced Edition of the game was to bring in as many people from the modding and fan communities as possible. By working with them and listening to them, we could make the right changes and try to improve the game to better meet their needs. Our first few attempts were crude -- an invite-only Reddit, some direct e-mails -- but things rapidly turned around with the launch of the official message boards where we could speak directly with the modders and fans and listen to their concerns.

• private beta test
  • We shared new content with them as early as possible and acted on their feedback to make the game a better experience for users and a better platform for modding. We did this through hosting a long-running private beta. We would push a new build out to the beta group, have them poke it and respond with suggestions and feedback.
• market prospect
  • We proved you could produce an epic, massive RPG in the tablet space, and the market was starving for such a project.
• refinements
  • We've added to this level of polish recently with a further enhancement we call smart radius.
• follow guidlines
  • We listed all the required UI elements and slowly re-constructed all the art and panels around the new portrait sizes, we also tried to embrace some UI guidelines from Apple for the iPad, trying to keep buttons over 44 pixels in height (we only failed in a few spots like class selection).
• beta testing
  • We beta tested the game for over six months. Throughout this time, the feedback on how to improve the game was tremendous.
• recruting
• bug database
• beta bugs
  • As mentioned above, this beta testing group was a volunteer group recruited from our forums. We chose people with strong skills and a good background with the original game and as such, the feedback was fast and on-target. The beta team had access to our bug database and beta bugs went straight into the system.
• outsourcing testing
  • We also hired an external testing company, iBeta, to help us final the iPad versions and to ensure testing coverage. They were able to run us through a "pre-certification" style testing to catch the differences between the different iPad hardware devices.
• digital distribuition
• direct selling
• preorder
  • Beamdog is two parts; an online digital distribution service, and our game development team, which we call Overhaul Games.
  • We developed the Beamdog Store with the goal of selling our games directly to our users -- no middlemen, no confusion on support, just a developer and a customer.
  • The direct-sales option and a preorder program allowed us to receive payment many months in advance of a typical royalty-advance deal, which was a great benefit for a small, self-funded developer.
• continuous delivery
  • The other great benefit was how our digital distribution service allowed us to push out beta builds of the game six months in advance and update testers to new versions without a hitch.
• fast build distribution
• version control
  • We use Beamdog daily internally for all our build distribution, and without it we couldn't have been nearly as agile in our response, effective at version control, or as fast at build distribution.
• code removed
• scout work
  • The code was also heavily laced with critical sections, which caused (in some cases) 70 percent of execution time spent in no-ops. Our long-term solution was to machete in and remove the threading, removing a couple hundred thousand lines of code from the game.
  • We always found a ton of complexity solving an era-specific problem that no longer applied. We continue to find roadblocks in the code and we're improving it as we go.
• architectural improvements
  • Complexity is par for the course in an RPG of this magnitude, but the intricate linking of assets and code really limited our ability to make the architectural improvements we wanted to make.
• re-pitch
  • At this point we brought the information back to Atari and the deal was dead in the water. Cameron and I spent a few weeks re-thinking the concept and we re-pitched Atari with an "Enhanced Edition" as opposed to an "HD" version.
• opengl
• quick teste
  • We went into development on BG: EE with a clear goal to target the OpenGL 2.0 specification (from 2004) for all functionality, to ensure support on all devices.
  • We did some quick testing on PC, on Mac, on iPad, on Android, and passed on all counts. Raspberry Pi, check. Raspberry-freaking-Pi OpenGL 2.0 support, check.
• expanded beta testing group
  • We expanded our beta testing group (and quite possibly due to the enthusiast nature of the participants in our beta) we had very few performance issues reported.
• after release feedback
  • During this timeline, we shipped the game on PC. We started getting more reports of poor performance and graphic problems.
• re-building
  • By talking with the Intel fellows, we've learned where we fall off the good path in their implementation and we have a new plan on how to re-build the entire system around those issues.
• fixing performance
  • We quickly diverted most of our key programming effort to fixing the performance concerns. We fought a war between hurting the visual upscaling quality and improving the framerate.

Frozenbytes Trine

1. modify scope

• change plans
• change schedule
• small team
• inexperienced team
  • How do you transform a game designed to be made in a few dozen man-months into something that takes hundreds of man-months? While the process was painful, the key was understanding that change was necessary. Many of the original design decisions were made to fit the original plan -- less than 12 months of production with a team of just a few inexperienced people.
• team departure
• team motivation
  • Having worked so long on an AAA-class project that never made any income for the company, a crisis was evident when the project failed. Some team members left the company, some of whom were considered very important at that time, and motivation for the remaining team was swinging from left to right when they were added to the Trine team.
• creativity freedom
  • A decision was made -- partly because of lack of time to focus on such a task amidst all the chaos -- to give the art team and the newly promoted art director almost complete freedom with regards to the game's visual style.
• schedule
  • There were only minimal schedule delays, most of which were caused by external additions, such as marketing materials.
• low level communication
  • Low-level communication also helped a lot -- the project didn't have any middle management, and many issues were solved by direct communication between artists and programmers.
• vision instead design
  • Trine followed a vision, not a strict design.
• porting
• overtime by programmers
  • At first we were only able to afford one PS3 debug unit. With that and access to the relevant documents and information, we began porting our existing technology to the PS3 in January 2009.
  • In five weeks -- and lots of overtime from the programmers -- a bare-bones version of Trine was running on the debug.
• trailer construction
• game changed for trailer
  • The trailer itself took many weeks of careful planning and hard work. It was very much a personal mini project for the game's producer and original concept creator. Many passages of the levels were modified to suit the trailer --obstacles were removed, geometry reworked, enemies added for extra fodder, and so on.
• press coverage
  • We did everything we could from materials to press announcements, previews, interviews, websites, reviews and ultimately end-user support . We were keen to get as much press coverage as we could and it paid off.
• continuously change in design
  • Considerable time was spent on making sure the characters fit the game's atmosphere. Originally the game featured a very generic knight, thin and lean with a sword and shield. As the game's art style progressed into a more and more vivid and vibrant direction, the knight started to feel too serious and boring.
• ideas pool
  • His transformation was the driving force for the final mood of the game -- making him fat instantly stroke a chord with the team and spurred further ideas, including great, just-right animations.
• team grouped by role
  • There had been a couple of (internal) writers and many of their ideas had been good, but things hadn't moved forward. The art team had been making levels without any regard to the plot, and at some point it was realized that the levels were more or less ready and there was no story connecting them, as there was no story at all other than a few different introductions and dialogue pieces.
• gameplay focused development
  • A goal was set -- whatever the story, it shouldn't affect existing levels; instead it should focus on simple things and try to convey the desired atmosphere and mood of the game. In essence, it was accepted that the story would not bring the game any awards -- we weren't aiming for the moon and stars -- but at the same time it should not bring it down in any way.
• cutting features
  • With time running out and effort needed elsewhere too, we cut everything that we could and stuck to the bare minimum.
• ready-made assets
  • The plan was to buy a lot of ready-made assets to speed up the development -- graphics quality was not a concern at that point.
• budget increased
• plan revising
• continous design changes
  • When the project was elevated to "proper status" and the budget was increased to 300,000 euros, it was clear the original plan needed revising.
  • While the broad scope of this change was successful and didn't have many problems, we kept making small design changes to the revised design down the line.
• team communication
• team aceptance
  • Everyone was passionate, especially the original designer/producer/programmer who also had money invested in the project, and passionate people do not give up on their ideas easily. Each design change also had to getcommunicated to the team and sometimes the confusion stemming from design arguments would cause uncertainty as to what the final design was supposed to be.
• self funding
  • As our contract with the publisher was more akin to a distribution one than a full-blown publishing contract, our increased ambition was not in any way reflected in the milestone payments we had agreed upon, and ultimately we ended up funding two-thirds of the project on our own.
• increasing team
• increasing scope
  • The project's budget and resources were in constant motion. Instead of cutting down design and scope in the early stages, we pumped up production resources with a "yes we can" attitude and gradually added more people to the project. Luckily, our empty bank account kept us from going overboard, otherwise we probably would have made the fatal mistake of adding too many people to a delayed project.
• testing phase
• bugs
  • but the problems started to become evident with Trine, especially during the testing phase where weird and "unfixable" bugs occurred.
• low documentation
  • We neglected proper design documentation, production plans, programming plans and sometimes even art supervision. Everything happened at the last minute. In hindsight it's great to reminiscence how the team pulled together, but it certainly did not feel like the right way to do things at the time.
• indecisiveness and procrastination
• last possible moment
  • Because of indecisiveness and procrastination, the final story -- not just a revision of it, but the whole thing -- was written two days before recording was scheduled to begin in March 2009, a few months before the scheduled gold master date.
• schedule gold master
  • The state of the overall project and its overambitious design was finally understood in May 2009, roughly a month before the scheduled gold master.
• in-house QA instead publisher QA
  • Despite this, our in-house QA was much more useful than the external QA the publisher had set up -- in the future we plan to use in-house QA and general testing sessions to a much greater effect, and start them earlier.
• publisher communication
  • The submission process was shrouded in mystery as all the communication with SCEE was handled by the publisher. Throughout the development, our relationship with the publisher had been difficult, and the submission process probably suffered from this as well.
• submission process
  • Another group of bugs, such as wrong filenames or wrong program version numbers, could have been solved by a more experienced publisher, or by having direct control over the submission process.
• QA final acceptance
  • The team's, and especially the management's and the programmers', moods swung from the first submission's triumphant joy to annoyance to desperation to humorous disbelief during these weeks of constant waiting for new QA notes and final acceptance.
• PSN versions
  • The PSN versions were finally launched on the 17th of September (EU) and the 22nd of October (US) of 2009 -- the one month delay between Europe and North America further highlights the submission and launch problems with the project, as the only major difference between the versions is the amount of languages -- Europe has six languages, North America only three. Both versions had been completed at the same time.
• game updates released on the console
• platforms
  • It is much more difficult to get game updates released on the console platforms, and this was something we were not prepared for.
• patch it later builds
  • In hindsight we probably should have fixed many additional things during the submission process but after a couple of failed submissions we were too intimidated by the risk of breaking existing stuff and thus further delaying the game that we rather went the "let's get it out and patch it later" route.
• level's development order
  • When your game is divided into separate levels, in what order should they be created? We didn't struggle with this question -- the tutorial was made half-way through the project so that it would reflect the game reasonably well, and the last level and the end boss were left until the very end of the project.
  • This was improvement over the Shadowgrounds games, where the development followed the games' level progression.
• balancing adjust with patchs
  • We made the speed of the rising lava slower with patches and removed it from the easiest difficulty.
• code base reused
• engine expansion
• cost estimate
  • The same code base has been used in all of our games since, including Trine. As layers and layers of new code have been added to the engine, the cost estimate of adding online multiplayer has always increased with each project, and it became very hard to justify the additional cost of rewriting the game engine -- or rather, getting enough money to complete both the rewrite and whatever game we had in production.

Unknown Worlds Entertainments Natural Selection 2

1. unstructured development
   • We had no producer, no schedule, no milestones, and no meetings. We also had no design document, no technical plan and no business plan.
   • Our core team was seven people in a room, but we also had many critical remote contractors and part-time community contributors. Every time we tried daily meetings, we ended up deflated and demoralized. It made no sense why spending 10 minutes a day talking about our work made us so unhappy, but at least we were smart enough to stop. No status meetings naturally extended to no meetings at all.
   • We did try to have a schedule, but we found it was inaccurate and out of date instantly. It didn't seem worth maintaining something that was perpetually wrong, so we stopped doing it. After writing a business plan, I realized that I learned almost nothing writing it. A year or two later I realized I never looked at it, either. If I wanted to describe "our plan" to someone, it was easier to send along a couple paragraphs by e-mail. Very few people will get through a 40-page business plan anyways.

• implemetation over documentation
  • And not having structure meant we could adapt to changes very quickly, and that we could spend all of our time working on the game, instead of planning it.
• high level concept instead of design document
  • One reason this unstructured approach worked for us was due to our design process. Instead of a design document, we used four "pillars" to describe the game. Each pillar is the name of a feature, described in specifics by a short paragraph. Imagine the bullet points on the back of your future game's box (even if it won't have one). All decisions about high-level features were compared to these four pillars.
• everyone ideas
  • This let everyone on the team have a set of "beacons" for the game direction, which allowed everyone to vet new ideas, have discussions and cut long conversations short if they weren't advancing one of these high-level goals forward.
• team cohese
• multidisciplinary team
• design principles
  • At a lower level than features, we kept artists, level designers, programmers, and animators working together cohesively through a set of design principles.
• day one playing
  • From day one, everyone on team played the game -- even before we had any art assets or game-specific code. The first thing we did was create a basic level, coded a rifle and an alien bite, and ran around a small box attacking each other.
• gameplay test
• looking for fun
  • These tests were great for boosting our morale, and getting us in the right frame of mind: shipping. We had a game, albeit an ugly and boring one; now we just had to make it fun.
• features reworked
• cutting features
  • It's quite difficult to ignore gameplay or implementation problems when you're hearing or seeing their exasperation about some aspect of the game. Many features were reworked multiples times and/or cut to fit our tastes.
• iterative development
• non-designers feedback
  • By the time we released, NS2 had many thousands of games played, so we didn't have much to fear. Through this iterative development, I came to understand just how important it was to take feedback from non-designers, and the game was so much better because of it.
• open development
  • As a small company without a marketing budget, how do you build an audience? We decided to take our fans "behind the scenes" and open up our development. We blogged, tweeted, recorded video footage around the office, and otherwise became as transparent about our game development as possible.
• pre-order
  • When we were almost out of money (the first time!), we thought: "Why don't we ask our community if they would pre-order our game?" We put together a polished video that shows the technology, and a first look at the new game, and launched it with our preorder program.
• humble bundle
  • Open development helped us again when the Overgrowth team suggested that we do an unprecedented "preorder bundle" of our two games, and make it a PR event. We thought it was a great idea and we generated another $40k each in just a couple days. It worked so well that they then formed Humble Bundle, Inc. and turned it into a profitable venture-backed business.
• playable alpha community mod
  • Another way we leveraged open development was way before our playable alpha. We didn't have any maps yet, but we did have assets for making maps. So we released these props and textures, along with a document describing how to build a map and our barely-functional editor. Some of our pre-ordering folks started making maps right away. We asked the most promising community members to work on official maps for the game, for a share of the eventual revenue instead of our sparse cash.
• community QA
  • We used it to assemble a die-hard group of volunteers that performed all our QA and gave us tons of valuable feedback.
• community feedback
  • At every step of the way, we would release what we had, talk about what we're building and why, and listen to feedback.
• No crunch
  • One of the reasons we started Unknown Worlds is because we believed making quality games and having a great life went together. We view game development as a marathon, not a race. So we made sure to keep fit, have a life and not crunch.
• scope
  • Natural Selection 2 was an ambitious follow-up to our free independent Half-Life mod, Natural Selection. Our original plan was to make a quick commercial sequel on the Source engine to start making money. Instead, we spent six tough years developing our own engine and almost going out of business multiple times.
• tool creation
  • We also decided we wanted to make the most moddable game ever. We did this by implementing 100 percent of our game code in Lua. There wasn't a Lua IDE on the market that we thought was good enough, so of course we spent more time to write our own (called Decoda).
• self management
• proactiviness
  • We have a completely unstructured environment, without task lists, priorities, managers, producers, or even job descriptions. We rely on people to figure out the best thing for them to work on, and how to do it efficiently.
• performance optimization
  • It wasn't until close to release that we realized we had some fundamental engine optimizations to make that we should have caught earlier. So we ended up making some massive technical changes within a week or two of launch.
• launch press
  • We wrote approximately 600 members of the games press and dozens of YouTube channel owners. Each received a copy of the game, a press kit and an invitation to play, review, or interview us.
• keep the vision
  • While the road we traveled was hard, we consider ourselves extremely lucky that we never had to modify our vision for the game to fit a marketing plan, publisher desire, current trend or brand.

Tale of Tales The Path

1. prototyping
   • In July 2006, a first prototype was committed to our 144 repository.

• reuse
• indie development
  • We decided not only to re-use the Girl in White character from 8 and the Drama Princess engine for autonomous characters, but also the environment rendering system of The Endless Forest. This re-use was one of our ways to reduce the development budget.
  • After not being able to secure the -- for us -- gargantuan sum of 1.5 million dollars required for 8, we were determined to make a game for a budget that was so small that we didn't need the support of the games industry.
• cost reduction
• digital distribuition
  • For this reason, The Path was going to be a short game that was mostly non-linear (no plot-based narrative, emergent behavior, few cut scenes). And we were going to focus on digital distribution exclusively, not only because it makes sense in terms of technology, but also because it reduces production and marketing costs while drastically increasing the revenue share for the developer (meaning a much smaller volume of sales is required to break even).
• funding
  • By the end of 2006, we had secured another 26,000 euro from the Flemish Audiovisual Fund and Design Flanders for a first phase of the production. The support of Creative Capital continued throughout the project until the day of launch (which they funded). Ultimately, they have contributed almost 50,000 US Dollars to the budget (sadly, at a time when the dollar was at an all time low).
• pre-production
  • In January 2007, we implemented the Drama Princess engine in the 144 prototype, which signified to us the start of the actual pre-production.
• marketing blog
  • Making a commercial game and deciding to publish it ourselves immediately meant that we were going to have to work on our marketing. In February 2007 we stopped resisting Web 2.0 and started the Tale of Tales blog.
• collaborators
  • In May 2007, a first prototype of The Path was sent to our collaborators, animator Laura Raines Smith, and musicians Jarboe and Kris Force, after which they joined the project in earnest.
• development break
  • Partially to force ourselves to take a break, and partially because of marketing benefits, we decided to interrupt the production of The Path briefly to develop a small game that we had acquired some arts funding for.
• pre-launch
  • On 17 March, the day before leaving for the Game Developers Conference, we "pre-launched" The Path with co-producer Villanella in the Muhka Media Film Museum in Antwerp. The evening consisted of an interview with Flemish culture diva Chantal Pattyn, a short playthrough of the game on a big screen, the opportunity for the audience to play The Path before its official launch date in the company of a Robin cosplayer, our first!
• concept art
  • Very early on we worked with concept artists. I was anxious to prove that it would be possible to bring in some amazing artists who could take our vague ideas and surprise us with a new interpretation.
• outsourcing assets
  • But I thought, surely, we would contract out the building of Grandmother's house, at least.
• outsourcing people
  • We ended up searching for people and wasting a lot of money in the process. We had tested several modelers to work with us and had high hopes of finding someone that we could work with permanently.
• implementation over planning
  • And so, there is not a lot of beautiful concept art from the project. It is not that I didn't want it, but I must admit I doubted its practical usefulness, anyway, in bringing out what I wanted this fully 3D world to be. 2D is not 3D. I needed to feel this world with my hands.
• prototyping based development
  • Our process consists of making the game and then designing it . That means using prototypes as a tool for guiding the design. As soon as we can, we want to have something in the game engine to play with.
• new ideas implemented
  • Through this process we came up with ideas and quickly implemented them in the game with the actual characters, so we would get an idea if things are a good idea or not.
• designing all togheter
  • The music Jarboe and Kris Force made for the game had such an enormous effect that it changed our thinking about the game design. And this, we feel, is as it should be. A video game should not be seen as its individual parts. Each individual model is not a sculpture unto itself, but more like a brushstroke in a larger picture.
• indie
  • The Path was our first commercial video game project. And it's also the biggest project we've worked on so far. It was a completely independent production: managed by ourselves and funded with art grants and a loan.
• art focus instead of tech
  • In the production of The Path, we also had to make some tough choices between improving our technology and polishing art. Since we thought the aesthetic appeal of The Path was going to be one of its strongest features and since we are far from master programmers, we compromised heavily on the technology side.
• planning project phases
  • We had planned the production to be finished quite a bit before launch, to allow us sufficient time to fine-tune the experience.
• crunch time
  • For four months in a row, we worked 14 hours per day.
• target audience
  • A more painful place for us to fail was our hope to reach an audience outside of the typical gamer demographic.
• self marketing
  • Independent marketing consists for the most part of manual labor: sending emails, posting to forums, talking to press, making blog posts, etcetera.
• model-driven development
  • In Quest3D, you don't write code. You express your ideas about processes and interactions through flowcharts --much like the flowcharts a programmer might draw to design a certain routine before coding it. However, in Quest3D, the flowchart actually works, with no additional coding. And it works in real time! As you connect the elements of your flowchart, the behavior of your application changes. The visible programming interface combined with the direct feedback makes Quest3D a superb tool for artists to work with software.
• port to specific plataform
  • The biggest downside to Quest3D is that it can only output applications for Windows. Luckily we found Transgaming, which was willing to port The Path to Mac OSX through its Cider technology.
• team of artists
  • Each member on the development team for The Path is an artist. Not just an "artist" in the games industry sense of the pairs of hands required to make Thee Mighty Code look and sound pretty to human players, but an artist in the sense that they are capable of communicating on a profound level through their medium.
• community beta testers
  • This time, we sent a message to our mailing list to invite people who live in or near Belgium and were available for an entire day to come and play The Path at our studio. Many people responded, and in the end we made 12 appointments. Each tester would come to our studio and play the game in a room set up for the occasion. The first few hours we would sit there and watch them play without saying much. Then we would evaluate their experience over tea.
• accessibility
  • After that, we would leave them alone for a few more hours, to play the game in private. This series of thorough playtests has really been eye-opening to us and probably greatly contributed to the accessibility of The Path.
• newbie over hardcore gamer
  • So we had to make some hard decisions about whom we were making the game for (in the end, the enthusiasm of the newbie player trumped the skepticism of the hardcore gamer).
• Online testing
• community bug tracking
  • A second round of tests was done when the game was almost finished, mostly to find technical errors. This test was done through the internet. Testers would download the latest build of the game and play it for hours, days, weeks. Some people were very dedicated.
• marketing blog
  • As of then, to some extent, everything we did online served as marketing for The Path. The Tale of Tales blog served as a central hub.
  • But thanks to the blog, publishing our opinion pieces instantly became marketing for our game. And that was all the motivation we needed.
• monthly press release
  • We also created a plan of sending out one press release per month throughout the entire production to a list of email addresses we had started for The Endless Forest but which grew exponentially throughout the production period of The Path.
• lowering prices
  • We actually thought The Path would be largely ignored by the press, or receive a lukewarm reception -- but we really wanted people to play it. So in order to reduce the risk of purchasing a game that you can't find a decent review for, we decided to make the price as low as possible.

Humble Hearts Dust An Elysian Tail

1. indie
   • This is the story of how Dust: AET came to be, along with what went right and wrong during production and launch. Admittedly it was hard to come up with a list, because when you are independent and your livelihood is at stake, you can't afford to let things go wrong.

• start from scratch
  • A week of rudimentary tutorials later, I quickly realized you have to make EVERYTHING from scratch! Nolevel editor existed. No animation tool. No scripting or dialogue systems. No nothing -- just a bunch of otherworldly programming words.
• self learning
  • Most of my education came from online tutorials, and while each one provided valuable insight into the process, very few were directly applicable to what I wanted to achieve. That's when I came across James Silva's book on developing for XNA, which he had written while working on The Dishwasher.
• pen and paper design
  • I would rough out each motion with pencil on paper, and then do a digital pencil test. When I was happy with the motion, I would ink each frame on my light table, scan the artwork into Photoshop, and then separate the shadow layer out and do cleanup/color/shading (a technique I developed while working on my film).
• sprite tech
  • Each frame would be downsampled from film res to a 300x300 block, and arranged neatly on a sprite sheet. In the end Dust himself comprised over 500 unique frames of animation, across four massive 4k sprite sheets. Dust alone used up most of the RAM available on the Xbox 360.
• tool creation
• level editor
  • Again, with the help of James' book, I crafted a level editor that would allow me to incorporate my skills as a painter.
• outsourcing team
• remote team
  • I first reached out to an old friend, Alex Brandon (Funky Rustic), of Unreal/Jazz Jackrabbit/Deus Ex fame. While I couldn't bring him on full time, he did end up providing a number of wonderful tracks for the final game. Shortly after, I met a couple of guys out of Ireland, who would eventually define the sound of Dust: AET and bring it to a level beyond my wildest dreams.
• publisher
• pitch
  • A month later, Microsoft got involved. After several months of pitches and contracts, Dust: AET was upgraded to the status of Xbox Live Arcade. I was assigned a producer to work with, Andrew Williams, who not only became instrumental in providing feedback and championing the game up to its release, but a good friend as well.
• publisher feedback
• freedom for development
  • They were about as hands-off as a publisher could be, but always provided valuable and objective feedback on the game (which I needed after staring at it from a foot away for nearly four straight years). They never forced me to change a gameplay feature or add in something to appeal to a different market -- they let Dust: AET grow on its own, and I think they know that's the best way to do it.
• full time job
  • Signing that deal had charted a new direction in my life. My small three-month project was far behind me and I would spend the next three years, without breaks or weekends off, finishing the game.
• online resouces recruting
  • Taking the indie-level budget into consideration, for months on end I focused on scouring several corners of the internet for aspiring and freelance vocal talents.
• remote coordination
  • Having all my actors record remotely from their home studios and directing them over Skype provided some challenges in and of itself, but made the end result that much more unique and special to me.
• deadline shortned
  • When an accelerated deadline was imposed near the end of production, I was left with three options: do the cutscenes as motion comics (a technique I'm not fond of), remove them completely, or use a limited-animation technique similar to anime.
• crunch time
  • During the most severely brutal period of crunch, I created over 6 minutes of hand-animated cutscenes for Dust: AET in a matter of weeks.
• schedule change
  • After a lot of back and forth with Microsoft, my family, and a whole lot of prayer, I said yes to Summer of Arcade. I would have to take an already massively difficult eight to 10 months of development and cram it into three.
• hard crunch time
  • Much of what happened after that is a blur. I was already used to working seven days a week, but now those turned into nearly 20 hour workdays.
• scope reduced
  • On the subject of trimming content, Dust: AET was originally envisioned as a much larger game than it ended up being.
• documentation
  • I suggested that Dean reconsider the "build your own village" concept, but I could tell he had already crossed it out of his own internal design documentation.
• feature creep
  • There would be sacrifices and cuts, and the early feature creep that represented the fun and experimental beginnings of the project were long behind us.
• technical problems
  • I dropped the 1700 audio files into the solution -- and realized the game was taking upwards to a minute to boot.
• milestone
  • It became clear that in order to meet the impending milestone (that I could not miss), I would have to cut all the voiceover from the game. A year of casting, recording, editing, animating, coding. All gone.
• recoding
  • A few hours later (which was the norm at the time) I woke up, seemingly having reprogrammed the entire dialogue system in my dreams, as well as a new way to load all content, and was able to get everything working again.
• no marketing
  • By far my biggest regret with the game had nothing to do with actual production, but rather that I literally had no time to build awareness before the launch.
• test
  • Finally, while it was my intention to make a dialogue-heavy RPG, it's not something I'm rushing to do again right away. The time, cost, and insane amount of work that it takes to write, test, record, and localize such a thick script makes it a prohibitive endeavor.

11 Bit Studios Anomaly Warzone Earth

1. indie
   • That's why one day we decided to quit the jobs we had at the time and found a new studio to be -- from that point --completely independent. Awareness of the future difficulties or a lack thereof did not matter.

• gameplay driven game
  • The leading theme of the first game will be gameplay. We won't make a story-driven game, because it's not our strong point. Experience prompted us to make a gameplay-driven game.
• self creatin tools
  • In the past we used to work pretty efficiently on our own engines, so at the start we decided to create the base fundaments for a new proprietary engine chiefly adapted to our needs.
• multiplataform goal
• write once runs everywhere
• customization
  • Firstly, no engine supports all platforms. For us, it was extremely important to port the game to as many of them as possible to enable multiple revenue streams. Secondly, using a third-party engine provides you with certain tools and features but no more. If you need something really custom, you're screwed; the engine developer won't deliver custom features for a small indie startup.
• experienced team
• skilled team
• outsourcing team
  • From the outset, our team was very strong in the field of technology (frankly speaking, it was very strong in all areas). We had a lead programmer with deep knowledge of PC and Xbox 360, including both high-level engine design and down-to-the-metal optimization. We had one of the best Polish GPU programmers with PlayStation 3 experience as a contractor. We had an extremely experienced gameplay programmer. And all those people had worked together for a couple of years in the past. This was a real asset, and we decided to use it to our advantage.
• scope limited
• feature limited
• tools limited
  • We limited the feature and tool lists to the absolutely necessary -- locations created out of XSI prefabs, top-down view, game logic created in Lua scripts, single player only, with a light pre-pass renderer for the sake of simplicity.
• early prototyping
• paralel development
  • The key to quick and efficient development was to enable gameplay programmers to work on the actual game almost from the start. So Lua integration came online as soon as the engine was capable of displaying a simple wireframe mesh. This way, while the engine was being developed, the game prototyping went on.
• production plan
  • Knowing from the past that chasing milestones could leave us with heavy crunch time, which was something that no one wanted at all, we made a production plan with solid buffers after each milestone, just in case we would slip.
• experienced team
• no big research needed
  • However, these buffers were not the only factors that made the plan work. Firstly, we were experienced. If we decided to implement a multi-threaded resource system or local contrast post-processing shader, we didn't have to research the area. We just knew how to do it -- and the same about graphics and design. We knew exactly what assets are needed to make the game look good, and how to proceed with gameplay iterations.
• team already knowed
  • Secondly, the core team had worked together in the past -- some people for more than 10 years. We've already been through good and bad together. We were a real team.
• limited budget
• team focused
  • Fourthly, we were aware that we had no money for delays, or to create a second game. We had just one shot. The game had to be made on time, had to be good, and had to sell -- so we stayed fully focused. No business meetings, no publisher requests, no other options: just the game and the plan. Vertical slices for presentations to possible publishers eat a lot of your time. Think about what you really need, and what kind of development should consume your time in the end.
• scheduled iterations
  • Fifthly, our plan was a good one. We avoided feature creep, and we scheduled enough iterations. We had a full time pessimist onboard to question every detail of the plan until it was rock solid. If you are planning buffers, double them, and get the worst pessimist to look at the plan and then add more buffers to make that pessimist satisfied.
• outsoucing PR
  • It's obvious that in order to get press attention for an indie production, you need to have a good game on hand. But having the good game, you need to know how to create some buzz around it and present it to people. Word of mouth is one thing, but visibility in game press is the other -- and the second thing can surely enlarge the first one. To this end, we decided to work with Evolve PR, because we're friends with director Tom Ohle; we had a couple of beers together, and we know he's a decent guy and does his work well.
• small team
  • Thanks to our external PR agency we didn't have to handle communications by ourselves. At the time the team was pretty small, and it actually takes a lot of time to spread the word about the game.
• idea
• meeting idea
• discussion idea
• game scheme
• prototyping
  • At the very start, we had one goal -- to reverse tower defense. With such a goal, Michal (design director) and Przemek (art director) created a few initial ideas about how the game could look. Those ideas were then presented to the rest of the team and heavily discussed. The team's questions and doubts allowed us to find quickly the holes in design and kill those concepts that did not arouse any enthusiasm. Thanks to this, they were able to create the general game scheme in a fast and efficient way and then quickly go to prototyping.
• gameplay testing
  • We wanted to build a dynamic game in which arcade elements would be as important as tactical ones, so testing a playable version was key.
• inspiration
  • Becuase Anomaly is an inverted tower defense game, we played a lot of the genre -- both classics and twists on it. One major inspiration was surely the amazing Defense Grid. I need to note that we have played some simplified inverted TD games (mostly Flash games available via browsers), however none of them fully utilizes the idea of tower offense gameplay;
• innovation
• user feedback
  • Later, in reviews and user feedback, this emerged as one of the key values of the game; the feedback underlined the freshness of the game -- "unlike anything I've ever played before."
• polish iteration
• quality process
  • We focused on high quality visuals, and went through a lot of iteration. If you make a game, it's worth iterating extensively, because you not only notice bugs or shortcomings, but you'll also do something colloquially called "polishing."
• planning scope
  • The first step in assuring the quality was scoping the project correctly; for example, we didn't include multiplayer because we didn't feel confident we could do a good job with the time and resources available to us. We decided to do less, but make it better.
• search for fun with prototyping
  • Gameplay-wise, it takes a lot of prototyping and playtesting. When we started an "inverted tower defense" project, we created the first prototype. It was boring. So was the second. The third one did the trick.
• constantly improvements
  • So we iterated. A lot. And we constantly improved. Plus we paid a lot of attention to the details. Everyone strived to improve the quality of his area of the game.
• outsourcing job
  • In the early startup phase, our capabilities were limited. Luckily, we knew a few skilled programmers and graphic artists we'd worked with in the past. We outsourced different parts of the code and graphical assets to those people, which allowed the core team to focus on the big picture of the game.
• after release stats
  • Most of the players were interested only in the story campaign mode. Steam stats show that only about 15 percent of players launched additional modes (like our Squad Assault mode, which is something like a survival mode). It means that most players got what they wanted out of the main campaign and didn't want to jump back into the game quickly.
• IDE programming
• debug tools
• console log
  • We learnt everything from scratch on the back of our own mistakes. It began with a not-so-good toolset - we used Visual Studios and the VS_Android plugin. Unfortunately, we could not conjure up a debugger. Eventually we used the console log.

Dejobaan Games Aaaaa -- A Reckless Disregard for Gravity

1. brainstoming
   • With Aaaaa!, we started by tossing ideas back and forth until we had something that interested us as gamers and businesspeople.

• development process
  • Initially, Dan (as Gameplay Architect) would create a level skeleton, manually stamping buildings here and there. He'd then pass it to Tamlyn or Ryan (level designers) to push and pull individual pieces around until things worked better.
  • They'd give it back to Dan, who'd play through it, then add even more, piece by piece. Then over to Ichiro for yet another pass. This worked, but it took us about six hours to create a single, tiny level. Way too long!
• automation
  • So, we automated some well-understood processes -- game developers often do this to good effect. "Here's a tool to decimate a model. There's one to change the color of a skycube."
• tool creation
  • In our past games, we've often underestimated the value of building specialized tools, working instead to generate or repurpose everything by hand. With Aaaaa!, we made an effort to automate our efforts.
• random generated levels instead of manualy
  • Rather than placing everything manually, we asked for a random variation and screamed, "No good! Send it back!" and played Goldilocks until we had something we liked. From there, we could tweak by hand to make things really shine. Our level designers wielded simple, yet expressive tools that allowed them to experiment with level design without having to painstakingly try everything by hand.
• demo
  • "The demo turned me off, but I got the game on sale anyway. It turned out to be awesome!" We've heard this quote from gamers a number of times since launch, and eventually came to the conclusion that the trial version just wasn't doing its job.
• reuse
  • Halfway through development of the game's 81 levels, we decided to lock down the designers' toolset, forcing them to use many of the same tidbits over and over.
• new feature workflow
  • After all, every new mechanic we'd added to the game (graffiti, flipping people off) required a lengthy process that we remember as follows:
• experimentation
  • But when we asked ourselves how this fit into the overall game, we came up empty. So, we abandoned it. And the lesson we learned was this: don't experiment at this stage -- it's just a waste of time.
• test and feedback
  • We didn't test enough. And when we did bring testers in to toss the game around, we underused the feedback we received.
• bottleneck
  • However, to add a simple, rotating fan blade to his level, he had to go to Ichiro, who would import the model, orient it, resize it, apply a skin, add it to the catalog, and script the rotating motion. Or, he'd simply not do any of that.
• game document
• requirements changed
  • Stop us if you've heard this one: after the initial planning stages, we never substantially updated our design document. Towards the middle of development, the game looked significantly different from our original plans, so we threw the plans out and flew by the seat of our pants.
• pre-mortem
  • Much of the document you're reading could have been written before we even finished Aaaaa! -- but we never took the time to consider what we'd already been doing right and wrong.

Torus Games Scooby-Doo First Frights

1. requirement

• vision
  • Warner Bros.' directions to us were quite clear: make a cooperative game for kids that they can play with their parents; give a fresh, younger representation of the Mystery Inc. gang in their early years of the sleuthing; and implement a blend of light combat and puzzle gameplay.
• creativity freedon
  • But for the environments, storyline, enemies and the direction of the game, Torus were given quite a long rope in creative license. This was a fantastic opportunity that the team relished. We were given strong support by Warner Bros. to ensure the spirit of Scooby-Doo! was genuine in all art, design and corny one-liners created for the title.
• research
  • We studied games of similar genre and game play direction to ours quite closely and picked out the pieces that we felt worked well, and were the main appeal to our target audience, particularly co-operative play, simple button mashing combat, destructible world objects and light puzzle. This became the essence of the Scooby-Doo! First Frights design, and is a success in that it reached our young audience (and Scooby-Doo! fans) as intended.
• multidisciplinary team
  • We're very proud of the cinematic story moments in Scooby-Doo! First Frights. The quality of work by the animation teams, the writing, voice-talent and music, helped set the tone to deliver the spirit of Scooby-Doo! to the game.
• small team much job
  • We had a small internal animation team of only five people at its peak facing an enormous task -- to create 64 minutes of unique cinematic moments within a five month development window.
• outsourcing team
  • Needless to say, we brought in two contractor animators and enlisted the assistance of outside production company The People's Republic of Animation to get through the workload.
• tutoring
  • And this success could not have been achieved without Warner Bros. introducing veteran writer Ed Scharlach, who helped bring the Mystery Inc. team to our TV screens in its earlier years. Receiving Ed's guidance and words of Scooby-Doo! was an honor for the team and helped shape the final scenes we see in the game today.
• story and content driven development
  • Up until this game, Torus had produced mostly technically-driven rapid development games across most platforms. Scooby-Doo! First Frights was our first story and content-driven game, and this presented a new school of thought into the team.
• skill improved
  • This game was a giant leap for Torus, and now that we stand at the summit looking back, every single person on the team has grown two-fold both professionally and technically.
• cross functional pairing
  • One of the most positive moves made during development was the pairing of level designers to artists. They would sit together, eat together, live and breathe their level -- and it shows. Beautiful panoramas and vistas are scattered throughout Scooby-Doo! First Frights, all at 60 Hz -- quite a feat considering the small level art team and short schedule.
• tools created
  • Continuing the theme of a new era for Torus, Scooby-Doo! First Frights provided the outlet for the Torus tech team to implement long-awaited tools. The result of decades of experience, these tools laid the groundwork for the game, and included the implementation of two new systems: "Clank", our physics system, and "Squeak", our new sound engine.
• pre-production
  • Measure twice, cut once, as the saying goes. The pre-production period for a project cannot be underestimated in any way. It's not just a time for drawing a few pictures and scribbling out a design; it's the moment when the foundations and blueprint of the game for the entire development needs to be laid out -- and in detail.
• production phase
• estimation
• scope
  • Once we headed into production, and in reflection of the vertical slice build, we identified that the design was over-scoped; some cuts were made, but only so much could be done by that point. We'd made a promise to deliver the game as originally planned, but this is one area where our inexperience in developing a game of this genre showed as we progressed through development -- we underestimated the workload necessary to produce a game of this scope and content.
• demo
  • Today, pre-production is still considered as the most vital stage of a project's development; however, a vertical slice (or demo build) should never impede on this time, nor affect the required workload.
• technical restrictions
  • The reason why the levels are linear in Scooby-Doo! First Frights is due to our tech at that time not allowing backtracking between regions, hence forcing us into a single direct path through each level.
• limited time and resouces
  • These holes weren't unnoticed by the team. We didn't suddenly reach the end of development and go "Oh, hang on, that doesn't make sense!" We were quite aware, but with limited time and resources, could only fill in the gaps so much.
• aditional hands
  • Introducing additional programmers into the fold to assist the team led to too many people working on one portion of the code, and with the restrictions of time, they had no opportunity to understand the "big picture" before making changes; their micro changes would inherently break another part of code.
• pre code design
  • With this in mind, there is great value in pre-code design. Paper designing the structure of the code before writing one single line, and ensuring that it works in harmony with all other systems in the most efficient way possible, has become a new paradigm to the way we approach coding our games today.
• share ideas with others teams
• minimize risk
• documentation
  • It forces one to think before they code; to share their ideas with the relevant teams before implementing to minimize risk, and to ensure that no stone has been left unturned, or game mechanic unconsidered. The documentation also serves as reference to anyone new to the code and encourages more effective communication and understanding.
• target audience
  • Warner Bros. and Torus held individual focus groups with our target age group to gauge levels of difficulty in the game, and to pinpoint problematic areas, and for most part in the end we got this right.

Treyarchs 2002 hit Spider-Man

1. new team (13)

• proof of concept and design
  • We formed a new team out of parts of the others to begin work on the proof-of-concept and design. This team of four programmers, four designers, four artists, and a producer wasn't starting totally from scratch; we had Activision's previous Spider-Man game for the Playstation (PSX) to look at.
• target plataform
  • The PS2 was our lead SKU, because it has the largest installed base and was the easiest to get development kits for. We figured if we could make our game run on the PS2, we could make it run on anything. We began work on the Xbox a few months after the PS2 and the Gamecube a few months after that.
• people over process
  • "All you need is good people," says the submarine commander in Das Boot, after the chief engineer repairs the boat and saves their lives. It's true, with good people you don't need to enforce process because it happens automatically. Everyone makes sure they do a good job: they volunteer for code reviews, they write their own unit tests, they find better ways to do things instead of the ways passed down from on high.
• hiring process
  • Because I'm not in HR, I don't know how we got these people, but I think part of the reason is that the people in charge of interviewing know their stuff, whether it's art or code.
• middleware
  • Treyarch was developing a few titles for the next-generation platforms, and it was obvious that having one crossplatform library to do the rendering, which all the teams shared, would be a big advantage. We formed a new team, Next-Generation Libraries (NGL for short).
• engine reuse instead write from scratch
  • The first decision we had to make was what engine to use. (Writing one completely from scratch was out of the question for an 18-month project, a lesson we learned the hard way with Draconus.) We had access to the previous Spider-Man PSX engine through Activision, but our designers and programmers were used to the engine we used for Max Steel and Draconus, an engine that was already next-generation and cross-platform. Our engine had a powerful scripting language, but it also had slow turnaround times and was never intended for a Spider-Man game.
• dev process
  • At its heart, our methodology was "code and fix." However, there were many semiformal processes that prevented our software cowboyism from totally spiraling out of control.
  • The artists and designers were scheduled in Microsoft Project. For the coders we started with an XP-like system of file cards representing weeks, posted up to a large corkboard. But the schedule changed so frequently that this method stopped being good enough, and we switched to Joel Spolsky's method from www.joelonsoftware.com. This worked pretty well; I would go through the schedule every morning to make sure everyone was keeping their schedules up to date. Also, once we switched to this system our estimates tended to be more accurate, which was a nice side bonus.
• bug tracker
• bug feedback
• bug database
• bug priorization
  • Using Microsoft Access, we started logging bugs right away. People would log bugs by sending an e-mail to the producer, who would first log the bug into the database and then later print out paper lists for people.
• daily build
• daily tests
  • On average we broke two levels a day, usually due to simple things like not checking in a new file. To protect ourselves from these errors, we did daily build and smoke tests on the PC and the PS2. We did the daily build on a machine that would do a complete update of the data and source depositories, rebuild and recompile the various intermediate files into their final output, and run an automated test of every level, just to see if they ran.
• storyboard first
• level implementation meeting
• level alpha
  • On the art and design side of things, we would storyboard a movie or create concept art for a level before we began animating or modeling it. A professional writer wrote the script with all the voiceovers. Before we designed a level, we would have a level implementation meeting, where the participants in creating that level would discuss what the level was going to be before it was modeled and scripted. Because of this process, several of our levels were very close to good-enough-to-ship on the first iteration, although several other levels had to be revisited several times before we signed off on them. We had a concept of "level alpha," which meant the level was basically ready to go in the box except for cutscenes (scripted or animated) and voice-over, and game designers didn't work on the next level until they had their previous one at "level alpha."
• internal test departament
• external qa
  • Finally, we had a small internal testing department. It's fairly standard in the game industry to wait for a game to reach so-called "alpha" (a completely nebulous term) and then put it into QA. Then QA tests the game out of sight of the developers and submits bug reports. Although we did do the standard external QA with Activision, before the game was at alpha we had internal testing. At first this was just one person, but as we got closer to finishing, the number grew. And once the game hit alpha, Activision sent some of their best and brightest testers over to Treyarch (which was easy, since our offices are one block from theirs) to test the game on-site, so they could demonstrate bugs in person, work with the very latest revisions, do testing on development kits, and ask us when they discovered bugs whether or not the bugs were important.
• communication
• designers closed to programmers
• team localization
  • The layout of our office was geared to encourage communication between the people who needed to communicate. The leads' offices were fairly central in an L-shaped office suite. The game designers were close to the programmers who supported them, which was key in getting things to happen and encouraged additional lunchtime communication. The programmers who dealt with specific platforms were farther away. NGL was on a different floor, but their lead was in a nearby office, and NGL representatives would share offices with us when it was useful for them to do so.
• design documents
• intranet web site
• internal FAQ
  • All of our design documents were made available on an intranet web site, along with short documents on how to use the tools and a small FAQ that had some common troubleshooting answers.
• lead-driven management
  • Finally, we had a lot of management. Greg John oversaw the entire project. There was a producer watching deliverables. There was a creative director. There was a level-modeling lead. There was an animation lead. There was a game design lead. There was a lead programmer. The engineering group — the programmers who wrote the platform-independent, gameplay-related code — had their own lead. Each console had a lead go-to guy who understood that console best. NGL had a lead programmer and a producer. In all we had about one lead for every five people, and all the leads met once a week.
• staff planning
  • Some of our other problems can be traced back to staff size. When the project started, we had about four programmers, four game designers, three modelers, one texture artist, one producer, and one creative director. NGL was only in our imaginations at this point. Treyarch was eagerly looking for more staff, but staff doesn't just come out of thin air. Most important, we didn't have a concept artist, we didn't have a writer, and we had so many people working on the proof-of-concept that we didn't really have someone to come up with a full design.
• game design document
  • By the time we finished our proof-of-concept, the design consisted basically of a list of bosses, a list of levels, and some ideas on how our new AI system might work. Each item had about a paragraph devoted to describing it. Our story was a page long. By the end of the project, we had a wealth of design: we had the output of each level implementation meeting; we had the script; we had a couple of pages on each boss, describing the moves he would be capable of; we had concept art and storyboards; we had concept art for the front end. If we had come up with that material earlier in the project, we would have been rudderless for less time and could have made more game before shipping.
• cutscenes after final voice-over
  • It was already alpha, and we had very few of the cutscenes done, because it's a waste of resources to do the cutscenes until you have final voice-over.
• DSL instead pure language
  • Because CHUCK is such a powerful script language, however, game designers would often take on tasks that could have been handled in code better. CHUCK doesn't really have arrays, and it doesn't have a debugger, so for anything complicated, C++ is the way to go. Unfortunately, it wasn't always the way we went.
• internal and external bugs
• multiplataform development
  • Nothing prepared us for how many bugs we'd find in this project. The total came in at around 16,000, about half of which were internal and half of which were external. This was more than twice as large as the largest bug count we'd ever seen on a project at Treyarch before, partly because we were on three platforms and therefore had more bugs.

Pipeworks Softwares Deadliest Warrior

1. brainstorming
   • In the very early phases of the project I would brainstorm with my producer, Carlos Giffoni, to determine what would make this game different. What about this game would really appeal to the Deadliest Warrior show fans, hardcore game fans and casual game fans? And how could we create a great gaming experience while also staying true to the main premise of the show?

• inspiration
  • One of the brainstorm sessions lead to discussions of Bushido Blade and the strategic combat system Square's PlayStation 1 classic used. No fancy combos, no ridiculous powers and health systems -- just timing, spacing and strategy. It really resonated with what we were trying to achieve on Deadliest Warrior.
• core design refinements
  • Not only did this style of gameplay jive with the IP, it was also something that we, as gamers, wanted to play on our own time. We immediately started solidifying core gameplay mechanics while eliminating those elements of the original design that no longer supported the direction that we were moving in.
• external help
  • PV: The Deadliest Warrior team was very involved in the development process, which kept us honest from a historical accuracy perspective but also was invaluable in keeping the game in line with the TV series. Data collected in the show was used in development, and some of the weapons experts featured in the show even did some of the mocap for the game.
• hiring process
  • PV: A funny anecdote related to this is when we were initially seeking developers to work with, it came down to Pipeworks and one other studio. That studio came into the pitch with a fully working demo, and Pipeworks had a rendered game trailer. Being a producer, I was immediately impressed with the demo and felt that it created a good base for iterative development.
• two QAs
  • I am putting this in bold, as I think this is the second best decision we made as the publisher (choosing Pipeworks as our development partner being the first). We used two QA teams. Pipeworks is a part of Foundation 9 Entertainment, which has its QA group, F9QA. It made sense to partner with them as they already had an internal pipeline established to hand over builds and communicate on-the-fly about bugs.
  • We also partnered with VMC to QA the already QA'd builds. Using a staggered build delivery schedule, we were able to get F9QA to go through all the functional and compliance issues, have Pipeworks make the fixes, and then send the game to VMC for a final compliance check.
• build reviews
  • As a team, build reviews helped us to see what was going on in the game at that particular moment. It was a snapshot, if you will, especially for those on the project who had their heads down grinding away at their tasks.
• motion capture data
  • Even though the decision to go with motion capture was the correct decision to make and the end result was what we wanted, our initial methods of selecting and processing the mo-cap data caused us quite a bit of extra work. We were definitely unaware of the complexities and time required for selecting hundreds of motion capture moves based off of videos of said moves (each move having multiple takes).
• gameplay focused development
  • Our original plan to have all of our in-game text ready for localization was foiled for a number of different reasons. The main reason was our focus on tweaking and refining the actual gameplay fighting mechanics, and not concentrating on what would make the UI better.
• balance test
• full time testers
  • The hardest and most vital part to get right in a fighting game is character balance. We played over 100,000 battle simulations, had a full-time team of dedicated testers, and bought in new players for game testing sessions throughout the project, in order to get the intricacies of each character right.
• feedback from community
  • One of the great things about the gaming community is that the dedicated fans are very vocal. We were able to get a lot of great feedback from the players on the forums, Xbox Live, and Spike.com. Using this feedback and running some ideas past the players, we were able to create a Title Update that addressed all the balance issues. If we were not listening to the community, it would not have been possible to get this done as quickly as we did, so a big thank you must go out to all the fans that played this game for hours on end and gave us excellent feedback.

Crocodile Entertainments Zack Zero

1. initial idea
   • The idea was to make a platform game with 3D graphics but a 2D game structure. Something simple that would take a couple of years to develop for PC and thus have an initial team, structure, engines, tools, procedures, and an introduction for developing our second game for consoles, a world that was foreign and unknown to us.

• tool creation
  • But at the time we started the company, there were no cheap and accessible game engines for small studios, so we started designing our own. Nonetheless, building our own technology did give us the chance to access a grant.
• prototyping
• tool for designers
  • Crocodile Entertainment's first year was practically dedicated to building all the tools and technology needed for the project. While we were looking into game prototypes, we were also creating the necessary tools to make the art and design tasks easier and independent from programmers.
• tools refinements
  • The first preliminary versions of the engine exported too much information from the 3D software, but slowly we were able to improve our tools making almost everything editable in real time: moving and scaling objects in game levels, delaying and establishing offset parameters for animated objects, particle systems, shaders and materials, etc. Also, all enemy mapping and enemy generators could be placed in-game, controlling the enemy flow, and with the help of Lua scripting, a complete level could be set in real time.
• no offices
  • Not having offices has always been a problem while developing the game, although it did make us improve our pipeline, looking constantly for better ways to manage communication and task organization.
• small team
• outsourcing assets
• no producer
• precise requirements
• distribuited teams
• monthly meetings
  • The biggest communication and organization challenge was amongst the art team. During the main production year, the team had two concept artists, one animator and two 3D artists, while some assets were outsourced. Without a dedicated producer and with no offices to resolve any doubts that could arise, it made us work harder in the description and design of the graphic assets we had to create, since we tried to meet only once a month. Since some team members lived far away, we didn't want to waste precious time traveling and attending too many meetings; that's why we defined each month's tasks in detail in each meeting.
• concept art requirements
  • This was possible largely due to the work of the concept artists, since they had to help us visualize all the environments, characters, props, etc. For every game asset, however small it could be, we had to work with concept artists to find the appeal we wanted.
• daily supervision
  • This was more difficult with animation tasks, especially with character animations that have direct impact on gameplay. In these cases trial and error play a major role, as do good communications between the programmer and the animator -- something Alberto had to personally supervise every day.
• task management
  • When we started the project, the software we used for task management was MS Project, using email to communicate tasks to the people scattered in different places. That did not work. Communication is crucial.
  • Later, we made a macro of the list of tasks, organized by user and priority, to upload to the wiki, with colors and comments to improve visibility. Wrong. We got neither feedback nor comments. We did have regular staff meetings with the task lists and work layout, but on a day-to-day basis it was impossible because of the overlap.
  • Later, we began using Google Docs. Things improved communication-wise, but soon visibility was lost and the document became impossible to read, despite being organized into different sections.
  • We then turned to Basecamp, but eventually switched to Teamwork (we changed because Basecamp worked terribly on iPad, and at the end of the day it is good to review the check list, make comments, prioritize and do all those things sitting comfortably in a chair). It really is much more productive, more participatory and does not require a dedicated producer.
• scope change
  • But in March 2009, when we went to the Game Developer Conference (GDC) in San Francisco, we took part in a talk which encouraged developers to develop for the PlayStation 3. And considering how PC sales had deteriorated in the two previous years, we decided to drop our original plan and try to go directly to PS3.
• no offices
• brainstorming
  • So we met with the team and held a brainstorming session in a restaurant, while having some beers and eating pizza. As we have said before, we have no offices, so we had to improvise our meeting room.
• plataform transition
  • Considering the PS3's reputation, since everyone says that it's a machine that's difficult to program for, after receiving the development kits the transition was faster than expected: we got the game running on PlayStation 3 in little more than two months and enjoyed the platform's architecture a lot.
• feature creep
• lack of requirements specification
  • Furthermore, all the gameplay adjustments lead us to the dreaded feature creep. Our fear to stop all development made us fail to define all of the game's features in detail. Even though the game's new design was clearly defined, there were many loose ends that made us constantly add small features to the game.
• in-house testing
  • There were many sleepless nights, long hours working, fixing and adjusting the game, the different stages, playing for hours to prove to ourselves everything was working while we fine-tuned it, all in the midst of a daunting economic situation.
  • We asked for help from family while the banks relentlessly hounded us. It was a very tough situation that we hope we do not have to go through again. Finally, in December 2011, we passed quality assurance.
• no PR
  • In the end, after watching a video about indie studio marketing, we were convinced that the best strategy was to wait until people could actually buy the game, so that players could impulse buy after reading an article in a magazine or on the internet (we have a feeling that our exhaustion, caused by the stressful closing of the game, had something to do with this decision).

Sony Santa Monicas God of War Ascension

1. extensive playtesting

• brutal feedback
• constant iteration
  • The decision to add multiplayer to the traditionally single-player God of War was controversial from the start, both with fans and team members. This departure from our core expertise forced us to reconsider how we made games, and in some ways, it enabled us to return to the principles that helped create the original God of War: extensive playtesting, brutal feedback, constant iteration.
• motivated team
  • People on the team have never been more passionate about proving something, and after our MP Beta, we had converted legions of fans who had either been on the fence or outright opposed to it into our strongest advocates.
• big scope big team
• online outsourcing hiring
  • For Ascension, however, the scope of the game and the complexity of the entire project required that we grow the team dramatically. We acknowledged early on that we required a variety of new skills (multiplayer engineering and design, for example), and leadership expertise in order to successfully deliver the project we had defined. Through an aggressive hiring push, working in conjunction with on-site talent acquisition staff who helped execute our rigorous interview process, we were able to find key contributors in all disciplines and at all levels of seniority.
• continuous improvement
  • By building on the strengths of the prior games and leveraging the team's knowledge of how to create these sequences, we were able to focus on continually pushing the quality bar.
• close PR
  • For this project, we had outstanding relationships with marketing and PR that started early and stayed consistent through the entire project.
• beta testing
• validation
  • Multiplayer beta testing provided a chance to validate that the system and game design for the MP game would hold up to the scrutiny of a dedicated fanbase, and to the volume of players we'd see once the game launched.
• team quickly iteration on fixes
• deploy infraestructure (testing, certification, patching)
• log monitoring
• live testing environment
• priorization of key features
  • We had designed the team's workflow to enable them to quickly iterate on fixes, deploy them through infrastructure (testing, certification, patching), and coordinate with internal technology partners within Sony. We also developed the right systems to monitor, log, and interpret any changes we implemented. Also, the live testing environment gave us insight into how we should prioritize for key features, and drove our development tasking as we closed in on release.
• focus development
  • We determined that each level needed key design and art leads to gather the massive volume of fixes completed in a day and make sure the levels stayed functional as we were putting the finishing touches in.
• shot pre-production
  • Between "all hands on deck" to finish the previous game, and experiments with new directions we didn't take, pre-production for Ascensionwas not in the place where Todd Papy (game director) and senior leadership wanted it to be when we began. This proved to be very difficult to recover from, and it did have a detrimental impact on the entirety of the project.
• technical debts
  • While many of the systems that were improved for God of War: Ascension built upon successful systems from prior games, some features, not least of which was multiplayer, required substantial rewrites that took longer than expected, and we couldn't deliver those mechanics until well after key deadlines.
• undefined requirements
  • What we didn't know was how much work it would take to make the game we envisioned, and how many people would be required to successfully realize that vision. On top of that, we all didn't agree on what the game should be.
• prototyping
  • So we ventured on and did a lot of prototyping.
• shared leadership
  • While we had the majority of the team fully dedicated to either multiplayer or single-player, some key leaders, including Todd and Chacko, were split between single-player and multiplayer.
• gameplay over history
  • As we closed in on finishing the game, we decided to retain our primary focus on the game's biggest moments --those "epic" moments and setpieces. Unfortunately, this came at the cost of narrowing our story-telling vision.

Lumines Electronic Symphony The Untold Story

1. external hiring
   • Unfortunately, Child of Eden experienced some challenges during development that required the team to continue working on that project, so it was a few months before we finally decided to bring in not only an external programming team (the excellent Rocket Studios, based in Sapporo -- filled with ex-Hudson veterans, including the original designer of Bomberman), but an external game director as well.

• difficulted communication
  • Without consulting the project manager or me, he would make arbitrary decisions like removing some classic elements of the HUD, or other time-proven contributions to the Lumines formula. He would fight over things that weren't important, and then disappear from discussions about things that mattered.
• working process
  • Not only did we get the game done on time with our new director, Ubisoft veteran Ding Dong, on board, we created a much more efficient way of working, streamlining the process so we could finish skins faster and with greater, immediate results. If we had to change a color or a texture, we could do it quickly and see the results immediately.
• tools for the artists
  • Our new director had the tech team create a template, with a foreground (blocks), a midground (particle effects, like the "COMBO!" counters that appear), and a background (animated movies or 3D effects) where various effects like shaders, opacity, lighting, and other visual details could be tweaked by the artists, instantly.
• fast feedback
  • This made the art flow happen a lot quicker, since not only could we see what was being made, but if we had any feedback -- and we had lots of feedback -- we could see the adjustments as soon as the artists had implemented them, instead of putting in the order to the programmers, and having to wait two or three days to see the results.
• plan b
  • This is personally where the biggest pressure on me lay. Not only did I need to pick 33 or 34 songs that would work well together, and yet skip across the entire spectrum of electronic music, but I also had to have back-ups for each song (minimum five) in case our first choice didn't come through.
• fans' feedback
  • Based on the feedback we received upon announcing the game soundtrack, it seems like the effort was definitely worth it. It's really satisfying to hear feedback from fans who say they like this song or that song best, or were surprised that we included X song or Y song. The best feedback is when I would see a review saying that they don't even like a certain artist, but that in the context of Electronic Symphony it works really well. That's a great feeling.
• post release plan
  • However, that doesn't mean that fan feedback fell on deaf ears. We had lots of DLC plans in store for Electronic Symphony, ranging from a 12-month rollout of new skins, to a six-month episodic release of new skins, modes, and music. The first skin that we had planned as a DLC was a high-definition, all-3D remake of the original "Shinin'" skin, which we figured would please fans craving a digital release of the original game.

DrinkBox Studios Guacamelee

1. requirements
   • A clear vision for the gameplay and overall game design that was well-defined before we entered full production

• pitch
  • Guacamelee! was born out of team pitch sessions that started taking place in the fall of 2010. We spent a lot of time talking about the kind of project we thought would work well for the team and discussed the high-level mistakes we felt we'd made with our first game.
• single page pitches
  • Once we developed a sense of the kind of game we wanted to create, we asked everyone to put together single-page pitches for each of their own ideas.
• concept video
  • This concept video was one of the most useful things we did for the project. It helped us quickly visualize the world and let us develop a concept for the combat system.
• combat demo
  • Our next demo added in a free form, dimension-swapping mechanic, simplified the basic combat moves, and was built as a vertical slice. By this point, all the key mechanics of the game had been developed and proven to work.
• prototyping
  • Although questions remained, the game was well defined. This was accomplished using a small group and rapid prototyping, with the freedom for people to try different things. We considered this a major accomplishment in the context of our previous title and it gave us the confidence to move into the full production of the game.
• target audience
  • In contrast, when we started Guacamelee! we made a conscious decision to try and make the visuals more appealing to hardcore players.
• dev by tech and refinement by art
  • While this success was naturally a result of the talents of the art team, it also depended on a cooperative back-and-forth between the art, tech, and production departments. In particular, over the course of Guacamelee! we changed how effects were developed, counter-intuitively putting the development more into the hands of the tech team and then letting the art team direct refinement.
• internal milestones
  • publisher meetings, public showings, festivals and competitions. On this project, we set milestones for ourselves based on showing the game to external people, specifically targeting
• public deadline
  • During Guacamelee!'s development, each public deadline was spaced several months apart, giving the team enough time to make noticeable progress, but still enforcing a constant pressure.
• external playtests
  • We were able to repeatedly observe the strengths and weakness of team members at going from prototype to polished product, we were able to collect external playtests on what was working and not working in the game, and we were able to adjust our approach to production repeatedly after each milestone.
• funding
  • Guacamelee! was part of the Sony Pub Fund initiative. The Pub Fund works as follows: in exchange for a period of exclusivity Sony pays an agreed-upon amount to the developer after the game ships -- typically something approaching the budget of the project.
• exclusive X non-exclusive
  • As mentioned, this came at the price of some exclusivity. To weigh the options we created a spreadsheet to work out the financial break-even point of an exclusive versus non-exclusive arrangement.
• PR
  • Near the end of our second game, Tales From Space: Mutant Blobs Attack , we started working with a PR firm. We felt this was a good fit for us. Some teams do all their own media outreach, but this appears to rely on certain personality traits we weren't sure we possessed. In addition, we felt there was a lot we could learn from observing a PR firm in action.
• work relationships
  • During the development of Guacamelee! we had particular difficulty managing some of the personalities on the team, and at different points on the project we had to dismiss two individuals. These dismissals were not related to work performance, but instead were precipitated by a breakdown in working relationships.
• authority structure
  • Some new members of the team struggled to find their place alongside peers when working without a clear authority structure. Lacking the confidence to navigate disagreements constructively, in frustration these team members sometimes ignored decisions or emotionally disengaged from certain tasks. As a result, we've begun to put a clearer authority structure in place for the team, and we've become more aware of the need to monitor personalities and provide ways for people to make their concerns known.
• company policy and behavior
  • In other cases we failed to set clear boundaries on inappropriate behavior. For example, it came as a surprise to discover individuals working on personal projects that seemed to be affecting their work performance and that were, in our view, in conflict with their employment obligations. As a result, we've become more explicit and proactive about enforcing company policy and behavior.
• QA
  • We had already shipped two games with a small 1-2 person QA team without any major problems. We had put out numerous demos for Guacamelee! using the same QA process. The approach had worked in the past, so we weren't concerned about it working in the future.
• testing scope
  • The arena bug was subtle, although the results were not, and was not easy to reproduce. We were dimly aware that the bug existed, but its frequency was unclear. Because of the difficulty in reproducing it, the scope of testing the rest of the game and the small size of the QA team, the bug was not properly identified.
• difficulty spikes
  • While there are a number of criticisms regarding Guacamelee!'s gameplay, one that is especially frustrating for us is the complaint some people had about difficulty spikes. Parts of the game are challenging and that's intentional, but the difficulty spikes suggest we were not thinking critically enough about ensuring players were prepared for key challenges.
• two paralel projects
  • During the development of Guacamelee! we released our second game, Tales From Space: Mutant Blobs Attack for the PlayStation Vita. The title was originally planned as a 1.5 version of About a Blob aimed at the Vita's launch, but over time became a follow-up game -- although not officially a sequel. For the first time we had multiple internal projects running simultaneously, and we encountered challenges balancing and planning the two projects with a small team.