Sponsored By

Postmortem: Hymn of the Sands

A postmortem of capstone project "Hymn of the Sands" by a producer at the Guildhall at SMU.

Dustin Davis, Blogger

December 18, 2013

5 Min Read

Today marks the end of a five month capstone project by Working as Intended Studios, a team of graduate students at the Guildhall at SMU.  Our project was to create a game demo in the time given.  I joined the team as producer about a month into development, after Proof of Concept Gameplay, making me the fourteenth team member.

From the start, the team had very few limitations on their design - they had to work in UDK and the game couldn't be exclusively first-person.  Other than that, the rest was up to us, so long as we make a fully-working demo that showed what we were capable of.

At the time I joined the team, they had the game type (puzzle and isometric action) theme (Egyptian gods) and a rough art style figured out, sample combat mechanics working, examples of traps and enemies, and a version of our core game mechanic: Realm Shifting.

Unlike other projects I've produced at the Guildhall, from my perspective the development of this game was notable mainly for its steady progress.  Now that may not sound interesting, and we certainly had problems and challenges, but from my first day on the project to today, the game got better and more complete.  We somehow made it through wihout any of the dramatic stops and starts that can come with game development, and student projects in particular.

 

The following list is a few points brought up during the postmortem our team discussed today.

What went well:

  • Time management:  We knew exactly the amout of time we had left, had decent project visibility during the majority of development, and had learned to plan accordingly.

  • Design feedback: The Level Design team in worked particularly well providing collaborative feedback on each others' work.

  • Archetypes: Our programmers were quick to create a range of adaptable archetypes the level designers would use to develop the abilities and enemies in the game, meaning that if a level designer wanted to experiment with making the upgrade to the Blink decrease its cooldown, the designer could do it himself on the fly.

  • Cross-discipline assistance and communication: Our Capstone room was typically a lively and active place.  An designer would be sitting with an artist during an art pass showing him how to avoid Kismet warnings, while a programmer was getting feedback on the HUD from the game designer.

  • Ownership: Everyone felt a part of the game.  The Level Designers largely got to work on the elements they liked best, the artists got to "art pass" the game, giving them a lot of influence on the overall look and feel, and the programmers had their hands in nearly every element if they wanted.  And all of this was done without drama or posessiveness.

  • Team playtests: Regular times were set aside for us to play the game as a group and as individuals, offering good project visibility. 

What went Wrong:

  • Organization and communication before Vertical Slice:  At the earliest points of development, the project vision wasn't particularly clear and agreed-upon.  Multiple design ideas were still in the air and the team wasn't entierly sure how much puzzle or action was in our puzzle/action game.

  • Learning while doing: As the first student project of this scope for most of the members of the team, there was a large learning curve.  Animation was being learned during development, much of the HUD and controls development details were new, and we had to dynamically adjust scope during development as we learned what we were capable of.

  • Didn't explore mechanics fully: Now at the end of the project, we see huge opportunities for developing our game mechanics further, if only we had the time to delve deeper.  There are game elements we already have in place we can now see have fun gameplay potential that simply didn't get explored.

  •  Approval pipeline breakdown: One of the drawbacks of a team that freely and happily talks to anyone and everyone is that the roles of the leads sometimes get overlooked for the sake of expediency.  This led to a few examples of a lead being surprised by new content when they should not have been.

What we would fix:

  • More playtesting, and more mini-milestones: As much as we tried to emphasize playtesting, it's inevitible that we wished there were more.

  • LDs could have leaned more on programmers: Our level designers would find elaborate ways to get UDK to bend to their will.  And as much cross-discipline communication as we had, sometimes things would get overlooked.  After an LD showed us their newest success, a programmer would sometimes ask, "Why didn't you just ask me?  I could have gotten that to work in ten minutes."

  • More solidity/strong leadership during pre-production: There was at least a little team stress  early in the project where uncertainty in the design and theme led to some passive-agressive conflicts that had to be worked out over time.

  • Breakfast: Our post-mortem discussions kept heading back toward "we all worked better when someone brought food" for some reason.  I think it's because Andrew brought us french toast this morning. 

 

My experience on Hymn was a highlight of my time at the Guildhall, and was one of those fortunate times where you can easily see the value of your influence on a team.  I'm graduating this month, while the rest of my team has another semester remaining at the Guildhall.  I wish my team the best, and hope to work with them again somewhere out there in the industry.

Read more about:

Blogs

About the Author(s)

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like