Blog Post 1

CAGD 470 - Video Game Production

Rune Chronicles

    My name is Kade Chambers, and I am the team lead and programmer for Rune Chronicles, a third-person action adventure game. My team consists of Preston Farris, Andre Lopez, and Jacob Tucker. Preston has taken on the role of our 3D modeler, while Andre and Jacob are acting as our concept team and level designers. Additionally, Andre will be working on Terrain components, while Jacob will also be handling animation integration.

    This game will be built in Unity version 2020.3.16f1 using assets created by the team, and will also be using animation from Adobe Mixamo. We will be using Jira to track our development and user story burndown rate.

    "Rune Chronicles drops the players into a dangerous, adventure-filled world. Collect crystals throughout the world while defeating your enemies with your powerful melee and magic abilities. Players will upgrade their character and fight through bosses to acquire new spells while collecting crystals to charge the gateway runes to move to the next area."

    To start with production, our team held our first kick-off meeting, where we decided on our initial goals for the sprint, and assigned tasks that we needed to have completed in order to meet these goals before Sprint 1's end. Our goal was to push out a paper-prototype to test certain game mechanics and features while also creating a backlog of assets and conceptual pieces in order to fully begin virtual development on the game. As the sprint progressed, we quickly decided to add additional tasks to keep our production moving as we underestimated the rate at which user stories would be completed.  The idea was to get the entire team on focused on the same vision before beginning on our game systems, and I believe this helped our team boil down a list of components into essential and non-essential mechanics.

    For Sprint 1, I took on the task of concepting our paper prototype idea and creating a set of rules that would allow our player to interact with the game in an open-ended way. This would allow other members of the team to contribute to the prototype in other ways, while allowing them time to produce content for the digital stage of development. Various items in the game were implemented over the course of a week in order to add more gameplay variety between game sessions. This set of rules were later iterated on when Andre produced a concept map for the players, and when Jacob implemented our enemies and item chest locations.

You can access the rule sheet here!

    

Another task that I completed over the course of this first sprint was getting our development environment set up. To do this, I decided that our team would be using GitHub to manage our project, to allow for version control and branching. This involved starting a base project within Unity, and setting up a repository with collaborator access for my team. As members of the team are less familiar with version control software, we also had a short meeting where we went over the core of GitHub and the process of committing to a personal branch.

    To help our team visualize the visual flow for the player. I also created a wireframe within Adobe XD of our intended user interface flow, and shared access to the team so that anyone can reference this model in the future, or test additional functionality. 

    In order to better collect feedback from our paper prototype playtesters, I also created a feedback form for our players, and asked my team to provide a list of future questions that might help provide additional feedback for their roles in the digital prototype. This allows us to quickly iterate over our design to address feedback in specific areas, as well as gather data on general player experiences.

    Overall for this sprint, we assigned 50 points distributed over 50 player user stories. By the end of the sprint, our team had completed 35 points worth of work, and completed our over-arching goal of pushing out a paper prototype and beginning work on a digital prototype within Unity. 3 user stories remained in progress, and 12 user stories did not move out of assigned.

    I believe a large reason for this was the slow-down in production very early on when beginning with Jira, and the amount of tasks that were assigned during our first kickoff. By underestimating the work that we could accomplish, we spent additional time going back into our backlog and getting more tasks assigned, which can be seen visually in the above graph after a large number of story points are assigned. In the future, I plan to correct this mistake by giving our team a large enough list of tasks to keep everyone busy, and assign user stories based on the amount of work done this sprint.