Obviously, bugs have varying levels of severity. You don't want show stoppers or other inconsistencies that lower the quality of the game, but if you wait to release a perfect product, you could be waiting a while.
I always put new releases on Google Play first, since it's about 90 minutes to turn around an update, as opposed to a week on iOS.
You might try applying the concept of user pain to decide whether your game is currently in a sufficiently bug-free state.
Is does sound like you're letting too many bugs slip through, so it may be worth looking at your entire development process so you can try to avoid introducing so many bugs to begin with. As others have mentioned, many of your "bugs" sound more like incomplete features.
That being said, I never really liked the Agile development model (but this is just me), because it forces you to code fast, without thinking about possible bugs you might be introducing. I also don't like how it categorizes and splits work into fixed, periodic categories (or whatever they're called - 2 weeks planning, 2 weeks developing, 2 weeks testing, then repeat). Since you're not documenting much, just adding tasks, you will end up forgetting details of what was planned before you even start developing. Plus, when it comes to bugs, you really cannot plan for them. I always find it easier and faster to fix bugs as I find them, while I'm still involved in the task I'm working on, even if it's not related to my work. Instead, Agile just forces you to add a new task for the bug and move on.
Agile is not not cowboy coding. If you plan to implement a certain feature, you're not really done with the task until the feature works as expected (i.e. no bugs). Fixing bugs as soon as you find them is a good practice, and it doesn't contradict good agile practices. In the contrary, if you are measuring project velocity (story points per sprint or whatever your measure is) then the earlier you fix the bugs the better you'll be able to measure the "true" velocity. Otherwise you are just borrowing time from the future and adding to the hidden technological debt.
That said, agile may not be easy to do in practice (depending on the organizational culture), and may not be the best approach for every project. On the other hand, I've not find any negative aspects of it in my experience.
First: asking whether a number of bugs is appropriate is like saying that it takes "6 months to grieve a relationship". This is not grounded on any baseline. Therefore, its very hard to determine what an acceptable/inacceptable number of bugs really is.
From the looks of it though, you are creating too many bugs. This assessment is based on the fact that the sheer amount of bugs you are faced with impedes your progress. If your velocity is near null, then there is a proble.
There are many reasons why this could happen:
- Poor code quality
One of the problems in many teams is that they "develop".
Developing new features is fun, but it inevitably changes the system you're working in. If you spend no time refactoring a bit, you'll end up debugging a lot.
If your team refactors as it moves, at a steady pace, old structures will remain relevant, and bugs will be easier to spot.
Refactoring also allows you to optimize your code and eliminate redundancies. If you follow OOP principles, you'll reduce the amount of lines of code, and thus, the amount of lines of code developers will need to read through to find what went wrong.
Another common problem is the lack of testing methodologies. Without delving into TTD (though I would advise it if your team is familiar with that approach), its important to test implementation under different circumpstances. It's possible that a new feature / refactor "works" under your current test conditions, but it doesn't mean it keeps status quo with all potential situations.
My personal way to assess this is to create automated test cases with "random" values. This allows me to easily run a number of cases and assess that the system works under different circumpstances. This gives me faith in the code-base, which is important before committing important changes.
- Poor work ethic
Your team, by now, should have a culture of what it means to put something to "done". Most likely, they consider it's done when they've developed it.
It shouldn't be just that though.
The DOD (definition of done) should encompass any technical debt created by the new feature.
In other words, a new feature is done only when it works fully, and hasn't caused any instabilities elsewhere.
Thus, a bunch of the "bugs" youy are stuck with are probably the result of technical debt: a new feature that broke something else.
If you empower your developers with the responsibility of this DOD, it will be easier to implement a reward mechanism.
Following your principle, I would say:
1for1: if you get 1 feature to Done (including all technical debt bugs resolved), you get to have a drink.
This allows your developers to have a hollistic vision of development. Instead of "preying on the small bugs", they'll carefully choose one feature, and own it entirely.
Also make sure to use the "boyscout rule". If a developer creates a new feature that leverages another part of the code that is considered risky, he must leave the place "cleaner than it was" (thus making a few optimizations to the original code of the faulty class or bit of code).
Lastly, to insure your most important features get done, assign an arbitrary value (0-100) to each feature, where 100 is the most important one.
When "drinks" come, insure everyone has fully completed their one feature, then, look at its value.
If it's 100, YOU get to pay their drink. If it's 50, pay half of their drink, etc.
If people want "free drinks", they're likely to start on 100-rated items (heck you could even go with 200-rated items if you want to pay them 2 drinks!).
This gives them incentive (drinks) to acquire ownership and responsibility (DOD).
Good luck!
Most observations above are correct. I like to start new and cool features before I get to completely finish old features. Again, this is on the edge of the sword again. Sometimes having a partially working feature makes it easier to see if a feature is worth keeping or throwing away. And sometimes it's easier to come up with ideas and features when there is something (partially) playable.
I'm known to live by this motto:
5 days dev
1 day refactor
1 day off
copy paste for the rest of your life.
It works for me, and brings amazing results. So far, I haven't felt like dropping out of this loop.
Specifically, I get no more than 1-3 hours per day to dedicate to this project, but I try to deliver at least an increment of functionality every 'dev' day.
Any 'dev' day I can't achieve this, I commit the next day as 'extra refactor' day, because it shows that my technical debt has increased.
So its not unusual for me to have 2 refactor days in the same week, but this is so that the next week, I get to make 1 increment in each of my 'dev' days.
I think its a good indicator of the health of your codebase too (being able to deliver quality, quickly, without having to debug for several hours).
- The game sometimes crashes hard.
This is a very worrisome bug. If the game suddenly crashes at unexpected times, it could mean deep problems that could be very hard to fix, and if you release/sell this game and it crashes on people, your reputation will take a dive. By not fixing it immediately, you may have built code that relies on code that needs to be removed or was poorly designed. I personally try to keep bugs to 0 and if a bug creeps up, I fix it before moving on to anything else. When building new features on buggy code bases, future bug fixes can break working code. I've been in that situation before and found it better to stop adding features and just fix everything first. In the long run, you'll save time.
Buggy code can kill motivation. If you remove all the bugs before adding more features, your nicely working program will provide more motivation to finish it. "Hacky" code and endless bug fixing can drive a person insane and kill an otherwise good project.
I hope you fix all of your bugs first. Then you'll see how much easier and enjoyable coding your project can be.
Our team is just two persons, who work with the project after the day job. This is kind of a hobby, but a little more serious than a hobby.
I understand when a huge mismanaged project with programmers fighting deadlines and bureaucracy and apathy has bugs pile up, but I can't imagine why a two-person hobby team would let a bug database grow out of control. That's not an excuse for more bugs. It's a reason you should have fewer bugs.
I had a neighbor once that was a musician and didn't have a regular paycheck. Every year he would meet with his tax preparer and have a conversation that went something like:
-"How much do you want to pay in taxes this year?"
-"Let's start with zero and see where we end up..."
This thread reminds me of that story. 
