It's thanks to elements such as fog that CoO gained its level of polish, according to Phail-Liff. He said that an extra ten percent of effort can yield another forty percent of polish to the final product. The fog took three days out of the team's tight schedule to implement, but thanks to its use in other elements of the game, such as cut-scenes, it made the rest of the process move more efficiently. He was also careful to point out, however, that too much polish can undermine the process, as mistakes can be even more costly and produce diminishing returns for developers.
In creating new visual elements, Phail-Liff said, they should be prioritized according to important conditions such as dependencies from other team members (if it slows down the other programmers and artists early on, it's not worth it), whether it adds to the story or to gameplay, reusability (the blood technology didn't add to the narrative, but it could be reused and made combat more visceral), and the potential for bugs, among other things. Ultimately, the goal is an added visual element that sells the narrative and adds visual quality but doesn't create bugs or slow things down, Phail-Liff recommends that artists wait until the end of the process to implement it. In CoO's case, some of the game's beautiful vistas weren't implemented until much later on in the production process.
Mistakes are Okay! (Kinda)
As Phail-Liff pointed out at the beginning of the session, Chains of Olympus was a project that was rife with mistakes. In spite of the assumptions of many, Ready At Dawn didn't graft Daxter's engine onto the God of War franchise at all. The difference between Ready and other developers lies in how it tackled those issues head-on and devised quick solutions which turned things around. One of the biggest problems that the team initially had involved the conversion of the team's tech from Daxter to CoO, specifically for lighting. Daxter's engine utilized real-time lighting. In CoO's case, the pipeline changes in the development process would've taken far too long. Instead, the team switched to pre-rendered light sources, which required different geometry and textures to produce.
Along the way, the team devised ways to alter scheduling to hit a satisfactory level of quality while keeping things on track. Phail-Liff was quick to point out that the "we'll fix it later" attitude is a great way to ship bad games, and Ready At Dawn's scheduling changes didn't reflect a "it's done when it's done" outlook, either. Ultimately, he said, the time taken away to reiterate some design element has to be utilized for something that will save time near the end of the production cycle. He showed off a chart that showed how a linear schedule would put all of the team on one element at a time, then split up tasks near the end of the process. In Ready At Dawn's non-linear approach, tasks are split up each step of the way, which speeds things up. In the end, it dramatically sped up the production of content throughout the development process.
