Of all the things we could think of that went right this semester these were the three most common suggestions from the team:
- Taking in and applying user feedback
- Our art pipeline
Whether it was feedback left from Shbeeb or someone within the class our team took into consideration all suggestions. Most of the time those suggestions were implemented or built upon to create a better experience. The game from vertical slice to RTM is drastically different, all thanks to the great feedback we received. Using feedback is something we will all continue to use as we move on to other classes or into the industry.
The project’s success would have not have been possible without communication within our group. All members were very active on our Slack channels answering questions, giving feedback, and asking for help. Most members were more than willing to partake in weekly Google Hangouts. These were used to have everyone update the team on what they had been working on, where they were struggling, and to leave any other comments/feedback/concerns.
Thanks to our art pipeline we were able to produce a lot of content consistently throughout the project. We had established fairly early on that one member was handling enemies which included modeling, rigging, and animating; Another member was primarily texturing all models and the last member was modeling props to populate the world. As soon as a model was done it would be passed off to our texture artist, who would first place the model in engine for our programmers to work with, then texture the model. When they were done they would update the textures in engine. For the most part creating our assets was a fairly smooth process.
There were a fair share of things that went wrong with the project, these are the three most common suggestions from the team:
- Starting level design late
- Time management
- Source Control
Thanks to Hurricane Irma things started off pretty rocky in the beginning. As a team we constantly felt behind in a lot of ways up until vertical slice. One area of the project that didn’t really come together until too far into the project was level design. We hadn’t really established our levels up to vertical slice. Sure we had a general idea of what we wanted, but the designs, weren’t tested. What we found was a lot of walking, large empty areas, and nothing meaningful for the player to actively explore for within the temple. Had we accomplished and solved those problems by RTM? In a lot of ways yes, but there is always room for improvement. We think a lot of these issues could have been alleviated if we had started much sooner in designing and testing our levels.
Time management was a constant plague for us during this project. Between eight people our schedules varied wildly. From having four classes to part time jobs, everyone had a fairly busy schedule that led to severe bottleneck issues during development. We had established dates when things were due, however things were always seeming to come in last minute which caused others to have to work into the early hours of the morning to finish up before milestones.
I’m going to swap to me (Ben) really quick. As producer I feel in a lot of ways I caused some of these bottleneck issues to occur. Even though I had established due dates, I was fairly lenient on allowing extra time to account for people’s busy schedules. This in turn allowed people to work on things up until the last minute which caused other areas of the projects that were dependent on these assets to get behind. I apologize wholeheartedly and will take this as a learning experience and continue to improve.
Our biggest struggle this project was establishing source control. Because we were using Unreal to create our game, it required us to find our own means of source control. Initially we went with Perforce, however after waiting a number of weeks to get our licenses, it never came. We then moved on to GitHub as a temporary solution, until Perforce arrived, which caused our project to fall apart at vertical slice. Finally we landed on TortoiseSVN which ended up being a much better solution for our team. This solution wasn’t established until a week after vertical slice almost nine weeks into the semester. Rather than waiting on Perforce we should have just moved on to TortoiseSVN from the get go.
If we could work together again on the same project these would be the things we would change:
- Due Dates
- Source Control
As mentioned above due dates were not strictly enforced. This is something we would implement. If something is due on a certain date then it is expected to be completed. If the person failed to complete the task then we follow the guidelines put forth within the team contract we all signed. Sticking to due dates would make the development process much easier and we would have overall a much better game.
Establishing source control day one is another thing we would do differently. We should have never waited so long on Perforce. We were aware of TortoiseSVN and should have just used it from the beginning. This would have alleviated many headaches, failures, and sleepless nights if we had just established source control right away.
Tasks were handled for the most part through HacknPlan. However there were many times when tasks were too vague or didn’t have enough structure to help those who were assigned what to do. Something we would change is to have the tasks much more specific in the description section and break down a task with many parts into sub-tasks. For example we had a task for the Alien which had another task for texturing, and sometimes a tasks that had two tasks in its title. This should have been broken down into task, Alien and sub-tasks: texture, model, rig, animate, etc.
Ben Taylor | Steven Baeringer | Sak Vangpradith | Zeke Duncan | Kristian Acevedo | Chris Encarnacion | Matthew Goode