Hey all, so I haven't mentioned it here yet but I recently began working as lead designer on a small gamedev team. After looking into available tools we have decided to use GM:Studio to speed up development. One of the programmers is new to GM (He's a Java bean) so to help get us all up to speed I'm compiling a list of guidelines to make our lives easier. Now, I've only recently been getting back into GM so my memory on some of the conventions aren't the best. So far I've covered:
1. Prefix resource names (spr, obj, etc)2. Use GML not drag and drop3. Avoid built in globals (health, score, lives)4. DS are your friendsI'm trying to think of other little rules of thumb that we might benefit from. What are your best practices when using GM? What things should you never ever ever ever ever do? How can I make sure our code doesn't get out of hand?And as a final note, I'm actually looking to take in more programmers and artists for this project. What we're making is a 2d game centered around espionage/sabotage. We already have a couple designers, two guys on sound, one (maybe two) artists, and three programmers (including me). One of the programmers (not the Java bean) isn't sure if he can stay on so I'd really like to get more people just to be safe. So, if you think you can contribute, and wouldn't mind making some cash if (or when) this game turns a buck, feel free to leave a comment or PM. If you want more info, I can gladly provide it.Cheers
GM best practices #1: You do not use GM.
GM best practices #2: You DO NOT use GM.GM best practices #3: If someone says "stop", stop making the game.^ Mention using GM, you warrant getting these comments.
In all seriousness though, the practices should be the same as if you were using another language. You mentioned resource naming conventions, but also consider things like how you name your variables and scripts. If one person is writing a script used in more than one place, it'd be good to agree on a way to do it.Also, come up with a commenting system that is both explanatory and doesn't flood the screen. Come up with ways to handle things that everyone can understand, like whether you store data in arrays, structures, or objects.I'm mostly taking this from N-Tier influences where you have several "tiers" like data and presentation. Might be overkill for you but it's an interesting model anyway.EDIT: I missed Xemic's reference.Whatisthisfightclub?
Here's another good practice:
- Do not code like SerprexMinimalistic coding is great for efficiency but nobody else will ever understand it.A functional language is always the best choice.
I'd say treating GM like it is more strict than it really is should be a best practice. For example, always using semicolons and
Make everything up as you go. If you can't figure something out, google it or spam the IRC. If something takes a lot of work, it's probably the best solution, but see if you can work around it or come up with something easier. When it starts to get laggy cut the room speed in half and double all the speeds. When you use "//" to comment something out or label things or whatever see if you can draw pictures out of the text with it. Object names can be creative or they can be minimalistic. your_mom_is_a_whore and object53 are both pretty cool names for a couch. Scripts are annoying and should only be used as a last resort; copy and paste your codes instead. The best way to prevent theft from decompilers is to give all the important variables names like "haranekxneofpowesasdf."
I don't think there's really much of an advantage to not using the speed variables, GM is going to have them anyway so why reinvent the wheel.
Anyway the format stuff is important because it makes converting code to another language easier and it also just plain makes it easier if you are in the habit of always going those things.