Post by Morreion on Aug 27, 2015 15:21:54 GMT -5
Life working a crowdfunded game (Psychochild's Blog)
In the glass house
One of the biggest changes from “traditional development” is that there is a significant focus on communication with the playerbase. This means that the development team is always in the limelight. This makes sense, as people have given the company money and they want to see that money is being put to a good purpose.
In traditional development, you often don’t talk with the outside while doing development. You certainly have to communicate with the people who write the checks to fund your company, but for the most part you work in seclusion from your future playerbase.
But, now there’s an emphasis on getting out in front of the audience. The developers working on Camelot Unchained do a lot of streaming (where you sometimes see the back of my head as I’m working), lots of newsletters, lots of interaction with current and potential future backers. This interaction does take some time, though, which is always a precious resource in game development.
It’s not necessarily good or bad, but very different that what I’ve experienced in development before.
Your mistakes on display
Because of this emphasis on communication, everything is out on display. This includes bugs in the game.
In traditional game development, you might have some flaw in the game system that you just endure. Maybe for some reason it crashes the game when characters move backwards; the simple solution is to tell your testers not to do that for right now. But, when you have backers interacting with your game, a flaw like this will generate a lot of reports about the bug. You kind of have to fix it sooner rather than later so people aren’t distracted by the flaw.
It’s also harder to have code or design that is in transition, half developed and not quite finished. For example, few games are even close to being “balanced” during development. You might code abilities to test out the system, with the intent of adjusting the values later. If something is truly overpowered and broken, you can tell the team “Don’t use that for right now.” Players doing quite cooperate so well.
But, the great part is that you do have people crawling through your system looking for problems. You will have a larger group of people testing your game than you would otherwise be able to afford. This can help you find bugs and flaws that would otherwise go unnoticed. I usually the first part of my day going through the forums and putting bugs people report into our bug reporting system. This is a great boon if you’re doing something far out of the ordinary with your game systems, and you need a lot more testing than usual.
In the glass house
One of the biggest changes from “traditional development” is that there is a significant focus on communication with the playerbase. This means that the development team is always in the limelight. This makes sense, as people have given the company money and they want to see that money is being put to a good purpose.
In traditional development, you often don’t talk with the outside while doing development. You certainly have to communicate with the people who write the checks to fund your company, but for the most part you work in seclusion from your future playerbase.
But, now there’s an emphasis on getting out in front of the audience. The developers working on Camelot Unchained do a lot of streaming (where you sometimes see the back of my head as I’m working), lots of newsletters, lots of interaction with current and potential future backers. This interaction does take some time, though, which is always a precious resource in game development.
It’s not necessarily good or bad, but very different that what I’ve experienced in development before.
Your mistakes on display
Because of this emphasis on communication, everything is out on display. This includes bugs in the game.
In traditional game development, you might have some flaw in the game system that you just endure. Maybe for some reason it crashes the game when characters move backwards; the simple solution is to tell your testers not to do that for right now. But, when you have backers interacting with your game, a flaw like this will generate a lot of reports about the bug. You kind of have to fix it sooner rather than later so people aren’t distracted by the flaw.
It’s also harder to have code or design that is in transition, half developed and not quite finished. For example, few games are even close to being “balanced” during development. You might code abilities to test out the system, with the intent of adjusting the values later. If something is truly overpowered and broken, you can tell the team “Don’t use that for right now.” Players doing quite cooperate so well.
But, the great part is that you do have people crawling through your system looking for problems. You will have a larger group of people testing your game than you would otherwise be able to afford. This can help you find bugs and flaws that would otherwise go unnoticed. I usually the first part of my day going through the forums and putting bugs people report into our bug reporting system. This is a great boon if you’re doing something far out of the ordinary with your game systems, and you need a lot more testing than usual.
