Identifying Objectives

Identifying Objectives

Greetings!

Let’s talk about goals and objectives. In the last update, I introduced the reasons for creating this story and in this update I’m going to translate those reasons into objectives for the story. Again, for the story, I could (in theory) write about anything, so it helps to have some constraints in mind.

This is a lengthy one – let’s get to it!

Based on the last update, there were a few reasons for writing a sample story. To remind you, here they are in bullet form:

  1. Rule examples are quicker to develop when a reference exists.
  2. A story would help illustrate how rules and templates apply to end product.
  3. A story is more accessible than rules – making this project easier for audiences to absorb.

Those are the reasons to create the story, in a nutshell. But something seems a little off about these reasons. They are a bit arbitrary. Why did I choose these three? For instance, why have Item 3 when it doesn’t really affect development?

Ah. Well, it turns out each of those reasons apply to different types of stakeholders:

  1. For me, rule examples are quicker to develop when a reference exists.
  2. For players, a story would help illustrate how rules and templates apply to end product.
  3. For outsiders, a story is more accessible than rules – making this project easier for audiences to absorb.

For anyone reading this that isn’t familiar with the term, a stakeholder (in project management terms) is anyone who may potentially be affected by the project. I think the first two (me and players) are obvious (me, as the developer, and players as users of the system). The third bullet refers to “outsiders” meaning anyone who isn’t a player – this is an umbrella term to include everyone who is not “me” or a “player”.

In stakeholder-terms, the outsider includes friends and family who support me even though they’re not familiar with what the heck I’m doing. It includes strangers to the project who might be experienced gamers looking for something like CQ StoryHammer. It also includes strangers to the project who have never played a role-playing game in their life. The outsider is someone who – for whatever reason – is not in-the-know when it comes to CQ StoryHammer. They are not insiders, they are outsiders.

And that leads us to our first objective, the story needs to pull people in – increase the chance to turn outsiders into insiders. Translated, our first objective looks like this:

  • Needs to be engaging and fun

Great. That works. Typically, objectives should be measurable and able to be tested – so at the end you can measure success based on whether the criteria was met (i.e. “Does this project meet this objective?”). But I’ll worry about how I tackle that after I’ve created my list.

Since I want to maximize my chance of turning outsiders into insiders, I want the story to end in a way that seems to invite readers to do just that. There a couple ways to do this – cliffhanger, call-to-action, “Choose Your Own Adventure” style gimmick, etc. However this manifests isn’t important at this point, I just know I need to do that. So here’s the next objective:

  • Needs to have “invitation” ending

Okay, good start. But before we move on, I want to back up for a bit – not too far. Just back to stakeholders. You see, there are two more stakeholders that I had forgotten about. They aren’t people but they are affected by the story and will require certain constraints just the same. The first, um, entity that is a stakeholder is Cryptiquest, LLC. Cryptiquest, the company that is producing the CQ StoryHammer game system, has rules about the types of content it produces. We’ll tackle that in a second. The other entity that is a stakeholder is the CQ StoryHammer brand itself. That might sound odd, but it makes sense if you think of what type of stories I’m trying to develop this system for. During the last update, I explained how a story about a pigeon trying to roost on an overcrowded statue would not fit the scope of a CQ StoryHammer story – and that’s true. So, we’ll need to set up some guidelines of what exactly IS a CQ StoryHammer story in order to prevent such a thing from happening.

But let’s get those Cryptiquest stipulations out of the way first. It’s fairly straightforward anyhow. Right on Cryptiquest’s home page, it explains three values: invent believable worlds of fiction, design for experience-first, and think inclusive & welcome diversity. So, here’s how that plays out in bullet form:

  • Needs to be unique
  • Needs to be believable
  • Needs to consider the reader’s experience (above all else)
  • Needs to be inclusive to audiences

Again, once we have the complete list, we’ll modify these objectives so they are measurable and testable. We have some more objectives to create. For the CQ StoryHammer brand, for instance, we have to think about how to weed out stories that don’t apply. Let’s do that now.

CQ StoryHammer game system is designed for any genre or setting. That makes creating a single story as a reference a challenge since we don’t want the setting in this single story to give the wrong impression. We wouldn’t want to write the story about a star ship crew, for instance, since it would imply that CQ StoryHammer is for science fiction genres or for spaceship settings. Not that this genre and this setting are poor, it’s just limited compared to what the system is designed for. We don’t need to come up with the solution now, but we need to add objectives for it:

  • Must not be genre-specific
  • Must not be setting-specific

So, these two objectives are important but they do little to weed out bizarre stories about pigeons and statues. CQ StoryHammer games are about adventure and journeys. And due to the nature of role-playing games, they are designed to be independent of characters, that is to say, that the world would exist and antagonists would carry out their plans regardless of who is/are the protagonist(s). I’ll jot those down:

  • Needs to have a journey
  • Needs to be an adventure
  • Should be plot/villain pushed (i.e. not protagonist-centered)

Okay, you might have noticed, but two of those objectives contradict other objectives (e.g. “Needs to be an adventure” vs. “Must not be genre-specific”). But that’s why we have our reasons at the top – to help us prioritize these objectives. But I’m getting ahead of myself. For now, we’ll keep them there.

Last thing to look at is our original reasons for the story. Here they are as a reminder:

  1. For me, rule examples are quicker to develop when a reference exists.
  2. For players, a story would help illustrate how rules and templates apply to end product.
  3. For outsiders, a story is more accessible than rules – making this project easier for audiences to absorb.

We already addressed number 3. Numbers 1 and 2 are similar enough that they can both be addressed with the following objectives:

  • Needs to be conducive to rule examples
  • Needs to be conducive for templates

And that’s it for the objectives. What we’ll do in the next update is look at this list, prioritize the objectives, make them measurable and brainstorm story ideas that fit all the criteria.

Here’s a list of all the objectives:

  • Needs to be engaging and fun
  • Needs to have “invitation” ending
  • Needs to be unique
  • Needs to be believable
  • Needs to consider the reader’s experience (above all else)
  • Needs to be inclusive to audiences
  • Must not be genre-specific
  • Must not be setting-specific
  • Needs to have a journey
  • Needs to be an adventure
  • Should be plot/villain pushed (i.e. not protagonist-centered)
  • Needs to be conducive to rule examples
  • Needs to be conducive for templates

See you on the next update!

-Luke

 

Oh! One more thing…

One major design objective that is considered important (especially by marketers) is the “target audience.” By identifying the group of people who most likely would consume your product, you can build a profile of that consumer and then make design decisions to further entice that group. In doing so you could increase the odds of that target audience flocking to your product.

For example, I could assume that the age most likely of a person who would consume a CQ StoryHammer game would be in the age range of 16 to 29, that they would have money to spend on gaming supplies, that they might have a propensity to turn to escapism, and then I could cater the story so it appeals to a 16 – 29 year old gamer who has a propensity to turn to escapism. Easy, right? Eh… maybe.

I could assume those things (and more) but I find this practice to be chancy-at-best. This method runs the risk of coming off as disingenuous, but that’s not the worst part. Thinking in terms of profiles is to cater to a stereotype which runs against a core value of Cryptiquest’s value to “think inclusive and welcome diversity”. Besides, the goal here is to invite outsiders to become insiders while not pushing away the insiders, right?

So, forget thinking in terms of “target audience.” The priority is to support the project, not the audience. Instead, let’s think in terms of building something cool, and again – inviting those outsiders inside.