[mentisworks]

Hi folks, as you can clearly see I'm new here . Also, I'm new to GM so I hope you're not too sick of newbie questions!

I've been working on a little shooter, learning from the shooter tutorial, and I have reached the stage where I wish to add a boss fight to my level. My initial try seems to have gone awry pretty quickly.


Here's what I would like to do:


1. Create the boss object off screen, and have it move towards the center of the screen, then stop and stay there. This is the first level boss, so it requires no additional movement.

- Using a controller object, I am generating the boss at x(320) x(-200).
- In the boss objects creation event I am using the Move Towards Point action set to x(320) y(160).

Problem: The object continues to move down, without stopping.

2. Give the boss a health of 100, and subtract 5 from that with each successful hit.

- Created a variable for the boss' health.
- Collisions with player shots subtract from this variable.

Problem: None. Works just fine thankfully.

3. Updated in post number 17 below.


Any help would be greatly appreciated. I'm sorry if you guys get these questions millions of times .

This post has been edited by mentisworks: 06 April 2007 - 03:31 AM

[Aurimux_Ra]

1. Make that toward in Step event , not creation .

This post has been edited by Aurimux_Ra: 03 April 2007 - 04:43 PM

[Katuko]

Ah, good to see a well-formulated question for once.

1) Since the action is only done once, in the Create Event, the object will only start moving towards the point without stopping. Put the action in the Step Event instead. A new problem arises: the object will start wiggling back na forth on the spot, because it goes past it, goes back and past it again, and so on. In the step event, also tell it to move only if the distance is larger than, say, 4. So it'll be:

if distance_to_point(x,y,320,160) > 4
{
move_towards_point(320,160,2);
}
else
{
x = 320;
y = 160;
}

In D&D it would be

if variable "distance_to_point(x,y,320,160)" is larger than 4
START BLOCK
move towards position (320,160) with speed 2
END BLOCK
else
START BLOCK
Jump to position (320,160)
END BLOCK


3) Use an alarm and a "shield" variable. If the variable is equal to 1, the bullets won't do damage (Check upon collision). Use the alarm event to reset the variable to 0.

Just tell me if you want me to elaborate.

<(Katuko)>

[mentisworks]

Thank you very much for your replies. Indeed, I first only tried Aurimux's suggestion. Which did cause the problem of wiggling.

Then I followed your instructions, Katuko, and unfortunately I came upon another problem there. I am now getting an error message when the game starts...

Quote

COMPILATION ERROR in argument 0
Error in expression:distance_to_point(x,y,320,160)
position 30: Wrong number of arguments to function or script.

Which makes me wonder if either the syntax you gave me has an error, I used the D&D method, or if I need to set this variable somewhere first?

This post has been edited by mentisworks: 03 April 2007 - 05:57 PM

[Katuko]

Oh, I remembered the number of arguments wrong. Sorry. It should only be
distance_to_point(320,160)

Remove the two first arguments. It's point_distance() that uses 4.

<(Katuko)>

[mentisworks]

Ah okay. Thank you. That fixed it. So the issue now is that when the object gets close to those coordinates there is a visible jump (probably a distance of 50 or so).

This occurs even when I set the variable to "greater than 0." I'm wondering if this has something to do with the bounding box?

[Katuko]

If the distance is smaller than the distance you want. Sorry again. That's what you get for rushing code. The distance should be the same as the speed the object's moving at to avoid the visible jump.

<(Katuko)>

[mentisworks]

Okay, so since my object is moving at 4, I changed the variable to "larger than 4." That is, assuming that I'm understanding this correctly. Yet the problem persists, which makes me think that I have no clue what I'm doing! Ha ha .

[mentisworks]

Sorry to bump this, but I was hoping for some more help with this issue. As stated above, I am still experiencing the "jump" effect before the object reaches its destination. Even though my variable distance and speed are the same.

[torigara]

There are three ways to calculate the distance between two instances, those gives slightly different results:
- distance_to_object gives the distance between the bounding box of two instances. (results in the smallest value) If two instances are colliding, the result will be 0.
- distance_to_point gives the distance from the bounding box of one instance to the given position, without taking other instance's bounding box into account.
- point_distance gives the distance between two points, without considering any bounding box. (results in the largest value)
Choose one which is appropriate for your purpose.

[Katuko]

If the distance is SMALLER THAN the speed, the next step would make the object jump past the spot. Therefore the check should be "smaller than", not "larger than". A little mistake from my side.
Here's the fixed code:

if distance_to_point(320,160) < 2
{
move_towards_point(320,160,2);
}
else
{
x = 320;
y = 160;
}

<(Katuko)>

[mentisworks]

I have implemented your "smaller than" change, which had a different result altogether. It caused the object to simply appear at that point, and then start to wiggle.

After looking at it a little closer I realized it's because the instructions are now in the wrong order.

- If the distance is < X, then move to point.
- Else, jump to that position.

Resulting interpretation is that the distance WON'T be smaller than X until that position is reached. Therefore, this step is bypassed and the object jumps directly to that position.

However, I believe I have figured out an alternative method. Using the distance_to_point variable does appear to have one undesired result for me, which is also the source of the problem here.

As Torigara pointed out (thanks for that!), this variable does make its calculation using the bounding box as reference, instead of the center of the image. That's the reason for the jump.

Thus there are two solutions to this. The first, more logical one I suppose would be to use the point_distance variable instead (though I'm not sure of the syntax for it). The other solution, which I thought of first actually, is a sort of workaround. Here's what I found to work...

-If distance_to_point(320,200) is larger than 0, then Move Towards Point (320,200).
-Else, Start Moving in Direction: none (square in the middle), speed 0.

Because the bounding box was changing my desired position with the distance_to_point variable, I compensated for this by changing the coordinates to 200 from 160.

Now the movement is smooth, and the object stops in the right place. So I would like to thank you all for your help. Even though you did not provide me with the solution directly, you have made it possible to solve this problem on my own. And that's even better!

My next steps will be to tackle the actions mentioned in #3 above. Which I'm sure will bring up other issues, and I will post them here when they do.

Thanks again!

This post has been edited by mentisworks: 04 April 2007 - 04:24 PM

[Katuko]

Again, I rushed it. I'll do it properly this time.

if distance_to_point(320,160) > 4
{
move_towards_point(320,160,4);
}
else
{
x=320;
y=160;
}

I'll go through it just to make sure...
If the distance to point (320,160) is larger than 4, move towards it with a speed of 4. Else, just jump to it.

<(Katuko)>

[mentisworks]

Katuko, that is actually the same code which we tried in posts 3 -5. It worked with the exception of the jump. I do believe that the jump was caused by the bounding box, on account of using the distance_to_point variable. As Torigara pointed out...

torigara said:

distance_to_point gives the distance from the bounding box of one instance to the given position, without taking other instance's bounding box into account.

But as you can see I have discovered a somewhat different solution to this, so no worries .

This post has been edited by mentisworks: 04 April 2007 - 05:00 PM

[Katuko]

OK, glad to have helped. But by changing distance_to_point(320,160) into point_distance(x,y,320,160), the code works fine. Forgot to take the bounding box into consideration.

Good luck with your game!

<(Katuko)>

[mentisworks]

So that's how you do it. Well, I might use that, since it's probably a more efficient way to go about it .

Thanks again for all your help. You might be seeing me in this tread again before long .

[mentisworks]

What did I tell ya, I'm back . I have now been working for a couple of days on number three from above. But let me be more specific this time...

3. At regular intervals the boss should change "state," represented by an animation, into a form immune from the player's attacks. After said time interval, the boss should change back into its original state, represented again by an animation.

- Initially, I was using one object for the boss, with two Alarm events.
- The first alarm event used the Change Sprite action to trigger the first animation and set the immunity variable. It would also set the second Alarm.
- The second alarm event used the Change Sprite action to trigger the second animation, and again set the immunity variable. It would also set the first Alarm.
- So both alarms would just loop each other.

Problem: This method worked well as long as I was using static (non animated) test sprites. But when I inserted the animated sprites, the animation would just loop, creating undesired visual results.

That's when I decided to change my method. Instead, I tried to create separate objects for the initial boss form, the first animated boss form, and the third animated boss form.

- After the initial boss object would move into place, I used the Change Instance action, on an alarm, to change it into the first animated boss object.
- The first animated boss object allowed me to use the Animation End action to change the sprite into a static image. On an alarm, it would change into the second animated boss object.
- The second animated object behaved exactly as the first, only using different sprites, and was not immune.

Problem: Now that I was using three different objects, I could no longer set the boss health variable in any of them. So I moved the variable to the boss controller object. This did not seem to work, however. The result was that the initial boss object would destroy itself right after creation.

I tried moving the variable to the initial boss object instead, hoping that it would remain after the first object change. This cause even further animation glitches and inconsistent boss immunity. Which leads me to ask, are variables set in one object not available in other objects?

So here's what I would like to know: Which method appears to be more along the right track for the results I'm trying to achieve in number three above? And, since both methods are exhibiting problems for me, what changes must I make to achieve this goal?

Your help is greatly appreciated! In advance, thank you again .

This post has been edited by mentisworks: 06 April 2007 - 03:43 AM

[mentisworks]

Sorry to bump this again. But I could really use the help .

[torigara]

You abandond the first way too shortly. Obviously it is the simpler way. You seem to know how to use the animation end event, why not apply it to the first method?

[mentisworks]

I suspected this may be the case. The reason I did not use the Animatin End event in the first method, was because I was using two different animations. I did not think it was possible to use multiple Animatin End events, which differentiated between multiple animations.

If this is indeed possible, I'd love to know how. Otherwise, I was thinking that maybe there is a way in code to specify that the animation should only be played once, instead of looping.