Thats a 14*14 grid formation, each node containing a single ship. It is placed inside a parent formation which contains it and a single other ship just behind the front grid. Basic thrust control AI is working so the ships 'try' to stay in formation by both attempting to fly toward their designated formation positions (shown in blue) as well as thrusting to match the velocity of their formation position. With a significant mass and limited thrusting power, there is a limit to what accelerations the ships can follow. Pictured here are the ships after the formation has exceeded their maximum acceleration by stopping and turning rapidly, just before all the ships regain formation.

As the battle simulator can run fine in slower than real time (this fleet of 197 ships did manage to run in real time though), it is possible to simulate and render battles of essentially unlimited scale. It might take a long time, but it could model (and render to a video) a battle of hundreds of formations and thousands of ships. I ran a little test with 40000 ships and it seemed to work (But it ran really slow as expected). 250000 ships works, but is really slow. One million ships did not work (Out of memory error)

I've been doing quite a bit on both the editor and battle simulator recently. With a bit more progress on the editor, and some more AI, we will be starting to have a real game.

Discuss here.

Fragmented Galaxy has been an extraordinarily poorly focused and organized project. I know this, and it is mostly my fault. Also, I don't really mind. For me it has always been an impulse based project. I felt doing ground combat first would allow us to quickly get a functional game out. Without ground combat, there would be no resources, and thus no economy, ships, or game. Well, I went and made planets for a while instead.

Anyway, the plan for ground combat, which will be the source of all resources and ship production, really hasn't been designed to a point where I feel I can implement it. The designs just seem to gain complexity, and I'm unsure of how big of portion of the game screwing with ground combat stuff should be. Originally the plan was to make is super simple, but the idea of significance between different parts of planets was introduced, and things got messy. On that front the project has basically stalled.

Now, on a different topic: Why do I work on this project? The concept for Fragmented Galaxy (aside from the unrefined ground combat ideas) seems very elegant from my perspective as a programmer. It has a very simple yet powerful and realistic economic system, very powerful political system based on some simple building blocks, a rather different and clever technology/research approach, an truly clever and powerful AI setup integrated with the fleet design which mirrors the ship design system. All of these are built on simple principles that are combine either through a hierarchical structure, networking or both. From the programming perspective Fragmented Galaxy is in some cases a worst case game (massively server side, computational expensive, realtime), but those are issues related to computational load. As far as basic implementation and design, Fragmented Galaxy is just a collection of fundamentally beautiful algorithms. This is why I'm still here, 3 years into the project.

And, as to why the project always gets sidetracked: I'm just here to play with clever algorithms. When I started generating planets, I ventured into the realm of procedural terrain generation, high end rendering, graphics card programming, and now the Python programming language. Any of these areas could happily consume years of my life, and I expect them to do so. As far as Fragmented Galaxy goes though, none of these are really very important to the game.

And that leads me back to a new idea. I'm going to want to get to play with those clever AI, ship and fleet design ideas sometime, and ground combat just isn't seeming very interesting at the moment. Thus, I came up with the idea of making a fleet battle game. Basically you would be given a fixed budget to make a fleet, and battle another fleet made with that budget (or potentially a different budget as a handicap). This could start without fleets, just with single ships, and fleets could be added later. Saving fleet/ship designs (including AI settings) out to files for sharing would allow a single player campaign (which could serve as a tutorial) of preset opponent fleets and corresponding budgets (you could score based on budget used, or losses taken, or both, or simply win/lose). We could allow players to battle their own fleets, battle over the network (Lan) or online, and we could host official tournaments (submit your fleet, battles run server side)

This would be a pure strategy and design game with no realtime aspects. Simply make your fleet (or select one you already made), and press go. Potentially realtime or turn based modes could be added where you could send in backup waves or something like that.

This entire system could be kept intact, but imported into Fragmented Galaxy to allow you to use your same fleets in the MMORTS. The only issue I see is with techs; not all nations in Fragmented Galaxy will have the same techs, and none will have the exact same development status on the techs. It is only an issue with integrating the fleet battling game with FG, and thus I'm not going to worry about it now.

Anyway, I now have an idea that will let me play with the AI, ship and fleet stuff, and make an interesting game that does not have serious hosting issues. It might happen sometime.

Again, it is just a planet viewer, with just one planet.

Basic testing shows that it does run on Mac, Windows and Linux, though there are some rather ugly graphical bugs in some cases, possibly on all Windows and Linux computers.

It is just a planet viewer, with just one planet, but it does actually connect to the server and do a few other things you don't see.

Ground Combat

- Losing colonists —> research points
- Declaring war —> lose colonists
- Planetary population decreased —> planetary resource concentrations increased
- Colonists on a planet exterminated —> can recolonize at any planet + facility production decreased
- Facility production decreased —> Maximum fleet cost decreased
- Recolonize a planet —> can pick a favorable location + population will regenerate over time
- High resource concentration + normal population —> high facility production
- High facility production —> resource concentration down
- High technology level + normal population + allied population —> boosted facility production
Example: Low resource concentration + normal population + multiple allied populations —> high facility production
Note: Sharing a facility with other players will divide the production towards each player. Yet sharing a facility with allies will provide a boost. If you have enough allies sharing one facility then the boost will be much, much greater than the loss due to sharing.

So basically, every time you want to increase your population, you must declare a war, wait for your population to die-off, and then repeat the cycle by colonizing a planet that has not recently had its resources extracted. If your population is at war and wins, then they will start a civil war until your population dies-off. Larger wars take more time (1-4 hours) to lose. Uneven wars (e.g. you have low population) take very little time (2-8 minutes).

You can also avoid war, and try gaining research points for your alliance.
Players at war take longer to die if there is a pacifist player on the planet.
You gain extra research points by losing to pacifists.
Pacifists gain research points for their alliance by slowing-down wars.
Players at war can speed-up a war by halving the pacifist-modifiers every f(n,x) seconds (by clicking the "speed-up" button).

Pacifists are divided into five categories:
Clan Pacifist, n=1, research points go towards a clan, which is composed of two or more players
Alliance Pacifist, n=2, research points go towards an alliance, which is composed of two or more clans
Guild Pacifist, n=3, research points go towards a guild, which is composed of two or more alliances
Faction Pacifist, n=3, research points go towards a faction, which is composed of two or more guilds
Coalition Pacifist, n=4, research points go towards a coalition, which is composed of two or more factions
More categories (n=5,6,7, etc.) as the playerbase increases.

Note: You can fight with guild members (depending on guild policy) to gain research points, but it won't increase your guild's research points.

Now for the value of 'n' and 'x'.

Time for population to die-off = 1 hour * (your population) / (enemy population) * (1+planet clan modifier) * (1+planet alliance modifier) * (1+planet guild modifier) * (1+planet faction modifier) * other modifiers

Note: For multiple clans on the same planet, the planet clan modifier is the root-sum of each clan's tech levels.

For example, with one clan, the clan modifier might be 1.
For each clan, alliance, guild, faction, etc. the player at war can click on a "Speed-Up" button.
The speed-up button will halve the clan/alliance/guild/faction modifier.

Example:
Time for population to die-off = 1 hour * (10,000) / (10,000) * (1+clan modifier)

After declaring war —> X=1

clan modifier = 1 / (2^(X-1))
clan modifier = 1 / 1
1+clan modifier = 2
Time for population to die-off = 1 hour * 2
Time for population to die-off = 2 hours

After exp(n*2) seconds —> X=2

Player clicked "Speed-Up" once, after waiting e^(n*X) seconds.
This is a clan, so n=1
clan modifier = 1 / (2^(X-1))
clan modifier = 1 / 2
1+clan modifier = 1.5
Time for population to die-off = 1 hour * 1.5
Time for population to die-off = 1.5 hours

After exp(n*2) + exp(n*3) seconds —> X=3

Player clicked "Speed-Up" a second time. Had to wait e^(n*X) seconds for the "Speed-Up" button to recharge.
clan modifier = 1 / (2^(X-1))
clan modifier = 1 / 4
1+clan modifier = 1.25
Time for population to die-off = 1 hour * 1.25
Time for population to die-off = 1.25 hours

Note: There is one "Speed-Up" button for every single clan/alliance/guild/faction/coalition with a member on the planet. Players have to be online in order to click the "Speed-Up" button. Longer wars give more research points to the players involved (calculated before any "Speed-Up" buttons). Research points are distributed once the player declaring the war has his population die-off. Players declaring a war get research points, and the clans/alliances/guilds/factions/coalitions get research points for prolonging them by pacifism.

Player techs are different from clan techs are different from alliance techs are different from guild techs. They each have a different tech-tree. For example, an alliance tech may be to increase the size of the alliance by +1 clan, or to grant a production-bonus to all facilities shared by alliance members.

Wars are planet-only. After the war is done (i.e. attacker's population has died off due to losing, or due to winning and then civil war), the players involved are automatically at peace again.

Space Combat

- Maximum fleet cost increased —> can keep more ships in orbit
- Planet with fleet in orbit —> no non-allies may colonize
- Ships in orbit —> can attack another fleet in orbit (travel time between planets is instant; travel time between solar systems is not instant)
- Attacking a fleet in orbit —> fleet in orbit destroyed
- Successful attack —> can now colonize planet
- Failed attack —> your ships are instantly rebuilt at the nearest colony and can attack again
Defending orbital fleets take a long time to regenerate if the player is offline (e.g. 50% of ships rebuilt after 30 minutes).
Fleets regenerate instantly if you are online.
Attacks take 2-8 minutes.
Defender and attacker gain research points for space battles.

Key points: The more production, the higher your fleet cost, and the harder it is to destroy.
Lots of players or one player with lots of time can destroy a large enemy fleet.
Fleets regenerate instantly if you are online.

Emphasis on "instant". The game… Now revolves around killing yourself by attacking as many people at once as possible. The faster you lose, the faster you gain research points, and the better your research, the more stuff you can control, and lose more quickly —> faster research.

Summary:

If I want to get research points then what I do is destroy an enemy blockade (2-8 minutes), colonize the planet (instant), wait for my population to grow (10-180 minutes), declare war (instant), wait for my population to die-off (can take up to eight hours), and then repeat! Any clans/alliances/guilds/factions/coalitions with members present at the planet will also gain research points. When I log-off for the day, I want to be colonized at a planet with high resource-concentrations and setup an orbital blockade there in order to:
a) boost my allies' production-bonuses
b) hope that someone will attack me

As my research points increase, I can maximize my maximum number of planets. This means that I can have multiple wars running on different planets.

If someone wants to be a war-monger, the effectiveness of their taxation is increased by allying with players who also take taxes from pacifists.
If someone wants to be a pacifist, the effectiveness of their facilities is increased by allying with other pacifists on their planet (as well as those pacifists' Diplomacy tech level).
War-mongers can easily tax a lot of raw-resources and get rich.
Pacifists can control the most colonists, and can become war-mongers at any time.

Players can be both pacifist and a war-monger at the same time. The only reason to create the distinction is so that we can say which technologies are pacifist-oriented, and which are war-oriented.
Mostly-pacifist players want lots of mostly-pacifist allies.
Mostly war-monger players want lots of mostly-war-monger allies.

Summary:
1) The more allies you have with similar technology as you, the higher your benefit from facilities or taxes is.
2) Some technology benefit player-player treaties, while some benefit group-group treaties.

I'd like to see group-oriented technologies becoming just as important as warfare technologies.
Origin of idea: War of Conquest. If you allied with someone, you got to share their technology bonuses. In Fragmented Galaxy, technologies should give bonuses to your allies… And also very important: More allies (even with newbies) should always be better than fewer allies (of just a few high-tech players). Emphasizing large groups of players helps to avoid elitism in the community.

http://f-g.wikidot.com/the-game

You will lead your nation through its founding and the numerous inevitable following conflicts over territory. Lead or follow, war or peace, explore or concur, fight in the core or wander on the fringes: The choice is yours (Once the game is available and you acquire it).

Should be:

You will lead your nation through its founding and the numerous inevitable following conflicts over territory. Lead or follow, make war or peace, explore or conquer, fight in the core or wander among the fringes: The choice is yours (Once the game is available and you acquire it).

• Green: Inserted word
• Red: Altered/replaced word

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.

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.

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.

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