Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Cthulhu]

It's a loincloth.  It's more obvious when shaded.

[Aqizzar]

It would be more obvious if it wasn't a similar color to his skin.  The cyclops being stark pale is creepy and all, so maybe the loincloth should be a very different color.

Sorry about using your thread to document my own problems with GameMaker, but hey, this is where the discussion is.  Anyway, figured out the strip-spriting thing.  Stupid tutorial.

[chaoticag]

GM8 does it automatically, and those tutorials were made for GM8.

[Cthulhu]

Update:  He has armpit hair, and his eye bursts when you kill him.

[Cthulhu]

I have some serious bugs I can't figure out.

How do you keep things from getting stuck to objects?  Goblins and stuff will walk into a wall and dig themselves into it trying to move away.  The cyclops does the same thing when it charges.

[Chutney]

It's probably a problem with the animations changing. If you're using pixel perfect collisions: don't. Set hitboxes to slightly smaller than the actual sprite. It would also be good if when a collision was detected, it pushed the objects away from eachother so no more collision is detected. this should fix your probs, broski

[dragnar]

I believe game maker's collision code works oddly if not all the colliding objects are solid. If that's not checked on any of them see if that helps.

[chaoticag]

Another way is to check whether the solid object is not a certain distance away from something before moving in that direction.

[Cthulhu]

Alright, taken all of that into consideration.  Making everything solid seems to have greatly helped, but there are still some kinks I need to work out.  I have an idea for them though.  The deal before was that it would let them have one step even if they were colliding, so when they tried to move they'd dig into the object and get stuck.  Changing animations also had some issues with some monsters, especially the cyclops, who would turn and his head would be buried in three feet of wall.

Solid thing works, great.  Would you believe I was this close to giving up?

The problem was I was setting up a rough playable alpha demo with five rooms, three enemy types, and one boss.  Nothing was working like it was supposed to, and I was getting discouraged.  Now I'm afraid of burning out, so I've been putting in some mandatory Earthbound and Doing Stuff That Isn't Internet time.

I don't think I'm ready for that demo though:

AI is funky, I'm probably going to have to redo a lot of the enemy code
Rooms are too big.  640x480 when your guy is 32x32 leads to a lot of running around not doing anything, and there's too much open space for the enemies to provide a challenge.

[Aqizzar]

Time for more "Aqizzar Hijacks Cthulhu's Thread Because People There Know How To GameMaker".  Two questions.

I haven't actually dealt with the parent-child object relationships yet, but that will probably be the next thing I work on after basic spawning.  Before I stick my head too far up my ass in pursuit of the wrong solution, and an object be both a parent and a client?

Here's what I'm thinking - A shoot'em'up, where enemies spawn (child from parents I assume), but instead of emitting gunfire themselves, they would spawn along with invisible fire-emitters.  The emitters would then move with the main enemy, and die along with it as well.  Would the emitters be children to the enemies, who would themselves be children to enemy-parents, or would the emitters have parent-emitters, and the enemies and emitters would just have to know to spawn together the right way?

Second question: Which is the better way to confer airplanes flying through hostile skies - top-scrolling or side-scrolling?  More of a graphic and presentation preference, but I'm wonder which people like more.

[Cthulhu]

This probably isn't the right way, but I'd have a master object for each enemy class or whatever, and that would be the parent of a certain group of enemies (Guys what go in S shapes, guys what kamikaze, etc).  Then I'd have the spawners lining the top (Or right, if it's sidescrolling) edge of the screen with timers and the like to determine spawn.  They could spawn fire-emitters at the same time, which would have the same movement pattern as the planes they're emitting.  They could probably even have the same parents, but you'd have to create useless events to overwrite stuff meant for the planes.

Also, you'd need a way to kill the emitter when the plane dies.  Maybe the plane destroys everything in its square when it dies.

[Cheddarius]

Yeah, but think about how much you've learned, Cthulhu. Firstly, making the game now will be a breeze compared to before, and secondly, if you do finish you'll learn even more and perhaps be able to create really awesome games, and thirdly, if you finish you'll have sort of generalized knowledge of how to finish things, probably, and maybe you'll finish other stuff.

[Cthulhu]

Yeah, I'm back on track now.

[Aqizzar]

This probably isn't the right way, but I'd have a master object for each enemy class or whatever, and that would be the parent of a certain group of enemies (Guys what go in S shapes, guys what kamikaze, etc).  Then I'd have the spawners lining the top (Or right, if it's sidescrolling) edge of the screen with timers and the like to determine spawn.  They could spawn fire-emitters at the same time, which would have the same movement pattern as the planes they're emitting.  They could probably even have the same parents, but you'd have to create useless events to overwrite stuff meant for the planes.

Also, you'd need a way to kill the emitter when the plane dies.  Maybe the plane destroys everything in its square when it dies.

I do really like the idea of having static enemy-generation-markers outside the screen (or something similar), because good spawning is hard to pull off.  I'd rather have the emitters tied a little more firmly to the enemies, so I can guarantee they die at the same time.  There should be some way to spawn client emitters from a master emitter-object, but are also keyed to specific enemies spawned by their own master-objects.  They're two different ways of achieving the same effect, but I feel like the emitters being free-floating objects that rely on nearby deaths telling them to die too leaves too much room for error and hiccups.

[ILikePie]

Here's what I'm thinking - A shoot'em'up, where enemies spawn (child from parents I assume), but instead of emitting gunfire themselves, they would spawn along with invisible fire-emitters.  The emitters would then move with the main enemy, and die along with it as well.  Would the emitters be children to the enemies, who would themselves be children to enemy-parents, or would the emitters have parent-emitters, and the enemies and emitters would just have to know to spawn together the right way?

Use parents when you have two or more objects that need to have something in common. If you have multiple kinds of emitters/enemies, have a parent object set up for each with what ever they have in common. For example, and enemy could have health variable, instead of setting this for each and every kind of enemy, set it once for their parent. Don't have the enemy be the emitter's parent (Or vice versa) unless they have something in common.

Edit: Once the enemy spawns, tie his emitter to him through some variable. If you're going to have the emitter move along with the enemy you might have to this eventually (my_emitter.x = self.x, etc.). Then just have a function that kills my_emitter when the enemy dies.