(my apologies if I'm starting a new thread where I should have added to an existing thread; this seemed like a sufficiently distinct track of discussion)
Just finished my first beta DA game. Very stable, quite fun. Some bugs and the obvious incomplete stuff, but quite good for a beta. Thank you devs! Anyway, onto the main reason for my post:
I think I have an idea for dealing with the "engine cheese" problem. It's been mentioned before in a few forms but I thought I'd go a bit further.
Disclaimer: this may be a completely hare-brained idea (or programmatically non-feasible, or already beaten to death, etc), if so please let me know so I can move on to more productive things.
The problem, as I understand it:
- under normal (pre-engine-nerf) rules, ships could be built with 80+ speed (40+ for well-loaded warships)
- even after the engine-nerf, rather fast ships can be made (20+ for a huge hull transport at high tech levels, probably 30+ or even 40 with max miniaturization but I haven't checked that)
- due to the nature of GC2 movement and standard computer performance limitations, the AI can't intelligently deal with enemy ships moving much over 8. As a result, players who utilize the higher speeds can beat the AI like a red-headed step-process (less so with the nerfing).
- further reduction in engine speed, however it was accomplished, would make it take a LONG, LONG time to move across a gigantic galaxy. This may or may not be a true "problem", but it is worrisome to some players.
Proposal:
- add a "warpgate" starbase ability (conferred by a new line of modules) that allows an allied ship on the same square as the starbase with at least 1 movement point remaining to instantly "warp" to another allied warpgate-equipped starbase within X parsecs (where X depends on the StarbaseAbilityValue of the module or modules). This action would consume all remaining movement points for that ship.
- nerf engines like crazy so that speeds don't get above 8-10 (or whatever works out). This could be done by further engine space nerfing or by limiting ships to at most 2 engine components (which would probably require more programming).
Disadvantages/Costs:
- presumably requires changes to code, so that the parsing routine for StarbaseModules.xml could make sense of:
[StarbaseAbility]Warpgate[/StarbaseAbility]
[StarbaseAbilityValue]15[/StarbaseAbilityValue]
(replace ['s and ]'s with <'s and >'s, I couldn't get them to display due to them looking like tags)
Not to mention the probable need to add another command to the ship command window for "warp" that is only active in the above circumstances; and of course the code to implement the "warp" command (I imagine setting the x,y location of a ship isn't too bad, but I'm armchair programming here and the code to determine allowed warps would be a bit tougher).
- requires addition of a number of entries in StarbaseModules.xml and TechTree.xml, but that probably won't be anything compared to the coding.
- would either add to micromanagement of long distance travel (including new-production rally points from across the empire) or would require additional code in the auto-pilot plotting routines to take warpgates into account.
- will probably tick off people who like really fast ships and whipping the AI with inter-stellar-ballistic-missiles in the form of building a transport and "firing" a chunk of metal containing 500 billion angry marines at an enemy world in the same turn.
- could allow low-speed cheese in the form of minimal-to-no-engine ships stuffed with weapons and armor that could make it across the galaxy by gates when it would have been untenable to cross the distance on normal drives
- may not scale well to galaxy size
- would either make freighter trade routes look a bit silly ("why are they not using the gates?") or would complicate their code (I am NOT suggesting routing them through the gates).
- inevitably will add more complexity to the game. Whether that's good or bad I can't tell right now.
Advantages:
- AI wouldn't have to deal with possible-move trees much past the normal depth for an 8 move king (which is still not fun, but better than a 30 move king), since engine speeds wouldn't exceed that and any warped ship has to stay on the starbase square until the next turn (allowing processing of it's possible moves from that point on normal speeds).
- Players could still move ships across a gigantic galaxy in a few turns IF they had sufficient control of the space to keep the constructors/starbases alive and had the industry, money, and will to build the infrastructure. Players could even construct a gate-base in the middle of enemy territory and start warping in large fleets, but it would be risky to do so without having already established a degree of space superiority (and, of course, the square would have to be reached by normal engines first).
Notes:
- I would suggest that the starbase modules come from a new line of techs off the root (or near the root) of the propulsion tree. Technobabble-wise it could be explained as a revisit of stargate technology using the new insights from hyperdrive-style propulsion research.
- The numbers could obviously be tested and tuned, but right now I'm thinking of a progression like:
Warpgate I module : 15 parsecs
Warpgate II module : +10 parsecs (25 total)
Warpgate III module : +10 parsecs (35 total)
Warpgate IV module : +15 parsecs (50 total)
Warpgate V module : +20 parsecs (70 total)
So early on they could help a fair bit (while normal speed is still kicking around in the 3-6 range), but later on they could be used to cross a Gigantic galaxy in time comparable to that of the pre-nerf engines.
Alternatives:
- have the gates be planet based instead of starbase-based (improvements instead of modules). This would make the gate locations considerably more fixed, but I tend to prefer the starbase idea.
- make warpgate travel non-instant (instead moves at much faster rate determined by module level), where the ship disappears and shows up at the destination however many turns later. This seems like it would be a lot more complicated code-wise.
I could ramble on quite a bit longer, but I'll stop there and see if there's any point in my saying more.
Thanks for your time,
Keith LaMothe