With credit to my two teammates on this project, Bernd Paulus and Kyle Forgaard.

A game done in 15 weeks with a group of 3 people total. We wanted to make a co-operative experience rarely found in games in-which players work on a team, but each have drastically different roles. To contrast with other co-operative games, like shooters for example where there might be a tank, healer, specialist, etc. In most games in that genre, players may have different play-styles to suit their tools, but overall their task is the same: Shoot the enemy, help their teammates.

What we wanted was different. We wanted each player to basically be playing their own individual game that happens to be intertwined with everyone else’s.

What we came up with was a medieval-themed game where one player played the king, and up to 3 others were his council members: the Head of Resources, the Head of Carpentry, and the Head of Arms. The mechanics for each of those players evolved a lot through development, as to be expected, but the main concept of each never waivered.

The King

The King is in charge of major decisions, resource distribution, and communication between the Heads. He request resources from the Heads and either uses them to buy other needed resources or distributes them to other Heads who need them to function. Everyone depends on each other to function, since everyone produces a resource that someone else needs. He also has the less demanding job of taxing the people to produce gold for purchasing extra resources, while trying not to make the citizens too furious. Should this happen, or should the Head of Arms fail to product the kingdom, or if the upkeep of the kingdom not be maintained through the spending of resources, the game is lost.

The Head of Resources

The Head of Resources produces the bulk of material for the kingdom to use, managing farms and mines to produce the needed food and building materials. He also has the option of upgrading his production buildings, as well as risking his daily production for a boost. The more risk he took, the more he gained, but the less chance of success.

The Head of Carpentry

The Head of Carpentry finds and builds new production buildings for the other 2 heads, while also producing workers as resource. His job is to search for new building plots each turn, and then decide based on the properties of the plots, as well as what buildings are currently needed most, which type of building he should construct.

The Head of Arms

The Head of Arms produces and deploys soldiers to fight off any incoming invasions. His job is to scan the incoming forces, and change the armaments of his own forces to match. He has the option of producing archers, foot soldiers, or cavalry, and each has an advantage over one other, similar to rock, paper, scissors. Every turn he must prepare himself for the next army, and for every loss, the kingdom becomes a little more unstable.

Development

Being a small team, there were a few things we knew we had to keep in mind. First of all, not to bite off more than we could chew. That’s why, with 3 programmers, we decided to make this game completely a GUI based game. It made it slightly easier for us to create a decent looking game despite having no artistic talent between us. The second major thing we kept a close eye on was to not over-scope the project. To combat that, our idea was very modular. This is why we have 4 distinct roles. Originally there was a fifth. The way we planned out the game, we made sure that each subsequent role would be less and less necessary, just in case we were unable to create it in time. So about 2/3rds through development, we realized we needed more time to flesh out and balance what we had with the first 4 roles before we implemented the 5th, and that we wouldn’t have enough time to properly implement the 5th without it appearing shoddy and thrown-in. And finally, the third thing we watched closely was the splitting of the roles within the development team. We decided to make one programmer be a full-on director/producer who focused on making sure the game felt right, one programmer would focus completely on code and making things functional, while the last would be the median between the two, someone who knew well both the code-base and the intended feel of the game and could act as a sort of bridge. I felt it worked out well. No one was ever over burdened and we always had someone looking in all the necessary directions. No problems ever snuck up on us.

The project, while not very pretty to look at, turned out pretty fun and solid. and I’m proud of what we created.