Does game development's iterative, interactive, and multi-area nature make it more susceptible to the occurrence of bugs, compared to other fields such as desktop, web, and mobile software development?
Provide statistics of your project if possible.
I am currently working on a game project where 50% of development cards are bugs, and I intend to discover how it compares to other projects.
There is no answer to your question.
First you need to define what is a bug.
Say I write a feature. I'm done with the code, and I start testing it. I find something that is not quite what I expected. So it could be considered a bug. I fix it, test again, and the code I wrote seems to work fine.
Now if I ship this feature to the test department, and they find something they think is not quite what they expect; now if the testing of feature is part of the normal development process, and it's expected that they find such kind of issue, is it a bug or just something that needs fixing (in which case it will be part of the "feature" card)? If the test department is the last step before shipping, and they find something, it'll likely a bug and you'll likely get a bug card.
And once the product is in the hands of the client, and they report something, you'll likely also get a bug card.
So here we have four "issues" that could be considered bugs. Which of those your team considers actual bugs?
Then you need to consider how your team handles those bugs.
"Bug management" differs from team to team. Some teams stop everything they do when a bug gets on their JIRA board, some will accumulate them and wait until they can fill up a full sprint only with bugs to fix, some teams will send the bugs to fix to their junior devs/new hires.
It will even differ within the same team during development. An increased attention to bugs may be given once the project gets close to the shipping date, while focus may be on broad development during the earlier days.
Finally, you need to consider the nature of those "bugs". A spelling mistake in an obscure part of the user manual is a bug, but it will be much less of an issue for a game where you get a solid tutorial than when the software is about the actual language.
For these reasons, since every team is different, there is no one metric that you can use to compare your own team to other teams/other fields.
I am currently working on a game project where 50% of development cards are bugs and I intend to discover how it compares to other projects.
I bet you're asking this because you find you have a lot of bugs on your JIRA tasks list, and a colleague just said that it was because game development was a bug-prone domain.
As it's been commented by thedemons on this version of the question on SO:
game development tends to require a lot of maths, and needs to be able to handle a lot of edge cases because the players/users usually have more freedom interacting with the application compared to other fields. Therefore, it is more prone to error.
Being error prone does not relate to the proportion of bugs on a JIRA board.
The amount of bug cards you have on your JIRA board only relates to how your team works. If you think the ratio of bugs/not-bug cards is too high, it may be time to try and convince your team to think about how you work and what/how you prioritize: make sure no bugs stay there for more than one sprint? Make sure the definition of "done" requires that the feature is tested and ready to ship? Empower your devs and allow peer testing?
That's for you and your team to decide.