Posted By
|
Message
|
Kai Proton
Registered 31/01/2005
Points 201
|
29th June, 2015 at 29/06/2015 11:26:50 -
Im looking for help in Awarding Extra lives to the player based on score mutiples.
say for Example every 5000 = 1 life,
then the player gets that life at
5,000
10,000
15,000
20,000
etc.
at the moment, Im thinking (in this case) if the score is divided by 5000, and the result is an integer and not a real number it can then trigger the reward, but Still not sure.
Can anyone Suggest a simple method of doing this type of thing?
----------------------
Time for a Sexy Party!
----------------------
|
s-m-r Slow-Motion Riot
Registered 04/06/2006
Points 1078
|
29th June, 2015 at 29/06/2015 12:36:09 -
You might want to try something like this:
IF Player Score =/> 5000
AND IF Alterable Value A of [Score Object]=0
THEN Add 1 to Player Lives
AND THEN Add 1 to Alterable Value A of Score Object
For successive extra lives, just modify the above, as follows:
IF Player Score =/> 10000
AND IF Alterable Value A of [Score Object]=1
THEN Add 1 to Player Lives
AND THEN Add 1 to Alterable Value A of Score Object
The Alterable Value stuff added in there prevents the bonus from happening more than once for each score plateau.
n/a
|
Dr James 2
Registered 17/02/2015 13:10:14
Points 64
|
29th June, 2015 at 29/06/2015 13:23:28 -
Sounds like you could use the mod function, but then you'd have to land bang on those scores (so not like 5,001).
Hmm. Quickest way I can think of doing this is just by adding the same score to two separate values and when one goes over 5000, set to 0 and add 1 to a life.
Or
s-m-r's way! Either way you're probably going to need two separate values.
n/a
|
Phizzy
Registered 05/06/2015 09:10:21
Points 21
|
29th June, 2015 at 29/06/2015 13:23:36 -
Oh god no, that's horrible, don't do that.
One event version, just off the top of my head so I might have missed a necessary limiting condition...
IF floor([Player Score] / 5000) > 0
AND floor([Player Score] / 5000) > [Last Landmark]
... [Player Lives] + (floor([Player Score] / 5000) - [Last Landmark])
... [Last Landmark] = floor([Player Score] / 5000)
If you put that in, it should just work, but here's some explainy:
This divides your score by 5000, then checks the floor value of that division. If the number is under 5000, it'll give you 0. If it's 5000-9999, you'll get 1. 10000-14999, you'll get 2. And so on.
You then need to check that the number this returns is greater than 0, because you want to start getting lives at 5000, and that you haven't already been given a life for having a score this high. [Last Landmark] can be any value, a counter, alterable or global value, whichever is easiest. It needs to start at 0.
You can replace the instances of '5000' in that to any other number and it'll work just the same. If you want to make it more flexible, you could define a constant and check against that constant. Does MMF do constants? No idea.
(Writing out code on this site is horrible... And I can't remember how Fusion events work)
Edit boop: If anyone saw this before, it was just set to add one life if this condition was reached, but I updated it so if you get tens of thousands of points at once you'll get the appropriate number of extra lives.
Edited by Phizzy
Phizzy
|
Kai Proton
Registered 31/01/2005
Points 201
|
29th June, 2015 at 29/06/2015 19:02:59 -
Thanks For the help guys,
but its made my brain hurt, so need a beer, and I will re-read tomorrow .
----------------------
Time for a Sexy Party!
----------------------
|
markno2
Registered 06/06/2006
Points 865
|
30th June, 2015 at 30/06/2015 01:43:05 -
I'm not as smart as those guys. What I would do is have two counters (or you can use two alterable values, or the player's score). Counter 1 holds the player's score and Counter 2 is set to an initial value of 5,000. Then in the event editor:
Event:
Counter 1 is greater or equal to Counter 2
Actions:
Add 1 to lives
Add 5,000 to Counter 2.
Discarded pizza boxes are an indispensable source of cheese.
|
Kai Proton
Registered 31/01/2005
Points 201
|
30th June, 2015 at 30/06/2015 16:33:37 -
Hey markno2,
Thanks thats shockingly simple, and may be the way for me to go,
if I add a third Count (or count 0) and set that to the increment value,
then when the actions add to counter 2, it would be counter 2 + counter 0,
the reason for this extra, is I always get about halve way into coding these things and if they arent variables form further back and I want to change them then there is a load of code to sift through..
----------------------
Time for a Sexy Party!
----------------------
|
The_Antisony At least I'm not Circy
Registered 01/07/2002
Points 1341
|
4th July, 2015 at 04/07/2015 00:16:25 -
Matthew's equation works, but if the player loses a life, they'll also need to lose 5000 points or the very next play through the game will result in an error in the number of lives.
If all enemies spawn the same score amount - meaning if all enemies give the player an additional score of 100 for every enemy killed, then you could use a simple equation.
Compare two general values ->
Value("Score") mod 5000 = 0
+One action when event loops:
Add 1 to lives.
Problem with the above equation is that if the score doesn't exactly equal 10000, 15000, or something plainly divisible by 5000, the math won't work and the number of lives won't increase.
So, here's the hack method:
You'll need three counters. Your score, your lives, and a new one named "score range". Make the score range counter max value 6000. Min value 0. When an enemy is destroyed, pass the value to the score counter as usual. Also pass the same value to the "score range" counter.
Create a new event:
Counter("score range") > 5000.
Add 1 to Counter ("lives").
Set Counter ("score range") = Counter ("score range") - 5000.
Now every time the "score range" counter exceeds 5000, the player gets an extra life, the score counter still displays correctly, and the remainder of points over 5000 remain on the "score range" counter.
ChrisD> Employer: Say, wanna see a magic trick?
ChrisD> Employee: Uhh… sure, boss.
ChrisD> Employer: Your job! It just disappeared! Pack your things and leave! Pretty good trick, huh?
|
Phizzy
Registered 05/06/2015 09:10:21
Points 21
|
4th July, 2015 at 04/07/2015 20:25:04 -
Originally Posted by The_Antisony Matthew's equation works, but if the player loses a life, they'll also need to lose 5000 points or the very next play through the game will result in an error in the number of lives.
How'd you work that out?
I have to say I like markno2's method, very simple and will work exactly the way you need it. My method would do the same thing, but I suppose it's a bit harder to understand and does an excessive number of calculations in comparison. But whatever you're working on probably wouldn't be affected by a few extra mathematical operations anyway... Actually, it's Clickteam, it would probably cut your framerate in half.
Edited by Phizzy
Phizzy
|
The_Antisony At least I'm not Circy
Registered 01/07/2002
Points 1341
|
6th July, 2015 at 06/07/2015 03:13:55 -
If the number of lives is based off of the score value, the player loses a life, and doesn't lose 5000 points, the very next level will recalculate the number of lives via score and the player won't have "lost a life". An extra counter, alterable value, or global value should still be less of a tax on resources than a list of 10+ range testing events.
I like Mark's idea myself. It's super simple; if the player is at 4990 points and they earn another 120 points, the extra 110 would still carry over. Since the number of lives isn't based on dividing the actual score, if a player loses a life, it stays lost without having to modify the score value. It's a better solution than my own because it doesn't involve a third counter or alterable value; It's less complicated. Testing ranges is for suckers.
ChrisD> Employer: Say, wanna see a magic trick?
ChrisD> Employee: Uhh… sure, boss.
ChrisD> Employer: Your job! It just disappeared! Pack your things and leave! Pretty good trick, huh?
|
Phizzy
Registered 05/06/2015 09:10:21
Points 21
|
7th July, 2015 at 07/07/2015 21:00:33 -
No... I don't think you understood my code. Number of lives isn't based on score there. You're just awarded extra lives when you've reached a milestone you haven't reached before.
Phizzy
|
The_Antisony At least I'm not Circy
Registered 01/07/2002
Points 1341
|
8th July, 2015 at 08/07/2015 04:20:02 -
I don't think you understand your code, Phizzy. Regardless, the OP has multiple answers, so let's stop bickering maybe.
ChrisD> Employer: Say, wanna see a magic trick?
ChrisD> Employee: Uhh… sure, boss.
ChrisD> Employer: Your job! It just disappeared! Pack your things and leave! Pretty good trick, huh?
|
Phizzy
Registered 05/06/2015 09:10:21
Points 21
|
9th July, 2015 at 09/07/2015 11:53:07 -
Are you serious? Jesus Christ.
You only get extra lives if you go over a previously unattained landmark(s), which is stored in a global value. This has nothing to do with your current number of lives. That isn't involved in any calculation. You only add to it. It will not cause any error if the player loses a life.
Is this what happens when you try to help someone here these days? Glad I stopped by.
Phizzy
|
Fifth Quadruped
Registered 07/05/2003
Points 5818
|
9th July, 2015 at 09/07/2015 16:59:11 -
Nah, Phizzy's code is sound. It's comparing the score against the landmark, and comparing the score against zero. And that's it. I still like markno's solution; it's just so straightforward that it's hard to think of it. But Phizzy's has the advantage of adding multiple lives at once if the score jumps that far at once.
Go Moon!
|
UrbanMonk BRING BACK MITCH
Registered 07/07/2008
Points 49667
|
10th July, 2015 at 10/07/2015 00:37:15 -
Originally Posted by Phizzy Actually, it's Clickteam, it would probably cut your framerate in half.
I had a chuckle at that, but you have to admit Fusion 2.5 is a huge leap from where we were in TGF.
n/a
|
AndyUK Mascot Maniac
Registered 01/08/2002
Points 14586
|
10th July, 2015 at 10/07/2015 04:52:15 -
Not in my experience. Fusion 2.5 is even slower than MMF2.
.
|
UrbanMonk BRING BACK MITCH
Registered 07/07/2008
Points 49667
|
11th July, 2015 at 11/07/2015 00:35:35 -
Well I DID compare it to TGF and not Fusion 2, so there's that.
I found fusion2.5 to be slower in the iOS runtime, and I was forced to use it because the older builds no longer work as well with Xcode. Rapid development of simple games comes at a cost I guess.
n/a
|
|
|