Game Development Progress:

This page is intended to serve as an evolving blog post. Any and all updates and progress reports to the game - in its current state as a university project - will be shared here for lecturers and fellow students alike.

Screenshot of an in game village

Mid-Sprint 1

(Monday the 3rd through Friday the 7th November, 2025) This week was interesting, to say the least. While I had anticipated writing up basic documentation and jumping straight into design, what ended up happening was scrutinising documentational drafts, and mapping out a hefty Software Development Lifecycle (SDLC) document. Though it was a pain to get out of the way, the benefits have been made very apparent. I - with my team - have been able to roadmap a significant part of the design process, covering things from proto-personas to user stories and SWOT analyses. All of these help frame our project as a an actual "product" and allow us to weigh it against a pseudo customer base.

Now, while this is generally intended to allow developers to extract real user values and translate those into functional game or application requirements for an MVP (Minimum Viable Product), my team and I are approaching this from a sort of "reverse-engineering perspective". As the project leader, I designed and pitched this project to my university with a set scope and MVP in mind, which means tailoring our "market research" to reflect design choices I had already made. In all cases, when a student or faculty member pitches a project for collaboration and potential academic grading material, these "pitches" are all pre-scoped with a target MVP in mind. Although this itself isn't industry standard, because we're reverse-engineering my initial MVP, my team and I are able to at least simulate this portion of the design phase.

With this first week having come to a close, the next portion of Sprint 1 will focus on wrapping up the initial planning phase, and Sprint 2 will see us moving into actual design and scope definition.

Aaron Stevens.

Sprint 1

(Monday the 10th through Friday the 14th November, 2025)

With the end of this week, the final half of our first sprint comes to a close. Having had another week to reflect on the tasks set in place - lots of juicy documentation - my team and I came to the realisation that this approach was far too cumbersome. While the documentation is an integral part of the process, we're approaching this from a waterfall / agile hybrid. Traditional waterfall methodology dictates that we have our paperwork completely ironed out before moving on, while agile tends to adopt much lighter documentation that is iterative and done in parallel with development. That in mind as we embrace a hybrid method, my team has done something akin to a refined draft of our desired final documentation. While my team have been finalising the drafts, I've begun drafting architecture, and coding skeletal classes that form a template of the technical aspects of what our evolving documentation will come to reflect. This was largely at the suggestion of my lecturers, that I use the MoSCoW prioritisation system to determine what's most important, to what's least important. This system was used on the documentation itself, and allowed us to realise that it was okay put less emphasis on certain sections, and more on others. This, I feel, has given us much more room and time, as it's freed up valuable resources and allowed us each to focus on tasks tailored to our own strengths, rather than working collectively on a single item at a time.

One thing I learned this week that seems be a relevant statement across many industries; too many chefs spoil the broth. The chefs are us - the developers - the broth is the project, or at least any single aspect at any given time. While it's important for all the developers to be on the same page and aware of the process as a whole, it's not necessary - and often times a detriment - to have them all working on the same task simultaneously. Tasks should be delegated to those who thrive in that environment, and once drafted, passed around for input from the rest of the team. Alterations can be suggested, changes made, and you move on. This keeps the project from going stagnant, as all sections are constantly moving, growing, and being reviewed by your team and ultimately polished.

Aaron Stevens.