Our decisions during development

In comparison to other groups for this assessment, plenty of members had left the team and one joined. That left us with 3 members in this group. Moreover, unlike most groups (where they continue from where they left off) we chose to work on an aesthetically different game. The framework is similar (turn-based RPG), with changes to fit an entirely new design, but our challenge was to design a working game with a different design within 6 to 12 weeks. 

This was a hurdle to overcome, and to do that we had to be wary about what we can do. Each of us was assigned a role to work on the game; Kylie worked on the art, Blake worked on the code and mechanical framework, and William wrote the design document, the marketing plans, and the story that eventually shaped the game’s art and narrative. We decided to choose Godot as our game engine because it is open source and has no current financial risks to use.

As each member of the team is highly critical, any moment when a team member gets sick may cause severe production issues that will force us to reschedule development time. Our solution was to prevent this from happening as much as possible; we encouraged each other to take breaks and rest whenever they felt down or unable to work. Judging by our result about 6 weeks in, we feel that we’ve made the right choice: Very few tasks were delayed, and many were on schedule.

Another factor that allowed us to minimise delayed tasks was frequently communicating with each other to verify design decisions or agree to compromises. We had a long conversation regarding the battle system and how it should function, so its systems follow according to the design document. A similar event was about the story writing; since the combat system only accommodates exactly 4 people, the story was rewritten to immediately introduce those characters early on.

Production Roadmap

We learnt from our previous project that we should leave as much buffer time as possible to prepare for any project risks we may encounter. We structured our first two sprints to complete all the major assets and try to incorporate a small portion of polish elements (like UI, sound, and animation) for the MVP leaving the rest of the weeks for testing, QOL checks and polish -- and of course, plenty of leeway for anything that may hold us back. Codecks was the Kanban board of our choice to manage our weekly tasks.

Concept Art

Enemy Concept Octospider in 3D by William 

Thumbnail Environment Concepts by Kylie