The Daily Click ::. Forums ::. Klik Coding Help ::. Extra lives...
 

Post Reply  Post Oekaki 
 

Posted By Message

Kai Proton



Registered
  31/01/2005
Points
  201

Wii Owner
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

Candle
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

Wii Owner
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

Game of the Week WinnerVIP MemberPicture Me This Round 30 Winner!Weekly Picture Me This Round 39 Winner!Kliktober Special Award Tag
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

Wii Owner
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

VIP MemberStarSnow
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

VIP MemberStarSnow
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

VIP MemberStarSnow
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

VIP MemberGOTW JULY 2010 WINNER!Kliktober Special Award TagGOTW HALLOWEEN 2011 WINNERPicture Me This Round 51 Winner!
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

Has Donated, Thank You!Little Pirate!ARGH SignKliktober Special Award TagPicture Me This Round 33 Winner!The Outlaw!VIP MemberHasslevania 2!I am an April FoolKitty
Picture Me This Round 32 Winner!Picture Me This Round 42 Winner!Picture Me This Round 44 Winner!Picture Me This Round 53 Winner!
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

Game of the Week WinnerSecond GOTW AwardHas Donated, Thank You!VIP Member
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

Has Donated, Thank You!Little Pirate!ARGH SignKliktober Special Award TagPicture Me This Round 33 Winner!The Outlaw!VIP MemberHasslevania 2!I am an April FoolKitty
Picture Me This Round 32 Winner!Picture Me This Round 42 Winner!Picture Me This Round 44 Winner!Picture Me This Round 53 Winner!
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
   

Post Reply



 



Advertisement

Worth A Click