Getting to know the game (and the problems)

 On Tuesday, the 10th of November, we met up with Jakub Stepaniak, who introduced us to the game of AudioWizards. We talked about how the game has been built and what problems are present. After Jakub left, we continued on with the meeting and talked about the project and how we would approach these problems. 

The game is played in a maze and the players try to hunt each other down, while listening to audio clues of other players whereabouts. As the game is designed towards the visually impaired, it leans heavily on audio and currently there are many issues that need fixing and balancing. Currently, the game is using Google resonance audio software development kit for it's audio handling. The SDK is pretty out of date as of right now and it has apparently been producing a lot of bugs, so we will need to either figure out a way to fix these bugs, or just use a completely different approach for handling the audio in the game. 

The accessibility feature (Unity Accessibility Plugin, UAP) in the game is also proven itself a handful, and we need to figure out a way to efficiently communicate the state of the game to the player. The text-to-speech also forces words in English to other languages. The current menu navigations with the UAP are also confusing and need to be thought out better. The way the audio communicates with the player in-game needs to be improved, it has to be faster and clearer so the player knows exactly what the game is trying to communicate to them. We need to keep in mind that the target audience has impaired vision or total loss of vision, so our main focus is with the audio.

Even if the main audience for the game are blind, we thought that the graphics of the game could use a bit of refining, if not a total make-over. If we could improve the current visual state of the game, it could be more interesting for the players who can see. We also need to think about accessibility for color blind people, and customize the graphics in a way that is easier to distinguish. Another thing we thought about when discussing the not-visually-impaired players, was that right now they have a huge advantage if they were to play against a blind opponent. To balance this out and give equal chances to both, we could adjust the game to be actually hard to see in, so that all players would have to rely on the audio the game gives you. The game could also punish you if you move too fast by making the player emit a louder sound for the other players to hear.

As for the programming side of things, we decided to stick with just the game's current version of Unity to reduce any version issues. We now have the game to ourselves, so our programmers have the opportunity to get themselves familiar with the code so we can be ready when the time comes to get our hands really dirty.

The game hasn't really been tested with that many people, so to actually see how the game works for both kinds of players, there is a need for some good publicity to get people interested. If we widen our scope on what platforms we market ourselves on, we could bring in more players and testers. 

As we go on, we will refine our approach to these problems, but this meeting was definitely a good start. Our team has high hopes for this project, and we are all very excited to be working on it!

-Susanna