1 Introduction

There is still a way to be followed in relation to the inclusion of the visually impaired (VI) public in the game entertainment universe. Garcia e Almeida [15], define the games usually use graphical interface to transmit information to the player. This limits visually impaired people given that the gameplay characteristic of a game can be understood as the nature of interactivity. That is, how and how much the player can interact with the game world, and how this world reacts to the choices the player makes [22]. Therefore, it is necessary that the users can have access to all the information so that they can better interact and make their decisions to face the challenges of the game.

Thus, the design and development of audiogames can be seen as an initiative to include people with VI, considering those they are games based mainly on a sound interface. These games may or may not contain the graphical interface, which in this context is an irrelevant requirement to understand the game, the sound interface should be sufficient for the VI user to play the game. To enhance the user experience, some audiogames use 3D sounds. This kind of sound promotes that the user can perceive various dimensions through the sound interface, creating an immersion environment. Some audiogames use screen reader software, while others develop their own voice synthesizer. There are also those that include the use of haptic interface adapted to the mouse or make use of more specialized features such as the vibration of mobile devices. In any case, audiogames should follow accessibility criteria, which unfortunately is not always the case [2].

Some studies propose the use of heuristics/guidelines for game evaluation and development [2, 12, 13]. However, these do not fully cover the criteria needed to promote accessibility, gameplay, and usability required by audio-based games. In this context, Campos and Oliveira [7], proposed a set of 12 heuristics for the evaluation of audiogames. The study by Borges and Campos [8] presents an initial set of 31 guidelines for audiogames design. These studies were related so that it is possible to carry out evaluations during the development of audiogame. Guidelines are guidance that helps the designer build interfaces with a greater degree of usability [9]. Guidelines have as their main advantage, offering flexible guidelines and assisting in setting project goals and decisions. Guidelines to address a variety of issues, one of the ways companies disclose rules, standards or style guides for the development of their products [9].

Based on these studies, this papers presents Fair Play, a (final) guidelines for the design of audiogames. The guidelines proposed here will serve as an instrument to assist in the design of an audiogame, following good development practices for better usability, accessibility, and gameplay of the game. This proposal was elaborated and validated through diverse research studies, presented in this paper in details.

Therefore, the remainder of the paper is organized as follows: Sect. 2 presents the papers related to this study, Sect. 3 shows the steps taken to consolidate the Fair Play guidelines, Sect. 4 presents Fair Play which is the final set of guidelines already consolidated. Section 5 concludes the paper with lessons learned and final consolidation.

2 Related Work

Although there are studies that propose the use of guidelines for the development of accessible games, these do not focus on the development of games for visually impaired users. Therefore, the related work we present in this section mostly are guidelines proposal for the development/evaluation of accessible games in general, these work served as a reference for the proposal of Fair Play.

Desurvire et al. [12] proposed a set of game evaluation heuristics (HEP) organized into 4 categories, namely gameplay, history, game mechanics, and usability. Heuristics were proposed to be used early in the game design to facilitate design thinking from the user’s point of view. Later, the same authors [13], adapted these heuristics, resulting in a new list (PLAY) that was created to help game developers throughout the design process, particularly at the beginning of the concept phase, when design changes are less costly. The new list of heuristics was grouped into the following categories: gameplay, fun factors/Entertainment/Humor/Immersion, usability and game mechanics. One of the advantages described by the authors is that the PLAY proposal is modular [13]. For example, if a game does not have a history, questions related to this heuristic should be taken from the evaluation instrument.

Yuan et al. [23] reviewed the state of the art in the research and practice of accessibility in video games and pointed out relevant areas for future research. As a disability can affect a player’s ability to use different games, a generic interaction model for games has been defined, allowing identification of the types of barriers faced. A large number of games accessible and research for different types of disabilities and with different genders. They were then classified into a series of accessibility strategies according to their degree of severity between high and low. This helps developers identify accessibility issues in their game design.

A large number of studies (e.g. [1, 3,4,5,6, 10, 11, 14,15,16,17,18,19,20,21, 23, 24]) proposed recommendations for the development of accessible games in general. However, there is no standardization of how they are categorized. Some studies organize the guidelines by level or progression, data entry, graphics, sound and installation/configuration [20, 21]. Others organize by disability, being a user with motor, cognitive, visual, hearing and speech disabilities [18, 23]. Others organize by the severity of accessibility violations [3], while others suggested guidelines based on the of WCAG 2.0 structure [10, 19], being these perceptible, operable, comprehensible and compatible. There are also studies that did not present any kind of categorization [6, 16].

The guidelines proposed in this paper differs from previous studies by, specifically to assist the development of audiogames for visually impaired users and still have principles of usability, gameplay, and accessibility, different from others.

3 Fair Play Creation Method

Fair Play was proposed based on a technique of reviewing the literature called Snowballing, in which studies were identified that have recommendations for games generally accessible. From these, recommendations were selected that could also be applied to audiogames, resulting in an initial set published by Borges and Campos [8]. For the consolidation of this set, 6 stages were carried out, the last two being related to their availability and which are described in this section.

3.1 Stage 1: Data Collected

In order to evaluate the 31 guidelines proposed in a previous study by Borges e Campos [8] (initial proposal) we first carried out two studies (A and B). The goal of these two studies was to verify whether the 31 guidelines would be used to guide the implementation in audiogames projects and the relevance during the development process. Additionally, it was necessary to verify if the guidelines were identified in existing audiogames.

Study A - Evaluation with Audiogames Developers. To assist in this process, an online questionnaire was developed to verify if the proposed set of guidelines could be used by audiogames developers during the construction of their projects. To do this, the questionnaire was organized into 6 sections, which sought to identify the profile of the respondent, verify information about the developed audiogame, to analyze the implementation priority of each of the 31 proposed items, to identify which of the items had been implemented in them projects, to analyze if the items were clear or if there were suggestions for changes, and finally, to understand what lessons were learned during the development of their audiogames.

At the beginning of the questionnaire, it was explicitly described that the respondent should be an audiogame developer. This restriction was due to the fact that the study is interested only in the development of audiogames. The questionnaire was made available in Portuguese and in English.

Results. We collected 8 responses, 6 from Brazil and 2 from abroad. To ensure the confidentiality of the responses, the participants were named from R1 to R8. The average experience of audiogames development reported by respondents was 1 to 3 years, and only two respondents (R4 and R5) had experience in developing games accessible to people with visually impaired of 7 years or older. The audiogames gender varied, from the adventure (R2, R3, R6, R7 and R8), action (R4), experimental (R1), and simulations and strategy (R5). As for the care that was considered to facilitate and allow use by people with visually impaired, most participants reported using diverse audio resources, such as 3D sound localization and sound feedback throughout the game. In addiction, respondents also reported that they use the provision of shortcut keys to facilitate the player’s actions and choices, and other sound resources that aid in the orientation of the player.

We also asked the respondents to prioritize the importance of enhance of the 31 guidelines. The 5 points likert scaled was: “High priority”, “Medium priority”, “Low priority”, “Not important” and “no comment”. Among all the guidelines, some have stood out because they have been considered as “high priority” by at least half of the respondents, such guidelines are: D3, D5, D8, D9, D10, D11, D15, D17, D19, D22, D26, D27, D28, D29, and D30. The guidelines D1, D2, D12, D20, D23, D24, D25, and D31 have been marked as a “Medium priority”, also by the same number of respondents, which still maintains them at a high acceptance level. None of the guidelines were labeled “Not important” by more than 50% of respondents. And for the “no comment” option, guidelines D12, D15, D16, D21, and D27 have had one to two markings. The respondents with more experience in the development of audiogames, had very different results. While R4 considered that 48.4% of the guidelines can be considered as “High priority” and 41.9% of “Medium priority”, R5 considered that 35.5% of the guidelines could be classified as “Not important” and 22.6% as “High Priority”. Thus, taking into account the next most experienced respondent, R1 considered that 48.4% of the guidelines are “High priority” and 41.9% are “Medium priority”. The responses of the other respondents were also analyzed and their highest percentages remained as of “High priority” and “Medium priority”.

Another question asked was to verify if the proposed guidelines were considered during the development of audiogames projects. Of all the guidelines, more than half were “fully implemented” by more than half the respondents. The “Partially Implemented” option was the most used by respondents. In contrast, 13 guidelines (D3, D4, D6, D11, D12, D13, D14, D20, D21, D23, D25, D27, D31) were marked as “Not implemented”, also by at least half of the respondents. For this question, we emphasize that the implementation or not of the guidelines is very variable, since factors such as scope, gender, available platform and experience of the developer, directly influence the execution of some criteria defined in the set of guidelines. For example, experimental games, as in the case of R1, may have a few functionalities and therefore the game do not implement many of the proposed guidelines. In the case of R1, 51.6% of the guidelines were marked “Not implemented”. Of the five respondents who reported having participated in the creation of an adventure game-type audiogame, the average of “fully implemented” guidelines was 56.77% versus 36.77% of “Not implemented” guidelines and 29.03% of “Partially Implemented”. For the other respondents, the average “fully implemented” of the guidelines was 11.6%, against 10.3% of “Not implemented” guidelines and 6.6% “Partially Implemented”.

And finally, the importance of audio in the game, emphasizing that all graphics should be represented, such as soundtracks, sound effects, locutions, and environment were the most lessons learned reported. Sounds should be clearly implemented so that the player has as much information as possible, such as where he is, where he should go, what he should do, and how he can feel the emotions of the characters. Otherwise, the immersion can be broken and the gaming experience becomes understandable for all audiences, whether or not VI. Another well-quoted point was the testing of people with visual impairment during the development of audiogame. It was also mentioned the importance of creating a tutorial and following development guidelines for the creation of audiogames.

Our results indicate that the set of proposed guidelines was well accepted by the respondents, always maintaining an average of acceptance above 50%. However, some of the guidelines should be re-examined to be better described and clearer.

Study B - Evaluation with Blind User with Experience in the Use of Audiogames. The set of guidelines for the development of audiogames was used to verify if audiogames already developed implemented the items of the proposed guidelines. To that end, a user who is blind and who has experience in the use of audiogame was invited to carry out the evaluation of 8 different audiogames. The tested audiogames were: Dark DestroyerFootnote 1, Last CrusadeFootnote 2, Segredo do mosteiroFootnote 3, Tic Tac ToiFootnote 4, Duck BlasterFootnote 5, Cobras e escadasFootnote 6, Snakes and laddersFootnote 7, and Super Mario BrothersFootnote 8. All audiogames used in the analysis are available for desktop only. The Audiogames vary greatly in their game categories they go from adventure to RPG, board, shooting, and action.

After playing each audiogame, the user received the online questionnaire with the 31 guidelines and for each of them, was asked to the mark on a Likert Scale, verifying that each of the 31 items were observed in the audiogame, with the scale of 5 points ranging from: “Strongly Disagree”, “Partially Disagree”, “No comment”, “Partially Agree” and “Strongly Agree”.

Results. For the analysis of the data, a descriptive statistic was used, using the most frequent response for each item of the 31 guidelines. After the calculation of modal, the answer most used for each item was “Strongly disagree”, obtaining a percentage of 62.9%. That is, most of the proposed guidelines were not identified during game use, which is of concern since in that many of them are basic items needed in an audiogame, such as D31, which provides mechanisms to configure the audios and sounds of the game. This guideline was only observed in one of the games, in the Last Crusade. The most guideline identified in the audiogames was the D15, which proposes for games in desktop, that the player can do all the operations of the game by means of the keyboard. Note that all audiogames tested in this step are for desktop and even so, some of them do not provide all their functionality accessible by the keyboard.

Lastly, it is observed how much it is necessary to include in the process of development of audiogames, guidelines, and recommendations for the development because only then, will be generated audiogames with greater gameplay, accessibility, and attractiveness for users with VI.

3.2 Stage 2: Data Analysis

The guidelines needed to be refined based on the results of the assessments conducted in Step 1. In this way, the authors of discussed them in person and modified those that had changes applied for clarity (i.e., D2, D6, D11, D14, D15, D17, D21, D23, D25, D27, D29, D30), grouped by being similar (D3 with D4) and divided to become more specific (D9, D24). Additionally, initially, the guidelines were directed only to blind people and, therefore, items related to the GUI had been disregarded. However, for a better experience of use by people with low vision, items related to the graphics interface were inserted in the present study, for a new analysis. Thus, we analyzed another 51 items that apply to the graphical interface and that generated another category called Graphic Elements with 4 linked guidelines, which were added to the original set, resulting in 35 guidelines (Proposal preliminary).

3.3 Stage 3: Heuristic Relationship of Guidelines

In the study of Borba Campos, Oliveira [7], in which a set of 12 heuristics for evaluation of audiogames was elaborated, it was defined and explained how each heuristic can be applied in an audiogame evaluation. Heuristics contained examples of evaluation issues, which needed to be generalized to make them applicable to a wider variety of games and regardless of the used platforms (e.g. desktop, mobile, and console). Additionally, it was necessary to confirm the association between the examples of questions with the heuristics.

To do this, we performed a process of modification of the evaluation questions, which consisted of the re-evaluation of the 50 examples of initial questions, presented in the 12 evaluation heuristics [7], and in the addition of new questions, with the aim to make them more comprehensive, totaling in 81 questions. From these modifications, we individually, in possession of the definitions of the 12 heuristics, carried out in a first moment, the relation of the heuristics with the 81 examples of questions of evaluation of audiogames. Afterward, we as a group, analyzed and discussed the individual relationships.

Following the same process, we performed the relationship between the 35 development guidelines and the 12 evaluation heuristics. In a group, it was verified that one of the guidelines (D35- Allowing the interfaces and texts to be resized, allowing the player to zoom and pan the screen) was already being considered as part of another guideline (D18). For this reason, directive D35 was unified with D18, resulting in 34 guidelines. Additionally, following the template of WCAG 1.0Footnote 9 the naming of “evaluation questions” has been changed to “checkpoints”. The changed heuristics are described below.

  • H1 - System state visibility: The audiogame should keep the user informed by audio about the relevant actions of the game. Checkpoints: Does audiogame keep the user informed about what’s happening? Can the user know your score/status at any time?

  • H2 - Correspondence between the system and the real world: The audiogame should use a more natural language possible for the user. Checkpoints: Are the concepts used in audiogame comprehensible? Does the game follow trends established by the community of players facilitating their learning?

  • H3 - Control and user freedom: The user must feel in control of the audiogame. Checkpoints: Do you feel that you are in control of the application? Can you save the game? Can you go back to an earlier point in the game? Can you forward audio? Can you rewind audios? Can you adjust the audio speed? Is it possible to adjust the audio volume? Is it easy to return to the beginning of the game?

  • H4 - Consistency and standardization: audiogames should be performed through consistent and standardized actions. Checkpoints: Is there consistency between the control of the game and what do it do? Shortcut keys follow a gaming industry standard, when there? Are the controls the same throughout the game? Is there standardization in the navigation of the menu options? Is there consistency in setting shortcut keys? Is there standardization in audio volume? Does the audio type of the elements remain the same throughout the game? Is the sound interface consistent? Is the graphical interface consistent? Are the vibration features consistent?

  • H5 - Error prevention: Audiogame should prevent the user from making mistakes. Checkpoints: Can the user identify when a menu option is disabled? Does Audiogame disable keyboard keys that are not used during the game? When the user selects the option to quit the game is requested confirmation? Is the user prompted to save the game? Does the game disable options that should not be used by the user in certain parts and moments of the game?

  • H6 - Recognition rather than memorization: The user must recognize what to do while using the audiogame instead of memorizing it. Checkpoints: Are the sounds understandable? Are the effects of vibration understandable? Are the concepts used in the game understandable? Are the sequences of actions to complete the tasks of the game occur properly? Is the menu easy to use? Is it easy to learn how to use the game? Is the information presented easy to understand? Are the controls intuitive? Is it easy to use the game? Does the navigation follow a logic? Is the information presented to the user relevant? Is the menu easy to understand? Are shortcut keys easy to remember? Do the sounds of objects remind you of what they mean?

  • H7 - Flexibility and efficiency in use Audiogame must be flexible and efficient so that it can be used by different user profiles. Checkpoints: Are the game controls customizable? Is the shortcut key sequence easy to use? Are all controls necessary? Is the combination of keys used simultaneously appropriate? Allows efficient use by different user profiles?

  • H8 - Aesthetic and minimalist design: Audiogame should have an aesthetic and minimalist design. Checkpoints: Is the sound interface consistent? Is the graphical interface consistent? Are the vibration features consistent? Are the sounds easily identifiable? Are the effects of vibration easily identifiable? Is the information presented to the user relevant? Is sound quality adequate? Is the amount of sounds adequate? Is the use of the haptic interface adequate? Is the intensity of the vibration adequate?

  • H9 - Recognition, diagnosis and recovery of errors: The user must understand when an error occurs and succeed in re-establishing. Checkpoints: Can the user redo an error? Does audiogame tell you how to get out of an unwanted state? Is it easy to know when an error occurs? Is it easy to know why an error occurred?

  • H10 - Help and documentation: The audiogame should provide help and documentation to the user. Checkpoints: When starting the game, does the user have enough information to understand the game? Does the user receive help information according to the context in which he is in the game? Are the most important options presented first?

  • H11 - Gameplay: The audiogame must have gameplay. Checkpoints: Do audio effects generate interest? Do vibration effects generate interest? Does the game introduces its goals? Does the game have different levels of difficulty? Does the game offer different ways to achieve its goals? Does the game present challenges to the user? Does the game privilege the experience, that is, the character gets stronger as the levels and secondary objectives are conquered? Does the game allow the user to exercise any ability, be it physical, mental or social? Is the user involved quickly and easily? Is the game enjoyable to play again? Overall, the user is satisfied with this game? Does the user feel enthusiastic about the game?

  • H12 - Accessibility: The audiogame must be accessible to the user. Checkpoints: Can the controls be customized? Are the most important options presented first? Can the user access the options quickly? Does the game allow the use of a screen reader? Is the information accessible? In case of using a screen reader, can the information be accessed?

It is expected that an instrument with the relationships between guidelines and heuristics can be used by the developer during the process of developing an audiogame, thus identifying the guidelines to be implemented, and then, confirming in the related heuristics, through the verification, if the implementation is in agreement. When conducting the evaluation during development, it is believed that it is possible to avoid future rework. Additionally, this set of guidelines is modular, that is, if the audiogame to be created does not have a graphical interface, for example, the guidelines of the category of Graphic elements can be disregarded. The final result of this study, with the related heuristic relations, according to the new numbering of the guidelines, follows in the next Sect. 4.

3.4 Stage 4: Focus Group and Development of Audiogame

Development of Audiogame Applying the Guidelines. In order to verify the applicability of the proposed guidelines in a real development project, an audiogame was developed, named “The Campus of Shadows: A Game Based on Development Guidelines for Audiogames”, as a course completion work by 2 undergraduatesFootnote 10. The audiogame has the RPG genre and the game scene is a part of the PUCRS university map, using the buildings, routes, parking lots and setting. The game uses 2D graphics and information in the form of audio. During development, a report was drawn up which described which guidelines were applied in the game and which were not used in the development due to development time or did not apply to the style of game proposed during the project.

Results. Out the 34 guidelines, a 15 guidelines were applied during the development of audiogame (D1, D2, D3, D6, D8, D9, D10, D16, D17, D19, D25, D26, D27, D28, D34). Out of these, 7 guidelines (D11, D15, D22, D23, D29, D30, D31) were partially applied, needs to be improved its application in the audiogame, so that it reaches completely. While 9 guidelines (D4, D5, D7, D13, D18, D20, D24, D32, D33), although developers deem it important, were not applied due to the short development time. There was a consensus among developers that 3 guidelines (D12, D14, D21) did not apply to game style. Additionally, the group described that the guidelines served as support for the implementation of audiogame in a way that made the game more interesting to users with visually impaired and that meet the synthesis in which the set of guidelines is proposed, in proposing a game with usability, gameplay, and accessibility.

Focus Group. A focus group was developed with game developers to answer the following question: Is the set of guidelines proposed in this study suitable for use in an audiogame development project?. In this sense, the guidelines were analyzed to verify their clarity, understanding, importance, and applicability in an audiogame development project.

Prior to the focus group, a pre-questionnaire was sent to the participants for a better understanding of each participant on the purpose of this research. This questionnaire was composed of questions about the profile of the participant and brought the 34 guidelines for the respondent to assign a degree of clarity and another of importance, within a Likert scale of 5 points for each one. There was a field for the participant to write observations on the guidelines. This questionnaire was completed online before to the focus group.

The procedure used in the focus group session was as follows:

  • Presentation of the research: Moment to contextualize the research, outline how the study was carried out so far, present the moderators who will assist and/or conduct the activities and explain the objective for the Focus Group.

  • Presentation among group members: Each member of the group was asked to introduce herself, stating her name, profession, experience with games and/or accessible games and other information relevant to the group.

  • Task 01 - Greater relevance: This activity consisted of two stages, the first, individually, the participants listed and justified the five guidelines, which in their opinions, were the most relevant to be implemented in an audiogame project. In the second step, after all, participants justified their choices in the previous step, the participants chose the seven most relevant guidelines in the group consensus.

  • Task 02 - Clarity and Importance: From the answers obtained in the pre-questionnaire, the guidelines with the lowest clarity and importance scale and/or that had some observation related to their understanding were listed. Each selected guideline was discussed with the group to suggest changes in its description and to verify if the guideline really is important to be maintained in the final set of guidelines.

  • General comments: At this point, participants were invited to comment on the set of guidelines in general, allowing them to discuss guidelines that were not highlighted in the pre-questionnaire, for example.

Results. The focus group session lasted 2 hours. There were 5 game developers who were identified in this study from P1 to P5, as presented in Table 1. Participants are between 18–44 years old, with an average experience of 1 to 3 years in game development and three of them had the same amount (1–3 years) of experience in the development of accessible games, including audiogames.

Table 1. Profile of the participants
Full size table

Each participant presented herself to the group, informing her name, profession, experience with games and/or games accessible, among others. Afterward, we proceeded as follows for Task 1:

  • Part 1: participants individually selected the top 5 guidelines they considered to be most relevant to audiogames implementation. The guidelines chosen by participants were: P1 (D10, D19, D30, D17, D11), P2 (D29, D30, D9, D26 e D2), P3 (D10, D30, D9, D27 e D26), P4 (D19, D30, D9, D13 e D6) and P5 (D30, D19, D26, D22, D9). After the selection, each participant presented to the group the chosen guidelines, justifying her choice. During this phase, the moderator-researcher was collecting the guidelines informed by each participant in a spreadsheet, generating, in the end, a short summary with the most cited guidelines to assist in the second part of Task 01. The most cited guidelines were: D9 e D30 (4 votes), D19 (3 votes), D10 (2 votes), D26 (2 votes) e D2, D4, D6, D11, D13, D17, D22, D27, D28, D29 (1 vote).

  • Part 2: the researcher showed the spreadsheet with the result ordered by the most voted guidelines by the group. Based on the summary of the most cited guidelines, participants were asked to choose the top 7 most important guidelines in the group consensus. For that, a paper was given, with 7 fields and a space to describe the indications. Participants defined the most important guidelines in the group’s opinion, reaching a slightly different consensus from the top 5 listed in the spreadsheet. The following guidelines were indicated: D9 - Navigation patterns, D19 - Conflict between sounds, D26 - Tutorial, D27 - Shortcut keys, D28 - Accessibility features, D29 - Interactive sound mechanisms and D30 - Different sounds. Namely, such guidelines were also cited in Study A by audiogames developers.

For Task 02 the moderator-researcher brought to the discussion some of the guidelines that were evaluated in the pre-questionnaire as less clear (D4, D26, D7, D34), less important (D16) or less clear and minor importance (D5, D17). For the guidelines that were considered less clear, there were problems of understanding about them, participants were asked to make a suggestion of a new description of the guidelines. Observations and suggestions for improvements in the descriptions of the guidelines can be observed in Table 2.

Table 2. Result of observations and suggestions for descriptions of Task 02.
Full size table

Guidelines D5 and D17 were considered less clear and less important. The group reported that D5 (Include auxiliary game modes, with direct access to secret areas and challenges) is unrelated to the original guidelines and a game design decision that does not interfere with gameplay. While D17 (Avoiding actions that require user’s precision to interact in the game scenario), they argued that it depends on the game design and goal proposed by the game.

To conclude the Focus group, a space for discussion of the guidelines was opened in a general way. P5 suggested examples of the use of the guidelines. P2 reported on the importance of including a user test guideline, with testing the mechanics in isolation and then together. P3 commented on D12 (including features of haptic interfaces such as vibration and touch capabilities), stating that it depends on the hardware - it was a consensus in the group - and it should be possible to explore the possible resources of available hardware.

3.5 Consolidation of the Results

Based on the results obtained in this section, some guidelines have undergone changes in their descriptions (D4, D7, D16, D26, and D34) in order to provide a better understanding of what they are proposing. Additionally, one was excluded (D5) because its priority since Study A has always remained low and the Focus Group has confirmed this issue.

According to the results of Study A, some of the guidelines stood out because they were considered high priority by at least half of the respondents in that study. A total of 15 guidelines were related, and all 7 guidelines considered to be basic to implementation by the Focal Group were also related in that group of selected guidelines. Similarly, we verified which guidelines were implemented as fully implemented by at least half of the respondents and only the basic guideline “Shortcut Keys” did not appear in this second relation, among the 18 guidelines listed. Table 3 presents these relationships between the guidelines. In this way, it is clear that such basic guidelines are really essential to the implementation, by the opinion of different experts in the development of audiogames.

Table 3. Comparison between the results of Study A, Audiogame developed and the Focus Group, regarding the basic guidelines
Full size table

4 Fair Play: A Proposal Guidelines

Based on the previous steps, 33 guidelines were consolidated that take into account criteria of accessibility, usability, and gameplay. The following steps, which are related to its presentation, provide an instrument to be followed during the process of developing an audiogame and a web environment for the public consultation of the results of this study.

4.1 Stage 5: Elaboration of the Instrument

As a final result, an instrument/guide was developed to be used by the developer during the audiogame development process. Thus, it is possible to identify the guidelines to be implemented and then confirm with the checkpoints of the heuristics if the implementation of the guideline is in agreement. The complete tool with the guidelines, their relations to the evaluation heuristics and checkpoints, can be seen below.

  • Category: GAME EXPERIENCE, LEVEL, AND PROGRESSION

    • D01. Clear Language: Use simpler and clear dialogues so that the instructions in the game become easy to understand. [5, 10, 14, 17, 18, 20, 21]

      Related evaluation heuristics: H2

    • D02. Game experience: Offer predictable and expected information, making game content, challenges and functionality consistent with the mechanics of the game, while avoiding escaping your gameplay pattern. [17,18,19,20]

      Related evaluation heuristics: H4

    • D03. Levels of difficulty: Offer varying levels of difficulty and allow them to be adjusted during the game. [4, 14, 17, 18, 20, 21]

      Related evaluation heuristics: H3, H11

    • D04. Training: Provide a safe environment so that the player can practice the penalty mechanics of play. [1, 10, 18]

      Related evaluation heuristics: H10

    • D05. Quick start: Enable the game to start quickly, without the need to navigate through several menus. [17,18,19,20,21]

      Related evaluation heuristics: H3, H7

    • D06. Exploitation of the environment: Provide means to help players explore the virtual environment of the game by accessing content and interactive elements through easy orientation, moving through cardinal points and/or degrees, to determine where they are in the game. [6, 10, 18, 23]

      Related evaluation heuristics: H2, H11

    • D07. Logical sequence: Provide menus that follow a logical sequence. [3, 5]

      Related evaluation heuristics: H6, H12

    • D08. Navigation patterns: Use screen navigation navigation patterns for easy navigation. [3, 5, 14, 15, 19]

      ( Basic guideline for implementation )

      Related evaluation heuristics: H4, H12

    • D09. Keep context: Keep the player informed of what is happening in the game, avoiding loss of context. [3]

      Related evaluation heuristics: H1

    • D10. Progress Summaries: Allow the player to visualize their progress summaries during the different phases of a game, such as punctuation, lives and challenges. [3, 18, 20, 21]

      Related evaluation heuristics: H1

    • D11. Vibrating and touch features Include haptic interfaces features such as vibration and touch features. [6, 23, 24]

      Related evaluation heuristics: H12

  • Category: DATA ENTRY/SOFTWARE AND HARDWARE

    • D12. Sensitivity and time of action: Provide a means of setting time-dependent characteristics such as sensitivity and speed of events, movements, and game actions. [3, 4, 14, 17, 18, 20, 21, 24]

      Related evaluation heuristics: H3, H7

    • D13. Auto save: Enable mechanisms to automatically save the current state of the game. [18, 19]

      Related evaluation heuristics: H3

    • D14. Input Devices: Allow the use of different input devices. [3,4,5,6, 10]

      Related evaluation heuristics: H3, H7, H12

    • D15. Simultaneous and special keys: Provide the use of keys, buttons or gestures cohesively, avoiding combinations rarely used in game patterns. [5, 17, 18, 20]

      Related evaluation heuristics: H7, H12

    • D16. Accuracy of actions: Take care of the actions that require the player’s precision to interact in the game scenario, verifying if its use makes sense to the context of the game. [3,4,5, 15, 18, 23]

      Related evaluation heuristics: H12

    • D17. Assistive Technology Assets: Predict the use of assistive technology features, such as voice control, extended keyboards, brain-computer interface, screen reader, virtual loupes, and so on. [4, 10, 14, 16,17,18,19, 23, 24]

      Related evaluation heuristics: H3, H7, H12

    • D18. Conflict between sounds: Avoid conflicts in the sound information that is emitted by the game and those that are transmitted by screen reader. [3, 6, 16, 23]

      ( Basic guideline for implementation )

      Related evaluation heuristics: H12

    • D19. Configuring controls and commands: Enable game controls and commands to be changed/reconfigured, making sure they are as simple as possible. [4, 10, 11, 14,15,16,17,18, 23]

      Related evaluation heuristics: H3, H7

    • D20. Voice Commands: When using voice commands, use individual words from a small vocabulary, for example: “Yes”, “No”, “Exit”, “Open”, “Skip”, “Save” and so on. [11, 18, 24]

      Related evaluation heuristics: H3, H7

  • Category: INSTALLATION/CONFIGURATION/HELP

    • D21. Issuing immediate feedbacks: Send immediate feedbacks according to the player’s actions, so that he can know that his actions are being processed, such as reporting to the player about the data entries, need to close the dialog window, and so on. [3, 4, 6, 15, 18,19,20,21]

      Related evaluation heuristics: H12

    • D22. Tips and reminders to the player: Send tips and reminders to the player, depending on the context in the game, to assist you in cases of difficulty, including mechanisms to reduce the occurrence of errors, such as disabling menu items that are not available to use, close dialog dialog after user action, and so on. [3, 10, 19]

      Related evaluation heuristics: H10

    • D23. Bug fix: Include mechanisms that provide error correction, such as allowing the player to return to a safe point in the game, providing messages clearly indicating the reason for the error, and so on. [10]

      Related evaluation heuristics: H5, H9

    • D24. Manual and documentation: Provide manuals and installation instructions and game setup mechanisms. [3, 10, 15, 18,19,20,21]

      Related evaluation heuristics: H10

    • D25. Tutorial: Provide information on how to play and interact in the game through an initial presentation of a game mechanic in a didactic way. [15, 18, 20]

      ( Basic guideline for implementation )

      Related evaluation heuristics: H10

    • D26. Hotkeys: Provide shortcut keys to interact in the game options and to access information, such as to save, exit, pause, access help, and so on. [3, 18]

      ( Basic guideline for implementation )

      Related evaluation heuristics: H3, H7

    • D27. Accessibility features: Inform in the descriptions of the game explicitly that it provides for use by people with visual impairment. [14, 16, 18]

      ( Basic guideline for implementation )

      Related evaluation heuristics: H10

  • Category: SOUND ELEMENTS

    • D28. Interactive sound mechanisms: Use fun sounds, audio tracks and sound effects such as 3D sound, binaural recording, surround sound, sonar style audio map and etc. in a fun and entertaining way. [3, 6, 14, 17, 18, 20, 23]

      ( Basic guideline for implementation )

      Related evaluation heuristics: H11

    • D29. Different sound for each event: Allow the objects and scenery of the game to be recognized by sound, providing sonic feedback for the actions of the player. [3, 10, 15, 18]

      ( Basic guideline for implementation )

      Related evaluation heuristics: H12

    • D30. Sound and Audio Settings: Provide mechanisms to configure the audios and sounds of the game, such as narratives and ambient noises, including the ability to mute and/or turn them off, toggle them, controlling their duration, voices and volume of sounds, individually. [3,4,5, 11, 14, 15, 17,18,19,20,21]

      Related evaluation heuristics: H3, H7

  • Category: GRAPHIC ELEMENTS

    • D31. Graphics Configuration: Provide graphic settings options, such as disable 3D graphics, enable color customization, brightness, contrast and text and font size. [1, 4,5,6, 11, 16,17,18,19,20,21, 23, 24]

      Related evaluation heuristics: H12

    • D32. Interactive Elements: Clearly indicate the existence of interactive visual elements, using sound elements to describe them. [18, 23]

      Related evaluation heuristics: H12

    • D33. Repetitive Elements: Avoid repetitive animations and visual elements as the only source of information, diversifying visual and sound alerts. [5, 10, 18, 19]

      Related evaluation heuristics: H8, H12.

4.2 Stage 6: Web Environment

In order for this set of guidelines to be consulted by a greater number of developers interested in the development of audiogames, a web environment was developedFootnote 11, with the relation of the guidelines and linked evaluation heuristics, in order to bring the research work closer to the stakeholders and directly involve them in order to achieve continuous improvement. Initially, the environment was only available in the Portuguese language, but an English version is provided.

The environment was developed in a static way, that is, without the need for a server and was hosted publicly in on GitHub. This way, anyone interested in the topic could reuse the code and even suggest changes. The environment was organized into five sections, and in the Categories section, all 33 guidelines of the final set of guidelines, named in this study by Fair Play, are listed and organized into their 5 main categories. In the Basic Guidelines section are presented the 7 minimum implementation guidelines for an audiogame project. The Test section presents a reminder of the importance of performing tests during all phases of an audiogame project, to further ensure the accessibility and usability of the game to a player with visually impaired. In the About section, a brief explanation of the project developed in this research is described. And finally, the Contact section brings information to the communication, with the objective of generating interaction and possible evolutions of this project.

5 Conclusion

The final proposal of guidelines presented in this study was elaborated taking into account the existing literature on recommendations for the development of games accessible in general. Because it is a study focused on the development of games for the visually impaired, there was a constant follow-up by blind users throughout the creation of the guidelines, aiming to consolidate a more concise set with the target audience of this study. It is important to emphasize that the audiogame project must, besides following good development recommendations, include during all the processes of elaboration of the game, tests with players with visual deficiency so that the users can grant important feedbacks, aiming at a more accessible and immersive game.

The present work made possible the consolidation of the initial study proposed by Campos and Borges [8]. For this, it involved a process for evaluating the guidelines with accessible and end-user game developers. With developers, there was the application of an online questionnaire, the development of an audiogame and a focus group. With the end user, there was the evaluation of audiogames already available to verify which guidelines were applied. In addition, there was the linkage of the guidelines with heuristics of evaluation of audiogames, by the authors of this work, in which an instrument was created.

This will enable a more concise development with recommendations based on the literature. Fair play guidelines have been made available for community use through a web environment. It should be noted that by not applying guidelines, during the development of an audiogame, it can lead to a decrease in the interest of a user with VI in the use of the game. Also, when given audiogame does not have a focus on the end user, the player’s experience can become discouraging. It is not enough to predict the use of different audios if they do not create the feeling of immersion and do not guide the player in an easy and interactive way.