Sarcastic Game Dev Improvement Tips for GMS2

Rob

Member
[Make sure you use a different object for everything!]
  • Got 10 different weapons? Make 10 different objects for it!
  • Making a dungeon crawler with 20 different heroes? One differently-named object for each hero please!
  • This will mean that you'll probably be copying/pasting code a lot and maybe making small changes to each object - yay!
  • Don't bother making a script that can be used in each of your 75 hero objects either as it's much more fun to make copy/paste errors that will cost you a few dozen hours down the road.
  • You can also look forward to making as many changes to the SAME code as you have objects, with the definite possibility of making more copy/paste errors.
  • Why update code once when you can do it 20 times!
[If you're making a game that includes stats absolutely DO NOT use arrays or data structures]
  • Only use variables that are different for each of your 20 heroes and absolutely DO NOT try to think of any way in which these objects can in fact, be the same object.
  • The extra functions that are made for data structures will prevent you from being able to spend hours and hours working on features that could be done with a couple of well-placed data structure functions
  • Make sure you copy code directly from tutorials but don't worry about understanding it.
  • If it works now, you can completely forget about it as you won't be scratching your head in 3 months time wondering wtf the code actually does.
[ABSOLUTELY DO NOT bother to put comments in your code - ESPECIALLY if you didn't understand it in the first place]
  • In no way should you waste your time learning new things. It will only take time away from the 2000 lines of code that you need to update line by line in your epic RPG because that's a far better method than using a for loop and array
[Under NO CIRCUMSTANCES should you use the manual..]
  • Have you seen the size of it? Who the hell would read all that?
  • It doesn't make any sense anyway so why bother?
  • If you're having problems with a certain function just blame your logic and try random things until everything works properly.
[DO NOT DEBUG!]
  • Why bother taking the time to check the values of variables when it's obviously this other thing that you just did?
  • It's not like you need to make sure there are no logic errors. As long as you fix the current issue, things definitely WILL NOT bite you in the bum down the road.
  • What even is debugging anyway?
[If you get an error, don't bother to read the error message!]
  • It's all gobbledygook anyway.
  • It must be a logic problem because you didn't understand what you were doing anyway, right?
  • It's definitely not, 9 times out of 10, a typo or copy/paste fail - especially if you got that code from a tutorial (the code in videos never works properly!)

[When you inevitably get stuck and ask for help, make sure to spend ZERO time thinking about your question]
  • As long as you say things like "It doesn't work", that's enough.
  • These other guys will instantly know what you're asking because they're stupid enough to know more about GML.
  • If you don't understand something, don't bother asking for an explanation. They might be trying to teach you something and you DEFINITELY don't have time for that. It will just take time away from your project.
  • If they say something you don't understand or ask you a question that's nothing to do with what you asked, just ignore them, they're obviously wasting your time!
  • Don't bother to take any initiative at all - blindly copy/pasting into different events will eventually get you the desired result.
  • If you copy/pasted code and it didn't work IT'S DEFINITELY NOT YOU that is the issue. Blame the helper.
Be safe in the knowledge that all those hours you spend changing the dozens/hundreds of global variables every time you want to change the game is DEFINITELY worth all the hours you're putting into it and this is QUALITY dev time.

I had to get that off my chest in a hopefully-humorous way... no offence intended and I hope I don't scare anyone off asking for help - this community is how I got started and has helped me a bunch and I like to return the favour!
 
Last edited:

K12gamer

Member
Make sure the cut-scenes use more memory than the actual game.
(The best games today use at least 65GB of memory with 50GB of that used by real time cut scenes)
Cut-scenes should appear every 1-2 minutes...to break up the action.
Also...make the cut-scenes super long and unskippable. :oops:
 
Last edited:
D

DarthTenebris

Guest
Who needs brackets anyway? They're ugly and confusing. Just let the system do it for you and rely on operator precedence, especially when you're planning to port your first 3D FPS RPG game to all the possible export platforms. It's not like it's going to cause weird inconsistent issues down the road.

Why use variables? They require memory to be allocated dynamically, which is bad for your first multiplatform 3D FPS RPG game. Just type in the numbers directly into your code. How do you get those numbers? Keep trying random numbers until everything looks right. Definitely won't cause scalability issues for people with different aspect ratios on their monitors.

Whenever you have a problem, don't post your code with the [ CODE ] tags. Instead, try reading your code aloud and recording it to make an audiobook of your code (source). Since we can't post audio files here on the forum, you'll have to upload it to youtube where it definitely won't be compressed and horrible to hear.
 
Last edited by a moderator:

Rob

Member
Hahah @DarthTenebris thanks for reminding me about the brackets (not guilty) and numbers (guilty)... I remember positioning things with magic numbers and then having to change them all every time I wanted to add things or change things...
 
Z

zendraw

Guest
first of all, your criticism makes sense only from a programmer`s standpoint. as a designer you want ready objects to place in the room without opening thery create event. and it is very dependant on the game. if the designer needs to place objects in the room, he needs those objects availible, without messing with the create event in the room. thats why you have parents.

again this depends, it is far better to have individual variables then an array of variables. lets say you have 100 unique perks. even if you look them up 1000 times, if someone asks you whats perk 53 youll have to look it up, and when your gona constantly use that perk variable in the code, imagine looking it up all day long. putting them in an array gives absolutely no benefits other then being able to effectively listing them out, in shor easy access. nothing else.

i agree only if comments are short and dont occupy all the free space around the rest of the code. if y ou need to write an essay to explain the damn code, then you wrote a bad code.

the rest are for total noobs so i have nothing on them.

overall your criticisms are not so good, you dont mention atall bad and messy code, as if it is okay to have 100 lines of code for somthing that can be written in under 10 lines. not to mention coding manners that requires pressing extra keys, like obj_Player, MACRO_VAR and such. this is not good in the long run even using the damn _ is too painful... and these practices aways come from people who code for couple hours a day or somthing like that and care about theyr code being well decorated and beutiffle. you will never code somthing big like that.
 
Last edited:

Mercerenies

Member
first of all, your criticism makes sense only from a programmer`s standpoint. as a designer you want ready objects to place in the room without opening thery create event. and it is very dependant on the game. if the designer needs to place objects in the room, he needs those objects availible, without messing with the create event in the room. thats why you have parents.
Okay, I partially agree. You should still code it to minimize repetition, doing fun stuff with parents to reuse similar code. If your designer wants separate objects, fine, then make a child object that does the bare minimum necessary to get to the desired state. But reuse as much code as possible upstream.

again this depends, it is far better to have individual variables then an array of variables. lets say you have 100 unique perks. even if you look them up 1000 times, if someone asks you whats perk 53 youll have to look it up, and when your gona constantly use that perk variable in the code, imagine looking it up all day long. putting them in an array gives absolutely no benefits other then being able to effectively listing them out, in shor easy access. nothing else.
This is where OOP shines. Put all the perks into a big dictionary (or an array with a bunch of macros defined to make indexing easier), and have them be objects describing any state you need of them. Why go to the trouble? In addition to listing them out for debugging purposes, which you already pointed out, it also trivializes serialization. Rather than having to save 100 different variables to a save file, we just save a big dictionary, which is (depending on how complicated your perks are) either a for loop or (ideally) just a json_encode call.

i agree only if comments are short and dont occupy all the free space around the rest of the code. if y ou need to write an essay to explain the damn code, then you wrote a bad code.
I have nothing to say here. I agree. More comments does not necessarily a good programmer make.

obj_Player, MACRO_VAR and such. this is not good in the long run
W-what? You don't see obj_* in big productions? Try working at any given big corporation. Those people can be crazy strict about linting and style guides, to the point of insanity sometimes. We have a word for a startup which doesn't use any kind of naming convention: failing.
 

MissingNo.

Member
W-what? You don't see obj_* in big productions? Try working at any given big corporation
Yeah I agree but I always wondered why Game Maker doesn't have a automatic prefix or suffix feature. I already get enough strain from clicking and typing and the unnecessary
repetition doesn't help with that.

I'm sure some programmers are going to scoff at that idea because it goes against tradition, but honestly heading into 2020 it baffles me prefixes and suffixes aren't automated in most programs.
Seems like something the program could handle easily.
 

Mercerenies

Member
I'm sure some programmers are going to scoff at that idea because it goes against tradition, but honestly heading into 2020 it baffles me prefixes and suffixes aren't automated in most programs.
Seems like something the program could handle easily.
They're called sigils, and some programming languages have them. Old BASIC dialects would suffix all string variables with $. In Perl, scalars (numbers and strings) are prefixed with $, arrays with @, and hashes (dictionaries) with % (plus a few more obscure sigils for things like subroutine references and globs). I think that paradigm is falling out of style in favor of static typing: no mandatory sigils, but if you use a variable the wrong way you still get compile-time feedback on it. You do still sigils appear in more modern languages, primarily in type signatures. Ocaml uses a single apostrophe prefix to denote type variables, and Rust uses the same to denote lifetime variables. But in terms of the value language, you don't really see them that much anymore.
 

Rob

Member
Code:
first of all, your criticism makes sense only from a programmer`s standpoint. as a designer you want ready objects to place in the room without opening thery create event. and it is very dependant on the game. if the designer needs to place objects in the room, he needs those objects availible, without messing with the create event in the room. thats why you have parents.
Well yes, this is about programming - maybe the title was misleading and I should change it to "Programming" rather than Game Dev?

The only benefit I can think of for multiple objects is for placing things in a room eg multiple different types of platforms (different sprites etc) but... again if you have many many objects it becomes a horrible mess and there are better ways to add things to rooms (like tiles). If tiles are limiting because you cant add/change variables to them in the room then the same can be said of objects - because having a different object for everything means you've already got the code inside each one already, surely? You can always make your own map editor too - which is pretty simple once you have a decent knowledge of GML.

Parents can be useful for grouping up and affecting different objects and if all of your code is within the parent and you dont need to make multiple changes to the same code because it's in different objects then in my opinion that's a good way to do it too and multiple objects could be a better option than single objects.

Maybe there are even better ways to do things that i don't know about (I'm far from Pro, I'm sure) but this Sarcastic Game Dev Tips thread is based on code that is definitely not an optimal way to go, and will take up many more hours of dev time and cause problems that would not otherwise exist.

Code:
again this depends, it is far better to have individual variables then an array of variables. lets say you have 100 unique perks. even if you look them up 1000 times, if someone asks you whats perk 53 youll have to look it up, and when your gona constantly use that perk variable in the code, imagine looking it up all day long. putting them in an array gives absolutely no benefits other then being able to effectively listing them out, in shor easy access. nothing else.
Well yeah I can imagine that would be a problem if you didnt know what enumerators were. I've spent my fair share of hours using arrays without enumerators and... with enumerators it's so much better (and just as readable as variables / globals!)

Code:
i agree only if comments are short and dont occupy all the free space around the rest of the code. if you need to write an essay to explain the damn code, then you wrote a bad code.
The point was that some people do not use comments even when they're using code that they dont understand. How can they expect to fix anything or know wtf is going on a few days, weeks, or months later?

Code:
overall your criticisms are not so good, you dont mention atall bad and messy code, as if it is okay to have 100 lines of code for somthing that can be written in under 10 lines. not to mention coding manners that requires pressing extra keys, like obj_Player, MACRO_VAR and such. this is not good in the long run even using the damn _ is too painful... and these practices aways come from people who code for couple hours a day or somthing like that and care about theyr code being well decorated and beutiffle. you will never code somthing big like that.
Well between GMS1 and GMS2 I have 3k hours and my fingers haven't fallen off yet from using prefixes (and they also prevent me using the same names for different things).

As for "overall your criticisms are not good" I don't think you've had the pleasure of trying to help someone who is not interested in learning, and who just wants the code to do the thing that he can't do because he limited himself to global variables.

One of my very first games was a stat heavy monster breeding game and I went into it with no knowledge of arrays / enumerators or anything like that. Over a year I learned better ways to do things and I was disgusted that I wasted so many hours changing globals when there were better methods. I don't know if some part of this thread annoyed you but I can definitely say that my criticisms were spot on from the past few 3-4 years of me learning GML and trying to help others out of the same dev-holes I used to be in.
 
Last edited:
Z

zendraw

Guest
ofcorse there are better ways, if you want advice, learn to use the basics like if else, while, with for switch, in the best way possible, and then you wont have trouble. for instance you can put anything in a states system, the game itself aswell. reason being, anything that is persistent, yet can behave diffrently depending on X, can be put in a switch. your monitor is persistent what happens in your game is not. so when starting a level you can define how it plays, like a movie.
 

Gamebot

Member
Don't allow the ESC key to exit your games...
Have players use CTRL + ALT + DELETE (then the End Program prompt from the task manager) instead.
Good thing the only keyboard your allowed to use is a special keyboard made for that game with jumbled letters and numbers. Which by the way only allows two keys at once. Oh well try CTRL-ALT-DELETE anyway.
 
lol, nice tips, heres mine :)
" do not work on your project, you'll never finish it, what are you thinking??"

but really, sometimes have a different object for every npc or weapon is good...
 

K12gamer

Member
If your game is an app...make it FREE...but put in tons of lame non game related ads.

Have your game glitch / slowdown if the ads appear alongside game play.
Periodically have the ads obscure important parts of the screen...making the game unplayable.

Oh...and for future apps...make players buy a retinal scanner..to make sure they watch the ads...and
don't simply walk away and wait for the ads to end.
 
Last edited:
- NEVER back up your work, and don't even dare to think about using source control!

- Don't use meaningful variable names that make your code easy to read on its own.

- If your game is a little sluggish in the FPS department, just bump up the system hardware requirements in your game description. This way you don't have to waste time using the Profiler to find out what's making your game slow, and players can use it as an excuse to buy a new computer.
 

K12gamer

Member
If you're 100% human...only use Drag and Drop...because only people with Alien DNA are smart enough to make games using code.
 
Last edited:

TsukaYuriko

☄️
Forum Staff
Moderator
As long as you say things like "It doesn't work", that's enough.
I hate you with a burning passion. <3
This sounds like something you'd end up with after my mind finally breaks from being locked up in a basement for a couple of weeks while forced to read every topic that pops up in Programming. :p


There's already a lot of incredibly valid advice for the most common aspects in the opening post, so let's see what other stuff several years of pent-up frustration from moderating Programming and Collaborations and working with various teams of incarnations of incompetence (disclaimer: not referring to GMC, referring to prior and current jobs :p) can come up with...


[Working with source control]
  • Don't bother with writing informative commit messages. Nobody looks at these, anyway. Just use haaaaaaaaands for each of them.
  • Make every commit as big as possible. Making multiple smaller comments takes more time and is therefore inefficient - in that time, you could be working on another thing to cram into the next big commit.
  • Don't test your code before committing it. Don't even run the project once. Source control is used for backups, after all - if it doesn't work, you can always fix it in between commits.
  • Commit absolutely everything, including the views. As they say, everyone on the team should be working with the same tools.
  • If you want to share files with your team, commit them to the repository. (I didn't make this one up. WE HAVE A TEAM AT WORK THAT DOES THIS, not even due to not knowing better, but due to finding alternative solutions too bothersome.)
  • When not working in a team, don't push your repository to an online repository hosting service. People might hack your account and steal your glorious game idea, so it's a risk. Save it on your hard drive, and only there. If the hard drive dies, your game idea is protected from theft, which is good for security.
  • Don't make different branches to work on unrelated features. It will only confuse you to have to remember which change is on which branch. Having to merge branches also adds more work, but you don't get more done than if you work on a single branch.
  • If the repository becomes too big, delete some of the history to free up space.

[Collaboration]
  • Don't work alone - let others do the work for you, for free. Working and paying people to work for you are inefficient uses of your time and money.
  • Present your project well to leave a good first impression when recruiting people in your Collaboration topic.
  • It is important to comment your code when working in a team to help with understanding it, so comment your code in your native language so that you can understand it well.
  • If you don't know how to do something, don't ask others for help with it. Ask them to do it for you instead. Or just don't do anything about it, they'll notice it once it's far enough down the backlog and do something about it in record time.
  • Keep the documentation in a central place where everyone can access it, such as a flash drive that's passed around the office. The last person that used it will know where it is.
  • If the flash drive method outlined above is insufficient for your team's needs, either due to people losing or forgetting where the flash drive is, keep the documentation on multiple flash drives.
  • When not working together in an office, whenever you make a change, make sure to always send an e-mail with the latest copy of the documentation in a ZIP file to all members.
  • The documentation consists of a lot of text, so use a word CPU to write it. CPU is the technical term for processor, but make sure to always use technical terms to appear proffesional. Ensure that you can explain all of the technical terms you use, though, as some of your coworkers may be more stupid than you and won't know the technical terms.


I'm sorry.
 

Mercerenies

Member
Make sure to never write functions. Who needs those when you can just copy paste your common code everywhere?
Can you imagine? If I wrote functions, I'd have to have a call stack, then you've got a stack trace to deal with, and who wants that noise?

Plus, if you write your whole game in a GM extension, you can use C++, which is obviously superior as it has goto's.
 

Lukan

Gay Wizard Freak
Don't work alone - let others do the work for you, for free.
I feel like everyone is still jabbing me for stealing all of Ninety's free time for art and music.

Also, who has time for Shaders and other essential features that have been added over the years?
Write all of your code in GameMaker 8.1 and port up for the best possible results!
 
Last edited:

otterZ

Member
This thread is great :) Here are a few more tips and a few for putting games up on Steam too:

1) When you buy GM2 make sure to use your GM2 password and details to log into the Gamemaker Community Forums. (I actually did this lol)
2) Don't bother working on small projects when you first begin, just take on a huge long scope project instead.
3) When putting your game up on Steam, don't double the time you need because it will take longer than you think - this is obviously wrong! Halve your release date instead!
4) Don't spend a lot of time on building your Steam store page, just wait until a few days before - don't do a video as that just wastes time.
5) Do not put a clear release date for your Steam game - just put up 'when it's done' - as it looks far cooler and much more focused, plus it gives players confidence in your planning and finishing abilities.
6) Only let close friends play test your game as we don't want to get constructive criticism as it will only make us feel bad.
7) Aim to make your first game as huge as possible, with as many features as possible - cram it all in.
8) No need to make a strong theme or purpose to the game, after all you can just put up that it's 'Rogue-like' - that should do it.
9) Don't bother with marketing, people will find your game on Steam anyhow, no worries.
10) When making a game, just complete the first 20% as that's the most fun part; just give up making the game when it comes to all the hard dark work like level creations, marketing, testing etc. - just start a new game. In fact, do this multiple times so that you will eventually have a huge confidence boosting portfolio of unfinished games.
11) When using GM2 make sure to scowl at others using different game engines, especially Unity. If any Unity users try to talk to you, just start arguing with them from the get go & hope for a fight.
12) Don't have fun making games whatever you do. Making games, like everything else in life, is serious. Life is just a chain of serious events happening one after the other eventually ending in death; so don't be misled by people pretending to have fun between life's tragedies.
 
Last edited:

Amon

Member
Always assume that forum members are using the forum dark skin and pretty up your text with colours that make it unreadable for people using the light skin.
 

woodsmoke

Member
Me reading this thread:


I really should use parents more.
I'm more of a artist/designer than a programmer, and not all that serious about gamedev either.
Brute force that code!
 
Last edited:
  • Like
Reactions: KPJ

K12gamer

Member
Put lots of tiny sub-screens in your games with text so small...only players with 20/10 vision are able to read it.

.....
 
Last edited:

Evanski

Raccoon Lord
Forum Staff
Moderator
Never under any circumstance post any of the code you have when you have a problem, everyone knows what your talking about there programmers
 
Never under any circumstance post any of the code you have when you have a problem, everyone knows what your talking about there programmers
Better yet...post your entire project zip in your first post. Don't waste time writing a descriptive post title, "Need Help" will do and gets straight to the point without wasting everyones time. Don't tell anyone what the actual problem is, it's more fun for others to try and guess what the problem is! Don't mention what version of GMS you are using either, people might hack your license! If no one responds immediately, be sure to bump your post every 10 minutes or so to wake everyone up because everyone lives in the same time zone.
 
J

jcg3729

Guest
As a new user for GMS these are some good tips especially about posting!
 

K12gamer

Member
To guarantee your game's success...be sure to include a few HOT female characters in it...even if the game you're making is Pong.
 
Top