• Add Review
  • Subscribe
  • Nominate
  • Submit Media
  • RSS

Battledome Turn Order discussion

  • kentona
  • 02/25/2015 08:52 PM
  • 2138 views
Definitions:
Actors: battlers and drones in the current arena battle

Pseudo code
Set a 'threshold' variable equal to the sum of all of the actors 'agility'
Each actor has a 'readiness' variable, called turnpoints/TP, initialized to a random range of their 'agility' (50% to 150%)
Every cycle, add each actor's 'agility' (plus/minus 10%) to their 'readiness'
For any actor whose 'readiness' is greater than the 'threshold', add them to the 'turn queue', sorted descending from their 'readiness', and decrease their 'readiness' by the 'threshold' value
If there are any actors in the 'turn queue', pop them off the front of the queue and do their turn actions
Repeat the cycle until one of the battlers die

Actual code
int turnId = 0;
PriorityQueue<Battler> turnQueue = new PriorityQueue<Battler>(8, queueComparator);	//turn queue
int turnThreshold = 0;
turnThreshold = battler1.getAgl();	//don't have drones yet, so just do main battlers AGL
turnThreshold += battler2.getAgl();
System.out.println("Turnpoints threshold is " + turnThreshold);

//turn logic
battler1.initTurnCounter();	//this initializes to their AGL +/- 50%
battler2.initTurnCounter();

//main game occurs here
while (!battler1.isDead() && !battler2.isDead()) {
	turnId++;
	System.out.println("Turn " + turnId + " -----------------------------------");

	while (turnQueue.isEmpty()) {
		battler1.incrementTurnCounter();	//AGL +/- 10%
		if (battler1.getTurnCounter() > turnThreshold) {
			battler1.decrementTurnCounter(turnThreshold);
			turnQueue.add(battler1);
		}

		battler2.incrementTurnCounter();	//AGL +/- 10%
		if (battler2.getTurnCounter() > turnThreshold) {
			battler2.decrementTurnCounter(turnThreshold);
			turnQueue.add(battler2);
		}
	}

	//do turns
	while (!turnQueue.isEmpty() && !battler1.isDead() && !battler2.isDead()) {
		currBattler = turnQueue.remove();
		// do their turns etc...
	}
}


You can test out the algorithm here: http://rpgmaker.net/games/5000/downloads/6676/


Thoughts/Concerns

I think the underlying logic of this turn determination algorithm is pretty solid. It allows for faster battlers to get extra attacks in versus slower opponents, and it will scale well for battles with multiple drones and battlers. There is no waiting for cycles to increment (beyond the time it takes for the computer to do some simple addition and comparisons) before an actor is ready (like in an ATB system). But maybe there are issues with it that I don't foresee?

I think the main issues the demo is encountering has more to do with the base stats of my predefined battlers and the range of my randomization. And also the value I set the threshold to - I made it the sum of the agilities so that it is scaleable to the relative agilities of the actors, but perhaps that was a bad idea? What else could it be other than a fixed value, or a multiple of the sum (like 2x or 3x)?

I think that tightening up the relative values of the battlers's agilities would help even things out, turn order-wise.

Are the random ranges I use for initialization and for each cycle a good thing to have? Are they too high or too low?

For reference, here are the base stats:
case FIGHTER:
	this.hp = 155;
	this.maxhp = 155;
	this.nrg = 60;
	this.maxnrg = 60;
	this.atk = 30;
	this.agl = 25;
	break;
case LITHE:
	this.hp = 115;
	this.maxhp = 115;
	this.nrg = 52;
	this.maxnrg = 52;
	this.atk = 20;
	this.agl = 35;
	break;
case BRUTE:
	this.hp = 220;
	this.maxhp = 220;
	this.nrg = 75;
	this.maxnrg = 75;
	this.atk = 24;
	this.agl = 11;
	break;
case CRAWLER:
	this.hp = 195;
	this.maxhp = 195;
	this.nrg = 90;
	this.maxnrg = 90;
	this.atk = 16;
	this.agl = 17;
	break;
case JOHNNY5:
	this.hp = 150;
	this.maxhp = 150;
	this.nrg = 120;
	this.maxnrg = 120;
	this.atk = 13;
	this.agl = 20;
	break;

Posts

Pages: 1
Hexatona
JESEUS MIMLLION SPOLERS
3702
I'm reminded of the few times I used to play DOTA. It seemed to be that if you had an agility-based champion it was pretty much an instant win because they could attack like 10 times before a normal one could attack.

Anyway, the reason I bring it up, even though I doubt this will be the case, just make sure you can't cheese the system and have a ridiculous amount of turns.
As Hexatona said the value of a turn vs the value of an action is the hard part of making this work. Practically every 2k3 game has this issue since an extra turn is worth more than a stronger action (lol int stat) 99 times out of 100. Effects with no or little scaling (ex. potions that heal 100 HP), overkilling (100 HP damage when the target only has 50 HP left), turn-based cooldowns (Hurt is available again after 2 turns, mind the vast majority of this is done in round/turn based battle). There's offsets (the value of each action is worth less with appropriate scaling, and hitting costs more frequently) but like those are ever well done and turn frequency rule supreme.

One way to help balance this without changing current stats is to add a flat modifier to agility scores. For example if a LITHE fights a BRUTE then we have:

Lithe Agility: 35
Brute Agility: 11

Assuming no randomness in readiness change the Lithe will get three turns before the Brute gets their first which the system will have to be balanced for or the turn frequency will have to change. The relative stat numbers can be changed or a modifier can be applied to both agilities to reduce the weight the agility score have on turn frequency. If we apply a modifier of 30 for example and get:

Lithe (Effective) Agility: 65
Brute (Effective) Agility: 41

Which shifts the turn frequency to giving the Lithe two turns for one of the Brute which helps the Brute some. I know it's an edge case (fastest vs slowest) and there's a lot that goes into balancing turn frequency, I just want to make sure this is known as one way of going about it.


The threshold itself is, as long as it is greater than the fastest unit change to avoid cases where the current readiness is > 2x the threshold, irrelevant. Battlers will hit the threshold at the same rate as everybody else since the a battler's readiness is linear. There's no waiting for gauges to fill so the player won't even notice if there's one or a thousand readiness ticks between turns. Add some playroom on top in case a battler's agility can increase during a fight without any issues.
LockeZ
I'd really like to get rid of LockeZ. His play style is way too unpredictable. He's always like this too. If he ran a country, he'd just kill and imprison people at random until crime stopped.
5958
In the discussions and strategies in the actual battledome thread, the way agility is typically used is not just to affect how fast you attack but also your ability to move in and out of the enemy's range.

I would make agility's effect two-fold. First, have two possible modes for the battlefield. At any time the battle is either a short-range battle or a long-range battle. Either robot is capable of moving in close or moving away on its turn to switch from one to the other, but the success rate is based on your agility compared to the enemy's agility. Many weapons are designed around the idea that they can only be used at short-range so this makes sense.

Second, do your turn order thing, but to a far lesser degree. 3x agility probably shouldn't be anywhere near 3x the number of turns. It mostly lets you move faster; the speed of a gatling gun or a rocket launcher would be only slightly increased. Maybe something like ATB gauge += (200 + agility) on each battle tick, and when your gauge gets to 10000 you get a turn. This way a robot with the max possible agility (200) would act almost twice as fast as one with the minimum possible agility (10). Which is still a huge deal.
I really like the idea of short range and long range battle modes. It would add an interesting twist to the MyBrute concept. Remember though that the battle happens automatically between the two robots and pplayers dont have any direct control over their battlers. (It is like setting your battleplan aahead of time and then people voting a winner in the Battledome events Dudesoft runs.). I will have to think of a good way to strategically implement it.

I added a turn mod of 200 to all AGL calls related to turn counts
LockeZ
I'd really like to get rid of LockeZ. His play style is way too unpredictable. He's always like this too. If he ran a country, he'd just kill and imprison people at random until crime stopped.
5958
I was imagining the pre-planned strategies being done like setting your party's AI in Dragon Age: Origins or Final Fantasy 12. The player would create a set of conditions for different actions to be used, in order of preference, like:

1. If opponent's HP is below 20%, and beam cannon is not out of ammo, and energy is above 25%, attack with beam cannon.
2. If battle is long range, and own HP is above 90%, attempt to close to short range.
3. If energy is below 25%, attack with energy stealer.
4. If battle is long range, activate energy shield.
5. If minibots are present, attack with flamethrower.
6. If battle is long range, attempt to close to short range.
7. If shotgun is out of ammo, and minibots are not present, attack with martial arts.
8. If shotgun is not out of ammo, attack with shotgun.
9. Attack with martial arts.

This was just the first way my mind jumped to, and so I was suggesting the short and long range thinking that it would be easily possible in a system like this. Were you thinking of doing battle plans a different way? This way wouldn't really limit what kinds of actions you can add to the game; as long as the outcomes of those actions are also possible conditions, there's no limit to what the player can choose to do. After all, in FF12 the entire game was played this way.
I honest-to-goodness haven't thought that far ahead, and prioritizing moves and actions (Which Beat Should I Choose?) was going to be a blog post sometime soon.

Also I quit FF12 like 12 minutes in.
Pages: 1