So I had this idea for a mechanic in the game I'm writing. But I'm a bit at a loss how to write and implement it.
The premise is this. In battle, you're presented with a full bar that slowly depletes (Indicating the time you have). There is also a button. You click this button to deal damage, so you want to furiously click this as much as possible before the timer bar depletes.
When the bar depletes, you're sent to another page. For the amount of times you've clicked, you deal a proportional amount of damage to the enemy, and this is described on the second page. Basically it's a bit more interactive for the player than turn-based combat where damage is rolled automatically.
I had some other ideas as variants for different sort of attacks, using a similar countdown function. E.g. A timer, a rune displayed, and you've got to click on the same rune from a set of eight before the timer runs out to cast, etc. It all would use the same underlying 'timer bar' mechanic that depletes in real time, then sends you to a different page once the bar runs out.
Anyone know how I should go about this?
Alternatively, I was also thinking about how one would do a similar coundown (or count UP) bar where you have to hit a button when the bar rests within a certain section, much like your 'Dance Dance Revolution' kind of thing. E.g. Hit when the bar rests between 60% and 80%. But I've been thinking this would be too hard to implement and may not even be possible.
In your css:
I attached a sample.
EDIT: One obstacle I can see is keeping the CSS 10 secs and the in-passage 10 secs stat as two separate items, which means if you were to ever try and modify the timer value (E.g. A talent that increases the time you have), you'd have to do some real messing around.
Also, for some reason I've yet to figure out, the bar really slows down as it reaches depletion instead of depleting at a static pace.
BTW, not complaining, just thinking out loud as I play around with it. ^_^
For the second one, that's easy to fix. Change "ease" to "linear" below:
As for the first thing, the animation and the timer actually have nothing to do with each other, as you pointed out. If you do want to line everything up with variables, you could use JQuery to pace out the animation. I'm not sure precisely how to do that off the top of my head, but I'll see if I can whip something up later.
So far I've added a live damage counter in the same passage as the countdown timer so the player can see how much much damage they're doing before the second passage, and I'm playing around with a way to make said damage pulse once every time you click. So far it's just flashing in an epileptic fit inducing kind of way, but hey, progress!
EDIT: Adding the Shakescreen add-on TheMadExile made and attaching it to the button with a 0.5 sec duration seems to have done the trick instead of a pulse. It gives a rather satisfying 'screenshake' every time you 'land' a hit.
I didn't test it as extensively as I probably should have, so let me know if you have any problems.
It will probably only work with integers (so no half-seconds) because of how the <<timed>> macro works.
jQuery's ready() method does nothing useful when used inside a story format. The main entry functions of every story format I know of is registered via ready() or equivalent. By the time any user code can be executed the document has been ready for a significant amount of, computer, time. Using the ready() method, or equivalent, in user code does little useful as it immediately executes its callback. Beyond that, you're attempting to animate an element possibly before it's even on the page. The correct way to handle this would be with a postrender or, probably better, postdisplay task.
Further, if you're going to use jQuery to animate the bar, then you'd be better off using the animate() method's complete callback parameter, rather than a separate <<timed>>. That way the animation and passage navigation are perfectly synchronized.
I'd also suggest hiding, or disabling, the button immediately, so the player can't get any last second hits in as navigation begins.
I would recommend something like the following:
The <<timed>> macro has no issues working with fractional- or sub-second delays—either specified in seconds or milliseconds; e.g. 1.5s, 1500ms, 0.5s, 500ms.
Where did you get the idea that it couldn't?
I feel like I should probably stop answering these questions, haha. Thanks for the code.
Disabling the button and forwarding with JQuery; strange how it always seems so obvious after the fact.
Probably a half-baked internet blog. I thought that <<timed>> used CSS time values, and I read somewhere, sometime that CSS time values had to be integers. Looking it up real quick and it's clear that the thing I read at some point (or made up and convinced myself of, who knows) about time in CSS was absolutely not true.
Should've double checked before posting that.
This is what I threw together from the stuff you guys gave me. For ref:
Meshing together the code from TheLastExile with the stuff from Chapel in one of my usual Frankenstein experiments. Aiming to create a timer where the button is always visible, you've got to click when it rests within a certain range (60% to 80%), and if you click at the wrong or right time it triggers failure or success instantly. I'm aiming for the speed in which the timer depletes to be a variable, like the first bit of code.
EDIT: Trying this has resulted in another flashy mess. o_o I'll try again later.
The jQuery readiness callback normally gets the hammer from me fairly quickly because of how pointless it generally is within user code and how often people recommend it. I also have a particular distaste of cargo cult programming, which is often the reason behind its recommendation, so that's likely a factor as well.
Which is great, because 'for want of a nail' is perfectly applicable to an upcoming tabletop session I'm running.
Not a huge deal, but might as well minimize code anywhere you can. Otherwise it looks good.