Postmortem - Game Production & Documentation

What went right?

This was an incredible experience for me. I had been working as assistant designer on this game (Ready Set Fight) for over a year. I did it as my internship for my undergrad and continued working there after I graduated. While we had made a lot of effort in the game’s design, character production, and extensive playtesting and balance updates, we had still never sat down and written out the full description of core systems we were using. The lead designer Joe had all of the details in his head, and he would explain them to you the best he could if you tried a playtest, but nowhere were all of the concepts, systems, and elements fully explained. It took a lot of talking, and asking questions back and forth with trial and error through many playtest sessions to get a full grasp of the game as a whole. We thought we were pretty much ready to start manufacturing. I always knew in the back of my head “yeah, we should write all this down eventually” and I figured that would happen with the writing of the Rulebook, however the Rules written down still don’t quite explain the whole picture. Once I sat down for this class and began building out all the documentation we learned about, I was forced to have the discipline of describing each part in great detail. This was a revelation for me, as it wasn’t until I had to think about explaining it in black and white text to a complete stranger that a lot of the systems really clicked for me in terms of their meaning and greater purpose behind the game.

Building the full Design Document for the game was not only a great learning and practice experience, but it was also very enjoyable. I had a lot of fun having to figure out the best ways to describe the systems and how they link together. Since a lot of the core rules and mechanics were already drafted in some form, I had a lot of material to work with and build off of. Even having the creator explain his backstory and world helped form the bigger picture of the game and why certain design decisions were made. Compiling all of it felt like putting together a giant jigsaw puzzle where as the pieces started to fit you could see the picture forming. Once it was complete I was thrilled with the resulting documentation as it finally put into words and structure why this game is so awesome!

One last thing that went well with this project was the final pitch video. I put a lot of effort into polishing the pitch using google slides (power point clone). I was able to add-in all of the game’s artwork and cards and used the power point slide animations to animate them and show how the game board worked. It helped so much to be able to take a player through a turn of the game (in brief form) so the viewer had a full understanding of what to expect when playing this. By keeping it brief and not going too in-depth with the rules of the game, it keeps viewer interest and is brief enough to get you excited and not get bored. Lastly, writing myself out a script helped a TON for the final video presentation. If you watch my first draft video and my final side-by-side you can hear the difference. The script helped me keep my words together and in-order, helped me explain things exactly how I wanted to and not fall off-track, and kept me moving swiftly and confidently to keep within a 5 minute goal time limit. I am super proud of how the final video came out and I even want to go back and tweak and edit a few more things to make it even better - or re-tool it a bit to use for a future investor / trade-show pitch to be sent out for evaluation. After speaking with the owner we are going to do just that and make this into a game pitch video for an upcoming design competition!

• What went wrong?

I am not satisfied with how the Art Bible came out. It’s a good first draft, but it is missing some key details. This is mostly due to the fact that the team hasn’t ever defined any art guidelines for consistency. I also do not have direct contact with the artist because we are going with a contractor he is working directly with the creator and we aren’t in open discussion like an in-house team where we can align our work styles. I mostly made the prototype cards and I made some design choices that looked cool to me and worked well on prototype cards where I knew I would have to print many copies as development moved on. However, a lot of these design choices ended up transferring to the final art, and nobody has defined any guide or art bible. So for this project I mostly defined my own art work on the game, as well as used early versions of finished artwork to describe what the artist has done (without communicating with them). This leads to some inconsistencies and unknowns. We don’t have a unified color palette so I didn’t include color codes. We don’t have unified line weight or font weight or even angle tilt, so it’s a bit hard to define in an Art Bible at this time. Some sections had to be left with “to be determined later” as a result. 

One thing I feel was left out of the Design Document was a diagram explaining the different parts of the cards. This would include descriptions of each part of the card - title, corner stack icons, attack, defense, card text, keywords, and combo links and any other artifacts on the cards. I think this is needed for the rulebook and final version of the game, and certainly should be included in the design document. Given more time I would make a diagram of the card details first.

Lastly, the production pipeline is very much an estimation, not based on our real development. We haven’t kept a record of our work over the last year and a half so it’s difficult to determine how long it has taken to design characters, refine cards with balance changes, and finalize decks etc. While all 8 starting characters are designed, we are still making balance tweaks and even changes to key art and card titles. In this class we learned that the more you know exactly what needs to be done to make the game, the more your pipeline resembles a Waterfall style, whereas if you are experimenting you fall more into Agile. The tabletop card game development process falls mostly into Waterfall style as we have to have things done in a certain order. We can’t have the cards manufactured until the art is done, and the art can’t be complete until the card is designed. While that is true, a lot of the design process is still agile - we start with a fully designed deck, then we test it and make live changes and tweaks as we go. While we have sent several characters to the artist as ‘final’, we still end up making more changes and having the art redone. The Gantt chart provided doesn’t fully represent this. It’s more of an ideal chart of how things should go if everything went perfectly. In reality, we are facing all sorts of delays, art redo’s, and design hurdles / changes causing more delays in the pipeline. Given more time to redo it I would model our production plan into a more hybrid of agile and waterfall charts to represent our actual practical pipeline rather than an idealized one.

• What is the most important takeaway you gained from this project? 

I think a big takeaway for me is that it seems that working studios don’t value documentation like this because they don’t see an immediate monetary value. Why would I have my designer work on writing a document about how the systems they already designed work and what they add to the game, when I could have them spend that time working on more of the game design. Why have an artist stop doing artwork to write out the details of their process when I could have them do more art in that time? It’s a very short-sighted view that the agile system has brought upon us, and while agile development caught wind because people just want to make stuff faster and iterate faster, it leaves behind the discipline of understanding why what we’re making works or doesn’t work. How can you expect multiple artists to work together if they don’t have a guideline to follow? They will produce different results every time - and that expands to every part of the design process. Code will come out different, UI will come out different, narrative elements will come out different. It’s why a lot of games feel weirdly disconnected these days. When you start shipping stuff that you haven’t bothered to sit down and fully understand, you end up shipping crappy, broken systems that people lose interest in quickly. You can’t just throw disconnected systems into a game and expect it to be fun. You need to map out why the systems will work together and add fun to the game. It’s like an author who writes fantasy / sci-fi. You can’t sit down and just write your final version right away. Before you even begin to write chapters, you have to sit and think about your fantasy world, what systems it has, how they work, what history the world brings, think about what fantasy elements will work together to bring the story alive? You must build out these ideas and rules and understand what makes them work or not work before you can write out a seven-book series of novels. If you expect to keep building games for the long run, or want to build a game that could have many sequels in the years to come, you have to do good documentation. Once you can explain on paper why these things should be made this way, then you truly understand why your game will be fun. Or, you will discover why your game won’t be fun far sooner so you don’t waste years of development time to find out late that your game just isn’t fun or the systems don’t really work together to create something greater than the sum of its parts. It’s a crucial discipline that is too vastly overlooked.