SECRET KEEP - Designing the Scenario System

I spent rather a lot of time just trying to tackle the whole nature of how to present the story, the scenario, the missions, etc.  I thought I'd make a post just about that, as it's been the cause of a long absense from actual hands-on coding in the project!...

Q: How does the player choose missions?  

Q: How do they get a sense of where they are "up to" in the story, or in the world?

Q: How is progress shown and measured?

Q: What's your relationship with each faction?

Q: Is there a world map, and where are you on it?  Is it literal, or abstract?

There are honestly tons of questions, and I've just dabbled so far, and I really don't know the final answers to most of these things!

But it has helped me in thinking about how the Scenario System needs to work, both in the backend, and how it needs to come forward and present to the player in the front end.

I thought I'd post a bunch of my sketches and scribbles along the way, mainly so I can look back on them here and remind myself of my ideas and ruminations!  :D

This was the old Mission Select Screen.  Overall, I don't like it much!

And in reality, most of it was just a mockup of text and images, and didn't actually DO anything.  The different missions themselves didn't even do anything, but loaded into a random "blank" level.  

But I do kinda like how it shows some broader context, like your own attributes, reputations and relationships.

It was now time to actually get this thing working!  To have different missions the player can play, and also to show the world changing in response to their choices and actions.

So...  I started to churn through tons of ideas about how the story and missions could be presented to the player...  How would they choose between missions?  Would would they sense progress?  Would things be divided into "Chapters"?  How would objectives work?  What would be the different types of rewards for each mission?

I decided to make a kind of Mockup Scenario, to move things from the abstract into a specific case study.  This can generally help to think things through more clearly, with specific goals and limitations in mind.

I started to play around with how the Mission Select UI itself should be laid out.  How should the info be arranged?  How would it fit in the screen?  What sorts of Progress Bars or Mission Type Icons, or Reward Icons would make sense?

I kept playing with ideas for icons, to make things easier to understand.  

After all, in many ways "The interface IS the game".  And the player needs to understand things in a fun and intuitive way.

I started to think about the screen flow, and how it's all flow together.  I still wasn't sure whether I'd want things divided into Scenarios, then Chapters, then Mission, and how it'd all fit together.

I started to collect some fonts that were free for commercial use, that could work with the game.  I tried them out in different contexts.

I wanted to make the Mission Select screen, and have the layout make visually and logically before actually implementing it.  It turned out later, I got rid of this version, and stripped my whole Scenario Design back even further!  But this was all involved in the path moving forwards.

So I came up with this mockup of the Mission Select screen, which would indicate the player's overall progress in this Chapter.  They can select Missions from the 3 provided, each with a different Mission Type and Victory Points value.  Click on to see the details on the right hand info box.

I decided I needed a more detailed example Scenario Story example to actually think through what my needs were for how to actually tell a story, but also support branching and a "storylets" approach.  

I still needed to figure out how Chapters would work, and how I'd try to make it clear to the player what the overall story and trajectory was about, even when they just found themselves in the middle of it all!

I don't think I've actually figured these things out yet, in reality!  But this is all part of the process to getting there.

I find I need a good big bench space when working on these sorts of things!  Need to cross-reference and cross-correlate all my notes!

Trying to define the range of mission types I want to support.

Thinking about pacing of the chapters, how many missions are in each.

What would give a good feeling to an overall story arc?

What if mission objectives were more like "Bingo", where you have a range of objectives, and need to tick them all off, in any order?  

This is how Thief: The Dark Project works.  You can have numerous objectives, and tick them off as you get to them.  I like this format.  This led to more like what I've ended up with, down the track a way.

I realised I'd sort of lost track of my prior convictions and ideas, which was to have a more broad "Library of Missions".  A database of missions that can "come to the surface" as the player acts through the game.  

I realised that my current design thinking was perhaps a bit too rail-roaded, a bit too specific and kind of fragmented.  Not open enough.  Not general enough.

I realised I actually needed to get simpler and more atomic, in order to make it more versatile and more powerful.

I also took a beat to think about the player, and their ultimate perspectives.  

Why are they buying the game?  What do they want to get out of it?

What are their criteria for happiness and satisfaction with the game, and with the story and the missions?

What is their experience of getting the game, and going through the main scenario, and also perhaps delving into user made content, or even making some themselves?

What kind of value do I need to provide?

Thinking about what makes up a cool campaign.  

What would I expect from the main campaign if I was the player of this game?

I started thinking about how it all needed to fit together, in terms of how the screens appear to the player.  There would be mission select, and little intros and outros (of text) at times, and playing the missions themselves. 

This was all really part of "boiling down" the idea to its simplest component parts.

I was thinking about "Groups" or "Chapters" or little chunks of missions.  Here, I think I was still stuck in an earlier idea of how to have missions trigger other missions, and I was thinking about it in a fairly fixed way, creating structures and ideas that would serve my needs, but actually in a way that was overly complex and finicky.

I later boiled this down to a more generalised system of having variables and tags, and checks and changes, that could be applied to achieve the same things, but in a much more open and general-purpose way.

At this point, I had tens of pages of notes, and multitudes of ideas bouncing around.

I made a reference board of some of the key stuff that I kept finding myself wanting to reference.

I kept wanting to know:  What are the mission types I want to support?  What are the factions I have models for?  What is my example story arc?  How would the objectives system look in a mission?

This was my mockup story arc I was using to think through the shape and needs of the scenario system.  This really helped me to work through what was really needed, and was vital in boiling down and removing complexity that wasn't needed in the system.

Thinking about what elements would be needed in the Mission Data.  

After having my mockup scenario idea, I kept trying to think about what that structure really was, and what it needed behind it to work.  I think this was the stage of my workings where I started to realise that I didn't need to strict concept of "Groups" but instead to go more atomic with variables and tags that could mean anything!

Thinking about how the screens would be presented to the player.

This is where I kinda went back to the drawing board. I wanted to go "full storylets", and have a more generic, open system.  

I would need a scrollable list of "however many missions happen to be open", rather than being limited to "3 missions available at a time".

And I recalled a system I'd made previously for a Tile RPG game called The Age of Nothing, which had quite an open Quest System, that used Checks and Changes and acted on a table of variables to track basically "whatever I wanted".

This system had worked well, and really had many similarities to the Storylets Scenario System I wanted for Secret Keep.

I asked a few of my programmer friends if they'd be up for giving me some advice, to talk over where I'd gotten to with my Scenario System plans.  This was a great idea, and it lead to a few big benefits!

I got into Diagrams.Net, and plotted out my whole system of data and logic in more detail, so I could present it to my coder friends.  This process in itself was very helpful!

And then chatting it through with multiple programmer friends, I got excellent insights and advice into what looked fine about my plans, and where there were some issues or improvements or simplifications to be made.

It also lead to some chats (and more research) into the differences and benefits of Scriptable Objects versus normal Monobehaviours.  I'll probably end up using a mix of the two, in different places.

I finally got down to it, and delved into the Unity project, and ended up implementing most of the core features of the system over a few days, and it worked great!

Once I had a solid plan, for a nice generic system, it came together fairly smoothly, and I was really happy with how it came together.  There's still more to do on it, but I think the foundations are good!

I also thought back to another game I've made called B-Grade Renegade: Race to the Rocket, and how the randomly generated missions work there.

It's actually a pretty cool system, where the player can choose between 3 mission each turn.  Each mission has an Objective Type, a Reward value, and also a Perk in the area, and a Distance travelled by taking that route (with your travel distance being important, as the game is a race against the clock).

I'm really happy with how that system worked, because there were many dimensions to consider each turn, with perks such as "well paid job" or "find cars here" or "there's a shop on the other side of this mission" being things that might be really valuable to you at the time, or not valuable at all, depending on how you're doing in the game.

So these factors all weigh against one another, and factor in differently depending on your current situation, such as:  Do you already have a car?  Do you have money to spend?  Do you need more supplies?  Are you low on health?  Etc, etc!

These are all things I could consider further for Secret Keep, somehow!

I also listened to a good Harvey Smith interview, talking about the design of Dishonored 2, and ways of thinking about the Core Abilities of the player, the essence of what the game is about, and how that can change going from Game 1 to Game 2, and various other things.

This is something I should think more about for Secret Keep!

An example of what Mission Data will be needed to define a mission in full.

When thinking about how to get the actual Objective Types working, I've had to stop and really think about how missions will be generated, how an objective will be "set up" in the world, and how it'll be "checked off".  

This is all done dynamically, so it needs to be able to take its cues from the Mission Data, and sort of "take care of itself" without any designer-hand-placement.  

So this raises big questions about how much info the designer will actually specify in the Mission Data, and what this data will look like.  How vague or specific can it be?  What's the interface and data actually look like for specifying these things?  All a big work in progress.

I quickly moved from my paper spreadsheet to a digital version, and things started to grow and shrink and get complex!

The main thing I needed to learn from this was what generalised variables I could use, across all mission types, to get the ball rolling, so I could actually start implementing ANY of the objective types.

So I've made an actual start on the Scenario System, in the project itself!

There is Scenario Data, Mission Data and Rules, with Checks and Changes used across them.

It's a nice generalised, atomic system, that is versatile and powerful.

I've also implemented the in-game Objectives Dialog Box, which shows your objectives and their current status (complete or not complete).

I've only implemented 2 objective types so far, one of which is sort of just a placeholder "Find the Flag" objective.

I still need to implement at least 2 - 4 other objective types, which are more complex, and depend on me doing some other work first.

Working through this process, it really makes me realise, even though I've released many games, there's just so much to learn and tackle when designing and programming games!

Each new challenge can be so huge and daunting.  And progress is very slow when combined in with all the other parts of my life!  

It's nice to look back on a process like this and see the progress, and enjoy seeing it come together.