Przerwa z pisaniem, bo spiętrzyło się trochę rzeczy. Ale od 9tego do 20tego stycznia jest 11 dni, jakaś masakra czasowa. Oczywiście cośtam mogę na listę “dlaczego nic nie zanotowałem” wrzucić – od operacji żony zaczynając, przez różne problemy rodzinne aż po… no dobra – wystarczy szukania.
Suma sumarum istotne jest TYLKO co się zadziało – skończyłem framework czegoś co roboczo od lat nastu funkcjonuje u mnie jako OnceUponATime.
Szkielet do tworzenia struktury gameplayu, questów, postaci, zależności. Powiązania międzyobiektowe bez klas, więc idealne do wdrażania/portowania na cokolwiek łącznie z jakimiś archaicznymi developmentami na 8bitowcach.
Początkowo było to proste C ze strukturami, w tej chwili a w zasadzie od trzech lat funkcjonowało w prototypach paru gier jako kawałki (bardzo małe fragmenty) mojego kodu. Jak to się odbywało? Jak robiłem InPlainSight to potrzebowaliśmy jakoś osadzić logikę dialogów. Logikę nieco pokręconą w sensie nie do końca liniową, powracającą na różnych warunkach w różne etapy danego dialogu. Przynajmniej tak wyglądał edge case, który wykluczał użycie czegoś innego. Przy okazji – robiąc prototyp w czystym C++ i terminalu i testując to, odkryłem parę tzw. blokerów. Paradoksalnie – teraz na Unreal Engine 5 i World Partition moje myślenie w postaci tego frameworku ma jeszcze większy sens. Ludzie utykają na wrzucaniu wszystkiego w klasy, potem z tego blueprint i na scenę. Tylko robi się problem, jak w streamingu ten blueprint… pojawi się nie wtedy kiedy myślimy, że się pojawi, bo jest poza naszym polem widzenia i loadingiem danych sceny. No właśnie.
Wracając do InPlainSight to bardzo bardzo okrojony fragment OnceUponATime. W sumie taki dość banalny przykład na zastosowanie dużej ilości warunków oraz nielubianej przez większość programistów funkcji switch 🙂 W sumie nie wiem dlaczego ludziki preferują miliard if’ów opakowanych jeszcze w elseify i else – szczególnie w sytuacjach, gdy operujemy czymś przewidywalnym – np. integerem albo enumeratorem. Podobne myślenie systemem struktur miałem robiąc DarkWeb do Creature Lab‘a czyli takiego trochę symulatora Dr Hyde i Frankensteina, finalnie ta koncepcja i struktura wjechała na stół roboczy też do głównej gry. Cały subsystem gry (czyli DarkWebu) to trochę logiki i trochę danych, które są referencjami do obiektów w grze właściwej. Taka gra w grze, albo obok właściwej gry. Bliżej OnceUponATime jestem robiąc teraz Haunted House Renovator, aczkolwiek znowu – tutaj bardziej questy – w zasadzie idealne rozwiązanie tylko wymagające zmiany myślenia z ze stricte obiektowego, ale tutaj jest na tyle szczęśliwa sytuacja w stosunku do First Dwarfa, przy którym przez moment pracowałem, że zaoranie czegoś i przepisanie jest z mocy tych palców, które piszą te słowa. Im dalej z developmentem, tym ciężej jest te decyzje podejmować.
Sumując – mam już ten framework w takiej postaci, że ma w zasadzie wszystko co chciałem, przy oczywiście jakichś sufitach tego projektu.
Co to ma do tego developmentu? Oczywiście odpowiedź jest skomplikowana, bo jeszcze nie chcę do końca powiedzieć w czym rzecz. Za wcześnie, a internet jest jak palantir, nigdy nie wiesz kto to czyta.
Powiedzmy, że jest projekt A czyli temat tego devloga. Prosta “mała” gra*. Bez fajerwerków. Jest corem jest struktura danych oraz replaybility. Wykorzystuje jakąś część OnceUponATime plus parę innych moich małych frameworków. Teraz komplikujemy. Jest druga gra, projekt B. Też wykorzystuje trochę OnceUponATime, ale generalnie jego mechanika idzie w inną stronę i cały ciężar podobnie – inny kierunek niż projekt A. I teraz najgorsze: jest też projekt C, który powstał tylko i wyłącznie, aby pobawić się formą psychologiczną w grze pierwszoosobowej oraz… by wykorzystać framework OnceUponATime. Czyli takie trochę tech demo frameworku, ale w praktyce trochę więcej. Czyli więcej niż roztrojenie umysłu.
I tak i nie. Przyjąłem taką metodę małych kroków. OnceUponATime wdrożę całościowo (projekt C) jako dojadę z projektami A i B. Ten B może być sztosem, ale mam cały czas z tyłu głowy, że może to jest tylko moje wraże bo #nikogo.
Najgorsze jest to, że ten framework miałem już prawie zrobiony w 2015 roku pod development na 3DSa. Ale Nintendo robiło jakieś problemy z zakupem dev kita, prawie 2 lata mnie zwodzili, po czym jak już dostałem zieloną flagę, to średnio mi się już chciało pakować w to kasę, bo… wjechał już Switch i wiadomo było, że uwalą starsze konsole mobilne. BTW koniec marca 2023 to jest data zamknięcia eShopu na WiiU i 3DSa. Szkoda 🙁
Plusem sytuacji obecnej jest to, że przerobiłem framework pod na tyle uniwersalną formę, że przepięcie go pod SwiftUI i MacOS/TvOS/iOS nie jest problemem. Bo projekt A i projekt B to wieloplatformowe marzenie. Aczkolwiek – z paru powodów jedzie to w tej chwili u mnie jako projekt w Unreal Engine co jest trochę nieoptymalne, ale najmniej odrywa mi głowę od core mojej pracy teraz.
*Wnioski nr 14: w małym zespole, szczególnie solo developmencie nie ma czegoś takiego jak “mała gra”, “drobne zmiany”, “lekko poprawię strukturę”. Serio – to jest fikcja. Tym bardziej – że to mówimy o projekcie (projektach), które jadą po godzinach, a umówmy się – czasem problemy z pracy, które trzeba rozwiązać – zostają w głowie i jest bloker z własnymi rzeczami.