top of page
Week 10

Phase 4

Week 10

The "Level"

Because the game's experience suggests that this game will be a journey, all talk has been around one level with a start and end. What happens in between this beginning and end will be up to the players to be present in the space and discover what we put there to be discovered. Although it is up to the player to pace themselves and learn to be mindful, it is still up to me as a designer to give the players clues and suggestions that this environment is alive and interactive. 

I work best visually and all this time we have been discussing what the player will be doing. I wanted to place this down onto something tangible that can be looked at and criticised. Hoping to include and decide on where to put the interactions I've been diving deeper into [See Sketchbook 1, pages 19,20]. 

Game Overview

Knowing that the players will be using a canoe and the activity of portage to travel and that because it is a journey the character is one, I could create this basic sketch to storyboard what might be where. This will allow me to keep a record of decisions that have at least been agreed upon that the team would like to see in the game.  Although the artwork should create an illusion to the fact, I am going to refer to the pieces of land that the characters will walk on as Islands. This is so we can start to design with purpose, making clear decisions which Island will have what interaction, where we intend the player to meet certain encounters and other possibilities down the line. 

One thing that we appear to all agree on that there needs to be some form of a tutorial which uses what we learned from the prototype that Alex worked on in Phase 3. With the player beginning in the canoe, and a river current controlling the movement from left to right before the player even begins to control the paddling should indicate there is a direction in which they will be moving at all times. Once arriving on Island 1, players will figure out that they are on an area of land between two rivers, with the current leading them from left to right, they will ultimately have no option than to stay or take the canoe to the opposite side of the Island. Mirroring Alex's prototype, we will include a hard gate that should encourage or force the player to put down the canoe, helping them to understand that movement is much faster while not carrying it. 

Beaching the Canoe

I had a concern about how the players will control the character when coming to land and manipulating where on the Y-axis it can go, or whether they can control that at all. Some things are a given for the environment, like rapids for example, as the game is inspired by portage, which exists because of rough water and rapids. My worry is that with the left to right current constantly moving the canoe at a certain pace, without any clear and concise instruction, or any obvious way to control the canoe, players could end up barreling into the rapids or at least into an invisible wall. It is our intention not to allow paddling down rapids as it is the point to portage, thus exploring on land. Sketching out an example to again visualise the problem...

Encountering Rapids Problem

To keep players becoming tangled up in a place where only introducing extra controls to help themselves get out, me and Alex decided that to fix this issue, while in the canoe, the character will have some core control over the canoe. We don't intend to make a canoe simulator game, so removing some of these elements we feel will remove the player's need to worry over the details of controlling. Focusing more on the pace of the canoe. This lead us to the decision that the canoe will work on a track, always having its Y-axis location predefined as though the character has control of the direction of the journey on the water. It will be up to the player to pace the character. 

1) With the rapids approaching from the right of the screen, there will be a place for the canoe to be beached and portage around the rapids. No matter what the speed of approach the players choose, the canoe will be guided onto land by the character. Then Allowing for the player to exit the canoe. 

2) This is the start of the new path for the players, maybe following the river to join it downstream, or off to another river through the forest. Here they can move more freely, with the possibility to navigate the character on the Y-axis now.

Branching Pathways

Talking about how the players will navigate between river and land ignited a convocation about how the players will navigate on land. A debate on whether there should be forks in the road or not ensued. 

Fork in the Road
The MindFork

There was a lot of difference in opinion whether allowing players to backtrack to see what was down the other pathway was a mindful thing or not. I argued that to be mindful and present is to accept what decision has been made and remain in the moment rather than considering what might have been or what could have been experienced [See Phase 1 Mindfulness]. However, completely restricting the player's movement on both river and land doesn't sit right with me, we want the players to freely choose what to do rather than completely funnelling them through a journey which can end up meaningless for them.  

We came to the conclusion that we want the players to have the freedom to explore, no matter what pathway they choose. And that providing multiple pathways allows for a greater feeling of freedom of choice, especially in a scripted game. However, I felt it was important that the players should experience all the possible interactions scripted in for all the available routes, otherwise there would be no sense of worth. The MindFork is what we are calling the system which will trigger a particular interaction down a pathway, while also disabling the other possible interactions down the other fork pathway. 

All of this needs to be prototyped and playtested but for now, I like this as a compromise. 

The Story

A talk with the guest speaker Jasmine highlighted that our character needs a story and although we might not intend for the audience to know the purpose of the journey or who exactly the character is, we as the developing team need to have a solid understanding of the reason for this journey and root it in some truths. This will help some design decisions down the line by offering a reason for the character to be doing a particular thing. 

We have two storyline options so far. The Delivery Man, or the Outing. 

The Delivery Man - This was the most original idea for the story, in which the character is a courier delivering a package/parcel to a small outpost of hut deep within the forest. This stemmed from the origins of the voyageurs and the act of portage, wanting to give the journey a reason, a purpose. With the ending showing the delivery of the package but not allowing the player to be a part of it or probably even witness the whole thing, to hopefully highlight to them that it was the journey that was important, not the destination. The package might have even been kept secret. This is however probably pointless, keeping something a secret throughout the whole game to only reveal it at the end isn't really the core experience that is preferred. 

The Outing - Rather than giving the character a destination of importance, inspired by online videos of people exploring the wilderness and doing short stays with overnight camps, we like the idea of placing our character in this scenario. Either on their way into the forest or on their way back to the car, this might highlight that there can be experiences on the journey without there being a necessary destination. So placing the player in the character's shoes on their way back to civilisation sounds like a cool idea. 

20191208_210614.jpg

I have also been considering the emotion of the player whilst playing the game. Although the overall experience is to be mindful, there could be opportunities to guide the player into this mindful state using the careful placement of particular interactions along the journey. This was inspired by Kurt Vonnegut's Shapes of Stories which was shown to me in a creative writing class. Considering the popularity of this 'ill-fortune' state of the protagonist, we could implement it into our game but have the beauty of the environment the protagonist and its ill-fortune that triggers emotion in the players. 

Defining the Game

With all the members in the group and a rather long essential experience, we have had to collectively work together to understand exactly what it is we intend to make as an overall game. The visions and concepts that are brought into the mix by four very creative minds can greatly improve the general concept while also causing pauses in ideation.  With plenty of mixed opinions on the direction of the game, we have had to define hard roles for the team to allow for work to continue smoothly. 

Creative Director: Alex || Lead Designer: Myself || Research and Marketing/ Concept Art: Adam || Lead Developer: Jamie

With our roles outlined, Me and Alex are able to focus on the core gameplay elements. We have concluded that the game's concept can be made with a simple core amount of work that could then be called complete. Then, as we progress onwards, we can add in interactions and encounters that should only build upon the core game. 

Being a game concept that Alex has roughly had in the back of his mind for a long time, something I quickly understood and jump on board with, we'd have some early core ideas that are to define the direction. One of these being that the mechanics will be very simple, where the players simply have to trigger instances which play an animation to watch. After reading Fewer Mechanics, Better Game on Gamasutra, I feel this can definitely be achieved with the correct aesthetic and baring the essential experience in mind at all times. 

The Core Concept

Creating this flowchart of the first rendition myself and Alex had worked on was to have in one space, all the expectations for the player. This will allow me to look at the requirements such as animations, sound effects, affordances and where there might be downtime or lack of information. For me, it will be important to discover what the player understands and doesn't understand. So using this flow chart, I can request prototypes for Jamie to develop and work together to make something that is user-friendly. 

This flow chart also gives the game a structure now, something to base a schedule on and to gauge how many extra levels of interactions we can add into this game. Something I have already noticed while creating this flowchart is that it is highly possible there need to be some interactions worked into the game. As Island 3, which for now is required to visually show a transition between the autumn weather into colder, northern weather. 

Gameplay_Flowchart_V1.0.png
bottom of page