Space Combat (madness)

For what's not in 'Top Priority Game Design'. Post your ideas, visions, suggestions for the game, rules, modifications, etc.

Moderator: Oberlus

Message
Author
MisterMerf
Space Squid
Posts: 67
Joined: Sat Oct 02, 2004 3:38 am
Location: Saint Paul, MN (USA)

#136 Post by MisterMerf »

More readable version of Wiki document (moderator delete, if appropriate):
EDIT:Wiki now quite readable (soon to be updated)
Space Combat Proposals -- Categorical Breakdown

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.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) viewtopic.php?t=894
Picking Battles to Control Manually in Multiplayer 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.

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.

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. This is a double-edged sword. It can prevent players from attempting to waste others players time if variable-sized player time budgets are being used (discussed in section 4, hopefully). On the other hand, it may discourage players from pausing at all and instead wait for another player to pause. This could create a nasty game of "chicken" unless this modication is refined.

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


4. Multiplayer Battle Selection

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:
Scenario A:
|-----------------------------------Battle 1-------------------------------------|
|------------------------------Battle 2-----------------------------------------|
|------------------------Battle 3----------------------------------------------|
Scenario B:
|-----------------------------------Battle 1--------------------------------------|
|-------------------------------Battle 2---------------------------------|
|--------------------------Battle 3------------------------------|
(Diagrams don't look right in Wiki or in this post. *sigh*)

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.
Last edited by MisterMerf on Mon Oct 11, 2004 2:10 pm, edited 1 time in total.

Ranos
Dyson Forest
Posts: 234
Joined: Tue Mar 23, 2004 6:24 am
Location: Northern Wisconsin

#137 Post by Ranos »

@ haravikk

As Impaler said, the AIs can have trouble making good decisions in battle. The only two differences between your suggestion and real-time combat is that with your's, you get to give orders while the game is paused at the start of combat and you have to wait for your TFs to ask for help instead of being able to give it when you feel it is necessary. If I had to pick between these two options, I would pick real-time. It also wouldn't be to difficult to have a paused order giving time at the atart of the battle and then from there make it real-time.

@ MisterMerf

That is a mighty impressive write-up of some major points. I have a couple of modifications and point additions to add to some of your review. Now if I could just remember what they were.

These are in no particular order.

Addition to Section 4:

4.4 Unlimited Combats per Turn

Definition: Players may participate in as many battles as they can create per turn.

Strengths: Players miss nothing in their battles. They don't have to worry about other players outsmarting the AI controlling their fleets.

Weaknesses: Players who have few or no battles must wait while others go through their battles. This violates the weak Time-wasting Criterion.

Modifications: I have a semi-solution to the time wasting problem. Allow players who don't have combats, or have fewer combats than others, to watch other peoples battles, for a fee of course. This would simulate the real world (Please, no realism remarks) act of being able to study your enemy. The cost would basically represent the cost of planting a spy or sending a spy ship to watch the battle. The spy is of course you. This would add another level of tacitcs and strategy since there would be the possibilities of your enemies building ships to counteract your's as well as them learning your battle tactics.

Modification to 3.3

While I am in favor of Method 3.2 Mod 1 (fixed length pause), I can help alieviate some problems with other options.

Change to definition: In addition to, or in replace of the clock which runs down when the game is paused, players are only allowed a certain number of pauses per battle. This would help prevent the battle from getting paused every 3 seconds.

2. When a player decides to pause the action, a message pops up for all other players in the battle asking if they wish to give orders. This message will stay up for no more than 5 seconds. At the end of those 5 seconds, it will A, assume you do wish to give orders and your clock will begin to run out or B, assume you don't wish to give orders and will automatically wait for battle to resume. This could be a player option, a game option or it could just be programmed in. If a player decides to give orders, this counts as one of their pauses, if that part is used, and of course it runs down their clock.

3. When the final player clicks the done button, a message will appear for all players alerting them that combat will resume in 3 seconds or some short ammount of time.

Modification to 3.1

At the beginning of a real-time battle, there is a paused portion in which orders may be given. This allows players to give complex orders at the beginning of battle and adjust them as needed through the course of battle.

I believe that is all additions I would make to the review. Now on to some other thoughts.

Currently, there are two options for the "battle-field" size. Those are planet and system. As I have stated in other posts, I'm in fovor of system. With the three Combat Timing Methods listed by MisterMerf, I feel that Real-time would not work with system level combat. This is due to the fact that you could have ships in multiple different locations on the map and with Real-time, it would almost be impossible to keep track of everything.

It would also be fairly unnecessary to use either of the phased options in planetary combat since it is mainly the two side advancing towards eachother and there wouldn't really be multiple battles going on at once.

Unless MisterMerf or someone is already doing it, I'll write up a review on Planet vs. System combat. Hopefully, I'll post that tomarrow during the day.
Last edited by Ranos on Mon Oct 11, 2004 9:26 pm, edited 1 time in total.

Sky Keeper
Space Krill
Posts: 5
Joined: Sat Oct 09, 2004 9:12 pm
Location: Russia

Phased-Time

#138 Post by Sky Keeper »

One observation regarding Phased Time: if it the game is in the middle of a real-time phase nothing should prevent you from giving orders as if it's a full realtime battle. This fixes the problem of pausing occuring at inappropriate moments.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Phased-Time

#139 Post by Geoff the Medio »

Sky Keeper wrote:One observation regarding Phased Time: if it the game is in the middle of a real-time phase nothing should prevent you from giving orders as if it's a full realtime battle. This fixes the problem of pausing occuring at inappropriate moments.
It also undermines a main goal of phased time, which was to make giving orders not dependent on being able to click faster than the opponenent, like in Warcraft or other RTS battles.

MisterMerf
Space Squid
Posts: 67
Joined: Sat Oct 02, 2004 3:38 am
Location: Saint Paul, MN (USA)

Re: Phased-Time

#140 Post by MisterMerf »

Sky Keeper wrote:One observation regarding Phased Time: if it the game is in the middle of a real-time phase nothing should prevent you from giving orders as if it's a full realtime battle. This fixes the problem of pausing occuring at inappropriate moments.
In one interpretation, this doesn't really distinguish Phased-Time from speed-reduced Real-Time.

If taken in the Phased-Time spirit, orders can be given during real-time segments but are not interpreted until a battle orders pause has been completed. I'll add a note about this in the Wiki document. Could reduce wasted time and probably won't be confusing as long as real-time segments don't last too long.
Edit: If the battle execution speed in phased-time is much higher than a normal real-time pace, this modification may not be worth the trouble.

Ranos: I'll merge your comments into the Wiki doc as well.

User avatar
utilae
Cosmic Dragon
Posts: 2175
Joined: Fri Jun 27, 2003 12:37 am
Location: Auckland, New Zealand

Re: Phased-Time

#141 Post by utilae »

Sky Keeper wrote:One observation regarding Phased Time: if it the game is in the middle of a real-time phase nothing should prevent you from giving orders as if it's a full realtime battle. This fixes the problem of pausing occuring at inappropriate moments.
This is incorrect. In phased time, the idea is that you can only give orders in the turn phase. You cannot give orders in the real time part. The real time part is intended to be short, maybe visually pleasing and to watch.
MisterMerf wrote: If taken in the Phased-Time spirit, orders can be given during real-time segments but are not interpreted until a battle orders pause has been completed.
This idea would not work very well. If you give an order during the real time phase, then the order may be given in vain. This is because the ship will have moved since you gave the order. And the move order you gave during real time may no longer be approprate during the turn phase.

Impaler
Creative Contributor
Posts: 1060
Joined: Sun Jun 29, 2003 12:40 am
Location: Tucson, Arizona USA

#142 Post by Impaler »

Agree with Utilae you should give orders only durring the paused phases, execution is completly non-interactive. Atempting to give orders that will be remembered and executed on the following excution phases would be counter productive as the player would probably spend more time canceling obsolete orders then they do giving new ones.

A variation to Variable-Pause-Phasing. Rather then all players clocks begining to run down when any player pauses only the pausers clock would run and only he could give orders. This could avoid the chicken problem as you cant save yourself any time by waiting for others to pause first. If combat is paused for one person to give orders then any other player who also wishes to give orders must make their own independent pause with its associted costs. Execution begins when everyone has confirmed orders.

Modification to 4.2

At game start up several paramiters are set that effect the scaling of time alocations. Possible variables are "Seconds per your Ship Cost units" "Seconds per Total Cost units", "Seconds per # Task Forces/ships", "Seconds per player in battle". Each side in a battle is evaluated by these rules and given a time alotment for that battle. For example 3 players are in a battle and player 1 has 2:00, player 2 has 1:45 and player 3 gets 3:10. Now each players raw time gets multiplied by a handycapping % which can be set at game startup to help slower players or challenge skilled ones. Lets say Player 1 had a 200% handycap, 2:00 is multiplied by 2.00 and his total is now 4:00.

At the end of the Main Galactic turn their is an optinal "time Budjet Phase". The player can view tactical information on each of his battles and see the default time aloted to each as calcutated by the above system. The player can shift time from one battle to another probably by means of a slider bar for each battle, a qick press "auto resolve" button can be pressed to set a battle to zero time aka autoresolve (note that this effects only HIS forces in the battle). Their might be some kind of limit or expidential cost to assign huge amounts of time for a single battle (every additoinal second above X cost 2,3,4 seconds from other battles). Also as the player is viewing and manipulating these sliders their total time is running down (possibly faster or slower then happens in actual battle). They loss time from ALL of their battles proportionaly. When they are happy with their budjeting they can press a confirm button to stop their time loss. When all players confirm then the server starts pairing off people for battle engagments.


Also you stated that Phase Time Combat will use Senario 2

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.
I would strongly opose that. Senario 1 is definatly the way to go, total Execustion time should be identical for all battles independent of all other factors even auto-resolved battles execute for this set amount of time. This is a nessity for battles rolling over to the following turns and for re-enforcments to enter battle in a logical well timed manor.
Fear is the Mind Killer - Frank Herbert -Dune

noelte
Juggernaut
Posts: 872
Joined: Fri Dec 26, 2003 12:42 pm
Location: Germany, Berlin

#143 Post by noelte »

Ok, starting from tactical moo like combat i'm on the move to phased real time. One little question, what's about the time between the points we issue commands? I mean, in time when orders are executed, some kind of AI have to take over!?

One sidenote, will we have different AI? Maybe we see different AI when advancing in research!?
Press any key to continue or any other key to cancel.
Can COWs fly?

User avatar
utilae
Cosmic Dragon
Posts: 2175
Joined: Fri Jun 27, 2003 12:37 am
Location: Auckland, New Zealand

#144 Post by utilae »

noelte wrote:Ok, starting from tactical moo like combat i'm on the move to phased real time. One little question, what's about the time between the points we issue commands? I mean, in time when orders are executed, some kind of AI have to take over!?

One sidenote, will we have different AI? Maybe we see different AI when advancing in research!?
I imagine that in the order phase you would have given movement orders (kind like waypoints I guess on where to move) and attack orders (what targets, what weapons to use).

Then the order phase is over, its like pressing play, the ship would move along the waypoints, when it gets in range fire its weapons, etc. We'd have to figure out how it woould work exactly.

noelte
Juggernaut
Posts: 872
Joined: Fri Dec 26, 2003 12:42 pm
Location: Germany, Berlin

#145 Post by noelte »

IMO, waypoints are rather bad. You would have to know how your enemy is moving. I think targeting enemy forces could work, but in this case we need pathfinding/tactical movement, which is calculated.
Press any key to continue or any other key to cancel.
Can COWs fly?

User avatar
utilae
Cosmic Dragon
Posts: 2175
Joined: Fri Jun 27, 2003 12:37 am
Location: Auckland, New Zealand

#146 Post by utilae »

noelte wrote: IMO, waypoints are rather bad.
Well I was thinking of making it so that ship would not just ba moved to a destination, maybe you want to make it go a certain route, or do a few 'twirls' before getting there.

Also I was thinking of waypoints more like how you would draw a segmented line. You click to go there, then there, then destination.
eg.
.\destination
../
.|
<>ship

emrys
Creative Contributor
Posts: 226
Joined: Fri Oct 24, 2003 3:44 pm

#147 Post by emrys »

haravikk wrote:What if combat was less direct orders but more decision based?

<snip>

(The player's AI) ... will look out for certain circumstances, for example ships being surrounded, a mission being complete (and not being sure of what to do), heavy damage being suffered and so on.
When this happens a 'Situation' appears in the player's list, highlighted based upon severity. They may click on this to be presented with options (if being surrounded then a 'break through' option might appear, generic options such as re-assign to mission X could be available too), they can use this to change that AI's goal.

<snip>

In larger (or otherwise 'busier') combats then the game-speed could slow down to say no less than half-speed until the amount of 'situations' decreases, think along the lines of bullet-time but for giving a player more of an opportunity to make decisions without being totally overwhelmed.

Even with the 'bullet-time' feature players could still have a lot of decisions to make, the key to keeping up would be to filter out minor situations and pick out only the important ones, leaving the admirals to deal with the rest themselves.

This would emphasise a good initial plan as well, as that would determine much of the AI's default behaviour in combat.

The 'bullet-time' idea could also be employed in reverse to speed up slow parts of the combat or hurry along parts which don't require any player-input to help keep combats from lasting too long (though a finite limit would be handy anyway).
Just to say, there's something I like about this, the idea of only requiring players to direct the complex parts of the combat, and of the combat engige intelligently adjusting the rate of flow of combat time to maintain an enjoyable pace.

Of course the devil would be in the details, or more specifically the hard work would be in the implementation, but a few steps in this direction might not be a bad idea...

It might nicely show the properties of combat seeming all nice and easy until it develops away from your initial plan, after which it becomes more an more an exercise in holding things together and patching up the bits where it's all unravelling.

MisterMerf
Space Squid
Posts: 67
Joined: Sat Oct 02, 2004 3:38 am
Location: Saint Paul, MN (USA)

#148 Post by MisterMerf »

Impaler wrote:Agree with Utilae you should give orders only durring the paused phases, execution is completly non-interactive. Atempting to give orders that will be remembered and executed on the following excution phases would be counter productive as the player would probably spend more time canceling obsolete orders then they do giving new ones.
I also agree. I was just dutifully adding a conceivably useful mod.
Impaler wrote: A variation to Variable-Pause-Phasing. Rather then all players clocks begining to run down when any player pauses only the pausers clock would run and only he could give orders. This could avoid the chicken problem as you cant save yourself any time by waiting for others to pause first. If combat is paused for one person to give orders then any other player who also wishes to give orders must make their own independent pause with its associted costs. Execution begins when everyone has confirmed orders.
Well, why didn't I think of that? =]
(MisterMerf updates Wiki ...)

Edit: Waaaaaaait a second. The reason I was thinking of for players not to pause was that "the right moment has not yet arrived". While useful, this addition doesn't give the players a strong reason to give orders during another player's pause. It remains merely convenient (which may be strong enough, I won't be the judge).

Edit: Ignore the above edit. I had forgotten which element of Variable-Pause Phasing was under discussion. =P

Impaler wrote: At game start up several paramiters are set that effect the scaling of time alocations. Possible variables are "Seconds per your Ship Cost units" "Seconds per Total Cost units", "Seconds per # Task Forces/ships", "Seconds per player in battle". Each side in a battle is evaluated by these rules and given a time alotment for that battle. For example 3 players are in a battle and player 1 has 2:00, player 2 has 1:45 and player 3 gets 3:10. Now each players raw time gets multiplied by a handycapping % which can be set at game startup to help slower players or challenge skilled ones. Lets say Player 1 had a 200% handycap, 2:00 is multiplied by 2.00 and his total is now 4:00.
That block (and the budgeting one that follows) sounds far too intricate to me. I cautiously suggest that such a system will drain more fun from the experience than it will contribute fairness to the system.
Also you stated that Phase Time Combat will use Senario 2
I'll adjust it. Scenario 2 is definitately undesirable, but for the instant's thought I gave it, that was the only way I saw Phased-Time getting implemented.
Last edited by MisterMerf on Tue Oct 12, 2004 11:15 pm, edited 2 times in total.

MisterMerf
Space Squid
Posts: 67
Joined: Sat Oct 02, 2004 3:38 am
Location: Saint Paul, MN (USA)

#149 Post by MisterMerf »

emrys wrote: Just to say, there's something I like about this, the idea of only requiring players to direct the complex parts of the combat, and of the combat engige intelligently adjusting the rate of flow of combat time to maintain an enjoyable pace.

Of course the devil would be in the details, or more specifically the hard work would be in the implementation, but a few steps in this direction might not be a bad idea...
I think the devil in those details will be considerably nastier than other AI devils. If ship AI can't carry out missions perfectly, as least it carries them out predictably. Even the pace of combat might be intelligently controllable by AI.
haravikk seemed to be suggesting that the AI could decide when the player needed to give orders. I very seriously doubt that the AI will be able to do this to the tastes of every player and this is one element (unlike predictably dumb ships) that will be unfixably aggravating for a player to deal with.
emrys wrote: It might nicely show the properties of combat seeming all nice and easy until it develops away from your initial plan, after which it becomes more an more an exercise in holding things together and patching up the bits where it's all unravelling.
It all depends on what we want from our combat, but this is one element of realism that I, at least, don't want to see. =P

Ranos
Dyson Forest
Posts: 234
Joined: Tue Mar 23, 2004 6:24 am
Location: Northern Wisconsin

#150 Post by Ranos »

Here's another thought that I just had. In many TBS games, one of the options for multiplayer is Hot Seat. MOO2 had it, Civ3 has it and I'm sure there are other games that have it. MOO3 doesn't have it because it would be impossible with Real-time combat.

Using Phased-Time combat eliminates this problem. It is a perfect union between Real-time and Turn based combat. In hot seat, the battle begins and player 1 gives his orders. When player 1 is done, player 2 gives his orders. Then they get to watch their orders played out.

I'm not saying that hot seat multiplayer is a huge influencing force here but it does give another plus to phased-time.

Post Reply