It seems like he wants a set of expire events where certain events will fire independent of whether the timer is paused or not.
It might be possible to have a global timer for these decorations and each object has a durationUntilExpiration, which is the global timer + the object's duration of existence. Within each object, when the global timer is > than the durationUntilExpiration it just disposes of itself. Would it make sense to do this with key value observers, or would that allow too much checking? It doesn't seem like there would be a need for too precise granularity here. That seems like what you mean by not scaling well. He doesn't need it notifying each object each millisecond. But then thinking about it a little more, simply having a timer that is independent of a paused state seems to make sense. You don't want bullet holes on a wall disappearing if the game action is paused, but as soon as it's unpaused, the time is elapsed, the objects have expired and are cleaned up. Fun problem. On Jul 1, 2014, at 3:12 PM, Quincey Morris wrote: > On Jul 1, 2014, at 11:21 , William Squires <wsqui...@satx.rr.com> wrote: > >> Use-case: >> I have a (fictitious) FPS game in which the players or bots can "damage" the >> scenery by leaving blast marks. A timer should remove these "decorations" >> after a given delay, but I want the timers to pause if any players/bots are >> within line-of-sight of the decorations. > > It seems to me it’s a mistake to use “per event” timers at all in this > scenario — it might not scale well. > > The way I’d approach it (after thinking about it for about 30 seconds, so > this may not be intelligent at all) is to create a set of “future event” > objects, each of which has its own “remainingTimeDuration” property, along > with information about what it is you want to do at the end of the duration. > > Then, use a single timer, which is set to fire at the end of the remaining > time of the soonest event. If a new event is created, or if the game is > paused, or if the timer expires, invalidate the timer, subtract the actual > elapsed time since the timer was started from each pending event, and start a > new timer for the soonest of the newly updated events (if not paused, or > start this timer at the end of the pause). > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > This email sent to z...@mac.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
