How forcefully should a single-player engine reject invalid data?

Question

In a single-player game, when trying to build an entity out of components specified in external scripts, what do you think is more desirable to happen when one of the components is ill-formed:

• Should the engine skip over that component and let the entity live in the game world with only the components that were well written?
• Or should it not add the entity to the world at all if but one of the components is ill-formed?

Note, I'm not talking about logging the errors — that should come without saying — just about what should happen to the entity.

Answer 1

If you're talking about a moddable game, then you might want to follow one of your suggestions above. But if you are concerned about rolling over your own errors, I'd say don't do it. I have become an advocate of Fail-Fast. If this is an error that you have created and must resolve before releasing, you should make the error obvious. The article that is linked to at the bottom of the wiki page is a good read on the subject with why failing fast is good, and when it should and shouldn't be used.

Answer 2

The distinction between user and developer is not always clear in game development. Standard programming techniques like "fail fast" are not always advantageous, especially as team sizes grow.

For example, perhaps your technical artist has screwed up the shader for the targeting outline - broke the fallback, let's say, so it's only loading on SM4 systems, and he didn't notice because he's got a top of the line system. This results in some animations failing to load. Those animations are referenced by a particular spell your combat designer has written. Finally, your level designer is trying to get the spawns in place and those spawns all happen to be able to cast that spell - but now she can't place any of them in the world because their spells aren't valid because the effects aren't valid because the shaders won't load because the designers always have the worst computers.

So your demo isn't ready by 2PM and your investors wonder why you can't even get a single enemy in the game and your project gets shut down.

Or you choose the option where you log the failure but keep trying, and the game plays fine except some enemies spell effects don't appear - but the investors don't know what those are supposed to look like anyway, so they don't notice.

For that reason, I'll almost always advocate the first option - spawn as much of the entity as you can. There are cases for fail-fast - like if the data should never be edited except by people capable of doing builds (i.e. programmers and technical producers) and is always checked 100% at load, or if you're absolutely sure the person responsible for the problem is the person using the editor - but those are not the usual cases, and require a lot of technical infrastructure per se, which you might not be ready to invest in.

Answer 3

The user should be able to preview the entity he is going to import, and know in advance if there are errors.

You should somehow decide what errors should be fatal, preventing it to be added to the game, and which can be dismissed as warnings.

Of course if for any reason the imported entity might be somehow able to irreversibly alter the savegame data, you'd better require for it to be flawless.

Answer 4

I would suggest that in development, it should be noisy about invalid data. i.e. log everything somewhere it will be read. However, if your engine can ignore this and continue it should do so. You can have logic like

void setValue(int value) {
    if (value < MIN_VALUE) {
       log(value + " is too low, using " + MIN_VALUE);
       value = MIN_VALUE;
    }
    if (value > MAX_VALUE) {
       log(value + " is too high, using " + MAX_VALUE);
       value = MAX_VALUE;
    }
}

Even in a multi-player game this is acceptable unless you are assuming that one player is trying to cheat the system.

After releasing the software, you are likely to want to turn off this logging by default on the assumption the players are not going to read these logs.