I don’t know if this is a dark secret of game developers, but games ship with bugs. Known bugs.
Part of the late development process is reviewing the bug list to see what most needs fixing. We all hate bugs, but we also love shipping. Not everything has to be fixed before release. The closer we get to making the release build, the stricter the criteria become. We’ve recently deferred a bunch of bugs that we would have fixed when we started the triage process.
Why be so strict? Because many fixes can have unintended consequences. We just discovered a fairly rare bug yesterday, which had been introduced by a change we made last year (which was tested back then and found to work perfectly as designed). Since even a simple bug fix can destabilize the game, we want to make sure any last minute fixes are truly warranted.
At the end of the process, the only bugs to be fixed are those that affect all players, prevent play, or make us look stupid. Most of what we’ve been finding lately have been issues that come up if you have tons of feuds, or when you made certain decisions and then ally a particular clan. These aren’t going to be that common. And even the players who end up doing that won’t be blocked from the game, or find it illogical. My classic “look stupid” bug was a game I saw years ago, where the publisher spelled their own name wrong on the title screen. Luckily we haven’t found anything like that.
But of course, we do want to fix all the bugs. So I’ve been making the fixes in an alternate branch of the code. As soon as everything is locked down in the App Store, we’ll switch over internally and start testing that.
6 thoughts on “Bugs, Part 1”
Shipping with bugs is inevitable and even necessary. I work in a bank and deliver systems, including financial systems, with known bugs. We don’t mind the known bugs, the business risk owner has accepted them. It’s the unknown bugs that are scary.
The reason the business risk owner accepts bugs is that the cost of fixing the bug is too high, at least in the short term. And that, I guess is the same for you. The time cost of fixing all bugs, including testing, is higher than the value of releasing now (or at least soon)
Hi there: I am a long time player of Kodp. I am curious to know if, a: you are aware that you have a significant following within the blind and screen reader using community. Specifically, I was curious to know if you have any beta or late testers who have gone over the new game using voice-over on the IPhone? I have high opes for the new app, as it is mostly accessible using voiceover, hence my dedication. However, if you are lacking such a tester, I would be interested to know if you needed such a person. Obviously, you might already have covered this concern. However, accessibility often slips the mind of developers, unfortunately. If I can be of any assistance, I would be more than happy. I’m familiar with OSX, accessible design and voiceover scripting. Namely, it would be simpler to address such issues now rather than after release.
Hopefully this reaches you and there is no need for my messages. I hope you have already covered accessibility. But on the off chance you haven’t, please give me an email. I would be more than happy to do my best.
Yes, we fully support VoiceOver on iOS. One of my testing team and several playtesters are VoiceOver users.
I’m working on software development and I think that automatic testing (unit testing, integration testing, user test) are a key feature for every software right now.
I’d like to know also to know when do you plan to release for PC?
See e.g. http://sixages.blogspot.com/2015/07/script-testing.html and https://blog.sixages.com/index.php/2017/07/find-once-fix-everywhere/
Also see https://blog.sixages.com/index.php/2018/06/release-date/ — “next year.”
Ok, I was hoping for a release this year!
Comments are closed.