Charge Time

[Mordred]

I think there are some pretty fundamental questions that need to be addressed before any work can be done on mage classes. The most pressing of these is "what do we do with Charge Times?"

On WotD, we were able to successfully integrate automated CT-based initiative into our battle system using only our primitive Excel-based battle tool. This is a feat that can be replicated for FFS. However, I can state categorically that it is not possible to run a game that has delayed-resolution actions (e.g. Jump, Fire4, Charge+5) with anything less than either

A) manual calculation (which sucks)

or

B) a fully automated, real program in control of the battle.

What I'm asking is mostly to Ilium and any other programmers here, and that question is: can you actually deliver on "B?" If you have any doubt whatsoever on that matter, we need to take a hard look at whether to include delayed-resolution actions in the game at all.

[Ilium]


int Number;

while( Number <= 100 )
{
cout << "Number " << Number << endl;
Number++;
}

This will be the fundamental code of each delayed time action used in the game. It will be adjusted and expanded according to what we are asking from it, but basically what this says: If "Number" is less than 100, increase Number by one. Example:

int ChargeTime;

while( ChargeTime <= 100 )
{
cout << "ChargeTime " << ChargeTime << endl;
ChargeTime+=5;
}
edit: this is super simplified and is not entirely what it will look like in the end product. It's only to demonstrate how a while condition will be able to effectively incorporate CT, Jump, etc. time mechanics.

[Mordred]

I'm gonna ask another dumb question, then... You have a means in mind for inserting these delayed-result actions into the initiative list, right?

EDIT: And a third dumb question! In FFT, you could check the AT list to make sure your spell target wouldn't move away before the spell went off. How are players going to manage that in FFS, or, if their tactics specify "never use a spell that would take that long to charge," how will the GM running the battle check that?

[Ilium]

Each character in combat will have its own while loop counting individually to 100. Once one reaches 100, the program will note its that class' turn to act, at which point the value will return to 0. If the Lancer uses Jump, it will start a new while function that will count at its own specified time until it reaches 100, when the program will note that action taking place.

However I haven't even really begun to think about coding the program yet, only trying to keep in mind how everything we discuss here will be effected by programming.

[Ilium]

May 2, 2013 15:39:56 GMT -6 Mordred said:

EDIT: And a third dumb question! In FFT, you could check the AT list to make sure your spell target wouldn't move away before the spell went off. How are players going to manage that in FFS, or, if their tactics specify "never use a spell that would take that long to charge," how will the GM running the battle check that?

Right now the only thing I can come up with is running the battle one turn at a time, and showing each CT count. That would be really tedious though. Maybe run battle three rounds at a time? And also let everyone know how long it takes abilities to charge. We can probably come up with something better and more creative.

[Mordred]

Running battles one turn at a time would be horrific, especially since the definition of "turn" is fungible in the CT-based initiative system.

The only other solution I can come up with is just having two kinds of abilities, 1) instants and 2) those whose Charge Time is defined as "it goes off the next time your initiative comes up."

[kablizzy]

If we have a program to calculate CT, there's not as much reason to return to the single-turn running that HoI adopted. Plus, the real issues with FFT were in things like Speed Save, Cheer Song, Scream, and the like. Assuming we balance that out, we can inject speed again as a balancing factor (Ninja get an extra turn from speed once every 8 turns, while clunky knights operate more slowly, etc.).

[Mordred]

As long as there's an easy way for the battle runner to check when any given action would resolve, in order to prevent tactics uh-ohs with fixed-destination delayed resolution actions, it's Kool and the Gang.

Speed Save, incidentally, is probably salvageable. I can't see it being more damaging to speed balance than Haste, which is way more effective than more than the most brutal beatdowns on a Speed Save-having tank.

[kablizzy]

Nor I, really, but since we're so early in development and CT discussion, we can kinda keep it on our radar as an ability to watch.

[Schwerpunkt]

May 2, 2013 16:27:08 GMT -6 Mordred said:

Running battles one turn at a time would be horrific, especially since the definition of "turn" is fungible in the CT-based initiative system.

Total Number of Units on the Field * 100 = Turn Length.

But I agree that it's an extremely bad phrase to use. Especially since, in the context of FFT, a 'turn' is the entire package of a single unit's movement and action at a single point in the battle.

And I agree that doing battles "turn"-by-"turn" would be a bad idea. Very clunky, in fact, since you always have to wait for new tactics to be determined, written, and then submitted.

I could go for some turn-by-turn duels in IRC, though. That'd be neat.

[kablizzy]

That'd be really cool sim integration, actually.

[Schwerpunkt]

Yeah. I don't think any sims actually do it. The good thing is that a duel would basically be a really stripped down battle ("I smack you, you smack me") with functionally the exact same skill sets and formulae, so it shouldn't be too hard for Ilium to export that into a quick-and-dirty duel tool that just crunches numbers and stuff.

It'd also make those big tournaments way more awesome. Especially the upsets. Oh boy, the upsets in real time in IRC. The tears, man, the tears!