Assignment 3: Play testing
We found many helpful insights into our game during our intensive play testing session. This included a rather serious issue where players lost 100% of their health if they collided with an enemy ship.
Our testing demographic consisted of players who were naive to our game, were all gamers and enjoyed either rhythm or arcade games to some degree. We believed this was important as we wanted to get feedback from players who should enjoy our game and be familiar with how the game play works when effective.
During our first run through our rhythm elements proved to be underwhelming as many testers did not realise that they were part of the game. During deep testing the rhythm elements did add a complexity to the game some testers felt was missing but otherwise did not deliver as intended.
Our defence phase was a hit but not without a few issues that were uncovered, like the player still being able to shoot the enemies even though nothing happened and the phase change being confusing to our testers.
Reflections from the Readings
Game Design Workshop : A Play-centric Approach to Creating Innovative Games, Fourth Edition by Tracy Fullerton.
The final part of Fullerton's book offers insights into working as a game designer. This includes an in-depth discussion on team structures. In the developers team we will find a game designer, producer, programmers, visual artists, QA (quality assurance) engineers, specialised media and a level designer. All of these roles are important to game development and all contribute to the game design.
The book looks at stages and methods of development, with a key focus on agile development. Agile is a methodology that offers a flexible and iterative design approach, were developers address priority features to set short-term goals. Teams will work in sprints, a short period of time focused on implementing a clear goal, they will hold scrum meetings, daily meetings to track progress, set goals or report problems and teams will use prioritisation and working on features to organise workloads and sprint goals.
Agile project planning allows for scoping and revising during development, features are given a scope of time, effort and cost during planning phase that can be refined if found unfeasible. In agile budgets and time isn't manipulated to reach the required outcome instead features are refined using a task priority list, and low priority tasks can be removed from that feature. This means features can be implemented to the clients expectations without budget or delivery time blow outs.
Fullerton goes into detail about how designers need to communicate their designs, for our project we have used a one page design document, however, our team also constructed some tables that communicated the statistic required for certain parts of our game.
Fullerton suggests the use of flowcharts, to demonstrate all possible outcomes of a game, tables and spreadsheets, concept art and descriptions. This should all be formulated into a design document that has all aspects of the game nicely listed in a content page.
The book also suggests designers make sure they get a full understanding of the game industry to become better designers. This includes gaming platforms, the size of the industry, genres, the publishing landscape, developers and finally the business in game publishing. Designers who understand that a game that will take millions of dollars to make but based on current research might not seem that profitable will know how better to pitch their game, either by refining the idea to be less expensive to make or knowing how to make their game more appealing for a large audience reach and therefore higher profits.
Finally, designers also need to know how to sell themselves, along with their ideas. The book suggest designers educate themselves by researching the industry, participate in academic pathways, play games, take the initiative to design games and levels, networking, joining related organisations, attending conferences and the ever common, yet dreadful, starting from the bottom as an intern or a QA tester. Once designers have found work in the industry they can begin to look at pitching ideas, as the book suggests most production companies take ideas from trusted sources, like known game developers.
Our team is mostly interested in independent production as we are all Computer Science students vacationing in game design. The book implies that being a successful independent game developer is a long shot but I don't know, I'm feeling optimistic.
