1. Thou shalt read the manual and seek guidance within before asking others. @1:16 2. Thou shalt not use Drag and Drop. @2:26 3. Thou shalt manage thy white space. @3:25 4. Thou shalt name thy variables descriptively and consistently. @4:10 5. Thou shalt not use persistent rooms. @5:05 6. Thou shalt not use the physics engine if your game does not require a physics simulation. @6:09 7. Thou shalt not make thy pixel art game any larger than 960 x 540 @6:47 8. Thou shalt not use Object Following for your game's camera. @7:40 9. Thou shalt use double equals (==) when comparing values. @8:27 10. Thou shalt not use 1 in place of True nor 0 in place of False. @9:22 11. Thou shalt not use magic numbers. @10:19 12. Thou shalt not use the "self" keyword. @12:15 13. Thou shalt not preemptively worry about performance issues. @13:13 14. Thou shalt not use the "Solid" checkbox, nor the associated scripts. @14:04 15. Thou shalt use the Draw GUI event to draw things relative to your game window. @15:05
I've basically picked up on all of these tips already as i've been doing GMS2 tutorials throughout the years but its nice to have them refreshed when I come back. Also: "Write your code as if you're writing it for someone else" is probably the most important commandment of all.
Good list, but missed one of the most important ones. THOU SHALT COMMENT YOUR CODE!! In 6 months... all code was written by someone else. you'll need it.
Ha, almost every code block in my game has at least a few comments. And if I don't need an entire block, I copy it to some event I'm not using for anything and comment out the WHOLE thing with /*. Trust me, being able to look at older problems can help at later points.
Agree that code must be commented; I once came back to my code after a week and my first thought was 'who wrote this crap??', and I had written it with no comments :( Took me 20 minutes to comment it all before I could start to add to it
"No! BAD programmer." ha I've learned really great things, especially with variables name, magic numbers and 1 in place of True; all regarding code readability. Not a surprise I have a problem understanding my code 1 week later. :x “Write your code for someone else, because in 4 months, you’ll be someone else!” So many things I see other programmers doing in other videos but I didn't know why, now I do. Thanks a lot.
Ha. Well done. I do think it says something that you are the first person to point out that solid actually isn't that complicated, just most beginners don't fully understand how it works and then can't make it work exactly as they want. Still solid advice to avoid it (ha).
ive been programming for YEARS and felt great about each commandment... until the last one. I cant believe draw GUI is a thing! I actually learned something it feels so good
Great tips, I would also add when reading the documentation pay special attention to the return value of a function. A lot of times the return value of a function will tell you a lot without having to read too much.
Eary on in my learning of GML someone told me to never use self but didn't say why, and I later learned that self and id were the same thing and assumed I should never use id either 😅
Doing right now : 1, 2, 3, 4, 5, 9, 10, Oh crap I've been thinking of doing this, time to delete the thought from existence : 6 Noted : 7, 8, 11, 14, 15 What even is that : 12, 13 I am new. This is helpful. Thank you Pope. Have a nice day.
Great video. Luckily I've had good standards for GM and coding in general so none of these really applied, however the part with how to calculate a proper aspect ratio was the gem in the video for me. Thanks!
16. Adjust the origin points of collision masks or get ready for physics headaches later on. 17. Use switch statements when dealing with more than two states or functions that must be run independently.
This is golden advice, plenty of which I've heard echo across searches and inquiries. Thank you for this solid advice. What's new to me is certainly helpful. I will certainly refer back to this lesson in the future.
These are really great tips. I follow most of these suggestments, but all of them will help me with Coding in GM. This video was a great help and real excited on what other topics you will cover in the near future.
Agreed with everything up until the part when you said to ignore optimization when coding until it becomes a problem. If your performance issues are a culmination of a series of choices you made each with minor negative effects on the performance of your game, you would have to go back and completely refactor everything. Shouldn't you always strive to find the most optimal solution to a problem that won't create issues down the line?
This is an old programming adage, and the gist of it is, if you don't know what performance issues you have, it's quite possible your optimizations will make the code have WORSE performance than if you didn't optimize it - there's often not an actual "best" way to do things, but tradeoffs on different axes like "speed vs memory use", and generally optimizations make your code more complex which makes it harder to change it later. (Even if you don't make your code worse, you can still waste your time if you optimize things that already have a negligible impact on performance - a 5% save in an object you have hundreds of instances of in each room will save more performance overall than a 90% save in an object you only have one of)
I agree with you, the only two making drag and drop tutorials are Shaun Spalding and Sparckman, so I'm afraid starting a project, what if I get stuck. Shaun only made about 6 of those and sparckman is so unpredictable you don't know what he's going to make next. I like dnd but is still too new.
Sprained my neck from nodding so much. Wanted to add a couple that would've helped me had I started with them. XVI: Though shalt differentiate your instance (member) variable naming scheme from your local variable naming scheme. Personally I use m_ to differentiate my member variables from local variables. Based on a couple of your code examples, it looked like you use _ to differentiate your local variables from your instance variables. Both are good and serve a noble purpose. XVII: Though shalt provide API scripts for Objects that have publicly-accessible variables or capabilities. This has been an absolute lifesaver when working on collaborative projects or old code. Instead of having to remember instance variables that don't get put into intellisense, you provide a script named _ Ex: Player_GetHealth(playerID). This also makes it much easier to change the inner-workings of your objects without breaking a bunch of other code that uses them. XXVIII: Though shalt use resource naming schemes for large projects. This may be the most subjective thing on my list but naming-schemes can really save your bacon when having to manage a large project and open the door to some interesting extensibility options. Say you have a base object that has different sprites associated with different movement states (I.E. standing, running, jumping, etc) and you're going to be creating a bunch of objects that inherit from this base object. Using resource naming would save you from having to create code that individually sets all of these resources in code. Ex: For an Object named Player, create sprites named PlayerMovementStand, PlayerMovementRun, PlayerMovementJump, etc. and have your base code discover these resources programatically according to your naming scheme using asset_get_index
As someone whose highschool programming teacher herself learned to code in the '70s, and required all of us to write our BASIC code on paper first before even sitting down in front of a screen, unlearning the preconsideration of code efficiency is obnoxiously difficult. I would love to be free of worrying whether I'm bogging gamemaker down and setting some sort of critical system up for catastrophic failure by forcing it to evaluate a string rather than utilizing an integer.
About commandment 10: I only ever use the numeric interpretations of booleans for multiplication. That can be quite convenient, as it can save an if-block. I mean stuff like "speed *= 2 * ultra_fast_mode", where ultra_fast_mode is a boolean variable.
I find persistent rooms can be OK for implementing a pause menu in a separate room (in which case you'd turn on persistency before leaving the room and turn it off after you return), but there's indeed a LOT of weird quirks with them that take extra work to get around. For instance, the Room Start Event triggers if you re-enter a persistent room, so you'd better not use it for any initialization code that's only meant to be run once! Also, if you turn off persistency in a different room from the current, you don't delete the stored state, so you need to re-enter and leave the room while it's un-persistent to actually reset it! For something more complex like an RPG overworld these quirks stack up way too high to be worth the effort working around.
This video was helpful and funny as hell. Please make another I'm sure you could come up with at least another10. I was pleased with myself because I picked these things up naturally. There were only one or two things I had not thought of.
Nice video and I agree with all including Mike's commenting code. I would also add "magic strings" to this list for several reasons including localization, enums for easily identifying array indexes and #macro for game wide constants.
This video didn't really helped me because i have some experience with game maker and knew most of the commandments, but it is so well done that i watched it to the very end! Congrats! Amazing video! I'm proud of you!
As someone who is relatively new to GM, these seem like great tips, but a few things about GM confuses me at times. Before trying out GM, I've messed with several engines- Unity, Godot, Construct 2, etc.... It seems weird how in GM, it has built in physics, yet it's advised by every veteran GM user to avoid it at all costs, where in Unity and Godot, the built in physics are awesome. As a novice in GM, it comes across that GM is broken software that has to be navigated by custom means, because using built in tools will break your game or something. Secondly, I don't get the hate directed towards Drag n Drop by veteran GM users. To me, DnD seems way faster than GML, plus easier on my eyes. One can still code in it if need be. One can preview what the code looks like. One can also convert it to code later on. For veterans who've been using GML for years, DnD probably isn't attractive, but I personally find it a better way to understand GMs approach to creating things. I've read a lot of the GM manual, but IMO, it's a bit to much of a dry read. People who ask advise on the forums simply want their questions answered in layman's terms.
Thanks for clearing up the physics thing. In regards to DnD, I see your point, but I'm more of an artist than I am a coder. Visually memorizing the icons connects easier to me than memorizing lines of code. Why type out a chunk of code when you can simply drag over one window and plug the values in it? It's just way faster to get the same results coding gives, which gives me more time to focus on my art. For things where detailed coding feels more necessary, simply drag over the execute code window and type in the GML. I find DnD more fun to use. DnD is kind of like playing a puzzle game, where coding is more scrutinizing my screen for that one typo. I'm not an expert by any means at coding, but I'm not a complete noob either. I'm pretty convinced that going into the future, things like DnD are going to get more common, more cleaner, and advanced as future engines come out. It's just the evolution of things.
I liked DnD a lot when I first started because it I started coding using RPG Maker Engines. It was similar to what I was used to at the time. But the more I used gamemaker, the speed at which I could type was faster than mouse clicking and it made changing things faster and easier (especially when debigging). I think DnD is a good stepping stone when starting out, especially because you cant do everything with it, so it forces you to learn raw gml. BTW, I'm aware RPG maker has RGSS, but I never really needed to learn it at the time. Although I wish I had as the things I was doing would have been much more optimized in RGSS.
Also, side note on single vs double equals - in a lot of languages with this distinction, an expression that sets a variable to a new value will also evaluate to that new value. This is often used as a shortcut for return values, Python, Bash and Matlab all will use whatever was the last value of a command in a function as the return value if there's no explicit return value for instance. So a single-equals comparison would first update the variable, then check if the new value is boolean true. Almost nobody does this kind of thing, but C (a major inspiration of a lot of later languages, including GML) is a language from a time where stupid hacks was the only way you could make programs fit in your floppies / CPUs and it just absolutely revels in them. There's even the trigraphs, a relic from the era when not all computers supported the ASCII character set, so you needed escape codes for common symbols! And don't get me started on all the problems C-strings (null-terminated byte arrays) have caused.
I'm glad to see that I figured most of these out for myself. Sadly I've been working on my first major solo game project for 8 months, and have learned a lot of this in the process, so the game has a lot of crap like this, but my next project will be much cleaner. I cannot get myself to use == on the go. I'll be banging out code all day, and then realize I didn't do it. :-/
About not using persistent rooms, the same can be said for any other built-in feature of the GM engine. People also will say to avoid things like the Solid property, and the built-it speed variables. So then why use the engine at all? Why not code everything from scratch, right down to the metal? The better way to think of it this commandment is **"Don't use features in the engine that you don't understand well enough to use."** Whatever features of the engine that you make use of, inevitably you're going to discover that you didn't fully understand it, and this lack of total understanding has just resulted in some weird, undesirable behavior. At that point, you have a choice: delve and seek to find the deeper understanding and work with that engine feature, or eschew the engine and build your own system entirely from scratch. Both are valuable learning opportunities, and valid approaches, and depending on what you want to do, each approach may be better/easier for a given problem.
That's a good point. I suppose I picked solid and persistent rooms to single out as they feel like the biggest "sledgehammers" that newer users tend to use. They don't want their player to run into walls so they set the walls as solid and it seems to work... until it doesn't. Same with persistent rooms, they want to keep one thing about that room the same when they transition to their menu screen or something, and they don't really realize everything else that is going to be affected because that room is now persistent. then they try to enable and disable it dynamically... and it just becomes a mess. But, I agree with you: I could have condensed about 4 or 5 of these commandments into 1: "If you don't understand it, don't use it" commandment. I suppose that's why I've sort of pulled away from making videos and moved exclusively into helping people on the forums and chat rooms. Once you make a video, it's there forever, and any mistakes stay there with it. Learn a better way to do or teach something? Make a new video and hope someone finds that instead of the old one... ¯\_(ツ)_/¯ Sorry for the mini-rant. Thanks for your comment and for watching!
I thought of another good one! Use ; at the end of every line of code. To be clear, that is: ; ^That thing. It ends the line of code you're writing, it may not sound important, but there are several instances where you can get undesirable results from not ending your line. Obviously you don't use those just after an IF statement or whatever, and definitely not after a curly bracket like } or {, but most other lines should have a semi colon at the end. Trust me it's a good habit to get into, you'll be glad you did.
I'm pretty new to GML, but I've done a lot of programming in other languages. I've gotta give you major props for #4. My instructor at University taught me of this practice and I stick with it to this day, even though other people think I'm mad. As a guy with some programming experience, I found the stuff pertinent to Game Maker's built-in features to be the most helpful. Particularly, #5, #8 and #12 strike me as some awful temptations that could lead to bad habits if not avoided outright from the beginning. Lastly, I've been interested in some of your other creations, and was wondering if you had examples of some very specific things I've seen in your projects -- namely the ALttP-styled textbox and scrolling. I had some idea of what to do for the former, but the tutorials I've followed use actual text; I'm pretty sure one would want to draw characters to some buffer space ahead of time, and then update the Y offset in a loop for that "scrolling out of existence" effect between dialogue prompts. The latter question, I don't think I'm ready to implement just yet, but I'd like a good framework to work within so I'm not trying to reinvent the wheel. Sorry to bring these off-topic questions up here, but I'm not sure of the best avenue to get ahold of you. Tried Twitter once, but I think I just suck at Twitter.
Hey, I suck at Twitter, too. Best way to get a hold of me is through Discord. You can join my discord server which has lots of awesome people on it who can help with almost any issue you might have. discord.gg/4jhvWp As for the Zelda thing... nope, it's pretty much what the tutorials will tell you to do. I print a temp copy of the string with a limited number of characters out to the screen. No need to get buffers involved. You are welcome to comb through the project if you'd like, but it's been awhile since I've even looked at it, so I may not be able to answer all questions. www.dropbox.com/s/6ijcn0xqtkm81oo/Zelda1.gmz?dl=0
Its fun to see this after a year and 2 month since I got GMS2 and also started learning about programming from knowing nothing except "variable are those things you declare in which you store data that can vary" xD Its like watching a summary of what experience made me learn and of course tutorials (Pixelated Pope included, regarding views). Still I wanna point out, I think knowing how things work "under the hood" is SO important. Not letting yourself have code that seems to work magicly or following a tutorial in order to reach a result without really having understand how things work even if you reach the result you expected. Gotta say, simultaneously with GML I also started learning Java (later also Android). And took me some months to realize, wow at least the programming languages I studied are essencially the same thing. And to the purpose of knowing how some things work under the hood its really helpful to know more than 1 programming language. And if you are interested in how hardwares work (in depth) even better. It may sound like a joke, but I had no idea about most of these things at first 😅 Anyway, great old video.
Only thing this is missing: Thou shalt pick your resolution ahead of time... Coupled with my sinful use of magic numbers, I spent several hours yesterday changing my game's resolution to more suit my needs. Old or not, this video helps a lot. :D
360*640,180*320 and 90*160 all scale evenly to both 720p and 1080p. Most people have a 1080p display but you may as well use one of those resolutions if you can.
You are correct. Apparently the screenshot I found was from a very early build... but I think the basic idea is still communicated well even if I wasn't completely accurate. Thanks for watching!
another thing I would recommend would be to add a semicolon to the end of every line that doesn't end with a bracket, and comment your code. Comments can help you understand what your code does and semicolons help to show the end of a line. I instinctively hit that key before hitting enter on any line of code. I also used drag and drop to start out the code to give me a good base to start from, I also used it to help me get an understanding with how to for sure get an object to follow my mouse.
13:13 I'm super guilty of this one, really good advice to follow lol I tend to get so hung up on one little data structure and how I think the most optimal way to code/use it is that it'll take me a whole day just to figure it out
@@KryptKicker5 I mean a little pedantic, but still thank you for the book recommendation :) I was only giving the one example of data structures, but I fully understand where the video's coming from about getting hung up on overthinking the small stuff. Sure, it's great to know what you want to use ahead of time, but there aren't many in this world that will know the _exact_ answer right from the get-go, so 9/10 it's better to get something down in code first and then revisit that to better optimize it. Same thing goes for anything circuitry related, you build a spaghetti prototype first just to make sure it works, and then you optimize and compact it from there.
TY for the premature optimization tip. So many people obsess about this and it’s usually not even a factor. Similar with writing obfuscated “tight” code on a first pass. It’s okay if your snippet takes five lines to lay things out clearly instead of being scrunched up into a line or two. Tighten it later, after you know it’s working and why. I fall for this myself sometimes and have to take a pause to remember that clarity is paramount.
Great tips! - Many thanks, I'd started using "Self" - and wondered whether I should be using ID or Self - question answered! (along with a lot more... :D )
About self. It was recently -ish changed to be the same as id (which means my trick on passing self around to refer to the final executing instance no longer works :( Never the less, self is still bad form...
14:51 actually from my experience it just keeps any non-solid object from going into the x,y of the solid object And yes you can still modify what happens when the object collide even though you checked solid Its pretty much making your object a brick wall, The only problem I see is the collision event fires early And somethings you want to pass through it wont And sometimes two solid objects ignore eachother being solid but I think thats a bug
What happens is when you collide with a solid object, the object is moved back to xprevious and yprevious. So this means it's more difficult to get your object to get right up against the solid object.
I took "Thou shalt read the manual and seek guidance within before asking others." to mean Google it/try to figure out for yourself, and only ask for help if you've got no where else to turn. As a novice, I haven't found the manual to be very helpful. For me, it's like trying to learn Russian by reading an English to Russian dictionary - you get definitions, but rarely any kind of useful context. I feel like it's written for intermediate programmers who are trying to understand the syntax of GML, and not absolute beginners trying to understand how to do something. I think before attempting GML, a better place to start would be a programming course. Although a bit dated, John Janetka's Game Programming Course (GPC) is the best I've found for absolute beginners like myself.
Can you help point me in the direction of a tutorial for creating a camera that doesn't use the "object following" feature, as detailed in commandment 8? I'm having a bit of trouble finding one. Edit: I'm using Game Maker 1.X.
It's very very easy in GM 1.4. Basically just position your view x and view y. I usually do it like this: view_xview[0]= target.x - view_wview[0]/2; view_yview[0]=target.y-view_hview[0]/2; //Keep the camera in the room view_xview[0]=clamp(view_xview[0],0,room_width-view_wview[0]); view_yview[0]=clamp(view_yview[0],0,room_height-view_hview[0]);
Yup! That's the most basic of camera systems. But the principal is the core of any camera system. You have to center the camera on some point, and you can use any logic you want to decide what that point is.
I'm so glad I came across this video now so I learn my GML the right way. When you say don't use physics your not saying don't use collision boxes right. Your saying don't use the physics [Tick]. And I shall now go to your camera view tutorial so I never use camera follow [Tick] again.
I've got a new camera tutorial coming really soon! For now, here's a text version to help you get started. docs.google.com/document/d/1l_8HmdPMwAhYd8YQXJTkT-5acmsdEp0BBJgfwsusuZE/edit?usp=sharing
Now, this video is getting a bit old... There is actually ONE place you can use self and it's the "right" answer. And that's when inside of a constructor.
@@PixelatedPope What about collisions? self and other? I have passed in id and reference it as _id in a parent constructor and that seems to work well.
@@Ragnark1 inside collision events it's just other.id. You used to be able to just say "other" but recently other was changed so you have to use other.id.
@@PixelatedPope One other question: a global variable controlling focus of a user control in Game Maker -- should it be global.control_with_mouse_over_focus = noone; or global.control_with_mouse_over_focus = undefined; ?
The whole 'black box' idea is one of the reasons I've struggled with Godot. EVERYTHING feels like a black box in Godot, and when you need to do something outside of what the engine does by default, it gets a lot more complex than gamemaker. It's totally possible, but it feels like you end up spending a lot more time reading docs than with GM, and at this point, I've used Godot longer than Gamemaker, but GM is still easier to use. Gamemaker almost feels closer to a game framework/library like raylib or monogame than godot does.
For part 2, why not just choose Drag n Drop when creating a new project. You can always use GML with the "Execute Code" tool in the toolbox. It just provides you both options in reality.
The code readability parts of this were covered in Robert Martin's "Clean Code" book. Very, very good and entertaining book. I recommend with all my heart (no pun intended). Interestingly, the main theme of the book is "only comment your code when it's unavoidable":-D Because if your code needs comments, that means it's badly written.
When I started with game maker, I jumped right into GML, because I was already familliar with other programming languages, like python and java, and it was also easier to understand things faster, because I was already familliar with other game engines too and programming in general.
I agree with everything, but the GUI event thing. problem is you can't keep track of the GUI event surface and since its works differently than draw event, its kinda boring to make it works as you want sometime (specially when you make a pixel-art game and want to stretch, windowed, fullscreen..). I'd say as long as you dont suffer performance issue, its better to go with a custom GUI system. IE. a "GUI suface" drawn after everything, following the camera or whatever. I feel like this gives you much more control over what's happening
right so tell me how I can recode move_contact_solid(point_direction(x,y,mouse_x,mouse_y),lerp(0,point_distance(x,y,mouse_x,mouse_y),0.2)); there's no other code I've yet found that checks in every direction and when I tried doing it myself with place_meeting*4 it didn't even work then.
Solid is not necessary for ANYTHING. All solid really does is move you back to xprevious and yprevious if you collide with something that is solid. So move contact solid is just a while loop that moves you towards something until you are just about to collide with it. It can be replaced with the following code: pastebin.com/YL8z8e9k Is that a lot more code? Yes. Absolutely. But you now have absolute control over how your collisions are handled. It's up to you whether that's something you need or not. Like I said, these are all just suggestions, and you can definitely make a game while using "solid". But don't think that there's no way to duplicate solid's functionality, because there always is, and by duplicating it you'll gain much more control over your games lower level functions. Thanks for watching!
that new intro...hot damn! I didnt like how long the animation/voice over took to say what was the next tip/piece of advice. Overall the video was good though, i liked it.
Ok, I work primarily in 16x16, but what if my game's art style is made using adobe animate or other software to draw in? It ha vector imaging and would most definitely be more than 960x540. Would that work? I'm a beginner in this, so take what I ask with a grain of salt.
I'm in high school and we're making a game in GameMaker but the teacher required us to make it in Drag and Drop, so I created a drag and drop project and only use code blocks.
1. Thou shalt read the manual and seek guidance within before asking others. @1:16
2. Thou shalt not use Drag and Drop. @2:26
3. Thou shalt manage thy white space. @3:25
4. Thou shalt name thy variables descriptively and consistently. @4:10
5. Thou shalt not use persistent rooms. @5:05
6. Thou shalt not use the physics engine if your game does not require a physics simulation. @6:09
7. Thou shalt not make thy pixel art game any larger than 960 x 540 @6:47
8. Thou shalt not use Object Following for your game's camera. @7:40
9. Thou shalt use double equals (==) when comparing values. @8:27
10. Thou shalt not use 1 in place of True nor 0 in place of False. @9:22
11. Thou shalt not use magic numbers. @10:19
12. Thou shalt not use the "self" keyword. @12:15
13. Thou shalt not preemptively worry about performance issues. @13:13
14. Thou shalt not use the "Solid" checkbox, nor the associated scripts. @14:04
15. Thou shalt use the Draw GUI event to draw things relative to your game window. @15:05
I've basically picked up on all of these tips already as i've been doing GMS2 tutorials throughout the years but its nice to have them refreshed when I come back.
Also: "Write your code as if you're writing it for someone else" is probably the most important commandment of all.
Good list, but missed one of the most important ones.
THOU SHALT COMMENT YOUR CODE!!
In 6 months... all code was written by someone else. you'll need it.
Thanks, Mike! I cover commenting a bit in my readability blog post I link, but you're right; should have given it some air time.
Ha, almost every code block in my game has at least a few comments. And if I don't need an entire block, I copy it to some event I'm not using for anything and comment out the WHOLE thing with /*. Trust me, being able to look at older problems can help at later points.
I never comment lol is it a problem?
Agree that code must be commented; I once came back to my code after a week and my first thought was 'who wrote this crap??', and I had written it with no comments :(
Took me 20 minutes to comment it all before I could start to add to it
I comment on every line. and then some. Probably over zealous but It makes me happy.
"No! BAD programmer." ha
I've learned really great things, especially with variables name, magic numbers and 1 in place of True; all regarding code readability. Not a surprise I have a problem understanding my code 1 week later. :x
“Write your code for someone else, because in 4 months, you’ll be someone else!”
So many things I see other programmers doing in other videos but I didn't know why, now I do.
Thanks a lot.
I'm sinless and get into the Game maker paradise
And you'll get 70 virgin gamergrills to play your games lmao
As am I, all thanks to Shaun
Solid puts the object back at its position before the collision.
Black box demystified through the help of Commandment 1.
:P
Ha. Well done. I do think it says something that you are the first person to point out that solid actually isn't that complicated, just most beginners don't fully understand how it works and then can't make it work exactly as they want. Still solid advice to avoid it (ha).
*"Still solid advice to avoid it"*
I see what you did there.
ive been programming for YEARS and felt great about each commandment... until the last one. I cant believe draw GUI is a thing! I actually learned something it feels so good
The only thing i learned was that there is a function called draw_roundrect ;/
I am satisfied with it ;/
Great tips, I would also add when reading the documentation pay special attention to the return value of a function. A lot of times the return value of a function will tell you a lot without having to read too much.
Eary on in my learning of GML someone told me to never use self but didn't say why, and I later learned that self and id were the same thing and assumed I should never use id either 😅
"thou shall not use the physics engine if your game does not require a physics simulation"
Take note, /r/gamemaker :P
tbh that applies to all engines
So nice to see some GameMaker specific content like this. Nice job. Really appreciated the resolution tip. 👌
Glad to see another video of yours. I was worried you had stopped making videos. Well done!
Took a long break (got addicted to FFXIV...), but I'm back and got several more planned that I hopefully can get out pretty soon!
Doing right now : 1, 2, 3, 4, 5, 9, 10,
Oh crap I've been thinking of doing this, time to delete the thought from existence : 6
Noted : 7, 8, 11, 14, 15
What even is that : 12, 13
I am new.
This is helpful.
Thank you Pope.
Have a nice day.
Great video. Luckily I've had good standards for GM and coding in general so none of these really applied, however the part with how to calculate a proper aspect ratio was the gem in the video for me. Thanks!
this guy deserves more subs
*guey
16. Adjust the origin points of collision masks or get ready for physics headaches later on.
17. Use switch statements when dealing with more than two states or functions that must be run independently.
About to dip my toes in Game Maker. I feel like these commandments are going to come in handy.
Thank you for giving an “instead do this”. Too many saying not to do something with no alternative explanation
So......is multiplying by 0.5 or dividing by 2 faster? xD
"Technically" multiplying. But that hasn't been a real concern for probably 20 years. On a modern system there will be no significant difference.
Bit shifting right by 1 is fastest, lol
@@zacharychristy8928 How's that work for floating point? You integer purists can't handle the real world!
@@PixelatedPope on a good compiler i assume it to be optimized during build
@@sephirothbahamut245 I would hope so.
This is golden advice, plenty of which I've heard echo across searches and inquiries. Thank you for this solid advice. What's new to me is certainly helpful. I will certainly refer back to this lesson in the future.
These are really great tips. I follow most of these suggestments, but all of them will help me with Coding in GM. This video was a great help and real excited on what other topics you will cover in the near future.
Draw Goey event
the gooiest of gui's
gooey
i haven't watched the whole video yet, just had to stop and give props for that awesome character art animation. ok back to the video.
Intro by Flekcter: ua-cam.com/channels/tDSW3BN6tek9gyehelEsnQ.html
Character art by @Rathaelos: twitter.com/rathaelos
Is this a personal attack or something? Nice video mate, insightful.
Agreed with everything up until the part when you said to ignore optimization when coding until it becomes a problem. If your performance issues are a culmination of a series of choices you made each with minor negative effects on the performance of your game, you would have to go back and completely refactor everything. Shouldn't you always strive to find the most optimal solution to a problem that won't create issues down the line?
This is an old programming adage, and the gist of it is, if you don't know what performance issues you have, it's quite possible your optimizations will make the code have WORSE performance than if you didn't optimize it - there's often not an actual "best" way to do things, but tradeoffs on different axes like "speed vs memory use", and generally optimizations make your code more complex which makes it harder to change it later. (Even if you don't make your code worse, you can still waste your time if you optimize things that already have a negligible impact on performance - a 5% save in an object you have hundreds of instances of in each room will save more performance overall than a 90% save in an object you only have one of)
Ha! I thought "self" and "id" were the same thing for, well, probably years now. Thanks for this!
As of the latest revision, I believe they actually are. They must have watched this video lol
Cant thank you enough for this! I wish you could make more videos about Gamemaker, you are one of the bigs out there.
Took a long break but have a lot of topics lined up. Hopefully I'll get the next one out sooner rather than later.
I agree with you, the only two making drag and drop tutorials are Shaun Spalding and Sparckman, so I'm afraid starting a project, what if I get stuck. Shaun only made about 6 of those and sparckman is so unpredictable you don't know what he's going to make next. I like dnd but is still too new.
wow... dont tell me you dont know "*hearbeast*" he studied GML for 11 Years! check his channel
And Shaun Spalding! My two personal heroes.
great tips. I'm using Unity, and most of this apply to it too.
UndeadSoldierE get out
Sprained my neck from nodding so much. Wanted to add a couple that would've helped me had I started with them.
XVI: Though shalt differentiate your instance (member) variable naming scheme from your local variable naming scheme.
Personally I use m_ to differentiate my member variables from local variables. Based on a couple of your code examples, it looked like you use _ to differentiate your local variables from your instance variables. Both are good and serve a noble purpose.
XVII: Though shalt provide API scripts for Objects that have publicly-accessible variables or capabilities.
This has been an absolute lifesaver when working on collaborative projects or old code. Instead of having to remember instance variables that don't get put into intellisense, you provide a script named _ Ex: Player_GetHealth(playerID). This also makes it much easier to change the inner-workings of your objects without breaking a bunch of other code that uses them.
XXVIII: Though shalt use resource naming schemes for large projects.
This may be the most subjective thing on my list but naming-schemes can really save your bacon when having to manage a large project and open the door to some interesting extensibility options. Say you have a base object that has different sprites associated with different movement states (I.E. standing, running, jumping, etc) and you're going to be creating a bunch of objects that inherit from this base object. Using resource naming would save you from having to create code that individually sets all of these resources in code. Ex: For an Object named Player, create sprites named PlayerMovementStand, PlayerMovementRun, PlayerMovementJump, etc. and have your base code discover these resources programatically according to your naming scheme using asset_get_index
I found that DnD can be a very handy tool if you know how programming works, but when you're new to the syntax of GML
I'm so glad I watched this before I got very far in my game...it's my first game with GMS2 and I'm pretty much learning as I go
As someone whose highschool programming teacher herself learned to code in the '70s, and required all of us to write our BASIC code on paper first before even sitting down in front of a screen, unlearning the preconsideration of code efficiency is obnoxiously difficult. I would love to be free of worrying whether I'm bogging gamemaker down and setting some sort of critical system up for catastrophic failure by forcing it to evaluate a string rather than utilizing an integer.
About commandment 10: I only ever use the numeric interpretations of booleans for multiplication. That can be quite convenient, as it can save an if-block.
I mean stuff like "speed *= 2 * ultra_fast_mode", where ultra_fast_mode is a boolean variable.
Yup. I do that all the time! Nothin' wrong with that as long as you understand it. Same could be said about every single one of these.
I find persistent rooms can be OK for implementing a pause menu in a separate room (in which case you'd turn on persistency before leaving the room and turn it off after you return), but there's indeed a LOT of weird quirks with them that take extra work to get around. For instance, the Room Start Event triggers if you re-enter a persistent room, so you'd better not use it for any initialization code that's only meant to be run once! Also, if you turn off persistency in a different room from the current, you don't delete the stored state, so you need to re-enter and leave the room while it's un-persistent to actually reset it! For something more complex like an RPG overworld these quirks stack up way too high to be worth the effort working around.
This video was helpful and funny as hell. Please make another I'm sure you could come up with at least another10. I was pleased with myself because I picked these things up naturally. There were only one or two things I had not thought of.
Nice video and I agree with all including Mike's commenting code. I would also add "magic strings" to this list for several reasons including localization, enums for easily identifying array indexes and #macro for game wide constants.
i just checked the description for a link to buy the 15 commandments of gamemaker poster but it wasnt there!
This video didn't really helped me because i have some experience with game maker and knew most of the commandments, but it is so well done that i watched it to the very end!
Congrats! Amazing video! I'm proud of you!
Hearing someone saying GUI as gui instead of G-U-I feels pretty weird
Yeah, I've had a lot of people say that. I work in software UI professionally, and I assure you it is not strange at all.
I honestly had no idea what he was talking about when he said gooey, thanks
I've never heard a dev say "gee you eye"
As someone who is relatively new to GM, these seem like great tips, but a few things about GM confuses me at times. Before trying out GM, I've messed with several engines- Unity, Godot, Construct 2, etc.... It seems weird how in GM, it has built in physics, yet it's advised by every veteran GM user to avoid it at all costs, where in Unity and Godot, the built in physics are awesome. As a novice in GM, it comes across that GM is broken software that has to be navigated by custom means, because using built in tools will break your game or something.
Secondly, I don't get the hate directed towards Drag n Drop by veteran GM users. To me, DnD seems way faster than GML, plus easier on my eyes. One can still code in it if need be. One can preview what the code looks like. One can also convert it to code later on. For veterans who've been using GML for years, DnD probably isn't attractive, but I personally find it a better way to understand GMs approach to creating things.
I've read a lot of the GM manual, but IMO, it's a bit to much of a dry read. People who ask advise on the forums simply want their questions answered in layman's terms.
Thanks for clearing up the physics thing.
In regards to DnD, I see your point, but I'm more of an artist than I am a coder. Visually memorizing the icons connects easier to me than memorizing lines of code. Why type out a chunk of code when you can simply drag over one window and plug the values in it? It's just way faster to get the same results coding gives, which gives me more time to focus on my art. For things where detailed coding feels more necessary, simply drag over the execute code window and type in the GML.
I find DnD more fun to use. DnD is kind of like playing a puzzle game, where coding is more scrutinizing my screen for that one typo.
I'm not an expert by any means at coding, but I'm not a complete noob either. I'm pretty convinced that going into the future, things like DnD are going to get more common, more cleaner, and advanced as future engines come out. It's just the evolution of things.
I liked DnD a lot when I first started because it I started coding using RPG Maker Engines. It was similar to what I was used to at the time. But the more I used gamemaker, the speed at which I could type was faster than mouse clicking and it made changing things faster and easier (especially when debigging). I think DnD is a good stepping stone when starting out, especially because you cant do everything with it, so it forces you to learn raw gml.
BTW, I'm aware RPG maker has RGSS, but I never really needed to learn it at the time. Although I wish I had as the things I was doing would have been much more optimized in RGSS.
Also, side note on single vs double equals - in a lot of languages with this distinction, an expression that sets a variable to a new value will also evaluate to that new value. This is often used as a shortcut for return values, Python, Bash and Matlab all will use whatever was the last value of a command in a function as the return value if there's no explicit return value for instance. So a single-equals comparison would first update the variable, then check if the new value is boolean true. Almost nobody does this kind of thing, but C (a major inspiration of a lot of later languages, including GML) is a language from a time where stupid hacks was the only way you could make programs fit in your floppies / CPUs and it just absolutely revels in them. There's even the trigraphs, a relic from the era when not all computers supported the ASCII character set, so you needed escape codes for common symbols! And don't get me started on all the problems C-strings (null-terminated byte arrays) have caused.
Thou shalt NOT drop Game Maker for an entire decade and start learning all over again! 😭 lol
I'm glad to see that I figured most of these out for myself. Sadly I've been working on my first major solo game project for 8 months, and have learned a lot of this in the process, so the game has a lot of crap like this, but my next project will be much cleaner. I cannot get myself to use == on the go. I'll be banging out code all day, and then realize I didn't do it. :-/
I still do it sometimes, too, honestly. Just clean it up when you catch yourself and you'll be fine.
About not using persistent rooms, the same can be said for any other built-in feature of the GM engine. People also will say to avoid things like the Solid property, and the built-it speed variables.
So then why use the engine at all? Why not code everything from scratch, right down to the metal?
The better way to think of it this commandment is **"Don't use features in the engine that you don't understand well enough to use."**
Whatever features of the engine that you make use of, inevitably you're going to discover that you didn't fully understand it, and this lack of total understanding has just resulted in some weird, undesirable behavior. At that point, you have a choice: delve and seek to find the deeper understanding and work with that engine feature, or eschew the engine and build your own system entirely from scratch.
Both are valuable learning opportunities, and valid approaches, and depending on what you want to do, each approach may be better/easier for a given problem.
That's a good point. I suppose I picked solid and persistent rooms to single out as they feel like the biggest "sledgehammers" that newer users tend to use. They don't want their player to run into walls so they set the walls as solid and it seems to work... until it doesn't. Same with persistent rooms, they want to keep one thing about that room the same when they transition to their menu screen or something, and they don't really realize everything else that is going to be affected because that room is now persistent. then they try to enable and disable it dynamically... and it just becomes a mess.
But, I agree with you: I could have condensed about 4 or 5 of these commandments into 1: "If you don't understand it, don't use it" commandment. I suppose that's why I've sort of pulled away from making videos and moved exclusively into helping people on the forums and chat rooms. Once you make a video, it's there forever, and any mistakes stay there with it. Learn a better way to do or teach something? Make a new video and hope someone finds that instead of the old one... ¯\_(ツ)_/¯
Sorry for the mini-rant. Thanks for your comment and for watching!
Extremely useful and informative video as always Pope. This will surely help new users avoid some headaches. I look forward to more videos.
Fantastic video Pope, informative, clear and amusing. Love the new art too.
I feel great knowing how many of these I've practiced before watching
I like to rewatch this every few months or so just to see how I'm doing ;)
Tip 8 I never knew about! Thanks! I'll fix it straight away
Hi, the biblical reference and music was AWESOME. So funny i almost fell off my chair. I love the video. Thanks.
I thought of another good one! Use ; at the end of every line of code. To be clear, that is:
;
^That thing. It ends the line of code you're writing, it may not sound important, but there are several instances where you can get undesirable results from not ending your line. Obviously you don't use those just after an IF statement or whatever, and definitely not after a curly bracket like } or {, but most other lines should have a semi colon at the end.
Trust me it's a good habit to get into, you'll be glad you did.
I miss these :)
I'm pretty new to GML, but I've done a lot of programming in other languages. I've gotta give you major props for #4. My instructor at University taught me of this practice and I stick with it to this day, even though other people think I'm mad.
As a guy with some programming experience, I found the stuff pertinent to Game Maker's built-in features to be the most helpful. Particularly, #5, #8 and #12 strike me as some awful temptations that could lead to bad habits if not avoided outright from the beginning.
Lastly, I've been interested in some of your other creations, and was wondering if you had examples of some very specific things I've seen in your projects -- namely the ALttP-styled textbox and scrolling. I had some idea of what to do for the former, but the tutorials I've followed use actual text; I'm pretty sure one would want to draw characters to some buffer space ahead of time, and then update the Y offset in a loop for that "scrolling out of existence" effect between dialogue prompts. The latter question, I don't think I'm ready to implement just yet, but I'd like a good framework to work within so I'm not trying to reinvent the wheel. Sorry to bring these off-topic questions up here, but I'm not sure of the best avenue to get ahold of you. Tried Twitter once, but I think I just suck at Twitter.
Hey, I suck at Twitter, too. Best way to get a hold of me is through Discord. You can join my discord server which has lots of awesome people on it who can help with almost any issue you might have. discord.gg/4jhvWp
As for the Zelda thing... nope, it's pretty much what the tutorials will tell you to do. I print a temp copy of the string with a limited number of characters out to the screen. No need to get buffers involved. You are welcome to comb through the project if you'd like, but it's been awhile since I've even looked at it, so I may not be able to answer all questions.
www.dropbox.com/s/6ijcn0xqtkm81oo/Zelda1.gmz?dl=0
Its fun to see this after a year and 2 month since I got GMS2 and also started learning about programming from knowing nothing except "variable are those things you declare in which you store data that can vary" xD
Its like watching a summary of what experience made me learn and of course tutorials (Pixelated Pope included, regarding views).
Still I wanna point out, I think knowing how things work "under the hood" is SO important. Not letting yourself have code that seems to work magicly or following a tutorial in order to reach a result without really having understand how things work even if you reach the result you expected.
Gotta say, simultaneously with GML I also started learning Java (later also Android). And took me some months to realize, wow at least the programming languages I studied are essencially the same thing.
And to the purpose of knowing how some things work under the hood its really helpful to know more than 1 programming language. And if you are interested in how hardwares work (in depth) even better.
It may sound like a joke, but I had no idea about most of these things at first 😅
Anyway, great old video.
Yes, do all of these things. The really confusing errors that take the most time for me to figure out are the result of me doing one of these.
I started GMS2 with the actual coding stuffs and it’s easy to learn. I tried DnD and it felt complicated lol.
I learned all of these the hard way. Where was this video when I was still fresh at this?
Only thing this is missing: Thou shalt pick your resolution ahead of time... Coupled with my sinful use of magic numbers, I spent several hours yesterday changing my game's resolution to more suit my needs. Old or not, this video helps a lot. :D
360*640,180*320 and 90*160 all scale evenly to both 720p and 1080p. Most people have a 1080p display but you may as well use one of those resolutions if you can.
Pretty sure Hyper Light Drifter is 480x270.
You are correct. Apparently the screenshot I found was from a very early build... but I think the basic idea is still communicated well even if I wasn't completely accurate. Thanks for watching!
another thing I would recommend would be to add a semicolon to the end of every line that doesn't end with a bracket, and comment your code. Comments can help you understand what your code does and semicolons help to show the end of a line. I instinctively hit that key before hitting enter on any line of code. I also used drag and drop to start out the code to give me a good base to start from, I also used it to help me get an understanding with how to for sure get an object to follow my mouse.
13:13 I'm super guilty of this one, really good advice to follow lol I tend to get so hung up on one little data structure and how I think the most optimal way to code/use it is that it'll take me a whole day just to figure it out
@@KryptKicker5 I mean a little pedantic, but still thank you for the book recommendation :) I was only giving the one example of data structures, but I fully understand where the video's coming from about getting hung up on overthinking the small stuff. Sure, it's great to know what you want to use ahead of time, but there aren't many in this world that will know the _exact_ answer right from the get-go, so 9/10 it's better to get something down in code first and then revisit that to better optimize it. Same thing goes for anything circuitry related, you build a spaghetti prototype first just to make sure it works, and then you optimize and compact it from there.
TY for the premature optimization tip. So many people obsess about this and it’s usually not even a factor. Similar with writing obfuscated “tight” code on a first pass. It’s okay if your snippet takes five lines to lay things out clearly instead of being scrunched up into a line or two. Tighten it later, after you know it’s working and why. I fall for this myself sometimes and have to take a pause to remember that clarity is paramount.
I kept on thinking Mr. Bean would show up don't know why... Anyways, thanks for the insights! Very informative.
It would've bean nice if he did
Great tips! - Many thanks, I'd started using "Self" - and wondered whether I should be using ID or Self - question answered! (along with a lot more... :D )
Honestly, it probably doesn't make a huge difference (it used to, but self has been fixed I believe). But glad you liked the video!
About self. It was recently -ish changed to be the same as id (which means my trick on passing self around to refer to the final executing instance no longer works :( Never the less, self is still bad form...
it's kinda default use for someone coming from anywhere that has 'this->..' though. how is it a problem now that it's the same as id?
14:51 actually from my experience it just keeps any non-solid object from going into the x,y of the solid object
And yes you can still modify what happens when the object collide even though you checked solid
Its pretty much making your object a brick wall,
The only problem I see is the collision event fires early
And somethings you want to pass through it wont
And sometimes two solid objects ignore eachother being solid but I think thats a bug
What happens is when you collide with a solid object, the object is moved back to xprevious and yprevious. So this means it's more difficult to get your object to get right up against the solid object.
13:30 or do ">> 1" IF the value is a base 2 number (128, 64, ...)
Great video and amazing new propic & channel graphics!
this is the first video i see from you arent bad! i enjoy it! :D
SUBBED
I just thought about one more. Thou shall consider compiling the final build using YYC. (gives 3~5 times faster performance)
What if if DON'T have an IDE?
@@mariannmariann2052 There is a guide to install Visual Studio and set up things for GMS
I took "Thou shalt read the manual and seek guidance within before asking others." to mean Google it/try to figure out for yourself, and only ask for help if you've got no where else to turn. As a novice, I haven't found the manual to be very helpful. For me, it's like trying to learn Russian by reading an English to Russian dictionary - you get definitions, but rarely any kind of useful context. I feel like it's written for intermediate programmers who are trying to understand the syntax of GML, and not absolute beginners trying to understand how to do something.
I think before attempting GML, a better place to start would be a programming course. Although a bit dated, John Janetka's Game Programming Course (GPC) is the best I've found for absolute beginners like myself.
"Worry less, code more, make progress"
Can you help point me in the direction of a tutorial for creating a camera that doesn't use the "object following" feature, as detailed in commandment 8? I'm having a bit of trouble finding one.
Edit: I'm using Game Maker 1.X.
It's very very easy in GM 1.4. Basically just position your view x and view y. I usually do it like this:
view_xview[0]= target.x - view_wview[0]/2;
view_yview[0]=target.y-view_hview[0]/2;
//Keep the camera in the room
view_xview[0]=clamp(view_xview[0],0,room_width-view_wview[0]);
view_yview[0]=clamp(view_yview[0],0,room_height-view_hview[0]);
PixelatedPope OK. Thank you! I take it that "target" is whatever object the camera follows, like "obj_player," for example?
Yup! That's the most basic of camera systems. But the principal is the core of any camera system. You have to center the camera on some point, and you can use any logic you want to decide what that point is.
PixelatedPope Thank you for your help!
Wow I love this! Will def be taking screenshots of those to use on th GMC!
gfycat.com/gifs/detail/KindlyKeenGrayreefshark
gfycat.com/gifs/detail/HarmlessBlondIchneumonfly
gfycat.com/gifs/detail/ElderlyShadowyFishingcat
gfycat.com/gifs/detail/ThreadbareBareDonkey
gfycat.com/gifs/detail/MediocreYellowishHapuka
gfycat.com/gifs/detail/ExhaustedDistantCutworm
gfycat.com/gifs/detail/FriendlyVengefulJackal
gfycat.com/gifs/detail/DishonestHorribleGopher
gfycat.com/gifs/detail/UniformLiquidAlbacoretuna
gfycat.com/gifs/detail/SparseRevolvingGavial
gfycat.com/gifs/detail/LongAnchoredFlee
gfycat.com/gifs/detail/MiserablePhysicalKob
gfycat.com/gifs/detail/IllustriousFinishedBernesemountaindog
gfycat.com/gifs/detail/RapidDisfiguredDegus
gfycat.com/gifs/detail/PiercingSatisfiedAoudad
thanks for the tips. i'm a beginning gamemaker myself and this was really helpfull
I'm so glad I came across this video now so I learn my GML the right way. When you say don't use physics your not saying don't use collision boxes right. Your saying don't use the physics [Tick]. And I shall now go to your camera view tutorial so I never use camera follow [Tick] again.
I've got a new camera tutorial coming really soon! For now, here's a text version to help you get started.
docs.google.com/document/d/1l_8HmdPMwAhYd8YQXJTkT-5acmsdEp0BBJgfwsusuZE/edit?usp=sharing
@15:34 all i can imagine is him spraying me with water from a spray bottle like a cat
Learned so much from this, Hope to see more videos :D
I got the "self" thing out of this. I thought I was doing it right to avoid issues...
Now, this video is getting a bit old... There is actually ONE place you can use self and it's the "right" answer. And that's when inside of a constructor.
@@PixelatedPope What about collisions? self and other? I have passed in id and reference it as _id in a parent constructor and that seems to work well.
@@Ragnark1 inside collision events it's just other.id. You used to be able to just say "other" but recently other was changed so you have to use other.id.
@@PixelatedPope One other question: a global variable controlling focus of a user control in Game Maker -- should it be
global.control_with_mouse_over_focus = noone;
or
global.control_with_mouse_over_focus = undefined; ?
@@Ragnark1 Assuming the value going into the variable is always going to be an instance ID, I would go with noone.
i love the way you pronounce "GUI"
Great video, lots of helpful stuff we should be paying attention to. Make more videos PP!
The whole 'black box' idea is one of the reasons I've struggled with Godot. EVERYTHING feels like a black box in Godot, and when you need to do something outside of what the engine does by default, it gets a lot more complex than gamemaker. It's totally possible, but it feels like you end up spending a lot more time reading docs than with GM, and at this point, I've used Godot longer than Gamemaker, but GM is still easier to use. Gamemaker almost feels closer to a game framework/library like raylib or monogame than godot does.
For part 2, why not just choose Drag n Drop when creating a new project. You can always use GML with the "Execute Code" tool in the toolbox. It just provides you both options in reality.
The code readability parts of this were covered in Robert Martin's "Clean Code" book. Very, very good and entertaining book. I recommend with all my heart (no pun intended).
Interestingly, the main theme of the book is "only comment your code when it's unavoidable":-D Because if your code needs comments, that means it's badly written.
I agree with XIII and XIV. Solid is a bitch...
I'm baffled by that low resolution idea for pixel art... It might be a very good advice, thank you:)
I also wouldn't recommend using alarms.
When I started with game maker, I jumped right into GML, because I was already familliar with other programming languages, like python and java, and it was also easier to understand things faster, because I was already familliar with other game engines too and programming in general.
THOU SHALL USE THESE COMMANDMENTS
Haha amazing. I loved the History of the World: Part 1 bit. Well done :)
I agree with everything, but the GUI event thing. problem is you can't keep track of the GUI event surface and since its works differently than draw event, its kinda boring to make it works as you want sometime (specially when you make a pixel-art game and want to stretch, windowed, fullscreen..).
I'd say as long as you dont suffer performance issue, its better to go with a custom GUI system. IE. a "GUI suface" drawn after everything, following the camera or whatever. I feel like this gives you much more control over what's happening
Another very important one you missed:
THOU SHALT BACK UP YOUR WORK OFTEN AND ON A REGULAR BASIS
Especialy if you ise 3rd party software (GMEdit).
right so tell me how I can recode move_contact_solid(point_direction(x,y,mouse_x,mouse_y),lerp(0,point_distance(x,y,mouse_x,mouse_y),0.2));
there's no other code I've yet found that checks in every direction and when I tried doing it myself with place_meeting*4 it didn't even work then.
Solid is not necessary for ANYTHING. All solid really does is move you back to xprevious and yprevious if you collide with something that is solid. So move contact solid is just a while loop that moves you towards something until you are just about to collide with it. It can be replaced with the following code:
pastebin.com/YL8z8e9k
Is that a lot more code? Yes. Absolutely. But you now have absolute control over how your collisions are handled. It's up to you whether that's something you need or not. Like I said, these are all just suggestions, and you can definitely make a game while using "solid". But don't think that there's no way to duplicate solid's functionality, because there always is, and by duplicating it you'll gain much more control over your games lower level functions.
Thanks for watching!
Thanks for saving my life
I probably screenshoted like infinite times
Great vidio! Got some new cool advices, so I won't make mistakes in my next game. Thank you.
I was making my Camera Object, & my camera was jittering until I saw your video.
And, It stop jittering.
Thank you.
Nice! Glad it helped you!
that new intro...hot damn! I didnt like how long the animation/voice over took to say what was the next tip/piece of advice. Overall the video was good though, i liked it.
Amazing as always. Thanks Pope!
Ok, I work primarily in 16x16, but what if my game's art style is made using adobe animate or other software to draw in? It ha vector imaging and would most definitely be more than 960x540. Would that work? I'm a beginner in this, so take what I ask with a grain of salt.
I'm in high school and we're making a game in GameMaker but the teacher required us to make it in Drag and Drop, so I created a drag and drop project and only use code blocks.
Nice! That's how we had to do it in GMS and earlier! Still counts as not using Drag and Drop in my book! Keep it up!
I'm sorry father. Because I have sinned. I didn't knew the manual existed until I first watched your video in dec 2019