As mentioned in the previous sprint the primary aim of this sprint was to finish off the presentation mode which could/would be demonstrated at events, either on a stand or directly to parties interested in supporting the development and launch of the game.
Bringing a game to life
This is often the hardest part of development, the myriad of small improvements that yield big gains in terms of player experience and yet you’d struggle to notice them unless you made an effort to. Particle effects, camera shakes, flavour animations – they all add up to making games feel alive. A lot more are planned for future versions but for now this will do.
One big change in this regard was introducing a new theme tune made by Huw Roberts – we met at Develop: Brighton in 2023 and he’s been a keen supporter of the project since. He was given a brief of making something that really brings the game alive through historical instruments and he delivered. Watch this space for an incoming article on this process.
Keeping on top of things
During the past few weeks I noticed there was something off with how the game played or, to be more specific, how a particular rule was behaving. The surround rule where the attackers can win the game by surrounding all of the defender’s pieces seemed to returning false positives. Something was clearly wrong and needed to be fixed but this kicks up a question: when?
In most projects bugs are found by QA who then write up a ticket with relevant information and stick it in the backlog, creating what’s called Technical Debt. These are then brought into future sprints as part of the predicted workload. There’s no hard rule as to when this should be done – some prefer at the end of the project, some prefer as soon as possible, some a hybrid approach (or “it depends”). One thing that most agree on is never into the current sprint….
… unless it’s critical or blocking.
Bugs can be assigned a severity level to determine their priority with words such as Blocking, Critical, Major, Minor, Suggestion, Query… Note how we use words and not numbers, sharing the same mentality with avalanche assessment – numbers are subjective and meaningless in these contexts, even dangerous.
This particular bug meant that the game was incorrect – that’s quite serious so it’s definitely major, most likely critical. Does it stop the game working? Not immediately, so in that context it’s not blocking. However the next sprint is to work on the AI, which requires that the rules are correct and suddenly this bug is now blocking. To me, this is an acceptable break of standard practice given the impact is only me and I’m fully aware of what’s going on. So, I created a bug ticket for posterity, stuck it into the sprint, fixed the bug and reported it as such.
Some might argue this is excessive for a solo dev project and I understand their reservations. However I would argue from my own experiences that this kind of due diligence is worth a lot more than is perceived and pays dividends if you need to go back and establish exactly what has been done and when.
Out with the old, in with the new
At the end of this sprint I found myself with a spare moment of no allocated work left to do and a prime opportunity to upgrade the game engine from Unity 2022.3 to Unity 6. Following the fallout from the Runtime Fee fiasco the changes to the strategy and direction of Unity 6 makes it an attractive proposition. The removal of the mandatory splash screen is a huge boon, I want to get players into the game as fast as possible.
Unity engine upgrades are typically painless and this was no exception. A quick spring clean, some package updates and build tests revealed that all is well, work can continue uninterrupted.
Next steps
Now that the presentation mode is done, the next thing to implement is a decent offline AI for players to compete against. This will replace the random move AI that is currently implemented (for implementation testing purposes -it’s hilariously wild with its moves) with a more traditional chess style model.