Introduction;


I spend much of my time working with analyzing or creating simulations and games to represent life and personal interactions. Using this background I’ve developed some ideas and suggestions, some of which have been adopted, while others were shot down or postponed. That’s expected, and for the best in some cases. However, in my attempts to suggest them as individual ideas, I think I have failed to create a coherent image of what my underlying concerns/thoughts are, and how these or other changes would address them. While many of the thoughts and arguments I intend to present here have already appeared, I hope to flesh them out more thoroughly and demonstrate some of the assumptions which I suspect I have not have expressed as well as I thought. (I’ve found I have a habit of doing that, I'm not holding my breath that this will make my ideas/methods clear- or that I've remembered everything.)
I am going to start with a short summary of the point. Realizing that what I imagined to be a short post has turned into a term paper way longer than I expect anyone here to read, I feel the summary should be placed at the beginning.
The (very) short version of what I arrive at over what is actually several pages to follow;

I want (and, from comments made, others including Mr Programmer God want) mid sized ships. For mid sized ships to be viable they need to be effective without making large ships or small ships strictly unplayable or super-powerful. This necessitates a series of exchanges without quantifiable “right answers.” We currently have very clear “right” and “wrong” answers.



I have a growing concern that there is an optimal design scheme. While this scheme is obscured by the options in shipbuilding, including component placement, I think it does exist at a basic level. The driver behind this belief is the appearance that some component choices are better and more effective based on fundamental rules, not personal style. While this seems like a natural order of things it creates a narrowing of *effective* (successful) choices in game play, while obscuring that with alternate choices that (new) players will become discouraged by trying. I intend to delve into my analysis of the various components shortly and demonstrate that they currently have a clear hierarchy of utility.

This entire analysis is, obviously, completely based on my own observations. As such it is subject and open to disagreement. I welcome whatever observations and conclusions others have arrived at, though my experience is that simply asking for them yields little response while presenting my ideas leads to being disagreed with.


My suspicion of an optimal design scheme is arrived at by asking the pertinent questions to building a craft; “should I add another component?” and “what should that component be?”

The method of answering the first question (whether or not to add an additional component) has just been changed by the institution of ship classes. However, there is some examination I would like to do, and through this I have arrived at some interesting conclusions.
With the previous rules, prior to the addition of ship classes, the answer to this question was fairly obvious. In adding a component one looses potential maximum speed and additional credits, while one gains a component which provides increased ability of whatever sort and increased survivability. First, I find that “potential” speed is the proverbial “two in the bush.” Only when some actual item or ability, such as actual maximum speed, is sacrificed (as happens when one lacks sufficient Engines) does this become a point in the balance. This sort of failure to apply appears in several places where something is considered balanced *if*, though I believe this maximum speed exchange is the only place where situations arise where the “if” may not ever be possible (cannot ever reach max speed of 20, cannot reach max speed of 19 and perform actions). The issue with the differential between actual and potential speed is not constrained to smaller ships, though they stand to gain the greatest benefit. While the smallest ships can never gain their full promised potential mid-sized ships do so only by sacrificing the ability to be effective in other ways. It is only at the largest categories (Maulers of whatever size), where there is little appeal to having more engines than powered components, that a ship can meet their promised maximum speed (or exceed it with spindizzies) AND act effectively. Thus, at no point did a ship actually loose anything by adding an additional component- only the largest (with the least valuable movement) can naturally meet their maximum speed without sacrificing capability elsewhere. Only when every ship can meet its maximum speed does this become something which is sacrificed, and then only at the levels where natural movement is significant strength. Alternately, some other point of sacrifice must be provided to make a choice actually exist between large and small ships. Ship classes are clearly a move in the direction of “alternate sacrifices,” however the benefits are questionable in the most basic damage suffered to damage dealt calculations. As I have little or no basis for a significant analysis, however, further discussion of ship classes must be postponed until after further play.
As we have not yet discussed the tools necessary to provide any answers to the first design question I will return to it.

The second question (what component to add) requires a thorough analysis of the components which can be added to a ship. At the moment we have three types of ships; Merchants, Colony/ark, and Combat (aka; Everything Else). We will set aside merchants and colony ships, as the focus of the game is combat and each presents special changes to the requirement of a ship that violate the general wisdom of a warship.
The components, as we all know, are Habitat, Engines, Drone Racks, Mass Scoops, Hold, Super Structure, Spindizzies, Swarm Generators, and Factories. As I want to perform some calculations determining the value of adding one component or another I’ll need to assign “weights” or “values” to the utility of the components.

At least one Habitat is required for every ship. The first habitat is required for the ship to survive, so we will assume this habitat is the base line for utility of a component of the ship, assigning it a value of 1 (100%, but I’m going to try and stick to a simple scale). <<One might suggest that the Habitat is worth the entire value of the ship, because without it the ship would be lost- however the value of the ship is a result of the functions each component perform in battle in allowing more damage out or preventing damage in. Thus, each component will carry their own value which, for simplicity, will not accrue to the habitat.>> The second Habitat I might add to the ship has 0 value under normal operating conditions. However, in the course of a fight the primary habitat may be destroyed which significantly increases the utility of that second habitat. However, the dead habitat is now an obstruction and the additional habitat will never provide more utility than its original would have. Ergo, I will assume the second habitat has an average value of half the original’s (.5). It could be argued that the second habitat is worth twice the amount as the original, as it provides twice the survivability. However the limitations (*IF*) on that utility restrict it to not exceeding the utility of the original. This is because the benefit assumes the original has ceased functioning- an eventuality which can be limited by placement or protection of the habitat, and other non-component-inherent aspects of shipbuilding. Further, the fact that a dead habitat literally provides no more benefit than any other dead component limits (blocks) the benefit of subsequent habitats. Thus I’ll say that each additional habitat then has an amount of utility approximately equal to 1 divided by the number of habitat already added. The potential for a habitat to be useful can never quite reach 0, though (thus the utility of habitats is 1, .5, .33, .25, .2, .16, .14, .12, .11, and each additional is .1).

At least one Engine is required for every ship. To perform at full capacity one engine is recommended for nearly every component except Habitat, Hold, and SS (and, obviously, other Engines). Thus, the utility for each Engine is 1, so long as the number of powered components plus engines required for maximum movement is at least equal to the number of Engines. If the number of Engines exceeds this amount, however, the utility drops rapidly to 0 (it has no actual use)- though redundancy prevents it from ever reaching 0. (I will assume a minimum, and average, of .1 for ease.) It is probable that fractions of movement would provide similarly reduced utility (ie; if an additional engine would provide less than the full amount the other engines on the ship provide such as a 10 system ship moving 18 hexes on 5 Engines)- though this is more intricate than I want to get right now. Similarly, the inability to reclaim Engines might adversely effect the utility- however that delves into component placement which is way beyond this discussion.

While Drone Racks are not +technically+ required, a ship without them has little point. While the new scouting rules may serve to weaken that statement the Beholders Racks produce in turn make those scouting rules potentially redundant- thus I feel confidant ignoring passive scan in determining the utility of this component. Because of Drone Rack’s fundamental place in the game they may as well be a required component (utility 1 for the first). Each additional drone rack component provides greater abilities to the drone, albeit in a pattern that consistently erodes as one aspect is increased. However, and this is personal observation from experiments with a 35 drone rack ship, there is consistently somewhere to put “extra” points that has potential value until there are enough “unnecessary” points in those to shift them to an already high trait where you actually prefer the points. (Potentially valuable traits often include movement, burn, and armor- which may have more value than expected depending on surprises in defense and speed, as opposed to power which is almost always equally valuable).
In short, while a specific shot may not have an optimal use of a full complement of drone racks, more drone racks is always better than less at a nearly constant rate and with barely notable exceptions. This makes drone racks our first constant-value component, and one with a consistently high value. I will refer to such components, real or proposed, as gold-standard for this reason.

Mass Scoops, much like Drone Racks, are not +technically+ required. However, a drone rack without at least one of these will become useless. Ergo, the first Mass Scoop has a utility of 1. Each Scoop requires an additional Engine and Hold to have any value. However, much as we are not weighing the utility of a component against the cost of having that component (yet), we will not weigh the cost of additional required components against the component. What we must consider is that additional Scoop components may or may not provide a useful resource during a given turn. It is difficult to specifically determine how valuable a given scoop might be, we can determine some extremes and outline some general guides to how the utility moves otherwise. Any mass scoops in excess of the number of holds cannot produce value thus dropping to the minimum utility (they can still take damage and provide redundancy). Similarly any mass scoops in excess of the engines set aside to run them provide no utility and drop to the minimum value. The number of useful Scoops is also reduced by the amount of redundancy present in holds and the likelihood of each point of mass being used. On the other hand, the maximum possible use of mass in a turn increases the value of each scoop. For general purpose we will assume that additional scoops not covered by specific rules have value equal to the maximum Mass that can be used in a turn divided by the number of holds the ship possesses. This is based on the assumptions that that higher numbers of holds indicate less concern for fill rate, while a player will tend to want to do as much as the ship is capable in a turn. While ships will not normally run at their maximum consumption on every turn I simply can’t generate a constant at random to apply to the divisor, so we will treat this component to an artificially high utility calculation. While this formula includes several questionable assumptions, and potentially provides values greater than 1, I do not intend to rely too much on these mid range results.

Again, Holds are not required to create a ship. However, like the Mass Scoop, the first is fundamental to Drone Rack function. Further, one Hold is fundamental to each additional Mass Scoop, thus we can assume the first has a value of 1 as does an additional one per Mass Scoop present. Similarly, the existence of a Factory almost certainly indicates intent to repair or expand the ship, providing a 1 value for each of the first 5 Holds. Because additional Factories may be redundant this cannot continue to be assumed, though the first additional Factory probably provides high utility for additional Holds. Applying further values to additional holds provides the same difficulties initially faced trying to normalize Scoops- the choice between storage and immediate use. Again, an equation that should give a general shape to utility which falls outside the specific rules, but shouldn’t be relied upon too heavily, might be maximum Mass that can be used in a turn divided by number of holds, indicating that the more available functions which can be performed in a turn the less important additional storage becomes. Yes, I just gave Scoops and Holds the same general formula as, at base, the same considerations apply. This time there is a constant which should be applied to the dividend to represent desirable redundancy in storage.

Super Structure is the first legitimately and completely non-requisite component. They have no function undamaged. Under attack or dead they provide some service. A single component of SS potentially absorbs 2x the damage of any other system and they provide access to control regardless of functionality. Because the best service a SS can provide is to be damaged in place of 2 utility 1 components its highest utility might be 2. However, because it does not guarantee the maximum effect of its sacrifice I will reduce this utility to 1, and because it does not guarantee its sacrifice at all I must halve that utility (to .5). I cannot increase the value due to its ability to conduct control while dead because it is so dependant on the variables of component placement and damage placement. Thus, SS has a consistent value, but one which, at best, is not inspiring. Note that this is a maximum Utility value.

Spindizzies are effectively useless to any ship with an actual maximum speed of 12 or more. While they can be used to perform the movement available at reduced energy cost their inconsistent availability puts the use of pairs or more for this purpose outside reliability. Below a speed of 12 they begin to accrue utility as the speed decreases. As spindizzy use is a highly personal and variable decision the best I can do is a calculation which considers their average provided speed (6 hexes every other turn) against the ship’s normal speed. Thus their value should be 3 divided by the max natural (engine) speed and the previous number of spindizzies. This formula is nowhere near reliable but should give a general shape. I do not intend to examine spindizzies too closely except to note their increased utility to larger ships.

Swarm Generators, the first of the maintenance components, are “preventative.” This does not allow them to prevent damage to a component, however- only the spread of already damaging nano. In my experience strikes tend to occur as either single point strikes (either small attacks or multiple warheads) which cannot be effected by Swarm or large attacks which grind through a large number of components before a small amount of nano can have significant effect. This suggests a bell shaped utility curve- from low utility for the first nano (useful for dealing with only a very few small strikes), to high utility for the strikes where power is large enough that one experiences several small but multiple power strikes or one large strike, back to low as you leave the high end of most probable powers for a strike. This increasing utility is a strange turnabout from most components, and indicates a natural point of choice- that the utility of an later Swarm component might have sufficient utility to pay off the early shortfall. The supposition that goes into the utility of Swarm (*if* the ship isn’t fast enough to escape being hit, *if* it is targeted, *if* the warhead is large enough Swarm helps, *if* swarm isn’t what’s taken out) and the large-block judgment make it easy to want to simply omit swarm from the discussion. However, instead I will simply assign swarm an average value of .75, suggesting that they each component is an equally strong choice. This is one of the strongest values in this schema, though less than any required component. I feel this is stronger than the component warrants.

Factories. One factory and 5 holds provide free money. An additional factory and 5 holds provide a stunning self-regeneration rate if not disrupted, and additional redundancy. The first factory is easily worth 1 utility, providing the ability to grow, change, or repair. The second unit provides a possible doubling to this rate, assuming that the energy/holds/etc are available, and each additional component provides equal amounts of benefit- if provided with the necessary materials. Thus, we will give each additional factory a value of {(holds / 5) - current factories} with the always popular alternate minimum value (.1).



Looking at the previous discussion the actual basic requirements for an active ship are Habitat, Engine, Drone Rack, Mass scoop, Hold. Obviously we will never have a move 20 ship as, even ignoring the considerations made for drone racks (the ability to take any actions) and using the increased hexes per engine of 4, three engines plus a habitat grant only a 12 move. Interestingly, this suggests that the utility for spindizzies on small ships will be higher than expected because they might be used to compensate for engines unavailable for movement due to powering components.

This returns us to the first design question, which we may now have tools to answer. To restate an underlying point from my first discussion of this question; an additional component should be added if the utility that can be obtained is greater than the utility given up. The sacrifice in this case is credits and maximum speed. Credits are, at this point, only used to purchase ship components, and ship components can alternately be created with factories. Thus the utility of credits is negligible. As already discussed, maximum speed is a valueless unless it translates into an actual loss in reachable speed. However, because maximum speed does, eventually, translate into a loss in actual speed we must determine the utility of that speed. For the moment let’s assume that the average value of a hex of movement is 1. As an average, I think this is high. I think the actual calculation for utility of a given level of speed should be something like {max speed * .1}, which means the average utility would be almost exactly 1 if every speed were equally available. This calculation is estimated from the ability of a given hex of movement to be useful under varying circumstances including maneuvering through gravity, escaping drones, reaching jump out distance, and compensating for movement lost to damage. <<For reference, the max speed I can fire attack drones at (using my 35 drone rack ship) is 22. That gives me “only” 2 points to play with for power, burn, etc (not including the point in each that cannot be changed). The max speed I have consistently fired attack drones, my general (mauler class) ships, is 16.>> However, the actual maximum speed possible in the game is achieved with 5 engines and a habitat, leaving only two components as other options and no power with which to engage them. This is at the end of the ship-size spectrum where natural speed has the highest value (not least because it is greater than easily achieved drone speeds). However, even the change due to ship classes leaves the max possible at 19, if one is willing to sacrifice other activities, and makes speeds of greater than 15-16 improbable even while leaving other included components unpowered.
While both scan and visibility based on size should also be accounted, I have too little information to comfortably perform a fully informed estimate of how to account for the utility there. I am confidant, however, that treating the average utility of natural speed as 1 at least compensates for that.

Moving forward, while the more useful of two options must be taken, any time two options have equal utility the player is faced with a choice of which option to pursue. We want to increase the number of places where the values are equal as each is, theoretically, an equally optimal choice. However, the path which leads to the optimal design scheme is finding which choice gives the greatest total value.

Having established this framework it will take some interesting mathematics to optimize the choices. As I have generally done I can point to some points that seem obvious to me. The first thing that must be underlined is that the ability to add drone racks will always be equal to the loss of an additional hex of movement, so the addition of anything beyond that is icing on the cake. As we have already recognized the drive to the super large ship this can be ignored for now. This is also the reason I would like to see the maximum speed be more determinate of the actual achievable speed of ships- to increase the average utility of speed. However, the utility of adding drone racks will almost always outweigh nearly any other option for additional components. This is another piece of the reason I referred to Drone Racks as the gold standard component.

Cutting into the lower end of the spectrum pushes the whole ship size upward because by negating the speed advantage of the smallest ships and reducing the speeds of the mid range ships until there is little to no reason not to simply build larger ships that rely on Spindizzies to perform similarly occasional movement at speeds which even mid-range ships cannot manage (I have had a mauler engage 8 spindizzies and 14 drone racks in a single turn).

Downgrading Drone Racks seems like the easy way through the puzzle. The problem is that this leads to deficit in a calculation I have not considered here (and would have a hard time outlining due to the variables involved); fun. Generally, my observation indicates that weaker drone racks means less action/ability, and thus less fun.

Making individual components more powerful seems to intuitively make larger ships more appealing. However, by raising the speed with which component utility spikes (the points where you can fire your first shot, you can make a shot count- for example) you alleviate the need for more components to generate the same utility (reduce the size of the average ship).

Strengthening small end potentially creates a “slippery slope” effect at each end- more utility will be derived from following the strengths (sacrificing components for speed v sacrificing speed for components). This is where the alternate advantages come in- acting as terracing (sudden drops in “movement” utility if these thresholds are passed). However, the current situation does not eliminate this slope. It simply makes it one-sided towards the large end, making the effort of “terracing” more difficult (larger drops in utility are required to generate the desired effect).

I understand your point about the power spike earlier, but I'm not willing to touch it really.

I guess my current view is that we have been play testing the current ruleset for sometime - and as you mention mauler classes were winning. Also merchanters were a bit fidly.

This has caused ripcurrents and ship classes to be added, and I think that this will cause variety of scenario - which could not exist before. i.e. through necessity you will field smaller ships into battle.

My guess is that you want ships that can:
Stock up prior battle, and have this pay off
Be far better at repair if they are useless at attack
Be better at mine laying and mine detection if they specialise
act as low fire rate, high payload torpedo boats
Be massively armoured but as a result hardly move and maybe have no scan
Be big but unable to move where you want them,unlike smaller ships.

Etc - ie every specialist ship class in any film/game you can imagine.
I like many of these ideas, and have got a few of the principles into the design. The most likely future addition from the list above is manouvreability (maybe).

I think this discussion is fine, and some of the ideas you spin off could be fab, but I really am focused on quality for a while....

GameAdmin wrote:

I understand your point about the power spike earlier, but I'm not willing to touch it really. I guess my current view is that we have been play testing the current ruleset for sometime - and as you mention mauler classes were winning. Also merchanters were a bit fidly.

I agree that the current ruleset needs playtested (no pun intended). like the title says, this is the underlaying logic to my argument- which individuals may have gotten through my cluttered previous presentation, but I've presented enough arguments that didn't seem to be taken the way I intended that I figured it was worth the shot at one big whole.

GameAdmin wrote:

This has caused ripcurrents and ship classes to be added, and I think that this will cause variety of scenario - which could not exist before. i.e. through necessity you will field smaller ships into battle.

I see the classes as "terracing," I don't know if they will provide the ratchet down the size scale you want.
on the other hand, I don't think that the RipCurrent rules will encourage smaller ship sizes. I think the optimal choice will be greater consolidation- higher per-system colonization.

GameAdmin wrote:

My guess is that you want ships that can: Stock up prior battle, and have this pay off Be far better at repair if they are useless at attack Be better at mine laying and mine detection if they specialise act as low fire rate, high payload torpedo boats Be massively armoured but as a result hardly move and maybe have no scan Be big but unable to move where you want them,unlike smaller ships. Etc - ie every specialist ship class in any film/game you can imagine. I like many of these ideas, and have got a few of the principles into the design. The most likely future addition from the list above is manouvreability (maybe).

I can't say I don't want that (I got the feeling its a desired design point, and it's definitely one I like)- but specialization is not my point here, or at all usually (unless I either think of something spiffy and likely to be postponed or that the long-term specialization point helps justify something useful for purposes right now).

I figure that specialization falls on the schedual somewhere around the "new drones" (ie; 6 moths min, more like 1 yr +).


I really am focused on the basic exchange of fire combat ships right now- ship utility as measured by attack drone effects (with some concessions to other drones, like beholders, because they have a direct impact on damage experienced and ability to repair without suffering more). Some suggestions would help specialists, but it's got less to do with wanting specialization and more to do with wanting to make design choices (more difficult) equitable. What I want is;

Quote:

The Baigrandian scout entered the system and spotted a GorsKagdan Mauler over the outermost planet. Warned of the entry of another race the Mauler suddenly became afraid of the dark and began filling the are around itself with Beholders to negate the tiny ship's passive scan advantage. The system moves in slow time as Baigrandian fighters vector into it, quickly reaching a system count equal to the lone Mauler- however as they close the strength gap with the GorsKagdan it's fleet finds enough space in the system for several cruisers to slide into the system. In the next system-tide the Baigrandian fighters move 20 hexes towards the large GorsKagdan ships. Seeing that even with their rate of closure the distant fighters will be beyond range of the Cruisers the Mauler alone fires on one of the fighters as the Cruisers continue to clutter space to deny the small fighters the cover of darkness. In the next tide the cruisers determine that, while the fighters are currently beyond range, their own speed will bring them into range before the drone's burn expires and they switch from beholders to attack drones as the fighters continue to close. The third tide since the Mauler's initial attack reveals that the ship it targeted attempted to pull away to save itself, but the drone had enough targeting to make the 45 degree adjustment needed and enough speed to make the diagonal and slams into the tiny ship. Unable to jump from the position to which it doged the vessel will disintegrate within moments. Other ships, seeing they have been targeted attempt to perform evasions- some will succeed, suffering only from having been seperated from the formation, while others will suffer the same fate as the spearhead. However the Biagrandians are among the GorsKagdans. In the next turn dozens of tiny attack drones splatter the Gors who return fire with an array of strategies aimed at the fleeing Biagrandians- some are targeted by single fast drones that quickly find their targets others by multiple drones one of which finds them because they dodged into it. More ships simply find they have tails with moderate speed and long burn- their choices limited to those performed while constantly running and dodging and additional Gors attacks aided by that consideration. Those that have, so far, not been targeted return for another pass while those carrying tails circle to come back with their tails away from their target. Many simply burn and die.

<<apparently it's easier for me to write up imagined battles than real ones- I've got a couple encounters with Maps that deserve some prose that I just haven't been able to find.>>

GameAdmin wrote:

I think this discussion is fine, and some of the ideas you spin off could be fab, but I really am focused on quality for a while....

I'm not sure what you mean by "quality."
If you mean bug fixes, I understand. I assume that bugs always come before suggestions (unless as a programmer you just get tired of them for a while).
If you mean core gameplay that's what I'm after too. as I said, a primary source of my utility determination is damage suffered v damage inflicted. As a wargame that is the core gameplay. As much as I talk and argue about the logistics (which are necessarry for a +good+ long term game) the firing and coping with attack drones is what I've been given to understand as the central mechanic to this game from which all other considerations ultimately flow.


Otherwise I've got nothing, as a beta tester I'm here to (have fun) report bugs and make suggestions about gameplay.

By quality I did mean bugs.

I think the things missing from the game that are in your prose are:
- Evasion (see seperate threads)
- tiny vessels having the slightest hope against larger vessels.

The scan stuff is pretty much as you descibe (for obvious reasons ).

Reinforcing and fleet dynamics will NOT be as you describe. Simply because given the choice of jumping in a huge monster or a tiny ship I will always field the monster.

One idea I did have a while back is to increase the merchanter idea. i.e. you need to jump in with smaller ships before the other ship can enter the system. Kind of like a simple pyramid.

eg 2 ships of size 40 or less before 1 ship of size 55. And 1 ship of size 55 before a ship of 65 etc.

HOWEVER, I discarded it as un-fun.

GameAdmin wrote:

By quality I did mean bugs.

hey, I always assume bugs come 3 or 4 priority levels above anything I have to say. If it's not working as intended what's the point of messing with the intention. (unless the errant workings are actually more fun!)

GameAdmin wrote:

I think the things missing from the game that are in your prose are: - Evasion (see seperate threads) - tiny vessels having the slightest hope against larger vessels. The scan stuff is pretty much as you descibe (for obvious reasons ).

A) the evasion I discribed actually IS in play- I described the intended function of the current targeting mechanic. I think all that mechanic needs is a tweeking the base percentages up and then the rate of compensation (without upping the percentages dodging almost never succeeds- significantly upping the percentages means dodging will rarely fail even with expendature in Tracking... The problem is finding a balance where dodging works but can be overcome). I'm actually coming to a place where I don't think evasion is a good idea- because the base speed is increasing. I think the tracking issue needs fixed, and the small ship speeds need that additional increase, but I think Evasion would just be too much.

B) the tiny vessels having the slightest hope (en mass) is a function of some shifts that would make smaller vessels more workable. The discription is actually taken from one of the attack methods Mapmakers used- though he did it with significantly larger ships. This is actually one of the two points of the original article, and the one most heavily persued; the ability of large numbers of small ships to be equal to small numbers of large ships (the other point being that 2 ships of equal size should have roughly equal usefulness- ignoring differences in how the compontents are placed).

GameAdmin wrote:

Reinforcing and fleet dynamics will NOT be as you describe. Simply because given the choice of jumping in a huge monster or a tiny ship I will always field the monster.

Reinforcing is as described (well, as intented)- the limit is overmatching, and the choice was not one monster or one tiny ship, it was several tiny ships v one monster, then many more against several monsters.
The other point there is, in my experience, a well organized ship of size X will (currently) usually loose to a well organized ship of size X+1 (strong organization allowing random factors to be *mostly* ignored, and even the weakest utility options being higher value than the utilty lost by making the ship +1 size). This is somewhat hidden as combat usually occurrs between multiple ships, but helps explain why few will build significantly smaller (even to the lower limit currently allowed). If X can inclued tiny ships then the size of the X+1 becomes small-mid range.

blah. As I'm looking over what I'm writing, I want to make sure that I don't make it look like I think a 4 component ship should be equally useful with a 76 component ship. I think that a 76 component ship should be more useful to the exact degree of what is given up; credits, theoretically- though as I said before this means little until we get other means of credit expendature online. I simply think that the gap in utility between a 76 component ship and a 50 component ship, the larger gulf between the 50 component ship and the 16 component ship, or the infinite difference between the 16 component ship and the =>9 component ship are currently larger than credits can account for.

GameAdmin wrote:

One idea I did have a while back is to increase the merchanter idea. i.e. you need to jump in with smaller ships before the other ship can enter the system. Kind of like a simple pyramid. eg 2 ships of size 40 or less before 1 ship of size 55. And 1 ship of size 55 before a ship of 65 etc. HOWEVER, I discarded it as un-fun.

I actually think that merchanters of varying sizes are completely covered by the exchange of speed v storage. (I also agree that this would ultimately be un-fun)
The only tweek I've got left for merchanters (barring wierdness that accrues from future changes) is a suggestion I've made before and has less to do with varying size than certain options being of questionable usefulness (I still don't get why I'd buy superstructure for stealable merchanters).

since I've posted this here, I'm going to post my notes for consideration/revision;
* Number of Swarm Gen and Factories with significant value should probably be limited by the amount of mass available. This creates one upper bound of number of useful components for each. It considers usage requirements for these components for determining their value.

* The absolute requirement of the first Engine and Habitat probably make a more accurate value "infinite." This also throws into question the derived values of additional Engines and Habitat- I believe the other values effectively remain the same or nearly so, though this must be supported or rejected.