Why Do People Love GameMaker So Much?

OliverSB

Member
What is it that attracts the userbase so much. From my understanding and my opinion, its a powerful engine for creating 2D games. With great tools integrated.

What specifically keeps people coming back to GameMaker?

From my understanding, people like the way it abstracts you to focus on coding your game.

I've always wondered, is GML something people love about GameMaker? I am assuming there is reason why GameMaker was created with its own custom scripting language.

Is it because people love being able to use 'with' statements or referencing object instances by the object name?

Is there any benefits to using a programming language with a integer ID based system?

Is there any benefit to referencing arguments using 'argument0', 'argument1', etc compared to other ways of dealing with arguments?

Is there any benefit to only being able to globally reference scripts?
 
  • Like
Reactions: jms

jo-thijs

Member
What is it that attracts the userbase so much. From my understanding and my opinion, its a powerful engine for creating 2D games. With great tools integrated.
For me personally, currently, nothing. (not to say it is a bad product, just that nothing currently attracts me to it)
Way back when I got into GameMaker, what attracted me to it was that it told me it allowed you to easily create cool games (without prior programming knowledge) at a cheap price and it delivered on that.

What specifically keeps people coming back to GameMaker?
It depends on person to person.
I think most people keep coming back to GM because of how easy it is to learn and stay updated on
and how easily and quickly they can create games with it (of a wide range of game genres at least).
Some people have claimed they just stick around GameMaker because they like the community around it and he support they've gotten from it.

From my understanding, people like the way it abstracts you to focus on coding your game.
Focus on game design, not the coding part, that's what you want to abstract away from.
You want to be able to focus on game mechanics, graphics, music, art, level design, story, ...
without having to wory about specifics concerning how you have to code these things,
what underlying system is used for drawing sprites on android phones,
how memory should be managed, how large integers can become, ...

I've always wondered, is GML something people love about GameMaker?
To me, yes.
Many others claim they don't like the GML part about GameMaker.

GML has many shortcomings.
However, I think it serves its purpose pretty well for most games I'm interested in (designing them quickly without worrying about implementing common functionalities such as drawing things).
It is also the language that thought me all the basics about programming (without ever needing a tutorial), so I like it for that reason too.

I am assuming there is reason why GameMaker was created with its own custom scripting language.
I don't know the reason for this, but whatever it is, the decision was made a long time ago.
Now, they just keep GML because it is so iconic for GameMaker and removing it would break all compatibility with earlier GameMaker projects.

Is it because people love being able to use 'with' statements or referencing object instances by the object name?
Even though I like these features (although the latter one has caused so many issues for other people that it might have better been implemented differently),
those are things that could be done in other languages about just as easily as in GML.
They might contribute to people liking GML, but they won't suffice themselves.

Is there any benefits to using a programming language with a integer ID based system?
It makes it so that variables only need to be able to contain 2 data types: reals and strings, which were the only data types in legacy versions of GameMaker.
GML uses weak typing and perhaps this made it easier to implement them.
You can also sometimes perform some cool tricks with ID arithmic (getting the n-th sprite given an offset in the resource tree).

In general towards the user (programmer of the game), it isn't beneficial however.
It only results in confusion when someone makes a mistake towards types (passing a sprite id instead of an object id for example)
and it doesn't add any really useful features.

Is there any benefit to referencing arguments using 'argument0', 'argument1', etc compared to other ways of dealing with arguments?
It's easier to create an editor for it.
Towards the user (programmer of the game) there is none.

Is there any benefit to only being able to globally reference scripts?
It's easier to create GameMaker this way.
Towards the user (programmer of the game) there is none.
 
M

MishMash

Guest
Despite being proficient in many programming languages, I always come back to GM. Whilst GML itself isn't perfect, there is one really key feature that makes it so great for game development and that is how well GML is integrated with the engine. The event system is a great abstraction and unlike many other programming languages, the design patterns are built directly into the engine as a whole. This means that common design practices such as Model-View-Controller are inherent and you don't have to do extra work as a programmer to setup these sorts of systems.

My biggest qualm with most programming languages is that design patterns and code organisation are something you need to implement yourself most of the time. This means if you want to make an entity management system, you have to manually implement a datastructure system to keep track of all active instances, perhaps having maps to different sub-lists of different types so you can find instances of a specific class. All of this is neatly organised into easy-to-use functions within the GML infrastructure.
I also personally love the memory paradigm. I always prefer having explicit control over creation/destruction of things rather than having to rely on Garbage collection. To me, it is a more intuitive way to program and you can also know with certainty that when you destroy some datastructure, it is getting removed from memory immediately. Generally as well, it allows you to program your games in a way that will still enable them to work if data is not loaded, or if something does not exist which can be particularly beneficial when it comes to networking or games with dynamic content loading because you don't always have the resources you expect to have, therefore having existence checks without having to explicitly create a secondary datastructure to manage existence is a nice way of keeping your projects robust, and also identifying problems/bugs without having to crash.
(An example of where this comes into play in a big way is something simple like killing an enemy which another enemy is targetting. If each enemy is just programmed to clear the target if it no longer exists, everything functions correctly. In a language like Java however, keeping a reference to an object is a pain because it means that object wont be unloaded if there is something still targetting it. Which means that you need to add additional functions and a destroyed state to stop objects doing anything if they no longer exist. Whilst this is just a small thing to add, having to do this all over an entire project, and then subsequently cleaning up all references is just another thing which wastes programmers' time.)

The script system also allows you to create general-use components that can be re-used by lots of different objects. This generally makes for a component-oriented style which is beneficial for game dev. The With syntax and general way of using functions to find instances of a given type/testing collisions are also particularly nice. I use with syntax all the time, and whilst you could argue it can make your code messy, having it localised outside of a given instance, it is really powerful to be able to run code from the perspective of another object. I often use this in conjunction with known scripts to perform actions on groups of objects which would otherwise require another script, resulting in a lot of code bloat.

This is not to say GML is perfect, there are a few things that would make it nicer to use:
- A javascript-style object type for wrapping up groups of data and creating "lightweight" structs
- A tagging system, or explicit component system to use in conjunction with the "with" syntax and any other GM function (such as instance_nearest), where it would run for the groups of tagged instances, as inheritance can be limiting in many ways. So for example, if you wanted to run code for all instances which had a "health" tag.
- Named custom user events. I use user events a lot to create clean networking systems and custom rendering routines for objects. This is the sort of situation where having a Java-style interface would be better. GM could resolve this issue by having named events and allow you to assign groups of named events to an instance. For example, I have the following core events for all networked instances:
event user 1 - Write instance network update (Runs when an object wants to update, also includes a switch statement with specific update event ID, so that objects can update in different ways, e.g. send position, send state, send inventory)
event user 2 - Read instance network update
event user 3 - Networked create event (runs after main creation once network object ID has been allocated)
event user 4 - Received network interaction on instance (something has performed an interaction on the object. This could be a damage event on the player (this system encapsulates networked events and the code runs on the host only)).
event user 5 - Network special event - runs when a new player joins the game (To allow a networked object to do things like ripple out desired updates).
event user 6 - Save event (runs for an object when saving, allowing them to write out their data to a file)
event user 7 - Load event

However, given that all these used fixed user event IDs, and there are only a number, we need to constantly pay attention to avoid any overlap with other similar systems which utilise custom events in this way. For example, rendered objects have different user events (13,14,15) in which they must implement some special rendering code, each for different scenarios, such as normal render, lightmask render, interact mask render. Again would be good to be able to name these and avoid chance of overlap.

All-in-all, it manages to be an incredibly fast language to work in that saves you crazy amounts of time and can equally be incredibly fast and efficient where you need it to be. So yeah, I think all of your points are all valid reasons (minus the argument0..n thing, thats just something you get used to though).

So yeah, the reason GML exists is probably GameMaker's most powerful feature. As far as the resource tree and/or editors go, I could take those or leave those, don't really use them personally, and I'd be more inclined to make a level editor specific for my game if I did work with static levels. However the way the scripting language is integrated with the engine makes it super fast to use and removes a lot of the tediousness that comes with programming, allowing you to always keep focused on what matters the most.
 

jo-thijs

Member
Despite being proficient in many programming languages, I always come back to GM. Whilst GML itself isn't perfect, there is one really key feature that makes it so great for game development and that is how well GML is integrated with the engine. The event system is a great abstraction and unlike many other programming languages, the design patterns are built directly into the engine as a whole. This means that common design practices such as Model-View-Controller are inherent and you don't have to do extra work as a programmer to setup these sorts of systems.

My biggest qualm with most programming languages is that design patterns and code organisation are something you need to implement yourself most of the time. This means if you want to make an entity management system, you have to manually implement a datastructure system to keep track of all active instances, perhaps having maps to different sub-lists of different types so you can find instances of a specific class. All of this is neatly organised into easy-to-use functions within the GML infrastructure.
I also personally love the memory paradigm. I always prefer having explicit control over creation/destruction of things rather than having to rely on Garbage collection. To me, it is a more intuitive way to program and you can also know with certainty that when you destroy some datastructure, it is getting removed from memory immediately. Generally as well, it allows you to program your games in a way that will still enable them to work if data is not loaded, or if something does not exist which can be particularly beneficial when it comes to networking or games with dynamic content loading because you don't always have the resources you expect to have, therefore having existence checks without having to explicitly create a secondary datastructure to manage existence is a nice way of keeping your projects robust, and also identifying problems/bugs without having to crash.
(An example of where this comes into play in a big way is something simple like killing an enemy which another enemy is targetting. If each enemy is just programmed to clear the target if it no longer exists, everything functions correctly. In a language like Java however, keeping a reference to an object is a pain because it means that object wont be unloaded if there is something still targetting it. Which means that you need to add additional functions and a destroyed state to stop objects doing anything if they no longer exist. Whilst this is just a small thing to add, having to do this all over an entire project, and then subsequently cleaning up all references is just another thing which wastes programmers' time.)

The script system also allows you to create general-use components that can be re-used by lots of different objects. This generally makes for a component-oriented style which is beneficial for game dev. The With syntax and general way of using functions to find instances of a given type/testing collisions are also particularly nice. I use with syntax all the time, and whilst you could argue it can make your code messy, having it localised outside of a given instance, it is really powerful to be able to run code from the perspective of another object. I often use this in conjunction with known scripts to perform actions on groups of objects which would otherwise require another script, resulting in a lot of code bloat.

This is not to say GML is perfect, there are a few things that would make it nicer to use:
- A javascript-style object type for wrapping up groups of data and creating "lightweight" structs
- A tagging system, or explicit component system to use in conjunction with the "with" syntax and any other GM function (such as instance_nearest), where it would run for the groups of tagged instances, as inheritance can be limiting in many ways. So for example, if you wanted to run code for all instances which had a "health" tag.
- Named custom user events. I use user events a lot to create clean networking systems and custom rendering routines for objects. This is the sort of situation where having a Java-style interface would be better. GM could resolve this issue by having named events and allow you to assign groups of named events to an instance. For example, I have the following core events for all networked instances:
event user 1 - Write instance network update (Runs when an object wants to update, also includes a switch statement with specific update event ID, so that objects can update in different ways, e.g. send position, send state, send inventory)
event user 2 - Read instance network update
event user 3 - Networked create event (runs after main creation once network object ID has been allocated)
event user 4 - Received network interaction on instance (something has performed an interaction on the object. This could be a damage event on the player (this system encapsulates networked events and the code runs on the host only)).
event user 5 - Network special event - runs when a new player joins the game (To allow a networked object to do things like ripple out desired updates).
event user 6 - Save event (runs for an object when saving, allowing them to write out their data to a file)
event user 7 - Load event

However, given that all these used fixed user event IDs, and there are only a number, we need to constantly pay attention to avoid any overlap with other similar systems which utilise custom events in this way. For example, rendered objects have different user events (13,14,15) in which they must implement some special rendering code, each for different scenarios, such as normal render, lightmask render, interact mask render. Again would be good to be able to name these and avoid chance of overlap.

All-in-all, it manages to be an incredibly fast language to work in that saves you crazy amounts of time and can equally be incredibly fast and efficient where you need it to be. So yeah, I think all of your points are all valid reasons (minus the argument0..n thing, thats just something you get used to though).

So yeah, the reason GML exists is probably GameMaker's most powerful feature. As far as the resource tree and/or editors go, I could take those or leave those, don't really use them personally, and I'd be more inclined to make a level editor specific for my game if I did work with static levels. However the way the scripting language is integrated with the engine makes it super fast to use and removes a lot of the tediousness that comes with programming, allowing you to always keep focused on what matters the most.
I agree with everything except this:
I also personally love the memory paradigm. I always prefer having explicit control over creation/destruction of things rather than having to rely on Garbage collection. To me, it is a more intuitive way to program and you can also know with certainty that when you destroy some datastructure, it is getting removed from memory immediately. Generally as well, it allows you to program your games in a way that will still enable them to work if data is not loaded, or if something does not exist which can be particularly beneficial when it comes to networking or games with dynamic content loading because you don't always have the resources you expect to have, therefore having existence checks without having to explicitly create a secondary datastructure to manage existence is a nice way of keeping your projects robust, and also identifying problems/bugs without having to crash.
Although being able to have explicit control over things is often very nice,
I'm happy I don't have to keep explicitly destroying strings and arrays I don't use anymore.
I also don't really like how I always have to explicitly destroy lists, maps and such all the time.
It is a nice way however to show to the programmer when data passed as arguments to a script/function are "call by reference" or "call by value".
Some people find the way arrays are passed as arguments in GameMaker:Studio confusing, but almost noone find how lists are passed as arguments in GameMaker confusing.

As for your argument concerning the habit of performing existence checks,
wouldn't it be better if the language enforced such existence checks when applicable
and you could also use data types which always exist guaranteed (like Maybe works in Haskell)?
Having to always perform existence checks is just a little bit worse than having "null" values for all reference types,
which is generally concidered to be a bad thing.
 
M

MishMash

Guest
I agree with everything except this:

Although being able to have explicit control over things is often very nice,
I'm happy I don't have to keep explicitly destroying strings and arrays I don't use anymore.
I also don't really like how I always have to explicitly destroy lists, maps and such all the time.
It is a nice way however to show to the programmer when data passed as arguments to a script/function are "call by reference" or "call by value".
Some people find the way arrays are passed as arguments in GameMaker:Studio confusing, but almost noone find how lists are passed as arguments in GameMaker confusing.
Okay, regarding that, I agree for literal types such as arrays and strings, how it works with automatically destroying things upon reassignment is good. I was referring more to datastructures. (The reason I didn't mention arrays and strings is because they are immutable, that is, if you assign an array to a different value, you get a copy of that array, not the original array itself. They behave in the same way as an int, and it would be odd to assume you had to manually unload each variable you assign to.) The odd thing with arrays in GM is that they threw the [@] accessor into the mix just to add to the confusion, but that's a discussion for a different time.

As for your argument concerning the habit of performing existence checks,
wouldn't it be better if the language enforced such existence checks when applicable
and you could also use data types which always exist guaranteed (like Maybe works in Haskell)?
Having to always perform existence checks is just a little bit worse than having "null" values for all reference types,
which is generally concidered to be a bad thing.
Well typing is a bit of a different discussion, I could take it or leave it in GM. I agree it would be beneficial in certain situations, however equally, I personally like the way it works. As for Maybe types/optionals, I think they do have a useful application, especially when wanting to to return failure from a function. Though given that GM doesn't have a strict type system, it wouldn't really make sense just to lump it in, as isn't the whole point of a Maybe type so that you are forced to deal with it in every function that has a possibility of a value not existing? This typing enforcement wouldn't immediately apply in GM.

Regarding existence checks, I didn't mean this as being the same thing as a NULL check, existence checks give us a little bit more than that because they can provide a bit more context as to what is going on. For example, there is a difference between checking for existence of a KNOWN instance index, vs checking for existence against "noone". This can become quite common if you have deactivation, because an existence check returns false, however the value is still relevant as the instance may get reactivated later on. Similarly, "Maybe" types don't always work in those instances. Consider surfaces, it is common for a volatile surface to get unloaded mid-run. Optional type constructors in this case could still hold a valid surface ID, but would not be sufficient to verify the existence (or lack thereof) of the surface, without you having to perform that "surface_exists" check anyway. (Atleast not without spending more time creating a surface-specific maybe type which dynamically updates on each interaction, but this is obviously starting to distract from speedy programming, and leaning back towards spending time having to engineer in these design patterns).

Bear in mind, my comments here are also within the context of what GM is as a whole. If you had the opportunity to design it from the ground up, then sure, there are loads of ways you could improve it. But for what its worth, I think it is a better alternative to just having null, because it can also tell you why its null (i.e. whether the values themselves are invalid, or if the datastructure did exist and was destroyed), so it doesn't fall into all of the same traps. Sure it doesn't enforce anything, but it's serviceable. So I do standby what I say in that I think its a valuable habit to have and can lead developers down an easier path in the long run, avoiding buggy mess, or making assumptions about objects that are still referenced, but no longer used. (I'm just not a fan of languages like Java at all anymore :p)
 
G

Guest User

Guest
i don't really have any special attachment to Gamemaker, but i don't generally form attachments with tools in general.

GM is really one of the only engines atm that offers a simple-stupid scripting language, everything else uses a language i don't want to learn or a convoluted Drag'n'Drop system. if GM only offered DnD or C#/Python/Ruby then i'd really have no reason to use it.

that, and, GM isn't limited to outputting one particular type of game either.
 

OliverSB

Member
What I dislike the most about GameMaker is no named events. I like to work systematically so I sometimes route events when they need routing.
 

OliverSB

Member
i don't really have any special attachment to Gamemaker, but i don't generally form attachments with tools in general.

GM is really one of the only engines atm that offers a simple-stupid scripting language, everything else uses a language i don't want to learn or a convoluted Drag'n'Drop system. if GM only offered DnD or C#/Python/Ruby then i'd really have no reason to use it.

that, and, GM isn't limited to outputting one particular type of game either.
I got to admit some of the other drag and drop systems are really good. I for example think it's pretty good that you can perform operations every so many ticks with just a few clicks. In GameMaker we have alarms that you have to code to reset. Also, 'trigger once' is good in the event system. But for people who are more used to coding GameMaker probably works better. Suites me better anyway.

I am comparing GameMaker to Construct. They are two diff workflows.
 
T

Timze

Guest
It's approachable
Visually, organized quite well.
DND is also the best teacher i have ever had. Learned more in 1 week of using DnD -> GML than i ever did studying C#, JAVA, C++.
 
A

Arheddis Varkenjaab

Guest
Why Do People Love GameMaker So Much?
Odd question given this this the GameMaker forum.

Now ask 'Why Do People Love GameMaker So Much?' on the Unity, Unreal, and Cryengine forum's and you'll find the answers to be somewhat different.

Maybe you should do that. At least you would then be able to collate an overall unbiased opinion.
 
S

Sam (Deleted User)

Guest
I like how if I forget a semicolon it's not going to prevent my game from running. However, it would be nice if a warning for that was submitted to the compile form, it isn't a huge deal to me.
 
B

Binary Orange Studios

Guest
I actually despise GameMaker, but there are no other better alternatives for 2D tile-based pixel art games until Godot matures for another few years, so...
Godot is what originally took me away from GMS 1.4, and GMS 2 is what took me back from Godot (that and Godot's lack of simple features, such as sprite batching).

I've always liked using GM more, though, as it is amazingly fast to prototype ideas with. The tileset functionality alone is a big seller for me. I don't despise it, but I can understand why some people might (the licenses can add up quickly).
 

kburkhart84

Firehammer Games
The thing people don't know(or forget) about GML specifically is the fact that it is a true game-focused language. There is nothing there that isn't useful in a game(not all games use all of it of course). Using a "regular" programming language for scripting generally means that there may be stuff there you don't need, things like remembering where to put the "new" keyword in C#, and other things. GML as a language is really simple compared to the quirks of other languages, but(though it isn't feature-complete) it has pretty much all you need for actual game creation.

The thing about Gamemaker itself, is that in its niche, it is topdog. Technically, other programs have certain features that GM is lacking, like Unity have a fully functional free version, 3d in other engines, and certain 2d features based off the 3d side of things, but for tile based 2d games, I don't think there is any other piece of software/engine that does all the stuff Gamemaker does, does it nearly as well, and yet is really quick to develop in compared to other engines. Unity's is technically more powerful due to having the 3d side of things, but the 2d features don't compare, and that can be said about any other game engine really, unless you start discussing custom made engines, which won't have near the development speed that Gamemaker gives you.
 
What I dislike the most about GameMaker is no named events. I like to work systematically so I sometimes route events when they need routing.
Can't you name an event like:
///NAMED EVENT

Up at the top. Instead of //, you have 3 ///

If you mean like a built in variable, you can always...

event_name = "something"

Then:

Code:
event_found = -1;
with(all)
{
if(event_name == "howdy")
{
other.event_found = id;
break;
}
}
 
I like GMS because it's easy to use, mostly. But also because it is what I started learning with, and while at this point I could use any engine I wanted (and I will learn new engines just to broaden my experience), gamemaker is just so effecient at making 2D games that I don't think I'll ever stop making games in gamemaker entirely. It will always be my jamming engine at the least.
 
Last edited by a moderator:

Poitsutsu

Member
It's mostly easy to use. It's made so simple to learn and understand. First I was like: "Omg, what is this!?" but now I'm like: "What would be the next game I would develop" :D haha, Gamemaker is awesome!
 
The first thing I liked about GameMaker when I started using it was the logical workflow, aided by the layout of the resource tree.

1. Create Sprite using included sprite editor
2. Create Object and attach sprite to Object
3. Add some code to the object to make it do stuff
4. Make a Room
5. Put Object in Room

RUN GAME!!!

It just seemed a very nice workflow, plus I didn't have to write the lower level code for the engine, like initialising graphics cards, drawing pixels to the screen, creating collision code etc...

Secondly, while I've had a chance to learn about low-level implementation of a lot of engine features, GameMaker has a handy time-saving function for almost all gameplay situations.

Don't like trigonometry too much, well you can use lengthdir_x / lengthdir_y / point_distance / point_direction functions easily without having to worry about should you be using sin() / cos() / tan() etc... (Just one example of many)

If you want to do the dirty work yourself, you still can, all the necessary functions are included.

And finally the documentation was really well put together in my opinion, clear usage instructions and exceptions, plus small examples for every function that usually showed them in a game relevant usage context.
 
Overall its a great tool for 2D games after having tried most engines and GMS2 is more efficient & user friendly and caters to heavy coders and non-coders.

Right-brained / visual people or children who are discouraged by code, will discover the drag and drop features friendly and helpful.
Depending on the degree of creativity non-coders can produce good games with DnD as shown below..

 
F

Famine

Guest
I use it because it's very good for 2D games and that's really all I do these days is focus on 2D games. I think the engine is fast and easy to use for projects that target that genre of gaming compared to other authoring/engines on the market. It's also powerful in that regard too.
 

Surgeon_

Symbian Curator
Yeah, GameMaker is great at some things and terrible at others (other posters have covered this already so I won't go into details) but nobody seems to have mentioned the community, quality community support and friendliness that you can find here on GMC. Lately I've kind of neglected gamedev for programming other things and as useful as it may be, it's not as jolly without a fun community to get involved with...
 
F

Fikani

Guest
In my point of view, i like this tool too much, it is easy coding and can do anything, i started with a free version 4 years ago just for fun, this lead me to have a nice game on the play store now >>Strange Warrior<< with more than 10k+ installs and more than 100 rating 4.6 , i did all the game using Game maker alone and i am very thankful
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
To add to what's already said, the combination of flexible collision handling (place_meeting and co), epsilon, and strong determinism makes GameMaker and exceptional choice for fighting games and other types of games that benefit from synchronous networking or input-based replays.

This isn't a luxury you can usually enjoy unless you rolled your own engine (very time-consuming) or deterministic recreations of floating point math, collision checking, and component systems for an existing engine (time-consuming and either low performance or up to 5 digit licensing fees for getting source code access).
 

The-any-Key

Member
In my case there where two ways.
GameMaker or Construct.
Both cross platform (wich where the thing I was looking for in the first place.)
GameMaker seemed less restricted compared to Construct when it comes to what game you can create with it. Glad I choosed GameMaker. Because construct is now under a monthly pay plan wich I don't like.
 
I'm not a terribly prolific programmer, but Game Maker has been a decent introduction so far. Oh, and as others have said, the community is pretty helpful.
 
Y

Yotzer

Guest
The first thing I liked about GameMaker when I started using it was the logical workflow, aided by the layout of the resource tree.

1. Create Sprite using included sprite editor
2. Create Object and attach sprite to Object
3. Add some code to the object to make it do stuff
4. Make a Room
5. Put Object in Room

RUN GAME!!!

It just seemed a very nice workflow, plus I didn't have to write the lower level code for the engine, like initialising graphics cards, drawing pixels to the screen, creating collision code etc...

Secondly, while I've had a chance to learn about low-level implementation of a lot of engine features, GameMaker has a handy time-saving function for almost all gameplay situations.

Don't like trigonometry too much, well you can use lengthdir_x / lengthdir_y / point_distance / point_direction functions easily without having to worry about should you be using sin() / cos() / tan() etc... (Just one example of many)

If you want to do the dirty work yourself, you still can, all the necessary functions are included.

And finally the documentation was really well put together in my opinion, clear usage instructions and exceptions, plus small examples for every function that usually showed them in a game relevant usage context.
^^^what he said^^^ + I was looking for a simple way to make games without learning code and did not like the other engines that offer that because they were only for simple stupid games/or generic (rpg maker for example) or it was in fact coding in disguise + when I was looking for tutorials ,I found more in quantity and quality for gms (specially Shaun Spalding tuts ) and the free version was time unlimited ,enough to make me fall in love with it.
 
T

tafkatfos

Guest
Just suited my work flow, and it's great for 2D games, which is what I make.
 

Distronaut

Member
GM (and Unity) are really good for casual developers with limited time & resources who just want to explore the fun aspects of developing games. Game Maker has always yielded some really impressive creations by ambitious users, so this has continuously inspired me to keep using it (only a bad dev blames the tools!)
 
D

drjeffreye8

Guest
Yeah, it would be nice if a warning for that was submitted to the compile form, it isn't a huge deal to me.
 

Maximiliano

Member
I like game maker because it was the software that got me interested in programming and making games over 10 years ago. I'm used to using it even coming back to it after all this time. I've seen it improve a lot and the community is pretty great.
 

Hyomoto

Member
Game Maker is interesting because it allows you to largely write functional code. In many ways you can start by just writing down what your game should be doing. But, if you so choose, it's also possible to dig a bit deeper into it and move beyond that. In many ways I just like it because it's comfortable. Working in Unity feels like a test of patience for me, and building stuff from scratch in C++ ( while entertaining for it's own reasons ) requires a lot of code before you can even begin to think about your game. But in GM, if you have an idea you can have a prototype up and running and _functional_ quite quickly.

It's hardly perfect, and much of what I say about it people will feel about their own preferred tool sets, so some of my praise does come from familiarity. I know a lot about GM, but I have to dig through the manual and tutorials in Unity. And even then I'll only get about 20% out of it. Plus, and this is just a personal thing, I think Unity is perhaps a little too wide of a net. It's pretty easy to spend as much time configuring and optimizing Unity as it you spent designing and building your game. GM is obviously quite a bit simpler, but it does wash a lot of the technical stuff away for 90% of all users and your game will still run as expected.
 

GMWolf

aka fel666
GML has many shortcomings.
However, I think it serves its purpose pretty well for most games I'm interested in (designing them quickly without worrying about implementing common functionalities such as drawing things).
So what you like is the engine. Not the language.

The draw_sprite, etc functions are not part of GML. They are part of the engine.

I like(d?) GM because of the engine. The object system and event system is decent, and drawing stuff ois easy. Yet, it exposes enough low level access to do what you need.

But god is GML a poor language. Without classes, structures, and only rudimentary data structures, I find myself spending more time implementing what I need, than just building my own renderer (which I resolved to do, and enjoy all of c++ and the libraries that come with).
The extra effort needed to deal with all of GMLs shortcoming every time is far greater than the extra effort needed to implement a renderer. Even with batching, etc.

Tl;Dr
I kept coming back to GM for the engine. But now that I can make one that suites my needs a lot better, I only come back to GM for making videos, but as I don't really use it any longer, I don't really have anything to make videos about.
 

breakmt

Member
I used to make game with LibGDX, but I always found myself over-engineering everything. I tried to make clean code in Java but every time it became a mess after 1-2 months. I didn't see much progress and I lost interest in development...

One thing I realized that I always did something like level editor and in this editor I tried to implement simple script logic. Of course, it was not that good and heavy to develop. Also I wasted too much time with it, not for a game.

One day I realized that I did it wrong. Why make own editor if I can use GameMaker? It has all I need - level editor, script editor, sprite editor (which I like) etc. I made a simple game in 3 months and it was surprisingly nice experience.

I have several wishes for GML and IDE... But even without them I think GM fit my needs.
 
J

japreja

Guest
I've been using GameMaker since version 3.?? (non studio) way before Mark Overmars started charging for the system in version 4 or 5, I eventually bought GM 7 and have been using it ever since. I put it all away after finding he sold it. But have recently come back to using it again. It is just fun to work with.
 
T

ThePandaSenpai

Guest
I started using GMS1.4 about 2 years ago. I knew nothing about programming. It opened up the door to me to several other languages.
I've tried using other engines but I just don't feel at home the way I do with GMS. ><
 
R

ramses

Guest
I used GM from around the launch of 7 up until Studio came out. To this day I think it was the way to build a quick and dirty mock up for absolutely any idea that crossed my mind. In the gaming context it provides all the bare necessities of a proper game engine, blended in a scripting language that handles "all of it", from graphics, sound or mechanics to system operations, all this without being heavily bloated. I'm looking at you, Unreal. And it now seems to have a rather wide cross cross platform deploy, which is nice.

GML's simplified C-ish syntax makes it easier to transition to other languages. I for one started with C++ and naturally it was not so fun. Picking up GML was a breath of fresh air, as you get to see results immediately.

The idea is not to put it in the wrong context. GM is a middle zone; it doesn't go any extreme lengths for complexity in some direction and at the same time it tries to cover all needs.

Also the debugger was pretty straight forward.
 
L

lynn0408

Guest
I don't think there is any other piece of software/engine that does all the stuff Gamemaker does, does it nearly as well, and yet is really quick to develop in compared to other engines.
 
F

flambastic

Guest
The fact that I've been using it for years and years and I can easily port my game to other platforms with little struggle.
 
F

Falconsoft-Industries

Guest
The language is easy and fun but can be confusing and challenging after a while but if you study hard and practice it you will get better, just don’t expect to be a pro at it overnight. Hehehehe I myself am only average at it.
 
S

sofaspartan

Guest
For me, it was definitely the ease of use and how quickly you could make something with little coding knowledge.
 
What is it that attracts the userbase so much. From my understanding and my opinion, its a powerful engine for creating 2D games. With great tools integrated.

What specifically keeps people coming back to GameMaker?

From my understanding, people like the way it abstracts you to focus on coding your game.

I've always wondered, is GML something people love about GameMaker? I am assuming there is reason why GameMaker was created with its own custom scripting language.

Is it because people love being able to use 'with' statements or referencing object instances by the object name?

Is there any benefits to using a programming language with a integer ID based system?

Is there any benefit to referencing arguments using 'argument0', 'argument1', etc compared to other ways of dealing with arguments?

Is there any benefit to only being able to globally reference scripts?
it was free to start and use 1.4 plus hotline miami was made using it otherwise i would have stuck with UE3 to 4
 
Top