That would be so AWESOME! It would definitely come up with intriguing new maps to play. ;D
But, if you do have the mathematics required to make it work, it would still need a LOT of trial-and-error to create a proper, playable map. Here are some of the various problems I've thought of:
I'm glad you asked!
1: What will the stats of the resulting asteroid be when 2 smaller ones collide?
I've been playing around with different ideas for this. Here's my current one.
When two asteroids collide, the game treats the smaller one as having "disappeared" (in reality its radius is set to zero, any trees and seeds on it are removed, the owner becomes 0, and a flag is set such that the gravity engine no longer calculates it. The larger asteroid then takes on a proportional amount of the smaller asteroid's energy, strength, and speed.
Lets take an example and look at the change in the energy stat when an asteroid half the size of the target pops and transfers its area and stats.Applied Difference in Energy = Energy Difference / Mass Proportion / (number of asteroids in the collision, this number is always 2)
Energy Difference = smaller asteroid energy - larger asteroid energy
The smaller asteroid has an energy of 0.6
The larger asteroid has an energy of 0.8
The difference is - 0.2
Mass Proportion = (larger asteroid mass * larger asteroid density) / (smaller asteroid area * smaller asteroid density)
Large: 600 area, 2 density
Small: 400 area, 1.5 density
The larger asteroid has a mass (ie area * density) of 1200
The smaller asteroid has a mass of 600
1200 / 600 = 2
Applied Difference in Energy = Energy Difference / Mass Difference / 2
Applied Difference in Energy = -0.2 / 2 / 2
Applied Difference in Energy = -0.1 / 2
Applied Difference in Energy = -0.05
New Energy = Large Asteroid's Energy + Applied Difference in Energy
New Energy = 0.8 + (-0.05)New Energy = 0.75
2: What will the behaviour of any seedlings/trees be when the roid they're on collides with another?
Trees and seedlings on the smaller asteroid are removed. I'm going to wait and see what the gameplay is like before I decide anything more for this..
3: What will happen when an asteroid is flung out of the system (which is extremely likely to occur)?
When asteroids fly out the system, the asteroids themselves stop at the edge of the level's quad tree. Basically they go a certain distance then just sort of stop. :P The game will not allow you to move them at all if it is outside the quad tree. This results in all sorts of strange behaviour which I won't go into for now.
Despite this, the gravity engine is keeping its own variables and it still knows where the asteroid "ought" to have been. It continues to plot the "virtual" course of the asteroid, and if after a time that virtual course should happen to take it back onto the allowed game area, the asteroid will "jump" to wherever this position is and start falling inwards at whatever pace and direction indicated by the gravity engine at that time.
During the time the asteroid is off the allowed play area, the seedlings seem to go flying off at lightspeed and the asteroid temporarily "dies", appearing to turn black and cease production of any seedlings.
This is the functionality that exists by default in Eufloria. The question is, how can I make it so that asteroids flying off the screen always return to the middle within a decent time frame? My hope is that they will always be drawn back to the middle after a reasonable amount of time has elapsed, and if they only come back and forth once every 20 minutes, well... then you have a comet.
If asteroids seem to fly off permanently, I might grudgingly introduce some kind of artificial mechanism to slow them down and nudge them back towards the game area. Another possibility is to just remove these asteroids from the game entirely, and this would introduce a level of strategy in deciding which asteroids to colonise - by judging which asteroids look least likely to go flying off into space, carrying your seedlings and trees with it.
4: What will happen when roids that belong to different EMPIRES collide and merge?
The larger asteroid's owner has a costless victory.
The smaller asteroid's owner loses an asteroid. :P
5: What if you place too many asteroids, and the gravity engine can't cope with hundreds of asteroids colliding and recolliding, and constantly changing size and distances to other asteroids?
The gravity engine calculates each collide and combine event, and each movement event, in a specific order each pass it does. It would follow its normal order regardless of how many events are taking place. The order in which things happen is predetermined, the gravity engine won't get confused simply because it is working with a larger data structure. I am pretty sure it will be fine.. :>