The Fly on the Wall postmortem

About

The game started off by using my own game engine called aGame Framework. This was an advanced gaming engine that ran the first prototype during sept 2009. During main development we switched to Unity due to better features and support.

The game was going to be a casual game where the player was going to see the world through a fly's perspective.
We had some ideas about mini games within the levels that where related to flying: time based, collect all, etc ...
Additional features included lighting effects: SSOA and dynamic lights to enhance the feeling of dark and dirty area within the game. We also considered using IK on the arms for when the character was trying to kill the fly. This was not considered important since the character was never visible when the fly was trying to escape. Another aspect that was going to be fun to have was rag-doll feature on the fly when flying.

Things that went right

• Assembling a great team that all were very professional within their respective areas. Although many of the members resulted in being from Denmark the collaboration and work-flow worked well.
• Character development went well despite glitches during development, time constraints and not all features where implemented. The development of the character was the smoothest and least problematic during the asset creation. This was mainly due to a stream/stage-like development pipeline where the character was handed down to people that where highly focused in their respective fields.
• Scripting using Unity was module/component based that resulted in easier development. The author found this useful despite not fully utilizing the full potential of this modularization.
• Switching to Unity in a early stage during development resulted in better modularization, asset and mechanics development. The old pipeline required artist to use many types of tools to incorporate assets into the game. From the programmers perspective this resulted in a focus on game development rather than engine development. Development using aGame Engine which was effective. But it was easier to focus all programming on the game rather than into the game engine.
• Online collaboration tools (Google) was used effectively to communicate ideas when team members where distributed. Lesson learned was that it would be better if there were committed work schedules from all the team members.

Things that went wrong

• Game vision was not perfectly communicated with all members resulting in game assets being reworked.
     The project started with a vision by the Project Lead of a edutainment based game. The game had a game design document that considered the game balance, mechanics, initial levels as well as media design. This document was shared with people involved in the project from an early state.
     During development the document was updated as needed and actual implementation was postponed until everyone was in sync.
     But despite of this there was a lot of assets "developed" and queued to be used in the game. The problem was that creating the actual gaming aspects of these items deemed to take longer than expected. During late stage of the project these had to be abandoned due to time constraints.
     Much work was spent on visual aspects instead of gaming during the start of the project that also resulted in a game having "heavy" media that had nothing to do with the actual game play.
     Although this is common in game development measures must be taken to avoid redundant work by planning. All members should be committed on what should be developed and rank these based on if it's important for actual game play.
• Collaboration using the free version of Unity was hard because the free version did not support collaboration using Subversion or an "Asset Server" which both require the Pro version.
     We did try to find a workaround that used Unity packages but soon everyone started to share the entire project through the Subversion server. This resulted in server handling 500 MB - 1GB data updates as Unity touches many files.
     Although the sharing of the project was not frequent and the technology handled the load, the project itself resulted in having major abnormalities (although it is not certain that this was due to technical error). 
     To avoid this we must use clear development procedures that everyone is committed to. These procedures should consider how Subversion is to be used. Another aspect would be that investing money in the Unity Pro version should eliminate many headaches encountered during development of the Fly on the Wall.
• There was a lot of focus on creating a complete game instead of making sure that the game mechanics on the completed levels worked for the deadline. This resulted in technical solutions to streamline the streaming of the game.
     Next time around the game testing should be an integrated part of the development procedure that could be assigned to people not working on the actual game development.
• Using different types of graphical tools worked technically well with Unity. But from an development and support perspective it would be efficient to focus on only one 3D modeling package instead of three (Maya, Max, Blender)
• Level design did not take into account level load balancing that later required programmers to create add hock procedures to make a seamless game play experience. Next time around the project would benefit from including these aspects during initial level design.

Conclusion

We managed to developed a full-scale game with 8 levels that is currently playable online. The project was harder to finalize than expected due to the details required for believability. Despite this requirement the game ended up looking as initial requirements specified. 
   We hope that further development will be done on the game since there are some visual anomalies that need to be taken care of. But this depends on the financial aspect of the project.