Blog Noel Llopis Games from Within wspomniał o tym niedawno w poście „Remote Game Editing” . Pierwszy akapit:
Od dawna jestem fanem minimalnych czasów wykonywania gier. Wszystko, co można zrobić w trybie offline lub w oddzielnym narzędziu, powinno być poza środowiskiem uruchomieniowym. Dzięki temu architektura i kod gry są bardzo uproszczone i proste .
(Artykuł jest wysoce zalecany, podobnie jak w przypadku większości materiałów Noela, niezależnie od tego, czy zgadzasz się w 100%, czy nie).
Uważam, że kluczem tutaj jest utrzymanie złożoności poza silnikiem. Nadal możesz mieć elastyczność, ale jest to elastyczność w potoku treści. Zyskujesz lepszą wydajność, nie tracąc czasu na konwersję i przenoszenie danych.
Co dziwniejsze, lepsza wydajność może przełożyć się na krótszy czas iteracji, pomimo utraty niektórych umiejętności edycji w silniku: łatwiej jest wypróbować coś, jeśli można załadować grę w ciągu sekundy.
Przyjęcie niektórych założeń „ filozofii unixowej ” pomoże ci zachować elastyczność łańcucha narzędzi: niewielki modułowy potok.
Moja osobista filozofia: upiec jak najwięcej danych w jak największym stopniu offline, ale zapewnij wsparcie silnika, aby otrzymywać nowe wypalone dane w dowolnym momencie. (Pamiętaj, że te nowe dane nie muszą wchodzić w grę, dopóki nie jest to wygodne: naciśnięcie przycisku „Odśwież”, rozpoczęcie następnego poziomu, przejście do nowego obszaru, cokolwiek. Kluczem jest znalezienie optymalnego punktu, który minimalizuje czas iteracji przy minimalnej złożoności kodu i nakładzie pracy związanej z kodowaniem).
W naszej firmie większość narzędzi dla artystów / projektantów koncentruje się na kwestiach związanych z interfejsem użytkownika: łatwość manipulowania pojedynczymi zasobami lub ich partiami itp. Czasami są to tylko narzędzia innych firm, takie jak Photoshop lub 3DS Max. Narzędzia te eksportują do formatu pośredniego (często xml, który odwołuje się do źródłowych danych binarnych, ale nie zawsze). Format pośredni jest wybierany przez backendowe narzędzie do tworzenia danych, które przekształca go w coś użytecznego i szybkie ładowanie dla platformy docelowej.
Przenośność osiąga się przez dodanie dodatkowych narzędzi tworzenia danych zaplecza lub rozszerzenie istniejących narzędzi tworzenia danych zaplecza, co ma tę dodatkową zaletę, że jest niewidoczny dla twórców treści.
Teraz, przy poprawnym utworzeniu danych przyrostowych, możesz wprowadzić zmiany w zapisanym formacie w ciągu kilku sekund; Twój silnik może pająka lub narzędzie może pająka, a następnie pojawią się w systemie zasobów, gotowe do ponownego załadowania, gdy będzie to wygodne.
Narzędzia - zwłaszcza narzędzia do tworzenia danych zaplecza - są często niechlujne i zawierają więcej błędów niż kod silnika. Jest to w porządku, ponieważ łatwiej jest je refaktoryzować / przepisywać, rozszerzać i testować; masz specyfikacje dotyczące ich zachowania i dość łatwo można je przetestować w jednostce w porównaniu z niektórymi kodami silnika.
Moje opinie na twoje pytania:
Czy silnik powinien być w stanie ładować różne formaty obrazów? Program ładujący tylko TGA jest dość łatwy w obsłudze.
(Poza tym: nawet jeśli używasz wbudowanego dekodera TGA, nie koduj go ręcznie. Po prostu prosisz o kłopoty - jest wiele subtelności w większości formatów obrazów i wiele narzędzi, które nie są zgodne dokładnie do prawdopodobnie nieokreślonego formatu. Najlepiej jest znaleźć istniejący dobrze przetestowany kod biblioteki do przetwarzania obrazów).
Chciałbym, aby tutaj narzędzie przekonwertowało z TGA na dowolny wewnętrzny format tekstury plus metadane.
Co z formatami audio? Czy jest możliwe obsługiwanie tylko ładowania plików wav? Co z plikami muzycznymi otoczenia, które często są ogromne.
Używamy tutaj trzech formatów: śledzonej muzyki (.xm), ADPCM (.wav) i Speex (.spx). Wynika to głównie z tego, że korzystamy z urządzeń przenośnych, a te formaty są bardzo lekkie do odkodowania.
Czy silnik powinien być zdolny do dynamicznego analizowania TTF i generowania atlasu? Pakowanie tekstur.
Atlasing to trudny problem: zobacz odpowiedzi na ostatnie pytanie . Prawie zawsze warto robić to offline.
Dodatkowo możesz przekształcić metadane według znaków w upakowaną strukturę prawie zerowego obciążenia.
Na zakończenie możesz wyczyścić i spakować ten potok ze swoją grą, dla społeczności modów. Zawsze możesz dodać więcej formatów źródłowych. I nic nie stoi na przeszkodzie, aby w określonych przypadkach wypełnić lukę między narzędziami do tworzenia treści a silnikiem; miejmy nadzieję, że Twój kod do pieczenia danych i kod pająka / transferu mogą zostać przekształcone w biblioteki, które w niektórych przypadkach mogą być później wykorzystane bezpośrednio przez narzędzia do tworzenia treści. Ale nie uczyniłbym tego moim pierwszym celem, koniecznie ... Tylko pamiętaj, że będzie to cel ostateczny i pozwól, aby wpłynęło to trochę na twój projekt, i najpierw wybierz nisko wiszące owoce.
Jako aktualizację warto rozważyć użycie formatu plików KTX dla tekstur. Ma tę zaletę, że jest „wczytywana structi używana” w większości przypadków użycia GL (a z twoich komentarzy brzmi, jakbyś celował w GL), a jednocześnie jest elastyczny i dobrze zdefiniowany.
Narzut nagłówka KTX może być nieco wysoki dla w pełni upieczonych danych, w zależności od celu, i możesz zrezygnować z obsługi wymiany endianów, w zależności od przypadku użycia ... ale zdecydowanie jest to warte przynajmniej rozważenia ze względów projektowych.