The origins of our castle game date back to the 20th of April. The task at hand was to prototype a medieval castle-building simulator. The core of the game's flow, around which all other mechanics would stem, was to construct a garrison, with limited time and resources, that could withstand varying degrees of assault. We drew from history for much of the gameplay and context, which facilitated our process.
Sara, who came in at the beginning of our session to talk about some of the basic premises, and to give us some reference material, commissioned the project. She wanted the game to be centered on the historical castle's primary function: to serve as a bastion for its subjects.

Our prototype went through several permutations throughout the course of the day. For a game involving what is essentially urban planning, the natural inclination was to design a strategy game where the interface is a birds-eye view of the terrain, with some arbitrary geographical features scattered about the map. After an awkward play-through with this set up, we switched to a two-dimensional elevation of the map, which allowed us to focus on very specific castle building elements, something that had begun to lose relevance in the original over-head view (side views are also quicker to prototype when using grids and dice).
The next configuration of the castle prototype was as follows: The player begins with a keep, drawn on the right side of the map. He/she can then build three additions or "upgrades" to the keep before the turn ends and the enemies arrive. In addition, the player starts with twenty soldiers at his/her disposal. The upgrades, which range from walls to ditches and moats, are designed to increase the number of turns it took for the enemies to cross the map while the player's archers pelt them with arrows.

When the enemies arrive on the scene, they enter from the left side of the map and move unyieldingly along the grid. Within a certain a certain distance of the player's tower (assuming he/she had built one and garrisoned it), the advancing foes begin to receive damage determined by dice roll. Damage is determined by the number of soldiers in the tower. If there are ten, and they make a successful volley, ten bad guys will be neutralized. As the enemies draw nearer to the tower the probability that the archers will deal damage increases. Should the advancing army find itself in a moat, ditch, or upward slope, the player's archers get two dices rolls to attack. If the enemies happen to reach a tower, they spend a turn to breach it and march forth without hindrance from its bowmen.
We followed this blueprint to a great degree for the remainder of the session. Our abstractions, however, began to grow more specific. The player was given three months in game time to fortify his castle. Each upgrade varied in the amount of time they took to build. For example, a wooden wall would take half a month, while a stone wall took twice that. A moat also took half a month, but required a ditch first, and so forth.

We were fortunate to have detailed references of actual castle defense mechanisms, which we readily adapted to our prototype. We allowed the player to make some very specific modifications to their fortress. For example, adding "machicoulis" to your castle enabled your archers to shoot at enemies that were up against the wall. Obstacles such as sharpened planks were cheap, quick to manufacture, and were super effective against invading marauders.
The amount of foes attacking each turn was predetermined and consistent, despite the player's statistics. Difficulty was keyed to the "type" of enemy: the first and easiest force the player faced were an uprising of seventy-five peasants. Peasants could attack the walls of the castle, but could not return arrow fire, and were usually vanquished with relative ease. Next, the player would be set upon by a hoard of pillaging Vikings, who had archers of their own and were capable of ranged attack on the defending soldiers. The second wave of enemies was also usually quickly overcome. By the third turn, however, the player faced an army equipped with catapults, which had a fifty percent chance of hitting his/her towers. Here we introduced hit points for walls and towers, which were respective to the material they were made of. Only at this stage did the enemy pose a real threat to the player, as the siege weapons fired relentlessly at his/her defenses.
Here we began to reconsider the format of the game. Initially, we wanted no input from the player as soon as building ended and the battle commenced. The introduction of some in-battle decision-making might be crucial to combating enemies with engines of war.
At the end of the day we had a basic three-level prototype, but with components that were easy to redesign and reconfigure as we saw fit. Curiously, we began to see very easily how it could be translated into a digital game; there was considerable amount of dice rolling used to determine the outcome of the battles that could be adapted quite simply.