Infinite Night
Summary: Infinite Night is a head to head caveman survival game designed for 2-4 players, created by the team Deep Fried Feelings.
Team Members: The team, Deep Fried Feelings, consisted of five people:
- Tim Seyfert, producer and game designer
- Aaron Millet, programmer
- Tim Eccleston, game designer
- Robin Lloyd-Miller, environment artist
- Nick Kinteris, character artist
Platform: PC. Made using Unreal Engine 4.
Project Timeline: Sept. 4, 2017 - Nov. 20, 2017; 12 one-week sprints
Hours Worked: 142 hours (53 production, 42 testing, 36 design); project total 776 hours
Contributions: In this group, I acted primarily as a producer, QA liaison, and game designer. Despite the fact that Infinite Night was the first project of my senior year, acting as a game designer (my major at the college) was a secondary assignment. I also did not need to act as a programmer (my minor, which I had completed the previous semester) because this team had strong technical skills on almost all members.
While the graduating class of 2017 had enough producers that every group had two by the end of the year, my class of 2018 had five producers to spread across almost 20 groups. Even after cutting down to 11 teams for the spring semester, we faced a massive deficit. As such, designers with skills in leadership, organization, and QA were in high demand. Because I had experience in those areas from my work on 2plicity, I offered to act as producer for this group.
This group in particular needed me to bring strong organizational skills to the table. While all group members were very talented, they all had individual flaws that needed to be mitigated if we were going to do great work. Sometimes that meant moderating meeting discussions so everyone could have a say (and the meetings would end in a timely manner), sometimes it meant making sure assigned tasks were being completed by their due dates, and sometimes it meant reaching out so that everyone stayed in contact with each other.
The structure of this class was somewhat different than we were used to. Instead of spending one semester in production, we had a full (school) year to make our games. That meant we spent the first semester in pre-production, brainstorming various ideas and planning out how to make the game across a long period of time.
This tested my skills as a producer and as a QA liaison. This was the most important time for testing so far; without knowing what was wrong with our prototypes and how to fix them, we wouldn't have a chance to go forward. In the beginning of the semester, we had three prototypes to test at once. This was challenging because it meant I had to facilitate three very different tests at the same time without confusing our testers, and I had to gather a wide variety of data without making our forms too long to be manageable.
(The image to the left is from an in-class presentation after I had a "eureka" moment with Infinite Night late in the semester.)
My final duty for the team was to act as a designer. The game's overall direction was in good hands with Tim Eccleston, but the two of us worked in tandem to make it the best we could. We spent time discussing and brainstorming what features we wanted and how we wanted to prioritize them, then presented to the rest of the team for feedback and scope discussion.
With Tim E. acting as our product owner and the driving force behind our inspiration, I helped implement what systems I had time for. I created the water 'shrooms so that players could douse enemy bonfires, and I added feedback on players' health by creating an on-screen blood splatter effect. Finally, I took some time to unify our controls so that players could interact with the environment using a single key, checking and re-checking the logic to be sure that players would never be surprised when they hit the button.
Earlier in the semester when we were experimenting with three prototypes, I took on one prototype mostly on my own. Although the concept (polevaulters equipped with spears who fight in midair) was not too difficult to prototype, I worked in Unity for that part of the project to ensure I wasn't wrestling with an unfamiliar engine while working on my own. Meanwhile, our stronger concepts received the attention of two team members each. (This ended up working out, as Spearvaulters ended up gathering significantly less interest than Infinite Night, even in the early stages.)
Game Context: Infinite Night takes place on a world similar to earth, but somewhat different. The primary difference is geographical; the cavemen live in a deep and winding canyon system surrounded by semi-active volcanoes. These volcanoes spew enormous amounts of ash, which the winds spread across the sky and throughout the canyons. Sunlight does not penetrate the canyon.
The other major difference is the existence of a highly-combustible plantlike material, named the "resource" by locals. These cavemen are primitive, having found fire but not yet realizing how to create it on their own. They are thus highly reliant on tribal bonfires, and reverent of "wild" fires (created by lightning strike or other natural forces). Finding enough resource to keep their fire burning, and carefully spending their supply, is a vital part of life.
Players step into the roles of rival tribesmen, equally intent on fighting off their enemies and protecting their clan. After all, though the canyon is big, when two tribes must share resources, neither will survive.
Postmortem: At the end of the fall semester, senior games faced cuts so that only the strongest games went forward in the spring semester. Infinite Night declined to present our progress to the school. Though our concept was strong and we could have been in a good place with a few more weeks or a few more team members, we did not feel we would make for good competition at the time. The lesson we learned was that sometimes even great ideas and hard work don't turn into good things.
I think the most important skill I learned on this team was how to adjust a team's priorities when work was heavier than expected. We had several sprints where our primary goal was completed, but some crucial tasks were left untouched. I stand by our decisions to implement each feature well before moving on to the next (as opposed to sloppily implementing many more features), but doing so meant we as a team needed to take a second look at what we had to do and when it would be completed.