SpaceCombatProCon

From FreeOrionWiki
Revision as of 22:28, 8 January 2005 by 80.145.138.133 (Talk)

Jump to: navigation, search

Space Combat Proposals -- Categorical Breakdown

by MisterMerf (Jon Renshaw)


Table of Contents

1. Introduction

2. Judging Criteria

3. Combat Timing Methods

3.1 Real Time

3.2 Phased-Time

3.3 Variable-Pause Phasing

3.4 Other Modifications

4. Multiplayer Battle Selection

4.0 Unlimited Battles per Turn

4.1 Fixed Number of Battles per Turn

4.2 Time Allotment

4.3 Simultaneous Engagment

5 Miscellaneous Thoughts

5.1 Multiple-Turn Battles

5.2 Conclusions

5.3 Final Word

===========================

1. Introduction

This space combat methodology comparison is intended to highlight some of the features of the ideas under discussion in threads:

Space Combat (madness) http://www.freeorion.org/forum/viewtopic.php?t=894

Picking Battles to Control Manually in Multiplayer http://www.freeorion.org/forum/viewtopic.php?t=852


In this draft, some ideas have likely been forgotten or otherwise omitted. This can be fixed.


The discussion herein will roughly adhere to the following format:

I. Method Definition

II. Method Strengths

III. Method Weaknesses/Exploits

IV. Potential Modifications and brief thoughts on each


2. Criteria for a good Space Combat Proposal:

Time-wasting General: Proposed schemes for space combat must attempt to minimize the time that players are drumming their fingers and doing nothing (presumably while other players are actually engaged in something).

2.1 Time-wasting (weak) Proposed schemes for space combat must not allow players to waste the time of others to their own advantage. Example: One player has a large time allotment compared to other players in a particular battle, any paused time subtracts from all players allotments, phased-time is being used, and control over pausing is given to players. Said player may pause time in useless places and run out other players clocks.

2.2 Time-wasting (strong) Proposed schemes for space combat do not allow players to alter the amount of time other players have to interact in combat.


2.3 Tactical Control Proposed schemes for space combat must attempt to maximize the amount of control players have in as many battles per turn as possible (without wasting time, of course).


3. Combat Timing Methods

3.1 Real Time Combat

Definition: Ships and objects in battle interact continuously as players modify orders at their discretion. Combat does not halt.

Strengths:

Players do not have to wait on each other, fulfilling the strong Time-Wasting criterion.

Orders may be given at any point in time, giving control a fine granularity.

Weaknesses:

Speed of battle progression may be tedious at some intervals and rushed at others. Difficult to skip boring parts and may be difficult to give all desired orders in the thick of battle.

More difficult to program than alternatives?

Complex orders (Ex: Flank planet Cand support Group B) difficult to modify mid-battle (and may not be possible at all).


Modifications:

Modifications involving paused combat are discussed under Phased-Time

Variable speed real time: Allow players to speed up and slow combat. Difficult to do properly with more than one player and potentially exploitable. Would address main weakness of RT, a violation of the general Time-wasting criterion.

Battle Begins Paused (thanks to Ranos): Explicit pause at battle outset allows for complicated orders to be given easily (once).


3.2 Phased-Time Combat

Definition: Players may give battle orders only at fixed intervals. Battle execution pauses while this is done.

Strengths:

Potential for players to consistently give all desired orders without rush.

Speed of battle execution may increase, reducing time 'wasted' in non-interactive portion of battle.

Easier to program?


Weaknesses:

Time is wasted while players done giving orders wait for others to finish.

Battle order pauses may occur at inopportune moments. Critical battle junctures may be missed or players may have to pause briefly in boring places where no orders need be given.


Modifications:

Fixed-lengh pause: Assumed optimization: Pause ends before fixed length if all players confirm that they are finished giving orders. (Not considered to violate strong Time-wasting criterion, but DOES violate the general Time-wasting criterion.) If battle order pauses are of fixed length, the unrushed strength of the method may be lost.

Variable Length Pause - Some Players have more pause time than others This can arise due to some time-budgeting schemes occurring at a higher level (described in section 4). This modification violates the strong Time-wasting criterion. Players have greater potential to be pointlessly waiting for others to finish giving orders. This modification may arise to help ensure that all players have full tactical control.

Variable Length Pause - Certain portions of battle have longer pre-set pauses than others Very good to do this at beginning of battle to allow for complex orders and ship placement. May be possible to do this throughout the battle as well. Reduces time wasted at a cost of reduced control for some players or the converse, depending on how the pauses are arranged.

Real-Time Orders (thanks to Sky Keeper) - Orders may be given at any time, but are only processed immediately following a battle orders pause. Reduces wasted time, but becomes less effective for faster battle execution rates or for longer battle orders pauses (as the Player may forget some orders already given, but not yet executed).  ?Also may raise reflex-fairness issues if fairness is a criterion by which Phased-Time Combat is judged?

3.3 Variable-Pause Phasing

Definition: Essentially a modification to Phased-Time Comabt, wherein battle orders pauses are player-iniatiated rather than occurring at fixed intervals. Presumably, players must budget their paused time against some value determined before combat (or at game start) in order to reduce wasted time and unnecessary pauses.


Strengths:

Potential to eliminate useless combat pauses and pause only at the proper moments.

Retains Phased-Time advantage of increased battle execution rate.

Weaknesses:

Pauses may occur at points that are useful for one player and useless for another player. Likely if the number of players in a given battle is greater than 2. Violates the strong Time-wasting Criterion. Also violates the weak Time-wasting crtierion unless certain modifications are added (players may waste other players time to their own advantage).

Time budgets for pausing may have the potential to waste more player time in this way: Players may choose not to issue orders during pauses initiated by another player, instead waiting for their "own" pause at a better moment, violating the strong and possible the weak Time-wasting criteria.

To prevent too-frequent or 'surprising' pauses, multiple restriction have to be applied in this method. This makes it a bit more complicated than the others.

Useful general modifications:

Incentive to give orders: To combat one of the method weakness, implement a budget incentive for a player to give orders during a pause initiated by another player ... even if said player would rather do it three seconds further into the battle. Possible incentives: player time budgets decrease, but slowly, after they finish giving orders (but while another player is still giving orders in a pause). A better incentive is needed (in my opinion) to make this modification useful and eliminate the mentioned weakness.


Delayed-response pausing: To prevent players from being caught off-guard by a battle orders pause initiated by another player. Players are informed that a pause initiated by Player Y will begin in X seconds. This modification must be balanced againt the increased tactical control of instantaneous pausing.


Other Modifications:

Budget cost to initiate pause: Players initiating a pause lose extra time off their budget. Player are prevented from attempting to waste others players time if variable-sized player time budgets are being used (discussed in section 4, hopefully). (Thanks to Impaler) To avoid "chicken" situations, all players must pay the budget cost whenever they wish to give orders, whether it be during combat or during a pause that has already been initiated by another player.

3.4 Other Modifications


Non Time-based Budgets (thanks to Ranos)-Applies to Variable-Pause Phasing and (perhaps) Phased-Time Combat: Battle orders pauses are budgeted by frequency or number rather than time. Serves as an incentive not too pause too frequently. Incentives need to be added to prevent excessively long pauses and to prevent players from choosing not to give orders during pauses initiated by others.

None at this time. Look for these if this document is revised or re-drafted.


4. Multiplayer Battle Selection

4.0 Unlimited Combats per Turn (thanks to Ranos)

Definition: Players may participate in all battles in which their empire engages.

Strengths:

Players have maximum tactical control of their battles. War effort is unhampered by shortcomings in the battle AI.

Weaknesses:

Players who have few or no battles must wait while others control theirs. This violates the weak Time-wasting Criterion and is impractical for any but a relatively small number of battles per turn.

Modifications:

Fee-based Observers: Idle players may observe the battles of others for a price. This would entail a "spy" game mechanic and may be difficult to make it "worth the price" in both game resources and player time.

4.1 Fixed Number of Battles per Turn

Definition: Players may choose a certain number of battles per turn to participate directly in. All other pending battles are decided by the AI.

Strengths:

Fairly simple.

Time is not wasted on unimportant battles (in general).


Weaknesses:

Unfair in the event of some players having multiple critical battles in one turn and others having very few. Player exploitable, to some extent. Other methods can mitigate this.

In the event of hard choices, players may get screwed by using up their precious battle choices on another player, while others get to beat up on the AI. Again, other methods can mitigate this.


Modifications:

Players may receive incentives to participate in battle with other players rather than try to beat up the AI. Mentioned in the second forum thread cited in the Introduction. This is intended to prevent some form of second-guessing ridiculousness that I didn't quite understand.

A maximum time limit prevents battles from dragging on too long and makes the scheme work toward the goal of the strong Time-wasting criterion.

4.2 Time Allotment

Definition: Players receives a time budget that they may divide as desired amongst the battles that their empire is engaged in. To prevent uninteresting scheming, they are (naturally) not given to know what battles others are participating in or which battles other player allot their time to.

Strengths:

Players may participate in more battles, for increased general tactical control.

More flexible than the Fixed Battles per Turn scheme, players may budget their time to make this scheme close to functionally identical to the other, if desired.


Weaknesses:

Reduced times alloted for each battle makes it more likely that players will see the beginnings but not middles or ends of their battles.

Battle scheduling by the server will be more complicated to minimize downtime between player-controlled battles.

Player exploitable in that players may initiate additional battle against a common enemy simply to make his budget less effective. However, this may pale in comparison to the fact that the common enemy is getting gang-beaten anyway.


Consider using Time Allotment with the Variable-Pause Phasing as a combat timing scheme,

Scenario 1: Time budgets are applied to battle orders pauses only. The potential for wasted time on the part of the player using the lower time budget is pretty nasty (as they wait for the player with lots of free time). Definitely violates the strong Time-wasting criterion.

Scenario 2: Time budgets applied to battle execution and battle orders pauses. Time allotments may really tip the scales against players with less time alloted. They can't help their time draining during battle and must give orders at a furious pace.

Scenario 3: Time budgets applied to battle execution (battle orders pauses are budgeted separately). If some players participate in many more battle than others, the separate battle orders budget may cause a lot of wasted time for the other players unless the schemes are made even more complex.


Time Allotment with Phased-Time Combat will be similar to Scenario 2 above.

Modifications:

Total time available for budget can be made to scale according to certain variables such as Total number of battles this turn, Total strength of forces in combat, or some other metric. This may make things more fair for players with a lot of battles, but will increase wasted time for the other players.

4.3 Simultaneous Engagment

Definition - Players select as many battles as they wish to control. However, they must control all such battles simultaneously (See Modifications for a possible variation.) This could be done with the use of tabs, or some such.

Strengths:

Players are more likely to see the beginning, middle, and end of engagments.

Any "boring" portions of battles created by Combat Timing methods may be used to control another battle, reducing wasted time. (See Modifications section for further mention)

Wasted time introduced by the limitations of battle scheduling for Time Allotment method is reduced or eliminated.

Syngergizes particularly well with Real-Time Combat (even variable battle speed may be implemented to work with Simultaneous Engagement).

Simplifies directly to Fixed Battles per Turn method (See Modifications section) if desired by player, but increases tactical control if desired.

Player may keep they option open by electing to participate in multiple battles and then concentrating on a smaller subset.


Weaknesses:

Network communication latency may severely hamper the number of possible battles handled simultaneously. (Will probably amount computationally and communication-wise to one huge battle with all forces involved). Addressed in part by one of the oft-mentioned modifications.

Potential for players participating in multiple battles to feel rushed and/or pressured to participate in more battles than they can handle.

Similarly, too much advantage may be given to players experienced with RTS games.

Additionally, incompatibilities between this method and Phased-Time and Variable-Pause Phasing must be resolved. Otherwise, players may be penalized for missing pauses that occur while they are engaged in another battle.


Modifications:

Multiple rounds: At the cost of increased battle scheduling complexity, multiple rounds of simultaneous combat may be allowed. This will reduced any "rushed" qualities and cut the game server a break as well. However, this will probably accompany a reduction in max time per combat.

 Ex:  Player participates in 4 battles scheduled for one round.  Max battle time is 10 minutes.  This crazy, micromanagement freak gets to play out all 4 battle simultaneously (if battle scheduling allows) for 10 minutes.   Alternately, Player participates in 4 battles schedule for 2 rounds.  Max battle time becomes 5 minutes, so Player plays out two battles at a time for 5 minutes maximum.


Staggered Battles: Battles scheduled to be simultaneous actually start at slightly different times to prevent initial give-orders periods and predictable boring periods (if any) from overlapping. Depending on the details, either results in a minor increase in wasted time (at beginning and end of round, only 1 battle may be unfolding) or subtracts a modest amount from time permitted for some of the battles. Simple ASCII diagram below:

(Diagram Broken...)

Example Modification specific to Variable-Pause Phasing: During player-initiated pauses, players who did not initiate the pause do not participate in the pause until they specifically elect to (and then terminate their order-giving normally).

This allows players who are focused on another battle occurring simultaneously not to lose time off their order-budgets just because another player paused when they weren't looking.


For Simultaneous Engagement to mesh perfectly with the complicated incentive modifications mentioned for Variable-Pause Phasing, new modificatoins are necessary. If there is interest, such modifications can be added in a revision of this document.


5 Miscellaneous Thoughts

5.1 Multiple-Turn Battles


To prevent wasted time, the schemes mentioned in this document are all likely to implement a maximum time for engagements. This would naturally result in battles that span multiple turns. If the designers wish to encourage this, the maximum timers can simply be shortened or the pace of battle otherwise adjusted. It should be pointed out again, at least, that multiple-turn system battles would encourage a game pace not unlike attacking individual planets separately ("Scenic Battle" ?). As such, the undesirability of multiple-turn system battle should not be cited as an excuse to implement "Scenic Battle" instead.


5.2 Conclusions


Real-Time combat combined with Simultaneous Engagment is a relatively simple means to maximize Tactical Control and minimize wasted time. The devil, as they say, may be in the details. The main reasons to decide against such a scheme would arise if the programmers feel that it is impratical to implement effectively. Additionally, the demand on the player to multi-task the managing of two (or more battles) at a time may be judged too great.


Phased-Time Combat has some shortcomings in the likelihood of unnecessary or "not enough" battle orders pauses arising. The scheme, however, seems simplest to implement and with some thought may lend itself well to any of the Multiplayer Battle Selection schemes.


Variable-Pause Phasing is effectively an optimization to Phased-Time Combat, but securing it against player abuse and time-wasting makes it complicated, especially when considered against the two advanced Multiplayer Battle Selection schemes.


Overall, the choice seems to come down to criteria not defined above: Implementation complexity and Player-execution complexity.


5.3 Final Word


This document has not been proofed and is in every way rough. If interest is high, it may be updated and modified based on new arguments, suggested additions, and clarity concerns. It is intended to be posted on the Wiki, but that depends on the author figuring out how to do so.