debugging is not the same as beta testing.
it would cost more money, has to be “special” ordered and would drastically decrease the likelyhood of hidden bugs in the game and hence, decrease the need for patches.
at the same time, hidden bugs likelyhood should be increased, especially with bigger games.
right now, out of 50 games you probably get 1-3 “hidden bugs” messages. for small games this is acceptable, for medium games a bit optimistic, for large or AAA games definately not enough.
thus forcing the player to have beta tests, at least later in the game when developing bigger games - or live with unhappy customers and suffer the consequences…
there is already some kind of mechanism at work that will decrease the ratings of buggy games, but this could be enhanced a bit as well…
this would add realism and give the player more options to handle his business.
additionally, beta tests could be conducted in house, keeping your staff (or part of it) busy but have no impact on hype, fans and/or sales (except for the obvious, buggy games dont sell too well)
then there could be public beta tests, costing some money and only keeping one of your staff busy for a short time, but raising hype for “good” games, lowering it for “bad” games.
after the beta test have your staff fix the bugs (or not) and release. maybe even have an option to “raise” the quality of the game a bit, lets call it balancing (through money and coding time)
depending on the quality (time/money) thrown at the beta test more bugs will be found, more balancing “problems” will be found. throw too much money at it, it is wasted, too little, not everything will be found.
keep a base chance of hidden bugs, no matter how much you test.
have balancing raise the review scores a little, depending on how much/good you balanced.
which reminds me of another two points I would like to “suggest”
- “feel” the ratings:
when someone is making a game, especially a studio with staff on bigger titles, they should be aware of how “good” and “well liked” their game will turn out. this does not mean they know the score before hand, but they should be able to “guess” correctly if their product will end up in the 1-4, 5-6, or 7-10 group. especially after (public) beta testing.
if the player had some sort of “sense” for red/yellow/green quality DURING development, it would help the learning curve with setting up the sliders.
there should be a random element involved (mistakes happen) and it could be tied into level/experience. my first game I have no idea, after 30 years in the business I should be rather proficient in estimated my own work.
I understand that this is possibly a game breaking help, everyone would just try the sliders each development phase until they get the green indicator. on the other hand, people can always just look up each setting on the wiki.
to combat that, you could get the indicator only AFTER you set the sliders and coding has begun.
that way you still can end up with bad work, but you can learn from your mistakes and get a better feel for each development phase.
right now, you have 3x3 sliders, the tech/design ratio, the combo and other factors including a random component that will yield one rating. this makes it hard to really figure out how to make a good or even great game.
with an indicator during development you at least can get a feeling for the sliders. i think it really would make the game more fun.
additionately, with the previously proposed idea to scrap projects during development, this would make sense. screwed up phase 1 (red), tried fixing in phase 2 (still red), scrap, start again.
pay with time and money. or try getting yellow and recover some costs by releasing…
- development time
this could be tricky to implement, possibly break the game and it could be argued that the game sizes already simulate this.
however, how about deciding how long you will be developing each phase. if we say the current game is always 100%, if we could shorten the time, the quality would suffer, lower ratings, possibly cost fans and sale. but i can crank out more games.
if we raise the time, the quality will get better, raise the ratings, get more sales, more fans, but developing the game gets more expensive and I can make less.
of course there is a minimum time (somewhere between 50-80%, could be different for different game sizes) and a maximum time (maybe 150? 200% 300%)
the effects of the time manipulation should not be linear. only spending half the time on the game could possibly cause a 9.0 game to come in as a 2, but spending 300% on a 5 game will not turn it into a 9.0 game.
but it should be possible to turn a 8.x game into a 9.x game or crank out three 5.x games instead of two 6.x games…
)
thanks