The Cult, as a game, our team felt confident with. Even with the game being cut, we are still happy about how it is today. There were some weaknesses ingrained in the game, but there was also a lot to learn from my perspective, especially since there were a lot of new things in this project for me when I had first tackled this semester. I have never worked with any of my team members before, I had never made a horror game before, and I had never done a major project in Unreal Engine 4 before.
What Went Well
Despite my first time using the engine, Unreal ended up being quite easy to get into. Additionally, my teammates had experience in it which made integrating features together a breeze. Once we got into a workflow, development was smooth when adding or iterating anything in the game.
-There was a workflow, and it took a while to become natural-
The beginning of our project was slow, considering we spent a lot of time concepting, but our eventual work on the final idea changed the rate of our progress and the efficiency of our work grew as we worked on new features. We never overstepped our scope while working on the game, and this was good considering some of the large risks concerning the heavy scope our game had, like the art-heavy mansion environment. By the time we were creating the final level, the processes of creating for the game became relatively straightforward and effective.
-Key to smooth communication is being honest and responsive-
I had never really met anyone on my team before, so going into this semester, I was not sure what to expect. What I was glad to realize is that we never had major conflicts with each other over the course of the semester, and that all we needed to do was send a message to the team when we get something done and the need for daily scrum was unnecessary, since these messages took its place.
-Fast prototyping meant fast builds meant getting lots of opinions through QA-
Something else that went well with the team was how fast our programmer put out prototypes and features as well as how fast our artist put out assets. While working on the first phase of capstone, where we needed to test at least three different concepts, this really helped out when we were a week behind most other teams' prototypes.
What went wrong
The most important thing I realized this semester was that I should have tackled the things I struggled with by reaching to faculty or giving myself more time. When I had problems with certain tasks over the course of the semester, I would try my best and leave them as is. This ended up making certain aspects of our design very lacking.
-Threw off narrative for a long time-
When we had finalized the concept of our horror game, one of the first things we were asked was what the narrative was gonna be. In response I created a backstory for the player and enemies they would encounter. But as the weeks would pass, there was always something wrong. The backstory didn’t cover how the narrative would be told in gameplay or how this narrative would add to the fear in the game. By the last two weeks, I had decided to meet with a professor to assist with the narrative, but by then I knew it was much too late to patch it up.
-Took forever to integrate evidence-
A single mechanic that had made our game unique in the beginning of prototyping was just moments away from being completed for a vertical slice, but we had decided to move the direction of our game that didn’t rely as heavily on the evidence mechanic. This was rather unfortunate, as it seemed a bit more work on the evidence system to implement it would have added a lot of narrative weight that the game is missing.
-Concepting took long, and had NO docs involved???? What?????-
At the very beginning, we spent a lot of time researching and developing ideas and minute-by-minute gameplay for our client, who was helping with the prototype by reviewing our ideas and giving feedback. Unfortunately we relied a little bit too heavily on the feedback, and started prototyping about a sprint or two later than most teams. Additionally, a lot of documentation was behind, so it ended up taking much more time than it needed to later in development.
All in all,
-Systems and Tech Design, was it right to do horror?-
Considering my experience in systems and technical design, I think horror was not a great genre for us to tackle. However, something that we wanted to push later in the project’s life was that the game is not necessarily horror, it’s a stealth game in a horror setting (which might still mean its a horror game, but I digress). I think focusing on branding the game like this may have excused some of the incomplete narrative elements of the game, and would have given leeway to more mechanics. This would fit the role I was going for even better as well, since I’d have had more time to create more systems and implement them.
-How can I improve what I do going forward-
Going forward, I do think I need to focus on what I can add to the game, and make sure that is what I’m doing. With this project, there was a big hole in the narrative that we set ourselves up with by trying to do horror. This was not something I could fill, and in hindsight, expressing this to the team may have led to finding a creative way around having a basic narrative so I could do what I do best, systems and tech, and made the game a lot more impressive to play.
Comments