Abstract

Introduction

Problem and Assignment

Challenges

Domain Challenges

Technical challenges

Requirements

Game design

Hardware

Technology

Architecture

Z Tellman

World-state

Brick

Approach

The proces

Roles

How did we treat these roles? Were they valid?

• Technical
• Architect - Swapping people might help maintain consistency and manage dependencies between sub-components. Not enough Clojure experience to feel comfortable in large projects (need to defend this point well, common lisp & scheme experience).
• Testing -
• Quality Assurance - Didn't review enough. Didn't take enough time re-factoring and designing. Switching people around might help this.
• Game/Interaction design -
• Design -
• User testing
• Production - Need end to end planning to be useful early in the process. Can influence important decisions.
• Soft -
• Project Lead
• Contact
• Editor

Planning

Phases

How will we divide the project up in phases? What is the reason for each phase? Small iterations, test early test often

Administration, communication and documentation

Use travis CI and github tickets.
Use Google group for communication.

Testing

Iterate the following steps:

• Prototype - Research abstractions and architectures. Should be done in pairs for key functionality (such as...?).
• Define Interface - Expose what functionality you will offer.
• Define tests - Think about what needs to be tested early to make sure no functionality is missing and what edge cases might occur before implementation.
• Small Iterations of the following steps:
• Implement - Actually offer said functionality.
• Implement tests - Should be beyond reasonable doubt that the code defies the defined interface.
• Re-factor - Beatify, Don't live with broken windows (A. Hunt and D. Thomas 2000)
• Code review by someone not in the prototype pair.
• Merge - When done merge back into the main branch (first mention, branches should have been explained before). Interface should only grow from here. Regression tests for bugs in earlier work. Approach loosely based on test-driven-development but aimed to expose an interface as early as possible to make planning more flexible.

What did we test? What should we (not) have tested? Decide beforehand.

Process reflection

What did we do right? What did we do wrong? What did we stumble upon? How can we use this? Were the roles complementary? Were the roles combinations chosen well?

Results

Discussion

Single Screen multi-user gaming

Stimulating cooperation

Appendices

Game design document, referenced throughout the document

Orientation report.