Last month we posted an announcement about our progress toward major goals. To sum it up very briefly: We’ve completed our internal milestone, a single player demo to share with potential publishers, but because we had to prioritize this we needed to push back the Combat Arena Beta release. We’re really sorry for the disappointing news, and hope this decision will lead to the best possible outcome for the game. The full announcement is available here. As of the beginning of 2024, the Beta is now our highest priority.
This newsletter will cover the end of last year as well as the last two weeks of development.
Progress
- We made some improvements to the terrain close to the edge of the playable area. You can now see mountains in the distance, giving the map less of an obvious edge. While they won’t be playable locations, they make the horizon much more interesting, and allow the environment to be more immersive. Here’s a comparison of the old horizon and the new one:
- In the coming weeks, it might be more difficult for us to share pictures and videos of our progress due to the nature of the work we’re focusing on right now. (Changing a file system’s structure isn’t the most visually appealing task.) This isn’t for certain, but we wanted to let you know about the possibility beforehand. We’ll do our best to include a visual whenever we’re able!
- A few weeks ago, we manged to get the project to a known good and stable state. This was a major part of the internal milestone we had been focusing on up until this point. This is useful because it allows us to create builds of the demo that feel good to play, and don't have any major issues.
- As a part of finishing up our single player milestone we fixed many soft locks, enabled autosaving during cutscenes, and gave friendly NPCs green health bars to help differentiate them from enemies during group battles.
- With our old milestone out of the way, we've started a bit of early spring cleaning in preparation for the Beta Combat Area. Over the course of development we identified a few problems in areas we had previously completed. It may be an issue causing poor performance, an overly complicated setup that slows down development, etc. Some of these are in areas that were considered too risky to make changes to while we were perfecting everything for the demo. Taking care of these issues now allows us to make the Beta a much better experience.
- This sprint we went back into those areas and fixed many of the issues we found. A lot got broken very quickly, but even in this sprint we have mostly returned to the previous state and we expect to iron out all the remaining bugs over the next few weeks. We also moved to a new way of picking out what parts of the game go into a particular build. This means that when we release a public build for the Beta we can say “Kinfolk X should be in, but not Kinfolk Y,” then we can turn Kinfolk Y back on for QA testers with a simple toggle. This is a massive improvement over our old system, which involved moving Kinfolk Y's files in a complicated way (and keep in mind the average Kinfolk has 10 or more files! So tedious!) This new system, called Addressables, also applies to the world, items, and basically everything else in the game.
- At the end of this sprint, we tackled automated testing once more. You may remember us discussing this before, but higher priorities forced us to leave it in a functional but incomplete state. Recent efforts have taken us the rest of the way, and we now expect a suite of easily expandable tests to run automatically each day against the game both in the Unity editor and in a build of the game. This will be a major benefit to QA, who will now get a daily report indicating if any issues have been introduced by the previous day's work. This should go a long way toward ensuring that there are as few bugs on day 1 of the Beta as possible.
- While we’ve been doing all this foundational work on the development side for the Beta, the QA testers have been continuing to look for bugs that come up in edge cases in the single player portion of the game. They’ll now be transferring to the Beta once we have more specific things for them to test.
- Aside from the large scale changes above, we’ve polished the look and feel of Kodoki’s animations! We’ve adjusted how he transitions between different movements, such as going from the end of an attack to standing still.
- Since the Lexicon has grown so much, we’ve made a separate page for the complete list and will only post relevant terms at the bottom of the newsletter from now on. Thanks for bearing with us while we figure out the best way to format this section!
Lexicon
- Build: A playable version of the game. We create new builds multiple times per week to test new changes.
- Cutscene: A non-interactive video sequence that occurs between segments of gameplay and depicts part of the story.
- Editor: (aka Unity Editor) The program developers use to make changes to the game. Developers can test their work here before their changes are added to a build.
- Known Good State: A version of the project that is known to be free of errors. Very helpful to have before making changes that are likely to produce bugs.
- NPC: A non-player character.
- QA: Quality assurance. The people who test the game and report bugs.
- Soft lock: A situation where the game becomes impossible to progress due to a bug, glitch, or flawed logic.
- Sprint: A two week period used for organization. Our newsletters are released on the last day of our sprint.
- Toggle: A switch that can be flipped between two possible outcomes. For example: A/B, or on/off.
Thanks for checking in on us, and we hope you had a Happy Holiday and New Year! See you for our next newsletter on January 26.