Re: Where to start?

On 12 fév, 11:55, "Ulf Åström" <ulf.ast...@xxxxxxxxx> wrote:
On 12 Feb, 11:29, jice <jice.nos...@xxxxxxxxx> wrote:

If the crash can be reproduced, this is not an issue. A crash occuring

I think the fundamental difference is that I'm trying to prevent
crashes from occuring at all. As player, I'd rather see feature X not
working than losing a promising character because of a crash. As
developer, it's much more useful to get a "feature X doesn't work" bug
report than "my game crashes randomly".


Ok, I'm kind of intentionally playing devil's advocate here. I'm not
saying that I'm right and you're wrong. I think both approachs are
viable. Of course, the less crashes you have, the better it is and if
you can avoid some of them by pre-conditions, it's ok. But avoiding
blindly the crashes everywhere will make it very difficult to find the
nasty bugs. I'm speaking about this kind of error handling code :

void my_func (params) {
if (crash condition meet) return; // do nothing
... // do something
}

This will take you to the hell of debugging because you may never
notice that there was something wrong during this function call and
the first visible impact may lead you to the wrong track. IMHO, the
proper handling of an unexpected crash condition would be :

void my_func (params) {
if (crash condition meet) {
// log error and everything needed to track its cause
exit(1);
}
... // do something
}

The exit() is very important because it will allow to correlate the
player's last action/situation to the error. If you only write a log
and keep running the game :
- the player may never notice the error
- he may notice it much later in the game and may not be able to find
out what was its cause.

To finish, I think our two approachs follow two distinct goals :
- either you add lots of controls in the code so that the game never
crashes whatever bugs it contains. This will smooth the player
experience, but your code will be more complicated and some bugs will
be difficult to fix without a very advanced logging system.
- either you let the bugs crash or stop the game. This will be very
painful for the player if you don't do enough testing before
releasing, but eventually, bugs will be corrected faster (and the code
is simpler) (and you need electric fence to use this approach) :)

--
jice

.

Relevant Pages

  • Re: Stalker: 1.0003 patch out!
    ... Fixed the crash upon making the screenshot to a saved game. ... Fixed the bug with standing dead bodies upon connecting to the game. ... Fixed the bug with NPCs spawning in front of the player. ... Fixed various crashes with dedicated server. ...
    (comp.sys.ibm.pc.games.action)
  • Re: Castle Draconia (my own version) completed!
    ... adventure 'Castle Draconia'. ... The game gives the player 200 gold pieces at the beginning of the game. ... Please play around with this adventure and note any bugs in the game. ...
    (comp.sys.cbm)
  • Re: My second roguelike
    ... with bugs at present. ... When I first tried the game the initial ... speed of input) whilst the enemies move every half second as far as I ... Either the player should be limited in how many moves it ...
    (rec.games.roguelike.development)
  • Re: What have you been playing... in SEPTEMBER 2008?
    ... experienced no serious bugs or crashes or any other problems. ... the game, I found most of the new stuff to be a welcoming addition. ... Crysis Warhead. ...
    (comp.sys.ibm.pc.games.action)
  • Re: Where to start?
    ... I consider anything that crashes my game a nasty bug. ... crashes whatever bugs it contains. ... This will smooth the player ...
    (rec.games.roguelike.development)