Archive | Postmortem RSS feed for this section

Gather and Harvest

30 Jul

I sorta became bored with Gather, and broke it in to two parts. My thoughts on it were taking me further into simulating things, which is mildly interesting to see the result of, but not much to play. My decision is to go one step further with ripping off paying homage to SimAnt, and include a player avatar that imitates one of the worker roles. This will allow players to lead some units into direct conflict by rounding up a posse. There might be some other homages to the Maxis classic coming.

So, that’s where Gather might go if I actually do work on it again. Separate from that, I think I want to do another game that’s closer to a traditional RTS that uses some of the concepts that I came up with for Gather This came about because a lot of what I was doing in Gather was based on RTS principles, but at the same time I wanted to have a very simple control scheme (in the end I was aiming for too simple). So, my thought now is to just embrace the traditional mouse and keyboard ‘drag and select’ style RTS controls. Therefore, direct control over all units.

Harvest will be more about developing fields of different resources located around strategic waterholes, these resources can confer different attributes to units which will ultimately help you topple your enemy. The resources are farmed until maturity and vulnerable until then. The game is about controlling as much of the map as possible and using the mixture of attributes to boost troops as necessary.

We’ll see which one gets worked on.

Throwing Away My Idea – (Gather Mid-Mortem?)

15 Apr

I’ve recently decided to re-shelve the idea that I was trying to work out with Gather.

The notion behind the game was to somehow represent the physical and chemical reactions in the brain that make us behave in a way that ensures survival. This was my cornerstone design goal. Well, it turns out educational games are bloody hard to make. My problem, I think, was that I kept trying to address this somewhat complex series of interactions in the most simple and abstract fashion. Instead of specific chemicals that I would have to research or make up a chart for, I chose to design using Color Theory, so specific colors would cause reactions in the system. And since I wanted to show off electrical signals as well as chemical reactions (which is kinda technically the same thing when talking about “gated” cellular interaction), I decided to map “energy” to color warmth (warm colors had positive charge, cold colors had negative charge), which could have worked if I didn’t keep getting bogged down with making cellular functions make sense on the color wheel.

Another major aspect to the idea was to indirectly affect a relatively autonomous system until it built itself up and then you ultimately make a decision about what do with the final output. The idea went through a lot of rapid evolution in my mind while I was working on the prototype. Basically, I could never figure out in definite terms what my game was about mechanically; I didn’t know what the “fun” part about it was. I think I just wanted to make an ant farm that I could check on and fuck with from time to time, kind of like Simcity in a way, and there may be something to pursuing that.

I wanted to write this essay for two reasons though; first, it’s good to put down on paper why something failed, and second, to address why my decision is to move on instead of keep working out this idea. The second question comes from a friend of mine who remarked that I spent about a month and half on this game already. I’ve wanted to figure out how to make an educational game that teaches neuroscience for about a year and half now, and it’s because I’m so intensely interested in being successful in this endeavor, that I don’t want to attempt to tackle it before I can do it justice. And frankly, I’ve got enough other coals in the fire already that I don’t need to waste significant amounts of time on a flustering idea.

So, is everything I’ve done a waste? I don’t think so. Gather was probably one of the most beneficial failures I’ve had  recently. I only even started the project to learn pathfinding and turret behaviors in Construct, so I was successful as far as that went ( most valuable takeaway: don’t call ‘find path()’ while the object is already finding/moving along a path). More importantly though, I learned something about my own ideas and how to address some of them. And I think a lot of my design ideas are going to find their way into other games eventually.

And for the record, “Gather”, as a name, has nothing to do with what the game was about and everything to do with my complete lack of fucks to give about names.

Final Prototype

7 Dec

Prison Bash

Wasd to move. Space to suck up terrain. Left click is a weak sand bomb, right click is a strong dirt bomb. The dirt bomb alerts guards. Find all five prisoners and lead them to the escape pod(blue box).

I had to answer these questions as well:

  • Describe your game (including story and gameplay)
  • What goals did you set for your prototype when we talked one on one?
  • What goals did you accomplish?
  • What goals did you feel like you fell short of completing?
  • What do you plan on doing with this prototype in the future?

Final Prototype Post-Mortem

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.