Quick Links: Download Gideros Studio | Gideros Documentation | Gideros community chat | DONATE
Tries/No more Lives system (Anyone has implemented before?) — Gideros Forum
  • Home
    • ›

    Tries/No more Lives system (Anyone has implemented before?)

    private_kennyprivate_kenny Member
    edited December 2014 in Game & application design
    Hi,

    I was trying to implement a Tries / No more live system that is similar to what Candy Crush and other games has implemented. Meaning to say, limiting the number of chances a player can make until a certain timeout period, a life will be restored.

    I'll like to query the best approach to do this.

    This is my fundamental building block:
    I have a SceneManager Sprite that controls 2 screens.
    Screen 1: Menu Scene (which shows the number of tries)
    Screen 2: Game Scene (actual game itself)
    When switching Game to Menu scene again, i fired an event to the SceneManager which re-creates the Menuscene.

    I created a Timer and started the timer at the SceneManager.
    This timer will be passed to MenuScene each time. Timer is set to trigger every 1s.
    Code will be similar to such.

    function SceneManager:switchScene(event)
    ...
    local eventType = event:getType()
    if eventType == ApplicationEvent.MENU_SCENE then
    scene = MenuScene.new(self.screenWidth, self.screenHeight, self.applicationEventsEngine, event.Target, self.database, self.timer)
    elseif eventType == ApplicationEvent.GAME_SCENE then
    scene = GameScene.new(self.screenWidth, self.screenHeight, self.applicationEventsEngine, self.database)
    end

    self:addChild(scene)
    ...
    end

    At the menu scene, I re-register at each instantiation.

    function MenuScene:init(screenWidth, screenHeight, applicationEventsEngine, coins, database, timer)

    self.timer = timer
    self.timer:addEventListener(Event.TIMER, onTimer, self)
    end

    function MenuScene:onTimer
    -- Print current timer on screen if life not max
    end


    This is ok when I try it once. However, when I try it twice, the screen will not display the timer anymore.

    Any idea? Is it due to each Menu Scene I created?




    +1 -1Share on Facebook

    Comments

    • amin13aamin13a Member
      Accepted Answer
      You can use my Attached file.
      lua
      lua
      main.lua
      1K
      +1 -1Share on Facebook
    • private_kennyprivate_kenny Member
      edited December 2014
      Hi amin13a,

      Thanks for your response. It looks good. You are using the frame rate to help do the timer scene. Its a nice suggestion. I'll probably use the same method!

      But however, I do have some problems with the frame rate after some levels I've created. It goes from 60fps to 35++. It affects the gaming. You have any idea? I think I'll better rethread this here:

      http://giderosmobile.com/forum/discussion/5452/dropping-of-frame-rates

      +1 -1Share on Facebook
    • jdbcjdbc Member
      edited December 2014
      Create a new Tries class to manage how many tries the player has done. Inside this class use the DataSaver.lua file and os.time function to store when you start to play and check time difference to reload lives.


      local starting_time = DataSaver.load("start_time")
      if (not starting_time) then -- first time
      starting_time = os.time()
      DataSaver.save("starting_time", starting_time)
      end


      -- Time in milliseconds to check if you have to reload tries
      time_reload = os.time() - starting_time

      Info about time and date functions: http://www.lua.org/pil/22.1.html
      JDBC Games on Google Play
      +1 -1Share on Facebook
    • ar2rsawseenar2rsawseen Maintainer
      ENTER_FRAME event has deltaTime property, which says how much time has passed since last enter frame event.
      So you can implement time counting which would be independent on frame rate, even if it is dropping ;)

      http://docs.giderosmobile.com/reference/gideros/Sprite/Event.ENTER_FRAME#Event.ENTER_FRAME
      http://appcodingeasy.com/Gideros-Mobile
      +1 -1Share on Facebook
    • private_kennyprivate_kenny Member
      Hi JDBC, thats what I did. But instead of creating a DataSaver I used the SQLlite database instead.
      Is this recommendable?

      Thanks ar2rsawseen.
      Lemme check this out :D
      +1 -1Share on Facebook
    • jdbcjdbc Member
      edited December 2014
      Hi JDBC, thats what I did. But instead of creating a DataSaver I used the SQLlite database instead.
      Is this recommendable?

      Thanks ar2rsawseen.
      Lemme check this out :D
      How many tables do you have? Why do you use SQLLite instead of files to store data.
      I guess you only need to store starting_time value, lifes and may be coins value. DataSaver works quite well for me.
      JDBC Games on Google Play
      +1 -1Share on Facebook
    • SinisterSoftSinisterSoft Maintainer
      You can use the system time - not many people bother to cheat the system.
      Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
      https://deluxepixel.com
      +1 -1Share on Facebook
    • private_kennyprivate_kenny Member
      Hi JDBC,

      I used several tables. But 2 to store the following.
      I have a starting_time, lifes and coins as well.

      Hi Sinister,
      You are right, but how to use the System time?
      os.clock() gives me the time the application starts, which is not what I want.
      +1 -1Share on Facebook
    • SinisterSoftSinisterSoft Maintainer
      When you first start you game load a file that contains the last time you added a life. If you have never save this file then start at the current time and give them 5 lives (the maximum?).

      You check the difference by every so often checking the current time vs the time you last added a life. You can do this in a frame interrupt (frame event).

      Then if the difference is > 30 minutes then add a life and also add 30 minutes onto the time you last added a life.

      If there have been multiple hours (eg overnight) then the lives will fully refresh as it will add multiple 30 minutes and so multiple lives (as the routine gets called each frame) or you can add multiple lives in one go.

      When update the last time you added a life then save it to a file (for when the user loads the game in the future).

      Here is what I used for 'What Rhymes With Martians?'...

      function increaseLives()
      local diff
      if livesLeft<(maxLives+4) then
      local now=os.time()
      diff=now-lastPlay
      local addition=math.floor(diff/regenerate)
      if addition>0 then
      livesLeft=livesLeft+addition
      if livesLeft>(maxLives+4) then
      livesLeft=maxLives+4
      end
      saveLives()
      lastPlay=lastPlay+(addition*regenerate)
      saveLastPlay()
      lives()
      diff=0
      end
      else
      diff=0
      end
      return diff
      end

      You can use 'diff' to show how long it is till the next life is given.
      Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
      https://deluxepixel.com
      +1 -1Share on Facebook
    • private_kennyprivate_kenny Member
      Ah thanks sinister!
      I did exactly what u mentioned. only difference is I used sqllite to store everything.
      I was actually just looking for os.time(), i was using os.clock() all the way and everything gone haywire :D

      Btw, I downloaded your game. It was very nice :)
      Quite addictive too :P
      I reached level 10 hahaha
      Added a review on playstore too. Keep up the good work bro
      +1 -1Share on Facebook
    • SinisterSoftSinisterSoft Maintainer
      edited December 2014
      Thanks. :)

      Working on this next...

      Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
      https://deluxepixel.com
      +1 -1Share on Facebook
    Sign In or Register to comment.