MoaCube

[Bedziom]

Prosz Cię bardzo ;)

[TeeGee]

Wczoraj wrzuciłem na bloga artykuł o GameMakerze z perspektywy profesjonalnego robienia gier. Może kogoś zainteresuje:

 

http://moacube.com/blog/professional-devel...k-at-gamemaker/

[Will]

Jeśli gm ma tylko takie wady to i tak nie jest tak źle. Unity sprawia znacznie więcej problemów i można kurwi.. dostać czasami. Moim zdaniem powinni do gm dołożyć możliwość pisania pluginów z pełnym dostępem do natywnego api(chyba, że już można?)w c# czy c++ a całość byłaby doskonała do 2D.

[TeeGee]

Problemy z fullscreenem, wczytywaniem zasobów i brakiem multi-platformowości są naprawdę poważne. Wiadomo, że prostą gierkę da się zawsze zrobić, ale jeśli klecisz coś komercyjnego i nagle okazuje się, że nie działa na 20% kompów, na pozostałych wygląda jak kupa w fullscreenie, a o Maku i iOS możesz zapomnieć, to niestety jest źle.

 

Sam fullscreen i crash na wczytywaniu zasobów daje automatycznego faila w certyfikacji większości portali. Przy takim Cinders to przejdzie, bo gra niszowa, na portale się nie pakujemy i możemy te problemy obejść po naszemu. Ale jeśli ktoś faktycznie chce zarobić, to póki co powinien poszukać czegoś lepszego niż GM.

 

Aczkolwiek - wiadomo - nie ma narzędzi idealnych. Tak jak piszesz, Unity też potrafi ostro wkurwić. Do 2D chyba na razie GM jest i tak najlepszy, ale niestety cały czas jest traktowany jako program dla dzieci, nawet przez YoYo Games.

 

Pluginy z pełnym dostępem do API byłyby fajne, ale chyba nie ma co na to liczyć :(.

[Will]

Z jednej strony na pewno masz racje. Jest to jakiś tradeoff, który trzeba mocno przemyśleć. Z unity są podobne problemy. Prosty przykład:

To jest tekstura, którą sobie generuje dynamicznie w unity:

http://dl.dropbox.com/u/5303770/texture.jpg

Niby wydaje się no problem, trochę zabawy pixelami i mamy teksturke. Przychodzi co do czego okazuje się, że funkcje unity do modyfikowania tekstury ze strony kodu(setPixels,Apply) Są tak niemiłosiernie wolne, że wydajność z 35fps'ów, o które walczyło się ostatnie kilka tygodni spada do jednej klatki na sekundę. No dobra no problem przecież Unity ma pluginy! Zrobię teksturę w takim pluginie i po problemie... WRONG

W pluginie możesz tylko modyfikować tekstury używając OpenGL..(nie ma dostępu do urządzenia d3d) czyżby tylko mały problem dla kogoś ktoś pisał cały czas w d3d? WRONG

Defaultowo unity na pc korzysta z d3d więc jeśli chcę się użyć ogla trzeba to wymusić.. sukces? WRONG

Takie coś nie będzie działać na windowsie, tylko na macu.

 

Można sobie odpuścić jak sami coś takiego chcemy zrobić dla frajdy a jak mamy takie wymaganie dla projektu? A takich cudów unity dostarcza wiele(a elementów dla większej gry, które trzeba przerzucić do kodu dla optymalizacji jest sporo). W końcu byłem zmuszony przenieść całość do shaderów a to nie jest takie proste i tanie bo trzeba wepchać w shadery coś co jest przeznaczone dla normalnych języków.

 

Kolejny przykład: Kiedyś pisałem projekt z lasami wokół całej trasy, jakieś 10h jednego dnia na ułożenie. Uruchamiam na drugi dzień i.. drzew nie ma :) Po TYGODNIU udało się to naprawić ale wtedy.. wiatr przestał oddziaływać na rośliny.

Kolejny przykład: Projekt nad, którym pracowałem jakieś 3 miesiące po update do kolejnej wersji unity z wydajnością zjechał do 10fps.. i rób co chcesz nie masz dostępu do natywnego kodu silnika...

Kolejny przykład: Unity ma crasha przynajmniej raz na dzień przy tym raz na kilka tyg przy tym miesza część planszy i.. rób co chcesz. Wysłać info do unity? Pewnie, tylko dorzuć do tego swój projekt, który ma 1.5Giga!

Takich przykładów mam setki jak nie więcej, przez ostanie 2 lata takie cuda unity robiło, że głowa boli.

 

Tak więc patrząc z tej strony równie dobrze można napisać o unity tak samo: "to póki co powinien poszukać czegoś lepszego niż Unity."

Prawda jest taka, że wszystko ma jakieś cholerne błędy, które potrafią zatrzymać projekt na długie dni czy tygodnie. Problem jest w tym, że w unity czy gm nie mamy właśnie dostępu do natywnego api, gdyby takie coś było dostępne sami moglibyśmy takie cuda naprawić.

 

Oczywiście masz 100% racje, że "Wiadomo, że prostą gierkę da się zawsze zrobić" i zarówno w unity jak i w gm'ie wszystko jest w porządku jeśli robisz coś prostego albo mieszczącego się w wyobrażeniach twórców. Mimo tego co napisałem mógłbyś spróbować przerzucić gierkę na unity, nie potrzebujesz w sumie pełnej wersji do stworzenia komercyjnego projektu. Dla gierki 2D brak dynamicznych cieni czy render do tekstury nie powinien być jakimś problemem a dużym plusem unity jest to, że działa na wielu konfiguracjach i jest na pewno szybsze niż gm.

[gnysek]

Myślę, że i tak mało problemów TeeGee znalazł. Tak naprawdę jest ich więcej i Mike oraz Russel o nich wiedzą ale - jak powiedzieli - to Sandy tu rządzi. Powie, że mają przychodzić w baletkach do pracy to zaczną. Dlaczego nie ma update'ów GM 8.1? Bo Sandy kazał robić Studio i tylko to się liczy. GM9 powstaje po godzinach, bo pewnie inaczej Sandy by stwierdził, że lepiej rozwijać to co już jest niż pisać coś na nowo, bo za długo to będzie trwać (mimo korzyści jakie to przyniesie).

Nie powiem już o dziurach w samym języku, czy np. evencie Trigger który sporo zwalnia grę (każdy trigger tak naprawdę dodaje nowy event step z ifem do wszystkich obiektów).

Na obecną chwilę zgodzę się jednak, że fullscreen (który działa przecież w GM7), oraz ładowanie zasobów to największy szit w GM (binarny odczyt z dysku wszystkich grafik w almorze i zapis do jednego pliku-paczki (ok. 5MB) trwa szybciej, niż wczytanie jednej grafiki 1024x768 za pomocą sprite_add!)

[Will]

Nie powiem już o dziurach w samym języku, czy np. evencie Trigger który sporo zwalnia grę (każdy trigger tak naprawdę dodaje nowy event step z ifem do wszystkich obiektów).

Nie rozważali przejścia choćby na mono?

 

Na obecną chwilę zgodzę się jednak, że fullscreen (który działa przecież w GM7)

Nie bardzo rozumiem z czym może być problem z fullscreenem. Jak mniemam gm napisany jest w d3d?

 

ładowanie zasobów to największy szit w GM (binarny odczyt z dysku wszystkich grafik w almorze i zapis do jednego pliku-paczki (ok. 5MB) trwa szybciej, niż wczytanie jednej grafiki 1024x768 za pomocą sprite_add!)

Tu akurat się nie dziwie. Wczytywanie w binarnych paczkach jest znacznie szybsze niż ładowanie pojedynczych plików.

[TeeGee]

Will, jestem pewiem, że o Unity dałoby się napisać podobny artykuł. Zresztą o innych narzędziach też. Na twitterze znajomy zadeklarował, że napisze coś podobnego o Ren'py, a Fano chce o MMF2. Co prawda sam z Unity miałem tylko pobieżną styczność, ale gadałem z kilkoma developerami, którzy go używają i przyglądałem się z boku produkcji jednego tytułu, i wiem że takich problemów, o jakich piszesz, jest tam multum.

 

Dlatego bardziej niż same problemy w GM, przeszkadza mi niechęć YoYo Games do updatowania swojego programu. Unity jest wadliwe, ale przynajmniej regularnie wychodzą nowe wersje. Czasem oczywiście update tylko dokłada problemów (pamiętam cyrk z przechodzeniem do wersji 3.0), ale generalnie można zakładać, że obecne problemy zostaną kiedyś poprawione. W GM problem z fullscreenem został po prostu zwaive'owany jako "Won't fix" i koniec tematu. Programiści wzieli się za pisanie kolejnych droższych wersji programu opartych na niedziałającym rdzeniu. Co z tego, że nie działa, co z tego, że nie ma wersji na Maka - wydamy to i pro devsi od razu zapłacą te ?200, nie?

 

Unity ma przynajmniej normalnie działający edytor - ten sam na Maka i PC (choć ten na PC faktycznie lubi się powiesić). W GM masz przesrane - jak chcesz mieć wersję na OS X, to pozostaje tylko pracowanie w GM4Mac i późniejsze portowanie na GM8.0. A jakie jest GM4Mac, to każdy wie.

 

 

Nie opłaca mi się już przerzucać gierek do Unity. Tak jak pisałem w artykule - do naszych gier akurat GM ujdzie. Pozwala na szybki development, kłopotów z performancem nie ma, a problemy jakoś obchodzimy. Zresztą, mimo że darmowe Unity jest ogólnie całkiem powerne, to do gier 2D jest bardzo niewygodne bez odpowiednich pluginów. A pluginy to już tylko wersja pro.

Natomiast ten większy projekt, o którym wspominam na końcu wpisu, ma iść na engine'ie pisanym konkretnie pod taki typ gier. To są już bardziej poważne pieniądze i do tego cudze, więc nie zamierzam ryzykować.

[TeeGee]

Myślę, że i tak mało problemów TeeGee znalazł. Tak naprawdę jest ich więcej i Mike oraz Russel o nich wiedzą ale - jak powiedzieli - to Sandy tu rządzi.

Problemów jest więcej, ale celem artykułu nie było wypisywanie wszystkich bugów i niedogodności (zwłaszcza tych do obejścia, bo np. triggerów można po prostu nie stosować). Skupiłem się tylko na tym co może faktycznie zabić większy projekt.

 

fullscreen (który działa przecież w GM7)

W GM7 też nie działa poprawnie pod Windows7. Sprawdzałem to przy okazji dyskusji o problemie tu na forum.

[ANtY]

Will, jestem pewiem, że o Unity dałoby się napisać podobny artykuł. Zresztą o innych narzędziach też. Na twitterze znajomy zadeklarował, że napisze coś podobnego o Ren'py, a Fano chce o MMF2.

No to chyba czas napisać co odpier**la SFML przy większych projektach ;)

 

 

takie cuda to normalka, o dźwiękach już nie wspominając

 

Z tego co dotychczas widziałem to nie ma softu, który by nie robił trudności przy większych projektach, tyczy się to też bibliotek do c++. Ciekawe jak jest z UDK.

[TeeGee]

W UDK też są oczywiście problemy :). Problemy są zawsze. Ważne czy jest dobry support i szansa na ich naprawienie.

[gnysek]

Tu akurat się nie dziwie. Wczytywanie w binarnych paczkach jest znacznie szybsze niż ładowanie pojedynczych plików.

 

Pojedyncze na paczkę. Zresztą wypakowanie, zapisanie na dysk do wczytania i skasowanie też jest szybsze, niż samo wczytanie. Nawet Firefox czy Chrome sobie z tym szybciej radzą...

[ANtY]

W UDK też są oczywiście problemy :). Problemy są zawsze. Ważne czy jest dobry support i szansa na ich naprawienie.

W SFMLu support i szanse na naprawienie gorsze niż w GMie. Laurent (twórca sfmla) na każdy znaleziony błąd mówi, że zostanie to poprawione w SFML 2.0, który niestety powstaje już 2 lata. Oprócz tego nie potrafi pomóc nawet z najmniejszymi pierdołami pytając się 4 razy, czy na pewno nie zapomniałeś załadować sprita, a jak w końcu do niego dotrze, że nie to już innych pomysłów na rozwiązanie nie ma >.>

[Will]

ale generalnie można zakładać, że obecne problemy zostaną kiedyś poprawione

Generalnie :P Od 2 lat zawsze robię save sceny zanim otworzę edytor krzywych, tak na wszelki wypadek.

 

 

Zresztą, mimo że darmowe Unity jest ogólnie całkiem powerne, to do gier 2D jest bardzo niewygodne bez odpowiednich pluginów. A pluginy to już tylko wersja pro.

Natomiast ten większy projekt, o którym wspominam na końcu wpisu, ma iść na engine'ie pisanym konkretnie pod taki typ gier. To są już bardziej poważne pieniądze i do tego cudze, więc nie zamierzam ryzykować.

Ja tam żadnych "obcych" pluginów nie używam :) Cenie sobie swoje nerwy. W większości przypadków autorzy pluginów nie wiedzą co znaczą słowa optymalizacja czy bug free.

Jeśli nie zamierzasz ryzykować to sprawdź baaardzooo dobrze ten silnik bo potem może się okazać, że będzie trzeba połowę jego kodu przepisać nawet jeśli jest przeznaczony dla danego typu gier a do tego już potrzeba kogoś kto dokładnie wie z czym to się je i sporo czasu.

 

Pojedyncze na paczkę. Zresztą wypakowanie, zapisanie na dysk do wczytania i skasowanie też jest szybsze, niż samo wczytanie. Nawet Firefox czy Chrome sobie z tym szybciej radzą...

Kiedyś poprawiałem program gdzie jakaś crucial funkcja wczytywała dane znak po znaku bez buforowania więc wszystko da się spier.. jeśli tylko bardzo się chcę. Powinni zrobić jedno wielkie archiwum i przy budowie projektu dorzucić analizowanie kolejności wczytywania i według tego ułożyć całość w paczkach a potem ładować w wielkich chunkach z wyprzedzeniem na drugim wątku. Zapewne mają taką samą wersje funkcji wczytywania od x lat i nikomu nie chcę się nic z tym robić :P

 

W SFMLu support i szanse na naprawienie gorsze niż w GMie. Laurent (twórca sfmla) na każdy znaleziony błąd mówi, że zostanie to poprawione w SFML 2.0, który niestety powstaje już 2 lata. Oprócz tego nie potrafi pomóc nawet z najmniejszymi pierdołami pytając się 4 razy, czy na pewno nie zapomniałeś załadować sprita, a jak w końcu do niego dotrze, że nie to już innych pomysłów na rozwiązanie nie ma >.>

Takie życie :) Ma inne pomysły ale łatwiej jest mu kogoś spławić niż poświęcić X swojego czasu.

[TeeGee]

Haha, napisali do mnie właśnie twórcy Constructa2. Spodobała im się moja recenzja GameMakera (nic dziwnego, skoro jedzie po ich konkurencji) i chcą mi wysłać licencję, żebym napisał coś o ich programie. Problem: ja naprawdę nie przepadam za czysto wizualnymi narzędziami do programowania.

[Skowron1993]

oO Nie widziałem tego programu nigdy :D Obejrzałem filmik z tworzenia i... wow :D Wygląda bardzo ładnie, przetestuję sobie ten programik :P

[Muuuuczek567]

Ja miałem Constructa i mogę powiedzieć, że GM jest łatwiejszy w obsłudze.

[ANtY]

Z Constructa korzystałem jeszcze przed GMem. Strasznie zabugowany i wizualne układanie warunków nie równa się z normalnym kodzeniem. Poza tym co chwilę crashował, tyle tylko, że performance lepszy niż GM.

 

@Muczek: łatwiejszy jak już się go ogarnie ;)

[Muuuuczek567]

Pewnie tak, ale ja mam tak, że jak czegoś nie ogarnę w dwa dni, to nie ogarniam więcej : (

Z GM-em poszło mi szybciej.

[TeeGee]

Mam trochę wolnego, więc postanowiłem popracować nad rozwinięciem prototypu puzzlowego dungeon crawlera, który wypociłem na którymś DBC. Gierka będzie się nazywać Bonfire i wygląda na razie tak:

 

 

Powoli dopracowujemy styl postaci i GUI. Jeszcze sporo placeholderów zostało, no i tło nie pasuje, ale kroczek po kroczku...

[Konrad-GM]

Mam trochę wolnego, więc postanowiłem popracować nad rozwinięciem prototypu puzzlowego dungeon crawlera, który wypociłem na którymś DBC. Gierka będzie się nazywać Bonfire i wygląda na razie tak:

 

 

Powoli dopracowujemy styl postaci i GUI. Jeszcze sporo placeholderów zostało, no i tło nie pasuje, ale kroczek po kroczku...

GUI brzydkie, zwłaszcza te okienka statystyk postaci... Ofc. nie chodzi mi o grafikę, lecz o układ. ;)

[TeeGee]

Spoko. Tak jak mówię - to dopiero prototyp i dosłownie z godziny na godzinę wszystko się zmienia. Wiadomo, że finalne ikonki dużo dadzą, w miejsce postaci muszą być ładne portreciki, a tło nie może być czarną plamą. Poleciała też historia u góry ekranu.

[getStringFromObject]

Podlaczajac sie do tematu narzekania na frameworki/silniki, ja swoje projekciki klepie w libgdx-ie (framework do javy) i patrzac na liste wad i zalet GM-a/SMF-la (znajomi na compo pisali gre w SMFL-u, crashowala sie srednio co 4/5 minut przez bledy we wskaznikach - GC to jednak duze ulatwienie) wydaje sie ze do projektow 2D ciezko znalezc lepsze narzedzie.

Jedyny problem jaki jest z libgdx-em, to dosc wysoki prog wejscia - trzeba miec opanawana jave, wiedziec zeby nie igrac z GC, brakuje troche tutoriali i dokumentacji. Poza tym miod i orzeszki - caly framework opensourcowy wiec zawsze mozesz sobie doczytac w kodzie jak dziala dana funkcja (lub dopisac/poprawic jesli masz sile przejsc przez kompilacje natywnych fragmentow), community wysmienite, aktywnosc glownych devow i czestotliwosc wydawania kolejnych buildow tez, wydajnosc w 2D znacznie lepsza niz to co oferuje unity (sauce: http://www.thesecretpie.com/2012/07/unity-...erformance.html ). Do tego gra dziala prawie ze od razu na wszystkich systemach obslugujacych jave, androidzie, html5. Backend iOS-owy wlasnie powstaje.

[TeeGee]

Mini-projekcik pomyka sobie dalej:

 

 

Lepsze GUI, bardziej pasujące tło, większe postacie. Powoli przypomina to grę. Jeszcze ikonki i brak dużych portrecików psują efekt, ale kroczek po kroczku...

[ANtY]

archer szczegolnie ladny, tlo faktycznie lepiej pasuje. Moze zaloz nowy temat dla tej gry

[TeeGee]

Chyba jeszcze za wcześnie. Nie wiem kiedy i czy skończę ten projekt, i nie wygląda jeszcze wystarczająco dobrze.

[TeeGee]

Ostatnio wygrzebałem cały zestaw zdjęć naszego zespołu, który kurzył się na dysku czekając na ewentualną publikację. Część jest zrobionych w czasie pracy, część podczas premierowej biby Cinders (choć tam większość raczej się nie nadawała do pokazywania światu).

 

 

W albumie na fejsie jest tego więcej. Miłego :).

[TeeGee]

Polygamia ma tę swoją serię wywiadów z polskimi twórcami gier. Tu link do naszego.

[Nikas]

Brakuje mi tylko czegoś o alkoholu w tym wywiadzie, bo to chyba dosyć ważny element w Waszej ekipie. :D

[gnysek]

W każdej ekipie. Najlepsze pomysły na grę powstają przy wódce. A te najbardziej poje*ane i zboczone przy sake w KKW... Szkoda tylko, że Magi nie podpiąłeś tam, wstydzisz się go ? ;)