Devlog #3

Design Proposal Presentation Reflection:

After pitching our design proposal to other teams and the stakeholder, we collected valuable feedback that we can apply to our game’s development pipeline. We reviewed a lot of the features we were continuously debating in our presentation, and received feedback to realize which of them we should and should not entertain moving forward.

For example, a core game mechanic we want to have is to let the player’s choice options evolve and become more complex through each chapter of the game. One thing we considered was the possibility of removing certain options from players should they use them in situations that it is not appropriate to do so. An example of this might be sending a user a meme when they ask for essay advice, which would have led to the meme feature being removed. However, after considering the feedback we were given, we realized that removing options from players is often poorly received in games, even if they have reason to do so. We have decided to avoid such ideas for now, unless we have the time and scope to test the concept through playtesting.

We also learned much about the concept and reception of our game, the directions we should go, things people within our target age group like and dislike.

Team Building:

We have been working and progressing well as a team, and have had long discussions about team exercises we have done in class. One example of this is our sailboat retrospective.

We’ve researched about what works and does not work within teams, and what we want to try and do or avoid moving forward. This will set a good starting point for collaborative working in the future, and we will continue to do more reflection exercises in the future to track our progress as a team.

We also created a team charter, outlining the team’s goals, roles, and responsibilities in one document. This was done in an effort to stay organized, as well as clearly declare the goals of not only the team as a whole, but also of each individual member.

Creative Brief:

Afterwards, we pitched our game by creating a one page brief outlining our core beliefs, and how we plan to address the problem that we chose.

Scheduling:

When the second semester arrives, there will be much to do to reach our goals for this game, so we must define a plan to get an MVP (Minimum Viable Product) finished within the time limit of the next semester, all while upholding each individual member’s other responsibilities.

We understand this schedule is subject to change and may shift as we continue with development. Tasks could be completed ahead of schedule or we could fall behind, but this is overall the general structure we want to follow moving forward. We are confident we will have a completed game by the end of the next semester.

Conclusion:

Overall, we have learned a lot these past few weeks. Our design proposal presentation went well, and we were given valuable feedback on how to improve our game concept as it stands, along with what to do and what to avoid moving forward. We have a much stronger idea of what we want to do, and also have our schedule set up to plan how we are going to accomplish it. Our concept was given the green light, and we are very excited to build Project Runtime!