Mam około tysiąca linii kodu do stworzenia własnej kosmicznej gry 2D, która tworzy sieci losowo generowanych układów gwiezdnych i wypełnia je losowym wyborem planet, stacji, statków i broni.

Potencjalnie będą setki różnych stacji / statków / itp., Z których będzie musiała korzystać gra - oto co zastanawiałem się. Czy powinienem poświęcić czas na stworzenie modułu ładującego dane „zakodowanego na miękko”, który przechowywałby wszystkie te informacje w (na przykład) plikach XML, a zatem łatwiej byłoby je później zmodyfikować, czy też powinienem po prostu skorzystać z tego, co mam? robiłem właśnie teraz - na stałe zakodowałem wszystkie obiekty w głównym silniku gry.

Jestem jedyną osobą biorącą udział w projekcie i, jak powiedziałem, to tylko hobbyści, które robię w wolnym czasie poza uniwersytetem. Ale czy społeczność zaleciłaby inwestowanie w stworzenie całego dodatkowego systemu przechowywania danych w dodatkowych plikach?

Jakie są zalety takiego kodowania danych w porównaniu do zwykłego kodowania wszystkich za pomocą konstruktorów? Czy istnieje długofalowa korzyść z posiadania zewnętrznych plików, które można modyfikować - jeśli nie szukam w grze modów, to czy konieczne jest posiadanie zewnętrznych plików? Jeśli jest to tylko kwestia hobbystyczna, z której mógłbym zrezygnować za kilka tygodni lub miesięcy, czy powinienem tracić na to czas?

Tak. Należy wdrożyć system, aby ładować zawartość poza główny silnik.

Nagłówki zwięzłych odpowiedzi.

Nie. Nie zajmuje to zbyt wiele czasu.

Myślę, że pytanie, czy jest to prawidłowy przydział twojego ograniczonego czasu, jest dyskusyjne; nawet jeśli tylko dlatego, że będzie to niewielka część całkowitego czasu projektu.

Spędzisz setki (tysiące) godzin na projekcie gry, który podejmiesz do końca. Być może nie na klonie Ponga, ale na pewno w przypadku złożonej gry kosmicznej. Porównaj to z czytnikiem plików konfiguracyjnych. Wdrożenie systemu do XML rury do swojego głównego konstruktora, a następnie uruchom ponownie do procesu gry, zajmie być może 10 lub 20 godzin. Nawet jeśli zajmie ci 50 lub 100, będzie to niewielki ułamek całkowitego czasu projektu.

Zaoszczędzi to czas

To nie jest czas; to inwestycja czasu. I to się opłaci.

Przepływ pracy ma znaczenie, a posiadanie programu ładującego konfigurację poprawi przepływ pracy. Tworząc system, który pozwala edytować konfiguracje w locie, zaoszczędzisz niezliczone przebudowy. Możesz spojrzeć na grę, gdy jest uruchomiona, dostosować XML i ponownie sprawdzić w kilka sekund. Lub możesz spojrzeć na kod, znaleźć linię kodu (spośród tysięcy), bardzo ostrożnie edytować jego wartości (jesteś w głównym silniku, mimo wszystko), odbudować, wykonać, przywrócić grę do stanu testowego, postaraj się pamiętaj, jak to wyglądało przed zmianą i sprawdź, czy zmiana przyniosła zamierzony efekt. Zakładając, że nic nie psuje się w twoim silniku, Twój pociąg z pewnością jest zakłócony.

Z bardziej fundamentalnej perspektywy, pamiętaj, że najbardziej czasochłonną częścią oprogramowania do pisania jest brak dodatkowych naciśnięć klawiszy lub białych znaków. Poluje na robale. A jeśli poświęcisz trochę więcej czasu na wyjaśnienie, pisząc bardziej szczegółowy kod, zaoszczędzisz sobie więcej czasu później. W twoim przypadku napisanie importera treści daje czystszy kod, który będzie łatwiejszy do odczytania. Zamiast mil zapisanych na stałe wartości Twoje źródło będzie zawierać proste ładowanie pliku. Podobnie, możesz odczytać plik konfiguracyjny bez przeszukiwania kodu silnika gry. Obie części stają się łatwiejsze w utrzymaniu i łatwiejsze do debugowania.

Zespoły jednoosobowe odnoszą największe korzyści

Jeśli wynająłeś artystę do wygenerowania części tej zawartości, musisz stworzyć narzędzia do pracy. Muszą dokonać edycji pikseli i szybko zobaczyć efekty. Nie odważyłbyś się zmusić ich do przebudowania kodu, aby zobaczyć każdą zmianę. Ich czas jest drogi i nie chcesz go marnować.

Teraz wyobraź sobie, że artysta jest bardzo niewykwalifikowany i powolny (programista) i ma wiele innych rzeczy do zmartwienia, ponieważ są również głównym programistą i muzykiem. Na pewno nie chcesz tracić tego czasu, w przeciwnym razie projekt nigdy się nie skończy. I ten gówniany artysta będzie nienawidził szkolenia, aby być lepszym artystą, ponieważ spędzają cały czas na zmianie nazw łańcuchów zasobów w kodzie.

Nie rób tego sobie. Zrób narzędzia, a będziesz miał więcej czasu na stworzenie gry.

To dobre pytanie, a najlepszą odpowiedzią, jaką mogę udzielić, jest to, że tylko doświadczenie może naprawdę powiedzieć, kiedy warto wybrać ścieżkę trudniejszą / czasochłonną. Jeśli ktoś mówi ci, że powinieneś ZAWSZE robić to w „właściwy” sposób, to po prostu się mylą.

Już rozumiesz, że jest to kompromis. Z jednej strony, kodowanie jest tak kuszące, ponieważ można szybko i łatwo rozpocząć, ale na dłuższą metę dodawanie funkcji i debugowanie stanie się koszmarne. Z drugiej strony napisanie wspaniałego, elastycznego, rozszerzalnego systemu wymaga dużych nakładów początkowych, ale sprawia, że ​​życie jest o wiele łatwiejsze na dłuższą metę.

Celem jest ukończenie czegoś, a jeśli utkniesz w tworzeniu świetnego systemu, cel cofnie się i stracisz motywację. W niektórych okolicznościach kodowanie jest w porządku, ale musisz zrozumieć konsekwencje takiego działania. Oto kilka powodów, dla których twarde kodowanie jest złym pomysłem:

• Możesz myśleć, że Twój projekt jest mały, ale możliwe jest, że rośnie, gdy zdecydujesz się dodać więcej funkcji. Jeśli zaczniesz programowanie na twardo, nadejdzie czas, kiedy energia potrzebna do jego utrzymania (aktualizowanie go o nowe rzeczy i naprawianie niezliczonych nieuniknionych błędów) zacznie poważnie przewyższać początkowe zyski.

• Rzeczy zakodowane są z definicji specyficzne dla bieżącego projektu. W następnym projekcie będziesz musiał zacząć od nowa, być może ponownie zakodować różne rzeczy (bo z tym będzie ci wygodnie). Jeśli poświęcisz czas na porządny system ładowania, możesz pominąć tę pracę i problemy związane z przyszłymi projektami.

• W tej chwili możesz pracować sam, ale może przyjść chwila, kiedy chcesz zaprosić kogoś innego do projektu. Czy poświęcisz trochę czasu, aby wyjaśnić swój obrzydliwy system parafialny i napisać dla niego dokumentację?

• Kodowanie często wiąże się z koniecznością zrozumienia, co oznaczają określone liczby magiczne lub skomplikowane zależności klasowe. Być może teraz możesz mieć to wszystko w pamięci, ale poczekaj, aż odejdziesz od kodu przez jakiś czas. Nawet przy obszernych komentarzach do źle zaprojektowanej struktury jest piekło.

Powiedziałbym, że powinieneś czuć się swobodnie w twardym kodowaniu tylko najmniejszych szczegółów. Jeśli masz choćby pojęcie o elemencie, nad którym pracujesz, jest używany przez kogoś innego, znacznie się powiększa lub jest używany w innym projekcie, poświęć chwilę, aby zrobić to dobrze.

Z drugiej strony prototypuję jak szaleniec, a pewne kodowanie na stałe jest szybkie i łatwe i pozwala ci skoncentrować się na eksperymentowaniu. To zależy od twojego stylu pracy.

Mówisz o programowaniu opartym na danych .

W przypadku małych projektów inwestycja w czasie może nie być warta czasu, ponieważ często istnieją o wiele ważniejsze funkcje, które można ulepszyć.

Jednak programowanie oparte na danych może być BARDZO łatwe do wdrożenia. Jeśli myślisz o tym poważnie, prawdopodobnie powinieneś użyć XML, JSON lub YAML, ale możesz także użyć zwykłego pliku tekstowego.

Programowanie oparte na danych

Plusy

1. Pozwala projektantom na dostęp i modyfikowanie danych gry bez wiedzy programistycznej
2. Możesz modyfikować grę bez konieczności ponownej kompilacji . Nie należy tego lekceważyć, ponieważ w ten sposób można znacznie szybciej rozwijać grę. Dobre gry pojawiają się po wielu iteracjach.

Cons

1. Wdrożenie wymaga czasu i wysiłku.
2. Może to zwiększyć złożoność programu.