I have been working on everything, and making pretty good all around progress. I'm looking to have a solid cross platform release of the planet viewer with login and maybe chat built in done by the end of the year. The server is far enough for this, but needs to be a bit more stable. The client can already login, so its mainly a matter of getting the user interface done, and getting a release put together. Once thats done, I'll work toward getting ground combat designed and implemented.

Here is a Large Screen Shot

In-FTL battles would not exist though, I agree. There would be no way to detect incoming ships and no way to attack them either.

@Craig
I disagree Craig. I think that sub-light speeds will be too slow for intra-system travel. A three tier system must exist: Sublight, FTL, and a relay or teleportation system for inter-system travel.

We are not going to. Ships can only go FTL outside/between solar systems, and there they can not do anything else.

intra-system travel is only FTL. Other stuff is strictly non FTL, thus no ships ever interact when they are going FTL, nor interact with ships going FTL. Problem solved. There is an assumption that interstellar space is huge and empty, and that no ships can interact there. Also, detecting FTL ships in a useful manner is impossible because they go faster than you can see them even if you could see such small things at those ranges. You might as well wait for them to arrive before you see look.

The assumption that you can not use FTL within a system is a gameplay decision we made a log time ago (with the possible exception of constructed special areas of jump gates). We could change this, but I don't think we should. If you want quasi physics excuses to justify this limitation, I can provide several.

@Phenoca
FTL and sub-light interactions depend heavily on the type of FTL that is used. For example an Alcubierre drive warps space to apparently move faster than light. No matter can survive the transition between the bubble and the outside universe. Not to mention that detecting a ship at FTL may be impossible.

These are all decisions that we will need to make.

And also - how are we going to do FTL-battles

We are not going to. Ships can only go FTL outside/between solar systems, and there they can not do anything else.

And also - how are we going to do FTL-battles versus orbital battles? Does one fleet suck the other fleet up into a spacetime rupture? Does the battle take-place inside of a wormhole, or a blackhole, or do we just pretend they instantly slow-down to equal velocities, or do we do something unique like warping local spacetime into a torus? Could we pick a non-orientable surface? Would it matter?

Imagine you are wearing a shirt, and fleet A is travelling down your left arm; fleet B is travelling down your right arm. If you hold your sleeves together, then fleet A cross onto the other sleeve to intercept fleet B, and move up your right arm. But such curvature of spacetime is impossible.

Another possibility would be portals, or warpgates.

And… I've removed the rest of my post because I just kept coming-up with the above idea, with wormholes being made by creating a large mass between both fleets which will curve spacetime enough to create a wormhole. I also found out that making a wormhole through time breaks the laws of physics… And if we "shrink" a 3D wormhole, then we get a 2D playing-field. If we shrink a 4D wormhole (with time not a dimension) then we might get a 3D playing-field until the wormhole collapses (your shirt sleeves are no longer connected). And the velocity of fleet B inside of the wormhole will start as (velocity outside of wormhole minus v-components in direction of velocity of fleet A outside the wormhole) all with respect to fleet A.

So if fleet A creates a 4D wormhole, I propose that the battle takes place in 3D space with fleet A's start velocity equal to 0, and fleet B's start speed is equal to (velocity of fleet B outside of wormhole)*sinθ, where θ is the angle between fleet A and fleet B's velocity, and fleet B is travelling away from fleet A.

http://www.youtube.com/watch?v=rDu2A3WzQpo

But under private testing for now :(

For the banner, fill it with opaque black (from side to side) then put the current image on that.

SHould I clarify?

I don't like our banner or the menu on the left going over it. It is too beautiful to be hidden!

I also read Prematurely Disappointed and CTRL+ALT+DEL.

I need to download it right now!

Sorry I've been gone. School is harder this year.
Good news though: I now have Windows 7.

As a newcomer here, you have a special and useful skill: the ability to have useful first impressions. If there is anything confusing about the site or game info here, please ask. We need to make a intro/FAQ page to cover such things. We already got one thing, the issues regarding site membership, but I'm sure there are other things.

hi, how do you register to this site?

Technically, you don't. You have a wikidot account which is all you need. Site membership is restricted to those who have permission to edit the site content. It's somewhat strange and a bit confusing I know, but it does work. I may try to rationalize it a bit in the future to explicitly allow site members and moderators separately.

oh, and welcome to the site. Thanks for stopping by, and enjoy the pretty pictures. New release estimated in 1-2 months to play with.

Eventually I will set up an image gallery system that is much more functional with ratings, comments, tags, various sorting options, and better support for viewing and downloading very large images. When this is done (it's a low priority compared to making the game work) I'll offer up some more nice high quality renderings from the client.

I will try it out when I get back to the computer I d/l'ed the client, just to check it out. My game is at a very boring point as well, so I like looking around. I like the concept that you have, and your storyline is intriguing.

Thanks for the update, and I will look forward to the new client.

There are also lots more new screen shots.

For now, you can try and use the account "Craig5" and password "12345" which I just created and tested.

From the server logs, it seems you did actually create 2 accounts, but login was failing because of the password. I would not be surprised if is not your fault at all though, as the server or client could have botched it. Both are quite buggy.

Once the new client is released (I'm guessing a few months from now), I will be far more interested in any issues found.

Anyway, thanks for trying it out and reporting your issues.

Thanks!

Edit: I also got chat working, though again, the new client has no GUI for it.

I'm going to fix up a few things, then see if I can actually install the new server software on the server and get it all running. I leave it up to check stability and processor load, and get the new client to talk to it.

With the client socket working in python, that would mean that the new client mainly needs a basic GUI, and not much else to get it usable with accounts and such.

Once it has accounts, and database access, the server side of the ground combat UI (applying players' actions) should be very easy.

Getting the (not yet finished) ground combat algorithm into the new database system will be an interesting project. I can't really say how long that will take, but once that, and the client ground combat GUI are done (another project of unknown difficulty), there will be a game to play, and it will be fully on the new client and server.

Along with the new client, I designed a new server architecture, which I think will work much better. I have finished the basic architecture, and done some basic testing of it. Everything seems to work well, though there are some features missing as far as automatic crash recovery and distributed processing across multiple servers (basic multi-core support should already work, and the database server can be on another machine), but I think everything else major is solid.

Along with the basic architecture changes, I have now implicated a new networking protocol. It has basic error detection, and should be a solid base for the networking. There are a few details that are currently in need of optimization for high loads, but I will get that fixed soon. I still need to implement it on the client side in python too. (Edit After some testing, for small messages, my code is more than twice as fast as RealBasic's built in alternative, and about 11% faster for much larger messages. I also got it about half implemented on the python side)

Also, I should note that several developers other than me have been active recently working on various design and documentation tasks, as well as the ground combat system which will be ported to the new server, client and networking once finished.

I think that is it for now. No pretty new pretty pictures. I need to rig up a PHP script so I can easily update a gallery of new screen shots for all you (not very numerous) fans :)

On another note, the new FG Game server software got another critical piece finished today (start to finish it took about 15 minuets to make though). I just finished basic testing of our process manager, which currently does nothing but launch a few things. Eventually it will have also the job of detecting crashed and frozen parts of the server software, and trying to kill and relaunch them. For now it will launch the task manager, and any other things that need to get started, like the client communication servers which I will make shortly.

I could worry about it. Which utility are you referring to?

First, you will need to actually get the client to run. I can help you with that. Then you need to figure out how to make a redistributable package out of it. PackPanda is built into Panda3D, but only supports Windows and Linux. I don't currently have a linux or windows rig that can run the game, and can't make mac packages.

Btw, you have dev permissions: if you have good enough hardware, and you want to go to the effort, you could run it now.

Thanks :)
I'll ask on AIM if I can't run it.

I'm just not going to worry about that now (any one want to worry about that for me?)

I could worry about it. Which utility are you referring to?

Hum, ship type ratios could be derived from the formations, so it could actually come down as little as design formations for your fleets, and ship designs to fill them. Then specify ratios for how big your fleets should be relative to each other, and then specify ratios for how much spending should go to different areas. That really comes out very simple conceptually. You could even just have one big spending pool, and allocate percentages to specific fleets and colonies and such. Very interesting.

Completely centralized budget based system. Such a setup would allow aspects of the game to be completely separate. So the aspects of the game would then roughly be:

• Budgeting
• Space combat
  • Design
    • Ships
    • Formations/Fleets (Including AI)
  • Commanding fleets
• Diplomacy
• Ground/Colonies
  • Economy
  • Ground combat

Well, thats an idea for another thread/topic.

Anyway, do you feel that a soft cap based on maintenance costs and the available budget for supporting ships would work well and solve the issue you raised? I don't see a need to cap the number of fleets. Having many cheap fleets is probably a bad strategy, as is having one massive one. Strategically, I can't invasion a reason to need more than 3 or 4 fleets ever for a given assault (1 would normally be enough given the customizability of sub formations).

As far as auto replenishing, the main issue is where the ships go when finished. I see a few options: Stream over to the destination fleets as produced, or queue into new fleets/sub formations what will ether merge with the damaged fleet or form separate fleets that can be used as replacements. Specifically what is done in any given case can be player configured. (Oh, another element of strategy!)

Sound good?

I'm really glad to have someone around actually thinking about making gameplay fun. We need that.

Perhaps the attack/defense fleet size could be limited by your population.
Or by the planets you control (too many ships in orbit means that planetary fuel runs-out)?
And the most complicated possibility would be planets supplying fuel to other planets, thus increasing the maximum attack/defense fleet size.

But basically, the premise is that I feel:
1) In an RTS, players want to relax. They do not want to deal with fleet-loss.
2) If fleets are easily replaced, then the stress is lowered.
3) If the fleet size is capped, this adds more strategy to fleet-formation and ship-design.
4) Capping the maximum number of fleets being sent out on attack will also limit the time that the player spends in-game, so that they do not get bored of the game, yet instead have to login consistently in order to be there when their attack fleets return home.
5) Attack fleets can raid… So changing your formation gives you an increased chance to 'evade' defenders and pick-up loot.
6) Since the game is based-upon resource production with respect to time (instead of large stockpiles), the 'raiding' system will have to be carefully designed.
7) If your attack fleet or defense fleet is destroyed - no problemo! It is automatically replaced (when the enemy leaves), until you run out of ships. E.g. A raiding fleet can attempt to evade defenders, or else form a "blockade" that can only be broken when the player comes online or the attack fleet departs (and the defense fleet is automatically replenished).

I apologize for not being able to find the name of the game. Fleet-size caps are uncommon in browser-based games, yet caps on number of raid-fleets is common.

You present some interesting ideas here. I don't actually see anything here at all that conflicts with my proposed formation system, you just present a different way to think about it, and a possible method for how node placement could be done. You just try to solve all the aspects which I have not yet addressed. Well done and thanks!

The key distinction I wish to present is that my design does not actually require a ship at every level. When a sub formation is attached to a node, there does not have to be a ship to follow there, but rather they can gather around a point in space defined by the higher level formation. This is most important at the top level. Instead of a flag ship, you have a formation with no governing formation (it is not a sub formation). I'll call such special formations fleets. The fleet is controlled by the player just like how the player would control the flag ship in your design (you could even put a ship in the center of the formation and call it a flag ship). As I have mentioned before, each level of formation has AI. The player (commander in chief) commands the fleet AI (representing a General). The fleet AI (The General) can be configured to follow/chase enemies, or not.

The concept of breaking formation has been discussed, and would work pretty much exactly as you described. Reentering (or initially entering) formation has not been discussed much, and could work as you described.

Flying in front is simply done by placing some nodes in front of others. As my system requires no leader ship, and no following (simply maintaining relative positions to nodes), it is a non-issue. This also solves the issue of what happens when ships die. No ship is positioned or commanded by other ships, only by formations. Thus when ships die, you fleet have a fleet to command, and it remembers all its settings and structure. Thus, you can start filling it right back up and it should swap ships around to where they are needed.

As far as constructing the whole fleet by assigning things to follow each other, it makes me think. Suppose each formation is given a center which is what you place it by, and a few nodes, that are placed relative to the center (like following behind, evenly spread, flanking, in front, whatever). Then you simply stick sub formation on the nodes recursively, and control by the top level formation's center. There, a fleet! This relies on large amounts of sub formations, but I think that is a good thing as it make it more adaptive as smarter (as far as AI goes).

The disadvantages you list regarding speed and turning are real hard issues. They are partly resolved by ship or sub formation AI that is falling behind or out of formation requesting that the formation wait (and the parent formation will evaluate all the wait requests it gets, apply a player specified scaler weight, and decide to wait or not based on the resulting value and the other priorities such as attacking or retreating)

Your concept of how such roles/tactics would relate to priorities is very solid, however you have mixed in some things that are not really priorities, more of abilities. They are some very interesting abilities though! I think it deserves to get split into two lists, abilities, and priorities for how to use various abilities. There can be multiple ways to use abilities, and priories are not tied to specific abilities, but some work well together: (Ex, ability: area effect shield reduction, priority: change into swarms to priority targets with high shields).

As far as your specific tactics, I think they will be better defined once you strip out the abilities and have just priorities. I think including those tactics as defaults would be good, though we should clearly allow people to edit them and make their own.

I should also note something; I think that ships can figure out their own priorities pretty well, so there should be some control, a weighting, for various AI configurations (tactics) for how much the ship uses the tactic values vs. the ones computed from its own abilities. Another approach, which is simpler to use is to allow the user set values as weights (above or below 1 to encourage or discourage) and simply multiply them by the ships computed values. I think this is the best approach as it allows ships to still respond to changing situations and be as strongly influenced by the configurations as the player wants. Thus generic simply puts all the priority weights at 1.

Well, thanks for the post. It really helped me get a good hold on how the AI will work, and how the player will control it. Now I want to apply this in one more way for you. One priority (or weight from the players view) would be "break formation - aggressive". A ship will be continuously computing a value for this (and other associated priorities that it can cooperate with), and be comparing it to the stay in formation priority. If the break formation value (after being multiplied by the player set weight) exceeds stay in formation, the ship will decide to break formation.

Now lets apply it to a (sub) formation. Suppose you have a small attack formation (maybe a few fighters, and a fast CC ship). You can give this formation the same AI, and it may decide to break from its larger containing formation, and attack. To aid in the proper application of such strategies, there is yet another way to apply AI. Each formation is made of nodes that hold ship or sun formations, and you can apply wights to the nodes. Thus, you can encourage specific parts of a formation (say the front lines) to break formation and attack by setting greater than 1 "break formation - aggressive" weights on those nodes. Furthermore, you can put low weights for breaking formation on the ships in the sub formation so that the sub formation will stick together if it breaks from the larger formation.

Potentially, you can put a sub formation within a sub formation within a sub formation ad infinitum, and it works the same at each level, which is the same as the ship level, and the same as the node level. All of it comes down to applying a bunch of priority weights. I hope that makes sense. Sometimes recursive constructs are hard to present in an easy to understand way.

A ship has 100% firepower when it is undamaged.

A ship has 0% firepower when it is destroyed.

What if percent firepower equalled percent hull-strength?

Ah, this topic. I helped someone do equations for a different space based combat stratagy game (iPhone turn based strategy to be specific). We though it through a lot and basically came to your idea there, with a slight change. If firepower does down to truly 0, a close fight goes on for ever. Firepower should decay to slightly more than 0 (ex, Firepower=portion of hull-strength*.9 + 0.1). Thats a basic approach. We were planning to allow module damage, and thus weapons could be damaged, but if that is not done, or until it is done, a simple equation like this will suffice.

Assumption: Targetting is done with the assumption that damage-per-second equals the power at a certain distance. Short-range weapons have highest power at distance zero, and the power quickly falls-off to an asymptote at power=0. Long-range ships still have high power at further distances, and some weapons deal the most damage (i.e. their power peaks) at long distance. This means that we assume that projectiles do not 'travel'. Dodging ammunition is a statistical modifier, and can be shown in the client-side GUI. But for damage-calculations, the assumption is that ammunition takes no time to 'travel' towards enemy ships. Any exceptions (e.g. missiles and mines) will have to be treated as friendly ships with zero range. The ship-design app should include the power vs. distance graph for each weaponry component.

I don't see any issues with that. Seems pretty well put too. Why don't you paste that on one of the design doc pages somewhere?
Well, one note: Missiles with guns on them are friendly ships, but with non-zero range :) (usually you will put a defensive module on a missile, but, guns can shoot anti missile missiles right?).

I'll respond to the second half of your post separately.

There are clouds and huge ice caps. No storm clouds per say though. I gotta get weather and climate modeling done first. Then we can have rain storms with lightning, and lots of other fancy things. Ha, those pictures are so out of date. That sun set has no fancy red glow, the land is all low rez mesh. Lame. I should put up a new pic:

There is a while pile of screen shots in my servers FG screen shot folder

Anyway, probably the next thing appearance wise is proper 3D clouds (thats going to be fun!) with shadows on the ground (cuz we are cool like that). Eventually I want to do automatic exposure adjustments, but that is actually kinda hard.

Currently it requires shader model 3 (directX 9 level stuff) for it's fancy mesh solution (fancy meaning it works ok and was easy to do).

Btw, you have dev permissions: if you have good enough hardware, and you want to go to the effort, you could run it now.

I believe that players should be able to 'connect' two occupied nodes, by having the ship in one node following the ship in one or more other nodes. This would keep ships in formation, regardless of varying ship-properties (different engines). In fact, I feel that building fleets should feel like building with pieces of Lego. Connect two ships (in 3D) so that they will follow each other (keeping their distance which was set in the formations applet, unless agressiveness-settings cause new the orders in the movement-AI). Then these two ships can both be connected to a flagship. Both ships now follow the flagship (at a specified distance, unless aggressiveness-settings change their orders).

Yet the benefit of following a flagship is that its highest priority will be to follow enemy targets, while the two ships behind it play 'follow the leader'. The formations template would thus set the AI to follow the flagship, which may have better armor, and can be given more customized targeting-priorities.

Right now we are defining a flagship as any ship that has no connections ordering it to follow a friendly ship. The friendly ships are following the flagship.

All ships (including the flagship) have their own targeting-priorities, and the priority to follow all friendly ships that are connected to them. The desired effected of this is to have the player feel like he/she is building with Lego; yet during a batle, the pieces scatter or reform, depending on the aggressiveness-settings. However, I would also like to have an 'attraction' scalar for each 'connection' between ships, so that as one ship follows another ship (or keep maintain their distance), the 'attraction' of these connections is set by the player. Ideally, the ships would move as though they were tied with elastic-bands, and the 'attraction' would be a player-determined spring constant, determining the acceleration of ships towards to their desired positions (or 'nodes'). Unfortunately, we decided (while making the engine) that ships can only accelerate forwards, so the way our spring constant works is the same as a real-life spring, except that ships treat "Tension" as "priority" for the movement-AI. The ship will turn and accelerate towards a connection whenever the "Tension" on the connection becomes too high (from being too far or too close). Thus, players design formations by connecting ships with springs - as many connections as the want, and the springs will have an affect on the movement-AI of either one ship or both ships.

Note: This could cause some unwanted oscillation in ship-distances.

Aside: Since pieces of Lego has a shape… You determine how ships are connected, relative to the rest of the fleet. If two ships are following a flagship, then they can maintain a 180 degree angle about the flagship, or one can follow closely while the other follows far-behind. One issue with this setup would be having tanks fly 'in front' of other ships. The only way to have a tanking-category ship fly in front of the leading ship would be to have the leading ship and the tank both following a weak ship with the same movement-AI and maneouverability of the leading ship, with the tank following closely, and the 'leading ship' following either the tank or weak ship. Then, once the weak ship (in front) is destroyed, [i]the formation still continues to operate as though the weak ship were still alive[/i]. Thus the AI continues to function, regardless of whether certain groups or ships are destroyed.
The benefit - a dynamic combat-system, with intuitive links to
the ship hangar applet and the ship 'categories'.
Disadvangtage: If ships in your fleet all have different maximum-acceleration, or are too closely-spaced, then… They hit each other. If the leading ship starts slowing-down, or even tries turning-around, then the entire formation can temporarily be disrupted, and even collapse, due to physics - note that when you hit a basketball off of a wall, it sometimes starts spinning when the wall changes its direction? Well - when a fleet changes direction, if it only has one leading ship, then it may start to 'spin' :( But I would find this fun to experiment with, because you can always add more leading ships, and space out your ships, or change the aggressiveness, or - I almost forgot - have more than one group/squadron in your fleet :)

A ship has 0% firepower when it is destroyed.

What if percent firepower equalled percent hull-strength?

Some car-racing games use this to necessitate Pit-Stops, but in Fragmented Galaxy, I feel that a linear firepower vs. hull-strength relationship would make the combat-AI much simpler :)

Assumption: Targetting is done with the assumption that damage-per-second equals the power at a certain distance. Short-range weapons have highest power at distance zero, and the power quickly falls-off to an asymptote at power=0. Long-range ships still have high power at further distances, and some weapons deal the most damage (i.e. their power peaks) at long distance. This means that we assume that projectiles do not 'travel'. Dodging ammunition is a statistical modifier, and can be shown in the client-side GUI. But for damage-calculations, the assumption is that ammunition takes no time to 'travel' towards enemy ships. Any exceptions (e.g. missiles and mines) will have to be treated as friendly ships with zero range. The ship-design app should include the power vs. distance graph for each weaponry component.

A DPS ship with the AI set to "hit highest firepower enemies" (should this be considered a tactic?) would hit the enemy with the highest power at a player-determined distance (see Targeting Modifier). However, a more advanced tactic would be to hit the enemy ship that will lose the most firepower while taking damage. To do this, we assume that enemy firepower is directly proportional to (current ship hull / total ship hull). Then we look at all available targets. The targetting-AI would compare:
- friendly weapon-power at current distance between ships (how much damage can be dealt)
- hull-strength of enemy
- firepower of enemy (weighted to a player-specified range, e.g. range 0)
- class of enemy ships (weighted by players to give priority to certain targets)
- priorities of enemy ships (need advanced technology to determine this)
The above determines which ship is fired-upon. However, the movement-orders for your ship also take into-account pathfinding - how easy it is to intercept the enemy - and do not look at your power at the current distance.

Problem: Without any anti-shields weaponry, the DPS category can be countered with a low-hull-strength + high-firepower ship that also has strong shields. This ship would optimally be used in the "tanking" category, and could be beaten with crowd-control (to disrupt formation, or hit clustered ships), or some anti-shields weaponry.

Categories are basically for the movement & targetting AI. A category is like a way to categorize different sets of priorities for the AI. When customizing your AI, you can choose both a category and a tactic for your ship. The action must fall into the ship-category, so I have made a list of a possible method of categorizing all tactics into five categories:

"DPS" and "Tanking" categories are acknowledged by everyone. Yet instead of the other categories being 'long-range' and 'short-range', I would like to use 'CC', 'Kiting', and 'Support'.

Generic (all ships do this regardless of their category)
- hit highest firepower enemies (weighted at a specific range of enemy weaponry (see Targeting Modifier) such as hitting the enemy ship that has highest power at point blank range)
- hit for the highest damage (your ship will aim at targets that are within range)
- maintain formation
- do special actions/tactics listed below (may affect formation)

DPS (Damage-Per-Second)
- chase or fire-upon highest firepower enemies
- chase or fire-upon highest firepower with weakest hull
- chase or fire-upon highest firepower with weakest shields
- chase lowest firepower with strongest hull
- fire-upon strongest shields
- chase or fire-upon enemy ships of a specific category (e.g. category: Support, or ignore category: Tanking)
- chase or fire-upon ships with specific components (e.g. troop-transport)
- fire-upon fastest enemy with weakest hull
- chase fastest enemy is almost destroyed (has taken the most damage)
- fire-upon retreating ships that are escaping from battle (Aside: in other cases, by "retreat" I mean "distance yourself from your target", but in this case I mean "attempt to escape the battle". What are the conditions for retreating with your entire fleet? If two high-velocity fleets meet, then the battle could end quickly, because it is unrealistic to have the ships stop.)
- orbit any of the above
- strafe any of the above
- fly to intercept any of the above
- this is a list of what comes to mind; this list should be made more concise if it is used by players to plan ship-tactics, or many of the actions should be until players can unlock them (by gaining experience in battle)

Tanking (absorbing damage)
- take damage for friendly ships (see line-of-sight)
- aggro enemy ships (i.e. convince enemy's AI fire-upon this ship)
- weak hull but strong shields configuration (weak hull aggros enemy)
- intercept enemy weapons with own hull (pseudo-code: disables enemy weapons yet takes damage from this; add animations into client)
- retreat to (specific ship) when hull integrity falls below X%
- attempt to ram (this would require good animation and pathfinding)

CC (Crowd-Control)
- intercept nearby weapons (see line-of-sight)
- AoE (Area-of-Effect) damage (vs. clustered enemy formations)
- AoE (Area-of-Effect) proximity-disruptor (temporarily disables engines and/or shields)
- disrupt enemy formation (magnetism?)
- disrupt enemy movement (tow-cables?)
- attach two enemy ships (with tow-cables?)
- slow enemy ships
- increase inertia of enemy ship
- destroy or lay minefield

Kiting/Pulling (using distance to your advantage)
- lure enemies away from (select a friendly ship)
- dodge projectiles
- deflect beam-weapons
- disable engines of non-shielded ships
- interfere with components (e.g. get in line-of-sight or repair ships, or counterract category: Crowd-Control actions (cutting tow cables, destroying magnetic/electronic/vibrational disruptors, close artificial gravity-wells, etc.)
- slow down movement of enemy category: Tanking
- retreat when shields take damage
- follow repair-ship when hull takes damage
- follow (select a friendly ship) when X% of friendly fleet is destroyed
- retreat when distance to target is less than X
- misinformation: temporarily disable a friendly shield
- misinformation: temporarily decrease firepower of friendly category: DPS (shouldn't do this when it is in range)
- misinformation: temporarily disable a friendly engine (recall: "fire upon fastest")
- misinformation: disguise category of a friendly ship (as another category)
- follow closest (select an enemy category) when X% of friendly fleet is destroyed
- fly with a non-functional (and half-price) component, such as an expensive component (that the enemy will target)

Support (anything that does not fit into the above categories)
- carry troops/civilians
- carry artifacts
- repair damaged components
- repair friendly hulls
- repair friendly shields
- cool-down overheated ships (if this is implemented)
- supply ammunition (if this is implemented)
- disable enemy misinformation (heh heh heh - "Sir, the ship we are chasing has its engines disabled; should we call-off the attack?" RE: "No, keep firing. It has just disabled its engines so that we'd forget it was retreating to its repair ships."
- recognize enemy kiting actions
- recognize repetition (if a friendly ship never catches-up to the ship that it is chasing) and give different orders
- salvage wreckages (if this is implemented)
- temporarily increase acceleration of friendly ships (magnetic attraction)
- retrieve escape-pods (probably good for morale, and if Captain-Exp. is implemented)
- increase planetary morale-boost from battle (news-reporters and famous people)

Tow-cable: The stuff Luke Skywalker's and Wedge Antilles use in Battle for Hoth!

Line-of-sight: I do not know how this will work, so instead of having a "line-of-sight" for weaponry, the tanks heal friendly ships while sacrificing their own hull, and crowd-control will statistically-lower the damage taken from one direction. This means that while CC ships appear to intercept weaponry, they are actually statistically augmenting the shields of friendly ships, whenever a projectile hits a side of the friendly-ship that is facing the CC-ship.

By the way - can we have a ship design that looks like a real-life space-station, with engines stuck-on? It would look so funny to see one of those fake centrifugal-gravity stations (like with the rotating ring?) with turrets firing out the sides :P

By the way - can turrets shoot through their own ship..? I have never considered… Line-of-sight :(
We need to find-out how turrets aim. One option is placing all turrets on the top of the ship, and then spinning the ship whenever its weaponry-components switch targets. Do turrets target different ships, or do they all fire at the same target? Does each ship have only one kind of weaponry-component? Having one weapon per ship would simplify the AI, but if there were multiple weapons per ship, then the only way I see the "Line-of-sight" working, is if every ship could move its turrets like a rubix-cube… And then we could call the game "Borg Wars" :P

Aside: Non-shielded ships carrying fossil-fuels or explosives/ammunition should be… In risk of receiving Critical Hits.

Assumption: The AI determines all in-battle orders, and the above actions are only "programmed" by the player, by having player-set priorities for each ship. The online player can have an advantage by ordering a retreat, and then optimizing his formation before re-engaging the enemy fleet.

So, all of the above is to make the interface look as cool as we want (the ship-animations can have complex maneouvres) while the actual battle is all statistical. Have you ever heard of those games were you click "Fight", and the computer says, "You take 2 Damage. You deal 2 Damage. You take 2 Damage. You deal 2 Damage. You Win."? Well - the Fragmented Galaxy server is basically doing this, so the processing is simplified, and the formation templates are simplified (category: DPS being simplest), but the actual ships in the game will be flying circles around each other with the weapon-animations being add-ons (the server treats travel-time for missiles the same way as it treats lasers - which means we have to work a lot on the missile-animations, but any display 'bugs' will not affect the outcome of the battle).

That is everything. Thank you for viewing my ideas on ship-combat. The above ideas are what have been scaring me from development, as well as being among my top interests in FG. I am a fan of stellar sci-fi combat, and FG is a means of realizing cool stellar combat. I would like to see some of the above ideas accepted, even if my concepts of inter-fleet combat need rethinking.

Thanks for encouraging me to get back into the development, Craig :) I felt I had to get all of the formations-ideas up-front if I was going to understand that Ship-Formations doc :P
To accept new ideas, I have to clear a space in my head for it. My head now has some empty space, which was needed :)