Game Description

The Truth Beneath the Park is a walking simulator inspired by the gruesome history of Washington Square Park. With the research on the park, the goal of this project was to heighten the player’s discomfort. They explore the park as it is in the modern day, but eventually will find themselves walking on those same grounds in the 18th and 19th Centuries. The two notable events in the park’s history are the Potter’s Field, and the Gallows. Towards the end of the 18th Century, the New York Government purchased the land and turned it into a burial place for indigenous and poor people. It is possible for the player to encounter an eerie graveyard, or even an old gallows with its noose in working condition. Washington Square Park wasn’t always as joyful of the sight it is today.

MergeCon Games team members + roles:

Daniel: Asset Modeling (Past Park), Communication, Troubleshooting

Connor: Effect Scripts, Hierarchy Management, Components

Chloe: Sound Scripts, Skybox, Scene Management

Alexander: Asset Modeling (Present Park), Hierarchy Management, Components

 

Screenshots:

 

Game Builds

We mentioned this to Grayson in class, but the transition functionality (between past-present park) breaks for us in the built version, but works completely fine in the editor. We’ve spent a few hours trying to fix it at this point but nothing seems to help and we’re kind of stumped, so we hope it’s okay that it doesn’t work properly in the final builds. If you’re feeling generous and are willing to look at our editor version, here’s a link to it: https://drive.google.com/file/d/1Tepbo-840wIPJKbXfHYj1gOnoFeF4ChS/view?usp=sharing

PC Build: https://drive.google.com/open?id=18drG453rrn3onwWooM1DxFPRxGy2jUWf

Mac Build: https://drive.google.com/open?id=19lX69x1Ks4XcjJGDKTeaFnd2gpcECq0h

 

Postmortem

Introduction

Set in New York City’s very own Washington Square Park, The Truth Beneath the Park tries to recontextualize what is to many New Yorkers a comfortable and familiar space, and reveal parts of its uncomfortable history. Taking the form of a Walking Simulator, the player navigates around a recreation of the present day park, finding themself confronted with scenes from its very real dark past.

Our team, dubbed MergeCon in honor of the numerous merge conflicts we faced from Github, was comprised of Connor Ritchey, Chloe Page, Daniel Narvaez, and Alexander Thornborough. Connor was responsible for the vast majority of the game’s scripting, a significant part of the scene assembly, and endless troubleshooting when things went wrong. Chloe managed the sound design, assembling soundscapes and writing scripts for them, as well as placing them in the game world. She also drew and implemented the skybox, and did some lighting and additional minor scripting, and together with Connor took the lead on historical research. Daniel created the assets for the historical scenes and assembled them in the game space, and took the lead on group communication, troubleshooting Github, and managing the playtests. Alexander created all the 3D assets for the modern park, its flora, and assembled the modern scene. He also did some minor scripting and created the menu. 

The first collaborative game of significant scope by any of the members of our team, it’s perhaps unsurprising that we met a large number of challenges, although we think we had some notable successes as well; we’ll go into more detail on both below, as well as ways that we hope to overcome similar challenges in the future, and learn from both the good and bad parts of what we faced.

What went right

1. Concept Dev Time 

 

The members of our group were comprised not only of those who were unfamiliar with the process of group game development, but also those who were unfamiliar with each other’s work styles and strengths. However, on the first day our group sat down to discuss which direction we wanted to take our walking simulator, our concept unfolded in a quite natural and equally thought out way. Rather than have our game embody a specific emotion, all four of us were in agreement that we would rather focus our time on creating an experience that would generate an overall feeling. We each shared our interests both from a design standpoint as well as a research standpoint and quite quickly found a topic all of us could genuinely invest our energy into. Our group’s immediate ability to communicate in a way so that every member’s thoughts and opinions were fully heard benefitted us from game conception to development. 

 

2. Dividing Tasks/Roles 

 

Much like how our game concept unfolded quite naturally, our dividing up of task roles was fairly painless as well. Each member of our group was able to oversee areas of the simulator that they were strongest and most interested in. Connor opted to handle the bulk of our project scripting, Chloe handled audio design, and Alexander and Daniel were the physical asset builders of the simulator. Each role we assigned ourselves were quite equal when it came to workload, time, and energy spent troubleshooting. There were no major concerns throughout the development process of one member not pulling as much weight as others. Through communication and an overall drive to flesh out our game as best we could, our group was able to stick to our task lists and get our jobs done.

 

3. Whiteboxing 

 

Keeping with previously explored best practices Connor created a separate unity project to perform all script tests in a closed environment. Using basic cubes and placeholder image assets where needed, he was able to demonstrate all requested functionality well before there were assets to use in the main project file. Having a functioning whitebox environment allowed Connor to test each iteration of the scripts as bugs and other issues arose when applying them to the live models.

 

4. Artistic Consistency 

 

In the first meeting, our group discussed at length the artistic style we hoped to achieve; we made it a goal to create all of the assets ourselves rather than relying on Unity’s asset store, and so we laid out a style that we thought would allow us to create them rapidly enough to accomplish this in the limited time we had. We quickly settled on a low poly look with flat colors, and extended this to both the models as well as the skybox, keeping it in mind throughout the development process. During playtests, this consistency we achieved was a recurring comment of praise, so we consider it a significant success.

5. Communication 

 

From the start of the project, Daniel made sure that the group had the necessary components needed for the group to work collaboratively. Before any concepts were even discussed, he made sure everyone had each other’s contact information. Two methods of communication were made, with one as a backup. It was also made clear that no two people should be working on the project at the same time. This allowed the group to git push changes and have the next person pull to begin their work on the project with ease. Making sure that everyone knew what their tasks were was also a big part of the success of our communication.

 

What went wrong

1. Github 

Although issues with Terminal were attempted to be kept at a minimum, we struggled a lot with github. The first obstacle was a result of only two of us knowing how to use Terminal with github, and the other two familiar with using the Github desktop app to push/pull changes in a repository. When we started working solely in Terminal, another issue rose. We initially had more than one person working on the project at once, which was stopped after the first 2 or 3 merge conflicts. The other problem was the code in the .gitignore wasn’t ignoring any .meta files (we later discovered it was because the .gitignore wasn’t in the root directory of the Unity Project). That caused us the bulk of our troubles, and slowed down development by a lot. We do, however, strongly feel that a lesson on using Github + Terminal in groups would definitely help in the future.

2. Time Management 

 

Everyone works at different times and at different paces. Projects as dynamic as unity often includes staggered workflow, where the next team member has to wait for the previous to finish their work prior to starting their own. Initially this didn’t present a problem as each of us had plenty of tasks to focus on simultaneously, however, when it came time for the final build it was clear we had not effectively managed our group’s time. In the future, having one or more group members create a project schedule seems imperative. If we had spaced out our work more consistently we would have had more time to debug the final build and could have presented a better representation of the hard work everyone put in.

 

3. Too Large a Scope 

 

The main features of our walking simulator revolved around notable historical points along the timeline of Washington Square Park. After a few rounds of research, our group came to the agreement that we would narrow these historical points down to five. These five points were each to be represented by corresponding key assets and included: a creek, farmland, a hanging tree, gallows, and a potter’s field. Each of these points were also to be paired with corresponding soundscapes and a handful of scripts attached to them in order to make them behave and transition properly. In the following weeks, however, it quickly became apparent that each historical transition would take much longer to flesh out than expected. The majority of all of our efforts were spent on developing the modern day park which left less time for the historical elements. As a result, we were forced to significantly narrow our scope from the initial five key points to only three: the farmland, gallows, and potter’s field. In the end, we found that these three points were all our project required to convey our concept and mood effectively. However, had we known from week one that we would only be tackling three points, we could have spent much more energy on developing them instead of spreading out focus thin amongst five.

 

4. Inexperience/Unfamiliarity With Software 

 

Unfamiliarity with the software used and the constraints it imposes is probably a virtually universal issue among novice developers, and unfortunately it was a problem for our group as well, and in several significant ways, one of which especially has been unfortunately extremely consequential for our end product. 

The first problem was because Alexander imported the first set of models from Maya to Unity in a way that didn’t interact well with the scripts, dramatically increasing Connor’s workload at a point in the project close to a deadline (not helped by the aforementioned time management issue). The second problem we ran into in this regard was when the main scripts Connor made for fading in and out the historical scenes—which we had planned all the historical encounters to revolve around—turned out to be impossible to scale up to the whole scene without Unity lagging significantly. This forced us to change how we handled that part significantly, and frustratingly, made redundant what had been a major part of the effort that had been spent on the project. The third issue is the worst of all, and unfortunately is one we haven’t been able to work around despite our efforts: a script that seemed to have been working perfectly in the editor no longer functions in the built version, in our case one that controlled the fading, which breaks a significant part of the functionality of the historical-modern transitions.

Ways we could resolve this probably vary significantly case to case, but doing frequent tests on how we’re going to approach implementing functionality (like these instances) seems like it would be helpful. The final issue seems simpler to resolve; going forward, it will be necessary to create test builds all throughout the entire development process, rather than simply relying on the editor. 

 

5. Scheduling 

 

With each member of the team having different schedules we found it incredibly difficult to meet in person. Focusing on using our in class time as efficiently as possible, it’s clear that the lack of additional meetings ultimately left us scrambling to compile the separate pieces into one completed project. In the future, requiring a minimum of one outside of class group meeting each week is much more likely to keep everyone on track. Beyond that, assigning a member of the group to spearhead scheduling and other project management tasks seems prudent.

What we learned

Our struggles with scheduling and time management are indicative of the lack of a project manager, or similar role, on our team. While any of us could have performed this task, the group collectively chose to keep management individualized. Coupled with the lack of in person meetings it allowed us to become complacent about the realistic deadlines this project presented. In the future we will hold the administrative elements of our group projects in equal importance to the various creative aspects to ensure that everyone can have the time they need to do their best work.

One of the biggest takeaways we have learned regarding scope is that although it is good to think big, it is important to start small. Keeping a larger goal in mind while creating a game is very good practice for keeping production moving forward. However, if you spread your time and energy thin amongst different areas of a project in hopes to achieve this larger goal, not only will the project not reflect the effort put into it, but also game production time will be significantly slowed. By focusing on a smaller scope to begin with and then branching out to other goals if time allows it, components of the game will feel more complete and well thought through.

Many of our problems with new software are probably virtually unavoidable when approaching them at a novice level, and for the most part might require experience to overcome, but there are certainly some steps we can take to minimize the damage they pose in future projects. As was mentioned previously, managing our time better will have a very beneficial effect for this too, since many of problems we face are solvable if there’s more time to deal with them than the night before a deadline. Frequent tests are going to be essential going forward, whether they’re for how certain functionality scales up (such as with our issue with the fading script) or simply to check that nothing breaks when the game is built, even if things appear fine in the editor. Finally, more collaboration between different parts of our team, both to draw on knowledge from each other when things do go wrong and learn rather than facing the same problem repeatedly, and also to consult about what the best approach two team members could take to minimize each others’ extra work.

It’s definitely a different kind of experience working in a group. Most things that are simple done solo become much more complex. As stated a couple of times already, lacking the fundamental skills for sharing through github/terminal are definitely required for making games. We also have learned to plan more playtests. One practice that was often made use of in the past was to playtest in small portions rather than adding a chunk of the game and testing it all at once; it’s easier to find out what goes wrong and where. Also, it’s not exactly team-healthy to leave one type of task to one person alone. There should always be at least two people working on scripts, two on assets, etc. This minimizes the chances of there being errors. Lastly, scope is still relevant, regardless if it’s one person or four people.