I have here a couple of homing weapon scripts, taken from the GMC forums 2 years ago. They both use different algorithms, but both of them requires you to put the codes in the bullet object itself. These will cause the missiles to actively seek out the nearest specified instance, so for best results use a parent object. I managed to create a weapon similar to the Hunter shot from Thunder Force using the first one. Maybe they can help you out.BPzeBanshee wrote:- I want to make homing missiles that home towards ANY enemy. Havent figured that part out yet.
The way I used it in my old game prototype was to use a parent object, though. When I did this the projectiles sought out the nearest enemy object they could find and even changed direction once the original target had been killed.Code: Select all
//By Louis8k8
targetx = argument[0]; //The coordinates of the instance
targety = argument[1];
found = 0; //A switch to determine if a target has been selected, 0 means no, 1 means yes.
seek = 0; //Records id of object to trace
alarm [0] = 1; //An alarm-loop which chooses the direction of the object's movement
/*Find Object*/
//A counted loop that counts from 0 to the size of the room width/height which you need put in. Will exit if found = 1 (an object is selected as target)
//If object exists and distance to it is within the detection range "distance".
for (distance = 0; distance < room_height+room_width && found == 0; distance += 1)
if (instance_number (argument[4]) > 0 && distance_to_object (argument[4]) < distance)
{
seek = argument[4]; //The target is set to that object
found = 1; //Indicating that a target has been chosen so loop ends
}
Code: Select all
target_dir = point_direction(self.x, self.y, targetx, targety);
diff = ((target_dir - direction) mod 360 + 540) mod 360 - 180;
if (abs(diff) < 10)
direction = target_dir;
else
direction += sign(diff) * 10;
alarm [0] = 2;
Code: Select all
if (found == 1 && instance_number (seek) > 0)
{
target = instance_nearest (self.x, self.y, seek);
targetx = target.x;
targety = target.y;
}
Drum wrote:I approve of this, nice work!
Thank you!Could you be more specific with this? I know the script works because I originally put a small thing together as a Homing Missile Demonstration for the guy that did Breakforce but I could only ever get it to home into one enemy. Really it's only in there because I havent taken it out for saving space yet, and as you can see with the lives bar I've used the missile sprite for something else entirely.The way I used it in my old game prototype was to use a parent object, though. When I did this the projectiles sought out the nearest enemy object they could find and even changed direction once the original target had been killed.
Yeah, I liked the implementation of it. I should just change the event to Key Press Z and then an if clause and I think that should do the trick. I actually came up with the menu thing based on someone else's code example too but I couldnt see the guy's name in it at the time. He had three buttons that would play sounds like "IMA FIRIN MAH LAZERN *PEWWWW*" and stuff like that. Your idea seems good too, I could use that for multiple cases as a global switch.EDIT 2: I noticed that if you keep tapping Z after selecting "Start Game" it keeps playing the voice clip without starting the game, unless I wait for the clip to stop playing. Upon checking your code I realized you didn't put in a function to disable menu item selection after pressing Z in the Main Menu, so the Alarm event for the "Start Game" object kept re-initializing whenever Z was pressed (in fact I can still change the selected menu item with the arrow keys after choosing "Start Game"). Pretty lean code though, so all you need to do is put in a variable in obj_menucontrol's Create event that would allow the player to use the arrow keys and Z when true, and disable use of the keys when false.
I'll dig up what I can on those relevant threads when I get the time. Pretty simple, you just create a generic parent object which you must set all enemy types to, and then code your homing missile to seek out that parent object in its Step event. Depending on how it is coded (using instance_nearest is often enough), it will seek out the nearest instance of the parent object, which of course will be the nearest enemy. I can give you a short sample if you want.BPzeBanshee wrote:Could you be more specific with this? I know the script works because I originally put a small thing together as a Homing Missile Demonstration for the guy that did Breakforce but I could only ever get it to home into one enemy.
. I actually prefer the second approach I outlined above, which allows different missiles to lock on to different enemies.Yup, an If clause will do the trick, since you only need to call an action if the variable returns true.Yeah, I liked the implementation of it. I should just change the event to Key Press Z and then an if clause and I think that should do the trick. I actually came up with the menu thing based on someone else's code example too but I couldnt see the guy's name in it at the time.
Just send it to me via PM or something and I can muck around with the stuff for another major release. \ This is indeed the plan, though I must confess I do have ulterior motives in implementing functions into GMOSSE. Whatever I use here will be easily able to be implemented into the 'true game project' that I've been planning for a long time.Twiddle wrote:I suggest putting in a template for multiple ships / additional ships as this is intended to be more a tool than a game by itself.
Code: Select all
//reset speed to 0
xvel=0
yvel=0
//is slowdown key down
if (keyboard_check(vk_shift)) movespeed=2 else movespeed=5
//add movement
if (keyboard_check(vk_left)) xvel-=movespeed
if (keyboard_check(vk_right)) xvel+=movespeed
if (keyboard_check(vk_up)) yvel-=movespeed
if (keyboard_check(vk_down)) yvel+=movespeed
//speed limit (for diagonal movement)
if sqr(xvel)+sqr(yvel)>sqr(movespeed)
{
dir=arctan2(yvel,xvel)
xvel=cos(dir)*movespeed
yvel=sin(dir)*movespeed
}
//add speed to position
x+=xvel
y+=yvel
//clamp position
x=max(min(x,238),2)
y=max(min(y,318),2)
Code: Select all
key[1]=global.shoot_button
key[2]=global.up_button
key[3]=global.down_button
key[4]=global.right_button
key[5]=global.left_button
Code: Select all
var num;
repeat(5)//however many keys there are
{
num+=1
getkeynamescript(key[num],num)
}
Code: Select all
//(getkeynamescript)
//all of these values are reset to zero after this script ends
var num,kname,which_key;
num=argument0 //key id (ASCII)
which_key=argument1 //the key being redefined
switch (num)
{
case 37: kname="left" ;break;
case 38: kname="up" ;break;
case 39: kname="right" ;break;
case 40: kname="down" ;break;
}
keyname[which_key]=kname
\Code: Select all
ship=instance_create(argument0,argument1,obj_player)
switch (argument2)
{
case 0: ship.sprite_index=ship0_img;break;
case 1: ship.sprite_index=ship1_img;break;
case 2: ship.sprite_index=ship2_img;break;
case 3: ship.sprite_index=ship3_img;break;
}
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?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.
Code: Select all
health-=other.damageI used to do a variation of this actually, by using a parent object for all player bullets. It saved me a lot of time since all enemies merely had to register collision data from one projectile type and the specific objects would register their own unique variables afterwards.Rozyrg wrote: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 thanThat 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.Code: Select all
health-=other.damage
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.S20-TBL wrote: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?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.
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.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 thanThat 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.Code: Select all
health-=other.damage
This says it all. I salute you for braving this arduous territory at all.S20-TBL wrote:The problem was when I tried doing a 2-player setup; the whole thing went haywire
Ah, I see your problem. The thing is, if a Child object shares the same Event as the Parent, then that Child object's specific Event will override the Parent object's version, essentially nullifying anything you put in there. The best thing to do would be to take note of which object has which events and then avoid re-using them for any Child object.BPzeBanshee wrote: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.
So painfully true...after going through it all I was left thinking "Now I know how some of those doujins produce stuff so quickly..."Rozyrg wrote:So many things you take for granted having only one player ship and one score to deal with.
Here's the entry on Parent and Child objects from the GM8.0 Help file:BPzeBanshee wrote:And I'm not entirely sure what you're saying is right S20. I can see the logic in it but I couldve sworn I have create events that play out in parent objects and create events that play out on top of that in child objects. It just seemed to have only occurred in this case when passing more stuff towards the parent enemy object. I'll investigate this more in case there's further errors in GMOSSE that I dont know about.
As for instance_deactivate_object(); it actually disables the object instead of destroying it. This means you can reactivate it later if you wish. However, this feature will apparently be taken out soon and replaced with something else, as its current implementation in GM is buggy. I use it to turn off enemy objects when they go a certain distance outside the view instead of destroying them, so I don't trigger their Destroy event actions. But doing this multiple times in a row will actually cause GM to speed up the game's framerate by 100% for some reason (probably memory related), so it's not recommended for every situation.Often, objects should behave almost identically but there will be some small differences. For example, one monster might move up and down and the other left and right. For the rest they have exactly the same behavior. In this case almost all events should have the same actions but one or two might be different. Again we can make one object the parent of the other. But in this case we also define certain events for the child object. These events "override" the parent events. So whenever an event for the child object contains actions, these are executed instead of the event of the parent. If you also want to execute the parent event you can call the so-called "inherited" event using the appropriate action.
EDIT: instance_count(BPmustbesmokingweirdstuff) = 2;S20-TBL wrote:As for instance_deactivate_object(); it actually disables the object instead of destroying it. This means you can reactivate it later if you wish. However, this feature will apparently be taken out soon and replaced with something else, as its current implementation in GM is buggy. I use it to turn off enemy objects when they go a certain distance outside the view instead of destroying them, so I don't trigger their Destroy event actions. But doing this multiple times in a row will actually cause GM to speed up the game's framerate by 100% for some reason (probably memory related), so it's not recommended for every situation.
I used keyboard_wait and some other dirty stuff for my original school project that got my foot in GML to begin with, based on Mark Overmar's Space Cleaner example. Not very customisable though otherwise I would use it here too.Rozyrg wrote:I personally use the keyboard_wait for pausing the game; but yeah, it can be quite fidgety. Even having specific instructions to unpause with any of the usable keys (aside from the arrows/movement buttons), half the time it will only respond to the pause button itself.
(not ruling out that my code might just be ****y though.)
I remember the fun I had just getting it to display PAUSE with that method... oh boy.
