You are not logged in. Please login or register.
Play nice. (This means you.)
Logins from the previous forum have been carried over; if you have difficulty logging in, please try resetting your password before contacting us. Attachments did not survive the migration--many apologies, but we're lucky we kept what we could!
mj12games.com/forum → Posts by mj12games
Isn't how armor or shield (in an ablative way) would work?
Not exactly.
My understanding of "ablative" in this context has always been like shields in SFB/FC -- they absorb X amount of damage and then they're gone. I believe what Ken was asking about is more like damage reduction in Silent Death, where every weapon hit is reduced in strength by X points.
Is there a way to get armor that works like "Damage Resistance" without breaking the game engine?
It wouldn't necessarily "break" the game, but there are two considerations:
1) Over what span does the DR work? (Is it -X damage points from each attack? Each turn?)
2) How would this be incorporated into the point costing system?
It's saying "Shift 2 columns right." I'd be tempted to make the convention N> for right shifts, and N< for left shifts, and explicitly call them column shifts.
I can see this.
I would also try to make sure that the unmodified use of the weapon used the leftmost column, and make sure that ALL of the column shifts went right.
One reason why I would resist this is the existence of weapon traits like "doubled range mods" and "inverted range mods". These are self-evident if the basic mods are +1/0/-1; not so much if the basic mods are 0/-1/-2.
Did you consider using the Decibel/Richter scale for this for increased granularity? That one has the advantage that +3 steps is a factor of 2 and +10 steps is a factor of 10. If you're not familiar with it and are interested, I'll walk you through the numbers. (I use it for population level mapping in Squadron Strike campaign games.) It would probably multiply the length of your tracks by 50%; I'm not certain, given the scale of game you're making, that the granularity it gives is worth the extra printed space on the ship sheet.
I did look at some other possibilities -- not the Richter scale in particular -- but I really like the results the 1/(2^.5) scale is giving. In particular, a -2 modifier (>2 column shift) is equivalent to 1/2; -3 is (roughly) equivalent to 1/3; -4 is equivalent to 1/4; etc.
Your system conflates direction of thrust-and-facing to direction-of-travel as a simplification, as a way to minimize record keeping, and does not produce an actual Newtonian vector solution. It does teach players how to maneuver with momentum.
Point taken. In the end, I have no quibbles really with what it's called, since in the actual rules, it's just "Movement". 
If someone can add or subtract their thrust rating from their current velocity by using the STRAIGHT AHEAD maneuver, why can't they move backwards? This is something that a vector movement system WOULD allow.
A ship could move "backwards" with a negative speed value and the rules would remain unchanged. It would require an allowance for what happens when a ship switches from a negative to a positive speed. Perhaps this:
A ship with a negative speed value moves backwards, instead of forwards. In all other respects, its movement is unchanged. A ship may switch from negative to positive speed (or vice versa) only when executing a "Straight Ahead" maneuver. When doing so, the difference between the starting speed and ending speed cannot exceed the ship's thrust rating.
For example, a ship with a thrust rating of 5 and a current speed of -2 carries out a "Straight Ahead" maneuver. It can either (a) remain motionless, with a speed of zero; (b) move backwards between 1 and 7 hexes, or (c) move forward between 1 and 3 hexes.
Regarding the 30* changes in heading/facing, I think it could be done -- it would, however, wreak havoc on firing arcs...
Not really - your old 12-point firing arc system where you listed arc letters is 30 degree firing arc resolution. Your nomenclature was interesting; I'd done it as 12-o-clock-is-forward and going clockwise around the base, because most people remember "He's on your 6! He's on your 6!" from WWII movies.
I think what I meant was, what the "FF" arc looks like when a ship is facing a hex side is different than what it looks like when facing a hex corner.
I'd also seriously think about referring to these not as -1 and -2 modifiers, but as "column shifts". I'd also set your convention to the base shift as the left most column and make all the shifts go in the same direction, rather than your current minus-and-plus system. It saves a type of math step at the table.
Not sure I follow the "set your convention to the base shift" part of your suggestion...
Marc, I've been very careful to be friendly and polite, and not knock other people's choices in games. I'm offering my opinions to help Dan make the best version of HIS game that he can, including clarifying terminology.
And the effort is appreciated.
I first heard about this re-design from customers who said "Well, it looks like your only competition for "Design everything in the game" product space is abandoning it." ... I hope that the people who've come to me worried that he's gutting the design engine are proven wrong;
I find this odd... certainly, I expected there would be those who disagree with some of the choices being made in the new edition. But I'm at a loss to figure out where people would get the impression that I'm "abandoning" the design-anything-you-want approach... ?
As long as we're all blowing up spaceships, we all win. I try to encourage everyone to play everything ...
May I get the same courtesy in return, please?
Hear, hear.
question about the errata for the two products with stickies. Did those get worked into newer printings of the books?
The errata have been provided to ADB; I don't know whether they have been incorporated into new printings or not.
Not sure I understand why this does not constitute "vector" movement.
A vector is a mathematical expression of magnitude and direction. In this system, every ship has a speed (magnitude) and heading (direction). The limitations on a ship's movement are based on the amount of thrust required to change from one vector to another. (e.g. if a ship starts the turn traveling 3 hexes/turn to the "north" and ends moving 4 hexes/turn to the "south", the amount of thrust applied was 3 + 4 = 7.)
The fact that the actual math is hidden from players, or that for simplicity's sake a ship's facing always equals its heading (absent the optional "pivot" rule), doesn't mean the system is any less vector-based (which is typically how I refer to it). But to call it "momentum-based" or "airplanes in space" doesn't really encompass what's going on -- IMHO, of course.
Regarding the 30* changes in heading/facing, I think it could be done -- it would, however, wreak havoc on firing arcs...
I'm not sure I follow. You mean like the SAE "Faceted Shields" rule?
No edition of Starmada to this point makes any distinction between port/starboard firing arcs and forward/aft arcs. All are point-costed solely on the width of those arcs.
Close Defense Cannons [FF3][FP4][FS4][AP6] 2-4-6 14-10-7-5-3-2-2-1-1-1-0-0
Why does this have 2 groups of numbers?
First group (2-4-6) is the weapon's range bands.
I don't think the firing arc mods can always be taken at face value for the percentage of weapons firing into a particular arc due to the formula involved, but hopefully you get the idea.
It's pretty close:
-1 = 70%
-2 = 50%
-3 = 35%
-4 = 25%
-5 = 18%
-6 = 13%
etc.
So why would you take that? Just for fluff?
It's primarily to go with the dual-mode weapons rule, which requires a weapon's modes to have the same range for the ORAT calculation. With the "carronade" trait, you can simulate a shorter range with one mode.
How's about this for an alternative: ship would move forward equal to its velocity, and then could use its thrust to move itself anywhere within its thrust rating of that end point.
Actually did toy with this for a bit before drifting back to a modification of the existing AE movement rules.
Perhaps this is an easier solution than the optional "pivot" and "delayed turn" rules.
This doesn't sound like vector movement at all. Why must a ship exceeding its thrust only go in a straight line? It would turn widely if it was going so fast relative to its thrust, but it certainly would not be limited to a straight line.
True, but such a wide turn is impossible to (simply) model on a hexgrid. See below.
I don't think I like the idea of a ship having to spend an entire turn doing nothing but decelerate before it can make even a minor course adjustment.
The problem is the hexgrid, which sets the minimum course adjustment at 60*. If a ship is traveling 500m/s, and wants to alter its course by 60*, it must expend enough thrust to accelerate to 500m/s in a direction 120* off of its current course. Thus, if a ship's speed exceeds its current thrust, it cannot accelerate fast enough to complete a 60* turn in a single movement phase.
This is the same principle that underlies the existing movement system, and can be offset with the Delayed Turns option (D.2).
I'd give you an update, but I was told to stop spending so much time on the forums and to get back to work...
Yes. Dual-mode weapons will continue to be supported -- in fact, they will be improved, in that the different modes will now be allowed different range values.
Oic. Hmmm, if the armor is going to be done like that, then what value, if any does armor have?
Not sure I understand the question. The "value" of armor is to increase the number of hits the ship can take before going "boom".
I am curious, why is the armor broken up into three parts the same as the hull? In many other games I have played the armor is marked off first, then the rest of the ship. (Examples are SFB, Full Thrust, Starfire)
In my opinion, armor shouldn't work like that. Armor increases the resistance of the hull to damage, but to assume that all of a ship's armor "plates" need to be shot off before any damage can reach the hull is just silly.
Ship A has 9 armor and 27 hull (arranged in three rows of 9). This ship will have to take 18 points of damage before its first threshhold check is made.
This is not correct. Armor is arranged in three groups, like hull. After the first 1/3 of armor is checked off, you move to the first group of hull boxes. Thus, in both cases the first damage checks are made after 12 points of damage.
cricket wrote:
That being said, Starmada has never really been intended to simulate ship-vs-ship duels.
Well, even it was not intended that is what happened ... SFB is definitely a ship-vs-ship kinda of game. (Large fleet battles are hard to play and take a long time) And doing a direct conversion communicated to the SFB community that it was a ship-vs-ship kind of game.
Not to be argumentative, but this makes very little sense. By that logic, any WWII naval game that gives Yamato 3 triple turrets of 18" guns is exactly the same scale as every other.
So the way I see happening in the future is a split like what happened in StarFire, where some people like the 3rd edition and some people glommed onto the 4th edition ... For me, I will probably use the old version to do ship-vs-ship kind of game and use the new version as a fleet version (i.e. instead of the Fleet Ops).
Of course, that's your prerogative. However, I've been trying to show the similarities between the new edition and SAE will far outnumber the differences. I'd hope you'll wait to see the whole package before passing judgment.
So any DMG >2 will be lost?
No, conversions up to DMG 5 will be supported. Whether that means a "Dx5" trait remains to be seen.
All I can say is that I have not completely given up on the game. Whether that means something will come out before Spring Training 2012, I don't know...
To be honest, the idea of a baseball game is so outside the norm for MJ12 that I have no idea whether anyone else out there would care one way or the other -- but I like it. 
It seems that the new edition abstracts out the ships more. That seems to be making the new edition basically a fleet edition. The ships are no longer ships in that there is a narrative of what happened on the ship. (e.g. My port phaser was knocked out allow the missiles to slam into my port-aft shield) So it is less a tactical game and more just a conflict of a set of ships.
I may be wrong, but I believe I have addressed each individual concern about "overly abstract" changes in the new edition, and demonstrated that they don't represent nearly as significant a change as some seem to fear. That being said, Starmada has never really been intended to simulate ship-vs-ship duels.
I'm aware there will be some who are disappointed in the direction being taken -- that's inevitable. All I can do is continue to develop the game that I want to play, and hope that others come along for the ride. On the other hand, I would hope people will give the benefit of the doubt; and if you don't like the new rules, dislike them for what they are, not what you fear they might be.
That would make it a bit useless to mix regular and no-hull damage weapons on the same ship then.
Not exactly... the worst you can do with the proposed "no-hull" trait is reduce a ship's capabilities by 50%. Once all of the target's hull boxes have been "hit", you can do nothing more, while your opponent is (on average) zipping around with 2/3 of his engines, defenses, and weapons.
It will be interesting to see how you pull off "no hull damage", since, from what you've shown, the only way to damage systems is to first damage the hull and force a threshold check.
My initial thought was to mark off "hits" for the purpose of triggering a threshold check -- however, "real" damage would overlap that caused by no-hull-damage weapons.
Although the S AE one is more accurate as not only you track damage for each weapon, you also track damage to engine and shield in a more precise way.
This is probably true, although I would argue the difference in outcomes between SAE and the new edition are minimal at best.
Will there be the 'no hull damage trait'?
Probably.
Will there be provision for crippling ships?
Yes.
mj12games.com/forum → Posts by mj12games
Powered by PunBB, supported by Informer Technologies, Inc.