Wątek "Artysta poszukiwany" skłonił mnie do założenia nowego wątku - parę refleksji na temat tworzenia gier. Mam cichą nadzieję, że również inni opiszą swoje (zawodowe lub hobbystyczne) doświadczenia na tym polu.
Oczywiście, również na Atari tworzyłem swego czasu sporo gier (prawie wszystkie nie wyszły poza pierwsze 1-3 levele, lub inne początkowe stadium - a taki Robocop na XL/XE (już nie pamiętam czym się wtedy inspirowałem, może był to Nintendo?), skończył się na kilku pierwszych "ekranach"), miałem podobne problemy, o których pisze Mgr Inżynier w wymienionym wątku, zwłaszcza, kiedy jeszcze pisałem w Basicu :) (Potem dzięki m.in. Tajemnicom Atari przerzuciłem się na Quick Assembler - co ciekawe, nie odbiega tak znacząco funkcjonalnością od tego, co dzisiaj jest, nawet posiadał okienka dialogowe).
Okiem praktyka, który robi jako hobby gry od A do Z (programowanie, grafika, dźwięk):
Muszę przyznać, że w wielu przypadkach sytuacja przy programowaniu gier (nie mówię o rzeczach pokroju silnik do Unreal Tournament) znacząco się poprawiła, wiele rzeczy już nie jest takich uciążliwych, i choć dyski twarde ciągle mają skłonność do "padania", a dyski internetowe ("chmury" - nawiasem idiotyczna nazwa) mają szereg wad, możliwości zabezpieczenia wielo-tygodniowej / -miesięcznej pracy jest nieporówynwalnie większa dzisiaj.
Dotyczy to również grafiki. Pamiętam, jak tworzyłem w asemblerze na Atari szereg specjalistycznych narzędzi, m.in. wzorowanym trochę na interfejsie Windows 3.x do szybkiego tworzenia animacji. Choć program miał sporo opcji, oczywiście do takiego Gimpa było mu daleko. Dzisiaj tworzenie grafiki komputerowej w znacznie większym stopniu przypomina pracę artysty - dzięki dostępnym narzędziom ze strony software'owej i hardware'owej. Przyznam, że nie miałbym cierpliwości dzisiaj do robienia animacji w ten sam sposób, co kiedyś - piksel po pikselu, zresztą nie byłoby to nawet realistyczne w czasach rozdzielczości full hd (1920x1080) na telefonie, w porównaniu do powiedzmy 160x240 pikseli. Dla odmiany, dzisiaj mamy graficzne programy wektorowe czy wspomnianego Gimpa (produktów Adobe praktycznie nie ruszam z pewnych względów), które wykonują ogrom pracy za twórcę. Pewnym nieciekawym efektem ubocznym widocznym w grach na Android, Windows Phone czy Iphone tego typu szybkiego tworzenia grafiki, jest fakt, że w prawie wszystkich grach wygląda ona tak samo (niby-komiksowo) - czyli wszędzie równie idiotycznie, coś na wzór Angry Birds ;)
Wracając do programowania, dziś już nie piszę oczywiście w taki sposób, jak w asemblerze, tzn. proceduralnie, czego uczył długi kurs tego języka w Tajemnicach Atari. Obiektowość - wszędzie, gdzie tylko można sobie na to pozwolić - bardzo przyspiesza programowanie i porządkowanie kodu: niektóre klasy mogą być nawet puste lub niemal puste (przykładowo, klasa głównego bohatera może jedynie dziedziczyć po ogólnej klasie abstrakcyjnej, tzn. być zupełnie pusta, zawierająć jedynie nazwę - a mimo to działa! :) ).
Jest zresztą szereg innych zmian, poczynając od udogodnień narzędzi, na samych możliwościach i metodach kończąc, włączając w to istnienie wielu bibliotek, zarówno wbudowanych w różne platformy, jak i niezależnych. Bez tego nie ma mowy o popularności jakiejkolwiek platformy dzisiaj: od czasów 8/16-bit wiadomo, że platforma (kiedyś wystarczyło powiedzieć: "komputer") jest tak popularna, jak istniejący software na nią - tzn. jego ilość i jakość. Nawiasem, szef Amstrada tego nie rozumiał, i był to jeden z powodów jego porażki na rynku.
Gdybymyśmy jednak cofnęli się do czasów 8-bit, myślę, że pierwsze, co bym zrobił, to zabrał się za tworzenie ugodonień i narzędzi (i być może wydał je nawet w firmie takiej jak L.K Avalon), a w następnej kolejności za programowanie gier. :)
A propos ostatniego zdania - w Avalonie tak trochę było - np. powstał tam Avalon Music Composer potem przemianowany na Chaos. W Mirage używaliśmy produktów konkurencji, to znaczy Chaos Music Composer :)
co do narzędzi... może to nie Atari, ale na C= gdy robiliśmy z Zephyrem Miecze Waldgira i Eternal to Zephyr napisał sobie swój mini OS na REU (commodorowskie rozszerzenie RAMu) miał linię komend i pamiętam tyle, że przełączając banki po 64kb mógł wgrać kod, grafikę, muzę do pamięci, linkować to i uruchamiać - wszystko z lini komend własnymi prostymi narzędziami/komendami. poza tym mieliśmy edytor leveli (mam go do tej pory ale zapomniałem hasła aby go uruchomić - narzędzie było zahasłowane aby lameria go nie umiała używać - teraz ja nie potrafię ;) )
co do robienia gier teraz... rok temu zacząłem robić gry na iOS/Andorid. chciałem zrobić stzelankę ale nie zdążyłem (więcej o tym niebawem) ale w międzyczsie zrobiłem jedną gierkę dla dzieci + 2 inne (równie mało popularne ;) to co chcę powiedzieć to fakt że narzędzi teraz jest masa i trzeba być leniem żeby nie zrobić gry.... tzn jak ktoś chce zrobić (na prawdę chce) to wybiera narzędzie a potem wujek google poprowadzi jak zrobić z tego grę... wybór jest spory. Ja wybrałem rok temu CORONA SDK ale jest tego od groma... np Unity - dzisiaj by to wybrał. Wogule teraz jest prosto....
Action! nie istnieje na STE. Można by (nie ja :) przeportować Amiga E, w sumie się trochę dziwię, że nie ma oficjalnych prób w tym kierunku... Język rewelacyjny, napisałem w tym StarBall na Amigę, jednak gra zniknęła w czeluściach czasu.
Co do "prosto", zależy co kto właściwie robi. :) Jeśli korzysta z rzeczy typu Unity, czy nawet drag&drop, to faktycznie będzie to prostota. Nie wyobrażam sobie jednak bardziej unikalnej gry, takiej jak "Misja" lub "Prince of Persia" (ta pierwsza, rewolucyjna wersja na 16-bit), zrobionej w click-edytorze.
Odrębną kwestią jest również grafika w grze, oraz dźwięk. Bez tradycyjnych narzędzi (programy dla grafików czy dźwiękowców), obawiam się, że wiele się nieosiągnie tutaj. Niestety, oba wymagają wprawy, zaangażowania i doświadczenia.
