How well does GameMaker 2 perform when Games get big?

J

JulianS

Guest
I am asking, especially wondering if there are any Resource Limitations, like the overall amount of Scripts, Sprites, Objects, etc. that can be created, if there are limits to Instances in a room or room size in general, or if any of you have any experiences, working on big Projects with lots of Resources.
 

Mert

Member
There's no limits, and this is irrelevant. By this logic, we wouldn't be able to play GTA 5. I don't think NASA Supercomputers would run it neither. What matters is balancing the load. This is the general, universal rule for any sector of programming or game development.

You can have a thousands object, but only 100 of them is present.
You can have 100 sprites, yet you load only 10 of them. Once you're in another stage, you unload that 10 and load another 10.
 
It reminds me of someone walking into a sports store and asking "Will this football let me score a touchdown in the Superbowl?"...Uhhhh, sure, but it totally depends on the person and not the ball.
 

JeffJ

Member
To me it sounds like, at least part of the question, is just as concerned about the IDE side of things - as in, how does the IDE handle a massive project with thousands of resources when compiling, saving and loading - and that is actually a very relevant question.

I can say from personal experience that GMS2 is a massive improvement in that particular area over GMS1 - a project with around 700 sprites, 500 objects and 1000 scripts would sometimes outright crash when trying to load or save, but GMS2 handles that size of projects pretty good. Loading a big project can take a while, but it's usually pretty smooth once that's done. I've talked to people who's worked on projects with upwards of 20.000 sprites/objects and still having the IDE handle it without issue.
The worst experience I've personally had so far with GMS2 in this regard is when you have a big room with lots of different layers, especially asset layers where each asset layer has lots of sprites on it, GMS2 can sometime struggle looping through all that internally, like when you're selecting all assets on a layer, or when you're simply adding a new layer or deleting an existing one. But it's not too bad, and you have to have quite a large amount before this happens.

One thing to keep in mind is that, currently, there is a theoretical limit in the case of objects, which is 100.000, because instance IDs starts at 100001 - this means that, if you had more than 100.000 object resources in the ID, the indexes (internally) would start to overlap, causing unintended behavior because your code wouldn't know if you were referring to an instance or an object.

On the other hand, if you have a need for more than 100.000 objects, I have a paragraph or two on why you're wrong.

TL;DR - as far as the IDE handling huge amounts of resources internally, you should be fine.
 
Honestly, I think people just get sick of the question. I know I am. It gets asked at least once a week by someone. Usually more than once. And if you hang around on the discord and the reddit, it's way more than that.

Sorry for trying to have a little fun with it ;P
Don’t apologize to me. Apologize to Julian for crushing his NFL dreams! )’:
 
@RefresherTowel
I get that you might be annoyed by the regularity of how much it's asked, and also maybe by what you consider to be (how can I put this kindly towards the OP) a little..foolish.

But.....

They haven't used the engine, and therefore don't know, and therefore.....need to ask. You didn't say anything rude, but I know if I was asking the question I'd prefer an answer that actually, uh, answered it. It's the kind of response that might put people off investigating the engine / community further, and could be a bit more considerate / welcoming. If it annoys you so much, then why even answer it in the first place?

@Niels
I liked your response (obviously), and I like GMS, but I have to say that if people have "pushed it to it's limits" then...it is limited, very limited. I can't think of a single GMS game that was impressive compared to say "Ori and the blind forest", and that's either the limitations of the engine, or the fact that every developer gimps their games to run on potatoes so everyone can play them. Whichever way I consider it there has been no game that wowed me on an artistic level from GMS (Deaths Gambit comes closest for me, but is still rather "pixelly"), no matter how "great" it was technically for the engine itself.
 
To me it sounds like, at least part of the question, is just as concerned about the IDE side of things - as in, how does the IDE handle a massive project with thousands of resources when compiling, saving and loading - and that is actually a very relevant question.

I can say from personal experience that GMS2 is a massive improvement in that particular area over GMS1 - a project with around 700 sprites, 500 objects and 1000 scripts would sometimes outright crash when trying to load or save, but GMS2 handles that size of projects pretty good. Loading a big project can take a while, but it's usually pretty smooth once that's done. I've talked to people who's worked on projects with upwards of 20.000 sprites/objects and still having the IDE handle it without issue.
The worst experience I've personally had so far with GMS2 in this regard is when you have a big room with lots of different layers, especially asset layers where each asset layer has lots of sprites on it, GMS2 can sometime struggle looping through all that internally, like when you're selecting all assets on a layer, or when you're simply adding a new layer or deleting an existing one. But it's not too bad, and you have to have quite a large amount before this happens.

One thing to keep in mind is that, currently, there is a theoretical limit in the case of objects, which is 100.000, because instance IDs starts at 100001 - this means that, if you had more than 100.000 object resources in the ID, the indexes (internally) would start to overlap, causing unintended behavior because your code wouldn't know if you were referring to an instance or an object.

On the other hand, if you have a need for more than 100.000 objects, I have a paragraph or two on why you're wrong.

TL;DR - as far as the IDE handling huge amounts of resources internally, you should be fine.
Only relevant answer to the topic, but a good one. Older version of GM really was not that nice for working on very big projects. After a point, you'd have to set up separate folders and do you're own custom resource loading. I'm not that familiar with GMS2 but it sounds like it's a bit better.
just curious, what is your pc specs?
 

JeffJ

Member
It is a lot better in that particular regard (I have many complaints with its IDE and other inherent flaws, but those are irrelevant to this discussion), so if you're being held back with a huge project, it might be worth it for you to check it out.

Specs:
Windows 10 Pro
Intel i7-6700K 4GHz
64GB RAM
2 x GTX980Ti
And working off a SATA6 SSD.
 

Niels

Member
@RefresherTowel
I get that you might be annoyed by the regularity of how much it's asked, and also maybe by what you consider to be (how can I put this kindly towards the OP) a little..foolish.

But.....

They haven't used the engine, and therefore don't know, and therefore.....need to ask. You didn't say anything rude, but I know if I was asking the question I'd prefer an answer that actually, uh, answered it. It's the kind of response that might put people off investigating the engine / community further, and could be a bit more considerate / welcoming. If it annoys you so much, then why even answer it in the first place?

@Niels
I liked your response (obviously), and I like GMS, but I have to say that if people have "pushed it to it's limits" then...it is limited, very limited. I can't think of a single GMS game that was impressive compared to say "Ori and the blind forest", and that's either the limitations of the engine, or the fact that every developer gimps their games to run on potatoes so everyone can play them. Whichever way I consider it there has been no game that wowed me on an artistic level from GMS (Deaths Gambit comes closest for me, but is still rather "pixelly"), no matter how "great" it was technically for the engine itself.
I'd say that Katana zero is pushing gamemakee pretty far, and tbh gamemaker just really isn't a powerhouse engine.

It's fine for most purposes, but it you want to make the next Ori, you better make it in the engine that Ori was made.
 

GMWolf

aka fel666
I'd say that Katana zero is pushing gamemakee pretty far, and tbh gamemaker just really isn't a powerhouse engine.

It's fine for most purposes, but it you want to make the next Ori, you better make it in the engine that Ori was made.
Nah you could quite easily get ori like graphics in GM. It's down to content authoring. You need good artists.
The other think is the asset resolution. That can be a bit more challenging but it's feasible. If you start animating with shaders rather than keyframes you can keep memory in check.
@kupo15 has experience with high Res animated graphics in GM.

Graphics wise, GM is fairly well balanced for games that run on opengl 3 level hardware or mobile platforms. Which is what people expect indie games to run on these days.
Of course to get the most out of it you have to be a bit of an engineer and understand the graphics pipeline. But that's true of any engine.

Graphics wise, GM does offer the tools to achieve most of what would be reasonable in a cross platform 2D title.
 
Nah you could quite easily get ori like graphics in GM. It's down to content authoring. You need good artists.
I have never seen a GMS game which even vaguely compares graphically to Ori in any way, shape or form. Must be a lot of crappy artists using GMS.

After umpteen years of the engine being on the market hopefully kupo15 will finally release a game that actually looks like it's running on bog standard modern PC hardware, rather than a 20+ year old SNES.
 

Niels

Member
You have to be a shader magician to get Ori graphics in gm:studio and hire someone that can write a lot of post-process plugins...
That said there is only 1 Ori made in Unity too:)
Think hollow knight graphics are a more realistic bar for 2d games
 

GMWolf

aka fel666
I have never seen a GMS game which even vaguely compares graphically to Ori in any way, shape or form. Must be a lot of crappy artists using GMS.
That's one way to put it...
More like if GM users are often one man teams.
To get ori like graphics you need a good artist, effects programmer, graphics engineer, etc.
If you look at ori, it had quite a few people working on it!

Once an engine gives you access to shaders like GM does, it really comes down to how well you can make use of the GPU.
Yeah we don't have access to all features, but we have what is sensible in 2D cross platform development.

That being said, we could do with a couple more features to help with performance:
I'm thinking DXT compression, more surface types, and such.
 

FrostyCat

Redemption Seeker
I have never seen a GMS game which even vaguely compares graphically to Ori in any way, shape or form. Must be a lot of crappy artists using GMS.

After umpteen years of the engine being on the market hopefully kupo15 will finally release a game that actually looks like it's running on bog standard modern PC hardware, rather than a 20+ year old SNES.
Absence of evidence is not evidence of absence. Just because you haven't seen a game that "compares graphically to Ori", it doesn't mean there won't be one in the future by someone else who isn't dissuaded by the lack of prior art. That's where the first of everything comes from.

In my opinion, the main reason that most GM games look like one-man productions is because GM is designed in a way that impedes collaborative use. Here are the 3 biggest stumbling blocks:
  • A file format that is hostile to source control, and has been that way for 2 years
  • A lack of IDE and build extensibility that allows asset interchange with non-coding collaborators (i.e. no IDE plugin documentation)
  • Insufficient runner extensibility for extending functionality on graphics, audio, non-built-in formats and other system-level resources
If GM is to achieve its full potential and increase the proportion of products that don't all look like one-man productions, it must first address its own anti-collaborative tendencies before anything else.
 

FrostyCat

Redemption Seeker
Wait, GMS2 doesn't play nice with source control? How? I had thought YYG's had done something around this.
The only source control use case that GMS 2 can tolerate is the single-user, perfectly linear development flow. Put multiple users and/or multiple branches into the mix, and the whole thing comes apart. That is not my sense of playing nicely with source control. If it is, then so are legacy versions of GM.

For the record, here is a brief sampler of complaints regarding the file format's hostility to source control:
And to cap it off, my Mantis ticket for this issue (which has languished for more than a year): https://bugs.yoyogames.com/view.php?id=29196

According to the ticket, YoYo knows it's an issue, but won't be doing anything about it until 2.3.
 
The only source control use case that GMS 2 can tolerate is the single-user, perfectly linear development flow. Put multiple users and/or multiple branches into the mix, and the whole thing comes apart. That is not my sense of playing nicely with source control. If it is, then so are legacy versions of GM.

For the record, here is a brief sampler of complaints regarding the file format's hostility to source control:
And to cap it off, my Mantis ticket for this issue (which has languished for more than a year): https://bugs.yoyogames.com/view.php?id=29196

According to the ticket, YoYo knows it's an issue, but won't be doing anything about it until 2.3.
Well, that's no good, to put it mildly. This should be the second accepted answer for the topic I'm probably preaching to the choir Frosty, but for the OP, Source control is basically a must for any project that is considered truly large from an engineering perspective. Otherwise every change and addition by different team members becomes a really problematic 'merge' experience.

How do people currently work around this? They save their changes separately, then copy and paste them back into the project after each merge?
 

curato

Member
How do people currently work around this? They save their changes separately, then copy and paste them back into the project after each merge?
Just use the GIT desktop app. Nothing wrong with GIT as such, but the integration with GMS2 is a real pain.
 

FrostyCat

Redemption Seeker
Well, that's no good, to put it mildly. This should be the second accepted answer for the topic I'm probably preaching to the choir Frosty, but for the OP, Source control is basically a must for any project that is considered truly large from an engineering perspective. Otherwise every change and addition by different team members becomes a really problematic 'merge' experience.

How do people currently work around this? They save their changes separately, then copy and paste them back into the project after each merge?
Merging is always a problematic experience wherever you go. Sometimes it goes cleanly, other times it won't. The percentage of these that end in messy manual resolution depends on the file format, the chosen workflow and general development practices. While we can hope there is a workflow that can help work around the current format's limitations (the "single user adds resources" workflow I hypothesized may be one of them), in the end it's YoYo's fault that complaints about source control compatibility were not taken seriously early on.

As for how teams work around it, the rough statistics from what I can observe are rather troubling.

Of the topics I've responded to where a team of developers is having issues with Git on GMS 2, most of them aren't around anymore. In other words, their way of "working around it" was to jump ship to another engine that placed more weight on working for professionals proficient in source control, and less weight on glitzing up the workspace. They decided that rebooting their project was less of a hassle than the long-term cost of constant conflicts.

For others, their way of working around it is to minimize the number of developers touching GMS 2 at a time, often to just one lead coder doing it all. The rest of the team are basically artists and musicians who don't really get to touch GMS 2 at all. This is maladaptive on several levels, yet I understand that their hand is forced by the way source control currently works. It clearly explains why the technical sophistication of GM projects remained relatively low this whole time. It can't get beyond the capacity of one or two full-time coders or level designers because the file format just can't work with more.

A third way is by passing around local asset packages (made possible by the 2.2.2 update) and then having a single integration developer add it to the main project. I'm not sure how many teams actually do this, but there should be some given the petitions for this feature before 2.2.2. It's an informal version of the "commander and lieutenants" workflow in Git, where everyone has read access but only the commander has write access. This reduces the incidence rate of inter-user conflict, but the commander would still have an issue with merge conflicts if he/she branches off master, dev and hotfixes as per standard Git practice. It also requires a lot of prior planning such that each lieutenant's work is sufficiently independent of each other and documented in a way that the commander can readily integrate. This is in complete contradiction with much of the established GML orthodoxy that values high coupling, so I don't really see this method gaining much traction until GML 2020 formalizes more team-friendly means of interfacing.

Just use the GIT desktop app. Nothing wrong with GIT as such, but the integration with GMS2 is a real pain.
Using an external client is no salvation when it's the file format being turned against users. Conflict resolution and even trivial merges are currently almost undoable with any Git client. You just won't notice it if you are a single-branch-single-user production, which YoYo seems to assume.
 
Of the topics I've responded to where a team of developers is having issues with Git on GMS 2, most of them aren't around anymore. In other words, their way of "working around it" was to jump ship to another engine that placed more weight on working for professionals proficient in source control, and less weight on glitzing up the workspace. They decided that rebooting their project was less of a hassle than the long-term cost of constant conflicts.
Yes, this is honestly what I suspected when I saw you mention the lack of effective SCM. GM as a tool has always been geared towards a solo developer. Which is probably the main reason why we don't see too many truly 'big' projects made with GM.

I see from the previous thread (and these posts) you've been campaigning pretty strongly to get this prioritized and fixed. Definitely agree with you, hopefully YYG's get behind this. I'm not liking how long this has been an issue, which hasn't been fixed yet, though. Kinda concerning.

Also, I just realized now you're Geisha from the old GMC. :) I thought the avatar looked familiar.
 

DBenji

Member
Nah you could quite easily get ori like graphics in GM. It's down to content authoring. You need good artists.
The other think is the asset resolution. That can be a bit more challenging but it's feasible. If you start animating with shaders rather than keyframes you can keep memory in check.
@kupo15 has experience with high Res animated graphics in GM.

Graphics wise, GM is fairly well balanced for games that run on opengl 3 level hardware or mobile platforms. Which is what people expect indie games to run on these days.
Of course to get the most out of it you have to be a bit of an engineer and understand the graphics pipeline. But that's true of any engine.

Graphics wise, GM does offer the tools to achieve most of what would be reasonable in a cross platform 2D title.
Correct me if I'm wrong, but if you wanted to get as much out of texture memory performance as a game like Ori you might need the ability to set different texture formats with your texture pages which GMS2 does not currently offer.
Ori sprites use "dynamic chroma key generation" to obtain the alpha for each sprite (similar to film green/blue screen) - meaning there is no alpha channel stored in the texture pages and the background is full red/green/blue (this being to save memory I assume). I also think a lot of games in the past may have used this method but I could be mistaken.

The ability to use different texture formats (i.e. ARGB32, RGB32, RGBFloat, etc) is offered straight out of the box in Unity, but from reading the manual and various posts by Mike, GMS2 does not currently offer any kind of benefit from having a texture page/sprites with no alpha. GMS2 does clip empty (0 alpha) pixels from sprites though.
 

GMWolf

aka fel666
Correct me if I'm wrong, but if you wanted to get as much out of texture memory performance as a game like Ori you might need the ability to set different texture formats with your texture pages which GMS2 does not currently offer.
Ori sprites use "dynamic chroma key generation" to obtain the alpha for each sprite (similar to film green/blue screen) - meaning there is no alpha channel stored in the texture pages and the background is full red/green/blue (this being to save memory I assume). I also think a lot of games in the past may have used this method but I could be mistaken.

The ability to use different texture formats (i.e. ARGB32, RGB32, RGBFloat, etc) is offered straight out of the box in Unity, but from reading the manual and various posts by Mike, GMS2 does not currently offer any kind of benefit from having a texture page/sprites with no alpha. GMS2 does clip empty (0 alpha) pixels from sprites though.
Yes that is true.
You will not get as good performance for sure. But that is not to say that you outright cannot do anything but pixel art in GM.
Untill GM games are developed with larger teams, I don't thing YYG will pander to us engineers, unfortunately.
 

DBenji

Member
Yes that is true.
... I don't thing YYG will pander to us engineers, unfortunately.
Sad but true. They'll most likely look at the percentage of users who do x the most and adjust accordingly - just as Unity abandoned it's support for js back in 2017 because too few projects used it. I don't blame 'em. But I can't help wonder if this constant priority over what the masses are using GMS for as opposed to what the more skilled/serious individuals/teams could be using GMS for if they would give it a chance is doing more harm than good.

For instance, Frosty pointed out that they have neglected to develop further support for source control - probably based off of percentages. But this means - as Frosty said - larger teams will shy away from GMS2 and pick a different engine -> reducing the chance we will see games with quality on par with Ori, Hollow Knight, Rayman Legends, etc...

Not a business/marketing expert, but I can only imagine how much a game on par with one of the aforementioned could do for YYG in terms of sales (not to mention further improving GM's reputation in the more general gamedev community) - yet they continuously hesitate to make certain moves towards this - stagnating the possibility for it to occur.

The biggest decisions being (IMO) not to further develop source control and never making nor planning to make (nowhere on the roadmap or foreseeable future) GMLive-coding/instant compile times native in the IDE (which is certainly possible to implement according to YellowAfterLife). Probably has been discussed to death (and some might roll their eyes) but you can't change the fact that that alone is a huge turn away for many pros who do not prefer the old way of doing things if it means wasting precious time and having to endure more stress in the workflow when there are free alternatives without it close by. (I use YellowAfterLife's GMLive extension and can't imagine what I'd do without it and would absolutely recommend it for anyone who wants to get serious with gm, but I learned of it's existence much later than I would have preferred and it still has some bugs and inconveniences which can be a chore to workaround.)
 
Last edited:
Top