Is it okay to make a game maker in game maker ?

boopboops

Member
I tried to develop a game creation program in Game Maker Studio. I heard that there could be legal consequences for that from my friend so I stopped developing it. I was wondering whether anyone could shine light on that for me. If I where to release it for free for example would that still be bad ?
 

TsukaYuriko

☄️
Forum Staff
Moderator
The community guidelines state that you are not allowed to "Post topics that could promote any product that directly or indirectly competes with any product by YoYo Games Ltd."
Furthermore, the EULA states the following:
Do not copy, modify, merge, distribute, translate, rent, lend, lease, reverse engineer, decompile, disassemble or create derivative works of: (i) Publisher Property (unless specifically agreed otherwise with the relevant Publisher); or (ii) the YYG Property.
I'll refrain from interpreting these, as this is a question best answered by YoYo Games' customer support, and therefore not here on the GMC, as it is not actively monitored by YYG staff. ;)
 

EvanSki

Raccoon Jam Host
The community guidelines state that you are not allowed to "Post topics that could promote any product that directly or indirectly competes with any product by YoYo Games Ltd."
Furthermore, the EULA states the following:


I'll refrain from interpreting these, as this is a question best answered by YoYo Games' customer support, and therefore not here on the GMC, as it is not actively monitored by YYG staff. ;)
I interpret this as dont create a derivative work of game maker, in game maker
 
  • Like
Reactions: Roa
I interpret this as dont create a derivative work of game maker, in game maker
That quoted section of the EULA didn't mention GM at all. Creating a game creation engine using GM doesn't violate any of that and it definitely doesn't make it derivative work. It's 100% yours, just like it would be if you made a platformer instead.

That said, GM really can't create a fully fledged game engine. There are a ton of features that would need to be implemented that just aren't there. The most it could do is something like Mario Maker where you can create levels and play them in-game, but last I checked that was A-OK to discuss here.
 
Last edited:

Roa

Member
You're free to do what ever you want with it. I've seen plenty of little self coded dev engines and "quick game makers" made in GMS.

All the EULA says is that you can't brandish yoyo's name as your own or distribute and sell GMS whole or in part.

And lets be real; no one is making competition for yoyo in this manner.
 
Probably the most prolific 'gamecreator creator', is @silentworks: He made a post about a bunch of the stuff he's made with GM:

People really shouldn't pooh-pooh making a game creator in GM as a waste of time.
His Android Game Creator has 10,000+ installs, and he sells it for $3 or 4 a pop, so it's a nice little niche market for himself.

He's been making these since at least GM6.
 
Probably the most prolific 'gamecreator creator', is @silentworks: He made a post about a bunch of the stuff he's made with GM:

People really shouldn't pooh-pooh making a game creator in GM as a waste of time.
His Android Game Creator has 10,000+ installs, and he sells it for $3 or 4 a pop, so it's a nice little niche market for himself.

He's been making these since at least GM6.
As impressive as those are, they either
1) aren't fully-fledged game engines and can't export a binary, thus making them as I described earlier, "something like Mario Maker where you can create levels and play them in-game."
2) have several kB worth of external (non-GM) code that allows them to function as a fully-fledged game engine.

Either way, you're not making a full-fat game engine 100% in GM [edit: GML]. You literally cannot. Wasn't really "pooh-poohing" the idea, though.
 
Last edited:
It's an idiom, meaning having nothing (in this case, features) removed.
Yes, I know what you meant. I was curious about what specific features were requirements for you. For example, I'm kind of surprised to see using external code/plugins somehow is a negative/excluding factor, as that's pretty standard industry practice.

I've heard the same argument said against GM for over 10 years. It's not a 'fully-fledged' Game Engine. It's missing important features. Your not a 'real' game engine unless you have X feature.

It was silly then, and it's really kind of silly now.
 
Yes, I know what you meant. I was curious about what specific features were requirements for you.
If you read the post you responded to, I answered that: exporting a binary executable. The singular feature you need for a "game engine" to let you actually produce a standalone game, and you can't do it without an extension*.
*an extension you have to write yourself

For example, I'm kind of surprised to see using external code/plugins somehow is a negative/excluding factor, as that's pretty standard industry practice.
Where did I ever say it was a negative? All I meant is that you can't do the most important stuff in GM [edit: GML] and you'll need to use a ton of C++ or some other lower-level language to do the heavy lifting. Please don't read any malicious motivation behind that statement, because there isn't any.
 
Last edited:
If you read the post you responded to, I answered that: exporting a binary executable. The singular feature you need for a "game engine" to let you actually produce a standalone game, and you can't do it without an extension*.
*an extension you have to write yourself
Oh, I read it. In fact, I even replied to your comment about exporting to a binary executable. (You quoted it on the next line! ).

So to be clear; It's a non-factor in the development world to use an external plugin/wrapper for this kind of task.

Where did I ever say it was a negative? All I meant is that you can't do the most important stuff in GM and you'll need to use a ton of C++ or some other lower-level language to do the heavy lifting. Please don't read any malicious motivation behind that statement, because there isn't any.
You say it was not meant as a negative, when in the next line you say it means it can't do the most important stuff using GM. :) Not being able to do the most important stuff sounds pretty negative to me. In fact, sounds like a show-stopper, if someone was looking to make a game creator using GM.

I don't attribute any malicious motivation. I know where you're coming from, because as I say, I've seen the same thing being said about GM for 10+ years. I'm just telling you how it is. Definitely don't have to agree with me.

Definitely don't agree with the statement that compiling an executable using GM-code is the most important thing to consider when making game creation software. Definitely don't agree it takes a ton of C++ code. (most of those types of things are relatively straightforward wrappers)
 
You say it was not meant as a negative, when in the next line you say it means it can't do the most important stuff using GM.
*In GML. 100% in GM means all of the code is within the bounds of GM, in GML. And you can't create standalone executables 100% in GM without any extensions or external code. It's literally impossible*. You need a decent grasp of C/C++ to be able to write a DLL you can use in an extension. You can't just wing it if you've never touched a source file in your life. I wasn't saying plugins/extensions themselves are a negative. Creating them, however, is a show-stopper if you're a beginner to GM or even programming in general—most users of GM are. That's potentially a big negative you need to be aware of if you want to work on a game engine in GM, which is the point I was trying to make in the first place before you got hung up on something I didn't word perfectly and assumed I was taking a dump on GM/extensions.
*OK, it's not quite impossible. With buffers, you could theoretically write bytecode and save it as a working executable. Have fun with that!

Definitely don't agree with the statement that compiling an executable using GM-code is the most important thing to consider when making game creation software.
Ignoring the struck-out portion because that's completely irrelevant. Creating standalone programs should be priority #1 if you're creating game creation software. That's the one and only feature that separates a game engine from a level pack creation software like Doom Builder, DromEd, or Mario Maker. The end-user needs to download another program separately to play your creation.
 
Last edited:
*In GML. 100% in GM means all of the code is within the bounds of GM, in GML. And you can't create standalone executables 100% in GM without any extensions or external code. It's literally impossible*. You need a decent grasp of C/C++ to be able to write a DLL you can use in an extension. You can't just wing it if you've never touched a source file in your life. I wasn't saying plugins/extensions themselves are a negative. Creating them, however, is a show-stopper if you're a beginner to GM or even programming in general—most users of GM are. That's potentially a big negative you need to be aware of if you want to work on a game engine in GM, which is the point I was trying to make in the first place before you got hung up on something I didn't word perfectly and assumed I was taking a dump on GM/extensions.
I see. We might be talking about different things. All good. Yes, I would say writing a compiler in GML would be not a good idea, or some other such low-level processing. As discussed, should use some other code. And no problem with them doing that.

Happy to disagree that it's a big negative. But you're not wrong to raise awareness about it, either, so that's fair enough.

Ignoring the struck-out portion because that's completely irrelevant. Creating standalone programs should be priority #1 if you're creating game creation software. That's the one and only feature that separates a game engine from a level pack creation software like Doom Builder, DromEd, or Mario Maker. The end-user needs to download another program separately to play your creation.
Once more we might have to just agree to disagree on this one, because, well, I still disagree. Lots of game engines (e.g. Construct 3 is probably the biggest) simply export HTML5/javascript.

Honestly, executable's thesedays are becoming more and more irrelevant. Build a web game, if you really want it as a downable app, you can electron build or just UWP it. (These are pretty much already existing processes.. no advanced C++ magic required, if people were worried about that)
 

James222

Member
*In GML. 100% in GM means all of the code is within the bounds of GM, in GML. And you can't create standalone executables 100% in GM without any extensions or external code. It's literally impossible*. You need a decent grasp of C/C++ to be able to write a DLL you can use in an extension. You can't just wing it if you've never touched a source file in your life. I wasn't saying plugins/extensions themselves are a negative. Creating them, however, is a show-stopper if you're a beginner to GM or even programming in general—most users of GM are. That's potentially a big negative you need to be aware of if you want to work on a game engine in GM, which is the point I was trying to make in the first place before you got hung up on something I didn't word perfectly and assumed I was taking a dump on GM/extensions.
*OK, it's not quite impossible. With buffers, you could theoretically write bytecode and save it as a working executable. Have fun with that!


Ignoring the struck-out portion because that's completely irrelevant. Creating standalone programs should be priority #1 if you're creating game creation software. That's the one and only feature that separates a game engine from a level pack creation software like Doom Builder, DromEd, or Mario Maker. The end-user needs to download another program separately to play your creation.
theoretically it MIGHT be possible to have a runner thats essentially a compiled game maker "game" which works as the runner, the runner has commands in it to read all bytes that are appended to the END of itself, so when the user compiles their game... with alot of work I imagine the workflow would be like:
1. User makes their game in the editor.
2. User exports the game
3. the editor then takes a premade runner exe made in game maker, it only has a few commands to read bytes at a certain location untill no more can be read in. if you know your runner exe is, 4085kb for example you could then tell it to copy this premade runner into a new location and then convert the users game data into strings and write them out byte by byte using file_bin_write_byte, at the end of the exe, this now imbeds the game data directly into the exe fullfilling all requirements.

the exe will still run as windows uses the header to only load the info from the exe it needs, this includes the length, so the exe still runs as per normal even with the appended data to the exe. upon running this would then read the data imbeded from the exe byte by byte until the end of the file, parse the bytes back into strings and reinterpret and run....

HELL OF A JOB THOUGH!
 
theoretically it MIGHT be possible to have a runner thats essentially a compiled game maker "game" which works as the runner, the runner has commands in it to read all bytes that are appended to the END of itself, so when the user compiles their game... with alot of work I imagine the workflow would be like:
1. User makes their game in the editor.
2. User exports the game
3. the editor then takes a premade runner exe made in game maker, it only has a few commands to read bytes at a certain location untill no more can be read in. if you know your runner exe is, 4085kb for example you could then tell it to copy this premade runner into a new location and then convert the users game data into strings and write them out byte by byte using file_bin_write_byte, at the end of the exe, this now imbeds the game data directly into the exe fullfilling all requirements.

the exe will still run as windows uses the header to only load the info from the exe it needs, this includes the length, so the exe still runs as per normal even with the appended data to the exe. upon running this would then read the data imbeded from the exe byte by byte until the end of the file, parse the bytes back into strings and reinterpret and run....

HELL OF A JOB THOUGH!
Yes, in fact I referenced that exact possibility in what you quoted:
OK, it's not quite impossible. With buffers, you could theoretically write bytecode and save it as a working executable. Have fun with that!
No reason to use file_bin* functions now that buffers exist and are orders of magnitude faster. I might just try making a hello-world Windows executable creator proof of concept at some point if I ever get bored...
 

James222

Member
Yes, in fact I referenced that exact possibility in what you quoted:


No reason to use file_bin* functions now that buffers exist and are orders of magnitude faster. I might just try making a hello-world Windows executable creator proof of concept at some point if I ever get bored...
Ah my bad didnt see that part of your message :), ah interesting, im thinking of making a little example right now as well :)
 
Top