Jak silnie silnik jednego gracza powinien odrzucić nieprawidłowe dane?

W grze dla jednego gracza, gdy próbujesz zbudować byt ze składników określonych w zewnętrznych skryptach, co według ciebie bardziej pożądane jest, gdy jeden z tych elementów jest źle sformułowany:

• Czy silnik powinien pominąć ten komponent i pozwolić istocie żyć w świecie gry tylko z dobrze napisanymi komponentami?
• Czy też nie powinien w ogóle dodawać bytu do świata, jeśli tylko jeden ze składników jest źle uformowany?

Uwaga: nie mówię o rejestrowaniu błędów - które powinny przyjść bez słowa - tylko o tym, co powinno się stać z bytem.

Jeśli mówisz o grze z możliwością modyfikacji, możesz zastosować jedną z powyższych sugestii. Ale jeśli martwisz się przewracaniem własnych błędów, powiedziałbym, że nie rób tego. Zostałem zwolennikiem Fail-Fast . Jeśli jest to błąd, który utworzyłeś i który musisz rozwiązać przed jego wydaniem, powinieneś uczynić go oczywistym. Artykuł, do którego prowadzi link na dole strony wiki, jest dobrym materiałem do przeczytania na ten temat, dlaczego brak szybkiego postu jest dobry, a kiedy powinien i nie powinien być używany.

Różnica między użytkownikiem a deweloperem nie zawsze jest wyraźna w rozwoju gier. Standardowe techniki programowania, takie jak „szybki błąd”, nie zawsze są korzystne, szczególnie w miarę powiększania się zespołu.

Na przykład, być może twój artysta techniczny spieprzył moduł cieniujący dla konturu targetowania - załamał się, powiedzmy, więc ładuje się tylko w systemach SM4, i nie zauważył, ponieważ ma najwyższy system liniowy. Powoduje to, że niektóre animacje nie ładują się. Do tych animacji odwołuje się określone zaklęcie napisane przez projektanta walki. W końcu twoja projektantka poziomów próbuje ustawić spawn na swoim miejscu, a te wszystkie spawn są w stanie rzucić to zaklęcie - ale teraz nie może umieścić żadnego z nich na świecie, ponieważ ich zaklęcia nie są ważne, ponieważ efekty nie są ważne, ponieważ shadery się nie ładują, ponieważ projektanci zawsze mają najgorsze komputery.

Twoje demo nie jest gotowe do 2PM, a twoi inwestorzy zastanawiają się, dlaczego nie możesz zdobyć nawet jednego wroga w grze, a twój projekt zostaje zamknięty.

Lub wybierasz opcję, w której rejestrujesz awarię, ale próbujesz dalej, a gra gra dobrze, z wyjątkiem, że niektóre efekty zaklęć wrogów nie pojawiają się - ale inwestorzy i tak nie wiedzą, jak mają wyglądać, więc nie ogłoszenie.

Z tego powodu prawie zawsze opowiadam się za pierwszą opcją - odrodzenie jak największej ilości bytu. Zdarzają się przypadki awarii w trybie awaryjnym - na przykład jeśli dane nigdy nie powinny być edytowane, z wyjątkiem osób zdolnych do tworzenia kompilacji (tj. Programistów i producentów technicznych) i zawsze są sprawdzane w 100% przy ładowaniu lub jeśli masz absolutną pewność, że osoba odpowiedzialna za problemem jest osoba korzystająca z edytora - ale nie są to zwykłe przypadki i wymagają dużej infrastruktury technicznej jako takiej, w którą możesz nie być gotowy zainwestować.

Użytkownik powinien mieć możliwość podglądu encji, którą zamierza zaimportować, i wcześniej wiedzieć, czy występują błędy.

Powinieneś w jakiś sposób zdecydować, które błędy powinny być śmiertelne, uniemożliwiając dodanie go do gry, a które można odrzucić jako ostrzeżenia .

Oczywiście, jeśli z jakiegokolwiek powodu importowana jednostka może w jakiś sposób nieodwracalnie zmienić dane zapisu, lepiej, aby była bezbłędna.

Sugerowałbym, że przy opracowywaniu powinno być głośno z powodu nieprawidłowych danych. tzn. zaloguj wszystko gdzieś, co będzie czytane. Jeśli jednak silnik może to zignorować i kontynuować, powinien to zrobić. Możesz mieć logikę

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

Nawet w grze wieloosobowej jest to dopuszczalne, chyba że zakładasz, że jeden gracz próbuje oszukać system.

Po wydaniu oprogramowania prawdopodobnie zechcesz wyłączyć to logowanie domyślnie, zakładając, że gracze nie będą czytać tych dzienników.