S20-TBL wrote:BPzeBanshee wrote:- Enemies need redesign. Changing damage to health variables for individual enemies seems like a bad idea and last time I tried making a parent object for this it failed. I was an idiot and should be able to do this properly now providing I figure out how I'm going to set up hp as a local variable for enemy objects and yadda yadda.
What do you mean by this? When I checked your local variable handling for enemy health, it looked pretty fine to me. Do you mean that you want to set up a universal system for handling enemy health for entire groups of enemy subtypes?
This, precisely S20. While the method I had worked, I realised there was a much more optimal way to handle enemy collisions for general things so I thought I'd do something similar to the player ship system.
As of now, I've gotten this working and converted all ships to this form - but I came across an interesting error while doing so. It seems that having anything in the parent enemy object (I used obj_enemytarget, which was already a parent object in GMOSSE purely for the homing missiles) with Begin Step is not read when the child object has a Begin Step event as well. This caused me some grief because while the normal rotating enemies worked fine with the method I had, the boss objects didn't. So what you'd see was, upon health reaching 0 for the orbs, they didn't die and kept on attacking.
This happened because I changed all the 'upon health reaching 0' commands to straightout commands within User Defined 15. obj_enemytarget will call this when enemyHP <= 0 and each enemy has their own enemyHP set to a number within themselves upon creation. This command to go to event_user(15) was in the parent's Begin Step event, and so was not read by the boss objects which had their own Begin Step event, but was read by everything else I made work with this method because they only used Step.
I dont know what the problem is, but I'm guessing it's something I wasn't taught about Game Maker itself and will probably find something about it anyway.
Rozyrg wrote:Yeah, I'd definitely recommend doing parents for the enemies. There's nothing to it, either really.
All of mine use a
master_enemy object for a parent which has all the basic collision events and stuff like how far it should be off the screen before it dies (I usually base this on it's
sprite_width, sprite_height, etc.) The trick is not to bog down the base parent with a bunch of really specific stuff only a few enemies will use, you can easily make sub-types that add different features or just build these onto the enemy obj itself.
Something else you could do is give the player bullets a damage variable on their creation script, so that the collision with an enemy is no more complicated than
That way you can change it on the fly and reuse the same bullet obj for different weapons. I know what a hassle it is to add collision events for dozens of bullet types..lol.
I've already come up with a good working method of doing this, but you've brought up extra things I did not consider putting to the parent object. Stuff like how far it should be off the screen before deletion I've done within the objects themselves and tweaked them slightly because I made the mistake of giving them an Outside Room event, which they spawned in to begin with and thus never appeared on the game screen.
So, now my list goes as follows:
- tweaking the power of player ship shots (setting obj_homingmissile's damage to 1.00 made it OP, and the Invader needs a small rebalancing of spread/power yet)
- thinking of how I'm going to make Invader's bomb, Im thinking of a bullet-cancelling line barrier like Hikaru's KIKU beam but Space Invaders style

- will do INI file support after making the bomb, containing option to change TATE settings.
- redo enemy patterns to timelines, not looking forward to doing this but it's necessary nonetheless. It will fix all remaining unintended timing problems with the boss and make things visually easier for creating bullet attacks.