Session 01: Goals, Objectives, and Tools
Welcome to this first session of the project notes for Zones, a mechanic for the CQ StoryHammer game system. This project had been started last year but it could benefit from the Projects treatment as I’m not sure if it’s current trajectory is still within scope or not. To ensure integrity of the product, I’m going to treat this as if it is a new project and go through all the steps – starting with the goal:
Goal: By the end of this project, I will have a set of instructions that explain zones and how they work.
That sounds easy but there is another goal to this project, one that has me questioning the scope creep mentioned in the introduction.
Supplemental Goal: By the end of this project, I will have a set of level components that I can use for testing future mechanics of CQ StoryHammer.
And that’s the crux right there. I’ve been treating the supplemental goal as the actual goal (for I’ve been working on that instead of the initial goal). Perhaps instead of treating these like two goals to the same project, I should separate these into two different goals.
On the other hand, I already have definitions for what zones are. The mechanics of zones will depend on future projects: movement, actions, ranged actions, etc. If that’s the case, then the original goal is a misunderstanding the concept of zones.
If that’s the case, then the supplemental goal can be the actual goal as long as its product serves to support future projects for zones (movement, actions, ranged actions, etc.) which oddly enough sounds exactly like the supplemental goal as-is.
Goal: By the end of this project, I will have a set of level components that I can use for testing future mechanics of CQ StoryHammer.
Neat. So we already know that an objective should be that the product is future-proof. What does that mean? That means that the product cannot be so limited that it is difficult or impossible to change to update for future CQ StoryHammer projects.
Objective 1: The product needs to be future-proof.
The resulting product will need to adhere to zone definitions, specifically allowing for the testing of different zone configurations. The definition of zones and zone configurations (not necessarily the mechanics for using them) is therefore needed for designing this. This sparks both an objective and some tools.
Objective 2: The product needs to enable testing of zone configurations.
Tool 1: Definition of Zones
Tool 2: List of Zone Configurations for Testing
In order to use these components for testing, they will need to accommodate human players at a table. So if I need to test 6 “zones” all in a row, and I make each zone 10″ x 10″, the result will be a 60″ (5′) board to test, which would require a table with at least one 5′ dimension. That wouldn’t work.
Objective 3: The product needs to accommodate a play area of 36″ x 48″.
Perhaps that’s too specific. Or to put another way, maybe that isn’t enough to accommodate human player at a table. While that objective solves the spatial issue, for instance, it doesn’t solve an issue like usability – ease of moving pieces – for instance. In a test version, I used paper and it was difficult to move paper pieces around since they are so two-dimensional.
Objective 3: The product needs to accommodate human players at a play area of 36″ x 48″.
I suppose I could keep going and describe all the restrictions of the human player which would need accommodating. For instance, stating that it is assumed that they will have two functioning arms and five fingers on each hand (or that they will not be visually impaired, etc.) but that seems unnecessarily exclusionary. However, this seems to suggest that all human players are the same? But then again, games typically just suggest age range when it comes to players so what is it I’m trying to get at here?
I suppose what I’m getting at is that Cryptiquest, which has a goal to “Think inclusive and welcome diversity”, doesn’t currently have a guideline for how to approach that with physical components in a game. That should be a tool.
Tool 3: Guidelines for Inclusive Physical Components
Now the objective can be rephrased as:
Objective 3: The product needs to follow Cryptiquest Guidelines for Inclusive Physical Components.
While I’m thinking of it, I want to add the other Cryptiquest values that apply. “Invent unique, believable worlds of fiction” does not apply here. But “Design for experience-first” ties into Objective 3, so I think that’s covered.
There is also a matter of legal – protecting IP. The resulting components will definitely be considered IP. I can copyright graphic elements but any processes or physical components would need to be patented, I think – which is way outside my budget. That doesn’t that they aren’t important to Cryptiquest. Just have to plan accordingly.
Objective 4: Ensure proper steps are taken to protect Cryptiquest intellectual property.
To help with Objective 4 – for every project – I should create some sort of guideline for achieving this.
Tool 4: Guidelines for protecting Cryptiquest IPs
Okay. I think that sums up the objectives and tools for this project. Or at least, it’s a good start. Let’s take a look at the final outcome:
Goal: By the end of this project, I will have a product that I can use for testing future mechanics of CQ StoryHammer.
Objective 1: The product needs to be future-proof.
Objective 2: The product needs to enable testing of zone configurations.
Objective 3: The product needs to follow Cryptiquest Guidelines for Inclusive Physical Components.
Objective 4: The project needs to follow Cryptiquest Guidelines for Intellectual Property Protections.
Tool 1: Definition of Zones
Tool 2: List of Zone Configurations for Testing
Tool 3: Cryptiquest Guidelines for Inclusive Physical Components
Tool 4: Cryptiquest Guidelines for Intellectual Property Protections
Next up: Tools for Measuring Objectives. This has mostly been complete as most of the objectives have tools except the first. So, let’s look at that now.
The product needs to be future-proof. How do I measure this? The project needs to be agnostic regarding setting and “mission” and it needs to be made with components that are easy to change or update in the future. For example, if the pieces need to be scaled smaller, it shouldn’t take longer than a two-week sprint if necessary. This sounds like two objectives.
Goal: By the end of this project, I will have a product that I can use for testing future mechanics of CQ StoryHammer.
Objective 1: The product needs to be setting and mission-agnostic.
Objective 2: The product needs to be made with a two-week time-frame for major upgrade.
Objective 3: The product needs to enable testing of zone configurations.
Objective 4: The product needs to follow Cryptiquest Guidelines for Inclusive Physical Components.
Objective 5: The project needs to follow Cryptiquest Guidelines for Intellectual Property Protections.
Tool 1: Definition of Zones
Tool 2: List of Zone Configurations for Testing
Tool 3: Cryptiquest Guidelines for Inclusive Physical Components
Tool 4: Cryptiquest Guidelines for Intellectual Property Protections
With that, objective one has now become two objectives which are measured by Boolean checks. During the next session, I will be establishing the deliverables for this project.