Before even starting this project it is crucial to first step back and go over the basics. Within our lecture we discussed the importance of understanding and identifying what roles we have within the team and how they play out in game development. Although we obviously where designated roles we need to both understand what they are and how they will work within our groups project.

In all group projects teamwork is crucial, as such we discussed how we are going to function as a group. There are multiple teamwork roles which means that people within the team will have to pick up multiple roles. Leader, implementer, team worker, plant/innovator, monitor/evaluator, specialist, resource investigator, shaper, and the completer/finisher are just some of the roles which need to be assigned within the group. Although I am the technical developer, I also need to ensure that I’m helping out with other jobs. With a small team of five people it requires us to do a bit of everything. A game is more than just world designer, narrative designer, and art, there’s a lot of different components such as the UI and the game loop etc. We made sure that all of us was aware that we are here to support one another when things get busy.

Reflecting on our initial discussions, I found myself naturally gravitating toward multiple roles beyond just technical development. While my primary responsibility is implementing the game’s mechanics and features, I also needed to take on aspects of the resource investigator by researching similar games, the monitor/evaluator by assessing feasibility of various features, and occasionally the completer/finisher by ensuring our mechanics were properly integrated. This way of role-sharing is essential in smaller teams. Understanding these responsibilities early on helped me prioritize not just what mechanics to build, but how my work would fit in with everyone else’s contributions.

After discussing the roles and how the team will work going forward we all went away and had a look at the GDD for ‘Those Left Behind’. Simply, the game is about managing a group of survivors that where left on earth after all the rich people left on a rocket ship to escape earth. As the player, you are a scientist who has to lead their family and any survivors they take in. The game is about strategic decision making to survive in the ruined world.

Delving deeper into the GDD mentioned three core pillars that will significantly influence my technical approach: “portraying human experience through struggle and survival,” “family dynamics using distinct character voices,” and “storytelling that lifts the weight of number crunching from the management game.” These pillars indicated that our games mechanics needs to support an emotional narrative gameplay rather than complex simulation mechanics. Unlike traditional management games that focus on optimization puzzles, our mechanics would need to emphasize consequences of choices and character relationships.

The GDD outlined a gameplay loop structured around “weeks” where players would: delegate survivors to camps, evaluate the teams, resolve random and narrative events, and then assess results before moving to the next week. This relatively simple loop would need robust underpinnings to support the emotional and narrative complexity described in the game pillars.

Looking at it from my perspective, I could see several core mechanics that are essential for game: something to keep track of resources like food and tech, a way to present story events and choices, a screen for assigning survivors to different teams, and a clear UI to show everything to the player.

Further analysing these requirements, I identified five interconnected mechanics that will form the foundation of our vertical slice:

1. Resource Management System – Not just tracking values for the five main resources (food, tech, scraps, security, and survivors), but also handling resource consumption rates, requirements for various gameplay features, and the relationship between resources. For example, the GDD specified that food shortages could lead to survivors abandoning the camp, while insufficient security could result in a game-ending scenario.
2. Camp Management Interface – This would need to be more than just a UI for assignments; it would require handling character statistics, specialties, and preferences. According to the GDD, characters perform better at tasks they prefer, and family members can provide guidance on decisions. This system would need to track these preferences and relationships.
3. Event System – This would be one of the more complex mechanics, needing to handle both random events tied to the teams and structured narrative events that advance the main storyline. Events would need to check resource thresholds, track previous choices, and potentially unlock or lock future events.
4. Dialogue/Choice System – For presenting narrative content and meaningful choices to the player. This mechanic would need to handle conditional text, resource costs and gains for different options, and track the impact of choices on family relationships.
5. Game State Manager – To control the overall game flow between phases, handle week advancement, and maintain the persistent state of the camp and storyline progression.

I tried playing games like Frostpunk and King of Dragon Pass since they were explicitly mentioned as being an inspiration for the game idea. I wanted to see how they handled management mechanics and narrative features. Frostpunk was really helpful since it also deals with survival and tough moral choices.

My analysis of these games has given me some valuable insights. In Frostpunk, I noted how the UI effectively communicates information through both visual design and positional hierarchy. Resources that require immediate attention are prominently displayed, while detailed breakdowns are accessible through secondary interfaces. This approach keeps the player informed without overwhelming them, which would be crucial for our game where narrative rather than number-crunching is the focus.

King of Dragon Pass provided examples of how to integrate narrative events with resource management. Its event resolution system, where consequences aren’t always immediately apparent but can surface later in the game, creates a compelling sense of causality that I wanted to incorporate into our design. This approach aligns perfectly with the GDD’s emphasis on meaningful choices and the human experience.

As I’ve previously mentioned we ended up picking Unity for making the game since we all had some very basic experience with it, and it’s good for UI-heavy games like this one. The game art for characters and scenes is all 2D, so Unity’s Canvas system works well for us.

Unity’s component orientated structure provides a significant advantage to our project. The reason for this is by allowing me to design each mechanic as a collection of a modular component, which in turn will allow us to constantly develop and test them independently before integrating them. Additionally, Unity’s event system will also be necessary for handling the interactions between all of these various mechanics, for example, triggering resource updates when events are resolved or updating the UI when character assignment changes. 

The goal for this vertical slice is to show the main gameplay loop: assigning survivors to a camp, gathering resources, dealing with random events, and making decisions. As stated in the project brief, we aren’t required to show the whole game, just enough to show the appeal for the game. Its massive project with multiple interlocking mechanics, but I’ve broken down a what mechanics need to be prioritised.

Here is development priority list based on my analysis of the game requirements and dependencies:

1. Firstly, I want to create the core mechanics, these include the drag and drop feature, camp management system, and an event trigger to continue the gameplay.
2. Next, I want to a resource management system which is connected to a state game state manager to establish the resource gain and resource usage.
3. I then want to start creating the narrative manager that controls the narrative content of the game whilst also controlling the players response choices.
4. After the game is functional, I want to start adding the game hooks by establishing an event system that controls random NPC interactions

By using this approach I have allowed for each new mechanic to build upon the previous mechanic which allows for constant and thorough testing. It also prioritises the core mechanics before adding the narrative layers which ensures a solid foundation to build upon. By designing the game this way is allows the team to each work on their own projects without requiring another persons work to be completed utilising the small time we have for this project.