While we were discussing a simple flow of ‘gameplay’ for the portage game I noticed something that I thought would require some testing. Since our game is all about a journey from the left side of the game world to the right side, the player must ultimately travel in such a manner but also needs to bring their canoe with them. We want to give the player a lot of freedom but practically I didn’t think that it makes sense for the player to carry the canoe in the left direction. If this example is transferred to the real world, with a person on a portage trail heading in a single direction, they wouldn’t want to be carrying the heavy canoe if they ever wanted to briefly go back in the other direction. Once I had established this problem, I went ahead with some testing.
I chose to use the program Pico 8 which is a simple console for code, sprite and sound editing. The reason for my choice is because I was familiar enough with it that I was confident I could quickly put together a script with some assets that would appropriately represent the test.
My first thought for how to solve this practical problem was to simply inhibit the player from being able to move left while holding the canoe, thus encouraging the player to drop the canoe if they desire to go backwards. Below is a demonstration of how this control set up plays.
I gave this demo to another class member not in our group to see their response and get their feedback. (Idea Development Sketchbook Pages 14-15) They did eventually work out the reasoning behind the inability to move left but ultimately felt that it was too restrictive and that it should be set up so that the player will make the choice to drop the canoe through the game mechanics. I took this advice on board and devised another solution.
The change with this version is that player moves much slower when carrying the canoe than when they are freely walking around. To test how players react to this change I had to change the prototype slightly to incentivise the player to move left once they have walked a certain distance to the right. I did this by adding an invisible trigger that spawns a bright yellow square behind the player as shown below. Of course, the square doesn’t do anything except disappear when touched but it is just there to represent a point of interest that the player might want to interact with.
I gave this version to a few people to test but the results were not quite what I was hoping for. While some people did drop the canoe to go back for the yellow square, a lot of people of didn’t. I believe the reason for this was down to how the prototype was set up and how it disclosed its features to the player. I went back again to make a few more tweaks to the prototype so that it would be more intuitive.
The core mechanics of this version are the same as the previous one but this time I set it up so that the player learns each feature one step at a time rather than all at once. The reason for this was so that they have time to process each thing that they are being taught, for example I changed it so that the controls are only shown to the player after they have had time to test each one individually.
As shown above, only the movement controls are shown and available to the player at first; once they have moved a certain distance to the right the next control is shown and they are able to pick up the canoe. Following that, the control to put down the canoe only shows when the canoe has been picked up, prompting the player to test this ability straight away. So in recap, first the player has to learn to move and acknowledge the speed; then they are prompted to pick up the canoe; and once they have done this they are prompted to drop the canoe. Having the prototype set up in this was makes sure that the player properly understands it before they even get to the part that we are testing for. This process can easily be translated to our finished game in that we can stagger the reveal for each of the controls. So in trying to test one mechanic, I accidentally learnt another very important design flow.
The last part of this prototype was the same as the previous but I expected to see a better result from testers now that the beginning was more streamlined. Fortunately, this was the case and everyone that I got to test it dropped the canoe before going back for the yellow square.
The aim of this prototype at first was to test a way to make the player not carry the canoe to the left, it then evolved slightly to focus on making this mechanic less restrictive but also intuitive and I believe we achieved this goal. Also while doing this we learnt an elegant way for teaching controls to the player so this process was definitely a success.