Team Dire Wolf - Prototyping Project
Full Sail University - Online Prototyping Class
Over the course of a month-long class Full Sail University’s Online courses, I was part of a prototyping team that was tasked with prototyping 6 mechanics that have been done in the past. In the first week, we were tasked with prototyping those 6 mechanics and then iterating on 3 of them in the second week. In the final week, we had to pick 1 of the remaining 3 to polish and showcase in an example level.
Here is a quick run-down of what we did:
Week 1
We were tasked with prototyping 6 mechanics that have been done before. The mechanics we chose as a team were Throw/Recall Weapon, Gravity Inversion, Light Manipulation, Teleport, Portal Gun, and an Inventory System. They did not have to be perfectly polished, they just had to work enough to show potential. After all, we were a group of 4 students with only about 3-4 days to work on them at this point in the week. By the time we were done, 3-4 of the mechanics were working very well, and the rest did little more than function. But we were excited with what we had so far.
Week 2
Week 2’s main task was to cut 3 of the 6 initial mechanics and iterate/polish those 3. We decided we wanted to narrow down 3 mechanics that could potentially compliment each other in gameplay. These mechanics were the Portal Gun, – which was now called a Teleport Gun, since it could only teleport specified objects 1 way, unlike the Portal Gun’s 2 ways – the Inventory System, and the Gravity Inversion.
The Gravity Inversion was changed during this week due to a programming issue trying to figure out how to access a variable in Unity’s standard FPS Controller prefab that would allow the player to jump again after gravity was inverted. About halfway through this week, I decided that instead of spending more of our limited time trying to figure this issue out that we design around it. This lead to the Gravity Manipulation mechanic that we would eventually feature in Week 3.
3 Colored Cubes that each correspond to a specific axis in terms of inverted gravity.
Shooting at the green cube inverts it's local gravity to -1 on the Y-Axis.
Week 3
The assignment for week 3 was to narrow down our remaining 3 mechanics to 1 polished mechanic to feature. We were allowed to utilize those 3 mechanics but we had to choose 1 of those 3 to be the main focus and feature a level to showcase it. The team ended up deciding on the gravity manipulation mechanic. We ended up ahead of schedule by the time the weekend hit and decided to created our level based on a specific theme: escaping an alien ship. After deciding this, we focused on designing our level based on that theme. The following pictures are the final result of this:
Week 4
Week 4 was more so a break week. At this point, our final turn in had been turned in and our main assignment was to reflect on the project as a whole. A postmortem. Below is the postmortem I turned in and is the overall reflection of the month, what I learned, and what I will apply in future projects.
What Went Right
Getting in touch immediately and establishing communication.
From the very beginning, the team member that ultimately settled into the team leader role reached out to everybody on the team immediately the first Monday morning of the month to get the team together. We had our discord server/group together by the end of that night. Getting the team together as early as we could led to us also getting together to figure out which engine to use, making sure that our versions were compatible with each other if not the same version, and getting everything set up in Perforce. Once we had that done, we decided to have a weekly schedule in a Google Sheet that had our work schedules in it so we could schedule meetings accordingly.
After we got all that set up, we had a small briefing on Perforce and made sure everyone on the team was up to speed on using it. We did this by making sure we all watched the provided Perforce video and going over the main points in our team’s discord server.
Experimentation of programming.
I think one of the things that worked really well for us is that our team leader was very motivated and enthusiastic to program seemingly 24/7, which, at least for me, was inspiring and gave a bit of a morale boost that continued throughout the month. This morale boost also pushed me to experiment and to not be afraid of programming. He would ask the rest of the team members to do specific tasks or at least ask what we wanted to tackle. This pushed all of us to program things we’ve never tried before and to hone and practice our programming skills.
Going into the later week, we established that no one person would be working on a single mechanic. Everyone would work on all the mechanics in some way. Naturally, we settled into a mechanic each while still reaching out to any team members that needed some help or suggestions with what they were working on.
Changing course early on and adapting to a mechanic that wasn’t working as planned.
After getting Milestone 1 done, the issues I had with programming the Gravity Inversion mechanic were proving to be seemingly more difficult than planned. First off, I got gravity to invert simply by multiplying the scenes physics by -1 which was simple. But when interacting the Standard Asset>FPSController in Unity, having restricted access to the code even after opening it for edit, made what should’ve been something fairly simple into a much more difficult task. Once Thursday night rolled by, I suggested a direction change with the mechanic and to instead design around this constraint, which eventually led to the mechanic utilized in the final prototype. We found that it was more interesting and fun to play around with. Once the gravity start to work, we had an extra 2 days to mess with it more. So, I took another team member’s code for a portal projectile, inherited it with a new projectile and reworked that inherited script to contain the gravity inversion mechanic. The final prototype is the final product of the change of direction and I think it worked out better that way. What Went Wrong
Perforce organization and communication revolving around it.
While we did get a handle on Perforce well over the course of the month, there were a few instances when miscommunication or misunderstanding caused headaches or even larger setbacks, costing a few hours to fix in more than one instance.The first of these issues was having way too many files in our team’s project folder.There were standard assets, materials, effects, etc., that we weren’t using and were never planning on using.This began to cause organizational issues, especially when one team member ended up with an extra Standard Assets folder, giving us duplicates for everything.I think we should’ve taken care of this immediately instead of just dealing with it.It would’ve saved us that trouble and saved us valuable working time.
The Second and probably bigger issue with our Perforce habits was not communicating thoroughly with checking things out or working on something that someone else was working on. There were a few instances where someone would be working on something without checking it out first and then checking it out when they were done and submitting immediately after. Meanwhile, another team member would be working on the same thing and either overwrite the other person’s work or would get latest and have his overwritten instead. Thankfully, we didn’t have any catastrophic events from this but it was an issue nonetheless that could’ve caused a lot of damage and a major setback, which is why I felt it necessary to bring it up here.
Version issues interfering with putting together the Milestone 3 build.
In Week 1, we decided that for us to begin working, we needed to (at the very least) make sure that all of us had compatible versions of Unity. Meaning we needed to have versions of Unity that weren’t going to throw up a bunch of errors on a team member’s end for open the project from a different version. We had this working by about Wednesday of week one along with other tasks to get everything ready to go. Throughout the entire month, even though we had different versions of Unity, everything was working smoothly aside from a few MissingReferenceExceptions or UnassignedReferenceExceptions. That is, until we reached the final night as we were working on finalizing the Milestone 3 build. When I got the latest revision from Perforce (being the team member that usually produces the build), all the materials within our game were missing textures. Now, this normally wouldn’t be that big of an issue. It would take roughly 20-30 minutes to fix all that. Plenty of time. However, the scene was done yet. Other team mates were working on other finalizing touches on the level, meaning once that was done, guess what I’d have to do. Get latest and all of those materials would once again lose their textures.
In the end, one our other team mates produced the build on his machine which avoided the texture issue altogether. But in the future, I think every team member needs to be using the same version of Unity, even if someone must roll back a version. That’s the best way to avoid any unnecessary and avoidable compatibility issues.
There needed to be more understanding of each other’s code.
Since this was a heavy programming class, it seems obvious that everyone would be getting familiar with all the code in the project, not just their own.Well, in hindsight it sure is.In the first week, we only really focused on our own code while reaching out to each other to help or to get help if we were stumped on something.Since we were writing the first of our code, not much was there to be shared.
When we 2 and 3 started to approach, it began to become apparent that knowing each other’s code would have made working on the same mechanics a lot smoother. This easily could’ve been fixed by making a habit of thoroughly commenting in our scripts, having a meeting once every couple of days to go over any code that we edited or new code that we wrote. Whenever someone worked on someone else’s code, there would be far less confusion than there was.
Conclusion
Overall, Team Dire Wolf had a very productive smooth month. Deadlines were done early, save for Milestone 3. Communication was good, and problems were few and far between. While it was a productive month, we had our share of issues and it’s still important to go over them to make sure that they are dealt with earlier in the future for production’s sake.
