This post mortem will outline the defining elements that lead to the exhibition version of Massive: Reactor, an arcade-style game designed by Byte Canvas. By the scheduled public showing, the game still had issues but was mostly functional and well received by the people that played and observed it.
The purpose of the game was to take an existing mass produced input device (as common as a mouse or keyboard up to a game-specific device like the Tony Hawk RIDE board) and design a game that required it to be used in a manner not intended by the designers. This project made use of a Guitar Hero: World Tour drum kit for the Playstation 3.
The team comprised of a designer/general artist and a programmer, with music from an outsourced musician/audio technician. 3 people in total to be credited.
What went well?
The style of the game came together quickly:
From the beginning of the project I was intent on making the prototype of the proposed game before making any further design choices as the idea of using a drum kit in this manner was not something I was familiar with at all (as was the intention of the brief and the design). Once we did that the test was ready. The game was called “Drum Station” at this stage.
Reactor developed a very cohesive style right after the first working version of the game had been developed. Once we had tested the controller and how it felt to use with the game prototype, it was obvious that the actions taking place on screen were not befitting the dramatic actions being used to play the game. Nothing felt worthy of it.
This was the stage I was wanting to get to for this exact reason. I did some art searching, looking for general inspiration on each of the elements in the game. I found an image of a tech planet that felt like an orbital laser might be set up around.
I started looking into the old Heavy Metal comics and Judge Dredd for inspiration along with Warhammer 40k, all of which have heavy industrial, futuristic tones and designs throughout. This lead to more changes like dramatic backgrounds and cyberpunk UI and titles.
The change that most reflected the action/feedback consideration, I feel, was the station’s laser and it’s cannon. The original design involved a needle like spike that would zap outward. Looking at it in action without any sound gave me and other observers an internal sound of “pew pew” which didn’t feel big enough for the action of smashing a drum. We needed a “Boom!”. I did some research and found this image-
The wide bore suggested “boom” so the design was adapted and a fitting sound implemented.
In past projects, I have paid attention to the visual cohesion of projects and how they fit thematically and audibly, but now the physical action of the player will have more consideration during the development of future games. This is a lesson that I have now added to the process that I will take when making games.
What didn’t go well?
Development instructions were not being interpreted to accommodate the whole:
The ability to communicate effectively between the designer and the programmer had many hindrances over the course of the project, due to many separate reasons but most were mechanical such as physically speaking to each other or the language barrier. These were largely overcome as they could be adapted to. However, in retrospect it is evident there was a fundamental difference in the way information was being received between the design notes and implementation requirements and the way they were being implemented. In so much as the documentation that outlined changes and required game functions were largely written to convey a functional goal, but were being implemented literally and only within the parameters of the request. The most effective example of this misinterpretation was evident in the exhibition version of Reactor.
The day before exhibition, the project required an input to allow a return to the main menu. From the design standpoint, hitting the cymbal pads together, twice, seemed to be obscure enough a behavior not to get in the way. When implemented, firstly, the result of the input was not the required function in that is simply restarted the level after a single dual-hit, but that was to do with the language barrier and likely the lack of diligence in confirming the requirement. There was a programmed time period between the game registering each individual hit of the cymbal pads. The other function of the cymbal pads is to change the direction of the main character, which is a function alternated between often. The hit time allowance was long enough that it was quite easy to accidentally restart the level. The game wasn’t tested after the implementation of the feature by the programmer and they had not made the mental consideration of how long the dual hit should take to be performed or whether the function as it was implemented would meet the player requirements to act as a strictly intentional effect.
Though this seems like an attempt at blame, it is simply an observation of a set of issues that are not uncommon in game development. My documentation as designer was written with the expectation that the person reading it would apply the practical application of the function to their understanding of the whole of the project. Similar to a notion of “common sense.”
But each request was being carried out to the specific parameters of the request. Developing a style of writing documentation to deal with this mentality is necessary in that this problem could be met again in the same manner or when working with multiple programmers who are not part of the rest of the project. Consider if one person worked on the direction system and another was given the function implementation description with no knowledge even that the cymbal pads had another use in the game. This would be a likely occurrence. Whether working with one person or many, being the designer who holds the understanding of the ramification to the game and the player means that future documentation should be written with the perfect ideal to what the function must do.
The problem with this may be that in order to be sure that the request does not conflict with other parts of the project may require a deep understanding of the programming as it stands at the point of update. To minimise the impact of this sort of situation, it would be easiest to have feedback from the programmer of what their function actually does as it is implemented. this could be a write up or log system that specifically refers to the numbers/times/functions/etc as they have been put into the game. This is a form of clarification as much as a useful update system for the technical specifications document.
The original team broke off early due to miscommunication:
The original team comprised the whole of Black Canvas, the same group who created the small tower defence game Soul Resource in 2017, plus one more who was rolled into the group. The initial developer had brought the Asteroids style game to the fore and was trying to develop that game. The problem came from the two designers that were working having polar opposite methods of development that formed a divide between the two.
One was intend on building the foundation of the proposed game and making sure that all of the actual input would function and then, through play and testing, start refining how the game could become more fitting for the controller. This person was not willing to plan further than a prototype to test the function of the tools being used as it would be a waste of time and would likely result in trying to force a game that didn’t fit.
The other felt that the desired end result needed to be decided first as a guide for the design process going forward and felt that beginning work on something without having a clear and total product idea would result in a lack of direction, which would get complicated and problematic.
Both had merit, both were missing the design consideration being asked by the brief.
The brief was trying to make the designers consider more than just the device itself, but rather how the device could be modified and how that would affect the game designed for it. One example was to cover the drum pads in flesh rubber and to require the player uses their hands instead of the drum sticks, this would suggest a slapping game of some kind. etc.
This misunderstanding was brought to the attention of the team after a week of correspondence on the development methodology to be used and this forced the final tear between the developers who proceeded to split into two teams. One of the divergents was insulted by the suggestion that they had misinterpreted the brief and the other was not comfortable with proceeding by the method being proposed by the current lead designer.
Looking back, these kinds of clashes would have been common and debilitating to the entire team if the split hadn’t happened as early as it did. The true cause of the friction was probably due to the amount of messenger and text based discussion and team contact that was taking place over face to face. This particular problem has been observed by both of the primary people involved in their previous teamwork and has been documented in the postmortems for them as well. Text based communication always resulted in friction. Remembering that, there was more of an effort to have face to face time for meetings and development, but due to the early need for rapid decision making text based contact was unavoidable and this is where the tensions started and evolved to the stage they did.
Language is a sophisticated thing that is hard pressed to be conveyed my just the words used. As other project were being developed after this period, there has been more of a focus on using voice based communicate when having meetings or making contact and it smoothed much of the decision making. In this particular case, the end products of both teams that resulted from the split are very cool and unique. I think that there would have been a diminished return in the final product had the team tried to force the cooperation as it would have needed to. Having worked on another project that had a team split due to conflicting methods previously, seeing the signs that suggested reparations were going to be more effort than they could pay off allowed the split to happen early in the project which lead to more time to focus on making something within both teams’ time frames and means.
Too many words:
This is one of the first projects I have been involved in that has had time to be polished. Granted that the focus of the design was about player feedback and interaction. The final stages had a “How to play” walk through that was immediately noticeably inefficient and poorly designed.
Each of the controls has a chunk of text describing (in words) the effect and also the context. The context is utterly unnecessary. It took too long to read about an unfamiliar system for such a straightforward game. This over explanation has been observed in other games where i have been in control of this area of presentation.
Moving forward I am going to try the most appropriate methods of briefly describing the controls of games and finding ways to reinforce the described player actions with images or by immediately following up the instructions with a manner for the player to try the instruction and see the result.