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
arrowPress Releases
August 2, 2021
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 3 of 4 Next

What Went Wrong

"I think we opened Pandora's box! And inside's a dozen hornets' nests tucked under the nutsack of a rabid rhinoceros! This ain't good, my friend."

- Agent Dexter, Darkest of Days

1. Xbox 360 Port

Eventually the decision was made to bring Darkest of Days to the Xbox 360, instead of just the PC. Resources at 8monkey were tight already, so a third party contractor was brought in to work with 8monkey's engineers to port the Marmoset engine and the game code to the Xbox 360.

The contractor's employees were capable and hardworking, communication between the two companies was smooth, and the port was ultimately successful -- we shipped on the 360 and even passed Microsoft certification on the first try. So what went wrong?

First, the decision to port the game to the Xbox was made about a year into full production. By this point the engine had seen nearly two years of PC-centric development: the technical design had not called for console support at the outset. So while the decision to make a console version of the game made sound business sense, it necessitated a major overhaul of the technology base.

Fortunately, we were able to keep most of our middleware across platforms -- SpeedTree, PhysX, and OpenAL all had Xbox 360 implementations that did the job. The major efforts in the port focused around the graphics code, resource loading and management, and memory use.

The rendering code had to be almost completely rewritten, creating a second Direct3D renderer in addition to the OpenGL-based PC version. Load times had to be brought under control with a new threaded archive-based loading system (with the nice side effect that PC load times are now amazingly fast). And the entire codebase had to be gone over in detail to look for memory savings and deal with fragmentation.

Obviously, timelines suffered as a result. The amount of work involved in the port was initially underestimated, causing schedule slips. Porting efforts were compounded further by schedule troubles on the PC side, which were amplified into even bigger delays in the console version. 8monkey's engineering team ended up spending more time working on console issues than anticipated, tying up programming resources that could have been put to other use.

In the end it squeaked through. The console version retained most of the visual effects and content from the PC, but had to be scaled back in a few areas to salvage performance and memory. The final console deadlines just before shipping were some real nail-biters, and there were more than a few all-nighters and working weekends before it passed.

The root mistake here of course, in case you hadn't picked up on it already, was planning. Had we known from the outset that Darkest of Days would see console release (or even planned for the contingency), smarter tradeoffs could have been made earlier in the process regarding technology and art choices. Unfortunately, the late port put us in a bit of a corner in some ways, and some hard choices had to be made that could have been avoided had we been more prescient.

2. Custom Engine (just the bad parts)

While the development of the Marmoset engine has been a good choice for 8monkey, it may not have been the most expedient choice for Darkest of Days.

Developing an engine from scratch takes time. A lot of time. Even though in our case it was done at very low monetary cost (it was created by only two engineers), it did take substantial time. Nearly a full year had passed by before the engine was full-featured and usable. During this first year, the rest of the team was attempting to prototype game-play for Darkest of Days. But most of our efforts during this phase were constrained by or centered around engine development in some fashion.

Even during full production, when the team began to grow and content for the game began to be produced in earnest, the engine was not always ready to behave. It never quite seemed to be finished (and indeed, what game engine is ever finished?) During the course of the project, engineering efforts were constantly diverted away from game code and into engine maintenance. In the last year or so, Marmoset did finally began to stabilize somewhat (with the notable exception of the Xbox 360 porting efforts). But the time had already been lost.

So should 8monkey have used a third party game engine? At this point it seems fairly clear that doing so would have shaved significant time from the development schedule, and gotten us to market much more quickly.

But would the game have been better? That's difficult to say. The look and feel of it would certainly have been drastically different, and it would have no doubt lost some of its unique charm. Some technical problems would likely have been traded for others, and certain technical design requirements may have been more difficult to satisfy (large outdoor environments and big NPC counts being two good examples).

3. The Travel Agent From Hell

"Darkest of Days was a game everyone wanted to spend fifty million dollars on... but we had ONE!"

- Aaron Schurman, Writer / Producer

Darkest of Days takes place in five distinct time periods: the American Civil War, Custer's Last Stand, World War I, World War II, and the eruption of Mt Vesuvius in 79 AD. This variety is one of the strong points of the game, allowing players the choice of time lines when selecting missions. But the feature did not come easily.

Asset reuse suffered massively: each time period required unique sounds, levels, characters, buildings and environment art. The number of time periods meant that at most, a period-specific art asset was used for maybe 15 to 20 percent of the "game time" in the final product. Our art team had to churn through props, characters and animations at a hectic pace. Toward the end we all became good at planning clever production of assets that could be shared between two or more periods. We tried to resist the temptation to just go nuts with wooden crates everywhere.

The temporal variety placed a lot of pressure on the engineering and design teams as well. AI features ended up being created for specific periods, and not used in the rest of the game (Civil War formation combat is a prime example; Roman soldiers are another).

The differing nature of the battles made game design a challenge. The game has 24 weapons, most of them era-specific, and they all had to be balanced and tweaked. Some of the future guns are used in several different periods, and these had to be adjusted for use in a wide variety of scenarios.

Making Darkest of Days was in some ways like making five games with the resources for one. It put a large strain on an already small team; saying it was a stretch is putting it mildly. In many cases it prevented us from polishing certain areas of the game to the level we would have liked. The variety still works well for the title and is a major part of its appeal, but it was traded for a measure of quality.

Article Start Previous Page 3 of 4 Next

Related Jobs

Insomniac Games
Insomniac Games — Burbank, California, United States

Technical Artist - Pipeline
Insomniac Games
Insomniac Games — Burbank, California, United States

Engine Programmer
Legends of Learning
Legends of Learning — Baltimore, Maryland, United States

Senior Gameplay Engineer - $160k - Remote OK
Bytro Labs GmbH
Bytro Labs GmbH — Hamburg, Germany

Senior Product Owner / Live-Ops Owner (f/m/x)

Loading Comments

loader image