Serious Games and VR: A two months project post mortem

This post describes the ups and downs we had during the development of a serious game project at the Guildhall at SMU. Our goal was to update a 10-year-old training simulation that helps to prevent teen dating violence. The new simulator places participants into a virtual environment (Oculus Rift) with a trained actor/facilitator. The simulator captures the actor’s speech in real time and replicates it into his virtual avatar, simulating a real life situation. Although this was based in an old project, recreating it using the current technology proved to be trickier than we expected. Next I discuss some points that came up during our post-mortem.

What went well:

The project started as an Unreal 4 project. However, we needed a tool to analyze real time voice data and translate it into real time lip-sync. To find the best tool, we researched solutions from voice only technologies to full facial-capture ones. Unfortunately, the research proved that none of the solutions would work in Unreal 4 with the resources and time frame we had. This forced the team to find another game engine and move to it as fast as possible. We elected Unity as our next try. Some team members had experience working with Unity 4 and we could tell that our project could be done in Unity. However, due to project graphic’s requirements, we decided to go with Unity 5.

When we finally decided the game engine and the lip-sync technology, we struggled with our virtual reality technology. We started the project using the Oculus DK1, but soon we realized that for better results we needed to upgrade to the Oculus DK2. But our problems were still not over. The project needed a 2D user interface, and 2D user interfaces are not supported in the Oculus environment. Along with other requirements, this scenario forced us to build a solution over the network using two separate computers, introducing a completely new set of variables to the project.

In shorter words, our technology changed a lot during the process, but in the end, we managed to find/create technologies that solved our problems. The most impressive part is that all of these changes happened in less than two months.         

What went wrong:

Our project had a different set of people working on it. Students, professors, on-site contractors, and off-site contractors were all working in different parts of the project. Each one of them had different schedules and availability. Furthermore, most of the team was not working in the same workspace. All these factors combined contributed to a huge challenge in the communication part. We tried different ways to make sure the team had a successful channel of communication. However, none of them worked as expected and lead us to the next point.

During our team game projects at the Guildhall, we typically use the agile with scrum methodology. Although this methodology proved extremely helpful to us, we couldn’t translate this success to this specific project. Many variables made this project completely different from the ones we previously worked on. As an example, since we were not sharing the same workspace the entire time, the use of a physical scrum board was almost worthless for the project. The scrum board was not solving its main purpose that is to give the team a clear picture of where we are at the moment, what you can do next and what is being done. Overall, our project organization was far from optimal for this particular project.

What we learned:

As I discussed in the changing technologies part, this project was heavily focused in research and development. However, due to resources availability, we had a strict time frame to finish and deliver the product. During development, we realized that these two scenarios don’t go along that well. Research tasks are unlikely to be estimated correctly and can take much more time than expected.

Until later in the project, we still had many unknowns about our tasks. This situation made our full production stage begins only by the end of our Alpha milestone. Overall, we learned that if a project is heavily based in research and development, extra time and resources should be accounted in the project schedule and budget to ensure the desired deliverable.

Using a process that solved past projects’ needs was not the best solution for us. Our development process proved that each project is unique and trying to use a solution to fit all projects will not work. It is important to analyze how the project’s resources are organized before compromising to a particular process. However, if the project is already in development when you realize this, don’t hesitate to change or adapt your process.

Near the end of our development, we made changes in the way team members reported their tasks status. These changes heavily contributed to a better work environment, unfortunately they only happened by the end of development.