64Digits

Posted by aeron on March 2, 2013, 3:36 p.m.

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 drop

3. Avoid built in globals (health, score, lives)

4. DS are your friends

I'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

Comments

Eva unit-01 11 years, 8 months ago

I'd say out of all those in the list, #1 is most important. I mean you can do all the below, but none of that matters if you can't find or differ your resources from one another.

Cesque 11 years, 8 months ago

On the subject of dumb advice:

Don't cycle through images. Make a separate sprite for every animation and change sprites instead, don't forget to regulate speed by creating multiple copies of every image in a row!

Quote:

This might work for AABB's but in all other cases I'd say no. Too many workarounds and conditionals doesn't make up for the small increase in precision. Neither SAT or GJK works like that. Try implementing a non static environment like this and you'll see what I mean. Do it the other way and see a world of possibilities unfold :)

…what? I admit I have no idea what SAT and GJK are, but I can see zero reasons not to check collisions before they happen. If you can move an object to a position, you can just as well check if it's occupied beforehand… right?

Haizen 11 years, 8 months ago

Trolls! The whole lot of ya >:O

Kunedon 11 years, 8 months ago

Quote:

Make a separate sprite for every animation and change sprites instead

A friend of mine actually did this for one of his games, granted he was just starting with GM at the time.

JuurianChi 11 years, 8 months ago

Wait.

I'm confused.

Is any of this good advice.

What the fuck you guys.

Quietus 11 years, 8 months ago

Quote:

Make a separate sprite for every animation and change sprites instead

A friend of mine actually did this for one of his games, granted he was just starting with GM at the time.

when you have sprites like "start walking", "walking", "stop walking" etc, it's usually good to have them all separate. can't see the benefit of having it otherwise.

my advice is get comfortable using particles and blend modes. primitives can be helpful. it's all about how games look these days, you gotta make it candy.

Kunedon 11 years, 8 months ago

Quote:

when you have sprites like "start walking", "walking", "stop walking" etc, it's usually good to have them all separate. can't see the benefit of having it otherwise.

Oh, hmm. I read that wrong, then. I meant that he had separate sprites for each FRAME of animation for one action, and used alarms to animate the character.

Glen 11 years, 8 months ago