PORADY AMATORA
// Od zera do amatora przez lata nauki
Zdecydowanie trzymałbym się z dala od silników wysokiego poziomu, takich jak Unity lub Torque2D MIT. Są świetne dla małych prototypów, ale nigdy nie wziąłbym ich na poważnie, aby opracować własną grę wideo. Dlaczego miałabym? Jaki jest sens, chyba że był to zwykły remake SideScroller lub Arcade?
Większość silników gier, bibliotek lub frameworków wykonuje tylko najprostsze zadania z dużą ilością rozdętego kodu z funkcjami i funkcjami, których nigdy nie użyjesz.
Kiedy wiele lat temu byłem nowy w tworzeniu gier, zacząłem na szczycie. Silniki na bardzo wysokim poziomie. Nie ma czegoś takiego jak RPG MAKER, ale zdecydowanie wysoko tam, jak Unity i Torque. Potem poszedłem niżej, do XNA i C #, ponieważ miał tak wiele zasobów i samouczków. Mój główny projekt wymagał wydajności, a może po prostu mam obsesyjno-kompulsywne pragnienie niewiarygodnej wydajności w moim oprogramowaniu, nawet jeśli nie jest to duży projekt. XNA po prostu tego nie wyciął i miałem wiele problemów z silnikiem, który przeczytałem, wymagało bólu głowy do naprawienia. Jaki jest sens używania czegoś „wyższego poziomu”, takiego jak XNA / C #, gdy wykonuje się tę samą pracę (naprawianie błędów i problemów XNA), jak przy tworzeniu własnego silnika w C ++?
Po dość długim okresie nauki w końcu dowiedziałem się o projektowaniu silników gier i zacząłem analizować kod samych silników. Czytając to, co ma do powiedzenia większość profesjonalistów, a także skargi krytyków silników gier uświadomiłem sobie: „Po co w ogóle korzystać z silnika?”.
Oczyszczanie mojego C ++ i naprawdę wchodzenie w niektóre filozofie używane w tym języku bardzo mi pomogło. Jednak tyle czasu poświęciłem na naukę tak wielu rzeczy, że chciałem po prostu zacząć grę.
Skończyło się na tym, że mam dość pochwał, był C ++ i bardzo niski poziom: SDL. Niestety był to ból głowy. Jest tak niski poziom, nie widzę żadnego powodu, aby nawet korzystać z tej biblioteki. Wolę po prostu nauczyć się OpenGL i zrobić to od zera. Szczerze mówiąc, to głównie fakt, że potrzebowałem zaimplementować własny kod, aby zrobić coś tak podstawowego jak odwrócenie obrazu (a implementacja innych nie działała z powodu tego, jak obchodziłem się ze sprite'ami), skłoniła mnie do trwałego wyrzucenia SDL. To świetnie, jeśli chcesz renderera oprogramowania, ale IMO wolę wyrzucić go, aby obniżyć go ze sprzętem (OpenGL) lub wyższym (SFML).
Nie chcąc kupować kolejnej książki na Amazon i uczyć się kolejnego API, poszedłem wyżej. SFML jest po prostu wspaniały, nie wspominając o bardzo chwalonej w Internecie. Przeczytałem prawie nieskończoną liczbę pozytywnych recenzji, bez żadnych negatywnych opinii. Nie mogę powiedzieć tego samego o SDL. Obsługuje wszystkie ekstremalne podstawy, ale resztę pozostawia mi i innym wybranym bibliotekom. Utknąłem z tym do tej pory.
IMO, silnik gry jest po prostu głupi. Biblioteki niskiego poziomu są znacznie lepszym wyborem zarówno dla ekspertów, jak i początkujących programistów.
Warto również zauważyć, że nauczyłem się więcej o koncepcjach programistycznych i wyostrzyłem swoje umiejętności tworzenia oprogramowania, gdy zmuszony byłem radzić sobie z rzeczami na niższym poziomie, niż kiedykolwiek nauczyłem się z silnikami WYSIWYG na wysokim poziomie.
Co daje ci coś takiego jak Unity w porównaniu z XNA? Edycja wizualna i kula. Początkujący w końcu dowiedzą się, że nadal będziesz musiał kodować prawie całą grę, tak jak gdybyś miał już C ++, a edytory wizualne są nieefektywne w stosunku do czegoś, co sam możesz stworzyć.
Co daje coś takiego jak XNA w przypadku SFML lub własnej implementacji OpenGL i innych przydatnych bibliotek? IMO, absolutnie nic dobrego. Gorsza wydajność, C # zamiast C ++, mnóstwo samouczków dla początkujących, ale znacznie mniej profesjonalizmu, a niektórzy oszczędzający ból głowy, że IMO są po prostu kulą do tego, czego powinieneś nauczyć się z C ++. Początkowo byłem zastraszany przez C ++ i uwielbiałem C #, głównie ze względu na słyszenie i pogłoski o opiniach głupców, którzy mieli takie same kłopoty, jak na początku w C ++: Chciałem po prostu wystarczająco dobrego programisty. Zdałem sobie sprawę, że muszę nauczyć się więcej podstaw i wyostrzyć swoje słabości, aby przezwyciężyć problemy z C ++, które C # „ułatwił”. Czy kiedykolwiek tęsknię za prostotą niektórych rzeczy w C #? Nawet nie! Wiem, jak to zrobić w C ++ bez żadnych problemów.
Jeśli zastraszają Cię biblioteki niskiego poziomu lub nauka DirectX / OpenGL, poczekaj, aż zaczniesz się komplikować, tworząc pełną grę wideo.
Moją filozofię dotyczącą silników gier można streścić w dwóch przykładach wyjaśniających nadmiarowość i bezużyteczność silników, z wyjątkiem pojedynczych okoliczności.
Początkujący zastraszani bibliotekami niskiego poziomu będą mieli atak, gdy odkryją, że nawet przy silniku wysokiego poziomu, takim jak Unity (oprócz renderowania grafiki, odtwarzania audio, ładowania treści; naprawdę podstawowych rzeczy) będzie to prawie identyczne z tworzeniem gry od zera. Złożoność polega na zaprojektowaniu gry, niezrozumieniu interfejsu API lub opracowaniu klas do renderowania na wyświetlaczu.
Eksperci, którzy nie są zastraszani złożonością tworzenia pełnej gry w coś takiego jak Unity, nie mają pożytku dla Unity, ponieważ czas, w którym pewnie zajęło by nauczenie się API i wymagań konkretnego silnika, prawdopodobnie bardziej boli mnie głowa i więcej czasu zajęłoby kodowanie kilku klas wymaganych do podstaw.
Silniki są więc bezużyteczne dla początkujących, ponieważ początkujący nie mogą nic z nimi zrobić, ponieważ brakuje im umiejętności inżynieryjnych. Podobnie, silniki są bezużyteczne dla weteranów, ponieważ mają już umiejętności inżynieryjne, aby zrobić to bez silnika, i równie dobrze mogą rzucić własnym bardziej wydajnym, specyficznym „silnikiem”, niż męczyć się z nauką interfejsu API silnika gry, funkcje i dziwactwa wydajności. Nie wspominając już o ogromnym koszmarze pracy z silnikami, których czasami nie można dotknąć, ponieważ nie są one oprogramowaniem typu open source (a nawet jeśli tak, czytanie kodu innej osoby może być czasem koszmarem).
Do diabła, nawet niektóre „niskie poziomy” „frameworki” są niczym więcej niż kilkoma klasami do tworzenia okna, renderowania na wyświetlacz i odtwarzania dźwięku. Jest to coś, co profesjonalista mógłby zrobić od zera przy użyciu innych bibliotek, takich jak SDL / SFML lub własnej implementacji OpenGL / DirectX / OpenAL, w ułamku czasu potrzebnego na ukończenie pełnej gry wideo.
TLDR;
Jeśli chcesz programować, naucz się być programistą .
Unikaj używania silników , ale nie bądź głupcem i ignoruj niezwykle przydatne biblioteki.
Jeśli chcesz zostać projektantem gier , wypróbuj silnik WYSIWYG i wypompuj te gry!
Jeśli chcesz zostać programistą gier , unikaj silników takich jak kule.
Dla mnie używanie silników gier wyższego poziomu osłabiło moją zdolność zostania programistą. W momencie, gdy zacząłem korzystać z bibliotek niższego poziomu lub w ogóle nie korzystać z żadnej biblioteki, zacząłem się tak dużo uczyć, że szybko przeszedłem od zupełnie nowego początkującego do kogoś, kto może teraz tworzyć gry wideo bez żadnego odniesienia, samouczków lub książki obok mnie. Tylko mój kompilator i dużo inżynierii i praktyki.
Ilość nauki, którą zdobyłem z bibliotek niskiego poziomu w KRÓTKIM okresie czasu była znacznie większa niż ilość, którą zdobyłem W BARDZO DŁUGIM czasie z SILNIKAMI wyższego poziomu. **