Team Cloud was organized to form a portfolio quality level using the March 2012 version of UDK. The team spent four weeks working together to design Ruin_ed. For those wondering why we chose this name it’s a play on Counter-Strike de_maps. Since this is a student project _ed represents education. So there is some thought behind it. Our first week was spent getting to know each other and start planning for our Alpha milestone. Week 2 we began to build in UDK and create a playable prototype of what we were trying to achieve. In week 3 we expanded on our prototype and started to create the type of setting and mood we wanted to show off in our design. By week 4 we were polishing the level adding lights and sound. As well as completing the terrain and other assets that may not have been included in earlier builds.
What Went Right
1. Team Cloud was a solid group.
We were fortunate enough to be paired up with a pretty solid group of students. Every member played an important role in the success and completion of this level design. We all seemed to get along rather quickly and enjoyed working with each other.
2. Every milestone was met on time.
Meeting milestones was never a concern. All work was completed or near completion in enough time to allow for proper testing, rebuilding, cook, and package times. All requirements for each milestone were also met. Huge improvements were made each week to the level’s design and encounters.
3. Combat gameplay.
I was pretty concerned with combat gameplay in the beginning of our project. I wasn’t sure if anyone on our team was capable of doing a good enough job to provide the player a challenge. Fortunately Team Cloud had Rashad Burnett take the charge in setting up our combat system. He did an excellent job at getting them to work, removing their errors, and any other weird bug that occurred during the development of this level. These pawns gave me a challenge even when I had them set to novice so I think we accomplished adding a good bit of friction.
4. There weren’t as many errors as expected.
Working on a project this large in an online setting worried me. I was very concerned with how we would all work on one level and how we would prevent each other from stepping on each other’s toes. Luckily UDK has the option to stream levels. With the combination of Dropbox and UDK’s streaming levels we were able to work in layers and prevent any serious issues from occurring.
What Went Wrong
1. Poor planning and organization to start development.
Unfortunately, I feel our team had very poor planning and organization from the start. We thought we had a plan but what we really had was just a bunch of gibberish with no real goal. If we had spent more time planning we could have done so much more. I think Ruin_ed is a decent piece of work, but if we had planned more I know much more could have been achieved and we wouldn’t have wasted so much time wondering what to do next. If we had planned better we all would have been on the same page more frequent and I would have felt less inclined what to tell other members what to do at times to help assist in the design process.
2. More streamed levels could have been used.
Due to members overstepping boundaries, roles, and authority a serious error occurred the day we were supposed to ship. This mistake could have been prevented if we used streamed levels for the player path, lights, and the castle. It was an honest mistake but it resulted in some unfortunate mistakes that were unable to be corrected in time for release.
3. Lightmass Volume was not used properly.
It wasn’t until very recently that I learned you can use more than one lightmass volume. I was told using more than one cause’s problems with UV overlapping. As the team lead I take full responsibility in this issue. Having three or four lightmass volumes throughout the player’s path would have optimized the level greatly as well as sped up the rebuild time for lightmass. Production Build took six hours to complete.
4. Rules, roles, and authority were loosely followed, almost forgotten.
As mentioned earlier, a team member attempted to make corrections the night before release and as a result it cost the project greatly. The rules, roles, and the powers of authority should have been made more clear. This problem could have been prevented through regular reminders in team meetings. As the team lead I thought I had made it clear that I would be making corrections to design decisions or concepts to tighten them up or make them more organic to the environment. Another way this situation could have been avoided was to make sure every team member had the proper packages for custom assets such as fractured static mesh, and lights that shoot out. It was an unfortunate set back, but the team overcame and we got through it together.
5. Some team members may have lost enthusiasm for the project towards the end.
I feel that in the final week a couple of our team members really lost interest in the project. Either because they felt the project was done or because they felt there was nothing left for them to do. Whatever the case may have been I was really hoping that in the final week we’d really come together more as a team and “game jam.” We never seemed to find a rhythm together. I know that our schedules are greatly different but there was never a time when I felt that the gang was all there. I didn’t want the development of our world to end. As a result, I kind of felt like we missed out on what could have been the best week in the entire development process. I enjoyed staying up late and putting in long hours and filling out the world to feel alive and vibrant.
I’ve enjoyed the time I and the rest of the team have put into this project. I wish we could have spent more time working on it and making it better. However, I believe if we had spent more time planning and preparing we could have achieved all of our goals and added more pop to the rest of the level. I would have spent more time going over simple guidelines with the rest of the group to prevent some of the errors we had. I would also encourage them to try new things for our level design. The biggest lesson I learned from this is to spend more time planning and outlining at the beginning of development. It will save time and can even reward you with extra time to meet other features or design choices.
The standalone level installer is available here https://dl.dropboxusercontent.com/u/11348542/Ruin_ed.zip
If you have any questions, comments, or would like contact information for the other team members please contact me at docrogers at fullsail dot edu.