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

11

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

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

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

component-based validation

— Пол Манта
источник

Мы говорим об одиночной или многопользовательской игре?

— о0 '.

@ Лохорис Одиночная игра.

— Пол Манта,

2

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

— Тетрад,

@Tetrad Я бы хотел, чтобы игра была максимально удобной для моддеров.

— Пол Манта

11

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

— Джон Макдональд
источник

2

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

— Джоккинг

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

— Блецки

7

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

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

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

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

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

— ashes999
источник

1

Я хотел бы думать, что предлагаемый вами сценарий можно предотвратить с помощью хороших систем контроля версий. По вашему сценарию художник «сломал сборку». Любой другой, работающий со сломанным шейдером, должен иметь возможность откатить шейдер до более ранней версии, пока проблема не будет решена.

— Джон Макдональд

1

@John Хотя хороший контроль над исходным кодом является обязательным, и иногда необходим откат для восстановления остальной части проекта до рабочего состояния, пока сбой не будет решен локально, он редко используется в качестве механизма предотвращения и на него не следует полагаться как таковое. ,

@John: В больших проектах сборка может занять несколько часов (или целый день). Таким образом, на самом деле вам нужен двунаправленный подход - вам нужен не только контроль исходного кода, но и бинарный контроль, чтобы непрограммист мог откатиться ко всем предыдущим сборкам. Но, конечно, у этого есть свои риски и издержки, потому что теперь вы разрабатываете новый контент на фоне другого устаревшего контента, с исполняемыми файлами, которые могут иметь другие плохие ошибки. И даже нахождение нужной сборки, к которой можно вернуться, может занять более 30 минут - если всем вашим дизайнерам придется остановиться на полчаса и возиться со сборками, это пустая трата денег.

@Joe Wreschnig: Это имеет смысл. Так что я думаю , там должна быть точка , в которой терпят неудачу быстро больше не является активом. Либо в типах людей, которые его используют, либо в проектах определенного размера. Я полагаю, что люди в команде должны решить, что работает для них.

— Джон Макдональд

2

Я не уверен , что быстро трудно потерпеть неудачу, что на самом деле то , что речь идет о, когда - либо актив. Даже в одиночной «команде», может быть, я не хочу иметь дело с кодом шейдера, потому что мне действительно нужно выполнить этот уровень. Конечно написать хорошую обработку ошибок и регистрировать все ошибки, но я почти всегда имеют лучшее представление о том, что важно прямо сейчас прямо сейчас , чем я сделал , когда я писал код ошибки шесть месяцев назад.

1

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

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

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

— о0' .
источник

0

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

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

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

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

— Питер Лори
источник

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

Вы должны быть в состоянии записать более краткие журналы для выпуска. В развитии вы можете быть более многословным.

— Питер Лори