Print

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

[Cthulhu]

Maybe I'm misunderstanding what you're saying, but parent and child objects don't have any actual connection beyond inheriting events.  A parent object will not spawn child objects, and if you add an event like that, the child objects will spawn more of themselves.

[dragnar]

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.

Why not just have the enemies spawn projectiles every some number of steps? There's no need for a separate emmiter.

[Aqizzar]

Why not just have the enemies spawn projectiles every some number of steps? There's no need for a separate emmiter.

A) I don't want the gunfire to be emitted from the center of the enemy graphic, or I want it to be emitted from multiple points on the graphic instead of just the origin point.
B) I'd rather not define a new attacking event with every enemy type.  (So much easier to define a new object-spawn with every enemy type instead, of course.)
C) I'm trying to push myself to learn new techniques and programing-thought, instead of just taking the easy way out every time.

[Cthulhu]

You can specify where on the sprite the projectile object spawns by setting the relative x,y coordinate.

[ILikePie]

A) I don't want the gunfire to be emitted from the center of the enemy graphic, or I want it to be emitted from multiple points on the graphic instead of just the origin point.

Set the gunfire's start position then, iirc its as simple as setting a single variable

B) I'd rather not define a new attacking event with every enemy type.  (So much easier to define a new object-spawn with every enemy type instead, of course.)

Use parents then, that's what they were made for. Have one super enemy with the attack event and make the rest children of said enemy. The emitted projectile can also be overwritten if you want a special projectile for each enemy.

C) I'm trying to push myself to learn new techniques and programing-thought, instead of just taking the easy way out every time.

This is actually more bug-prone than just having enemies shoot the projectiles themselves.

Edit:
goddammit, you guys post quickly.

[Aqizzar]

Yeah, I just realized after writing that post that I change the relative spawn point of the fire.  Telling the different kinds of fire to originate from different relative coordinates is a million times easier than making a whole other population of objects to fly in invisible formation and do the same job.

Still can't decide on top-scroll or side-scroll.  I'mma go play some Genesis shooters and see what I decide.

[Cthulhu]

It recently crossed my mind to make a top-down zombie shooter.  Something like The Last Stand, but you actually have to go out and find stuff during the day, not just check it off.  Plus barricades and stuff.  I dunno.

Hrm....  Damn, I'm starting to hit on stuff I'm not sure how to deal with.

Alright, cyclops miniboss works like this:  He spawns idle, and when you get close to him he starts throwing rocks at you.  If you hit him, he flashes red, jumps up and down angrily, and then charges you.  He's pretty easy to dodge, but if he hits you he won't continue on his path no matter what.  I'm not sure what's causing this.  I think it's because he's charging toward your position, and since you're not moving he just stays there.  Is there a way to make him continue on that path?

[ECrownofFire]

Could you temporarily make him not-solid? I've had some experience with GM, but I haven't really made anything, though I think that this is possible.

If you need to, you could make it so that when he charges, you check for the wall in the line that he's charging down, then calculate how many steps it will take to get there, and not get stuck. Just make him move for X amount steps or something. I don't know how well this would work, I'm not even sure if it's even necessary.

[Cthulhu]

I dunno, I'm thinking about rewriting the player entirely.  It's really cobbled together and getting to the point where doing anything will break him in some way.

[chaoticag]

Can I have a look at the code thing? I might find out what is causing it.

[Cthulhu]

I'll do you one better.  Here, now everyone can see just what I've been doing with my time.  Maybe it'll even help me figure out how to make this work.  Note how a few days in I stopped marking the design doc.  I am horribly unorganized when I work.

[chaoticag]

I can't seem to find a cyclops object. Are you sure you uploaded the right file?

[Cthulhu]

Oh, I deleted the cyclops an hour or so ago because I was just going to redo it, and then I got disheartened.  :\

[ILikePie]

Backups are your friend. :0


I'm in desperate need of something to do. You guys need any sprite work by any chance?

[Cthulhu]

I have a backup, but it's pretty old, I'll see if the cyclops is on it.

Yeah, Backup's from before I put the cyclops in.