Насколько сильно движок для одного игрока должен отклонять неверные данные?

В однопользовательской игре, когда вы пытаетесь построить сущность из компонентов, указанных во внешних сценариях, что, по вашему мнению, более желательно, если один из компонентов плохо сформирован:

• Должен ли движок пропустить этот компонент и позволить сущности жить в игровом мире только с хорошо написанными компонентами?
• Или это вообще не должно добавить сущность в мир, если только один из компонентов плохо сформирован?

Заметьте, я не говорю о регистрации ошибок - которые должны произойти без слов - просто о том, что должно происходить с объектом.

Если вы говорите о модифицируемой игре, то вы можете последовать одному из ваших предложений выше. Но если вы беспокоитесь о своих собственных ошибках, я бы сказал, не делайте этого. Я стал защитником Fail-Fast . Если это ошибка, которую вы создали и должны исправить перед выпуском, вы должны сделать ошибку очевидной. Статья, на которую есть ссылки в нижней части вики-страницы, - это хорошее прочтение на тему, почему неудачный быстрый подход хорош, а когда его следует и не следует использовать.

Различие между пользователем и разработчиком не всегда ясно в разработке игр. Стандартные методы программирования, такие как «быстро проваливаются», не всегда выгодны, особенно с ростом численности команды.

Например, возможно, ваш технический художник испортил шейдер для контура нацеливания - допустил отказ, скажем, так, что он загружается только в системах SM4, и он не заметил, потому что у него самая лучшая система. Это приводит к тому, что некоторые анимации не загружаются. На эти анимации ссылается конкретное заклинание, написанное вашим боевым конструктором. Наконец, ваш дизайнер уровней пытается установить спавнов на место, и все эти спавны способны разыграть это заклинание - но теперь она не может поместить ни одного из них в мир, потому что их заклинания недействительны, потому что эффекты не Это не так, потому что шейдеры не загружаются, потому что у дизайнеров всегда самые плохие компьютеры.

Таким образом, ваша демоверсия не готова к 2:00, и ваши инвесторы задаются вопросом, почему вы не можете даже получить ни одного врага в игре, и ваш проект закрывается.

Или вы выбираете вариант, где вы регистрируете неудачу, но продолжаете пытаться, и игра играет нормально, за исключением того, что некоторые эффекты заклинаний врагов не появляются - но инвесторы не знают, как они должны выглядеть, так что они не делают уведомление.

По этой причине я почти всегда буду защищать первый вариант - порождать как можно больше сущностей. Существуют случаи быстрого отказа - например, если данные никогда не должны редактироваться, кроме как людьми, способными делать сборки (например, программистами и техническими производителями), и всегда проверяются на 100% при загрузке, или если вы абсолютно уверены, что лицо, ответственное за проблема заключается в том, кто использует редактор - но это не обычные случаи, и они требуют много технической инфраструктуры как таковой, в которую вы, возможно, не готовы инвестировать.

Пользователь должен иметь возможность предварительно просмотреть объект, который он собирается импортировать, и заранее знать, есть ли ошибки.

Вы должны как - то решить , какие ошибки должны быть фатальными, предотвращая его быть добавлен в игру, и которые могут быть отклонены как предупреждения .

Конечно, если по какой-либо причине импортированный объект может каким-либо образом необратимо изменить данные сохраненной игры, вам лучше потребовать, чтобы он был безупречен.

Я хотел бы предложить, что в процессе разработки должно быть шумно о недействительных данных. тоесть лог всё где-то будет прочитано. Однако, если ваш двигатель может игнорировать это и по-прежнему он должен сделать это. Вы можете иметь логику, как

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;
    }
}

Даже в многопользовательской игре это приемлемо, если только вы не предполагаете, что один игрок пытается обмануть систему.

После выпуска программного обеспечения вы, вероятно, захотите отключить эту запись по умолчанию при условии, что игроки не будут читать эти журналы.