This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The first type is the fighting event. When this event occurs, the players will be presented with a scenario where two of the factions within the game, are fighting each other. It is then up to the players to decide whether they want to leave them alone, or if they would like to assist them. If they want to assist them, they have to choose their side. If the players are already friendly with one of the factions, they might want to assist that faction again. This choice is completely up to the players.
The other event type is memory based. It is an event that is based on previous events that the players have completed. The event is special in that it is based on previous data. If the players visited an island controlled by the Highbournes, and they used some special healing on one of the options, then the special event could say something like "The highbournes saw you at the island, and want to learn how to use your healing magic". It is then up to the players to decide whether or not they want to help them, or not. Keeping in mind that their current standing with the faction will influence the outcome of whatever option they choose.
The other event type is memory based. It is an event that is based on previous events that the players have completed. The event is special in that it is based on previous data. For example, if the players visited an island controlled by the Highbournes, and they used some special healing on one of the options, then the special event could say something like "The highbournes saw you at the island, and want to learn how to use your healing magic". It is then up to the players to decide whether or not they want to help them, or not. Keeping in mind that their current standing with the faction will influence the outcome of whatever option they choose.
\subsection{Winning or losing}
At one specific point on the map, there is a goal island. This island is the one the arrow is pointing towards, and is the one that the players are supposed to head towards in order to complete the game, and win.
@@ -127,48 +127,40 @@ \subsection{Modifications for testing purposes}
Earlier prototypes showed that the game was not ready to provide relevant results about its experimental purpose. Therefore it was decided to alter the prototype with a few modifications in order to obtain the necessary results. The players were intentionally left unaware of some of the modifications.
\subsubsection{Map layout and goal}
Originally, the map should have introduced a mechanic based on \textit{interest points}. The players should not have to only reach the final island on the map to win the game, but explore the Archipelago in order to find three specific islands before going to the final island. The players are informed at the beginning that each island contains a special artefact that they need to collect and return to their king. The islands should have been possible to localise thanks to clues gained in some special events. The intermediary islands would then only be revealed when the players would be close enough (if the island is within the circle showing the range of the next move). First, the provided clues should have been visual, and thus recognizable thanks to a variety of graphical assets, which were not ready when the game needed to be tested.
Originally, the map should have introduced a mechanic based on \textit{interest points}. The players should not have to only reach the final island on the map to win the game, but explore the Archipelago in order to find three specific islands before going to the final island. This mechanic was not implemented in the final playtest, as visualassets providing feedback were not ready at the moment of the playtest.
It was decided to simulate it by indicating the next island to reach thanks to the directional arrow. The arrow only showed a general direction where the island was, and would be revealed with a halo of another colour as the one used for the other islands when the players would be close enough. This would not perfectly reproduce the intended experience, but at least it would simulate the feeling of exploration by trying to find the correct island among others. This difference between the intended experience and the one simulated by the prototype was of course taken into account when analysing the results.
It was decided to simulate it by manually designating the next island to reach. This would not perfectly reproduce the intended experience, but at least it would simulate the feeling of exploration by forcing the players to explore a larger amount of islands.
When the players reach an intermediary island they are informed that an artefact has been collected by a panel appearing after solving the event.
Though in the latest version of the application, there is only one "goal" node that the arrow is pointing towards. For the purposes of having a play test that is lasting an acceptable amount of time, there were not implemented any new goals after reaching the first one. Instead the game is then considered \textit{complete}.
\subsubsection{Special events occurrences}
The special events were a difficult part of the design of the game. It was necessary to have them occurring not too often, so they would always be unpredictable for the players. This is also why they have such particular parameters to be triggered. However, internal tests performed before the final playtest with players showed that the events were not occurring often enough.
Since analysing the reaction of the players when facing a special event, it was decided that some regular events would be pre-made and set to occur at a given turn. To do so, the island would also be set to only generate one location during this turn. Also, two out of the three options offered in the event included in that location would trigger a special event, which would ensure that the players would have to go through it before moving on to the next island. The special events were set to be triggered at least once between each intermediary islands.
\subsubsection{Progression and risk}
Since the special events are a way to increase the risk, and so the difficulty of the game, the problem of the special events not being triggered often enough generated a problem in the game's progressive difficulty. It happened that the layers would literally have very few difficulties progressing through the game, because the risk was not increasing fast enough. To solve this problem, the risk parameter was set to be also altered every time the players would reach an intermediary island.
This altered the experimental purpose of the game, because the difficulty was supposed to naturally increase with the player's progression. However, it was necessary to have more control over the difficulty so that the final prototype could offer more relevant results about the play experience itself, and not only the technical data about the generation of content.
\subsubsection{Using a portable device}
After these modifications, the application was ready to provide relevant data. However, there was a last problem that would alter the data too much to be ignored. This experiment was supposed to test hybrid games as tabletop games using a digital component to enhance its gameplay. Throughout the development of the game, the application was running on a Personal Computer during playtests. It was important for the final playtest to be able to use a smartphone or a tablet as a digital component. This would allow us to gather data of better quality about how intrusive the digital component is in the flow of hybrid games.
Since the original development of the application had been towards a Personal Computer, the scale of all the UI elements were off when it was built to the tablet device. Everything was scaled down and was super small and the text were unreadable. This meant that the elements needed to be enlarged in order to properly supply the users with the wanted looks. At the time of the actual play test, the layout of the app was significantly enlarged, and all the elements were manually fitted to make sure that the players would experience the app in the best possible way, so that the looks of the elements would not hinder the actual gameplay experience.
Since the original development of the application had been towards a Personal Computer, the scale of all the UI elements were off when it was built to the tablet device. Everything was scaled down and was super small and the text were unreadable. This meant that the elements needed to be enlarged in order to properly supply the users with the wanted looks. At the time of the actual play test, the layout of the application was significantly enlarged, and all the elements were manually fitted to make sure that the players would experience the application in the best possible way, so that the looks of the elements would not hinder the actual gameplay experience.
\subsection{Material, Scope and resolution}
The \textit{Material} of the prototype was closer of what players would expect when playing a hybrid game. It was the first time that the game was tested with analogue components made of something than paper, thus changing the tactility of the different pieces. With earlier prototypes using paper to iterate more quickly, the players had shown frustration when not being able to pick up the bits of paper, or losing them. Using cardboard for the tokens would ensure that this problem would not alter the results. As explained above, the digital component was a tablet for the first time. This would help providing the necessary information related to the flow of the game. However, since the port to tablet was made in a very brief time, some problems with zooming as well as fluidity drops when moving the camera around on the map would alter the experience. This problem was explained to the players prior to testing, and taken into account in the final results.
This is the highest fidelity prototype that was created during this project. Although all the visual assets are still place-holders, the prototype uses a tablet as a digital device and that all the mechanics are implemented.
It is the first time the \textit{faction} system and the special events are introduced in the game, and are not tested separately. Therefore, testing those mechanics is the main purpose of the prototype. By testing these two new elements and how they fit in the game, the \textit{Scope} of this prototype covers all the principles previously mentioned all along this paper. About the game itself, a progression in the difficulty must be visible when the players reach the intermediary islands. The difficulty must increase, and the decisions should be taken more carefully. Also, the players must realize that their choices have influenced the game and the generation of content. Finally, the specialization must be strong enough so that the players construct their authority in the game.
\subsection{The Playtest}
The descriptions established in the following paragraphs are based on a transcription of notes taken during the playtest (see appendix \ref{sec:transcript}). After the game, some questions were asked to the testers. This interview was conducted in the form of an open discussion, guided by a few general questions. The observation was audio-recorded, but the playtesters did not give their authorization to join the recording in this paper. Therefore it is not included, but a transcript of the notes taken has been included as an appendix (the names of the testers have been changed).
The descriptions established in the following paragraphs are based on a transcription of notes taken during the playtest (see appendix \ref{sec:transcript}). After the game, some questions were asked to the testers during a short interview. This interview was conducted in the form of an open discussion, guided by a few general questions. The observation was audio-recorded, but the playtesters did not give their authorization to join the recording in this paper. Therefore it is not included, but a transcript of the notes taken has been included as an appendix (the names of the testers have been changed). The observers from the development team were the designer of the game and one of the two programmers.
\subsubsection{Preparation of the playtest}
The playtest has been organized in a place that all the testers know. The testers are game design students who all have some experience with tabletop games (mostly trading card games). Two of the people chosen, had never seen the game before. They are the beginners to who the third playtester has to teach the rules. The third playtester is the only one that has experienced with a previous version of the game: if the specialization system is not strong enough, that player would take a \textit{leader}'s role - which is not wanted. The playtest will start in the normal starting conditions of the game.
The playtest has been organized in a place that all the testers know. The testers are three game design students who all have some experience with tabletop games (mostly trading card games). Two of the people chosen, had never seen the game before. They are the beginners to who the third playtester has to teach the rules. The third playtester is the only one that has experienced with a previous version of the game: if the specialization system is not strong enough, that player would take a \textit{leader}'s role - which is not wanted. The playtest will start in the normal starting conditions of the game.
The players are informed that the application is not completely ready, and that they will have troubles moving the camera around in the map screen. They are informed of the other modifications made to the prototype, except those about the special events and the difficulty progression. Those decisions were taken so that their reactions are as natural as possible when playing.
The players are informed that the application is not completely ready, and that they will have troubles moving the camera around in the map screen. They are informed of the other modifications made to the prototype, except those about the special events occurence. Those decisions were taken so that their reactions are as natural as possible when playing.
The game being a hybrid board game, the players have been informed that they could ask questions to the observers in case they could not find the solution of a problem in the rules. If the observers think that the question is legit and the answer is hard to find in the rules, they decide to give that information and take notes about how to solve the problem.
\subsubsection{Feedback and results}
The observations made during the playtest, as well as the open discussion with the testers showed both the successes and failures of \textit{Archipelago} in the state it was as a final prototype. Some aspects of the game had already identified as safe to build upon thanks to previous prototypes and playtests, and were not the focus point of this playtest. However, the last implementations made in this prototype were created to support the core concept of using PCG to enhance board game mechanics. Several focus points of the observation should be mentioned in this report:
\begin{itemize}
\item The faction system and the special events must support the core mechanics and provide a particular feel. Indeed, one of the interest of using PCG to support board game mechanics is to reuse the players input in order to pass them as parameters to generate later contents. The players should notice this and understand how their actions influenced the game content generation. During the playtest, it has first appeared that the players did not notice at once that they triggered a special event. And when they did, they did not realise that this event was based on actions that they performed earlier. After the second special event however, one of the playtester realised that the faction followed them from a previously visited island. But the name of the island was too abstract to remind them what they did to trigger the faction's reaction. User Interface elements did not provide the necessary information to remind the players what part of the content had been affected by the results.
\item The system progression and risk as it was implemented in this modified version of the final prototype is the one that showed the best results among all the prototype created during the development of the game. The playtest showed that the faction system was not enough to sufficiently and increase the difficulty along with the players' progression on the map. However, modifying the prototype to divide the progression in several sub-objectives provided interesting results. First of all it provided a meaning to the node exploration by adding intermediary goals for the players to reach. Second, it was an interesting element to use in order to inform PCG of the players' progression and generate more difficult events. More generally, this system combined with the exploration mechanic based on islands to reveal when approaching close to them provided another interest of having a procedurally generated map.
\item The faction system and the special events must support the core mechanics and provide a particular feel. Indeed, one of the interest of using PCG to support board game mechanics is to reuse the players input in order to pass them as parameters to generate content. The players should notice this and understand how their actions influenced the game content generation. During the playtest, it has first appeared that the players did not notice at once that they triggered a special event. And when they did, they did not realise that this event was based on actions that they performed earlier. After the second special event however, one of the playtester realised that the faction followed them from a previously visited island. But the name of the island was too abstract to remind them what they did to trigger the faction's reaction. User Interface elements did not provide the necessary information to remind the players what part of the content had been affected by the results.
\item The playtest showed that the faction system was not enough to sufficiently and increase the difficulty along with the players' progression on the map.
\item The system of specialization must provide a support for discussion, as well as an interesting way of developing strategies
\item Whether the application fits in the game flow or not