Prototyping

Paul (2008) defines prototyping as.

“Effective in demonstrating the subjective attributes of the game such as game-play and pacing without requiring the entire game to be built ahead of time.”

After receiving feedback from Launchpad, I am looking at changing how Red Chandelier is played. One of the areas I will be changing is the clues at the moment they are physical props, it was pointed out to me that this would be hard to sell to potential publishers. Therefore I have made decision to incorporate them all as PDF’s or possibly into a mobile app. Not only will this hopefully make the game easer to pitch in the future but it is also more sustainable, and cost affective as no paper will be used.

Another area that I plan to look into is multiplayer, currently it is a single player game where you solve puzzles to uncover clues that helps you work out who was the murder. I am considering turning it into a multiplayer game. To find out if there is potential, I plan to make serval prototypes to see how the game plays in a multiplayer environment. Currently I have two ideas for this.

The first idea would have the players, play as the detectives, but are unable interact with one and another. they can only contact Control who can contact the other players with information etc. It will not be possible to solve the case alone so the players will need to work together.

The other idea I have would have players play as the following, the detective, the killer, or the guests. Each guest will have a motive so something to hide, they will also know a hidden secret about one other player. This would allow all players a reason to participate.

It is important to consider that currently I don’t have the ability to make them in engine as both will required a programmer who can implement the networking side of the project. However, I am currently prototyping/playtesting the first idea.

Playtesting

Early idea concept

To see how the first Idea would play out I playtested it with a few 3rd years. Mirza-Babaei et al (2016) has this to say about playtesting “Playtesting aims to assist developers to achieve their design intent and help to identify and resolve potential problem areas during development”.
One of the largest issues here is how to make the game fun for all players. There is also the issue of how to make communication work for each player. The Idea of the control was to allow for more concise communication and to ensure that all players know what’s going on. However, it is not necessarily the most fun role to play.

The feedback I have received from playtesting is clear, in its current iteration it is confusing to play. The players were unsure what to communicate to control, and control did not know what to tell people or who to tell it to.
The other issue was who had access to the clues, in this test control was the only person who had access to them but could only access then if a player told them to.

Apron reflection I plan to implement the following changes. Players will now be able to access the clues they find and can decide what to tell control. NPCs will also now be on different floors so can only be accessed by the player on that floor. (Control will not know who is on what floor unless told) Control is now the gather and distruster of information to the players on a need to know basis with control deciding if they need-to-know. To provide more game play to control they will be able to brief players and decide who goes where at the start of any game. I am also planning on changing the way this is explained to all the players to make it clear.

References

Mirza-Babaei, P., Moosajee, N. and Drenikow, B., 2016, October. Playtesting for indie studios. In Proceedings of the 20th International Academic Mindtrek Conference (pp. 366-374).

Paul, L.J., 2008. Video game audio prototyping with half-life 2. In Transdisciplinary Digital Art. Sound, Vision and the New Screen (pp. 187-198). Springer, Berlin, Heidelberg.