“Create a path through the viral wastelands of NYZ and build up a vast genetic arsenal as you hunt, kill and consume your way towards your ultimate goal… destroying Alex Mercer!”
Prototype 2 was the final game I shipped at Radical Entertainment. In the time between the finishing Prototype 1 and starting Prototype 2, I transfered from the Front End team to the Mission Support team. Mission Support at Radical basically meant the programming side of mission creation. We built tools, defined processes and created backend systems to manage the creation and delivery of Mission content. We built the layers between low level engine code and high level mission content, allowing Mission Designers to be more productive.
Open-world action games a quite complex, and it lead us to do some pretty innovative things during this project. For example, the loading of mission content was completely reimagined for this game.
On Prototype 1, we only ever had one mission available at a time. When that mission started it got to load 3 characters of the designers choice, and had to make do with those characters and whatever characters were globally loaded (eg. common characters like Soldiers and Pedestrians were loaded all the time). Along the same lines, open world designers (designing things that happen ambiently in the world, regardless of whether or not you are in a mission) could only use globally loaded characters. They could not rely on characters loaded by missions since those missions could start and stop at any moment, and they could not load their own characters for the same reason.
This meant that designers were quite limited in terms of what they could load into memory, and at the same time, for large stretches of the game we were leaving huge chunks of memory completely unused. Both problems needed to be addressed in order to compete in the open-world genre.
For Prototype 2, we developed a much more dynamic system. To start, the distinction between a “mission content” and “open-world content” was completely removed. Now everything was a mission! And as a result we allowed multiple missions to be running at the same time. They could start and stop independently of each other too. As you run around the world of Prototype 2, dozens of little missions are starting and stopping. That group of scientists examining a decaying Infected body? That’s a mission. That dead Blackwatch Soldier with an audio recording on him? That’s a mission too!
Mission content was loaded in as a series of layers into one giant, contiguous piece of memory. When you got close to the area where the group of scientists were supposed to be, we created a new layer in our memory pool, and loaded all the content it needed. When you leave the area, the layer is removed, and that memory is freed. Since all missions shared the same large chunk of memory, that freed memory could now be used by another mission.
Now this whole system starts to fall apart when you start thinking about things like memory fragmentation, and even just testing (eg. we run out of memory when standing a position X, Y, Z, but only after playing Mission X in the game — eek!). We solved all those problems, but that could fill an entire article of its own!
As a result of this new mission memory system we were able to create a much more dynamic, rich world. Mission designers were allowed to use all the memory available and we even had some special cases were a particularly expensive character (like a boss fight) could shut down all other missions to have the entire chunk of memory to itself. In the end, the system was so successful that additional systems, like world props, were brought into this gigantic piece of memory, to allow us to take advantage of that memory growing and shrinking as you progress through the game. It was the most complex piece of Prototype 2’s mission architecture, but it was worth it, as it certainly had a major (positive) impact on the final product.
