A co to znaczy "deweloper"?
Jak powszechnie wiadomo, jestem deweloperem i zajmuję się dewelopowaniem symulatora. Zapewne wielu z Was zastanawia się teraz, co to znaczy deweloper. Postaram się pokrótce (no dobra, macie mnie, nie skończy się tak szybko :D) odpowiedzieć na to pytanie. Zacznijmy od tego, że deweloper to osoba, która zajmuje się budową domów i ich sprzedażą. Uprzedzając pytania, nie mam wolnych mieszkań w samym centrum Warszawy. Po prostu jest to kalka językowa z angielskiego
developer. Pochodzi ono od słowa
develop, czyli 'rozwijać'. Tak więc jestem rozwijaczem symulatora. Ale nie rozwijaczem z rolki, tylko osobą wkładającą pewien zasób pracy intelektualnej w celu polepszenia właściwości programu komputerowego MaSzyna EU07-424.
Równie dobrze ktoś mógłby tutaj zapytać, dlaczego nie można nazywać się jakoś inaczej, tak typowo po polsku. Odpowiedzi są dwie. Pierwsza z nich wynika z tego, że deweloper brzmi po zachodniemu, czyli jakoś tak poważniej, wymusza szacunek (no a nie?). Druga odpowiedź jest taka, że deweloper nie do końca ma określone znaczenie w kontekście symulatora (bo w zasadzie powinien zajmować się nieruchomościami). Istnieje możliwość zastosowania polskich odpowiedników. Weźmy np. takiego twórcę. Twórca powinien coś tworzyć, robić coś z niczego. Mamy nic, zyskujemy coś. Powinien być aktywny przez większość czasu. Jednak niezbyt tutaj pasuje, gdyż często otrzymuje się coś z czegoś, nic z czegoś, albo najczęściej nic z niczego. Programista? Nie, to słowo odpada, gdyż wywodzi się ze słowa informatyk, co w pewnych kręgach ma nieco negatywne zabarwienie. Rozwijacz? Już pisałem o rolce. Modelarz, trasopisarz? To są konkretne funkcje deweloperów. Więc pozostaje deweloper dewelopujący.
Jako że ta kwestia została omówiona, zajmijmy się drugim trudnym słowem na dziś - dewelopowaniem. Jak pewnie się domyślacie, znaczy ono tyle, co rozwijanie. Cóż, jest to wierzchołek góry lodowej. Najprościej mówiąc, jest to ogół środków i czynności podejmowanych w celu polepszenia właściwości symulatora i/lub dodatków. Oczywiście jest to pojęcie pojemne niczym Zas, więc wypadałoby określić, co w ten ogół się wlicza. Oprócz pisania nowych linijek w kodzie źródłowym pliku wykonywalnego, należy dodać testowanie działania, jazdy, rozmowy, konsultacje. Powiedzmy, że jest to pierwsze czytanie tego słowa. Ale jest też drugie, do którego przechodzę.
Jak już pisałem, dewelopowanie jest pojemne i pewne słowa należy rozumieć w przenośni. Konsultacje to z reguły przesiadywanie godzinami na IRCu, gadanie o głupotach. Oczywiście od czasu do czasu zdarza się, że ktoś komuś uświadomi błędy (choć nie zawsze napisze, co dokładniej jest źle), czy pomoże przy pracy. No ale jest tyle rzeczy do obgadania. Poza tym kompilacja się ciągnie w nieskończoność, więc czemu mam czekać bezczynnie? Oczywiście nie siedzi się cały czas na ircu. Po rzeczonej
komplikacji kompilacji należy przetestować nowe exe. Jak to się robi? Odpalamy bata, wszystko się samo kopiuje i uruchamia. Nie jest źle, jeśli sceneria się odpali. Jest dobrze, gdy się nie zawiesi przez pierwsze 5 sekund. Jest bardzo dobrze, jak to, co miało działać, działa. Jest wspaniale, gdy nie utworzyło się nowego błędu. Potem szybkie zamknięcie i ponowne zanurzenie się w mrocznych zakamarkach kompilatora. Oczywiście przy pracy należy się posilać. Empirycznie najlepsze efekty uzyskuje się przy czipsach oraz ajsti (oczywiście z Biedronki). No ale z drugiej strony, jak się je czipsy, to palce są tłuste i szkoda pisać po klawiaturze, bo będzie brudna. Więc się czeka, aż skończą się czipsy, myje ręce i można by było pisać dalej. Jest jedno ale - bez czipsów jakoś tak gorzej idzie.
Oczywiście życie dewelopera nie jest takie proste i kolorowe. Oprócz jedzenia czipsów, picia ajsti i gadania o niczym, należy czasem coś wykonać. Tutaj dochodzimy do ciemnej strony. Od rano do wieczora, a także w nocy odzywają się komentarze:
przydałoby się jeszcze dorobić lampkę X
nie da rady zmienić jeszcze Y
koniecznie należy poprawić Z
W tym całym natłoku informacji trzeba jeszcze objeżdżać w międzyczasie testerów, że pytają o exe sprzed tygodnia, nie testują na bieżąco, nie uwzględniają poprawek. Czasem zrobienie jednej drobnostki zajmuje długie godziny, a nawet tygodnie. I nie ma nawet chwili, żeby skorzystać z zestawu dewelopera...
W chwilach rozmyślań nad miseczką przetworzonych ziemniaczków i szklaneczką brązowozłocistego płynu nadchodzą różne pomysły i rzeczy do wprowadzenia. I tak oto pewnej wiosny, a raczej zimy jeszcze 2007 wpadłem na pomysł polepszenia nieco hamulców, aby coś więcej niż tylko Oerlikon było poprawnie odwzorowane. Skutek jest tego taki, że, z pewnymi perypetiami, piszę już kolejną (trzecią/czwartą) implementację ich. Co jednak cieszy, zanosi się na to, że podstawy będą mogły być niedługo (znaczy się kiedyś tam) wydane. To będą już ze dwa lata grzebania się, ale wychodzi na to, że bardzo owocne. Podobnież było i jest z przekładnią spalinowo-elektryczną, którą to też już jakiś czas męczę. A wszystko zaczęło się od byle jakich kombinacji z przerzucaniem kabin i fizyk między modelami w roku 2005... No ale cóż, człowiek miewa lepsze i gorsze dni, a czasem też lubi sobie zakombinować nie myśląc o konsekwencjach. Tak, to bardzo ważne. Deweloper musi wiedzieć, co robi, nawet jak nic nie robi, bo za jakiś czas nie będzie mógł się wyplątać z tego.
Deweloper musi również mieć plan działania. Np. taki
środa, niedziela - czipsy; poniedziałek, wtorek, piątek - ciacho; czwartek, sobota - woda mineralna
W innym wypadku można nabawić się rozstroju żołądka, miażdżycy bądź cukrzycy. Równie dobrze plan może być abstrakcyjny, np.
pn, śr, sob - modelowanie; wt, czw, nd - exe; pt - jazdy
Oprócz grafiku tygodniowego albo dziennego przydaje się też plan długoterminowy.
Luty - paczka z modelami do testów, Marzec - wypuszczenie modeli, Maj - exe i nowe tekstury
Co jednak ważne, plany takie nigdy nie wychodzą, chyba że są robione z nadmiernym zapasem.
Z racji tego, że już tak się rozpisałem, powinienem pokazać, że deweloper też człowiek. Zatem, jak już wspomniałem, zamierzam w jakimś czasie doszlifować exe do tego stopnia, żeby dało radę funkcjonować bez większych błędów i stawania AI w szczerym polu. Oprócz nowych hamulców, dorzucę jakieś drobiazgi ogólnie i parę koniecznych nowinek do spal-ele. Może uda się jeszcze zrobić jakieś optymalizacje, by wyciągnąć FPSów kilka. Nie wiem, kiedy to nastąpi dokładnie. Zmiany poczynione są takie, że wymagają jakiejś paczki w miarę skompletowanej. Wolę nie ryzykować pójściem na żywioł z daniem samego exeka z dokładnym opisem, bo i tak mało kto to przeczyta w całości (niektórzy proszą o rzeczy będące już w dizelpacku...). Poza tym podchodzę któryś z kolei raz do robienia scenerii, ze skutkiem takim jak zawsze. Odwołując się do spraw świeższych, myślałem nad falownikami, ale bez żadnych charakterystyk tego nie da rady zrobić, poza tym Taurus i Traxx wydają dźwięki w nieco inny sposób. Na chwilę obecną za wiele innych spraw mnie goni.
Cóż jeszcze mogę dodać? Jeśli ktoś chce cieszyć się symkiem, niech zostanie zwykłym szarym użytkownikiem. Rzadko kiedy mam możliwość, żeby po prostu zrobić sobie jakąś misję i pojeździć dla przyjemności. Gdy tylko jadę, testuję. Zapewne każdy deweloper odczuwa to w nieco inny sposób, w każdym razie tak to wygląda z mojej perspektywy. Mam nadzieję, że moja taka refleksja rozjaśnię nieco sytuację panującą.
Pozdrawiam!
----
Początkowo tekst miał traktować o sprawach bieżących, przeszło-przyszłych, ale tak jakoś wyszło.
