I've had the pleasure of working as the producer for People ForWords, a team participating in the Barbara Bush Foundation Adult Literacy XPrize. I joined the team for the project’s vertical slice milestone that ran from the end of May to the beginning of July, 2016. Our team is developing a new Android application that teaches and reinforces basic reading fundamentals aimed at adult learners between the ages of 25 and 50. In Codex: The Lost Words of Atlantis, Players take on the role of an archeologist, seeking to uncover the secrets of the lost city of Atlantis. As we finished our vertical slice milestone last week, I sat down with the team to perform a retrospective of how they felt our work had gone in the past month, and to identify what things we can do better moving forward with the remainder of the project.

What Went Right

1) Creating lines of communication

Our team functions primarily virtually—and we generally only come together face to face one day per week. When I joined the project as their first producer, one of the first requests that I received was a more defined method of collaboration that allowed people to leave notes for each other, share files, and notify each other of changes. We elected to use Slack as a collaboration tool, which allowed us to stay in touch constantly and keep each other apprised of our progress. The team particularly enjoys our integration with Google Calendar, as it allows them to set up meetings with one another and Slack sends reminders right to their computer or mobile device.

2) Rethinking documentation

Additionally, the team asked for a new method of creating documentation. Prior to my arrival, team members collaborated using Word documents hosted on network drives, which the team felt was far too cumbersome. We began migrating our work over to an Atlassian Confluence wiki solution, which any member of the team can view and contribute to online. The team loves the transparency and the centralization of this solution, and they enjoy that they can embed more complex web content than what a simple Word document supports.

3) Weekly production meetings with action items

Because the team functions primarily as a network of contractors coming together to collaborate on work, and because I was joining partway into the project after it had already found its footing, I decided to avoid creating a traditional backlog. Instead, I worked with the team to identify overall epics and milestone definitions that comprise the project, then worked with team members at our weekly production meeting to determine how progress was moving forward towards the larger goals. At each meeting, we work together to create a detailed list of action items so that each team member has a record of what work he or she agreed to do in the next seven days. The team appreciates the flexibility that the system creates for them, and they appreciate that the action items are folded into our wiki, so that it cuts down on the number of tools they need to work with.

4) State structure in Phaser

We’re building Codex using JavaScript and Phaser, an HTML5 game framework for desktop and mobile devices. As we build, our programming team elected to divide the game into a series of different states. This division allowed each of the programmers to keep their work in relative isolation, allowing the programmer working on the core gameplay mechanics to keep out of the way of the one implementing cutscenes, for example.

This division was particularly important, as most of the programming team was new to working with Android when the project began. Because of the separate states, issues in one section of the game never broke the entire build, and development never halted because of a single bug.

What Went Wrong

1) Poor documentation/planning from original design phase

By the time I joined the project, the team was already developing at full speed. However, the team as a whole did very little documentation of the overall design or specific asset requirements until about halfway through the vertical slice milestone. This affected the art department most heavily—because they had a fairly narrow picture of what needed to be done for a given week, the had trouble planning their time out in a broader sense. The team began to organize around Slack and Confluence to address these problems, but certain ambiguities carried over from the design phase of the project and hampered art’s productivity.

2) Only see build on Thursdays

While the weekly production meetings were quite useful to organizing the team and helping to solve larger blockers, they were also the only opportunity team members got to see their work integrated into a current build. This meant that requests for updates or changes could only be made weekly, and often bugs or miscommunications lingered for several days before a team member had an opportunity to catch them. To their credit, our programmers implemented all art and audio assets as requested, but usually only built to test on Android, which didn’t serve the rest of the team members well. We have an FTP server set up where we can also share versions created for web, but none of our programmers had direct access to the server, and it only received builds about three times in the month of the milestone.

3) Two separate repositories—both cluttered

Throughout the milestone, the team utilized two separate repositories for data: a shared Dropbox folder where file transfers occurred, and a Perforce depot where the programmers pulled files and built the project. The team found that keeping track of both of these two repositories was a difficult endeavor—especially considering that both contained outdated information and poorly organized folder structures. It required team members to specify where they were storing their work when making hand offs, and required the programming team to copy files from one repository to another when integrating an asset into the game—giving the programming team in particular twice the files to keep track of at once. The team began to fall into a rhythm of dealing with the data as they developed the milestone, but they all agreed that the use of two separate structures slowed down their development—especially as the Dropbox folder got larger and team members began to hit their data caps!

Looking Forward

Unfortunately, my time working with this team is almost done, but we discussed several ideas that those remaining with the project can embrace as they move into working on the alpha milestone.

1) Plan out the next milestone more carefully, and create specific asset lists

As we finalize the vertical slice milestone, the art and design teams began carefully specifying the assets they would need to create over the next couple of months in pursuit of our alpha. By taking the time to outline those requirements and document them as an asset list on our wiki, the art and design teams hope that they can improve their planning capabilities and improve the “big picture” understanding across the team.

Additionally, art is currently working with the programming team to set specific asset standards for use in Android and clarify naming conventions, so that all developers can easily track down the files that they need.

2) Push the build up to out FTP site so team can see more often

To improve transparency of how the game is coming together, the team understands that they need to start making full use of the FTP server, and push web builds out on a regular basis outside of the weekly team meetings. The team hopes that doing so allows the artists and designers to see how their work looks in context, and speeds up the feedback loop of integration and bug fixing.

3) Define specific roles for the repositories, define their file structure

Though the team discussed getting rid of the Dropbox repository, they decided that they would rather redefine the purpose of each depot—so that it’s clear where a given file needs to be uploaded, and so that neither becomes too cluttered with unnecessary data. Moving forward, the team plans for the Dropbox repository to house research imagery and legacy documents (those generated before the implementation of the Confluence wiki), while Perforce keeps all game-ready assets for the programmers to implement.

Additionally, the team realized that none of the art source files were in an accessible location, which limited who could access them and prevented a common backup of the files. Thus, the team also plans for the Perforce server to house all source files for art, audio, and video—which both creates a backup of the files, and allows designers access to the source if they need to create a version of an art asset for documentation on the wiki.

The team has a long road ahead of them as they work toward building the alpha version of Codex, and it’s fairly challenging to develop such a complex product with a primarily virtual team. However, the skills that the team learned, and the tools introduced over the course of creating the vertical slice milestone have set a solid foundation that will hopefully lead us to success in the XPrize.

Visit http://www.peopleforwords.org/ to learn more about CODEX: THE LOST WORDS OF ATLANTIS, and visit http://adultliteracy.xprize.org/ to learn more about the Barbara Bush Foundation Adult Literacy XPrize.