„Nie optymalizuj wcześnie” nie oznacza „wybierz najgorszy możliwy sposób”. Nadal musisz wziąć pod uwagę wpływ na wydajność (chyba że tylko prototypujesz). Nie chodzi o to, aby okaleczyć inne, ważniejsze rzeczy na tym etapie rozwoju - takie jak elastyczność, niezawodność itp. Wybierz proste, bezpieczne optymalizacje - wybierz rzeczy, które ograniczasz, i rzeczy, które pozostawiasz za darmo; śledzić koszty. Czy powinieneś używać silnego pisania? Większość gier działała i działa dobrze; ile kosztowałoby to usunięcie, gdybyś znalazł ciekawe zastosowania elastyczności w rozgrywce?
Znacznie trudniej jest zmodyfikować zoptymalizowany kod, zwłaszcza kod „inteligentny”. Zawsze jest to wybór, który czyni niektóre rzeczy lepszymi, a inne gorszymi (na przykład możesz handlować czasem procesora na zużycie pamięci). Dokonując takiego wyboru, musisz zdawać sobie sprawę ze wszystkich implikacji - mogą być katastrofalne, ale mogą być również pomocne.
Na przykład Commander Keen, Wolfenstein i Doom zostały zbudowane na zoptymalizowanym silniku renderującym. Każdy z nich miał swoją „sztuczkę”, dzięki której gra istniała w pierwszej kolejności (z czasem opracowano także dalsze optymalizacje, ale nie jest to tutaj ważne). To dobrze . Dobrze jest zoptymalizować sam rdzeń gry, myśl, która umożliwia grę; szczególnie jeśli eksplorujesz nowe terytorium, gdzie ta szczególna zoptymalizowana funkcja pozwala rozważyć projekty gier, które nie były zbytnio badane. Ograniczenia, które wprowadza optymalizacja, mogą również dać ci interesującą rozgrywkę (np. Limity liczby jednostek w grach RTS mogły zacząć jako sposób na poprawę wydajności, ale mają również wpływ na rozgrywkę).
Pamiętaj jednak, że w każdym z tych przykładów gra nie mogłaby istnieć bez optymalizacji. Nie wystartowali z „w pełni zoptymalizowanym” silnikiem - zaczęli od absolutnej konieczności i ruszyli w górę. Opracowywali nowe technologie i używali ich do tworzenia zabawnych gier. A sztuczki silnika ograniczono do jak najmniejszej części bazy kodu - cięższe optymalizacje wprowadzono tylko wtedy, gdy rozgrywka była w większości ukończona lub tam, gdzie pozwoliła na pojawienie się ciekawej nowej funkcji.
Teraz rozważ grę, którą możesz chcieć zrobić. Czy naprawdę jest jakiś technologiczny cud, który tworzy lub psuje tę grę? Może planujesz grę w otwartym świecie w nieskończonym świecie. Czy to naprawdę centralny element gry? Czy gra po prostu nie działałaby bez niego? Może myślisz o grze, w której teren jest odkształcalny bez ograniczeń, z realistyczną geologią i tym podobne; czy możesz sprawić, by działał z mniejszym zakresem? Czy działałoby to w 2D zamiast 3D? Jak najszybciej uzyskaj coś dobrej zabawy - nawet jeśli optymalizacja może wymagać przerobienia dużej części istniejącego kodu, być może warto; a może nawet zdasz sobie sprawę, że powiększanie rzeczy tak naprawdę nie poprawia gry.
Jako przykład ostatniej gry z wieloma optymalizacjami wskazałbym Factorio. Jedną z kluczowych części gry są pasy - jest ich wiele tysięcy i zawierają wiele pojedynczych kawałków materiałów w całej fabryce. Czy gra zaczęła się od mocno zoptymalizowanego silnika pasowego? Nie! W rzeczywistości oryginalna konstrukcja paska była prawie niemożliwa do zoptymalizowania - w pewnym sensie wykonała fizyczną symulację przedmiotów na pasku, co stworzyło kilka interesujących rzeczy, które możesz zrobić (w ten sposób uzyskujesz „wschodzącą” rozgrywkę - rozgrywka, która zaskakuje projektant), ale oznaczało to, że musiałeś zasymulować każdy element na pasku. Dzięki tysiącom pasków otrzymujesz dziesiątki tysięcy symulowanych fizycznie przedmiotów - nawet samo ich usunięcie i pozwolenie pasom na wykonanie pracy pozwala skrócić związany z tym czas procesora o 95-99%, nawet bez uwzględnienia takich rzeczy jak lokalizacja pamięci. Ale warto to zrobić tylko wtedy, gdy faktycznie osiągniesz te limity.
Prawie wszystko, co miało coś wspólnego z pasami, musiało zostać przerobione, aby umożliwić optymalizację pasów. Pasy musiały zostać zoptymalizowane, ponieważ potrzebowaliśmy dużo pasów do dużej fabryki, a duże fabryki to jedna atrakcja gry. W końcu jeśli nie możesz mieć dużych fabryk, dlaczego masz nieskończony świat? Zabawne, że powinieneś zapytać - wczesne wersje tego nie zrobiły :) Gra została przerobiona i wielokrotnie przekształcana, aby dotrzeć tam, gdzie są teraz - w tym 100% remake, gdy zdali sobie sprawę, że Java nie jest dobrym rozwiązaniem taka gra i przeszła na C ++. I zadziałało świetnie dla Factorio (chociaż nadal dobrze było, że nie było zoptymalizowane od samego początku - zwłaszcza, że był to projekt hobbystyczny, który w przeciwnym razie mógłby się nie udać z powodu braku zainteresowania).
Ale chodzi o to, że sąwiele rzeczy, które możesz zrobić z fabryką o ograniczonym zasięgu - i wiele gier właśnie to pokazało. Granice mogą być jeszcze bardziej inspirujące dla zabawy niż wolności; czy Spacechem byłby bardziej zabawny, gdyby „mapy” były nieskończone? Gdybyście zaczęli od mocno zoptymalizowanych „pasów”, bylibyście zmuszeni pójść tą drogą; i nie mogłeś odkryć innych kierunków projektowania (np. zobaczyć, co ciekawego możesz zrobić z symulowanymi fizycznie taśmami przenośnikowymi). Ograniczasz swoją potencjalną przestrzeń projektową. Może się tak nie wydawać, ponieważ nie widzisz wielu niedokończonych gier, ale trudność polega na zapewnieniu dobrej zabawy - na każdą zabawną grę, którą widzisz, prawdopodobnie są setki, które po prostu nie mogły się tam dostać i zostały złomowane (lub gorzej, wydany jako okropne bałagany). Jeśli optymalizacja ci to pomoże - śmiało. Jeśli nie ... to prawdopodobnie przedwczesne. Jeśli uważasz, że jakaś mechanika gry działa świetnie, ale potrzebuje optymalizacji, aby naprawdę zabłysnąć - śmiało. Jeśli nie masz ciekawej mechaniki,nie optymalizuj ich . Najpierw znajdź zabawę - przekonasz się, że większość optymalizacji nie pomaga w tym i często jest szkodliwa.
Wreszcie masz świetną, zabawną grę. Czy warto teraz optymalizować ? Ha! To wciąż nie jest tak jasne, jak mogłoby się wydawać. Czy jest coś zabawnego?możesz zamiast tego zrobić? Nie zapomnij, że Twój czas jest nadal ograniczony. Wszystko wymaga wysiłku, a Ty chcesz skoncentrować się na tym, co najważniejsze. Tak, nawet jeśli tworzysz „darmową grę” lub grę „open source”. Zobacz, jak gra się w tę grę; zauważ, gdzie wydajność staje się wąskim gardłem. Czy optymalizacja tych miejsc sprawia więcej radości (jak budowanie coraz większych, coraz bardziej splątanych fabryk)? Czy pozwala to przyciągnąć więcej graczy (np. Słabszymi komputerami lub na różnych platformach)? Zawsze musisz ustalić priorytety - poszukaj stosunku wysiłku do wydajności. Prawdopodobnie znajdziesz wiele nisko wiszących owoców, po prostu grając w grę i obserwując, jak inni w nią grają. Ale zwróć uwagę na ważną część - aby się tam dostać, potrzebujesz gry . Skoncentruj się na tym.
Podsumowując, weź pod uwagę, że optymalizacja nigdy się nie kończy. To nie jest zadanie z małym znacznikiem wyboru, który kończysz i przechodzisz do innych zadań. Zawsze można zrobić „jeszcze jedną optymalizację”, a dużą część każdego projektu stanowi zrozumienie priorytetów. Nie robisz optymalizacji ze względu na optymalizację - robisz to, aby osiągnąć określony cel (np. „200 jednostek na ekranie jednocześnie na Pentium 333 MHz” to świetny cel). Nie trać tropu celu końcowego tylko dlatego, że zbytnio koncentrujesz się na celach pośrednich, które mogą nawet nie być warunkiem wstępnym dla celu końcowego.