The Process of Creating a Mission

The first version of a new scenario

The starting point was always the historical research conducted by our narrative team. Together, we would identify key events — battles, sieges, or other pivotal moments — that could serve as the basis for a mission. The challenge here was to strike a balance: respecting the history and narrative, meeting player expectations, and ensuring that gameplay stayed fresh without diverging too far from the core single- or multiplayer skirmish experience.

Once a mission concept was agreed upon, my role as a level designer began. I was responsible for sketching the map layouts and outlining the gameplay hooks, main and side objectives, and the basic AI requirements for each level. These sketches and design documents also defined the factions, the intended style of gameplay, and the overall flow of the mission, as well as user stories for players of different skill levels and what their expectations and emotions playing through the scenario would/could be. If the scenario had a specific intricate system, an external balance sheet would be made to easily iterate on different numbers for said system in the table without needing to implement each of those in the editor. The outlines would then go through feedback and iteration until approved.

With approval secured, work shifted into the in-engine editor. At this stage, we kept the maps intentionally simple: blocked-out terrain, placeholder text, and minimal detailing. Early internal testing was key. Other team members — not only the designers — would play these early builds, since first-time player experience is crucial and designers naturally approach scenarios differently. Sometimes a mission that seemed compelling on paper would reveal problems in practice, whether due to cumbersome mechanics or limitations of the engine. This would cause a redesign of the mission, depending on the scale of changes, going through the outline stage again.

Alongside map design, I also worked on AI scripting. Age of Empires II uses its own rule-based scripting language. While we had an AI expert for the most complex tasks, I learned to handle the majority of the scripting through our internal library. This included unit training, base building, economy setup, and attack patterns tailored to each scenario’s needs.

Once the mechanics were stable and early bugs addressed, I moved on to a basic difficulty balancing. Each map needed to be accessible to casual players on lower settings while still challenging veterans on the highest difficulty. The balancing process involved adjusting not only enemy resources or unit counts, but also subtler levers like attack timers, army compositions, cooldowns on reinforcements or tributes, and the player’s starting conditions. Having systems in place early made it easier to iterate without major reworks later.

Text was initially drafted by me as placeholder objectives, instructions, and dialogue prompts. These would later be refined and/or replaced by the narrative team to ensure consistency of tone and storytelling.

When a scenario had reached a stable and well-received state, I transitioned to detailing and polish. This included blending terrain types, adding decoration, and cleaning up rough edges to ensure the map felt authentic and visually cohesive. After that, scenarios entered a broader QA phase, with external testers putting them through rigorous playthroughs. Using a ticket system, I collaborated closely with testers to address bugs, refine communication of mechanics, and smoothen out the narrative and gameplay flow.

By the end of this process, each mission was not only historically grounded but also designed to harmonize narrative beats, gameplay challenges, and player accessibility, delivering scenarios that felt both authentic and engaging.