ASCore SCRAPS Postmortem
Introduction
During this project we worked on a game called SCRAPS. SCRAPS is a post apocalyptic game where you play as a Scrapper trying to earn your way into a better life at the Bastion. A Bastion is a safe haven from the Wasteland where the rich and powerful have taken refuge. These people are called Bast's and they use Scrappers to do their dirty work with the promise of a possible spot at a Bastion.
With the background out of the way. This was a 3 month project where each member of the team acted as a level designer. During the first two months each designer worked solo creating a level design, learning the SCRAPS systems, and implementing unique game play mechanics for their levels. Each designer created two mechanics to implement in their level and the level needed to be structured in a way that the Scrapper was doing a task that would help the Bast's status inside of the Bastion. After the first two months we assembled into 4-6 man teams and merged our levels. During this process we made a seamless game that allowed the player to start at a Scrapper outpost, run through each of our levels and complete the tasks within that level, and end with being admitted into the Bastion. This was a crash course for a lot of students and it took each of us through the whole development cycle. There was a lot of ups and a lot of downs throughout the project and by the end of the process my team was able to create a fun experience for the players.
We wanted to be a little different and have our levels feel more cohesive. So we decided that our levels were based on a military base island. This gave us a design philosophy to ensure that all of our levels felt like you were in the same setting and not moving around the world. We created cut scenes and added terrain to each level to make sure the player felt like every location they were at was an island.
Lets go over some of the things that went right and some of the things that went wrong.
What went right
1. The overall level concept:
Through the whole project this stayed constant and did not need a lot of tweaking. Because of this I was able to focus more on the game play of the level and incorporating the mechanics.
2. Mechanics:
The two mechanics that I selected for this level, explosive objects and object snapping using the gravnull gun, worked really well with the level theme. The development time to create these mechanics was well spent and the overall design of the mechanics did not need to be modified much throughout the project. Which allowed for a lot more time devoted to other aspects of the project.
3. Cut scenes:
During the team project phase when we integrated the levels we decided to make our level an island and needed to provide the player with a way to get to the island. One limitation we had was we could not use a different player controller, meaning they could not drive a boat or car. But we could use cut scenes, and with permission from the creative leads(instructors) on the project we did just that. The system was easy to implement and we were able to get this step taken care of quickly allowing us to move forward with our creative work of creating a believable island.
4. Teamwork:
Overall teamwork was a huge success on this. We were able to bounce ideas off each other well and identify problems with our levels quicker. Which allowed us to have quicker iteration on our levels to make improvements.
5. Beta testing:
The beta test cycle really helped identify issues in our levels. People outside of our team critiquing and playing our levels differently then we would have gave us a much better insight on the flow of our levels. When someone doesn't know what to do you really learn how well your level is teaching them or not teaching them. This cycle made the playable levels much better.
What went wrong
1. Trying to take on too much:
For my level I wanted to add so many things through code. But I needed to spend time actually making a playable level. So when it came down to doing both it was a cluster of scrambled ideas. So instead of nice clean code that is well defined the level ended up with a jumbled mess of code. Even though all the code worked and was able to do what was needed it would not have been easy to extended into something else or to make major modifications if that had been required. That is a dangerous place to be.
2. Meeting scheduling and availability:
While this was mostly out of our control and based on the circumstances of us being online students. The fact we had different availability made certain things that we all needed to be a part of harder. Mainly our Gold videos at the end. This was/is compounded when a member also has a life event happening, while they can't control that and it is no fault of theirs it really compounds the problem.
3. Unity Terrain:
During the last two months of the project the Unity terrain fought us. Especially anyone who had underground parts to their levels. In the last month when all the levels had to be merged together this was even worse. We spent A LOT of time checking our terrain seams to make sure we did not mess up a neighbor when we edited our terrain or a transition terrain. These are only some of the problems we had with the Unity terrain in this project. In the future I would probably attempt to use a height-map and create a single terrain for all the levels. Or at least matching height maps to ensure snapping the levels together worked properly.
4. Perforce:
While this was a minor thing and more of an inconvenience it is worth mentioning here because it did eat up a hefty amount of time for some team members. This issue that was faced was server timeouts for the team members with slow connections, which would cause us to spend a lot of time re-uploading changes or downloading other team members changes. Especially when there was a lot of files or there was large files.
5. Trello:
Trello and agile development are great tools. However, this month I do not feel like the team leaned on it enough. Me personally I did not do a good job with the daily stand-ups. The board could have been used a lot more for collaboration and tracking. A lot of times we just fixed things and didn't say anything when we could have been creating cards so the fixes could have been reviewed. In the future I will try and help my teams rely more on Trello, or any other type of Agile sprint tracking tool, boards to help keep us organized.
Conclusion:
This project was a shock to the system for almost everyone involved. Even for me and I have made some games in the past, but I did not have the time constraints on those projects that this project had. I found out quickly how much that changes everything. This project has shown me in the future how much more white-board time I will spend off the bat so that when I get down to actually creating a level or writing code I can do it efficiently and with a plan/goal to keep me focused. This has been one of the best personal learning experience during my time at Full Sail.