Megalodon Post Mortem

Our Goal

 Our goal for the semester was to develop a game that redefines the expectations of browser-based gaming through an engaging and immersive experience using WebGL. Our game features hardware accelerated 3D graphics in your browser without the need to install additional software, enabling players to jump into the game very quickly

The Electronic Arts Office of the Chief Creative Officer (OCCO) handed us an existing EA project and tasked us with recreating that tower defense game in Pterosaur, their WebGL engine. Our client has planned to showcase the game at Google’s I/O conference in June to demonstrate the power of WebGL technology and the capabilities of Google Chrome.

The game is played like many other Tower Defense games. The objective is to breech the perimeter of the enemy base, while defending your own. The player controls a powerful hero unit and clears the way for AI controlled units to attack the enemy base. For each AI unit that breeches the enemy base, the player receives a point. The player with the most points at the end of 5 minutes wins the game.

What Went Well

• Relationship with the OCCO

One of the most exciting things about this project is that we worked so closely with the OCCO. The support the OCCO provided to us was a great help on the road to success. We’ve had the fantastic opportunity to work side by side in their office the entire semester. They even assigned a mentor to each member of our team based on their area of expertise. These mentors helped us learn and contribute better to the project. We had one-on-one meetings with our mentors each week as well as a meeting solely to go over our struggles working with the engine. Open communication between the teams allowed both of us to be flexible and get feedback quickly.

• Two Week Orientation

In order to get our team up and running with the engine, the OCCO handed us a demo and had us re-skin and improve the game. Our team of 11 people was split into two small teams competing against each other to see who could create the better game in two weeks. Each team presented their game to Rich Hilleman, the Chief Creative officer, and others in the OCCO. This mini project was a great crash course on the engine and technology and gave us an idea of the kinds of challenges we would face for the rest of the semester. With this mini project complete, the team was unified and prepared to face the challenges that lay ahead.

• Team Resources

The size of our team was a major advantage to our project. This project team is one of the largest in the ETC’s history. The combined talents of each team member encompassed the entirety of skill needed to create a product of the highest quality. Our client was able to make use of our skills by assigning a specific role to each person on the team. This clear demarcation of roles worked out really well, as each part of the project had a distinct owner and we were able to identify and solve problems sooner. The team remained self-motivated and eager to work throughout the project duration.

• Office Tournament

In week twelve of the semester, we had an exciting opportunity to present our game to our client by holding a tournament with about 16 players. With so many people playing the game, we were able to learn a lot about what worked and what didn’t work. We were also able to identify dominant and emergent gameplay strategies, which helped us polish and balance our game. After the tournament, our client gave us really valuable feedback and a clear direction of how to wrap up the project and make it feel right for I/O given the time we had left in the semester.

• Access to Original Art Assets

Our client did as much as they could to provide us with complete access to the art assets of the project we inherited. We made use of the original game’s environment, several of the AI units, and a number of textures. These assets saved us a ton of time and effort, meaning we could focus more on solving technical challenges while our artists concentrated on the in-game user interface, particles and feedback loops.

• Iterative Testing

We regularly tested our game internally, which allowed us to identify many bugs. We were also able to conduct many playtests with our client and get regular feedback from them. Sometimes on a daily basis, we could test our progress with the client to see how they liked what we were doing.

We also had a weekly event during which the team and member of the OCCO played games together to research their design choices. We played many games together including League of Legends, Realm of the Mad God, and AirMech. These sessions were valuable because they helped us understand the choices that other designers had made with games similar to ours.

What Could Have Been Better

• Communication

Without a doubt the biggest challenge for the team was communication. At the beginning of the semester, there were several occasions during which design decisions were not properly communicated to the team. Even when this problem came to light, it was not relayed between members of the team directly, but through our advisors. Clearly something was not right. We came together as a team and brainstormed ideas for communicating ideas to everyone and ideas for fostering open communication between members of the team. We created multiple variations of design documentation as well as technical documentation of our code base. We created easily accessible documents for tracking bugs, art assets, and ideas for polishing. We opened sprint planning decisions to the entire team as well. While this was definitely cumbersome to an extent, it ensured that everyone on the team understood what each person was accountable for and why.  Fluid communication was of course, a long and evolving process. We would have worked more efficiently and accomplished more had this been addressed sooner. Ultimately the real take away is that the leaders on the team needed to be more proactive in communicating ideas to the team.

• Limitations of the Technology

While it’s widely understood that using an engine that is still under development is risky, that is exactly what we’ve done. The Pterosaur engine created by the OCCO is quite powerful, but came with many technical limitations and even in our final weeks of the project, is still undergoing large changes. The engine has very limited support for dynamic particles. It has no support for swapping textures or texture transparency. We spent two weeks, far too long trying to build our own collision system because one wasn’t provided in the engine. One major request from the client was that we have deferred lighting in the game. However, we foolishly started moving on this prior to the feature’s completion in the engine. We wasted considerable time trying to make deferred lighting work before finding out that the engine simply wasn’t ready for it. Though we were able to make requests of the OCCO development team, more often than not we were told to simply work around the limitations of the engine. Had we fully understood these limitations, we could have made better use of our time.

Lessons Learned

• Communication and Leadership

In spite of having the features of the game design documented, communicating those ideas to the team was still a problem. People simply aren’t inclined to read long documents or go through spreadsheets. We learned that diagrams and images are very helpful in communicating complex relationships to team members. However, even diagrams can fall short and simply having conversations with some or all of the team to talk about ideas is very important.

Part of being a leader is making sure that the people around you understand not only what has to be done, but why it needs to be done. It’s also fine for leaders to make decisions, but they have to consider the ideas of the people around them or they risk alienating themselves from the team.  These were invaluable lessons.

• Organizing a Technical Team

Our project and our team were both extremely programming intensive. Our team had seven programmers working on the code on a day-to-day basis. Organizing the work of these seven people and ensuring that they weren’t destroying one another’s work was a challenge. By holding regular programmer meetings to go over major structural changes and developing a clear system of version control and code branching we managed to limit most major code conflicts.

• Pivots in the project direction

This project has seen three major pivots. The first was after we finished our two week orientation, another two weeks after that, and another in week 13. The team was flexible enough to quickly adapt to these new directions and continued to work hard to deliver results.  These types of changes are a common occurrence in this industry. Having this experience and being able to shift gears fluidly is extremely valuable.

Conclusion

In the near future, our project will be demoed at the Google I/O conference by our client, showcasing the power and potential of hardware accelerated 3D graphics using WebGL. This project has served as a testing platform for the engine that our client is developing and as a way to show what that engine is capable of.

This project has been an amazing opportunity to work on the cutting edge of technology and work with some of the most talented professionals in the games industry. We have delivered on our client’s expectations. The game is fun and easy to play and while the game isn’t as visually impressive as we had hoped, it is still head and shoulders beyond many other WebGL games. We are very proud of our success. Our experience on this project, will be invaluable as WebGL technology continues to mature.