Making of an Arabic Teaching Game: Antura and The Letters

I wanted to share my eleven weeks work experience at VGWB (VideoGames Without Borders). During these weeks I developed a whole section of the game "Antura wa al huruf" (Antura and The Letters) under the supervision of Francesco Cavallari (founder of VGWB), and of Davide Barbieri (Lead programmer from GhostShark Games). Background: In September of 2016, a Norwegian Agency, Norad, started a contest to realize an educational game to provide a way for Syrian children to learn while having fun. An estimated 2.8 million Syrian children are out of school due to war. Since most of these children have access to a smartphone, a mobile App was a viable way to ship that goal. The project timeline was roughly as follows: The project had initially 78 different project proposals (Phase 0). 5 Projects were selected as semi-finalists (Phase 1). 3 Projects were choosen as finalists (Phase 2). Feedback provided and request for improvements before winner election ( Phase 3). I Joined the project during Phase2, at time of writing the article we are in Phase3 and waiting to hear who is the winning project My role: I joined the project after the beginning and started working on a new section. My assignment was the development of the Assessments section: Antura's is structured in a series of worlds/maps each one with a travel line: during travel, you play minigames to learn Arabic, and after some minigames sessions the player is required to do an Assessment. It is not an exam at all, its purpose is to reinforce learning by doing a series of exercises that uses the concepts learned in previous mini-games, it is possible to answer by trial and error, and the goal is to not stress the children too much. How Antura looked after the first development rush. As a newcomer I spent the first few days looking over and learning from the documentation and the existing code; I did a quick draft of code to get an idea of the amount of work required and potential problems. The most important part (as always) is to understand the requirements, so I read the documentation several times, and printed my own copy and annotated it. Even if dependencies on preexisting code are minimal, understanding a pre-existing codebase helps a lot. Requirements: There was a total of 9 assessments types (later evolved to 13 assessments). Assessments had to look similar and have similar behavior, but at the implementation level, there? are differences in how the logic is implemented. The graphics needed to be simple on purpose to not distract too many children from the assessment. The first playable prototype was ready in one week, and I used it to get feedback from my supervisor. The key factor to development on the project was continuous feedback: this was a truly Agile experience, we had a development cycle that consisted in four days of rush programming and one day of testing/revisioning/bug-fixing. Requirements changed every two-three days (due to feedback from testers or from field testing). Journey map Things I got right. Wrap the content provided by the Question Provider, the IQuestionProvider interface is a bit controversial: it was first enforced to be a ?EURoeunique?EUR? interface among all games, but it was not sufficient to fulfill all different game logic; the workaround (used everywhere in the game) is to ?EURoedecode?EUR? the content of the IQuestionBuilder. That piece was designed with a goal in mind, but testing and improvements later required different behavior. At that point in development, it was no longer possible change that without breaking stuff, so we delayed that issue to a future refactoring. In the Assessments the decoding of IQuestionProvider is done by IQuestionGenerator, so the IQuestionProvider is free to change without breaking Assessments, in fact even though there are a couple of different implementations for the IQuestionGenerator, the interface is used in the same way by all Assessments (no decoding). The Assessments?EUR(TM) game loop is a Coroutine since the game is divided into well-defined phases, putting stuff inside a IEnumerator proved very useful. This is especially useful because it allows us to put animations where needed and wait for them to end without having to resort to state machines or complex flag systems. There were two major changes in the game flow, and I was able to seamlessly implement them without breaking stuff because of the usage of Coroutines.? Certain behaviors are just much more simple to implement using Coroutines. private IEnumerator RoundsCoroutine( KoreCallback gameEndedCallback) { for (int round = 0; round < Configuration.NumberOfRounds; round++) { InitRound(); yield return Koroutine.Nested( RoundBegin()); yield return Koroutine.Nested( PlaceAnswers()); if (round == 0) Koroutine.Run( DescriptionAudio()); yield return Koroutine.Nested( GamePlay()); yield return Koroutine.Nested( ClearRound()); } gameEndedCallback(); } Use my own sound manager. All audio is loaded into a global audio manager (implemented by DeAudio by other developers). While it was a real pleasure just to call one method for playing a sound file (and have each single sound effect tweaked by an audio engineer), I had specific issues to be addressed for assessments (some clips were allowed to overlap, while other clips were not). The easiest way to ensure the correct playback for audio files was just to add another audio manager (on top of the old one). That allowed me to keep the correct behavior of each sound, without adding extra complexity (I still call one method to play each sound). And for certain sounds, I now have a meaningful name public void PlayPlaceSlot() { audioManager.PlaySound( Sfx.StarFlower); } Things I got wrong Use of a time manager. Since all games had to implement at least two IState interfaces (one initial game state and one final game state) and there was an ?EURoeUpdate( float delta)?EUR? method to implement, I assumed that time scale was custom and I had to use that ?EURoedelta?EUR? also for Tweens and Coroutines. I was wrong! The game was in reality setting Time.timeScale to 0 to pause the game, while the UI was animated with a unscaled delta time. It would have only taken a minute to check that myself. While in theory, the time manager idea is nice, because it decouples the time flow from Unity?EUR(TM)s time scale, in reality, it was not used in other minigames, so it was pointless keeping it around. In fact, I later removed it during the polishing phase of the game. A bit overengineered overall. I can understand the short deadline, but there are a few things that I would like to have written in slightly different ways (well code works, so no reason to change it now), also rethinking later to the game I think? Assessments section was a good candidate for using an ECS pattern (which I learned recently, and I?EUR(TM)m still experimenting with it) however since I was not too confident with ECS I decided to not take risky roads. During the development, I thought more than once ?EURoeif I had used the ECS pattern, that would have solved that problem for me?EUR?. As a result of the extra complexity, I was able to cut a lot of code during polishing phase (For example, there were several Answers related classes that resolved a communication problem, later I merged them in just one Answer class. ) I?EUR(TM)m still very happy with the rhythm I was able to keep and with the result. Also, I think I did pretty well since I joined the project in progress and did not have the time I wished to have. Things I liked I worked with talented people, I had the chance to work with people I was following, and I continued to work together with some people I already knew. I learned a lot, and this was only my second team work experience (This time I had to collaborate tightly with some coders also). It is very surprising when you need stuff, and you find it was already implemented by someone else. I also really liked participating in some design decisions and helping refining some logic. It was a short but intense experience. Things I didn?EUR(TM)t like It was a relatively short experience, and I had a lot of fun, so it is a pity that has already ended. The game is already published on Play Store and AppStore, there are no major things to fix, and at least in my section (Assessments) there?EUR(TM)s no more work to be done. I?EUR(TM)d like to work on this project a bit more. Antura current look and feel of the assessments section. How did I get the job? I have to thank guys in GhostShark Games for that. I already worked with them for one year developing a couple of games, and I can?EUR(TM)t wait to see what the next project will be. In the meanwhile, we worked together on Antura. I use the free time between each project to develop personal stuff and to refine my skills. Does the game work? Yeah, it works! In reality the game is aimed to teach Arabic to children that already speak and understand it, however I was able to learn most of the Arabic alphabet and dozen of words (even though I didn?EUR(TM)t understand a single word of Arabic when I joined the project). Also, field testing showed children genuinely learned new things. As a personal note: I?EUR(TM)m surprised by how elegant Arabic writing is! Original version This article has been reblogged from my new developer's blog. Editorial note: some formatting and grammar changes have been made with permission of the original author to aid in reading of the article.

Making of an Arabic Teaching Game: Antura and The Letters

Comments

Recommended Tutorials

Other Tutorials by DemonDar

Making of an Arabic Teaching Game: Antura and The Letters

Comments

Recommended Tutorials

Other Tutorials by DemonDar

Reticulating splines