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

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 :(

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.

There are also lots more new screen shots.

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.

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.

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 :)

I also have been playing with planet appearance a bit. Nothing major though. Maybe I'll put up a new image and/or video soon.

Edit: Have a sunset! Ya, pretty crummy without atmospheric scattering, but at least the water looks somewhat nice.

On that note, I have made great progress the new server. I actually have the architecture working. The scheduler now properly runs tasks that access the database. Pretty basic, but it is a solid start to build upon, and also I can start bringing in major parts of the old server now.

Basically, the x-axis of the graph would be 'range of enemy weapon', and the y-axis would be 'targeting-priority'.

So by 'range of enemy weapon', I mean the firepower of an enemy squadron, at distance 'k'. If k=700m and the weapon is long-range, then we calculate a low firepower. Thus, if "targeting-priority" when 'range of enemy weapon' = 700m has a "low targeting-priority" (low value on x,y graph), then our friendly-squadron would decide not to target this enemy squadron (regardless of actual distance between these squadrons).

If the distance 'k' equals… 999999999999m, and the total firepower of the enemy squadron is very high at this range (arbitrary 'k' value to indicate long-range), then if "targeting-priority" (y-value) at 'range of enemy weapon = 999999999999m (x-value) is high (i.e. has a "high targeting-priority" (high value on x,y graph), then this is the squadron we should target, because it has a high firepower at said range, 'k'.

This is not dependent on actual distance between ships, but on the weaponry of enemy ships in an enemy squadron. So if enemy ships all have long-range weaponry, then their total firepower will tend to be high a high range, 'k', values and low at low range, 'k', values. Thus, if we set the 'range of enemy weapon', "x" vs 'targeting-priority', "y" as a bell-curved graph (where x, y are both greater than 0) then we can allow players to use a 'slider' in the interface to customize where they want the maximum on their bell-curve, thus targeting enemy squadrons that are most-effective NEAR a distance of x = value of slider.

And this lets you pick-off those pesky long-range ships with whichever squadron you choose.

However - if there are really good short-range weapons on enemy-squadron 'A', and really terrible long-range weapons on enemy-squadron 'B', then the advantage of a graph is this:
We multiply the firepower at a given range by the y-value (targeting-priority) on the graph, to give us our actual targetting-priority. The enemy squadron that has the highest "targeting-priority" * "firepower of enemy squadron at range 'l'" is the one that is shot-at.

I have just finished getting the full internal structure and the associated user interface for the ground combat app finished. This means that I can now place facilities on a planet, and a player or players can have full or partial control of each facility. I can apply various settings configurations to the facilities for each player, and edit the list of available configurations. While none of the configurations actually do anything, and there is no actual combat going on, we are getting closer.

Now I have to add some more settings to the configurations, and then make the actual combat happen (update the facility properties periodically to reflect growth, losses, conquest, etc.)

What this means for you? Ground combat game is one step closer! Also, as far as user interface complexity goes, note that the ground combat app is a development tool that controls all players at once, and is in no way trying to simplify anything. The game itself when released will be much more friendly.

For those of you who like numbers, this is all done through 7 separate windows, 4 of which can have multiple instances of open at once (See image).

It has been a while since the last update, and not very much has been done, but much planning has been done, and progress has started in what I see to be a very good direction. Here is the work in progress ground combat simulation app (GC App). Soon it will allow the user to set up facilities on a planet and fight over them.

Though I have to this point always avoided anything time line wise, I would like to say that this should actually be done soon. That means days or weeks, not months. I got about half of the remaining work done yesterday and today.

Once this works, the new server design will be implemented, the log in system will be ported over, and the GC App will be incorporated. Then the client app will be made from the GC App and then we will have a playable MMORTS! It will only be minimal ground combat at that point, but it will be a very solid base to build upon.

It will then be extended to add more features like national boarders, treaties and triggers, resources, technologies, a real time supply demand economy, and much more. This process will produce a fun and interesting MMORTS. Most of these features are independent of each other and thus can be tackled by different developers allowing for much faster progress. I would like to see this getting underway early this summer.

In addition to the game play improvements during this phase, the graphics and user interface will be moved over to OpenGL, and the planet will go from the current slow to generate low detail to a vastly improved immersive realtime experience complete with variable climate and weather, seasons, environmental sound, and deep zooming graphics detail. I can not provide a time frame for this, though I can say that a lot of work for it has already been done but is put on hold until the gameplay is further implemented.

As the ground combat game becomes more fun, it will hopefully pick up a user base which will allow us to tune it properly and be sure it is a fun and exciting part of FG. While this (unavoidably slow) tuning and refinement process is going on, the galaxy and solar system setup will be brought in allowing players to view other planets, and settle some of them. Then the existing physics and AI systems will be brought up to date to work with the new server, and ships will be added. Initially they will only do basic things such as be moved around, travel between solar systems, and investigate and colonize planets. This will be the final state of the development of ground combat. Once this is done, epic space battles!

I can not offer a time frame for epic space battles (I will wildly guess 2.3 years, end of summer 2 years from now), but a lot of work has already been done for them: the database system is pretty well designed; the AI engine is roughly coded; the physics engine has been tested and works with module and thruster based ships and my collision detection engine has been stress tested successfully and imported into the FG code base. It is not like we are starting from scratch; it is more like reassembling and extending.

Players need to be… Like in colonies… In hives… In… Groups! I mean, if players open the map and see over 1000 solar systems, they may become immediately discouraged, because they feel that they will never be able to 'win' the game.

But if you can form small groups (vassal system), and then 3-4 of those groups can form an 'alliance', and then (here's what I'd like to see) those larger group can form an even larger group (with more co-operative options (like a Guild HQ)). Ah - sort of like Pentacore, where every blue dot represents a player: http://www.pentacore.eu/content/map/

With different levels of government, players can work towards controlling a larger portion of the galaxy by working as a group to become the leaders of other groups. It is an interesting idea which I first noted in Pentacore, and allows players the stepping-stones towards galactic domination.

and then apply the same assumptions to ship X:
4) firepower of ship X is a linear function
5) firepower of ship X is 2hp/s when t=0s
6) firepower of ship X is 0hp/s when t= (health) / (damage per second of ship A) = 20 hp / (8hp/s) = 2.5s

then we can say:
The battle will last exactly 2.5 seconds (by assumption (6), ship X has 0 firepower at t=2.5s).
damage-dealt by ship B = integral from t=0s to t=2.5s of firepower(t)dt
where firepower(t) = mt + b
and b = firepower(t=0) = 8hp/s (by assumption (2))
and firepower(t=50s) = 0 (by assumption (3))
m = ?
sub t=50s
(0) = m(50s) + 8hp/s
(-8hp/s) / (50s) = m
m = -0.16hp*s^-2 (per second squared)
sub m into firepower(t)
units in "[]" for simplification
firepower(t) = mt + b
firepower(t) = (-0.16[hp*s^-2])*t + (8[hp*s^-1])

Note: firepower = damage dealt / second
so for ship A, firepower(t) = instantaneous rate of damage

Check: At t=2.5s, ship A is destroyed i.e. damage dealt = 20hp
sub damage dealt(t=2.5s) = 20hp into equation:
damage-dealt by ship B (onto ship A) = integral from t=0s to t=2.5s of firepower(t)dt
(20hp) = integral from t=0s to t=2.5s of (-0.16[hp*s^-2]t + 8[hp/s])dt

Aside: Integral of firepower(t)dt = (1/2)(-0.16[hp*s^-2])t^2 + 8[hp/s]*t
We want the integral from t=0s to t=2.5s,
Let F(t) = Integral of firepower(t)dt
Recall: integral from t=0s to t=2.5s of firepower(t)dt = F(2.5s) - F(0s)

Substitute into equation:
20hp = (F(2.5s) - F(0s))
20hp = (-1/2[hp*s^-2*s^2] + 20[hps^-1*s]) - (0 + 0)
20hp = 19.5[hp]
LS NOT = RS

But was the assumption valid?
If LS NOT = RS, then this indicates that
while assumptions (4) to (6) (i.e. ship A deals maximum-damage to ship X for the entire battle)
give us an output of damage(t=2.5s) = 20hp;
our assumptions (1) to (3) (i.e. firepower of ship X is decreasing linearly)
gives us an output of damage(t=2.5s) = 19.5hp

In summary: Assumption (6) requires that assumption (3) is false; assumption (3) requires that assumption (6) is false. But if we do not want the server to recalculate change in firepower for ship A after every shot fired by ship X, then assumptions (3) and (6) are advantageous.

What about the damage that ship X dealt, before it was destroyed?

Damage-dealt by ship X = integral from t=0s to t=2.5s of firepower(t) FOR SHIP X.
By assumption (6), firepower(t) FOR SHIP X = mt + b
Note: This is different than firepower of ship A, as we are now looking at the damage dealt by ship X onto ship A.
b = firepower(t=0) = 2hp/s (by assumption (5))
firepower(t=2.5s) = 0hp/s (by assumption(6))
m = ?
By our method, we get:
m = -0.8hp*s^-2
Remark: It is ok to have a different m-value, because to start-with, the firepower of ship X was less than ship A's. We are just using assumptions (4) to (6) instead of (1) to (3) to calculate damage dealt by ship X onto ship A.
If firepower(t) FOR SHIP X = (-0.8[hp*s^-2])t + (2[hp*s^-1]) then
Damage dealt by ship X = integral from t=0s to t=2.5s of firepower(t) FOR SHIP X.
By our method, we get:
Damage dealt by ship X = -2.5[hp] + 5[hp] = 2.5hp

Check: ratio of damage dealt at t=2.5s ~ ratio of firepower(t=0s)?
(2.5hp) / (19.5hp) ~ (2hp/s) / (8hp/s)
0.128 ~ 0.25
Considering that firepower(t=2.5s) ~1 for ship A, but =0 for ship X, 0.128 ~ 0.25 :)

Conclusion: for t=2.5s
Damage dealt by ship A = 19.5 hp
Damage dealt by ship X = 2.5hp
19.5hp < 20 hp, therefore ship X has not been destroyed, and the battle must calculations must be redone after considering the new firepower values at t=2.5s and applying assumptions (1) to (6).

Analysis:

Question: So the above calculations need to repeated an infinite number of times before ship X is actually destroyed?

Answer: I need help determining the actual length of the battle (at what time is ship X destroyed)? We need to know when ship X reaches hp = 0, so that the client CPU can show the player and animation for the ship blowing-up (i.e. Ka-Boom) and so that firepower values never become negative.

Question: What if the battle is interrupted i.e. ship X is not engaged for a full 2.5s?

Answer: We use the above methods to calculate the damage taken at t = time of disengagement (integral from t=0s to t=time of disengagement) for each ship, update the targetting info, and use the above methods to recalculate the firepower(t) for our entire fleet.
Phenoca writes: Ships can have firepower(t) > 0 against multiple targets. Firepower of each ship is affected by on the weaponry of the attacking ship, defense of target, distance to target, and an arbitrary percent-modifier (multiplies firepower by 0.0 to 1.0). Each ship chooses from its available targets via the targetting method (a sub-method of the tactical method).

So for an entire Fleet, we actually have individual ships (or sub-groups) where the above calculations are applied. I.e. For A, B, C vs. X, Y, Z we have a calculation for firepower(t) of:

A onto X
X onto A
A onto Y
Y onto A
A onto Z
Z onto A
B onto X
X onto B
B onto Y
Y onto B
B onto Z
Z onto B
C onto X
X onto C
C onto Y
Y onto C
C onto Z
Z onto C
lol

Problem: When calculating A onto X (see above list), we assume that firepower of X onto A = 0 and that firepower Y onto A = 0, which is not true! (Firepower of both ships would not be decreasing linearly since assumptions (3) and (6) are not true in real life.)

Solution: The targetting method makes some cunning assumptions, such implementing a function, firepower(t) of Fleet (X,Y,Z) onto ship A. There would also be functions Fleet (A,B,C) onto ship X, Fleet (A,B,C) onto ship Y, and Fleet (A,B,C) onto ship Z, such that firepower(t) = (m1)t + b1 + (m2)t + b2 + (m3)t + b3
I have not considered whether or not the above targetting method is plausible. If you understand this problem, please tell me, and offer help! This is because I have never encountered a problem like this, with… A potentially infinite amount of variables involved! (If the size of either fleet is complex - hohoho :)

Feedback Requested: Can we incorporate assumptions (1) to (6) in fleet-battles, using the (as-of-yet undiscussed) "arbitrary percent-modifier" and "targetting method" to factor-in the effects of tactical-manoeuvres?

Here is a planet. The texture is made using the old and slow method. I put in some of my improved code from the planet tool project though to make it faster. Notice how terrain and lines cross the seams without getting totally screwed up. I put a lot of work into making that work right!

The planet has lines on it. They properly follow the shortest paths between endpoints, meaning great circle routes. Also there are some little marker dots. Currently they are placed where you click, and demonstrate the mouse to 3D vector to texture implementation. Eventually it will be used for placing things like facilities, national boarders, and anything else you can click on the planet.

Basic drag navigation and scroll wheel zoom has been implemented and works well.

Where is this going you may ask?
The current goal is to create a ground combat game, which by itself should be somewhat fun, though slow paced and not overly interesting. Once this is done, it will be improved until there is a real economy, somewhat nice graphics, and basic diplomatic tools (setting peace vs. war with various players). Once that is done, work will continue to improve it, but we will also return to working on space combat. The first step of the space based game will be basic colonization of other planets. Once that works, ships, fleets and real space combat will be added. Then you will have ground and space combat. That is when FG will start to be really neat.

Because we have true scale space, ships are tiny, and move really freaking fast, and take a long time to accelerate and slow down (equal for each). Thus, when two fleets meet, what happens? They simply pass near or through each other and continue on their way. What if we give them super thrusters to stop and destroy each other? Well, they will just fly by each other, but be going much faster. Also, getting ships to stay together in fleets and properly stay next to rapidly moving planets is difficult. Super awesome solution of all of these problems? Attractive field technology (force fields, tractor beams, magnetic fields, super gravity, electric fields, what ever)! Then instead of fleet passes fleet, they shred each other into bits throwing ships in all directions! What could be better!

Have a video of this effect using simulated gravitational fields (video a simulation of a galactic collision, but the ideas is similar).

What does this mean to you? It means that FG will have spiffy cool graphics that use your graphics card to its potential (considering my graphics card is crap, that means little for me…). None of this 5 seconds to generate a crummy texture. On a decent card, it will make a good texture in less than 1/20th of a second.

I'm pretty delighted with this success and I will be proceeding straight to getting my render to texture code to let me produce textures with shaders. Things are going to get cool!

2 textures mixed with 2 octaves of noise all on the GPU. 4 fps so render time of 1/4 second for 512*512 on my crappy graphics card. Now I just need something that will let me get that image in a usable way. I did manage to get rendering to textures working, but I haven't managed to get shaders running in RealBasic yet. OpenGL ftw.

I still like that system, but today I realized that if we were to use a graphics engine where we have much more control over the GPU (like OpenGL), I could implement the same system, but much faster, and better.

First of all, the reason it can not be done in a shader is that when you zoom in, there are so many possible layers. In reality, very few will ever be used at once, but the pixel shader can not take advantage of the hierarchical nature to eliminate almost all of them. Also, even the amount of layers is use will be so large, and the amount of computation per sample in each layer so larger that it simply would never be close to fast enough.

Solution: Suppose we were to have an already textured planet. Once you zoom in, you get to the point where there is no detail left from the texture. At this zoom, suppose you implemented the appropriate sub layers (trees in the forests, dunes in the deserts) in shaders. They would add in the detail!

Now, you zoom in further, and its time for the shader's sub layers. We use the GPU to convert the current shaders into textures which we draw on top of the old lower detail ones, and generate new shaders for the sub layers (branches on the trees or what ever).

This allows per pixel detail at all zoom levels, and keeps the speed up. There is simply 1 shader drawing a few layers over 1 texture. That should be fast! Getting the GPU to generate the textures that will be combined will be somewhat hard, but apparently it's possible. Also, it would allow high quality effects like per layer bump mapping with proper lighting!

The slightly easier version is so skip the detail shaders and just use generated textures (generate them to higher detail). This would probably be done first, and detail shaders would be added if needed.

Also, the mesh height data could be generated on the GPU as height map textures which would speed stuff up a lot in that department. (Yep, that means fast detailed mesh with fast detailed textures with good lighting!)

What this means to you: If we go forward with this, it will mean some delays in the short run, but planets will look much better, and so will everything else (because of a better graphics engine)

I should note that I have never done anything like this, so it's all very speculative.

Basic design:

Progress wise, Tristan has made an excellent in game help viewer. His setup is far nicer than the one I hacked together in both function and appearance.
I have been looking into how the server should work. Currently we have a relational database system crudely mashed together with sqlite databases in the server app. I understand databases much better now, and I have looked at a real relational database system, I think I might know how it would let us simply the server a huge amount, while easily letting us use an virtual cluster of servers to handle larger loads. It would also let a good php developer implement some controls and stats on the web site, which would be nice.

I have also spend a bit of time playing with different development tools, and messing with open GL shaders (GLSL). That might come in useful when we redo the graphics to use something better.

The current main hold up is my stall on the planet tool. I just don't feel like ripping it apart and fixing my organizational mistake, and that is really the only reasonable option, so we just have to wait until I feel like making a large pile of shredded internals, and then fixing it. Maybe when I have more time.

At least at this point, taking some time to think about the project has helped, so the delay has been useful.

First of all, it crashes ever 2 minutes. Apparently relates to the music checkbox. I stopped using it and had it playing in the background by some music program, no biggy.

But from the video I saw, the Mac version has more options, and makes more… sense.

Is this what I'm supposed to see?

Also, resizing the window messes up the chat and view colonies buttons.

Anyway, all I (barely) manage to do is move the camera and start colonies. They don't appear in the show colonies button. I have no idea how to make a ship. Also I have to look at one planet from really really close just to have a chance to right-click it and start a colony. It's almost always a single pixel.

Basically, I doubt you worked on the Windows version seriously.

Now if only all those options did stuff! It is certainly not done, but it is beyond a simple GUI mock up (the undo menu for example does work, and so does redo). The image displayed is generated (in less than a second) by the functions and layers listed, but you can't really edit them to a reasonable extent yet.

Thanks for reading. Come back when we have some real news. There will be interesting news in not too long. Maybe in a few weeks, maybe less.

For now, some random thoughts to keep interest in the project:
It would be possible to have layers in the planet data that reflect mood thus effecting the music.
We can have binary (and more) star systems with planets in both types or orbits (around the stars and around the barycenter (center of mass of the stars)). The current orbit system can handle this just fine, but some changes elsewhere would be needed. Don't go looking for a 2 star 2 moon eclipse screen shot tho, its very unlikely!
The economy will have shipping prices, tariffs, embargoes and such. Thus all the resources will have varied prices in different locations.
Weather and seasons on a planet can effect combat stats, resource production, and other things. For example, food could get expensive during drought or harsh winters, mining can become expensive in wet seasons, population growth can slow or even reverse when conditions suck. Very small forces can have a bonus vs. Large armies in the dark (night or arctic circle in the winter, maybe even when its really cloudy) for stealth reasons.
The hierarchical AI will allow ships to act on their own and in group effectively at the same time, as well as group of groups etc. The level of individualism for ships and groups for various factors will be player set along with priorities for ships and groups.
The blind growing tech tree will allow open the possibility of discovering a never before seen technology. Once discovered, it could be kept secret, but using it in the presence of others makes them more likely to discover it.
Using technologies a lot can increase their bonuses to things that use them.
Player will be able to set up extensive treaties, as well as actions triggered by their violations and other triggers.
With the cost of controlling planets increasing with the size of your nation, the quality of planets will be more important than their quantity. The higher quality planets will reside closer to the center of the galaxy usually. Thus, a player can ether engage in heavy PVP there, or spend more time exploring the rest of the galaxy to find valuable resource rich planets.

Hey there. I'm very interested in your project. I am a writer/designer
and have written for one semi sci-fi themed MMO and a full sci-fi MMO.
One of which I still have my writings saved.

I program little to none, but seeing as your are using REALbasic it
doesn't look to different than BLITZbasic that I have piddled with.
Again I have tinkered in 3ds max but nothing really came of it, but I
know the basic interface and functions.

About a month ago I started designing my own game that is very similar
to this and would like to merge some ideas or if anything just put them
out there. My version was most likely going to be done in BLITZ with a
2D gui that had no combat; I was trying to go for a EVE online feel with
nothing but heavy economy and strategy.

Anyway before I start to ramble I would love to be considered for joining.
-Billy

As you probably know, running a server takes money. As you also probably know, we have spent a lot of time on FG and will continue to do so. Because of this, eventually Fragmented Galaxy will need to generate some income. I posting this here on the public forums, because the players are greatly effected by how payments work. We are fully open to suggestions at this point.

I do have some ideas for how it could work.

I think it is important to not charge people until we have a game that is stable enough that it will not lose their data, and will be available most of the time. Once this point is reached, I think it is a good time to start accepting donations, but not nagging or anything.

Once the game is pretty much fully featured and onto a fast server, it will be time to evaluate a payment scheme. If donations have not reached the volume we want, something new will be needed. I personally think it is valuable to let people play for free. It greatly boots the user base for one thing. The question is then: what would be different for paying customers? Restricting non paying players in some way makes the game unfair, and adding some non game play effecting difference would also not be good as it singles out non paying players, and often offers too little incentive to pay.

Thus I propose a multi server system. We offer a free server tuned to allow very few ships (3-8 or so), and control over very few planets. We might even adjust some other things to keep the CPU and band width lower such as lowering update rates and such. Basically tho, it would be a full version of the game, but scaled to load the servers less, and limit players sooner. It would also probably have a more limited non growing tech tree so new players just joining the check out the game could catch up pretty quick. We would then offer a pro paid server that allows nations to grow much larger and more powerful. It will be tuned for long term play, and have a much higher server load per player because of the higher colonized planet and ship counts. Paying players could play of the pro server, as well as the free one. We could also offer a server resembling the free one tuning wise, but only for paying players. Probably the free server would get by far the most players, and cost the most to host, but the other servers could pay for it, and when the system gets overloaded, or the server costs get too high, we can do stuff to the free server like adjust the tuning and update rates, without feeling like we are preventing people from getting their money's worth. The free server (or a clone of it) would also make a very good high load testing/beta server.

Please post your thoughts on the subject here, so we can make sure our players are as happy as possible when the time to collect money comes (not gonna be soon).

(Developers, as far as what we do with the money, see the Dev forum. I'll make a post there soon.)

Se you in a while!

The HUD is also going well. I finished up the frame management that handles all the objects. Now I need to install Tristan's editor, and get scripting working. That's about it really, tho getting scripting fully functional will be lots of work. Once the HUD is up and running, we will have to add features like the edit field Matt has been working on, scroll bars, data handling tools and lots of other stuff. It is going to be a long and hard process, but it is well defined and certainly within our abilities.

Soon we will be fixing up the content in the game play section as well.

On another note, we finally came up with and agreed upon a ground combat system. Basically it will allow you to put your nations borders where ever you want, and various settings will determine of there is war or peace where theirs overlap. Scattered across the planet, created by players, are facilities, which extract resources and hold your population. In war zones, the facilities are contested and control can slowly be transferred.

Enjoy!

-Tristan

Matt has been carefully breaking up the project into a series of Ages which will be released as we add features, as well as documenting the features they will have. This basically provides a development plan.

I have been working on the Planet Tool which will allow anyone to design and algorithms for procedurally generated planets. These designs will then be exported, and used in game, though the planet tool could have lots of other uses (like making high resolution movies of planets evolving over time, generating premade planets with varying LODs for other games, landscape texture generation etc.)

Currently the planet tool is just a GUI that does not really do anything, but I have finished coding the multiple undo/redo engine, and am working on the data export/import setup. The planet app is going to use an improved sampling system, with hierarchical layers which should allow many more layers without hurting speed too much. This means things will look good at high zooms. Scattered trees can be placed on forest edges for example. Another neat is past sampling. Because the planet is 4D (changes over time) you can simply sample the past and use it in the functions. This means you could have a HabitatForest layer which you sample at different times to get the forest age. This allows neat things like environmental latency around events (Vegetation takes time to recover and adapt). When combined with impacts, droughts, fires, ice ages, etc it could be really neat, but that level of complexity might be too slow for real time in game stuff (but still fun in the planet tool!). Also of note are planet condition properties such as season, solar input, mass etc. which can be used to effect planets so their content matches the planet's placement and properties in game.

That's all for now!

Here is a shot of our HUD in full screen with the Main Menu up. As you can see, the menu is clearly not done, but at least it works! The window background is also slightly transparent so you can see a star shining through. The buttons now have up and down graphics, so they look pushed in when you click them.

Here is a small section of an in progress render. Currently the rendering process is very slow because it does everything at the maximum resolution everywhere, and uses a crummy slow 4D noise function. I finally got the layer management system organized enough to easily add rainfall and temperature layers to help keep the forests and deserts separate. Also, I have plans to do clever things like skip spending most of the time deciding to not render vegetation foe every under water pixel, and to vary the sample rates depending on the rate of change and visibility. This should boost speed by several times, and make all the edges sharper. With the current system, low sample rate (really fast) renders look great except for the edges, so this change should help a lot. I also touched up the texture positioning and scaling system so they should tile correctly when sections of the texture are rendered separately at arbitrary sizes. Also, it supports textures of arbitrary resolution and size, so the tile edges don't need to line up which hides the tiled artifacts pretty well.

Edit: Updated image!

I have successfully sampled the surface of a sphere travailing along the 4th dimension through a smoothed noise field. It is currently very slow, and has a few tiny flaws, but it will be improved. Maybe I will make a 4D optimization on the N dimensional noise field.

My texture mixing code works too, so things will be getting interesting.

Details about the meaning of this will follow, but for now, just know that we are working on stuff.

Tristan has made a great collection of graphics which we will be using. It is all going very well.

Erm.
So there is this game I loved to play called "Fanta Scape". It was a Tactical RTS, and I loved it!
Only glitch was that you had to check the monster-positions when the (randomly-generated) map loads, so that you don't accidentally have "impossible" scenarios with monsters on islands (because characters can't swim :).
Anyways, so this game is cool, and you control units.

Now Square Enix clones this, and releases Final Fantasy VII for the DS!
A complete clone, with graphical, storyline, AI, element-types, and item-equipping additions.
But still a complete clone!

Oh yeah, and I was saying this because I think both games suck because there is no community in either of them (not multiplayer :).
However, I absolutely love the gameplay! It is unimaginable (if you haven't already played)!
Yet without community, I won't play.
I like players, not AI.
Hmm, though I think I'll test the Final Fantasy VII AI this afternoon. Some games have really friendly NPCs :)

Edit: The AI is really good :(

I also have been trying to squeeze the zooming bugs out of the 3D view, but they seem to prefer spreading and moving to coming out. Some stuff fixed, more stuff broken. That's how it goes…

Instead of calling it default view say galaxy view.

The music is good but when it gets to the end it should be scraped slightly and used as a battle theme tune.

Where it says your player name next to it should be Number of colonies.

Other suggestions include using planet-icons, and colony-ships :)
We also need a guide for how to make a colony.

Thanks timjag :)

Now that we have a bug list, it is time to fix them. I have patched most of those bugs I think, but some have been harder than others, and many are still left. The planet viewing bug has been particularly annoying. I have known for quite some time that my rendering system was only hacked to get star viewing to work, and it was no done right. In that system, there was no way to get planet viewing to work. To fix this, I just restructured the whole rendering system. Planet viewing now works, but I'm sure I broke many other things. Eventually I will patch up these bugs, and it should work again. When thats done, I will move on to making the planets look nicer, and forcing the background stars to render right (they currently get clipped for being too far away) when zoomed in.

I also got user names to no longer be case sensitive, and at least some non ASCII characters work in them now, but they somehow get converted into other characters when sent to the server. Some more work is needed to fix that.