Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!
I am already well aware that habits such as drag and drop, using default resources, and not compressing files are examples of bad habits.
One in particular I was wondering about is declaring local variables without first including "var". Will that have any significant impact on how memory or the game in general is handled?
I was also wanting to know if there are any other bad habits I should be aware of. Thank you.
First, compressing files isn't necessary unless someone correct me. GM does what it needs to do to the files on compile.
Second, if you don't use var then you aren't declaring a local variable you're declaring an instance variable which means the variable will exist in memory until the instance is destroyed. You would use var when you A) don't need to remember the value in another event or step or B) to efficiently reference values when using "with." Hard to explain without context.
Third question... a thing or two off the top of my head:
Don't use code not relative to drawing in a draw event.
Don't scatter and repeat gamepad or keyboard input code throughout multiple objects.
Don't use if, if , if, if when you can use if, else if, else if, else if or even better use a switch.
There's nothing bad in using "var" in itself.
Its just that you need to understand the scope of the variables you create. If you don't use "var", that variable will be accessible for any event in the same object. If you DO use "var", that variable will only be accessible in the same event its declared and not through the whole object.
Bad habits:
- Not respecting syntax
- Not indenting and spacing your code
- Not commenting your code
- Not using script for parts of code that are repeated in many objects
There's a whole lot of possible bad habits though. You will learn about them along the way lol
That's good to know. I've been programming without var for quite some time. In the past I've railed against drag and drop and other cringe worthy programming habits.
Using D&D is *not* a bad habit. Slap hard whoever told you that. ^^"
Either way, I believe more in adopting good habits. I concur that eliminating bad habits from your practice is the best way to make things organised and GMS-friendly; but you need to adopt good habits more, particularly if you want to improve.
...is a compilation of some of the best coding practices. But since there's so many of them, you can't learn everything altogether. You'll learn about them as you proceed. This is a pretty good list, too:
I am already well aware that habits such as drag and drop, using default resources, and not compressing files are examples of bad habits.
One in particular I was wondering about is declaring local variables without first including "var". Will that have any significant impact on how memory or the game in general is handled?
I was also wanting to know if there are any other bad habits I should be aware of. Thank you.
Not really a "bad habit" list, but some suggestions that may make your life with GM easier:
Make lots of Groups, and figure out a way for them to make sense; repetitively selecting objects or sprites from a huge list of them becomes tedious because GM doesn't remember the last place you were.
Scripts allow you to create Scripts within tabs of a single Script. While this is a handy way to keep certain Scripts together, you can no longer search for those tabbed scripts and sometimes it gets painful finding what's where.
If you want to offset a Sprite, rather than make transparent PNGs with padding in them, offset the Center of the Sprite (you can use negative values that are "off-screen").
If you're not good with the debugger and you're running into performance problems, start removing or commenting out objects or scripts you recently added until performance improves to find the possible culprit.
Bug-fixing is a pain - keep a pen and notepad near by and make sure that you can pause your game. Play thru and pause every single time you encounter something you don't like and write it down. Don't fall for the "I'll remember to fix this when I finish this test play" self-delusion: you won't remember. Also, crossing out items from that paper bug list feels GREAT.
Sometimes, you'll do things within things in such a way that it becomes almost impossible to remember how you did it. Make sure to document what and where things are when they get hairy. A month or two down the road when you need to revisit something, you'll be glad you did. Better yet, make sure that your comments in your code give you reminders of where stuff is and how you did it.
BACK UP YOUR WORK. Seriously, stuff happens, and hard drives suck the big one all the time -- you will cry tears of burning unicorn blood if you lose all of your work.
There are just too many to name, to be honest. Every language and subfield has its own taboos and bad moves, and nobody knows it all. Just make a best effort to learn what constitute bad habits in things that you use often and bad attitudes in general coding, then make an active effort to avoid them.
Let's take your var habit as an example for GML variable handling. In this narrow scope alone, I can easily name 15 common bad habits:
Not using var to declare temporary variables.
Using var to declare everything.
Using globalvar.
Using object.variable with multiple instances of the object in the room.
Using global variables for non-static instance properties.
Using self.variable or object.variable to refer to variables of the current instance.
Referencing from other outside with blocks and real collision events.
Consecutively numbered variable identifiers.
Attempting to make instance/object IDs or variable identifiers by concatenating strings.
Storing self or other as-is into variables holding instance IDs.
Not checking for noone, -1 or any other "invalid" value before referencing variables off something that can return or hold such values.
Forgetting to change perspective within a with block.
Calling string() on variables that already hold strings.
Relying on instance order to prevent race conditions in interdependent variable declarations.
Conditionally declaring variables.
There seems to be an excessive focus on activity-specific training here on the GMC, so much that mental conditioning and general aptitude are neglected. This is creating a generation of novices that just can't grow out of the title. Here is a list of 15 bad general coding habits/attitudes that I see most often:
Whoring after videos, tutorials, examples or mentorship.
Throwing TLDR cards at responders and written resources.
Coding when impaired and then excusing poor work in its name.
Relying too much on hands-on help (AKA being Post-New-Thread-happy).
Starting off with a big dream project.
Making up random crap and expecting the interpreter/compiler to get it.
Replacing proper analysis with naive, unspecific or overly broad "how do I do XYZ" lookups.
Copy-and-pasting code without understanding it.
Not tracing code.
Not learning basics.
Not consulting the Manual before using an unfamiliar function.
Not drawing diagrams.
Not exercising introspection.
Not commenting.
Not indenting code consistently.
If you can steer clear of everything listed above, any activity-specific bad habits or inexperience you have coding-wise aren't going to last long. You will develop into a solid developer before you know it, and I guarantee it.
The most important bad habit to break being disorganized. As some have mentioned tabbed scripts and indenting, its important you keep a consistant set of rules.
Keep a standard of asset prefixes. EI: All sprites might start with spr_ or objects with obj_ or textures with tex_ be consistant with it.
Don't be afraid to catagorize things in subfolders. If you need to parition entire parts of the game away, put them in an easily recognizable folder so that you can go right to the required resources
A rule of thumb, if you have a hard time reading your code by mixing up lines or pausing, or you don't immediatly know what something does, no one else will be able to know or read it at all. Keep it clean and concise. Make some standards.
Remember proper memory management. Delete ds_ systems, destroy buffers and organize texture pages and audio groups.
I gotta say this, because I found out within the last 24 hours:
1) forgetting to use ; to end a 'sentence'. Yes, you MAY be able to get away with it - but it will bite you in the bum in the long run. Never forget to use ;
2) mistaking assignment for comparison when using the equals sign = ...much too often people will say it's squishy, but I believe knowing the difference in = and == will make programming much easier in the long run! (DO NOT USE SHORCUTS! Doing: If(a+=b) WILL BITE YOU SOMEDAY!)
3) make your code clear and concise. If you can't read it aloud and understand it, you may want to think twice about using it.
4) STAY THE HELL AWAY FROM COBOL! (okay, that has nothing to do with GML, but it's good advice anyway! )
Using simple variables, such as a, t, x, etc. Also, not adding identifiers before objects, sprites, scripts... So like doing player for a player object name, instead do obj_player.
This. So much this. I strongly recommend ALWAYS having a sheet of paper and a sharpened pencil next to your mouse. To-do lists and diagrams help a LOT in making you get stuff done, and paper is a lot faster than mindmapping tools most of the time.
Yeah, I wasn't going to comment cause it just seemed a position of novelty, but I would be curious to know the advantages of not using resource prefix and using single character variables that have no meaning to the developers. Pretty sure someone looking at your code would just stop if they can't even logically follow variables. I mean, they are good for loops that get thrown away, but I fail to see how any of that helps.
Using simple variables, such as a, t, x, etc. Also, not adding identifiers before objects, sprites, scripts... So like doing player for a player object name, instead do obj_player.
actually, x is often used when referencing a position, t is used for a time value and a is used for primary values, or temporary acceleration. (just like i,j and k are used as counters, and u,v,w are also used as coordinates).
I also tend to exclude the obj_ for objects and start my objects with a capital letter... i like it. (would never give up World.width. its so much nicer to me)
I generally try to shorten my variable names whenever possible because I make typos all the time, but I still always have them MEAN something.
Like, here's some code I just wrote.
SS is short for Ship Script, and I C O N stands for Init, Cannon, Option and Nozzle, respectively (the latter three being the main powerups in the game).
I spend some time of my week (maybe an hour or two?) tidying up. When I've been in the zone and clicked create sprite and Create object , create script etc for possibly hours on end when I'm getting stuff done, invariably there's things created in the wrong group, the wrong line and the wrong place. Letting what seems like little problems build up is a sure fire way of extending your time doing things as you try to find obscure random assets. Tidying up and making sure things are put in the right place in the right group speed up the overall-general process of getting things done.
I personally spend a bit more time typing, in the hope that maybe six weeks later when I have to revisit code I can see that;
so that I might have a clue WTF I'm looking at when I haven't seen the code for weeks.
And finally, although at the time it is a pain in the arse, comment the living- out of everything. Going back to try and figure out what the hell your own work means is bloody annoying. When you get annoyed at your own bad commenting it's time to have a word with yourself.
The fact its equiped should be pretty clear. Also using a string to represent what really should be an instance? thats just plain bad practice.
also, using global variables for something that clearly belongs to the player object? *shudder*
Using simple varaibles as a bad habbit. That's what I was trying to say.... This is bad habits to avoid is it not? I guess I shoulda made it more comprehensive.
actually, x is often used when referencing a position, t is used for a time value and a is used for primary values, or temporary acceleration. (just like i,j and k are used as counters, and u,v,w are also used as coordinates).
I also tend to exclude the obj_ for objects and start my objects with a capital letter... i like it. (would never give up World.width. its so much nicer to me)
Oh, teh more you know. X is a built in varaible, I know but I was just trying to say. Don't treat it like school taught algebra. I understand that in programming x, y, and t sometimes. Which I recently used in a project for a shooting timer. Can be ok. But doing things like cs can be hard especially for an outside viewer to understand, that's canshoot, or callsony, etc. Either way I try to avoid it if possible.
I generally try to shorten my variable names whenever possible because I make typos all the time, but I still always have them MEAN something.
Like, here's some code I just wrote. View attachment 1885
SS is short for Ship Script, and I C O N stands for Init, Cannon, Option and Nozzle, respectively (the latter three being the main powerups in the game).
Abbreviations are used in my school notes, but they are pretty exclusive to my work/notes. SO I try to avoid it if I plan to allow someone else to join the project or have it opensource.
Also, a bad thing to do sometimes, especially if you can't comprehend math that well is to try to do insane amounts of logic in your head, especially if it's complex. Write it out, draw it out, notepad is open a lot for me just so I can jot down notes. It helps when initially setting up a system. Also, you could comment but I like to keep those to short sorta keynotes.
im not sure this really counts as a bad habit...
contrary to what you may htink, optimizing in this way can actually be worst in the long run.
(performance should be in the algorithms, not the code)
im not sure this really counts as a bad habit...
contrary to what you may htink, optimizing in this way can actually be worst in the long run.
(performance should be in the algorithms, not the code)
var xx,yy;
xx = global.player_x;
yy = global.player_y;
if (xx>0 && xx<640 && yy>0 && yy<640)
{
//player is withing these radius
//Then use xx and yy variables for something else
}
This is the "As far as I know" part, accessing a global variable is lot slower than accessing a local variable. Also, it is also better to use small variable names for complicated algorithms, not for performance but for the look.
Code:
if (global.player_x>0 && global.player_x<640 && global.player_y>0 && global.player_y<640)
{
//player is withing these radius
//Then use xx and yy variables for something else
}
var xx,yy;
xx = global.player_x;
yy = global.player_y;
if (xx>0 && xx<640 && yy>0 && yy<640)
{
//player is withing these radius
//Then use xx and yy variables for something else
}
This is the "As far as I know" part, accessing a global variable is lot slower than accessing a local variable. Also, it is also better to use small variable names for complicated algorithms, not for performance but for the look.
Code:
if (global.player_x>0 && global.player_x<640 && global.player_y>0 && global.player_y<640)
{
//player is withing these radius
//Then use xx and yy variables for something else
}
Again, this kind of optimization is not really good habit. (nor is it bad habit). but you must be careful as "premature optimization is the root of all evil".
and, if the difference in performance makes any real diff to your game fps, then your algorithm can probably be optimized.
and as for it looking better, its harder to read the first one as you have two extra lines to read before being able to understand the for loop. (and never use global.player_x. just use player.x)
Failure to properly document your code is the error I have seen the most. Using descriptive variable names and when that is not enough make a comment with a note of what is going on there is invaluable. With GMS I also like to use show_debug_message to spit out messages and variables at key points in the code. Debugging code is the most time consuming step in developing software and where most people fail regardless of skill is to take the extra time to make sure when you have problems (and you will) that they are easy to track down.
This is one-sided baloney. While big corporate bureaucracy has well-known downsides, its upsides are under-appreciated and under-applied elsewhere.
Sleeping on and cross-examining every novelty, idea and "innovation" before putting it to work.
Not mouthing off promises, deadlines or release dates that aren't backed up by established work.
Consecrating the PR front and client data as off-limits for jokes and pranks.
Treating business, investments and contractual obligations as a form of accountability instead of YOLO fodder.
Impulse-proofing is the Achille's Heel for a lot of Agile methodologies, startup/startup-like modus operandi and indie dev mentalities. There is plenty left for people like you to learn about from big business, and this throw-the-baby-out-with-the-bathwater attitude is a major obstacle.
For the same reason large corporate culture fundamentalism is a widespread problem in the business world, so is startup culture fanaticism.
Every single one of them cited late night work as to why the code didn't work properly. Guess what, that's impaired as far as I'm concerned. And the fact that they need help with it later on and spend our time solving it means they have done substandard work that is a net waste of time.
Using midnight oil as a fig leaf for bad code should not be encouraged at any capacity, let alone glorified.
dont run a code every step unless you actually need it every step and if you have more then one IF statements that will check for a certain action, aways use the most intense code last and most light code first.
hereis how i do detecting for instance. i dont need it every frame so i put it in an alarm that checks every 15 or 30 frames, depending on what i want and if theres a detection it sets a var on and the enemy shoots. bet he keeps shooting even if he doesnt see me becouse the check runs after 30 frames, WHICH on the other hand creates a nice effect of the AI having memory.
also a very bad habbit is to milk your old engine and dont use any effort for in future projects.
I see a lot of comments about commenting. My approach is to try and write a self commenting code by using meaningful names (variables, scripts, object, etc.). Only comment more complicated parts of code like complex algorithms (or even better, enclose them in a script with a meaningful name). And always write a /// comment as the first line of your scripts to describe parameters and in your objects to describe what each block does. It just makes navigating the code easier.
I completely agree with @Fel666 that you should try to avoid global variables if it is clear that they belong to an object.
In my opinion premature pessimization is also the root of all evil. If an optimization doesn't make the code less readable then I see no reason not to use the optimized version. E.g. using var where appropriate, initializing arrays starting with the last element, using ++variable instead of variable++, variable += 1 or variable = variable + 1, etc. But I agree, code readability and consistency is more important at first then any premature optimizations. Try to profile your code to find bottlenecks before doing any serious optimizations. You might be surprised where the real performance slowdown actually occur.
I also agree with @FrostyCat - it is easy to write messy code in a long coding session, but remember to always cleanup the code afterwards or it will likely hurt you in the future.
Finally, I always try to read my posts in the forum a few times since English is not my main language and try to avoid spelling or grammar mistakes and making myself clear.
Can't remember if this was stated (although I think FC did touch upon it in earlier)...
Do not assume your issue is unique to yourself or your game; for that matter, do not even assume your problem is unique to Game Maker users. If you have a problem, GOOGLE IT. And don't use retarded lengthy search terms like, "how do I make player jump up through a tree branch and land on it and able to jump down through it if space is pressed while ducking". Sure, Google is a great search engine and might be able to figure out what the hell you're asking, but odds are you'll get a bunch of impertinent crap and you'll just give up and come to these forums to post a question that has BEEN ASKEDNEARLY A HUNDRED TIMES BEFORE. Game Maker is over 15 years old and as such there are very few questions you may have that have not already been asked before. Some info is outdated, so you just need to Google replacements for the outdated stuff, which there are hundreds of posts and tutorials about as well.
Addendum: It's possible something can be found via Google albeit with some difficulty. If you say, "I tried searching on Google but couldn't find an answer," but one of us goes on Google and finds an answer on the first try, then you may get some heat for not even trying - and then a link to the answer. Some searches are difficult because of the terms you need to use and might require reading through hundreds of impertinent posts just to find the one you're looking for; most of us are pretty understanding about that here.
Wait, is there somebody who is investing in stocks? XD
Joke aside, I think it's a solid advice. Many newbies don't seem to realize the amount of work goes into a game. Any game. And it's okay, there are a lot of small things which can't really be seen unless you've been making games for years. Heck, if you are starting this when you are in your teens, it's probably also tough to grasp that it's something people do for 8 hours every working day. You could say that teens sit in school a similar amount of time, but from my own experience those two are not really comparable.
Also, to add a more practical piece of info, my advice is to invest in version management. Either git, mercury, or SVN, it's totally worth it. It has your whole project history. Just think about it. Everything you did. This gives you a whole bunch of possibilities, the simplest one being rolling back a version or two to find out where did you exactly break that thing you've been trying to debug. It also lends itself very nicely to backup, as you can just put it onto some free hosting. I mean version control specific hosting, for example github ( public projects ) or bitbucket ( public and private projects ).
Wait, is there somebody who is investing in stocks? XD
Joke aside, I think it's a solid advice. Many newbies don't seem to realize the amount of work goes into a game. Any game. And it's okay, there are a lot of small things which can't really be seen unless you've been making games for years. Heck, if you are starting this when you are in your teens, it's probably also tough to grasp that it's something people do for 8 hours every working day. You could say that teens sit in school a similar amount of time, but from my own experience those two are not really comparable.
Also, to add a more practical piece of info, my advice is to invest in version management. Either git, mercury, or SVN, it's totally worth it. It has your whole project history. Just think about it. Everything you did. This gives you a whole bunch of possibilities, the simplest one being rolling back a version or two to find out where did you exactly break that thing you've been trying to debug. It also lends itself very nicely to backup, as you can just put it onto some free hosting. I mean version control specific hosting, for example github ( public projects ) or bitbucket ( public and private projects ).
i think your second advice is a bad advice, about keeping older versions and checking on older code. this creates a bad habbit on not dealing with things on the spot but seeking ready solutions. and you create no skill in coding this way. i think no1 can deny that they have grown as a programmer when they delt with a problem and not simply found a solution to it somewhere externally. the only reason i see to keep old data is for backups.
but correct me if im wrong. this is how i see things and how things tought me.
i think your second advice is a bad advice, about keeping older versions and checking on older code. this creates a bad habbit on not dealing with things on the spot but seeking ready solutions. and you create no skill in coding this way. i think no1 can deny that they have grown as a programmer when they delt with a problem and not simply found a solution to it somewhere externally. the only reason i see to keep old data is for backups.
but correct me if im wrong. this is how i see things and how things tought me.
I am already well aware that habits such as drag and drop, using default resources, and not compressing files are examples of bad habits.
One in particular I was wondering about is declaring local variables without first including "var". Will that have any significant impact on how memory or the game in general is handled?
I was also wanting to know if there are any other bad habits I should be aware of. Thank you.
Drag & Drop isn't a bad habit. After a while, you start to realize it has limitations, and will want to explore GML and learn it, and for a while you'll feel like Drag & Drop isn't "real coding" and you may feel embarrassed by it. But this is just a phase and when it wears off you'll realize that it's just as legitimate a way of coding as anything else, and there's nothing wrong with putting a DnD action in an Event where you'd otherwise need to put a 1-liner GML action.
As far as bad habits, here's a few to avoid:
Not writing and maintaining project documentation.
Not testing frequently. Make a small change, test it, proceed once satisfied that it is working correctly.
Not refactoring. Any time you see an opportunity to refactor your code to make it more maintainable or more generally applicable, you should take it.
Giving up.
Not understanding the difference between = (assignment) and == (test for equality).
Not using semi-colons at the end of a line of code.
Poorly named variables, etc./not having a consistent naming convention that you always follow.
This is a rather Mickey-Mouse and frankly illegitimate view of indie development.
First, investment is not a big-company thing. Everyone does it and have to. Just not necessarily in the same things or at the same quantities.
Buy a new laptop for development, that's investment. Buy new software for development, that's investment. Buy licenses and certificates for development, that's investment. Of course, buy stocks, bonds and derivatives to grow the cash pile, that's investment.
As for the part about not paying taxes, you've got to be kidding me.
So your message is that the ideal indie developer either:
Dodges taxes
Fails to organize business finances
Neglects to file a proper tax return
Makes so little that they fall under the bottom tax bracket
For your information, I don't see any of the above as characteristic of an upright, well-meaning, sustainable indie developer.
I generally try to shorten my variable names whenever possible because I make typos all the time, but I still always have them MEAN something.
Like, here's some code I just wrote. View attachment 1885
SS is short for Ship Script, and I C O N stands for Init, Cannon, Option and Nozzle, respectively (the latter three being the main powerups in the game).
Personally, I like more verbose variable names. I only shorten things if I'm going to have to type them A LOT. I find that remembering what an abbreviated name means, or spelling the abbreviated name consumes too many brain cells uselessly, and slows me down when I'm reading the code because I have to mentally unpack the abbrevs. Whereas, my style of naming variables makes the code I write read almost like prose, expressive and full of meaning, and I find it very easy to understand.
Yeah, I wasn't going to comment cause it just seemed a position of novelty, but I would be curious to know the advantages of not using resource prefix and using single character variables that have no meaning to the developers. Pretty sure someone looking at your code would just stop if they can't even logically follow variables. I mean, they are good for loops that get thrown away, but I fail to see how any of that helps.
I experimented with this early on when I started using GM81, and found that while I dislike the 4-char abbreviations most people seem to use, like obj_ and spr_ and scr_, I do like to give my objects and their matching sprites the same name, so I need to abbreviate those in order to disambiguate them. So I use oObject and sSprite for my object and sprite names. I do omit abbreviations with my script names, because I feel like I'm simply writing a new function when I'm writing a script, and I want the function call to read "naturally" when I introduce it into my code (eg, the function should read "do_something" rather than "scr_do_something").
The normal abbreviations I use are:
s = sprite
o = object
f = font
sn = sound
bg = background
As a beginner who already developed some bad ones, I'd say:
- Not using some kind of naming convention with objects/sprites/variables for easier identification
- Not grouping the many sprites/objects and so on into categories (having a huge list of random nonsense makes it harder to find the thing to edit)
- Not using Parenting. I learned this the hard way. When I set up collision for my first ground object, I thought I had to repeat the code for all new objects used as a ground object. So I had "if place_meeting..." in my code for every object instead of just assigning all new objects as the child of the original. Parenting really helps clean up code as well as reduce tediousness slightly.
- Not making note of known bugs/improvements/changes. Don't count on yourself to just remember. any changes made can have weird effects, trying to fix them is hard if you don't remember what you changed.
This is a rather Mickey-Mouse and frankly illegitimate view of indie development.
First, investment is not a big-company thing. Everyone does it and have to. Just not necessarily in the same things or at the same quantities.
Buy a new laptop for development, that's investment. Buy new software for development, that's investment. Buy licenses and certificates for development, that's investment. Of course, buy stocks, bonds and derivatives to grow the cash pile, that's investment.
As for the part about not paying taxes, you've got to be kidding me.
So your message is that the ideal indie developer either:
Dodges taxes
Fails to organize business finances
Neglects to file a proper tax return
Makes so little that they fall under the bottom tax bracket
For your information, I don't see any of the above as characteristic of an upright, well-meaning, sustainable indie developer.
Dude, dont talk such nonsense. theres no such thing as upright, well-somthing, sustainable w/e indie, thats not indie. thats just your idea of an indie based on somthing. there are actual examples of people, indies, that made great games and dont meet your criteria.
Dude, dont talk such nonsense. theres no such thing as upright, well-somthing, sustainable w/e indie, thats not indie. thats just your idea of an indie based on somthing. there are actual examples of people, indies, that made great games and dont meet your criteria.
Don't reinvent the wheel.
There's a decent chance that something you're trying to make functionally has already been made in GML or, more likely, in another language you could attempt to decipher. Deciphering isn't bad, it exposes you to new languages and understanding that
many languages have a general underlying similarity. Learn proper nomenclature:
These are a couple of naming conventions commonly used in many languages. I use something along the lines of Java's style. From the code examples provided in the manual, I'd say it's more c-like. Use the manual for everything you can
Before asking if something exists, try finding out yourself by looking for its existence with keywords in the manual. Sometimes you can make out what section of the manual your wanted functionality belongs to, but not find the exact function, but if there's functions you see along those lines or naming you should look into it yourself.
Use conditionals and statements with MEANING
Having all of your code look like this:
Code:
while( true ){
// do some things for ever until I please
// break for some reason that looks like if( true ) {break;}
}
if( a == b - 1 ){ exit; }
// do more stuff ( there's no else because I, the writer, know that EVERYTHING below here isn't actually running after this
Is terrible. The first one is something I've seen far too commonly, and it really is something you'd only find amongst people without a formal education of programming. The second is an example of vaguely written code. What is a? What is b? And why the HELL are you subtracting 1 from b without any context.
Use Enums to your advantage
Enumerators were probably one of my favorite additions to GML. They're a little spazzy in the actual IDE, but work nonetheless. A prime example would be when you want to use states. Enumerators will help you from the pitfall of using strings (or personal opinion the annoying macro editor) as your state instead of far more debuggable and easier to remember, thanks to the IDE, enumerator.
It will allow you to namespace your values that remain constant throughout the whole execution of your game and will provide you with a consistent and expected experience.
Use switches
If you have a lot "if {} else if else if" then, usually, it's time to use a switch statement.
Code:
if( a == b ){
}
else if ( a == c ){
}
else if ( a == d ){
}
// VS --------
// they do the same thing, but switch statements were made for these conditions and make it more obvious what's happening in your code.
switch( a ){
case b:
break;
case c:
break;
case d:
break;
default: break;
}
Use the data-structures provided by Game Maker appropriately
DS_etc's are an extremely wonderful set of data types offered in the Game Maker Language. But you have to use them where and when they're most useful. People who just start beginning typically get stuck using ds_list and ds_grid for everything they do because it's the most relatable to what they've already experienced. IE 1d and 2d arrays.
The other structures (queue, stack, priority, map), are also your friends. Priority's are especially useful for when you want to organize data by weights or importance, such as logging the instances closest to a defined point. Queues and priorities are great when you want a fast way to iterate through the most recent or least recent set of data you were working with. Such as aiding you in making an undo / redo system.
The ds_map is fairly the most useful, to me, because it closely represents the way Game Maker's properties work with objects. It's basically an object, without the overhead of being an actual object. You can use maps as if they were objects and give them variables you'll use for later.
Smaller but just as important points:
Don't start attempting to work on something in your "Huge omg so success" project, if you've never done such a thing before. Test it outside of your monstrously sized game.
Give everything you can a name. If you have an array of objects, that array is their general name.
Use the debug console as much as possible. Using "show_debug_message" is very useful when you're working with code you're unsure is working correctly.
Test, test, test. Make sure you're testing your new additions as you go, as much as possible.
Don't do EVERYTHING in your game programmatically. That will bite you later if you attempt to make 95% of your game code and the rest objects, sprites, and rooms. Good Example ( programming animations when you really don't need too )
MAKE YOUR CODE REUSABLE. If you have a system in your game that will most likely be used in multiple areas, and you find yourself copying/pasting a lot, make a script that you can call instead.
Not nearly enough people using Game Maker use a version control system. These can save your life in the future either by yourself, or especially in a team. Take a look at GIT.
Last point, this is strictly personal opinion:
Unfortunately, Game Maker is not the place where you should be learning the fundamentals of programming. You can obviously learn how to write good script, and do it correctly, but scripting in Game Maker is far less brutal than what it took to make Game Maker. If you ever find yourself wanting to learn a new language and make a game with it, you'll find yourself in a rude awakening. Although that may not be the case for everyone, I'm sure most of us can figure it all out for ourselves, but it is a reality. Once you've come to look at how to make a game using one the languages Game Maker compiles your code too, you'll be learning a lot more about how you should consider programming your game and how and what's working under the hood more or less. This can save you out a decent amount of the time when making your game, and more than likely does you more good than bad. Also, regarding videos on youtube, the best videos you'll be watching aren't going to be "How to make A or B in Game Maker", but things that cover the fundamentals of programming which typically don't exist in Game Maker video tutorials or at the same quality.
Hate or like my advice, you're right either way. It's your opinion.
This is what I used to call a Jolt-logic-inhibitor: You're tired. Your code won't work. The answer: more code! So, you drink a 6-pack of Jolt. Look at the code, but you're tired. Your code won't work. The answer: more code! So, you drink a 6-pack of Jolt. Look at the code... etc. It's a bad habit, and unless you've got a good backup, you might as well close down. I had to teach myself this, so I used to grab a hardcopy and read it instead of the morning paper. Such clarity a little sleep brings! Good Catch Frosty!
Jolt Cola was a beverage originally made by The Jolt Company, Inc. of Rochester, New York, which changed its name to Wet Planet Beverages. From the outset, Jolt's marketing strategy centered on the caffeine content, billing the drink as a means to promote wakefulness. The initial slogan was "All the sugar and twice the caffeine"; this slogan survived for 24 years.[3] This slogan was changed to "Maximum caffeine, more power".
Personally, I like more verbose variable names. I only shorten things if I'm going to have to type them A LOT. I find that remembering what an abbreviated name means, or spelling the abbreviated name consumes too many brain cells uselessly, and slows me down when I'm reading the code because I have to mentally unpack the abbrevs. Whereas, my style of naming variables makes the code I write read almost like prose, expressive and full of meaning, and I find it very easy to understand.
To be honest, it's very situational... if a variable is only used for a single thing, I tend to give it a very long name so that it's unmistakable what it does in the off chance I'd need to modify code using it, but I often try to shorten names of single-use-but-not-single-value data structures so that if I edit their initialization script later I can see all the data as well without having to resize or scroll the script window. But variables I use all the time gets away with very short names. For instance, in more or less all my games, there's local variables k_u, k_l, k_r and k_d representing the directional input status (Key Up, Key Left and so on) and I instantly know what they do, and I always use c for my for loop counters by habit (and then d, e, f and so on for nested loops). The key variables also get a bit of extra mnemonics because "k" is pronounced "key", but I'd use those abbreviations without flinching anyway because it's such a strong habit.
Using shorter, unconventional names is fine if you work on a project alone, and document your code somewhat.
As soon as you work on something in collaboration, or if you plan to share your code, its Mich better to stock to conventions and use longer names (within reason).
However, there is no need to go overboard. If you have a map of loged in player positions, just call it 'position_map' or 'player_position_map'. No need to call it 'Logged_in_player_position_map'; That's just silly.
You can always add more details with comments.
Something else that is truely important is to identify what you code does in a broader sence, and split it up into smaller sections. Then identify what each of those sections are doing, and split it up further. Then start to write your code. You will understand your code better, and make it much more reusable and readable.
One thing I've never quite liked is when people go "write self-commenting code, then you don't need to write comments anymore". It very easily leads to too verbose variable/function names in my opinion, and focusing too much on each step rather than the intention of a section of code, so that the big picture is lost.... and the code ends up being very hard to read by someone else in the end anyway. I personally more or less only comment on my code's intentions, on a per-block basis (usually around 2-3 blocks per screen of code depending on complexity of task), use hierarchical script naming with the most important part of the name first (e.g. inventory_item_obtain), and adding extra comments when the purpose of code is unclear or hacky/unconventional. For instance, if I start a for loop with "for(c = c; c < maxvalue;c++){", I'll add a comment that it's supposed to start at c because it continues a previously aborted-halfway-through loop. (The c=c statement technically isn't needed, but it's there for clarity in what's going on).
)
