Sunday 1.12.2013 Release notes for Burnt Islands build 0.06. This release is a release containing adding and fixing several major features and bugs.
The game is a 3D video game based on real physics. You need to fly from island to island, build bridges in order to get your buddies further, eat food, fight with monsters and take care of your own. More about the game Games.studiofreya.com
Our project Burnt Islands reminds me more and more about the project European Air War. We have sometimes so many bugs that a huge amount of time goes to fixing them and not actually working on new features.
So, as I look at our issue tracker (Redmine) right now we have approximately 50% bugs and about 50% features and this is after fixing a whole lot of them for the past 3 days. As we like to rest and enjoy some Thursday - Saturday drinks, one of us thought that it could be motivating if we needed to fix at least 3 bugs or features in order to earn the right to get a drink!
It became a kind of competition where the one who is not working at a day job is able to do three quick bugs due to the knowledge of the code base, while the other one needed to sit for 2 hours to get a drink!
Exhausting but also a real motivation to get things done. One of the days it took so long time to figure out the fix that it was already too late to drink! Well, it resulted that complex tasks are now divided into smaller ones so that it doesn't take too much time to fix them. Divide and conquer is it called.
Whatever works for you this what we are doing now. But is that right? How do other indie developers do things? Do you guys also have many bugs?
3-bugs-1-drink has the disadvantage that larger and more complex bugs/features aren't started after a while. Maybe it's better to work 1 - 1.5 hours on the night shift before getting a drink?
One of us works as an enterprise application programmer at her day job and here is how the big guys do things:
- all major tasks are being specified and analyzed beforehand and is then divided into smaller tasks.
- developers get those small tasks and implement them in a period of 1-3 weeks (Agile / Scrum method).
- at the end of each iteration everything that was done gets tested and bugs are being fixed on the fly.
- next iteration - new tasks.
If we were using this method for our game development then the number of bugs would grow so huge after 3 weeks that I think it could take up to 1 month just to fix them. If we used those 2-3 days at the end of the iteration and no more then the game could look pretty much like "Day one Garry's incident" game that is full of bugs and received a horrible review here.
We don't want to release a bad game, so we wonder what is the best way to do things so that you implement new features and keep the bugs down?
(oh, we can't write bug-free code if anyone was wondering).
And what is the usual proportion of bugs vs new features in the game development industry?
Latest tweets from @freyastudio
New post: Rare monster T.co
Dec 2 2013, 6:30pm
Would you vote for Burnt Islands as an indie game of the year on IndieDB? T.co
Dec 1 2013, 9:37am
New post: Burnt Islands release 0.06 T.co
Dec 1 2013, 8:59am
New post: Next release is delayed T.co
Nov 23 2013, 4:21pm
New post: Burnt Islands release 0.05 T.co
Nov 16 2013, 7:19pm
New post: Appropriate number of bugs T.co
Nov 9 2013, 3:17pm
New post: Burnt Islands release 0.04 T.co
Nov 9 2013, 6:35am
Nov 3 2013, 5:42pm
New post: Burnt Islands release 0.03 T.co
Oct 28 2013, 10:10am
This was hard T.co
Oct 22 2013, 5:07pm