Witaj!
flowCRANE dodał nowy post w wątku: Jakie składowanie danych silnika gier 2D top-down shooter?
W sensie, że format edytora to nie musi być format silnika. Dokładnie, choć IMO nie tyle nie musi, co wręcz nie powinien. Edytor korzysta z innych formatów plików niż sama gra. Po pierwsze, dzięki temu IDE może w plikach przechowywać metadane, które są przydatne dla samego edytora, ale gra ich nie potrzebuje do niczego. Po drugie, edytor może przechowywać pliki projektu w taki sposób, aby każdy zasób był osobnym plikiem (co ułatwia implementację edytora), natomiast gra może operować na pliku zbiorczym. Np. IDE przechowuje każdy dźwięk w formie osobnego pliku, tak aby można nim było wygodnie zarządzać (przenosić, usuwać itd.) oraz odpalać w zewnętrznych aplikacjach (np. Audacity), natomiast na potrzeby gry, wszystkie pliki dźwiękowe pakowane są do jednego, zbiorczego pliku, ze słownikiem offsetów do buforów konkretnych plików. To samo w przypadku tekstur (luźne pliki PNG dla IDE, bulk file z atlasami dla gry), fontów, kursorów itd. Dodatkową zaletą tego podejścia jest to, że pliki przeznaczone dla gry powinny być binarne i jak najmniejsze: - brak metadanych, których gra i tak nie używa,
- mały rozmiar, maksymalnie przyspieszający czas ładowania danych do RAM/VRAM,
- bonus: utrudniony data mining, kradzież assetów, niechciane modowanie (jeśli na tym ci zależy).
Tego typu podejście sam stosuję, czyli edytor (IDE) operuje na pojedynczych plikach i zapisuje mnóstwo metadanych, natomiast gra operuje na małej liczbie binarnych plików amorficznych, zawierających całe zestawy danych — po jednym pliku dla zestawu fontów, kursorów, tekstur (atlasów), dźwięków, map, modeli, animacji itd. Gra ma zapierdzielać i używać jak najmniejszej ilości danych, edytor może być wolniejszy i operować na dowolnie dużych zbiorach plików i metadanych (byle się w RAM-ie zmieściły).
Z poważaniem,
4programmers.net
|
