Hello
i am trying to make a clicker game, but there is a problem faced me 
how can i let the game does something while its off?
for example Cookie Clicker, when u close the game and then open it after 10 mins u will find ur cookies increased.
i am using Unity Engine and scripting in C# btw.
Hello
i am trying to make a clicker game, but there is a problem faced me
how can i let the game does something while its off?
for example Cookie Clicker, when u close the game and then open it after 10 mins u will find ur cookies increased.
When the game closes, save the current time. When the game reopens, compute how long the game has been closed, and use that to work out any actions that might take place "as if" the game was still running during that time (without user input, obviously). You can't run code when the game isn't running, sorry.
Only issue with using the system time is if the time becomes out of sync, you may think about using an online system to retrieve settings from a server.
Or run a server. The "while closed" logic runs on your server. The game (client) retrieves data from your server when the user plays it.
thank you for you responses.
one last question please :D
how can i know the time when the game was just closed untill its just opened by using Unity / c# ?
http://msdn.microsoft.com/en-us/library/system.datetime.now(v=vs.110).aspx
http://docs.unity3d.com/ScriptReference/MonoBehaviour.OnApplicationQuit.html
You can also log the time every couple seconds while the game is running. The added benefit is that no matter how the application closes, the time is recorded and accurate within a few seconds.
Pretty much all the games in this genre (including cookie clicker) are ONLINE/SERVER based games. Meaning that you information is in a database on a server, and all the "truth" of the world is what's on that server ... so every "action" of any significance is a web request ... so the time in question here is always just the official server time ...
so .. lets say the user does the action: "build object A" ... it sends a request to the server which puts that in the db (with server based timestamps etc) ... then the client receives a response (usually with object A's id in it) ... and starts a local (on the client) display related to time passing. Each message back and forth with the server includes a response, which includes the current server time, which the client uses to "sync" to (and avoid getting increasing amounts of client clock drift involved) ...
Then lets say the phone dies ... nothing "happens" when the phone is disconnected. NOTHING.
The server is just sitting there with static rows in the db for that user, the client is just off ...
Then when the client runs the app again, it makes a "login" or "start session" or "resume" request to the server ... which then pulls all the "active/pending" builds from a list, updates their status based on current time, and sends the relevant info back to the client for updating in the UI (and notifying the user with things like flashing or pop-up displays ... etc.
The server is the holder of all truth, and runner of all important logic, the client is just a dumb data display and user input device .. which in certain areas has logic which mirrors or imitates the game logic to provide "real-time" updates to the UI (between server interactions).
There is also 1 exception to the server doing nothing except during client requests ... if the game uses push notifications (or anything like it) ... then the way that works is that the server usually has some periodic little method running to look at data that should generate a push notification (for instance when a building has just finished) ... and then package that up and send it to the client device (not a running app ... push notifications actually go to the phone, for when the app isn't running, ... then when the user clicks them, they launch the app ... which then does that "session resume" type call I spoke of earlier) ...
Servers that generate push notifications usually have some minimum threshold (like lets say 2-10 minutes) that must have passed since the last request came from the phone, else they won't send the notification (or they will send it to the app in a different format, instead of to the device as a push notification) ... systems like PubNub exist to make this stuff easy.
nice answers from all of you, Thank you
Pretty much all the games in this genre (including cookie clicker) are ONLINE/SERVER based games. Meaning that you information is in a database on a server, and all the "truth" of the world is what's on that server ... so every "action" of any significance is a web request ... so the time in question here is always just the official server time ...
so .. lets say the user does the action: "build object A" ... it sends a request to the server which puts that in the db (with server based timestamps etc) ... then the client receives a response (usually with object A's id in it) ... and starts a local (on the client) display related to time passing. Each message back and forth with the server includes a response, which includes the current server time, which the client uses to "sync" to (and avoid getting increasing amounts of client clock drift involved) ...
Then lets say the phone dies ... nothing "happens" when the phone is disconnected. NOTHING.
The server is just sitting there with static rows in the db for that user, the client is just off ...
Then when the client runs the app again, it makes a "login" or "start session" or "resume" request to the server ... which then pulls all the "active/pending" builds from a list, updates their status based on current time, and sends the relevant info back to the client for updating in the UI (and notifying the user with things like flashing or pop-up displays ... etc.
The server is the holder of all truth, and runner of all important logic, the client is just a dumb data display and user input device .. which in certain areas has logic which mirrors or imitates the game logic to provide "real-time" updates to the UI (between server interactions).
There is also 1 exception to the server doing nothing except during client requests ... if the game uses push notifications (or anything like it) ... then the way that works is that the server usually has some periodic little method running to look at data that should generate a push notification (for instance when a building has just finished) ... and then package that up and send it to the client device (not a running app ... push notifications actually go to the phone, for when the app isn't running, ... then when the user clicks them, they launch the app ... which then does that "session resume" type call I spoke of earlier) ...
Servers that generate push notifications usually have some minimum threshold (like lets say 2-10 minutes) that must have passed since the last request came from the phone, else they won't send the notification (or they will send it to the app in a different format, instead of to the device as a push notification) ... systems like PubNub exist to make this stuff easy.
not all "Click" games are online.
there is a game on android doesnt require network, and it increases you resources when u close the game and then open it.
so i think the time method is used there
