76

(3 replies, posted in Starmada)

p. 60 of S:AE says:

"Striker flights have a capacity requirement of 20. If using option F.1: Customized Fighter Flights, the initial coefficient in the capacity requirements formula is 19, not 183."

But (19 * 7^2 * 10 * 1/6 * 1/6)^(1/2) rounded up is 17, not 20. The formula is correct for non-striker fighters, why not for strikers?

I don't see anything about this in the FAQ.

77

(12 replies, posted in Starmada)

Ken_Burnside wrote:

We know that hexes are small enough that an explosion blocks line of sight, and that the turn length is short enough that this blockage has a duration.

This was true in previous editions, but not in SAE; explosions are now instantaneous.

78

(4 replies, posted in Starmada)

I agree -- use pre-built ships for the first campaign. The ships in SAE would be a good choice.

Tightening the optional rules way down is good, too. Could you use those ships with no optional rules?

Declaring all fire simultaneously, rather than ship-by-ship, would be a reasonable speedup for PBEM.

79

(36 replies, posted in Starmada)

I'm inclined to think any such thing should be emergent, not a rule. There should be a reason for bringing cannon fodder. In a campaign game, that reason may be the need to defend many systems...

80

(13 replies, posted in Starmada)

Yeah, we're currently contemplating limiting arcs to forward (G), port broadside (HJ), starboard broadside(IK), and aft (L).

81

(56 replies, posted in Starmada)

cricket wrote:

Next, consider the fixed-point scenario. A starbase is 100 hexes away, with unlimited range on its weapons. You have a ship with range-X weapons and engines Y. How many turns must you weather the storm before getting to return fire?

Answer: (100-X)/Y

Doesn't that assume old-style movement, where you can't accelerate over the course of several turns?

Of course, your point is even stronger taking this into effect.

82

(13 replies, posted in Starmada)

We're contemplating severely limiting range in our next campaign (to 12 or even 9), but not for the reasons described here. We think shorter weapon ranges may effectively make the map bigger and make maneuver more important, which is a Good Thing.

83

(91 replies, posted in Starmada)

cricket wrote:
go0gleplex wrote:

c) scrap the movement system and go to a true vector type system in which delta vee can be built up making that 30 range weapon a much smaller problem.

Oh, that's SO not gonna happen. smile

Not after the pain and agony that went into the current movement system...

I was skeptical about the new movement system, but the more I use it, the more I like it. You get almost everything you'd want out of a vector system without the destination marker (or equivalent bookkeeping). Heck, if you stack miniature poker chips under each ship to indicate speed, you don't need any bookkeeping...

84

(27 replies, posted in Starmada)

FlakMagnet wrote:

So I agree that weapons shouldn't be included that trump the fighter's ability to fire before other ships and inflict their damage instantly.

I do however, think that something has to be done to allow players to design weapons systems that head off the fighter's ability to launch in the order's phase and attack untouched.

Perhaps the best counter to fighters is not some special weapon system, but defense in depth: spread your fleet out enough that, while the fighters can swarm the forward elements, they'll be swatted out of the sky by some rear ships before they get a second attack.

Each weapon in a battery with the "Anti-fighter" trait would have it's target assigned and firing resolved during the fighter phase as if it were a fighter flight.

Y'know, one could try having fighters do their thing during the combat phase, rather than in a separate phase. When it's your turn, you can either fire a ship or move and fire a fighter flight. In either case, the damage takes effect immediately.

The drawback of this rule (and of sequential combat in general, as per E.5) is that initiative becomes hugely important in a battle with only a few starships. A one-on-one duel might well come down to the initiative roll.

85

(166 replies, posted in Starmada)

OldnGrey wrote:

I just tested both the Shipbuilder and the Shipyard.

It is possible to cut and paste all of the text in one go by selecting all of the text cells at the same time.

Okay, I guess I just pasted into an application that was "too smart" (Apple's Pages word processor) which reproduced the table. It works if I paste into something like Emacs.

You mention the Shipyard. Where do I find this? I only see the Shipbuilder on the MJ12 Starmada page.

86

(166 replies, posted in Starmada)

One of the points of Drake notation was to be able to cut and paste the text into other documents (e.g., email messages). This doesn't work at present, because the text is spread across multiple cells.

Can we get it all in one cell in the future?

87

(5 replies, posted in Starmada)

I agree completely -- the shipbuilder should be able to read in files it generates (in some format)!

cricket wrote:
andyskinner wrote:

I find that I don't mind this kind of revision--I don't really expect to figure ships by hand.  The only thing I wish is that the builder was a program which could read my ship description, because in order to get my ships current, I assume I'll have to enter them again into the new one.  Is there another way?

There has been talk of such a thing -- part of the reason why I wanted to standardize Drake Notation -- but at the moment the only option is to re-enter the information by hand.

Now I remember why my instincts led me there: it's correct Newtonian movement. The delta-v required to get from move N hexes/turn heading north to N hexes/turn heading 60 degrees east of north is N.

There are only two things I would change:

1) Get rid of moving one space between turns. Is there a reason for this rule? It feels like a holdover from tank movement.

2) Use speed, rather than ceil(speed/2) as the turn cost. I'm still open to argument here, but it seems good to me if turning is difficult -- makes arcs matter.

I still prefer (in untested theory) the following:

Use MP to accelerate or decelerate. Turning costs <speed> MPs. Sideslips are interchangeable with forward moves. There is no special "Agile" or "Nimble" designation, but overthrusters exist as per previous editions of Starmada.

This system has no restrictions on when you can turn or sideslip. If you have 15 MPs, you're welcome to come about in one turn at speed 5.

Sideslips are, as David notes, necessary to eliminate hex grain issues; I believe that, using hexes, your facing/heading is an approximation, so you should be able to move in any direction that is within the approximate arc. It is technically more correct to not allow consecutive sideslips (so the approximate arc is 60 degrees wide rather than 120), but I'm willing to trade that amount of realism for lower predictability and simpler plotting.

As for fighters and other small craft, I'd prefer for them to just have 10 MP/turn with no inertia. I realize that a ship with a head start can therefore outrun faster fighters, but with a little handwaving this can be explained as a simulation of the fighters' limited fuel capacity. Since fighters are so fragile and simple, keeping track of speed for each flight seems like too much work.

I believe this has all the advantages of the system David proposes, while being simpler.

Counterarguments? Playtests that reveal fatal flaws?

91

(15 replies, posted in Starmada)

I have traditionally used a vanilla vector system (destination markers, 1 MP to turn or accelerate in the direction of facing). I might be willing to use something a bit closer to airplane movement if (a) it allowed building up speed over several turns and (b) it didn't allow ships without a LOT of MP to make high-speed snap turns.

92

(36 replies, posted in Starmada)

D'oh! Didn't realize there was now a third page of posts.

Dan's solution works well, too.

93

(36 replies, posted in Starmada)

KDLadage wrote:

As far as costing it... I agree with Marcus: the payback should be less than the gain. You cannot have a weapon that fires once in 20 rounds ... but fires a "map killer shot" when it does without having trouble. One way of mitigating this, without mucking up the calculations, is to state that, at the start of the game, a weapon with a "delay" factor cannot fire until turn X, where X is the delay factor.

This seems eminently reasonable. With any luck, the gain in punch cancels the loss in flexibility, so a weapon that fires every other turn costs half as much as a weapon that fires every turn.

Of course, we can steal from SFB the idea of a weapon that gets more powerful as it charges, so you have to decide when you have enough...

94

(36 replies, posted in Starmada)

Hmm, even three phases feels too bookkeepy to me. (At the same time, I have to admit I liked the old Starfire system.)

What about an "opportunity fire" system where you can (perhaps at a penalty) fire at a ship at some earlier point in its movement path for the turn?

95

(36 replies, posted in Starmada)

Oh, and one other thing:

I agree with KDLadage that there should be a sense in which one side of a large ship can be weakened, in terms of defenses and/or firepower. There's not point in maneuvering around a spherical opponent with a uniform distribution of turrets.

96

(36 replies, posted in Starmada)

I agree with the observation that maneuvering is not as important as it should be.

The "simple vectored movement" KDLadage suggests might be a good solution. I wouldn't mind seeing the formulae adjusted so that small ships can, in principle, move MUCH faster than large ones. Imagine the Millenium Falcon flitting among Star Destroyers. Having a number of nearly-immobile "fortresses" on the map has the side benefit of creating terrain, something that is always lacking in space games. Also, while small, fast ships might continue the AB tradition, larger ones would be forced to have a little variety.

For a more realistic Newtonian system, perhaps the cost of rotation (as opposed to acceleration) should depend on the size of the ship. One obvious solution is to use the explosion size table to determine the cost for a 60 degree rotation. Very large ships, especially those with engine damage, might not be able to rotate, at least not in one turn...

I support fractional ROF, so I can buy a bigger weapon that can fire only every N turns. This should be priced so that I get something in return for the lost flexibility, e.g., I can fire 50% as often for 40% of the cost.

Cricket says, 'quoting from Hughes, "The tactical maxim of all naval battles is Attack effectively first."' Does anyone know of a corresponding maxim for air combat?

97

(123 replies, posted in Starmada)

OldnGrey wrote:

Go to the copy of the text page.

In Edit/Find&Replace,

Find All "Template"

Replace All with the name of the Template copy you wish to link the text page to ie "Template_2"

Paul

That did the trick.  Thanks!

98

(123 replies, posted in Starmada)

I've downloaded Shipyard StarmadaX v7.xlt.zip.  I copied Template to a new sheet and entered in my ship design.  How do I get a copy of the Text sheet to read info from this design?

Peter Drake

99

(8 replies, posted in Starmada)

We've been using the Newtonian movement rules here without any problems for a couple of years:

http://www.lclark.edu/~drake/starmada/maxburn.pdf

100

(9 replies, posted in Starmada)

Nahuris wrote:

Yes, because the issue appears to be that the fighters attack a small ship and kill it during the fighter phase. This immedietely puts an explosion on the board, which blocks line of site. If the fighters are behind it, in relation to the enemy, then they can't be fired on.... Next round, the fighters move up.

There is nothing to stop someone from stacking 6 wings of fighters in one hex, and rolling 36 dice against every target, while halving their shields......

One of the reasons that our ships only explode at the end of the turn.......

The other option would be to always run your smaller ships in groups, so that no matter where the fighters are, there is someone with LOS, or to field large numbers of fighters yourself..... at that point, all you would have is two carriers on opposite ends of the board, and swarms of fighters in the middle, with a "may the best dice win" feel to the game.....

Yes, this has been precisely our problem.

It's not just that explosions provide cover for fighters.  It's that explosions provide cover from behind which fighters can move during the fighter phase, attack, and then (by creating a new explosion) be behind cover again by the time starships get to fire.

Incidentally, I think there's a difference between

Uncle_Joe wrote:

if you have to use 'x' to counter 'x', than 'x' is too powerful

and

cricket wrote:

if you have to use X to counter Y, then Y is too powerful

The latter case is a sort of rock-paper-scissors mechanism, which can be interesting.  The former makes the game about x -- whoever brings the most x wins.  While Starmada has variant fighter types, it's about starships -- that's where all the interesting rules are.