Darryl Long

Over this week and the next were going to be wrapping up our Fungus tool application and making just finishing touches to the tool. This post mortem will analyse the planning and production during the development of the tool in order to identify mistakes or replicate successes.

Planning and Coordination

There was a clear lack of planning in the latter half of the project with a number of commands being made up on the fly and not being documented properly. Coordination between group members was fairly clear between creating commands and building different aspects of the project. These can be attributed to:

• Lack of Documentation – Lack of documentation in the initial planning phase caused a more chaotic development phase later into the project.
• Lack of Knowledge – There was a lack of knowledge at the beginning of the project as to a clear understanding of what exactly was needed to be extended in order for the designers to be able to create their games. We were able to create a base understanding of the initial commands and events needed through creating a mockup using the original Missile Command.
• HackNPlan – Through HackNPlan and communication over discord and face to face communication, the group was able to clearly able to distribute tasks and work on specific tasks.

There are a number of actions to prevent these planning problems and replicate the success of the coordination in the future.

• Documentation – Further documentation could’ve helped the planning and development of the project greatly. Having a document that detailed out each command we were going to add with details such as potential use, reason for addition, and  variables used etc. This would mean that adding another command or event would be a simple matter of adding another entry in the documentation, that way anybody can see why this command is needed and why we added it.
• Playtesting – Playtesting early could’ve helped with filling in the gaps of knowledge quickly and finding out what designers needed so that we could implement these changes. However during this project, we were unable to get the minimum viable product quick enough for players to be able to playtest, in addition, the playtest was not very successful, in the fact that we weren’t able to get the most valuable information out of the project. This will be discussed further in the next section.
• HackNPlan – The continual effective use of HackNPlan and communication should assist in coordinating with other group members in future projects.

Playtesting

Playtesting is an integral part of developing a tool, it allows the developer to see what parts of their tools are working and which ones aren’t and it allows feedback for more development and work on the project. The playtests in this project weren’t very successful, it took more than a week for users to playtest the tool and the feedback that they gave were mostly feedback about not understanding how to use the tool.  These failures can be attributed to:

• Mid-Late Playtesting – we began playtesting late in a 3-4 week project, this gave us less time to analyse feedback and make adjustments to the project.
• User Documentation – having unclear user documentation was detrimental to having a successful playtesting phase, this left our users confused and fighting to get the tool working rather than actually using the tool.

There are a number of actions to prevent these playtesting problems for the future:

• Early Playtesting – Attempt to get a working version of the minimum viable product as early as possible in the project being playtested. This allows for the core users to get familiar with the product in the first place and give feedback early in the development in order to get it working.
• Clearer instructions – There was a lot of feedback on the tool being difficult to understand and use, and designers being unable to create their games. Having clearer and step by step instructions would be more useful in getting a successful playtest. In addition, having examples or sample scenes would also assist in the playtester’s understanding of the tool.
• Time Estimates – Having a time estimate for a playtest gives the playtester an idea of how long a regular playtest would take, this allows them to be able to allocated time out of their schedule for the playtest.

Implementation and Development

The implementation and development of the tool rain fairly smoothly without too many problems. Changes had to be made as to how some of the command functionality worked and there were some problems with the tool Fungus itself. Overall the implementation and development of the tool was fairly successful in recreating functionality relevant to the original Missile Command. This was due to a number of factors:

• Base Tool – We were able to develop on top of an existing base tool with functionalities already developed. This created a framework and constraints that we needed to work within and develop commands for them.
• Commands – Commands were able to be developed fairly easily through the framework of Fungus. This allowed us to effectively create new commands for the tool.
• Research – We were able to research properly and work out how to create commands and events effectively. There was also some prior planning that helped us off on the right foot.
• Time Management – Time management through coordination and tasking up tasks in HackNPlan allowed us to effectively use our time to develop commands and events for the tool. In addition it kept a record of what needed to be developed for the tool.

There are a number of actions to replicate the success of the implementation and development in the future:

• Research – Research into how to implement the tool should be conducted before executing on the tool and beginning to develop it. This allows us to have an understanding of the tool that we are creating and how it should work.
• Time management – Tasking up and allocating tasks properly in HackNPlan allows us to effectively manage our time and get more progress done week to week.