Adventure - Abandoned City

Introduction:
Adventure is a project by myself and two other students at Full Sail University where each teammate designed, created and polished a short level to be linked together with the rest of team’s to form a large persistent level. The creative vision required the design of each individual’s level to be a 3D adventure platformer set on a desolate Earth and to be separated in three areas with a small connecting area for each. My individual level centered around the player navigating a deteriorating hospital in an attempt to reach the other side of a decrepit city. The project was made in Unreal Engine 5.4.3 and used Perforce for version control and to backup the project. Many problems emerged, but just as many lessons were learned and new techniques and skills were developed before the end of the project.
What Went Right:
1. Player Advocacy – The intuitiveness of the level progression was the most important aspect when designing the level. Despite having lots of scenery and open areas, Adventure kept the player on the intended path. In addition, the breadcrumbs and leading lines felt natural and subtle as they perfectly fit the scenery around them. If an area was blocked off, there was an obvious reason for it in game like a semi-truck blocking the road or fallen debris restricting access to the other half of the hospital floor. The forethought of player advocacy during the block meshing phase paid off when the final assets were implemented as everything already had a purpose and place in the scene.
2. Level Integration – Linking together the five levels was smoother and easier than anticipated. The difference in creative visions and aesthetics made me worried about how they would all fit together as a whole. However, the landscaping of the three main levels came together well and added some continuity that helped mitigate the difference in styles. Not to mention that the starting area (the campsite) and the ending area (the lodge) were directly embedded in the levels instead of simply linked together. The flow of the levels ended up more streamlined than I could have anticipated which allowed me to focus more polishing the level.
3. Creative Design Process – During the block mesh phase, I made it a point to use the limited amount of space as diverse as possible. This meant that I had to use the space as much vertically as I could horizontally and helped with the initial idea of an abandoned building. With the help of a GDC panel by Naughty Dog’s David Shaver, I took this initial concept and grew outwards from the basic vision to exact details and designs. The idea of starting with a broad vision and building a world around it is the essence of design and I was surprised with how well I managed to follow it. Adventure was an exercise in trusting my ideas and keeping sight of a clearly defined vision.
4. Team Assistance – During production, there were many bugs and design issues (which will be discussed later), but these issues were mostly solved between team members. Since most of the problems stemmed from Perforce, they needed to be solved quickly to prevent a member from working out of sync. Any problem faced was left in the team’s Discord and solved as efficiently as possible between teammates. If no one knew the solution off hand, then the team would work together to solve the problem. This left each teammate more knowledgeable on these seemingly common issues and helped improve their problem-solving skills.
5. Final Assets – As mentioned before, when the level was still in the block mesh phase, most of the final assets were already thought of and anticipated. However, most of the finer details were worked out in beta when these assets were put in place. Some of the final assets were built from multiple assets to make something original that fit the aesthetics of the scene like the buildings and the roads. The asset I am most proud of are the holes in the walls and floors of the hospital since they were made using the modeling plug in and a rock mesh to give them a rough outline. Despite being restricted in the assets that I could find and use, the limitations lead to creative solutions that I never would have thought of without them.
What Went Wrong:
1. Version Control Habits – Many of the team’s problems came from poor version control habits that lead to constant setbacks. The most common problems were checking out unnecessary files for extended periods of time and being out of sync with the main branch. Often, a teammate would check out files and forget to submit them back into Perforce which left teammates waiting to work on their portions of the level. This also led to teammates making files writable which caused their version of the project to be out of sync. These problems got better as the weeks progressed, but never fully got resolved. The frustration of these setbacks ingrained better habits when working in version control at the benefit of myself, my teammates and the project.
2. Crunch – Partially due to the setbacks to poor version control habits and partially due to busy schedules outside of the project, the team consistently got most of the work done in the day or two preceding a deadline. This, in one way or another, led to one of the problems faced during production. Lack of time led to lack of playtesting and iterations which led to bugs and errors which distracted from more subtle issues like asset management and version control habits. The benefit of working under crunch is learning how to better work under stress, finding creative shortcuts and efficiently solving problems. Still, the benefits do not justify the risk of damaging player immersion and enjoyment, so time management needs to be a bigger priority in subsequent projects.
3. Asset Management – Everyone in the team made a bad habit of adding too many unnecessary assets to the game files. Some of the assets were brought in with the intention of being used but were replaced by more suitable assets while other files were brought in with other assets in packs. Either way, most of these unneeded files were not removed in time for the final build causing it to be bloated in both size and performance. This also caused organization issues during production and editing as looking for any specific asset was made difficult with the numerous folders to dig through. Cleaning up unused assets from game files is tedious and time consuming, so the better solution is to be proactive by only adding in individual assets as needed and purging excess ones at least once a day.
4. Bugs and Errors – Although the team was able to work out most of the bugs as they came up, the frequency that they occurred still took a significant time away from important areas of improvement. Most of the bugs and errors came from Perforce with some files being labeled as read-only despite not being checked out and “Getting Latest” not updated files forcing teammates to force update files. There also was a significant number of errors when packaging a build. Most of the errors were caused by broken aspect files and excess files attempted to be packaged. It took time to research and solve these issues without guidance, so they were written down and cataloged in a word document in case they come up in later projects.
5. Playtesting – Due to the amount of crunch experienced during production, there was not a lot of time to properly playtest each build. There were builds that were not each section was playtested leading to being soft locked from portions of the level. Most of the time, however, the problem was how easy it was to escape the map which could have been easily caught through proper playtesting. Not to mention that, at least in my case, I was the only one who playtested Adventure instead of having friends or family giving a new perspective on things. Most design problems are missed during editing which is why the lack of playtesting hindered the polish of the project both in design and aesthetic.
Conclusion:

Adventure was the first group production I worked on and much of my fears of working with others came up at one point or another. However, I can’t say the project would be better if I worked alone. Working in a team is a skill that needs to be developed through practice and patience just like any other. Any problems were handled professionally and were outweighed by the new perspectives, ideas and all the support we provided each other. The lessons I learned from this project are invaluable and unforgettable as I start my next project with a new team and fresh ideas.