Richard Dalm's Portfolio
Postmortem
Postmortem: The Hidden Sands
Introduction
During the summer of 2016, a team of six different individuals were grouped together to create a visionary game based on the idea called SCRAPS. SCRAPS is a game set in the apocalyptic future where the world is nothing but a barren desecrated wasteland. The player will play as a character known as a Scraper; someone who is on the lookout for valuable items for the remaining population that exists. The project began with multiple prototype concepts later to be integrated and created into a single game in less than a month. While the determination to finish the project was strong, the amount of time the team spent together constructing the game became taxing. Like any project, there are many hurdles before the finish is reached.
What Went Right
-
Gathering the Team
The month began with teams being chosen by the students. The class was given the option to group with either four or six students to complete this project. Our team was instantly put together within the first days of the class start and consisted of six individuals. We placed ourselves under the team name of Daikon and began introducing ourselves formally.
The reason we decided to group together was because five of us were in a group project prior to this month. Amongst the five of us, we knew strengths and weaknesses of each other and had faith in our prior experience that we could get this project done. With the addition of a new, strong, and dependable member the team was set to complete an awesome project.
We started immediately on the project once the team was put together. This was exactly the kind of start we needed at the beginning of the project. Everyone took roles, positions, and began covering basic operations to create the project as soon as possible. From the beginning, we had a cohesive team with several proud moments.
2. Building the Blocks
One of the first tasks we faced at the beginning was what tasks and roles (bases) needed to be covered by the team and in what order. The very first base that needed to be covered was team leader. Then the second base was the team charter, which stood as a pillar to hold the team together throughout the project. The third base was actually figuring out our level map layout. And the fourth base was putting the map together officially, rather than just something on a piece of paper. With these four bases that our team needed to cover, we immediately began scheduling our work times to focus on the project tasks.
Deciding who was team leader was more tricky than we originally thought. While any one of us could be team leader, only one could take the throne. A few bowed out because they needed to be prepared for their family in order to tend to them. Ultimately, the decision was passed down by vote and the team leader was chosen. The throne was taken by myself and was respectfully accepted.
Our team created the team charter to showcase the bond amongst ourselves and commitment to the project. The criteria we labeled for the team was much like the previous project five of us completed. With a new project and an additional team member, we constructed a team charter that signified our beginning bond to the project. Everyone’s responsibility to abide by the charter was enforced upon creation. Enforcing the charter went really well considering the motivation to start the project.
When we were deciding how to put our project together, we sat in a meeting and discussed the ultimate goals we wanted to cover throughout the month. After that, we took our previously designed areas of SCRAPS and combined them into an entire level. We took the time to really think about how the entire level was going to flow. The discovery of who had what concept and idea in their area helped stage the setting of the level. This also helped envision transitions from area to area. To illustrate the flow of the level, we drew a map to help visualize our player’s path. This process was extremely helpful as we not only discovered how our design for the project was going to be set, but brought the team to understand each area and flow of the map.
Once the map and flow was established, we needed to put the plan into action. The transition from concept to establishment was rather simple. Everyone set up a personal folder, on a structured server that was handed to us, and placed their areas inside. One member grabbed all the areas of each team member’s personal folder, placed all the areas into one project folder, and submitted the project folder inside the server for the entire team to download. This process really showcased the power of the team. Everything for the project was made to be mainstreamed and obtainable quickly by the entire team to complete work efficiently.
3. Sturdy Flow
Under our team charter, we listed the days that the team would meet accordingly based on time zones and time frames of everyone. However, some team members met every day and almost all day. This was extremely helpful in the process of getting work that others could not handle done. Also, exploiting more ideas and mechanics helped balance out the problems the team was facing. The result of meeting every day, as well as almost all day, is really showcased when playing through the level.
When deadlines of the project were sent to the team, we made individual deadlines of what needed to be done today, tomorrow, and the week. When individual deadlines were not met, team members rallied together in order to solve and resolve any problems that the individual team member was struggling with. This entire project was not just an individual effort, but a very sturdy and cohesive effort. While keeping the solution simple to save time, we managed to help an individual team member see new concepts they can do to save themselves time as they work. When the individual deadline was solved and done, a stronger bond was made amongst the team to ensure the next deadline the individual would make is done quicker than before.
Through the entire project, the collaboration was extremely intense amongst certain team members. Members of the team would help one another in tasks, bounce ideas off of one another, or discuss future possibilities for the project. Without strong collaboration, the project would have been even harder to pull together and finish. Each of us had talents of our own that would really shine if put in the right area of work. When collaborating with a team member who is really good at something they can do, anything can be made possible given the right time and focus.
4. The Ideas
Once Alpha was put together, our team really needed to create concepts in the areas that involve player involvement. Rather than just give an area for the player to complete and move on, we decided to come up with mechanics, objectives, and motives for the entire level. We held meetings to determine what the player will be introduced, practicing and mastering by the end of the level. Concepts that were fun to use were shuffled into all the area. Two great examples of this were Ian’s concept of platform jumping and Stephen’s hammer.
Ian originally came up with moving platforms that the player will jump on to traverse above the ground. The idea was interesting and fun to watch. We took the platform jumping and extended the idea through the entire level. Except, everyone had their own personal twist they put on the idea of platform jumping. Thus, bringing the team even closer to understanding each area. This was the first real introduction, practice, and mastery concept that the team came up with.
But the platform jumping was not enough to say that a player has fun just jumping. As a team, we really sat down after our Beta submission and thought about what everyone was using the most. Ultimately, the hammer was being used the most throughout the entire level. Thus, Stephen’s hammer was decided to be a collectible item that the player stores in their inventory. Once the player collects the hammer, they can spawn the hammer from their inventory to summon it whenever the player needs to use it.
Matthew had a “pipe-bomb” script he made before Alpha that allows the bomb to be spawned behind the player to use. Combine the script with the hammer and the hammer becomes the soul of the entire level. What more fun can the player have than to run through a level and destroy stuff? This was an ingenious idea that brought the team to laughter and happiness.
5. The Cohesive Stretch
When looking back at the whole project, the memory of having team members that really wanted to work on a project brings joy and pride to my mind. We really wanted to have fun during this month because this was the process of making an actual game. There were moments of just crazy concepts that made every one of us laugh and chuckle as the idea and vision of it floated across our meetings. This brought the anxiety of the team to a minimum as the weeks continued. In fact, it was important to have meetings where we could be ourselves and think of the fun creating a game.
Then those meetings became really special. The floating ideas in the meeting and the lessened anxiety made us step back as a team to view our game as a whole. The importance of the meeting where we continue brainstorming ideas and mechanics became necessary. The cohesion was really developed during those meetings to bring the areas together rather than apart. Each member was so focused on their area that they lost sight of what was fun about the game. What we really wanted was a level of SCRAPS that was fun and can be remembered as a project for the other teams of the month and months ahead.
What Went Wrong
-
Teammate Lives
One of the most prominent problems we had all month was personal lives outside the project that each member had. Among the team, three of the members were fathers that tended to children under the age of five. While managing their school life and project work, they also had to take care of their children. This put deadlines on hold, loss of time on the project, and loss of focus during the project. If the team member was not focusing on the project intently, more problems were being created from their work; which required other team members stop what they are doing to help fix the problems that were happening.
This especially happened during our Beta creation, because one of our team members just had a death in the family and a funeral to attend. Their mind was amiss when doing project work, tending to their child, and helping their wife. Another team member struggled with his twin three-year-old sons. He would constantly have to make sure that they were settled and calm before returning to work. However, that was not very likely to happen because of the twin’s personalities. This dampened his emotion and drive to continue to work on school work which reflected on the team’s responsibility to cover any lost time.
Then there is the miscellaneous category of team members not showing up or caring about the work. This was a cause of lost time throughout the project. The team members that cared for the level let their area suffer to help the members get caught up if they missed days of work. Deadlines and time really resulted in being lost when handling others work or getting them caught up.
2. Emotion
Like any group project or activity, emotions hit people the most in terms of completing a huge project. The most impactful emotion to hit a team is something that is negative. Our team was no exception to this abrupt negativity. All of the team members had an attitude or emotional problem that occurred during each week of the project. Differences arose, conflictions, and complications just started happening. Members would blame another’s actions for not doing something that was mentioned during a conversation. Or having one team member come up with last minute concepts which angered another teammate because they felt that our level was fine as it was.
The mood of the team would shift from being decent to very poor when emotions started running all over the place. As team leader, responsibility for the team’s course of action was the best resolution for situations where emotions were high. A consensus was held while each member decided the direct course of action to simmer the raised anger. The consensus helped calm people down during the situation, however this did not solve the angered team members had over another team member. These moments were especially prominent during our Beta and Gold project times.
3. Responsibility
If one team member could not complete the task, change their attitude to help, or be absent because of their life outside the project, the responsibility of finishing tasks was placed on team members that were available. And when the team member that was available to help fix the other team members' problem on their area, their work suffered immensely. In order to support the project and the team members that continued to care for the project, the team leader took the work over their shoulders to help support the entire team.
There were some team members that cared to help solve the problems that were placed on the team leader’s lap, but they could not help with all the problems because they had their own problems to solve and fix. This sort of responsibility angered the team members that cared for the project. Judgment and negative thoughts on the other team members that did not care began to rise amongst team members. Rifts of collaboration between team members started to build which split the team entirely into pieces sometimes.
A great example of this was before our Beta submission. There was a team member who was not pulling their weight enough on their work and being lazy. He eventually saw the messages of the team’s thoughts about him. He confronted the team leader and a huge discussion took place. The discussion went well overall but ultimately his work ethic continued to remain the same even after the discussion. Which the other team members took into account during Gold and were silently still judging him. As team leader, the responsibility of making sure the team member’s work got finished was addressed by the leader himself to ensure the project stayed on track.
4. Milestone Submission Time
Near the end of the milestone deadlines for the project was where our team really suffered. The individual deadlines and tasks of one teammate were always right up to the last minute during Alpha and Beta submission. The teammate had an extremely large area to cover and complete, however, they were also the most knowledgeable in terms of programming. His skills were needed prior to submission of Alpha and Beta because others were suffering from system errors. These errors could be fixed if he was looking at the code and focusing on the problem. But the time away from his area ultimately led to a last-minute patch job to submit his area for the project on time.
We had other members that were knowledgeable in terms of programming but were absent or missing during the course of the project. The selfish nature really showed that the team member that was absent only cared for their own submission rather than the team’s overall scope of the project. When the project milestone was nearing, the teammate would show up and begin helping at the last minute. The realization never occurred to them that these problems existed unless they showed up around the milestone turn in. We then had to do “patch-work” to solve the solution just to submit the project in and then really fix the problem after the milestone was reached.
Other moments before milestone submission include teammates that struggled to complete tasks that they forgot or did not finish. Which was taxing on them because they were not helping to see the entire scope of the project. We were all caught up in our minor details that the project suffered from actually being fun to play during Alpha and Beta. Then we had one member sit there and do nothing except complain that the project is not done. The team leader finished his area for him and he was blaming the others for not completing their work. The entire milestone submissions were a mess right up to the day the project was due.
But even with all the complications and problems, we managed to bring together a project even under the rough circumstances. The delivery was the most important aspect to the team. We delivered what we were most proud of to the very end. However, all of the tension and stress would have been mitigated if the team was together constantly every day rather than in small time frames or for meetings.
5. The Helicopter
Out of everything that went wrong during this project, nothing beats the night of the submission for Beta. Disaster struck when we realized that the helicopter that lifts the player and transports them to the next area was broken. When nearing the end of the night before the closure of Beta submission, everyone downloaded the build on the server to check for problems one last time. The only bug that was significant was the helicopter.
Upon reaching the helicopter and traveling to the next area, players are spawned in different random locations around the level, in the next area, or not spawned at all because the game crashes. If the player was spawned in the next area, their character would be broken because the transportation of the helicopter changed their settings. Such settings include the use of the “Gravnull” system in the game, which allows players to grab objects in the map and movement of the character.
Upon finding this gigantic problem inside our game, the spirit of the team began to sink like the cloudy night sky. We were panicking to fix the problem as quickly as we could before the submission deadline. But our time for submission was not being reached and the frustration became very enticing. We sent an email to our instructor letting him know our situation and notifying him that we were in the process of fixing the problem. After two hours of the deadline’s submission time, we fixed the problem. However, the spirits of the team were really low.
The night taught the entire team to really focus on troubleshooting and passing any information that is wrong with the game around to all team members. The importance of knowing what problems may occur was something that needs to be addressed no matter how small. Any one of those small problems may lead to a game-breaking problem at the end, which makes the entire project crash and may cause the entire team to fail.
Advice to Future Students
The advice I can give to future students is to have a strong team leader that can inspire, rally, and mitigate the team’s problems. The team benefits from someone that can hold the team together and is always there when they are needed. Choose wisely the person that best represents the team and the interests of others. Because that person will put the team on their back to succeed through the arduous project. The position of team leader is not something to be lightly taken as it is the very last pillar to fall upon when on a team.
Conclusion
Overall the experience of making a game in a month was intense and eye-opening. There was much to learn from each team member since our talents at this point in the Game Design program were sparse and different. The personalities were also interesting and easy to get along with as the project kept going. As team leader, the pride of working hard and being successful throughout the month is very heartwarming and rewarding. Even as we near the ending of this project, the team still wants to continue to work on the project to make the game even more special. For the future, projects like this will be remembered and thought about during new projects.