Can I make something the size of Stardew Valley in GMS2?

A

Alte

Guest
I want to make a game but I want to make sure the engine I'm using will be able to (eventually) support what I want to make. Is something like SV feasible on GMS2? What I have in mind is similar in style and scope.

If not, are there recommendations for another game engine?
 
  • Wow
Reactions: Mut
Question: Can I do... in GMS2?

Answer: Yes.

Is it going to be hard? Unless you're a genius, yes. Any harder than any other engine? I don't think so, for anything 2D, GMS2 is on-par or better than any other option. It really comes down to preferences. Gamemaker doesn't limit your scope. But if you've never made a game before, you're going to find that making a game like SV is very rarely as easy as you think it is.

For beginners, you should really spend time making small games (by that, I mean like, program Pong to start). Start small and then move up in scope, otherwise you're just going to have a lot of unfinished games.
 
A

Alte

Guest
Question: Can I do... in GMS2?

Answer: Yes.

Is it going to be hard? Unless you're a genius, yes. Any harder than any other engine? I don't think so, for anything 2D, GMS2 is on-par or better than any other option. It really comes down to preferences. Gamemaker doesn't limit your scope. But if you've never made a game before, you're going to find that making a game like SV is very rarely as easy as you think it is.

For beginners, you should really spend time making small games (by that, I mean like, program Pong to start). Start small and then move up in scope, otherwise you're just going to have a lot of unfinished games.
Thank you for the answer and for the advice! I'm keeping my current scope very small and working my way up.
 

Dan1

Member
Spot on with what Cloaked Games said there - enough skill and enough practice and you can do it! :)
 

11clock

Member
I would personally not make anything large in scope in GameMaker. It has been done before (Wuppo, Undertale, Crashlands, etc.), but from my experience largescale projects in GameMaker are very difficult to maintain. My team is still using it but I am currently exploring other options for the future. Godot seems promising but it still has some issues that GameMaker still excels at in comparison.
 

YanBG

Member
I would personally not make anything large in scope in GameMaker. It has been done before (Wuppo, Undertale, Crashlands, etc.), but from my experience largescale projects in GameMaker are very difficult to maintain. My team is still using it but I am currently exploring other options for the future. Godot seems promising but it still has some issues that GameMaker still excels at in comparison.
After mastering GM, why would you go for Godot? For future projects i am thinking about Unity but only because it supports native C# programming.
 

11clock

Member
No structs, no object methods, poor performance (I measured about 500-ish objects to drop below 60 FPS), GML looks messy, the IDE gets really sluggish when your project gets big enough, proper composition is difficult to do in GML as everything has to be an object and you can’t just have simple data containers, lack of proper features that other modern engines have, and so on. Also I find GM’s development slow and YoYo Games seems to not understand what people want, constantly declining feature suggestions because obnoxious workarounds exist. When I suggest something to Godot devs it immediately at least gets considered.

After mastering GM, why would you go for Godot? For future projects i am thinking about Unity but only because it supports native C# programming.
Because it is the only other modern engine I found that has a dedicated 2D pipeline. I tried Unity but making a pixel art game in it is an absolute pain. Godot I got really comfortable with after only 3 days of use. But as said Godot has its own problems that I am waiting for it’s next major release to sort out.
 

Niels

Member
No structs, no object methods, poor performance (I measured about 500-ish objects to drop below 60 FPS), GML looks messy, the IDE gets really sluggish when your project gets big enough, proper composition is difficult to do in GML as everything has to be an object and you can’t just have simple data containers, lack of proper features that other modern engines have, and so on. Also I find GM’s development slow and YoYo Games seems to not understand what people want, constantly declining feature suggestions because obnoxious workarounds exist. When I suggest something to Godot devs it immediately at least gets considered.



Because it is the only other modern engine I found that has a dedicated 2D pipeline. I tried Unity but making a pixel art game in it is an absolute pain. Godot I got really comfortable with after only 3 days of use. But as said Godot has its own problems that I am waiting for it’s next major release to sort out.
Yeah I want to get into Godot next to gm:studio, but it has numerous issues with Godot that make me uncomfortable with it to make bigger games.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Guys, can I remind you that discussion of other game engines should be left to their forums and not the GameMaker ones?

No structs, no object methods, poor performance (I measured about 500-ish objects to drop below 60 FPS), GML looks messy, the IDE gets really sluggish when your project gets big enough, proper composition is difficult to do in GML as everything has to be an object and you can’t just have simple data containers, lack of proper features that other modern engines have, and so on. Also I find GM’s development slow and YoYo Games seems to not understand what people want, constantly declining feature suggestions because obnoxious workarounds exist.
If your framerate drops below 60 with 500 objects you are doing something very, very wrong. My game Skein can have up to 8000 enemies (with AI) in a room all at once (with no instance deactivation) before the framerate drops below 60, and it uses lighting and particles and all sorts of other things on top of the basic instances... The rest of what you say is purely SUBJECTIVE and has no bearing on whether GM is capable or not of doing X thing, which I'll remind you, was the subject of this topic.

Oh, and just because you weren't a part of a discussion, doesn't mean that it didn't happen. All suggestions that reach the YYG devs are carefully considered before being rejected or applied. A number of changes have been made to GML at the request of developers (ask the Hyper Light Drifter guys, for example), so just because your suggestions haven't been implemented, doesn't mean that they weren't considered or that NO user suggestions are implemented. ;)
 

11clock

Member
Guys, can I remind you that discussion of other game engines should be left to their forums and not the GameMaker ones?



If your framerate drops below 60 with 500 objects you are doing something very, very wrong. My game Skein can have up to 8000 enemies (with AI) in a room all at once (with no instance deactivation) before the framerate drops below 60, and it uses lighting and particles and all sorts of other things on top of the basic instances... The rest of what you say is purely SUBJECTIVE and has no bearing on whether GM is capable or not of doing X thing, which I'll remind you, was the subject of this topic.

Oh, and just because you weren't a part of a discussion, doesn't mean that it didn't happen. All suggestions that reach the YYG devs are carefully considered before being rejected or applied. A number of changes have been made to GML at the request of developers (ask the Hyper Light Drifter guys, for example), so just because your suggestions haven't been implemented, doesn't mean that they weren't considered or that NO user suggestions are implemented. ;)
How is what I said subjective? I literally listed important features that GameMaker does not have that other engines do have, those are absolute fact.

Not sure how you managed to get such good performance with 8000 objects, my tests only used enemies that just bounced around the room. I also had a drop shadow engine in play, but disabling it only saved 10 FPS.

And it wasn’t me making suggestions. In the old forums I kept seeing good suggestions locked because “oh you can do these like 10 obnoxious steps to work around it.”

What I was trying to say in my original post was that you _can_ make a game like Stardew Valley, but making it in something like GM is impractical due to lack of modern features. I, however, do like that a good portion of the listed features are on the roadmap, but the problem is that there are already other engines and languages that have had such features for ages. Heck, even C had data containers.

I would rather not wait for YYG to play catch-up and just move to another engine, and still use GM for what it is best at: rapid prototyping, as it is unrivaled when it comes to the speed of starting up a project.

EDIT: Forgot to say that I am still an active GameMaker user as it is my team’s engine of choice and we don’t want to move everyone to another engine until we know for sure that what we jump to is a better alternative. GameMaker lacks good competition atm as most modern engines are focusing on 3D while my team just wants to make 2D games. GameMaker is basically the lesser of all evils for us. What I am currently doing is making my solo project in other engines to “test the waters” before our full team jumps ship.

It is weird for me because I cannot recommend GameMaker for big projects for previous reasons, yet at the same time it has among the best 2D dev tools out there. I guess you could say my thoughts are extremely mixed.

EDIT 2: New recommendation: Use GM until something better comes out for 2D dev.
 
Last edited:
M

MishMash

Guest
I'll chip and say that I agree GM games "can" become hard to maintain, but tbh, from my experience, it's not all that dissimilar to working in other languages like C#. (You can write poorly organised, and hard-to-maintain code in any language) While GM doesn't really do anything to encourage good programming habits, and it can end up being a bit too flexible, if you adhere to good code organisation and also utilise GM in a way that best suits it, you can have a good amount of success, while still reaping the benefits of the engine.

For example in our project, we have a huge amount of code (~140,000 lines) however everything is implemented in a very modular and organised fashion, with clean function sets defined for each module, and control flow well organised through a series of control objects and control scripts. At this point no matter what content we add, its addition is clean and easy, and each individual piece of content can be treated almost entirely in isolation from other features (which ultimately makes code far more maintainable).
Performance scalability also shouldn't really come down to the number of objects the engine can have simultaneously, because regardless, if you are working on a game with a large world, the TOTAL number of objects in the world will be massive compared to the number you want to actively be simulating. So at that point, regardless of which environment you are working in, it is your responsibility to balance your resources. Having a few extra objects in another engine would mean that your game would run a bit faster without you having to do any extra work, but ultimately, the actual overall large-scalability wouldn't significantly improve, it would just delay the onset of the problem.

That is not to say GM is by any means perfect, but I personally think that the fast-development nature is a reasonable trade-off for some of the areas it is currently lacking in. I can still work in GM 2-3x faster than almost any other environment.

-- To answer OP as someone who is working on a super large project, it is definitely possible yes, however as Cloaked games said, it's not something that is all that easy to do. It'll take a few years of experience working on a variety of projects to gain the skills necessary to be able to develop any game with scale. A lot of it comes down to learning from doing. You'll make mistakes as you go, and hit walls in projects where you are limited by the code you wrote at the start. Eventually, you'll pick up techniques and habits that enable you to resolve these issues. Once you have a toolkit of skills and techniques, you can throw them all in together and work on almost any game you could want. After 10 years, I find GameMaker itself quite straight forward and fast to program in, and don't get hung up on issues any more. Though if you do want to dive in the deep end, you can always just give it a go and see how things turn out. Often having a clear goal in mind is a great way to motivate learning, as feature-by-feature, you'll be breaking down the task that needs to be done and learning how best to achieve it. It is likely that you wont be able to finish it the first time around, but that is all part of the process. I haven't personally finished many games, just have loads of hanging prototypes, but I have still learned a heck of a lot by trying :)

So do what you find fun for now. Once you gain a bit of experience, you'll be able to answer this question for yourself. When you get to that point, you'll know whether GM is the right engine to do what you want. (It definitely can be, but it can also depend on how YOU like to approach game dev, I personally like GMs flow, with regard to how instances are managed, how you have direct control over memory with datastructures, how networking is quite clean and minimalistic).
 
S

Sam (Deleted User)

Guest
No structs, no object methods, poor performance (I measured about 500-ish objects to drop below 60 FPS), GML looks messy, the IDE gets really sluggish when your project gets big enough, proper composition is difficult to do in GML as everything has to be an object and you can’t just have simple data containers, lack of proper features that other modern engines have, and so on. Also I find GM’s development slow and YoYo Games seems to not understand what people want, constantly declining feature suggestions because obnoxious workarounds exist. When I suggest something to Godot devs it immediately at least gets considered.



Because it is the only other modern engine I found that has a dedicated 2D pipeline. I tried Unity but making a pixel art game in it is an absolute pain. Godot I got really comfortable with after only 3 days of use. But as said Godot has its own problems that I am waiting for it’s next major release to sort out.
Thank you. Here's someone who doesn't lack perspective and actually acknowledges where GM falls short. This made my day.
 
I

icuurd12b42

Guest
I agree with the statements made about the shortcoming of GameMaker that are language related as in lacking features. That coming from a guy who was really upset when all them languages started to basically look the same... Years later I see the benefit of being able to grab code off the web and be able to have it run with minimal tweaks in JS, Java, c++, c#, etc.

Any shortcomings mentioned that are related to the performance of the language I can also agree with, there is something weird that yyc is slower than javascript, there is no denying this.

On the other hand as long as you stick with what the tool was designed to do and with a little cautious programming I don't see how such a game would be unachievable...
 

Kezarus

Endless Game Maker
No structs, no object methods
you can’t just have simple data containers
GML looks messy
Yeap, that sums up my frustrations with GM. I manage to do database-like txt archive and it works amazing, but had to store an entire line in a string that is separate by "|" instead of using a struct is a downer.

Or when I have to make script functions that are from an object exclusively and use "with(that_object){}" at the start.

Don't even get me started about the complete lack of simple IDE like buttons, panels, input texts... (ok, that is probably my fault. maybe the market place have something...)

Don't get me wrong people, I love Game Maker, been using it since 2006, made a top down shooter that is on Steam even. I think Unity does a crappy job at making 2D games and, for someone like me that have no team whatsoever and have to do everything on my own, it's a nightmare for solo devs despite the C# and Visual Studio support.

Answering OP, sure, I think you can manage to develop something along Stardew Valley lines. If you are organized enough, you could do almost anything on Game Maker. It depends on you mostly. (But I would love to see structs and functions implemented on Game Maker to ease my life, in fact, everyone's lives. =])

Cheers!
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
Yeap, that sums up my frustrations with GM. I manage to do database-like txt archive and it works amazing, but had to store an entire line in a string that is separate by "|" instead of using a struct is a downer.
Packing data into an array with a helper enum or macro set for name->index matchups is the common way of doing this, sometimes in other dynamic languages as well (because array access is commonly faster than field access in dynamic languages without V8-style optimization).

There are also more radical solutions for writing high-level code.
Or when I have to make script functions that are from an object exclusively and use "with(that_object){}" at the start.
There are more elegant methods
Don't even get me started about the complete lack of simple IDE like buttons, panels, input texts... (ok, that is probably my fault. maybe the market place have something...)
Everyone made an UI library because what programmer doesn't make an UI library at least once
 

11clock

Member
Packing data into an array with a helper enum or macro set for name->index matchups is the common way of doing this, sometimes in other dynamic languages as well (because array access is commonly faster than field access in dynamic languages without V8-style optimization).

There are also more radical solutions for writing high-level code.

There are more elegant methods

Everyone made an UI library because what programmer doesn't make an UI library at least once
This is exactly what I meant earlier, not wanting modern features because obnoxious workarounds like these exist. Do you _not_ want GM to improve?
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
This is exactly what I meant earlier, not wanting modern features because obnoxious workarounds like these exist. Do you _not_ want GM to improve?
I'm not a YYG employee and I do not have control over how GM improves, so I write posts or software that address the problems in ways that are available.

I would also argue that source-to-source compilation is a logical conclusion for high-level design rather than a "obnoxious workaround" as this is precisely what people did for JavaScript (and other languages) when it became clear that it wasn't manageable for giant projects. This is how there is TypeScript. And Haxe itself. And many other languages.
Should there be further concerns about whether this solves "large project" problems, this is what was used for GMLive (which has it's own GML compiler+bytecode interpreter running in GML), GML superset used for Nuclear Throne mods (of which there are few hundred), and a number of other projects with seemingly unlikely specifications.
 
Last edited:

11clock

Member
I'm not a YYG employee and I do not have control over how GM improves, so I write posts or software that address the problems in ways that are available.

I would also argue that source-to-source compilation is a logical conclusion for high-level design rather than a "obnoxious workaround" as this is precisely what people did for JavaScript (and other languages) when it became clear that it wasn't manageable for giant projects. This is how there is TypeScript. And Haxe itself. And many other languages.
Should there be further concerns about whether this solves "large project" problems, this is what was used for GMLive (which has it's own GML compiler+bytecode interpreter running in GML), GML superset used for Nuclear Throne mods (of which there are few hundred), and a number of other projects with seemingly unlikely specifications.
This sounds much more like trying to use something for a purpose that it wasn’t designed for, the equivalent of using a hammer to nail a screw. Instead of trying to do this, why not just use a tool more fit for larger projects instead?

As said my issue with GM is that, while it has a lot of nifty tools for 2D dev that other engines lack due to them focusing on 3D, you have to use an extremely dated programming language to get anything done in it, and the only “solution” so far seems to just be relying on 3rd party tools, which seems much more like bandaiding over the actual problem.
 
Last edited:

Kezarus

Endless Game Maker
Packing data into an array with a helper enum or macro set for name->index matchups is the common way of doing this, sometimes in other dynamic languages as well (because array access is commonly faster than field access in dynamic languages without V8-style optimization).
Yep, pretty much what I'm doing. I store an array/list inside another with a enum indexer. But... wouldn't be better to use a struct? =]

There are more elegant methods
Yay! Thanks Yellow. Gonna read this afterwards with morte attention.

Everyone made an UI library because what programmer doesn't make an UI library at least once
Yeap, pretty much my fault as I said. =]

Cheers!
 

FrostyCat

Redemption Seeker
This is exactly what I meant earlier, not wanting modern features because obnoxious workarounds like these exist. Do you _not_ want GM to improve?
As a current GM user, of course I have a stake in GML's ongoing growth. But getting it to improve for real is not just up to devs at YoYo.

In my experience, the GM user community is far-right conservative with the way it codes, especially those without exposure to other languages or paradigms. You can show it new techniques and their associated benefits, but it would refuse to try because popular opinion and big-name tutorials aren't already advocating it. And unless the technique does something flashy, most mid- to low-range users are too superficial to see how it would serve them. That discourages the development and adoption of new coding patterns, styles and syntax. You can lead a horse to water, but you can't make it drink.

There are also examples of improvements being made, but then reverted because the community was too vested in its ways to use it. The best example is trigger events from 8.1. It could have had a siginificant effect in organizing cross-cutting concerns (e.g. pausing) and reducing the contiguous length of step code, and I've seen what it can do myself. But because having fat, one-piece Step events was (and remains) over-encouraged by tutorials and general user sentiment, most users failed to leverage its strengths and subsequently called it useless. If you knew me back then, I was one of the few who leveraged it extensively and came up with new usage patterns for it. I was one of trigger event's biggest proponents. I was not able to save it.

So yes, I do want GM to improve. But for it to happen, the community should spend more time critically thinking about its tools and conventions. And if it leads to adverse practical consequences, it should be open to alternatives and/or replacements.

Doing something only because Spalding, HeartBeast and "the herd" are also doing it is a big problem around here, and GML becoming stunted in its development is one of the most immediate consequences.
 

11clock

Member
As a current GM user, of course I have a stake in GML's ongoing growth. But getting it to improve for real is not just up to devs at YoYo.

In my experience, the GM user community is far-right conservative with the way it codes, especially those without exposure to other languages or paradigms. You can show it new techniques and their associated benefits, but it would refuse to try because popular opinion and big-name tutorials aren't already advocating it. And unless the technique does something flashy, most mid- to low-range users are too superficial to see how it would serve them. That discourages the development and adoption of new coding patterns, styles and syntax. You can lead a horse to water, but you can't make it drink.

There are also examples of improvements being made, but then reverted because the community was too vested in its ways to use it. The best example is trigger events from 8.1. It could have had a siginificant effect in organizing cross-cutting concerns (e.g. pausing) and reducing the contiguous length of step code, and I've seen what it can do myself. But because having fat, one-piece Step events was (and remains) over-encouraged by tutorials and general user sentiment, most users failed to leverage its strengths and subsequently called it useless. If you knew me back then, I was one of the few who leveraged it extensively and came up with new usage patterns for it. I was one of trigger event's biggest proponents. I was not able to save it.

So yes, I do want GM to improve. But for it to happen, the community should spend more time critically thinking about its tools and conventions. And if it leads to adverse practical consequences, it should be open to alternatives and/or replacements.

Doing something only because Spalding, HeartBeast and "the herd" are also doing it is a big problem around here, and GML becoming stunted in its development is one of the most immediate consequences.
I have also noticed this problem with the community, as a lot of these work arounds are also suggested by them as well. Meanwhile when I go over to the Godot community, there is always active discussion on how to fix Godot’s core issues with lots of debates, and it has lead to the engine’s extremely fast development speed. Heck, the next update will be introducing static typing to Godot’s built-in language, finalize C# support and will also be rebuilding parts of the IDE from scratch to improve usability. And note that Godot has only been around for a few years. Compare that to GM’s 15 years or so just to get partial code folding and still lacks proper vectors.

This far-right conservative behavior from both the devs and community hindering GM’s growth is a big reason why I have been trying to find an alternative to GM for the past few years. I am sick of this bullsh*t. But the truth is that it is hard to find anything better right now as engines are more and more focused towards 3D games. Any possible alternatives for 2D dev seem more geared towards mobile and HTML5 development (Construct 2’s desktop exports are literally just wrappers for HTML5 for example).
 
Last edited:

YanBG

Member
It could be just me but i surpassed these tutorials after the first few months into GM. Gaining experience in the planing of your game is very important. I've remade a lot of it many times and it gets better(more modular, less hardcoded) but the process is very slow. Forget about a game each month, more like years(unless they are shovelware).

I don't use any third-party tools, except for the graphics(blender), but my levels aren't handcrafted.

Now do you mean performance for mobile or windows? I suspect i'd be glad if all the cross-platform functions that i don't use(yet/atm) would be thrown away, to improve the fps of my pc game. Especially for 2d(~20 years old looking) game on modern pc performance shouldn't be an issue.
 
I

icuurd12b42

Guest
Oh come on with the vilifying far-right conservative hyperbole...
Every developer in charge of implementing a language is conservative in the changes he will make to the language. it's the nature of the beast. If I was to tell you, for example, your code needs a rewrite, even if it would take you a day to do so, you would ***tch for 3 weeks before even trying. and that is true for most programmers. by nature you want to be conservative in making changes because you dont want to piss off your user base.

as for that only one feature we ever rejected, the triggers. it was just a silly substitute for a if condition in the step event. of course not many used it.. and if I remember why it was not part of gms1.4 is that they forgot about it converting gm8 to gms1.4 while 8.1 was a different branch... There was a "Ooops we forgot triggers, do you guy really want it" post and many said they did not use it. so yoyo did other more pressing things instead like yyc...

I would actually welcome a forum to discuss changes we really want to the language. but if it would turn into an outright political left vs right insanity politics we see on social media, I'm out. What's next, language don't change because trump? c'mon guys...
 

11clock

Member
Oh come on with the vilifying far-right conservative hyperbole...
Every developer in charge of implementing a language is conservative in the changes he will make to the language. it's the nature of the beast. If I was to tell you, for example, your code needs a rewrite, even if it would take you a day to do so, you would ***tch for 3 weeks before even trying. and that is true for most programmers. by nature you want to be conservative in making changes because you dont want to piss off your user base.

as for that only one feature we ever rejected, the triggers. it was just a silly substitute for a if condition in the step event. of course not many used it.. and if I remember why it was not part of gms1.4 is that they forgot about it converting gm8 to gms1.4 while 8.1 was a different branch... There was a "Ooops we forgot triggers, do you guy really want it" post and many said they did not use it. so yoyo did other more pressing things instead like yyc...

I would actually welcome a forum to discuss changes we really want to the language. but if it would turn into an outright political left vs right insanity politics we see on social media, I'm out. What's next, language don't change because trump? c'mon guys...
That remark wasn't intended to be political at all.
 
I

icuurd12b42

Guest
That remark wasn't intended to be political at all.
You do realise the term is basically one step short of basically calling us natzis in todays mindset... There are far better adjectives to define the community.
 

FrostyCat

Redemption Seeker
Oh come on with the vilifying far-right conservative hyperbole...
Every developer in charge of implementing a language is conservative in the changes he will make to the language. it's the nature of the beast. If I was to tell you, for example, your code needs a rewrite, even if it would take you a day to do so, you would ***tch for 3 weeks before even trying. and that is true for most programmers. by nature you want to be conservative in making changes because you dont want to piss off your user base.
Nobody is suggesting radical changes to GML like turning it syntax or paradigm upside down.

I am suggesting that the community start by being more investigative with alternative architectures and techniques not covered in usual tutorial fare, or patterns found in other languages with applicability in GM. And from that, I hope that some of them will prove to have long-term merit for GM development, and YoYo can then devote efforts in facilitating those architectures/techniques with improved GML syntax.

We all agree that there needs to be some sort of stability in the language for there to be a point. If GML changes so often that it no longer brings consensus between the developer and the compiler, it ceases to be useful.

But compared to shifting around too quickly, the kind of fixation that is today's GML really isn't much better.

as for that only one feature we ever rejected, the triggers. it was just a silly substitute for a if condition in the step event. of course not many used it.. and if I remember why it was not part of gms1.4 is that they forgot about it converting gm8 to gms1.4 while 8.1 was a different branch... There was a "Ooops we forgot triggers, do you guy really want it" post and many said they did not use it. so yoyo did other more pressing things instead like yyc...
If you put that hat on trigger events from day one, of course you're going to miss out on the benefits it can confer. And because so many people did the same, YoYo lost a valuable opportunity to improve on a fledgling code organization feature.

The reason was not that YoYo forgot about it in GMS 1.x's development --- it was actually part of GM up until GMHTML5, where it still existed and was working. Ever since triggers were introduced, its "like a condition in the step event" aspect was the only one most people ever thought of (except me), so it was quickly discarded by popular opinion without any critical evaluation. On several occasions, I showed that with small variations in the trigger condition, addition of active code and alternative architectures, it is possible to reorganize various cross-cutting concerns with it instead of repeating step code. It proved to be too unorthodox compared to community practices to catch on.

Pressure on paring down features mounted when the page on GMS 1.x was turned, and one day the admins held a referendum on trigger events. I remember the wording was along the lines of "OK, we think trigger events are useless, what do you think". Popular opinion rushed in concurring that it was useless because most people preferred hogging code in the step event. Then triggers were dropped on GMS 1.0.

Yes, even I admit that trigger events had a flawed implementation, for example the inability to set up initialization code for implementors and object-local triggers. But for expansions like that to have happened, the user community can't be so conservative as to refuse to evaluate new organization techniques and challenge current community "best practices" --- in this case, the everything-in-the-step-event fashion that is still popular today. Note the quotes on "best practices", some of them are undoubtedly questionable for anyone with professional experience in programming.

I would actually welcome a forum to discuss changes we really want to the language. but if it would turn into an outright political left vs right insanity politics we see on social media, I'm out. What's next, language don't change because trump? c'mon guys...
I am not using the term "right-wing" in the hyperpartisan sense. I am using it as the original definition of the term (i.e. conservative and traditional), in the context of how developers look at their craft and the languages they use.

My opinion is that there isn't enough appreciation nor growth of reformist and investigative voices (i.e. left-wing voices) in GM user circles. The same old techniques and organization patterns are being used to produce the same old kinds of products, and some of those traditional results actually do suck:
  • Poor code maintainability and readability due to large contiguous code chunks, especially in Step events
  • High prevalence of repeated code
  • High coupling between components
  • Overuse of graphical representations as a data model
  • Overrepresentation of pixel art and action games in GM products
In order to cater to this community orthodoxy, YoYo is maintaining GML in a direction that favours these suboptimal, sometimes outdated practices. That is making GML go backwards and stay backwards, while YoYo's competitors continue to evolve.

I suggest that you watch some of GMWolf's code architecture videos as an example of left-wing voices that GM desperately needs. He knows inside-out about the flaws of existing models, and many of those videos propose solutions to them. If alternative techniques like his would get wider consideration and acceptance, YoYo would be more motivated to promote and grow new features facilitating more effective use cases.

I too would welcome a forum to discuss new architectures and language/IDE changes that could facilitate them, but not if it would just be written off as weird for looking nothing like usual tutorial fare. And given that the "written off" part has happened before, I worry about it repeating today because of orthodoxy favouring current practices (many of which are neither optimal nor modern). Nothing good can come out of GML stagnating this way.
 
I

icuurd12b42

Guest
I can tell you what I think GMS2 did wrong with gml imho... It was the perfect opportunity to switch to a new language entirely, possibly a commonly used one with modern features. "Libafy" the old language in the new one... and add a templates that mirrors the old gms14 engine which the import (and old gml purists) would use... Still you would have the ability to use the original language functions while giving the opportunity to migrate the new language features...
 

FrostyCat

Redemption Seeker
I can tell you what I think GMS2 did wrong with gml imho... It was the perfect opportunity to switch to a new language entirely, possibly a commonly used one with modern features. "Libafy" the old language in the new one... and add a templates that mirrors the old gms14 engine which the import (and old gml purists) would use... Still you would have the ability to use the original language functions while giving the opportunity to migrate the new language features...
And indeed that almost happened.

JavaScript was briefly available in GMS 2 during the closed beta. But testing that requires having testers with prior exposure to web development, and the critical mass just wasn't there. Mix that with conflicts against existing GML requirements, and the feature was dropped before the first public release.
 

11clock

Member
And indeed that almost happened.

JavaScript was briefly available in GMS 2 during the closed beta. But testing that requires having testers with prior exposure to web development, and the critical mass just wasn't there. Mix that with conflicts against existing GML requirements, and the feature was dropped before the first public release.
JavaScript wouldn’t have been much better. JavaScript is a web language and unsuitable for large projects, especially games.
 
I

icuurd12b42

Guest
And indeed that almost happened.

JavaScript was briefly available in GMS 2 during the closed beta. But testing that requires having testers with prior exposure to web development, and the critical mass just wasn't there. Mix that with conflicts against existing GML requirements, and the feature was dropped before the first public release.
I guess I missed that beta version...
 

Mick

Member
TypeScript would have been a better option. It would have brought static types (optional), classes and namespaces among other things.
 
M

mike0804

Guest
Yeah, GameMaker lacks good competition atm as most modern engines are focusing on 3D while my team just wants to make 2D games.
 

Yal

🐧 *penguin noises*
GMC Elder
My opinion is that there isn't enough appreciation nor growth of reformist and investigative voices (i.e. left-wing voices) in GM user circles. The same old techniques and organization patterns are being used to produce the same old kinds of products, and some of those traditional results actually do suck:
  • Poor code maintainability and readability due to large contiguous code chunks, especially in Step events
  • High prevalence of repeated code
  • High coupling between components
  • Overuse of graphical representations as a data model
  • Overrepresentation of pixel art and action games in GM products
I'd add "overuse of global data instead of namespacing/modularization" to that list as well, it has ramifications for a lot of systems - it's a bunch of extra work to transfer objects containing data between rooms (and there's no such thing as a "data object") so it's much easier to store all persistent data as globals.... all objects/scripts/resources, and instances in a room also share a big global namespace... since you need to find your own system of separating concerns, but don't need to separate concerns for any reason other than your own sanity, it's easy to create a mess of hardcoded references between unrelated things that ultimately just hurt you in the long run.
 

FrostyCat

Redemption Seeker
I'd add "overuse of global data instead of namespacing/modularization" to that list as well, it has ramifications for a lot of systems - it's a bunch of extra work to transfer objects containing data between rooms (and there's no such thing as a "data object") so it's much easier to store all persistent data as globals.... all objects/scripts/resources, and instances in a room also share a big global namespace... since you need to find your own system of separating concerns, but don't need to separate concerns for any reason other than your own sanity, it's easy to create a mess of hardcoded references between unrelated things that ultimately just hurt you in the long run.
Maps and arrays typically fill the "data object" role in GML, and both GMWolf and I have demonstrated and documented these patterns. It's just that most of the GM user community don't have any experience or interest outside standard Spalding/HeartBeast fare, and won't care to look for or think about them.

Those of us with non-fundamentalist experience in other languages typically also know patterns for reducing coupling and hard dependencies. But again, these people aren't exactly easy to come by, and tutorials in the GM sphere typically emphasize friendliness over proper technique.
 

Evanski

Raccoon Lord
Forum Staff
Moderator
you all over here saying gms this gml that and Im sitting over here wondering why every code has to be some sort of alien language and why not just


Code:
object: pie[If eat] (object:player.Hp ++ 3)
Rather then

Code:
with(obj_pie)
{
    if  (eat == true)
    {
           obj_player.hp++;
     }
}
 
M

MishMash

Guest
My opinion is that there isn't enough appreciation nor growth of reformist and investigative voices (i.e. left-wing voices) in GM user circles. The same old techniques and organization patterns are being used to produce the same old kinds of products, and some of those traditional results actually do suck:
  • Poor code maintainability and readability due to large contiguous code chunks, especially in Step events
  • High prevalence of repeated code
  • High coupling between components
  • Overuse of graphical representations as a data model
  • Overrepresentation of pixel art and action games in GM products
In order to cater to this community orthodoxy, YoYo is maintaining GML in a direction that favours these suboptimal, sometimes outdated practices. That is making GML go backwards and stay backwards, while YoYo's competitors continue to evolve.

I suggest that you watch some of GMWolf's code architecture videos as an example of left-wing voices that GM desperately needs. He knows inside-out about the flaws of existing models, and many of those videos propose solutions to them. If alternative techniques like his would get wider consideration and acceptance, YoYo would be more motivated to promote and grow new features facilitating more effective use cases.

I too would welcome a forum to discuss new architectures and language/IDE changes that could facilitate them, but not if it would just be written off as weird for looking nothing like usual tutorial fare. And given that the "written off" part has happened before, I worry about it repeating today because of orthodoxy favouring current practices (many of which are neither optimal nor modern). Nothing good can come out of GML stagnating this way.
I do definitely agree that GM can encourage really bad habits, and it would be nice if there was a little more strictness. Interestingly, since having worked on a large project, and also now having a good grounding in a large variety of programming languages, i've started to utilise GM for paradigms it enables which are just difficult of faffy in other programming languages. That said, i'll start by clearing my main gripes which you have also addressed:

  • Lack of some form of data object (as it stands, I've started using maps and json_decoding/encoding a lot. Would be nice to skip the middleman here and just have direct access to json as a variable type (This is a reasonable compromise for something that could be added vs having specific structs).
  • Inability to disable default code routines on objects (I never use GMs built in motion anymore, so would be nice just to disable a lot of the default checks)
  • Lack of custom tagged user events (I suggested this as a feature when I met the YYG staff at an event a few years back). -- I had an interesting idea for extending functionality of component oriented programming, entirely using GMs existing architecture, but just adding a bit more structure and definition to what you are doing. E.g. script groups as components, and ability for a component to enforce event slots for custom defined events in objects, and equally, the ability to use GMs iterators (with, place_meeting object markers, or any area you can put an object index, you could put a "tag" e.g. "component_health" and it would run for all objects with the health component.)
Though getting onto the meat of my post, there are a few things you can actually really start to appreciate about GMs design that some engines just flat-out don't have. The massively overlooked, and often missed major feature of GM is the fact that its design patterns are DIRECTLY integrated into the functional core of the engine. GMs event loop is more beneficial to game dev and code organisation than people give it credit for. Whilst it doesn't entirely solve the problem, it does provide some structural integrity to your game's code, and equally does enforce some amount of use of design patterns, which other engines don't necessarily do. For example, code related to receiving network packets is safely contained within the networking event. Extending on from this, the missing link i described above about custom user events does make it so GM itself doesn't make the most of a few of its better features. To give you an idea of things I like about GM, or coding practices I employ:

  • Component oriented design using groups of scripts to create shared behaviour that can be used amongst a range of different objects. The great thing about scripts is you don't have to worry about inheritance. If you want something to use a health system, you can create a series of function such as: health_init(hp max), health_step(..), health_drawbar(...), health_restore(..), health_apply_damage(..). All sorts of sub-systems like this can be used to arbitrarily assign functionality to any object, without needing to repeat the code. Similarly, from an efficiency standpoint, an object can start off quite raw, and only have its variables added through these component-style script groups.

  • Existence-check based programming. I know this will spark debate, but I personally like the way GMs object system works. Whilst checking for instance existance can be weird, and you get some people rallying out the pitchforks asking for some kind of C#-style reference/garbage-collection system, there are a few undeniable benefits of existence based object management (or in the case of datastructures, custom memory management):
    #1 - When an object is destroyed, it is truly gone. This means you can be confident in knowing your memory usage wont explode and then have you hit a big stutter when GC rolls in.
    #2 - As a side-effect, having to then poll for existence of instances can actually be a good paradigm when it comes to gameplay safety, progressive loading, deactivation and networking. Given that in a real game environment, where you may have content dynamically loading/unloading, or networking where things may not always instantly exist, programming to poll for existence before interfacing with something is a nice way of keeping your game stable and ensuring some amount of correct functionality in the situation where things dont quite go right. Having to worry about things like object-pools can become very cumbersome (I know you can argue some amount of efficiency gain, not having to re-create objects, however they aren't nice to work with).
    #3 - In the case of memory management, I also like being able to dynamically create/destroy things without having to worry about floating/dead references. Especially for a game like mine where the data of the entire world far exceeds the size of standard memory, and precise resource management is essential.

  • Utilising custom user events as a means of "interface" style programming. I use this to encapsulate saving, loading and networking functionality within objects. When i'm a bit less busy, i'll write an intricate article on my networking system as i'm really proud of its design and ease of implementation. It also makes the maximal use of GMs architecture and has very clean organiastion and back-end management.

  • Scripts are also fantastic for creating all kinds of arbitrary systems. I often pass script indices around as references all of the time. I know this isn't exclusive to GM, but the context control flow can be really nice. For example, i've created a chat system where scripts are used to define core properties about the chat window, add responses etc; that feed off to other chat scripts. Similarly, as these chat handler scripts run within a specific object that only exists temporarily and defines each chat interaction, the scripts can also define local variables which are shared amongst subsequent chat script execution. This allows a rather unique way of maintaining a local, but flexible, context across multiple independent script executions. So for example, if I want a series of chat scripts to keep track of a specific state such as an NPCs mood, I can create a mood variable which gets modified based on the choices made. But this mood variable doesnt need to be defined in the root chat controller, it can just be progressively manipulated within the set of scripts that care about that one variable.
    Having a flexible local variable context like that can be powerful when used correctly.

I will add that a lot of these potential practices aren't necessarily entirely obvious, even to programmers who come from different backgrounds, and it has taken me years and years of making bad design decisions and re-writing systems to finally get a feel for a programming style that consistently works, and equally produces maintainable code for a giant project. I feel one day i'll be able to claim that my project is perhaps the biggest project made in GM. With regard to code-base size and unique feature count :p
 
Last edited by a moderator:
  • Like
Reactions: Yal

Yal

🐧 *penguin noises*
GMC Elder
Scripts are also fantastic for creating all kinds of arbitrary systems. I often pass script indices around as references all of the time. I know this isn't exclusive to GM, but the context control flow can be really nice
Definitely gonna have to agree with this, GM has a very user-friendly system for passing functions around as data (especially since they're untyped). I've written a bunch of interpreters for cutscene systems, but the one I'm the most proud of simply put a bunch of script/argument pairs in a queue and popped them one by one; no extra work was needed to extend the interpreter since you could put an arbitrary script in there (including scripts not originally meant for the cutscenes). And a lot of my current enemy step events are simply script_execute(my_behaviour).

Agreeing with all of your post, but I kinda feel like "custom-tagged user defined events" can't be stated enough so I'll state that one gripe again. :p

Oh, and also, an infinite number of user defined events would be a nice addition alongside that. With proper organization, 16 is plenty, but it still limits what you can do.
 
Oh, and also, an infinite number of user defined events would be a nice addition alongside that. With proper organization, 16 is plenty, but it still limits what you can do.
Although I agree, I found that I can just pass an object. In the object, you can assign as many variables as needed. Then you can use fewer argument# parameters. It is an alternative to not having unlimited arguments to pass, but its definitely not as clean as passing a custom class. It is also heavier in memory using an object.

Also, more on the topic: Cattails was made using GM. It is very similar to Stardew Valley. No reason, other than your own limitations, that it cannot be done in GM.
 
C

Cozen7734

Guest
NVM... Sorry for the bump.
 
Last edited by a moderator:
Top