Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: 8Monkey's Darkest of Days
View All     RSS
October 23, 2020
arrowPress Releases
October 23, 2020
Games Press
View All     RSS







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


 

Postmortem: 8Monkey's Darkest of Days


November 26, 2009 Article Start Previous Page 4 of 4
 

4. Artificial whuh?

"Why can't computers be as smart as robots?"

- Mark Doeden, Director

The battlefield AI slowly morphed into one of the biggest design challenges in the game. The required complexity was initially underestimated, and it became more and more apparent as the project went on that a major change to our AI approach was needed.

8monkey underwent three full rewrites of the AI for Darkest of Days, each lead by a different engineer. The third and final revision built on lessons learned by the previous two and was definitely the strongest, but still had some shortcomings.

One of the main design requirements was performance -- previous versions had not performed well with more than about ten or 20 characters, and the game design called for hundreds. So the first priority was to get the thing up to speed. This included the removal of some AI middleware which was not performing well, and as a result many of the low level algorithms, such as vision and pathfinding, had to be rewritten.

The new implementations had the advantage that they were more efficient and tunable, but even so, the balance between intelligent characters and numerous characters proved difficult to strike. The results on large battlefields were good -- every character thought for themselves and the battle really took shape well.

But once the player stopped and payed close attention to a smaller number of NPCs, the illusion tended to break down. Tuning the performance to be ideal for large groups sometimes resulted in individual NPCs who seemed unobservant or reckless. This constant balance war between AI quantity and quality continued through the remainder of the project.

Complicating the matter was the variety of behavior required from characters in the game. There were characters from five different time periods, civilian and military, human and animal, and on top of all that three types of future agents. Again, a lot of effort was spent on variety here, trading that working time for some quality.

Ultimately the AI system accomplished some of its major goals -- namely performance and the behavior in large scale battles. But it never quite reached the level of intelligence we all wanted from it in small encounters. Had we been able to find a solution to this problem as well, the game would have had a more consistent quality.

5. Divergent Design

"We can't all just go around stickin' our fingers in each other's... pies."

- Jack Monahan, Level Designer

While the concept and plot of the game were well laid out, the specifics of the game design were not always as clear. As a result, team members were sometimes unsure how to proceed with balancing and game tweaks. Often individuals would improvise a solution on their own, without conferring with the group, only to be met with disapproval from design leads or other team members once their work was added to the game. This bred frustration, duplicated work, and wasted effort.

This is also the flipside of the ownership coin. Many team members felt so strongly about their individual contributions that it began to create friction every time a change needed to be made. We all had to be working toward one goal, and keeping everyone's efforts on the same track proved difficult from time to time.

The road to completion was long, and there were some periods where the game did not look or play well. It can be frustrating to keep working on something that doesn't look good yet, and to resist the urge to do a 180 and totally change everything. Ultimately we were able to keep the working focus on nailing the basics of the game, but there was a lot of time and mind-share spent on ideas and proposals to "fix" it, when really what was needed was polish on the core mechanics.

Another source of design uncertainty was a general lack of outside gameplay testing. Most external testing was an effort to find bugs rather than test a design, and was therefore not centered around the central "is this fun" question that every game developer needs answered. Level design, AI, and weapon balance all could have used a lot more design testing than they received. There was a good deal of internal testing by team members, but this often did little to settle design disputes or inform the team.

Toward the end of the project, design problems smoothed out somewhat. Design iterations happened more regularly and with more discussion, and more outside play testing was sought. Everyone "fell into the groove", and as is often the case with many game projects, our team did some of its best work toward the end.

Conclusion

"My watch reads beer-thirty... how 'bout we hop on the next portal ride out of here and get a cold one?"

- Agent Dexter, Darkest of Days

Did the project have its problems? You bet. We had a small team, a small budget (this ain't no 20 million dollar game), and we made some beginner mistakes. We were starting up a new company, and bringing a new IP to life along with new technology. We were told on several occasions that the task sounded impossible. Expecting anything other than a rocky road would have been ridiculous.

But for all this, the game is unique and certainly breaks the mold in lot of ways. 8monkey set out to make something that stood apart from cookie-cutter shooters, something new and different. Here we have succeeded.

Public reactions have been mixed -- some love the unique feel to Darkest of Days, and others don't see past its faults. It is different from a lot of shooters, in both good and bad ways. The game now has a small cult following of players, loyal folks who love this difference from the mainstream.

It might have been a fun experiment to leave Darkest of Days in the oven for another year. This was not possible of course due to budget constraints, but the results would have been interesting. As the project progressed, everyone's work just seemed to get better and better, and toward the end we were really hitting our stride. As 8monkey plans for the future, it's going to be fun to see where we go from here with our new technology and experience.

Darkest of Days was ultimately a blast to make. It's really too bad you weren't there. There were free t-shirts and everything.

Data Box

Full Time Developers: 4-10

Part Time Contractors: 14

Budget: $1.7M

Development Time: 1 year prototype and engine development, 2.5 years production

Release Date: September 8, 2009

Platforms: Windows PC, Xbox 360

Typical Machine: 2.6Ghz Intel Core 2 Duo, 2GB RAM, GeForce 8800

Software Used: Visual Studio, Modo, Mudbox, Maya, xNormal

Notable Technologies: Marmoset Engine, OpenGL, PhysX, SpeedTree, OpenAL

Size: ~200,000 lines of code, 80GB of source content


Article Start Previous Page 4 of 4

Related Jobs

Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States
[10.22.20]

Senior Camera Programmer
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States
[10.22.20]

Programmer
Disbelief
Disbelief — Cambridge, Massachusetts, United States
[10.22.20]

Junior Programmer, Cambridge, MA
innogames
innogames — Hamburg, Germany
[10.20.20]

Mobile Software Developer (C++) - Video Game: Forge of Empires





Loading Comments

loader image