HamsterMan

Nie lubię takich skryptów jak ten którego używasz :P Dlatego napisałem własny:
 
Wszystko w scripts:
zapisz
//zapisz(nazwa_mapy); //UWAGA! //Wykonywac tylko 1 raz na 1 step! //Nazwa pliku: file_name = argument0; zmienne_n = 0; obiekty_n = 0; //Lista obiektow do zapisania: dadaj_obiekt('ob_gracz'); dadaj_obiekt('ob_przeciwnik'); dadaj_obiekt('ob_platforma'); dadaj_obiekt('ob_data'); //Lista zmiennych obiektow (wszystkich) do zapisania: dodaj_zmienna('x',0); dodaj_zmienna('y',0); dodaj_zmienna('sprite_index',0); dodaj_zmienna('image_index',0); dodaj_zmienna('direction',0); //Tylko dla obiektu 'ob_data': dodaj_zmienna('skin','ob_data'); dodaj_zmienna('tlo','ob_data'); //Reszta Cie nie interesuje :P instance_deactivate_all(1); instance_activate_all(); file_open_write(file_name); for(n=0;n<instance_count;n+=1;) {     i = instance_id[n];          if instance_exists(i)     {         for(a=0;a<obiekty_n;a+=1;)         {             if obiekty[a] = string(object_get_name(i.object_index))             {                 file_write_string('['+string(object_get_name(i.object_index))+';');                                  for(b=0;b<zmienne_n;b+=1;)                 {                     dd=false;                                          if zmienne[b,1] != '0'                     {                         if zmienne[b,1] != string(object_get_name(i.object_index))                         {                             dd=true;                         }                     }                                          if dd=false                     {                         execute_string('val = i.'+string(zmienne[b,0])+';');                                                  if is_string(val)                         {                             val = '"'+string(val)+'"';                         }                         file_write_string(string(zmienne[b,0])+';'+string(val)+';');                     }                 }                                  file_write_string(']');                 break;             }         }     } } file_close();
dadaj_obiekt
//dadaj_obiekt(nazwa_obiektu); obiekty[obiekty_n] = string(argument0); obiekty_n += 1;
dodaj_zmienna
//dodaj_zmienna(nazwa_zmiennej,nazwa_obiektu); zmienne[zmienne_n,0] = string(argument0); zmienne[zmienne_n,1] = string(argument1); zmienne_n += 1;
odczytaj
//odczytaj(nazwa_mapy); //UWAGA! //Wykonywac tylko 1 raz na 1 step! //Uzywac tylko w pustym roomie :) Wiadomo dlaczego. file_name = string(argument0); file_open_read(file_name); map_str = file_read_string(); file_close(); dt = string_count('[',map_str); dt2 = string_count(']',map_str); if dt != dt2 {     show_error('To nie plik mapy!',1);     exit; } repeat(dt) {     temp = string_replace_all( string_replace_all( string_copy(map_str,0,string_pos(']',map_str)-1),'[',''),']','');          map_str = string_replace(map_str,'['+temp+']','')          obiekt=string_copy(temp,0,string_pos(';',temp)-1);     temp=string_replace(temp,obiekt+';','');          dt3 = string_count(';',temp)/2;     n = 0;          repeat(dt3)     {         zmienna[n] = string_copy(temp,0,string_pos(';',temp)-1);         temp = string_replace(temp,zmienna[n]+';','');         wartosc[n] = string_copy(temp,0,string_pos(';',temp)-1);         temp = string_replace(temp,wartosc[n]+';','');         n += 1;     }          execute_string('i=instance_create(0,0,'+obiekt+');');          n=0;          repeat(dt3)     {         execute_string('i.'+zmienna[n]+'='+wartosc[n]+';');                  n+=1;     } }
I tyle. Działa to trochę powoli ale sprawnie :) Liczę że pojawię się w creditsach jeśli wasze gry się ukażą ;)
 
EDIT
Jeszcze przykład:
https://gmclan.org/up152_11_mapa.html
Dodać na GMC? ;]

Tytuł: M.E.A.T.
 
Gatunek: RPG, cRPG
 
Opis: 

M.E.A.T. w telegraficznym skrócie
Jest to gra RPG single player, stylizowana na klasyki gatunku z lat ’90. XX wieku, wykonana w rzucie 2D i grafice Pixel Art. Przed graczem stoi zadanie, w formie kampanii jednoosobowej, rozwikłania zagadki stanowiącej główną linię fabularną i pokonanie najważniejszego antagonisty, tj. nadrzędnego bossa. 

Gracz w trakcie rozgrywki rozwija swoją postać na wielu płaszczyznach typowych dla gatunku RPG. Postępy w rozwoju postaci opierają się na czasie poświęconym treningom i walce przeciwko AI. Poza działaniami związanymi z głównym wątkiem (opartymi na decyzjach skutkujących określonym rozwojem rozgrywki i tym samym dostępnością zadań), istnieje szereg misji pobocznych. 
Gra posiada otwarte zakończenie – nawet po wykonaniu ostatniej misji, gracz jest w stanie nadal odkrywać dalszy świat M.E.A.T.-a, jak i walczyć z przeciwnościami, jakie owe uniwersum postawi na jego drodze.
 
Autorzy: Trippin Bears
 
Strona na wspieram.to

Screeny: 




Trailer:
 

Tytuł: M.E.A.T.
 
Gatunek: RPG, cRPG
 
Opis: 

M.E.A.T. w telegraficznym skrócie
Jest to gra RPG single player, stylizowana na klasyki gatunku z lat ’90. XX wieku, wykonana w rzucie 2D i grafice Pixel Art. Przed graczem stoi zadanie, w formie kampanii jednoosobowej, rozwikłania zagadki stanowiącej główną linię fabularną i pokonanie najważniejszego antagonisty, tj. nadrzędnego bossa. 

Gracz w trakcie rozgrywki rozwija swoją postać na wielu płaszczyznach typowych dla gatunku RPG. Postępy w rozwoju postaci opierają się na czasie poświęconym treningom i walce przeciwko AI. Poza działaniami związanymi z głównym wątkiem (opartymi na decyzjach skutkujących określonym rozwojem rozgrywki i tym samym dostępnością zadań), istnieje szereg misji pobocznych. 
Gra posiada otwarte zakończenie – nawet po wykonaniu ostatniej misji, gracz jest w stanie nadal odkrywać dalszy świat M.E.A.T.-a, jak i walczyć z przeciwnościami, jakie owe uniwersum postawi na jego drodze.
 
Autorzy: Trippin Bears
 
Strona na wspieram.to

Screeny: 




Trailer:
 

Tytuł: M.E.A.T.
 
Gatunek: RPG, cRPG
 
Opis: 

M.E.A.T. w telegraficznym skrócie
Jest to gra RPG single player, stylizowana na klasyki gatunku z lat ’90. XX wieku, wykonana w rzucie 2D i grafice Pixel Art. Przed graczem stoi zadanie, w formie kampanii jednoosobowej, rozwikłania zagadki stanowiącej główną linię fabularną i pokonanie najważniejszego antagonisty, tj. nadrzędnego bossa. 

Gracz w trakcie rozgrywki rozwija swoją postać na wielu płaszczyznach typowych dla gatunku RPG. Postępy w rozwoju postaci opierają się na czasie poświęconym treningom i walce przeciwko AI. Poza działaniami związanymi z głównym wątkiem (opartymi na decyzjach skutkujących określonym rozwojem rozgrywki i tym samym dostępnością zadań), istnieje szereg misji pobocznych. 
Gra posiada otwarte zakończenie – nawet po wykonaniu ostatniej misji, gracz jest w stanie nadal odkrywać dalszy świat M.E.A.T.-a, jak i walczyć z przeciwnościami, jakie owe uniwersum postawi na jego drodze.
 
Autorzy: Trippin Bears
 
Strona na wspieram.to

Screeny: 




Trailer:
 

Super, to cieszy i inspiruje, że w Game Makerze można zrobić takie zarąbiste gierki  Powodzenia, obyście mogli rozwinąć skrzydła i żyć z robienia gier!

Tytuł: M.E.A.T.
 
Gatunek: RPG, cRPG
 
Opis: 

M.E.A.T. w telegraficznym skrócie
Jest to gra RPG single player, stylizowana na klasyki gatunku z lat ’90. XX wieku, wykonana w rzucie 2D i grafice Pixel Art. Przed graczem stoi zadanie, w formie kampanii jednoosobowej, rozwikłania zagadki stanowiącej główną linię fabularną i pokonanie najważniejszego antagonisty, tj. nadrzędnego bossa. 

Gracz w trakcie rozgrywki rozwija swoją postać na wielu płaszczyznach typowych dla gatunku RPG. Postępy w rozwoju postaci opierają się na czasie poświęconym treningom i walce przeciwko AI. Poza działaniami związanymi z głównym wątkiem (opartymi na decyzjach skutkujących określonym rozwojem rozgrywki i tym samym dostępnością zadań), istnieje szereg misji pobocznych. 
Gra posiada otwarte zakończenie – nawet po wykonaniu ostatniej misji, gracz jest w stanie nadal odkrywać dalszy świat M.E.A.T.-a, jak i walczyć z przeciwnościami, jakie owe uniwersum postawi na jego drodze.
 
Autorzy: Trippin Bears
 
Strona na wspieram.to

Screeny: 




Trailer:
 

Wygląda bardzo ciekawie, uzbieraliście już ponad 40 000 , spokojnie przebijecie 80 000 ! Gratuluję! Z ciekawości, czy gra jest tworzona w GMS 1.4 czy w GMS 2? 

od dwóch lat poruszam się tylko eksploratorem plików

@LolikZabójca2
 
Dziwię się, że Gnyskowi i spółce chce się z Tobą jeszcze pisać. Po tym co piszesz ewidentnie widać, że masz bardzo małe doświadczenie w ecommerce i mimo tego co Ci piszą rozmówcy, starasz się z nimi dyskutować o rzeczach, o których nie masz pojęcia ze względu na właśnie brak należytego doświadczenia. Nie chcę Cię urazić, no ale nie jesteś partnerem do rozmowy z nimi na takie tematy, skoro i tak wiesz swoje. To ja nie robię w ecommerce (bardziej duże systemy specjalistyczne, niesprzedażowe) a mam większą wiedzę na ten temat od Ciebie i mogę jedynie potwierdzić to co pisze reszta. Nawet nie zdajesz sobie sprawy z tego, że zahaczasz tylko o wierzchołek góry lodowej. Nie znasz realnych case'ów, konsekwencji spieprzenia czegokolwiek w tym zakresie. Śmiesznie się czyta tę całą dyskusję.

Zdecydowanie problem leży w twojej konfiguracji sprzętowej-systemowej. Biorąc pod uwagę jak działa GM, ten efekt "mrugania" jest niezależny od tego, w jaki sposób masz zaprogramowane draw.
Fakt, że masz pustą listę "Target" oraz inne problemy z samym IDE, świadczy o tym, że jest coś nie tak z instalacją GMS lub uprawnieniami. Debugowanie tego problemu jest praktycznie niemożliwe, dlatego zacząłbym od reinstalacji GMS (ale dokładnie usuń, z %AppData% też).

https://help.yoyogames.com/hc/en-us/articles/216753708-How-to-perform-a-fresh-install-of-GM-S-1-4

Poza tym rozważyłbym migrację na 2.0, wiesz z 1.4 będzie już tylko gorzej.

Oczywiście, że można
image_speed = ileś tam  

Jaka świnia taki schab, jakie życie taki rap. To jest piękne. 

Wiesz co się liczy? Świeży piasek w piaskownicy.
Bez dźwięku* teledysk jest bardzo przyjemny w odbiorze i wygląda ciekawie:)
*krytyka wynika jedynie z mojej całkowitej nietolerancji do "gatunku muzycznego" jakim jest rap

#nocna
Coś tam robię i w między czasie postanowiłem zrobić teledysk dla kumpla  Have fun  

Kończymy prace nad nową wersją, w tym na HTML5.

Nie ma najlepszego wyboru, są różne frameworki, a każdy z frameworków inaczej działa i służy do czegoś innego. Jakby nie patrzeć, to Android i iOS też mają swoje "frameworki" ale nie są multiplatformowe.

Wybierz taki framework, w którym najbardziej będzie Ci odpowiadał stack technologiczny, który znasz/lubisz i spełnia wymagania co do Twojego projektu. Może to być PhoneGap/Cordova + Ionic, NativeScript, Xamarin są tymi popularniejszymi.

Pamiętaj, że jak wybierzesz stack PhoneGap/Cordova/Ionic/NativeScript, to żeby zrobić coś bardziej rozbudowanego, to musisz i tak znać budowę obu platform, a nawet pisać pod nie rozszerzenia w Java i Objective-C.
 
PS. To, że wybierzesz stack PhoneGap/Cordova/Ionic/NativeScript nie znaczy wcale, że będzie łatwiej. Jak znasz JS, czy TS byle jak, to efekt będzie taki sam jakbyś miał usiąść do Xamarina czy pisał od razu na Androida w Javie czy iOSa w Objective-C.

Edit: NativeScript działa trochę inaczej, on binduje API Androida i iOSa do JavaScriptu, ale i tak żeby napisać rozszerzenie, trzeba je pisać też pod daną platformę, tyle, że w JS/TSie.

Co jak co, ale importowanie z GM 1.4 do GMS 2.X działa naprawdę spoko. Ja importowałem Almorę ( 30 tyś linii kodu ) i w sumie wszystko działało od razu - bez błędów. Oczywiście spędziłem ponad 2 miesiące na poprawianie funkcji na nowe + przebudowanie świata na system warstw, ale teraz jest pięknie

Zawsze znajdą się jednak Janusze biznesu żerujący na młodych nieobytych programistach.
 
No i ja programuje w PHP bo lubię

mi od dobrych kilku lat zawsze brakuje około 2 miesiące do osiągnięcia sukcesu w gamedevie xD
 
także już niedługo 

Nie poprzestawaj na tym, dojedź go jeszcze mocniej typeczka

Nie wiem czy występował we wcześniejszych wersjach, odkryłem to niedawno xD Ale też nie wiadomo, czy ja jakiegoś błędu tam nie popełniam, dlatego wrzucam ten przykład na forum.
Ogólnie to można powiedzieć, że GameMaker jest już na tyle legacy, że jest/musi być stabilny i nie ma się czym przejmować .
No i przypadek dotyczy korzystania z json_decode, a nie z korzystania ze struktur danych samych w sobie. Tak jak pisałem wcześniej, rozwiązanie jest takie, że albo sobie implementujemy własny parser JSONa, albo korzystamy z TJSON z marketplace.
Tak jak Gnysek pisał - lepiej jest robić grę i nie dokładać sobie nadmiarowej pracy. Wiadomo, warto też częściowo trzymać się mnemoniki SOLID i ogólnych zasad Clean Code - wtedy, w dużym uproszczeniu, jak natrafisz na jakiś mega duży problem to rozwiążesz go poprzez dodanie kodu, a nie modyfikowanie starego. Nie ma też co się przejmować wyciekami pamięci i tego typu sprawami, jeżeli np. jeszcze nie mamy opracowanego minimal viable product, tak przynajmniej uważam :). 

Jeżeli robisz małą, prostą albo przede wszystkim pierwszą grę to śmiało, twórz roomy, nie przejmuj się wydajnością za wcześnie bo najważniejsze jest to, żeby coś skończyć, nauczyć się. Ja na przykład jeszcze nic nie skończyłem, a zdecydowanie za długo siędzę w GMie xD. Pamiętaj, że sam fakt, że coś jest w pamięci nie wpływa na wydajność. Za wydajność odpowiada to, ile z tych danych musi być przetwarzane w ciągu jednego stepa. Czyli posiadanie wszystkich roomów w pamięci nie jest złe, bo GM za Ciebie odpala jeden i tylko jeden room i tylko w ramach tego jednego odbywa się cała zabawa. Oczywiście zapomnij o checkboxie persistence, bo są przykazania i należy ich przestrzegać: https://www.youtube.com/watch?v=G1WxKEk6Wrw

Ale jeżeli robisz coś już dłużej, projekt jest większy, room so big, much data, to oczywiście, że powinny być wczytywane z pliku. Ale nie tylko ze względu na RAM, są większe problemy, które trzeba rozwiązać, oto niektóre z nich:
 - Wykluczenie GMowego edytora. Fajnie, że ten w GMS:2 jest używalny, ale Tiled dalej jest lepszy, popularniejszy, większe wsparcie, jest na githubie, więc można forkować). Przykład z życia wzięty: w definicji pędzla jedna krawędź może mieć tylko jeden kafelek. Nie można przypisać kilku kafelek do jednej krawędzi (wtedy w trakcie rysowania pędzlem jest losowany któryś z nich - zabieg mający na celu urozmaicenie kafelkowej mapy). Natomiast sytuacja w Tiled wygląda następująco: można, jak najbardziej, jeszcze jak, jest możliwe. Oczywiście możesz liczyć na to, że edytor GMS:2 ciągle będzie rozwijany i będą dodawane nowe funkcje, ale to nie zmienia faktu, że w tym samym miejscu, gdzie masz kod będziesz mieć edytor map. A może się zdarzyć tak, że będziesz chciał, żeby mapy budował Ci ktoś, kto w ogóle nie ma nic wspólnego z programowaniem - lepiej żeby miał darmowe Tiled, czy kupował licencje na GameMakera? Albo będziesz chciał napisać customowy edytor w dowolnej technologii (może być nawet GM), wtedy na pewno potrzebujesz serializacji i deserializacji mapy.
 - Dojdziesz do momentu, gdzie trzeba będzie zrobić zapis i wczytywanie stanu mapy/gry. Wtedy najwygodniej mieć już zdefiniowaną np Entity World, które pozwala się serializować i deserializować do JSONa, przechowuje dane o warstwach, kafelkach, listę instancji i ich parametry. Wtedy taki save i load możemy ładnie zaprogramować przy użyciu odpowiednich wzorców obiektowego progamowania i nie powstaje nam spaghetti. Problem jest tylko jeden i jego rozwiązanie nazywa się TJSON i kosztuje 3.99 USD. Korzystanie z json_encode i json_decode nie jest dobrym pomysłem w przypadku, gdy mamy zagnieżdżone struktury. Jest to problem, ponieważ w aktualnej wersji występuje bug związany ze zwalnianiem pamięci: mianowicie pomimo ręcznego zwalniania tych zagnieżdżonych struktur pamięć nie jest zwalniana, przez co mamy grożny memory leak. Dlatego należy nie wymyślać koła na nowo tylko skorzystać z TJSON dostępnego w marketplace. Zastosowali tam taki myk, że wszystko jest na tablicach, a tablice są automatycznie sprzątane przez GMa, przyjeżdża garbage collector i sprząta.
 - Nowy GM jest wydajny ale sam z siebie nie pozwala na duże otwarte światy - mam przez to na myśli, że nie posiada zaimplementowanych gotowych mechanizmów do korzystania z otwartych światów. Trzeba sobie na własną rękę zrobić system chunków, object pooling itd. Nie chcę siać dezinformacji, ale długo był niezły przypał z instance id: mianowicie nie można było zaalokować więcej niż 100000 instancji, bo potem następował overflow i nowo tworzona instancja miała wtedy id takie samo, jak taka, która już powstała. Dlaczego mówię że przypał? Tak jak Pan Gnysek powiedział: RAM nie stanowi problemu. Możemy na rozpoczęciu gry alokować sobie pamięć na wszystkie obiekty, świat podzielić na chunki (ds_grid), do każdego grida przypisać listę (ds_list) instancji, w których się znajdują i w zależności gdzie jest kamera to aktywować obiekty z danej listy, i dezaktywować stare. 
Ale nie chcę siać dezinformacji, bo po pierwsze dokumentacja nie mówi o tym jak działa instance ID, dlaczego od 100001 zaczyna, czy to Long, Integer, jak wygląda sytuacja z GC: czy po zniszczeniu instancji dane id wraca do puli, czy po prostu ta wartość jest inkrementowana aż nastąpi overflow. Z jednej strony mamy ten wątek i ten post, a z drugiej strony robiłem ostatnio taki test i udało mi się bez nadpisywania i większych problemów, stworzyć instancje o id 200000 i wyższym. Poza tym trzeba wziąć pod uwagę, że najprawdopodobniej (tutaj powołuję się na dane pochodzące z Instytutu danych z d**y) YoYoGames najwięcej zysku czerpie z sektora edukacji, więc nie będą się skupiać na tym, żeby z GMa zrobić Godota, tylko żeby móc sprzedawać w szkołach/na uczelniach ich produkt bo "mamy tutoriale", "spełniamy standardy", itd.

Co do ilości RAMu i tego co pisał Gnysek: W poprzednim linku odnośnie limitów instance id jest poruszona kwestia RAMu i również samą kwestię tego ile GM może zająć na Windowsie najlepiej wytłumaczyć poprzez odniesie się do tego linku. Nie mam teraz GMa pod ręką, ale z tego co wiem, to na Windowsie wynikiem kompilacji i uruchomienia gry jest 32 bitowy proces, więc mamy albo max 2 GB albo max 4 GB. Mi osobiście udało się dobić do 4 GB i wtedy następował crash. Pewnie YoYoCompiler może skompilować exe do 64 bitów, ale nie jest istotne to czy mamy do czynienia z limitem 2 GB, czy 4 GB - ważne jest to, że limity te zależą przede wszystkim od platformy, a np. idąc na platformy o urządzeniach z mniejszą wydajnością (np. Android)  to nie możemy liczyć na to, że te limity będą większe. Dlatego dobrym założenie jest takie, żeby nie przekraczać 1 GB i dbać o nie powstawanie wycieków pamięci przy korzystaniu z list, map, siatek, kolejek, stosów i co tam jeszcze GM ma wbudowane. Tak jak Pan Gnysek wspomina, nawet 400 MB nie będzie problemem.

Chyba trochę się offtop zrobił, więc wrzucam taktycznie Otisa na podsumowanie wypowiedzi:
https://www.youtube.com/watch?v=R__buemC5Nc
 

Faktycznie, kłania się czytanie ze zrozumieniem . Co nie zmienia faktu, że na pewno jest limit odnośnie ID i możliwych do zaalokowania instancji. Teraz rodzi się pytanie co pierwsze odpadnie: id overflow czy out of memory. Spróbuję odpowiedzieć na to pytanie:
Jeżeli GameMaker trzyma ID w 32 bit integer (zakres wynosi od -2 147 483 648 do 2 147 483 647), zaczyna od wartości 100001, to ten zakres pozwala na zaalokowanie 2 147 383 646 liczb (od 100001 do 2 147 483 647). Opisałem wcześniej że możemy skorzystać z maksymalnie 4 GB RAMu. 4 GB to 4 294 967 296 B. Z samego porównania rzędów tych liczb widać, że wtedy można zaalokować wszystkie instancje z tego zakresu, jeśli każda z nich ważyłaby 2 bajty. Na na pewno ważą zdecydowanie więcej. Biorąc pod uwagę wszystkie wbudowane zmienne to wartość ta może dochodzić do 1 KB? Korzystając z porównania na bazie rzędów to wynika z tego, że gdzieś po zaalokowaniu 2 milionów instancji powinno zacząć brakować pamięci.
Czyli czysto teoretycznie wygląda na to, że limity GameMakera są w miare rozsądne, przykład: 
Jeżeli weźmiemy świat o wielkości 32768 x 32768 px, podzielimy go na kwadraty o wielkości 512x512 i w każdym tym kwadracie stworzymy po 50 instancji (drzewek np) to będziemy potrzebowali zaalokować łącznie 204800 instancji. 
Tutaj się rodzi jeszcze kwestia czy warto na drzewka marnować instancję, ale to już temat na zupełnie inną bajkę ( ͡° ͜ʖ ͡°). 
A kwestię tego, czy ID raz użyte wraca do puli, czy wartość ta jest inkrementowana - trzeba przetestować samodzielnie :).
Morał: keep calm & make games.

Jeżeli robisz małą, prostą albo przede wszystkim pierwszą grę to śmiało, twórz roomy, nie przejmuj się wydajnością za wcześnie bo najważniejsze jest to, żeby coś skończyć, nauczyć się. Ja na przykład jeszcze nic nie skończyłem, a zdecydowanie za długo siędzę w GMie xD. Pamiętaj, że sam fakt, że coś jest w pamięci nie wpływa na wydajność. Za wydajność odpowiada to, ile z tych danych musi być przetwarzane w ciągu jednego stepa. Czyli posiadanie wszystkich roomów w pamięci nie jest złe, bo GM za Ciebie odpala jeden i tylko jeden room i tylko w ramach tego jednego odbywa się cała zabawa. Oczywiście zapomnij o checkboxie persistence, bo są przykazania i należy ich przestrzegać: https://www.youtube.com/watch?v=G1WxKEk6Wrw

Ale jeżeli robisz coś już dłużej, projekt jest większy, room so big, much data, to oczywiście, że powinny być wczytywane z pliku. Ale nie tylko ze względu na RAM, są większe problemy, które trzeba rozwiązać, oto niektóre z nich:
 - Wykluczenie GMowego edytora. Fajnie, że ten w GMS:2 jest używalny, ale Tiled dalej jest lepszy, popularniejszy, większe wsparcie, jest na githubie, więc można forkować). Przykład z życia wzięty: w definicji pędzla jedna krawędź może mieć tylko jeden kafelek. Nie można przypisać kilku kafelek do jednej krawędzi (wtedy w trakcie rysowania pędzlem jest losowany któryś z nich - zabieg mający na celu urozmaicenie kafelkowej mapy). Natomiast sytuacja w Tiled wygląda następująco: można, jak najbardziej, jeszcze jak, jest możliwe. Oczywiście możesz liczyć na to, że edytor GMS:2 ciągle będzie rozwijany i będą dodawane nowe funkcje, ale to nie zmienia faktu, że w tym samym miejscu, gdzie masz kod będziesz mieć edytor map. A może się zdarzyć tak, że będziesz chciał, żeby mapy budował Ci ktoś, kto w ogóle nie ma nic wspólnego z programowaniem - lepiej żeby miał darmowe Tiled, czy kupował licencje na GameMakera? Albo będziesz chciał napisać customowy edytor w dowolnej technologii (może być nawet GM), wtedy na pewno potrzebujesz serializacji i deserializacji mapy.
 - Dojdziesz do momentu, gdzie trzeba będzie zrobić zapis i wczytywanie stanu mapy/gry. Wtedy najwygodniej mieć już zdefiniowaną np Entity World, które pozwala się serializować i deserializować do JSONa, przechowuje dane o warstwach, kafelkach, listę instancji i ich parametry. Wtedy taki save i load możemy ładnie zaprogramować przy użyciu odpowiednich wzorców obiektowego progamowania i nie powstaje nam spaghetti. Problem jest tylko jeden i jego rozwiązanie nazywa się TJSON i kosztuje 3.99 USD. Korzystanie z json_encode i json_decode nie jest dobrym pomysłem w przypadku, gdy mamy zagnieżdżone struktury. Jest to problem, ponieważ w aktualnej wersji występuje bug związany ze zwalnianiem pamięci: mianowicie pomimo ręcznego zwalniania tych zagnieżdżonych struktur pamięć nie jest zwalniana, przez co mamy grożny memory leak. Dlatego należy nie wymyślać koła na nowo tylko skorzystać z TJSON dostępnego w marketplace. Zastosowali tam taki myk, że wszystko jest na tablicach, a tablice są automatycznie sprzątane przez GMa, przyjeżdża garbage collector i sprząta.
 - Nowy GM jest wydajny ale sam z siebie nie pozwala na duże otwarte światy - mam przez to na myśli, że nie posiada zaimplementowanych gotowych mechanizmów do korzystania z otwartych światów. Trzeba sobie na własną rękę zrobić system chunków, object pooling itd. Nie chcę siać dezinformacji, ale długo był niezły przypał z instance id: mianowicie nie można było zaalokować więcej niż 100000 instancji, bo potem następował overflow i nowo tworzona instancja miała wtedy id takie samo, jak taka, która już powstała. Dlaczego mówię że przypał? Tak jak Pan Gnysek powiedział: RAM nie stanowi problemu. Możemy na rozpoczęciu gry alokować sobie pamięć na wszystkie obiekty, świat podzielić na chunki (ds_grid), do każdego grida przypisać listę (ds_list) instancji, w których się znajdują i w zależności gdzie jest kamera to aktywować obiekty z danej listy, i dezaktywować stare. 
Ale nie chcę siać dezinformacji, bo po pierwsze dokumentacja nie mówi o tym jak działa instance ID, dlaczego od 100001 zaczyna, czy to Long, Integer, jak wygląda sytuacja z GC: czy po zniszczeniu instancji dane id wraca do puli, czy po prostu ta wartość jest inkrementowana aż nastąpi overflow. Z jednej strony mamy ten wątek i ten post, a z drugiej strony robiłem ostatnio taki test i udało mi się bez nadpisywania i większych problemów, stworzyć instancje o id 200000 i wyższym. Poza tym trzeba wziąć pod uwagę, że najprawdopodobniej (tutaj powołuję się na dane pochodzące z Instytutu danych z d**y) YoYoGames najwięcej zysku czerpie z sektora edukacji, więc nie będą się skupiać na tym, żeby z GMa zrobić Godota, tylko żeby móc sprzedawać w szkołach/na uczelniach ich produkt bo "mamy tutoriale", "spełniamy standardy", itd.

Co do ilości RAMu i tego co pisał Gnysek: W poprzednim linku odnośnie limitów instance id jest poruszona kwestia RAMu i również samą kwestię tego ile GM może zająć na Windowsie najlepiej wytłumaczyć poprzez odniesie się do tego linku. Nie mam teraz GMa pod ręką, ale z tego co wiem, to na Windowsie wynikiem kompilacji i uruchomienia gry jest 32 bitowy proces, więc mamy albo max 2 GB albo max 4 GB. Mi osobiście udało się dobić do 4 GB i wtedy następował crash. Pewnie YoYoCompiler może skompilować exe do 64 bitów, ale nie jest istotne to czy mamy do czynienia z limitem 2 GB, czy 4 GB - ważne jest to, że limity te zależą przede wszystkim od platformy, a np. idąc na platformy o urządzeniach z mniejszą wydajnością (np. Android)  to nie możemy liczyć na to, że te limity będą większe. Dlatego dobrym założenie jest takie, żeby nie przekraczać 1 GB i dbać o nie powstawanie wycieków pamięci przy korzystaniu z list, map, siatek, kolejek, stosów i co tam jeszcze GM ma wbudowane. Tak jak Pan Gnysek wspomina, nawet 400 MB nie będzie problemem.

Chyba trochę się offtop zrobił, więc wrzucam taktycznie Otisa na podsumowanie wypowiedzi:
https://www.youtube.com/watch?v=R__buemC5Nc