W erze, gdy masz 8GB ramu, a Twoja gra ma plik win.dat dołączony do EXE rozmiaru 1-2MB, nie powinieneś się tym martwić. Nawet 400Mb gra nie będzie problemem, bo zasoby to 90%, a reszta kod i levele. Niewiele by to zmieniło.
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
Głos na symulator dla bezdomnych. Jeden z nich przypomina mi użytkownika tego forum, ale nie powiem którego, bo potem są żale, że się nabijam z wyglądu
Tzn. dodanie z prawej strony od newsów bloku "najczęściej czytanie" z np. ostatniego pół roku to żaden problem:
Jak już by były takie "reakcje", to to jest z 20 minut roboty i gotowe.
Natomiast to o czym mówicie, to "hot news", który jest zawsze na górze, ale tak szczerze... czy mamy aż tyle newsów, że coś może zakryć coś innego ? Zazwyczaj wtedy staram się po prostu nie dodawać kolejnego i z nim czekam, chyba nigdy nie było aż dwóch tak ważnych (a wtedy i tak oba są "hot" i by musiały być jeden pod drugim).
Myślę, że całym założeniem reakcji było sprawdzanie co lubicie czytać i czy w ogóle czytacie. Ale to sprawdzam ankietami widac ile osób głosuje.
Panie i Panowie, mam przyjemność gościć Was na 10. Community Awards! W tę okrągłą edycję użytkownicy staną w szranki w następujących kategoriach:
Gra roku
Demo roku
Zapowiedź roku
Artykuł / Tutorial / Silnik roku
Screen / Film / GIF roku
Użytkownik roku
Cytat roku
Zgłaszajcie swoje typy do poszczególnych kategorii do 18.01, g. 23:59.
Powodzenia wszystkim. Community Awards 2018 - start!
Jak chcesz zniszczyć wszystko w promieniu 100px, to nie korzystasz z collision_circle. Collision_circle zwraca informację, czy w kole o danym promieniu zachodzi kolizja z innym podanym obiektem.
1) w gms2 można użyć collision_circle_list
2). pozostałe sposoby
with (obj_potwor) { if (distance_to_point(other.x, other.y) < 100) { instance_destroy(); }}
Tablice GM usuwa automatycznie, gdy znika obiekt/referencja w kodzie. A list nie (ale kiedyś mają to zmienić). Dlatego tablicami nie ma sie co martwić, bo one się kasują z pamięci, a wszystkie ds_xxx trzeba ręcznie.
To też nie do końca prawda, odrzucane są trójkąty podczas renderingu, po vertex shaderze (Vertex Post-Processing). Także żeby zminimalizować draw call'e, które też mają wpływ na wydajność, stosuje się własny clipping. Podejrzewam, że o to chodziło autorowi