July 21, 2016

How to Create a Stealth Action Puzzle Game in Storyline 2

In this post I wanted to describe the design and development process of my submission for ELH Challenge 137 - a remake of the computer game Hitman Go (if you haven't played the game, consider looking at this gameplay video on YouTtube). I'm going to outline some pre-history of the project, describe my design process and what was going on in my head, what I spent time on, which elements of the submission had what reasoning behind them and why, as well as talk about the actual development of the module in Storyline 2.

The 3rd level of Catman Go (working title)

Background


I started experimenting with this idea a while ago, aiming not to think about the visual design and focus solely on the technical functionality. I also wanted to try and make a board that would scale or scroll (like in this great example by Rais Omar) and the game piece that could be dragged. If you're curious, click here for a published slide from my original experiment.

Although I learned a lot and I was happy that I did this experiment, it turned out to be too much work for a "stupid side project", particularly when it came to designing an elegant solution for preventing the player to drag the piece straight to the exit. Thus I shelved it and made a mental note to come back to it sometime later. Thankfully, ELH Challenge helped me revisit this project and implement the things I learned in its new version.

For the Challenge, since wanted to have a finished product without too many shortcuts, I decided to narrow down the scope of my creativity and cut down the number of features. Specifically, I decided to get rid of dragging and dropping and abandon the idea of a scroll-able board.

Design 

I started my design process with a research. Essentially, I did a lot of image searching in Google, Dribble and stock image websites, to saturate myself with images of game boards and screen-clipped anything I liked into OneNote.

With this done, I started designing the layout of the largest level in Inkscape (a free open-source alternative to Adobe Illustrator). Since I abandoned the idea of a scroll-able board, I needed to know how much real estate will be occupied by the essential elements: fields, pieces and goal tracking.

With two levels compared, I had an interesting problem of having too much real estate on the first and just right on the last level. Therefore, I needed something to fill the void on the first level without breaking the unity of the overall design. After playing around with various wild ideas, I settled on the design that used the field grid from the last level with the extra fields being clearly unavailable. I achieved the effect by making the fields semi-transparent and removing the gray connectors between them.

As a side-note - while the need to have fields and pieces is quite obvious, you might wonder why goal tracking was important in such a simple game. Well, when playing Hitman Go, it took me approximately 10 or more levels to figure out where I can find the level goals... Since I consider myself a person of a reasonable cognitive ability, and I only had time to create three levels at most, I needed to make sure that my users don't miss the goals. In addition, as you probably know, it's a good instructional design practice to keep the task visible or within an easy reach of the learner.

With all the elements created and arranged into the final level layout, I used Palettable to create a color-scheme matching the mood of the game, which I then applied to my design. Well, technically, I came up with 4 color schemes and engaged my family and friends to select the ones they liked.

The logic behind the final coloring was this:
  • Movement (beige) - the fields themselves and circles along the path
  • Direction (gray) - the connectors between fields
  • Focus points (black) - the cat itself and the arrows indicating the lines of sight
  • Goals (white) - mice and goal text
  • Background (blue)
Surprisingly, I spent quite a lot of time choosing fonts for an interaction that has a minimum amount of text. Below is the original font line-up I was choosing from (as well as an example of an alternative color scheme):

Early font candidates

I discarded all the fonts that looked too straightforward/elegant/boring for the context of a game fit for a kid (such as Raleway). Then I discarded the fonts that looked hand-written (e.g. Apple Boy) or were too elaborate, since, in my opinion, they did not agree well with a precise and geometric design of the game board. The final candidates were Perfograma and Showcard Gothic. As you can see, Perfograma looked cool but still too sophisticated for a game like this - not fun at all:

I think it wants to spell "No fun allowed"

In comparison, Showcard Gothic was definitely winning the battle, particularly when paired with another font (in this case - GrilledCheese) and a little sad face:

Nothing says "fun" as a sad face, right?

Development 

To avoid recreating all of the elements in the Storyline, I exported them from Inkscape as .png files instead. While a time-saver for development, it is definitely a time-sink for any future changes. For example, if you use one and the same image for 20 objects, Storyline does not let you replace that image with one click (unlike Captivate or Construct 2, which store images as global assets rather than individual objects) and you have to replace every single object (unless you want to mess around with the published output to replace the images there, or resort to other hacks). Do this only if your art is too complex to be created in Storyline, or if you're really sure that nothing is going to change in terms of colors or shapes.

Since I designed all my levels in Inkscape, I knew exactly how the end project would look like, therefore I started with the biggest level and worked backwards from it. This way, instead of adding more triggers I had to delete unneeded objects and then delete any triggers with "Unassigned" values in them. The rest of the triggers I simply adjusted to match the demands of the level.

Let's take a look at how a level is built.

Objects


Each field is an object with three states, as you can see below:


By default, all fields are set to "Disabled", except the fields into which the player can move. This was done to ensure that the player doesn't just click on the "Exit" field from the start.

Every field had a number assigned to it and reflected in its name on the timeline. To keep my sanity and make the development and testing faster, I added a separate layer with the field numbers to serve as an overlay:


I kept the numbers consistent throughout the module, which helped me greatly in reusing the triggers. The only difference is the Exit field, which is always 99, as it had a different set of triggers.

The mice are separate objects. I thought about adding them to button states, but decided that this would complicate an already complicated system and added them on top of playing fields instead. The mice have the same numbers as the fields they are standing on.

Variables and Triggers

Technically, the game uses only two types of variables: one variable to track the currently active field and a true/false variable to track the state of each mouse. Here's the list of variables actually used in the module:



The variable "FieldSelected" changes when the player clicks on a field to move the cat. For example, if a player clicks on Field 12, the variable value is set to 12. The same trigger was added to mice as well, as otherwise the player would have to click the areas around the mice. For mice, however, you need to make sure to add a limiting conditions to the trigger, as otherwise players can click on each mice whenever they want:

Mouse can be clicked only if the field it's on is enabled / active.

Alternatively, you can set the mice to state "Disabled" and create triggers to enable them, based on the value of "FieldSelected" variable. This way you'd have to make more triggers, but on the upside, the player won't be able to see the "hand" cursor when the cursor hovers over the mice.

In order to enable/disable all buttons correctly, you need to write two slide triggers for each button:
  • Change field state to "Normal", if the value of the "FieldSelected" variable equals to the value of the nearby fields.
  • Change field state to "Disabled" if the value of "FieldSelected" does NOT equal to the value of any nearby fields. Note that in this case, if you need to have several conditions, the logic should be AND, not OR.
For example, in the situation below, Field 13 would only be enabled if "FieldSelected" equals 12, as Field 12 is the only field from which a player can reach field 13:

Playing fields

Consequently, if "FieldSelected" does not equal 12, Field 13 should be disabled.

For each mouse, you will need to create three triggers, following this example:

Mouse triggers

Essentially, you need a trigger to interrupt the gameplay if the mouse is not dead when the player moves to a field it's observing (in this case, field 11). Secondly, you need a trigger to "eat" the mouse (variable MouseDead = true), if the player sneaks up on it. Thirdly, you need a trigger to hide the mouse once it's been "eaten" (variable "MouseDead" changed to true).

In other words, you'll need two triggers per each field to manage its states, one trigger per field to adjust "FieldSelected" variable and three triggers per mouse to interrupt the gameplay or manage the state of the mouse.

Final Touches

I was listening to Cat Purr Generator while working on this example and I wanted to add some of that ambiance to the game. I didn't want to spend a lot of time on looking for matching royalty-free soundtracks, therefore I decided to limit the audio to occasional "feedback" sounds: a meow when the cat eats a mouse, a hiss in case of failure and a content purr at the end of the level.

Lessons Learned

  • Set a clear and manageable scope for your project.
  • Design for largest and smallest amount of elements on the screen.
  • Start development with a very clear goal in mind.
  • Work from hardest to easiest (may not always be true, but applies in this case).


2 comments:

  1. Great job! I always enjoy seeing cool things people create, and its especially nice when someone tells you HOW to do it! Thank you!

    ReplyDelete
    Replies
    1. Thanks, Karen! Glad to hear you liked it. :)

      Delete