Post-Mortem: Project 2

INTRODUCTION

Today signals the final day of working on this project, a video (board) game. This project was relatively strange, and I didn't particularly have high hopes for it. However, every team had about the same amount of work done to a greater or lesser extent, and so I'm rather satisfied with it. 

Yeahnah: Election Day entailed working on a video (board) game, or so the brief told me. This game was more akin to a card game with FMV game elements, yeah, those cheesy things from way back when. The game had only three players and a set of two decks of cards (incident and response cards). Placing five incident cards in front of them, the players would respond to the incident with their response cards, input a code into a computer with the companion app running on it and voila. 

 

THE BAD

What exactly went wrong in this project? Were there things that I think could most definitely have been done to a higher standard or just better in general? The short and long of it is yes, there was quite a bit that I think could have been done better, as with all things game design things are bound to go wrong, take the time you think you can finish your project in, double that, and double it again and you'll have your time frame (or so I've been told). 

Firstly, my group found ourselves quite stressed and short of time. Without pinning blame, this was most likely because we didn't have any counter-risk documentation, or documentation that indicated and solidified to us the direction of the game that we are making. Having a basic schedule simply wasn't enough for us to keep entirely on track, and so our personal organisation let us down. However, one of the most glaring problems is that one of our team members felt unmotivated to do work, which most definitely didn't help to oil the dry brakes of the project. In the future, especially if given a larger project, with slightly more time, I would like to expect basic game development documentation such as a Game Design Document, a Schedule an Art-Bible so on and so forth. Rough outlines of these documents should be made promptly after the pitch. Even if the documents are rough outlines, the documents will be refined and expanded as the project goes through it's iterations. 

Personally, though this isn't directly related to the project, I didn't gain any programming experience from this project. As I was preoccupied completing and iterating on what little documentation we did have, alongside the placeholder artwork for the cards, I didn't get much opportunity to take Unity by the horns and check basic preliminary points off of the brief, particularly when attempting to have an inactive member of the team do some kind of work. However, I know that I definitely could have done much more work than I did, so in the future, I should actively seek out work where none seems present, not just trying to stay on par with the amount of work that others have done, but perhaps trying to go somewhat beyond that. Making scheduling documentation would likely help me accomplish this, and so I'd like to ask my team to get stuck into rough documentation early in the project. 

 

THE GOOD

However, just as there's bound to be negatives, there's bound to be positives. It's one of the inevitable traits of game development projects. While I don't think that this project went exactly the way that I, not my team wanted it to. In general, the project itself after the deadline felt underwhelming.  

I believe that amidst all other aspects of the project, out team's play-testing most definitely stood out. I feel that our team's play-testing, when the game was play-tested went rather well. After rounds of play-testing, rules would always be  altered and shifted to suit the group's vision of the game, it was always a pleasant experience to see the game being played by others, no matter how bad the game actually was. Clearly, these kinds of on the fly changes can only be made swiftly with physical media, such as the cards that we were to handle. In the future, if I'm to make physical media I would like to uphold those swift rule changes after each play test. If I'm working with digital media, though it may be harder, it would only make it that much more essential that I watch those whom play the game and take notes on their answers to a given questionnaire or their behaviours in the game.

 

Whilst I can't say that I'm happy with the end product at the end of this project, I can say that I'm satisfied with the design experience that I gained from it. Working with a physical medium, such as cards, especially as someone who is familiar with, and enjoys games such as Magic: The Gahering and Yu-Gi-Oh, I found it interesting to develop a PvE card game. I also come out of this project with much more respect for designers of board games and the like. Overall, I'm disappointed, yet satisfied with the experience of this project.

 

Tylah Kapa

@JadeKapa