Archive | Atec3351 RSS feed for this section

Post-mortem of Taicho

9 Dec

Brandon Lee, Eric An, Aaron Powell, Andrew Cross  11/18/11

Postmortem of Taicho


Brandon Lee – Stacking mechanic, Movement mechanics, Board layout.

Eric An – Board layout, Board production.

Aaron Powell – Movement mechanics, Capture mechanics.

Andrew Cross – Player pieces production.


Taicho was last idea we came up with right before class, and was by far our best one. Initially the game played very quick and brutal because we had the ability to stack and move all at once.This led to 2-3 minute games. I still there’s something to be said for a fast-paced game, but it wasn’t good enough for our game restrictions.

During the Alpha Test, the testers came up with an idea for capturing units that we found useful; capturing an enemy using multiple units. At the same time, it was horribly game-breaking. We solved that issue by having just one piece be the “active” piece in combat, and move to capture. Aaron and myself spent a lot of time forming a consistent logic throughout the game. The main problem we faced came from a debate about whether Stacking counted as movement since you “move” multiple pieces to one square. Ultimately, to get the right pacing and consistent logic we limited players to doing only one thing at a time, ie stacking can only be done one piece at a time.

Due to bad experiences with previous groups, I made sure to get the rules done myself. Making sure the rules clearly stated every facet of the game to the unintiated, even going so far as to define the critical terms like “adjacent” (an old habit from my debate days).


Postmortem of “Conflict”

22 Sep

I’ve decided that I should keep a Devblog for all my game creating shenanigans. So here is my first ever Game Postmortem. Hopefully, one in a long line. This was a paper due for Atec3351.

Brandon Lee                                                                                                             9/23/11

Postmortem of “Conflict”

Team Members: Adib K, Brandon G, Brandon L, Doug B and Eric A.

Adib – tech cards

Brandon G – board/typed up rules

Brandon L – fighting mechanics

Doug – resources

Eric – meter/victory conditions


Realistically we all had something to say about every mechanic in the game, but I was primarily responsible for how fighting would play out.

Originally, the game was going to be more economic and diplomatic, and I think that with enough time those could have been fleshed out more, but we ultimately made a game that relied heavily on combat. That transition made designing combat tricky; I had made it a very costly decision in the Alpha build, requiring that a player gave up one Army and one Money resource for however many soldiers they wanted to use. So, theoretically you could give up 12 resource cards to capture a Level 5 City (needing 6 Army supported by 6 Money), which would reward you with 5 random Resource (Army or Money) cards, 1 Tech card, and 1 Energy per turn. Aside from the energy reward being a little low, this is still what I would have preferred we do in the end. However, after a few playthroughs, I felt the game was playing a little slower than what would be considered fun, aka the Escalation Meter wasn’t rising fast enough. Personally, I’m a fan of turn-based strategies, and slow strategy games in general.

For the Final we changed two main things, we amped up the Tech cards, and we tried to promote fighting by letting the player only give up money to fight (unless they lost) and by taking a Risk approach, where we let the player leave behind Armies on certain tiles. The change to how much you sacrifice in a fight was probably for the best, but the defensive Risk mechanic was not fully thought out. There were many things I would not have included in the Final build, but the Risk mechanic was one of the most poorly misunderstood concepts encountered by the play team. It didn’t help that the purpose of the tokens was not made clear in the rulebook.

My partner Brandon G had the strange notion that a player was supposed to announce how many armies they would be using to attack with. I was joined with the play team in not seeing the necessity of that; I was also with them in not knowing that was in the game. Other than that I think the general fighting mechanic worked in the game. Tech cards in particular became a more interesting way to enhance combat in the game, once we cleaned them up. Overall, Conflict turned out reasonably well, and despite some last minute pressures I felt we produced one of the better put together games in class.