Gravity Engine - dev blog

[annikk.exe]

As you may or may not have heard, now that I have finished my AI map I intend to begin work on a "gravity engine", with moving asteroids.. and basically my first project once the engine is finished will be to build a rendition of our solar system.  Earth, Venus, Mars, etc, all will be represented, along with their moons, and will orbit one another.


I expect this to take several months to complete, but I suppose it depends how obsessed I get.  :>

[annikk.exe]

Last night I learned the equation for calculating the force of attraction between two masses.

It is: Fg = (G * CheckedRoid * DistantRoid) / SeperationDistance^2


Fg, G, CheckedRoid, DistantRoid, and SeperationDistance are all variables.

• Fg is a variable describing the amount of gravitational force acting on an object
• G is the gravitational constant (in reality 0.667 x 10^-11), which I will probably change to something more suited to the scale of a Eufloria level
• CheckedRoid is the asteroid whose gravitational forces we are calculating on this pass
• DistantRoid is the asteroid to which we are measuring the gravitational pull
• SeperationDistance is the distance between CheckedRoid and DistantRoid - calculated using pythagoras theorum: SeperationDistance = math.sqrt((horizontal difference between checkedroid and distantroid)^2 * (vertical difference between checkedroid and distantroid)^2)

I will use a For loop to check all of the asteroids in turn.
Then, for each asteroid I check (ie checkedroid), I will use another For loop to check all the gravitational forces from other asteroids that are acting upon it.
Then, once I have all the different forces acting on checkedroid, I combine them using Force Vector Summing, another crazy maths concept I learned about last night.

Basically imagine one of the gravitational forces.  It has a direction that it is pulling, and it has a magnitude.  You could imagine this like an arrow pointing from checkedroid towards distantroid.  You can imagine that the length of the arrow is indicative of the amount of force it is exerting.  So a large distantroid with a lot of gravity would exert a large force on checkedroid, and would mean a longer arrow.

So when you plot all of these arrows, you basically get lots of arrows spiking outward from checkedroid, and pointing at all the distantroids.  The size and the distance of the distant asteroids would be the determining factors of the length of the arrows.

To add all of these arrows up into a single combined arrow, first you pick up all of the arrows except for the very first one.
Where the first one ends, you place the second one's start.
At the end of the second arrow, you place the start of the third arrow, and so on.

If all of the forces acting upon the object are equal and cancel each other out, the line you draw with these arrows will always end up back at checkedroid where it started - regardless of the order you put the arrows down in.

If the tip of the final arrow is some way off from checkedroid, you can draw a line between that point and checkedroid and this line that you draw is the combined direction and magnitude of all of the asteroids.

So that's the principle behind force vector summing.  To do it mathematically I have to find something called the dot product of all of the different vectors.


Here is some pseudo code representing how I intend to do this:

Code: [Select]

for passnumber = 1, number of asteroids do

if distantroid is in the North East Quadrant compared to checkedroid then:
summedvectorx = summedvectorx + x[passnumber]
summedvectory = summedvectory - y[passnumber]
end

if distantroid is in the North West Quadrant compared to checkedroid then:
summedvectorx = summedvectorx - x[passnumber]
summedvectory = summedvectory - y[passnumber]
end


if distantroid is in the South East Quadrant compared to checkedroid then:
summedvectorx = summedvectorx + x[passnumber]
summedvectory = summedvectory + y[passnumber]
end


if distantroid is in the South West Quadrant compared to checkedroid then:
summedvectorx = summedvectorx - x[passnumber]
summedvectory = summedvectory + y[passnumber]
end

end


At the end of that, summedvectorx and summedvectory will be the values needed to show where to draw the force vector for the combined force.  Some quick pythagoras gets the distance, and thus the magnitude of the force, and it should be no problem to calculate the angle.


Then its some Newton laws or something, to calculate the effect that force has on that mass, given its present momentum and direction.  I will research that later I guess.

[annikk.exe]

It occurs to me I should really check out the Asteroid move functionality to see what it's like...  but eh... SCIENCE!!!

[njursten]

FYI, the Fg is the size of the force acting on both CheckedRoid and DistantRoid, it's symmetrical. This means that you only need to calculate the force for a certain pair once.

Code: [Select]

for i = 0,numAsteroids do
   for j=i+1,numAsteroids do
      ForceMatrix[i][j] = Fg
      ForceMatrix[j][i] = Fg
   end
end

Also, you shouldn't have to check which quadrant DistantRoid is in, that will be taken care of automatically:

Code: [Select]

ForceVector = Fg * NormalizedVector(PosChecked - PosDistant)
Here ForceVector, PosChecked and PosDistant all are 2D vectors (ie. a pair of x-y components) but not Fg.

If you need any help with the math I can probably help you out, just prod me in a PM.

[annikk.exe]

heh... wow... that's so much more elegant than my method :>

I will try to learn about matrices and the other stuff you mentioned, and prod if necessary.. :>

[annikk.exe]

Ok so I'm imagining the matrix as basically a table with columns and rows.
Where i is the column number and j is the row number.

Is that correct?

If so then for each step of i, you will in all of the top column and for each one you also set its symmetrical value to be the same.  So because you are saying Fg = both ForceMatrix[ i ][ j ] and also ForceMatrix[ j ][ i ], basically you are still storing the value twice because you need to know it both ways around, because at some point both asteroids will be the checked one.  The advantage is that it becomes more convenient to call the force acting on an asteroid, and results in less cluttery code.  Is that correct..? :>


I am not clear at all on how your second piece of code is working.  Can you explain it to me? :>

[njursten]

Yes, they are row/column indices. You could just store it in ForceMatrix[ i][j], but then when you do lookup in the table you have to make sure you index with i as the higher of the two numbers. Just extra code for no real improvement. The main reason to only loop over half of the elements is that it's quicker. Kind of a moot point if you're not gonna have a few millions objects. Yes, I'm a perfectionist.

Regarding the second part, do you know vector math (linear algebra)?

I've attached an image. The points marked A and B are the two asteroids. If you do the vector operation minus, you get the distance between them, as a vector. This is useful, because you need to know in which direction to add the force of the gravity. But you only want it as a direction. This would be an arrow pointing to the point marked (B-A)/|B-A| in the image, assuming the circle is the unit circle (ie. has a radius of 1).

To transform it into a direction, you normalize the vector. This is done by dividing the vector by its length (length for 2D vector = square root of (x^2 + y^2)). This will always result in a vector with a length of 1. To write x and y separately:

Code: [Select]

x part of force = Fg * xdiff / sqrt(xdiff^2 + ydiff^2)
y part of force = Fg * ydiff / sqrt(xdiff^2 + ydiff^2)

The distance, as a scalar, between the two asteroids is the same as the length of (B-A), normally written |B-A|.


Don't know if this made it clearer? Also, maybe I covered some stuff you already knew.

[annikk.exe]

Making neat, concise code is a good cause... and so is using features of the language that I've not used before, so I am definitely interesting in trying to use this Matrix beasty you are describing.

I am afraid I'm not at all comfortable with vectors and scalars.  If you were to ask me what they meant, I could probably hammer out a rough definition of vector but I honestly have no clue about scalars - what they are, how they are used, and how they differ from other, similar things.

I will try to learn about these things at the weekend.  Failing that, if it's really beyond me, I might just do it the messy way


Actual coding hasn't begun yet, by the way.  It's all planning and contemplation at the moment.

[annikk.exe]

Ok so... a scalar is a line you can draw between two vectors.  Right?

Assuming I'm understanding that correctly, then my next question is how does this help me determine what quadrant a particular force is pulling in?

[njursten]

Ah, no, a scalar is just a single number, as opposed to a vector. A length has only 1 dimension so it's a scalar, while for example a direction has 2 or 3 dimensions, depending on your world geometry.

A vector is simply a collection of numbers. They can be used to describe a position, direction or whatever that has several components. A matrix is more or less a collection of vectors. You should read up on "Linear Algebra". It basically means vector and matrix mathematics. There are some operations, like vector multiplication and matrix multiplication that can be very useful, but I don't think you can use them for this problem though. But general vector addition and subtraction is useful at least.

It's not the scalar that gives you the direction. It's the subtraction of the two positions from each other that gives the vector pointing from the first asteroid to the other. The whole thing about which quadrant the other asteroid is in is just a flawed idea. You should get a changed sign on the numbers automatically, because the direction between the asteroids will turn negative for x-component if the other asteroid is on the left of the first one.

[annikk.exe]

Code: [Select]

x part of force = Fg * xdiff / sqrt(xdiff^2 + ydiff^2)
y part of force = Fg * ydiff / sqrt(xdiff^2 + ydiff^2)


This code would erroneously produce a positive number every time.  In fact, sometimes the forces should be negative - if the overall force is pulling "south", for example, the value of Y part of Force should be negative.  Hence quadrant checking still seems essential.

[annikk.exe]

I am probably still wrong though.

[annikk.exe]

I have figured this out, I think.

I was getting confused because I was thinking about coordinates of the asteroids, instead of a "virtual" plane consisting of vectors that indicate acceleration and momentum.

(0,0) in the context of the summed Force Vector is actually "no additional momentum in any direction", not literally the coordinates (0,0).  The momentum itself is just another line in this virtual plane.

So suppose your CheckedRoid has a momentum which can be expressed as the vector (50,50).  If the Summed Force Vector of all the asteroids' gravitational pull lies at (15,-15) then we can combine the acceleration due to gravity with the existing momentum, to give the new momentum for this Game Cycle, by doing the following: (50,50) + (15,-15) = ((50 + 15),(50 - 15)) = (65,35).  Our new momentum vector, indicating the amount we shall travel in the REAL X-plane, and the amount in the REAL Y-plane, is therefore 65 units horizontally and 35 units vertically.

Suppose we had a Summed Force Vector with different signs... like (-12,30).  Our existing momentum (50,50) combines to give (50 - 12),(50+30) = (38,80).  So we travel 38 units horizontally, and 80 units vertically.



Let me know if this demonstrates the understanding you are looking for Njursten :>

[annikk.exe]

Asteroid initial momentum conditions will be expressed in how many units (+ or -) horizontally and vertically it travels in one game cycle.

So Asteroid0XMomentum = 5 and Asteroid0YMomentum = 0 would give an asteroid drifting slowly sideways.


Seems like I don't actually have to work out the angle it travels at... :>

[njursten]

Code: [Select]

x part of force = Fg * xdiff / sqrt(xdiff^2 + ydiff^2)
y part of force = Fg * ydiff / sqrt(xdiff^2 + ydiff^2)


This code would erroneously produce a positive number every time.  In fact, sometimes the forces should be negative - if the overall force is pulling "south", for example, the value of Y part of Force should be negative.  Hence quadrant checking still seems essential.

No, it won't be positive all the time, because xdiff and ydiff are not always positive. If asteroid B is to the left of asteroid A, then xdiff is negative and otherwise positive. Similarly for ydiff. Another important point is that you can't really do it any other way, you have to see how far into the quadrant the asteroid is. That more or less boils down to my equations.


Regarding the third post: Yes, you seem to have understood it.
Though the diff vector in my image exists in the coordinate plane. Then you scale it to get the real force vector, your acceleration vector more or less.

[annikk.exe]

Ok, having finally understood it I can safely say the way you have explained it was....overcomplicated.  :P   Perhaps simple if you know a LOT about mathematics, but I am a bit of an armchair scientist when it comes to that sort of stuff. Thankyou for pointing out that there was some flaw in my logic though.


I have been studying the use of a triangular matrix to store the force vectors for each gravitational relationship.

The efficiency is becoming clear.  For a level with 5 asteroids, a standard square matrix would store 25 pieces of data.  With the triangular matrix I can have the same information, but with just 10 pieces of data.

Where N is the number of asteroids in the level, the number of pieces of data needed in a square matrix is N^2.  The number of pieces of information that one needs to store in the triangular matrix is given by (N^2 / 2) - (N / 2).




Pictured here is possible data structures for a level with 6 asteroids.

Using the above formulas...

6*6 = 36.  You need to calculate 36 pieces of data every game cycle if using the Square matrix.
6*6 = 36 / 2 = 18, and 6/2 = 3... so 18 - 3 = 15.  You need just 15 pieces of data if using the triangular matrix.  Go ahead and count the boxes to check, if you want.  :>



So for a level with 50 asteroids, the square matrix would balloon to 2500 pieces of data.  But the triangular matrix would need to store 1225 pieces of data.  When you consider each of these pieces of data must be recalculated every game cycle, the desirability of an efficient data structure becomes clearer.  It should hopefully result in smoother (ie less jerky) movement of the asteroids.  :>

[annikk.exe]

In other news, I just managed to persuade my flatmate to make me not one, but TWO cups of tea.  At the same time.  I just finished drinking the first, starting on the (still lukewarm) second tea now.

[njursten]

Yeah, you're right. It would have made more sense to start with explaining vectors and matrices and their operations properly first. Hm, I'd recommend you to read up on it. Wolfram's MathWorld might be a good place to start (http://mathworld.wolfram.com/Vector.html). Though maybe it's a bit too scientific... I don't know what other resources there are though. Maybe Wikipedia?

[annikk.exe]

I watched a few mathematics lectures on youtube
I watched an entire series of physics lectures by Prof. Richard A. Muller, about 30 hours in total
I spent a lot of time talking to my cousin who works for Sony making fancy 3D stuff (and knows lots about linear algebra)
I visited various websites - of which Wolfram's Mathworld was one - learning about Linear Algebra
I spent time scribbling on A4 pieces of paper at evenings and weekends, practicing problem questions and trying to visualise what is going on.

I actually learned a lot more than was strictly necessary to solve this problem - but just getting used to thinking about vectors really helped me to see what was wrong in the end.  I went back over my first initial posts and looked at what I had been proposing, and realised the mistake I had made.  Hopefully the coding part will be that much easier as a result of the groundwork I've put in.



Tonight I will make a concerted attempt to figure out what code would create a triangular matrix like the one I posted previously.

Might even start the actual coding this weekend, too...  :>

[annikk.exe]

By the way, regarding this:

No, it won't be positive all the time, because xdiff and ydiff are not always positive. If asteroid B is to the left of asteroid A, then xdiff is negative and otherwise positive. Similarly for ydiff. Another important point is that you can't really do it any other way, you have to see how far into the quadrant the asteroid is. That more or less boils down to my equations.

The comments I made that you are referring to, I made before having understood what the problem was.
Therefore no longer relevant.  :>

[annikk.exe]

Hmm, I wonder... If I use the following command:

Code: [Select]

for j = 0,0 do

Does that mean that it will basically skip over anything inside the For loop, ie it won't even run those commands once?

[annikk.exe]

aaaaaand that's a negative.  It runs once.

for test = 0,-1 do runs zero times.

[annikk.exe]

So this code should create the triangular matrix.

Code: [Select]

--COLUMN

for i = 0,roidnumber do

--ROW
for j = (i + 1),roidnumber do


-- calculate!!


end
end

[annikk.exe]

Code: [Select]

for i = 0,numAsteroids do
   for j=i+1,numAsteroids do
      ForceMatrix[i][j] = Fg
      ForceMatrix[j][i] = Fg
   end
end


Oh.  You already had it there.  lol.
Well, I honestly did figure it out on my own as well! :P

[annikk.exe]

Started coding.  Got a brand new error that I've never seen before!  :>

[annikk.exe]

Am having difficulty with the part where I need to calculate seperation distance between asteroids based on their coordinates.  Need moar maths..

[annikk.exe]

Giving up for tonight.  Made some good progress I guess, the triangular matrix seems to work good, and the asteroids move....just not the way they are supposed to.

The problem at the moment is that I am improperly using a scalar to calculate the acceleration.  The vector is there too and I am sure I can use it, but my brain is tired for tonight so I am gonna get some sleep and work on it more in the morning.

[annikk.exe]

Question for Njursten;  how is xdiff and ydiff calculated?

[annikk.exe]

Sweet!!  Got it working! :D


edit... wait, nope.. :p

[annikk.exe]

ok... seems to be working now.  Got 2 asteroids orbiting one another.  :>

[annikk.exe]

Building trees on both asteroids, sending seeds between them while they orbit each other...

this is pretty magical... :>
<3

[annikk.exe]

Ah screw it, have a test level.  :>

I included some instructions in the comments in case anyone wants to try changing the initial conditions :>

[annikk.exe]

haha, flowers are so funny in this :p

[AWS]

ooh, nice!
im trying your test level now...
will report.

thanks annikk...

EDIT - excellent and incredible stuff indeed! may i make one note? the speed of rotation seemed pretty fast. im sure it'll all be ironed out by the end but i thought i should mention it.

looking forward to this one....

[annikk.exe]

Guide to making levels for the Gravity Engine

Work in progress.  :>



Global Variables


G is the most important variable.  It is found in LevelSetup().  It is the overall force of gravitational attraction.  If you set this number very high, your asteroids will need to travel extremely quickly in order to orbit each other, because they will be falling towards each other with a very large force.

roidnumber is another important variable.  This tells the gravity engine how many asteroids it should calculate gravity for.
If you set this to 1, asteroid ID's 0 and 1 will calculate gravity between one another, but the engine will completely ignore Asteroid ID's 2, 3, 4, 5, 6, and 7.

If you actually had asteroid ID's 0 through 7, and you wanted to calculate gravity on ALL of them, you would set roidnumber = 7.

roidnumber is a useful number to change when you are trying to balance the orbits of asteroids.  It means you can have all the asteroids placed, but only a certain number of the inner asteroids will move - the others will be invisible to the gravity engine.  Then you can balance the orbits of the smaller number of asteroids before introducing asteroids that orbit further away.





Creating Asteroids


When you create a new asteroid for the gravity engine, you have to declare the properties of the asteroid in a special way.


You declare these initial conditions and properties in LevelSetup().


See below for examples of creating asteroids.  It is ok to copy and paste these as templates, then change the bits that need changing.


Just make each asteroid in turn:

Code: [Select]

-- Asteroid 1 - Mercury
-- gravity variables
AccelerationX[1] = 0
AccelerationY[1] = 0
MomentumX[1] = 5.2
MomentumY[1] = 0
density[1] = 1
CoordX[1] = 0
CoordY[1] = 2700
roidradius[1] = 250

-- Creation
a = AddAsteroidWithAttribs(CoordX[1],CoordY[1],0.5,0.5,0.5)
a.Owner = 1
a.TreeCap = 4
a:SetRadius(roidradius[1])
a:Reveal(1)

• AccelerationX and AccelerationY should ALWAYS be set to zero.  You just need to declare them, is all.
• MomentumX and MomentumY tells the asteroid how fast it is moving in each direction when the level starts.  These can be negative.
• roidradius is the radius of the asteroid.  A bigger radius means a larger area, and correspondingly more gravity.
• density is how dense the asteroid is.  More density = greater amount of gravitational force, but (in theory) less susceptable to being moved by gravity itself, because its mass is greater.
• CoordX and CoordY are the coordinates you want the asteroid to start at.
• Make sure you change the number inside ALL the square brackets [ ] to the asteroid ID number of your new asteroid.  EG:

Code: [Select]

-- Asteroid 2 - Venus
-- gravity variables
AccelerationX[2] = 0
AccelerationY[2] = 0
MomentumX[2] = -4.1
MomentumY[2] = 0
density[2] = 1
CoordX[2] = 0
CoordY[2] = -4200
roidradius[2] = 325

-- Creation
a = AddAsteroidWithAttribs(CoordX[2],CoordY[2],0.5,0.5,0.5)
a.Owner = 1
a.TreeCap = 4
a:SetRadius(roidradius[2])
a:Reveal(1)


Random Tips and Tricks


You can create a "sun" asteroid that has a gravity well, but does not move itself.
To do this, make the sun Asteroid ID 0.  Then find line 209 in Function LevelLogic()

Code: [Select]

for pass = 0,roidnumber do
and change it to:

Code: [Select]

for pass = 1,roidnumber do

Now asteroids will be able to orbit around Asteroid ID 0, but Asteroid ID 0 itself will never move.



The easiest way to get one asteroid to orbit another is to place it directly above the asteroid you wish it to orbit, then send it flying off to the left or right by changing the MomentumX value.  Balancing the amount of momentum so that it maintains a constant distance is then the only real challenge.  You can get some really nice circular orbits this way without too much difficulty.



You can create a black hole by creating an asteroid with a roidradius of 1, and a density of several thousand.  Objects will fly around this apparent invisible point in space, as if there were an enormous sun there.

[annikk.exe]

Update to gravity engine to fix density bug:


Find code:

(click to show/hide)

Code: [Select]

Fgx = (G * ((roidradius[i] * roidradius[i]) * math.pi) * ((roidradius[j] * roidradius[j]) * math.pi)) / ((CoordX[j] - CoordX[i])^2 + (CoordY[j] - CoordY[i])^2)
Fgy = (G * ((roidradius[i] * roidradius[i]) * math.pi) * ((roidradius[j] * roidradius[j]) * math.pi)) / ((CoordX[j] - CoordX[i])^2 + (CoordY[j] - CoordY[i])^2)

Replace with:

(click to show/hide)

Code: [Select]

Fgx = (G * ((roidradius[i] * roidradius[i]) * math.pi * density[i]) * ((roidradius[j] * roidradius[j]) * math.pi * density[j])) / ((CoordX[j] - CoordX[i])^2 + (CoordY[j] - CoordY[i])^2)
Fgy = (G * ((roidradius[i] * roidradius[i]) * math.pi * density[i]) * ((roidradius[j] * roidradius[j]) * math.pi * density[j])) / ((CoordX[j] - CoordX[i])^2 + (CoordY[j] - CoordY[i])^2)

[annikk.exe]

This will probably break the test level, heh. 

[annikk.exe]

Got Mercury, Venus and Earth orbiting the Sun now..  and Luna orbiting Earth ^_^

[annikk.exe]

Now if only I could name asteroids....

[annikk.exe]

Added mars...

crashing for tonight, I think.  :>

[annikk.exe]

Progress on this particular map has now plateu'd, due to problems with the maximim map size.
Hoping for some answers in this thread..

[AWS]

well, im sure im not the only that is blown away by your progress with all this solar system stuff.
i really cannot wait till youve completed it all in its wondrous glory! 

didnt alex say that there was no way of expanding the paramaters (?) of the building space?

otherwise, anything further to report annikk?

AWS

[annikk.exe]

Fixed the map size problem, thanks to Mihaelo (sp?).  :>

Now I am trying to find a solution to the problem of seedlings not planting themselves properly.

What happens is the tree gets planted, and the 10 seedlings required for it simply stop orbiting and fly around lazily in space, at the position the asteroid was at when the button was clicked.

When the asteroid comes back round again, some of the seedlings are able to plant themselves.  However, frequently, 1 or more seedlings never manage to plant themselves, and hang around in space looking messy for the rest of the game.


So, to fix it..

Slowing the asteroid down doesn't help - it would need to stop for several seconds before moving on, which obviously would look pretty dumb.
I tried to increase their turn rate.  That didn't work, it seems to be a value between 0 and 1 - anything above 1 causes them to have a turn rate of 0.  Even set to 1, they weren't able to land on the asteroid and plant themselves.

I tried changing the minimum and maximum altitude....that didn't work either.

Not sure what to do about this problem.  One idea I had is to set the number of seeds needed to build a tree to zero, but reduce the number of seeds on the asteroid by 10 each time a tree is built.  If there are less than 10 seeds on the asteroid, the buttons for building trees are deactivated.  The problem is this means I need to know which asteroid the player has clicked on... and it gets complicated with the AI not needing any seeds to build trees either... meh.

One kind of sucky option would be to disable the Dyson and Defense buttons altogether, but cause 10 seedlings on an asteroid to automatically convert to a tree (neatly removing the seeds from the roid).  That means you would only get to plant Dyson trees, and sending an army of 30 seedlings to defend an asteroid with 1 tree, would simply result in you building 3 trees....and probably then losing the asteroid to the attackers.  Changes the dynamic of the game a lot, and is a bit meh overall.

Any other suggestions for fixing/working around this bug would be appreciated.  Or Alex could hotfix it so that seedlings in "plant mode" continuously recheck the position of the asteroid, in case it is moving... ;)

[Mihhaelo]

I have three idea's, although they're probably both of no use to you.

Idea one: You could make your map galcon-esque, seedlings being added to planets over time with the amount of seedlings recieved based on the size of the planet (So you'd put the spawn rate of tree's down to zero), every planet would begin with neutral seedlings on them. Tree's would be added to the planets at the start of the game in LevelSetup(), and planets would recieve a number of tree's proportional to their size. Tree's would be mostly aesthetic, although they'd still spout flowers. You could use your flowers to make the planet produce super seedlings or mines. (It can't be that hard to check if a planet has a super-tree, and add superseedlings in script). Alternatively, you could script it so that super-tree's increase the production of the planet. If you take this option, as in galcon, the players and AI's home planets would have to out-produce all the other planets individually. Otherwise the player might be in a position where they couldn't take any planets.

Idea two: Similar to your idea (checking to see if there are 10 seedlings on a planet, adding a tree and removing the seedlings in script). Although the game would only do this if 10 seedlings AND a flower were present on a planet. This would allow players a degree of control over where they want to plant trees. A drawback here, is you'd have to either have a high flower probability, or you'd have to add them over time with a script.

Idea three: Yet again, a rehash of your idea. You could disable the "planet tree" buttons at the start of the game, and make it cost 0 seedlings to make a tree. Every 60 seconds (or how ever long you feel like), the game would reenable the button. On planting a tree, the game would disable the button again.

Alternatively, to give players more say over when they build trees (and not time based) you could give players a "seed" planet; whereby the player would have to send 10 seedlings to this planet in order to enable the plant tree button. Realistically it would be ideal if this planet was a moon, and orbited their home planet and belonged to them at the start of the game.

If i think of anything else i'll let you know.

[annikk.exe]

Wondering what Globals.Agents.BomVolume  (int) does...

[Alex]

That's the volume of the laser sound. The first sound we used sounded more like a drum than the lasery sound we have now.

I'll look into this, chaps. Have no fear.

[annikk.exe]

Sweet :>  Thanks Alex!  ::heroworship::

[annikk.exe]

So at the moment I am working on a new version of the Sol map, this time with much wider spacing.  Mercury, Venus, Earth, Luna, and Mars are all in stable orbits, as is Jupiter.  I am currently working to balance Io and Europa in orbit around jupiter...  4 moons is going to be a big challenge to get right.


The list of stuff I want to do with gravity engine:


1.  First up, finish Sol - as a (hopefully) stunning example map.  This will likely use the AI from Infected Empire; the metric-based system for determining actions would work very well in this type of map.

2.  Write up a really nice template file of the gravity engine, this will be released for others to make their own gravity maps.

3.  I have another idea for a nifty gravity-based map that I'd like to try..

4.  I have plans to add asteroid collision detection in the future.  Rather than bounce off each other, I am tempted to make them "merge" into a single, larger asteroid - rather like 2 drops of raining winding their way down a car windscreen, touching, and then "popping" together as the surface tension between them collapses.

This would then be used in a map where the initial conditions consist of hundreds of tiny asteroids moving in random directions.  These tiny asteroids collide with one another, combining to form larger asteroids that fall into a natural orbit around one another.

This would be a really fun way to procedurally generate levels.  It wouldn't always produce a level that is playable, but from working with gravity for a little while now it's actually not that unusual for objects to naturally find a stable eliptical orbit..  I have already covered all the initial mathematics to describe how the collision detection and merging systems would work.

[Alex]

Haha I wonder if one day we'll be able to recreate Osmos in Eufloria

[annikk.exe]

That would definitely be possible, using very similar code as outlined above.. :>

[AWS]

wouldnt the best solution, without writing brand new script, to be to slow down the rotation of the roids to the point where all the seeds will plant themselves? this seems the most obivous solution to me. but then, i have no idea how it all really works. i just know that if the planets are going too fast for the seeds to plant, slow it down until they do.
no?!

[Bonobo]

You may know it, but if you don't, then the information might be of use:

These days I tend to increase game speed with that dev mode tip youze gave me in that other thread ...

And today I played some older standard levels ... with speed +3 or +4. Wondered why my flowers wouldn't plant even though I'd given them orders. Then I slowed down the game till it had normal speed, and voila, the flowers finally planted. Planting trees with seedlings doesn't seem to be affected by this.

[Harsha]

wouldnt the best solution, without writing brand new script, to be to slow down the rotation of the roids to the point where all the seeds will plant themselves? this seems the most obivous solution to me. but then, i have no idea how it all really works. i just know that if the planets are going too fast for the seeds to plant, slow it down until they do.
no?!

or instead of this, is it possible only to increase the speed of the seedlings that are planting (but not other seeds and the roids) so that dey can catch up?? 

[annikk.exe]

Setting + / - game speed in Developer does not affect the gravity engine at all, unless you are already artificially limiting it.
The final release will have a rate limiter applied, meaning a maximum of 100 recalculations per second.  However, + / - will still do nothing or almost nothing.

In any case, surely the map ought to be playable without the use of developer mode.  :>


With regards to slowing the asteroids down so seeds can plant themselves.
I found that in order to get this to work, the asteroids need to slow down to such a degree that it's barely possible to tell they are moving at all, much less work out if they are in a stable orbit or not.  In my view this approach results in a shortfall of awesomeness.



Sorry to shoot you all down.  :<  Thankyou for the suggestions though, please keep them coming!

[Sniped50]

I have plans to add asteroid collision detection in the future.  Rather than bounce off each other, I am tempted to make them "merge" into a single, larger asteroid - rather like 2 drops of raining winding their way down a car windscreen, touching, and then "popping" together as the surface tension between them collapses.

This would then be used in a map where the initial conditions consist of hundreds of tiny asteroids moving in random directions.  These tiny asteroids collide with one another, combining to form larger asteroids that fall into a natural orbit around one another.

That would be so AWESOME! It would definitely come up with intriguing new maps to play. 

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:

1: What will the stats of the resulting asteroid be when 2 smaller ones collide?
2: What will the behaviour of any seedlings/trees be when the roid they're on collides with another?
3: What will happen when an asteroid is flung out of the system (which is extremely likely to occur)?
4: What will happen when roids that belong to different EMPIRES collide and merge?
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?

In any case, if you can sort out these 'small' problems, I'd love to play any map you come up with. I hope it works! 

[AWS]

  In my view this approach results in a shortfall of awesomeness.

a decline in awesomness is not desired! awesomeness is necessary, carry on...
 

[Harsha]

With regards to slowing the asteroids down so seeds can plant themselves.
I found that in order to get this to work, the asteroids need to slow down to such a degree that it's barely possible to tell they are moving at all, much less work out if they are in a stable orbit or not.  In my view this approach results in a shortfall of awesomeness.

What about increasing the speed of the seedlings which are being planted?? 

[annikk.exe]

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

[annikk.exe]

What about increasing the speed of the seedlings which are being planted?? 

Unfortunately seedlings seem to be lazy about moving to the planting location, regardless of their speed.  I've had it all the way up at 5000 or so, and it made no appreciable difference.  Seedlings seem to have a special "plant mode" that they enter, where they fly about in a lazy sort of fashion.

[annikk.exe]

Still hoping Alex is going to save the day..  the whole Solar System idea is a bit scuppered otherwise :/  let alone a big bang level.

In the mean time I might make something a bit simpler, with less moving bodies, that works within the (pretty serious) limits imposed by being unable to plant trees on an asteroid that is moving.  I sense that people are getting a bit tired of waiting for something playable to arrive so I will get something put together this week.  This new level will go live at the weekend.  :: throws hat over wall ::

[Alex]

What I'll probably do is when an asteroid is moved, the seedlings will move by the same amount.

[annikk.exe]

That'd do it.. :>  That is their behaviour when orbiting, so that should look and function perfectly :D

[annikk.exe]

Did a few more updates to the engine itself tonight, to try to make it easier to create asteroids that are affected by gravity in different ways.


There are three categories.

1.  First you declare asteroids that have a gravity well, but do not themselves move.
2.  Then you declare asteroids that have a gravity well, and are also moved by gravity.
3.  Finally, you declare any asteroids that you do not want to be affected by gravity, nor have a gravity well.


Here's a template I put together to illustrate asteroid creation for the gravity engine:

(click to show/hide)

Code: [Select]

-- ****************************************
-- **********Asteroid Creation*************
-- ****************************************
--




-- ***
-- 1.  THE BELOW ASTEROIDS HAVE A GRAVITY WELL BUT DO NOT THEMSELVES MOVE
-- ***


-- Asteroid 0
-- gravity variables
roid = 0
AccelerationX[roid] = 0
AccelerationY[roid] = 0
MomentumX[roid] = 0
MomentumY[roid] = 0
density[roid] = 50
CoordX[roid] = 0
CoordY[roid] = 0
roidradius[roid] = 1750

-- Creation
a = AddAsteroidWithAttribs(CoordX[roid],CoordY[roid],0.5,0.5,0.5)
a.Owner = 1
a.TreeCap = 0
a:SetRadius(roidradius[roid])
a:Reveal(1)
a.Moveable = False


-- Asteroid 1
-- gravity variables
roid = 1
AccelerationX[roid] = 0
AccelerationY[roid] = 0
MomentumX[roid] = 0
MomentumY[roid] = 0
density[roid] = 0.1
CoordX[roid] = 3170
CoordY[roid] = 275
roidradius[roid] = 350

-- Creation
a = AddAsteroidWithAttribs(CoordX[roid],CoordY[roid],0.5,0.5,0.5)
a.Owner = 1
a.TreeCap = 4
a:SetRadius(roidradius[roid])
a:Reveal(1)
a.Moveable = False







wellonlythreshold = roid + 1
-- ***
-- 2.  THE BELOW ASTEROIDS HAVE A GRAVITY WELL, AND MOVE
-- ***


-- Asteroid 2
-- gravity variables
roid = 2
AccelerationX[roid] = 0
AccelerationY[roid] = 0
MomentumX[roid] = 0
MomentumY[roid] = 0
density[roid] = 0.1
CoordX[roid] = -1200
CoordY[roid] = -3700
roidradius[roid] = 475

-- Creation
a = AddAsteroidWithAttribs(CoordX[roid],CoordY[roid],0.5,0.5,0.5)
a.Owner = 1
a.TreeCap = 4
a:SetRadius(roidradius[roid])
a:Reveal(1)
a.Moveable = False





gravroidsthreshold = roid
-- 3.  THE BELOW ASTEROIDS DO NOT MOVE AND DO NOT HAVE A GRAVITY WELL

-- Asteroid 3
-- gravity variables
roid = 3
AccelerationX[roid] = 0
AccelerationY[roid] = 0
MomentumX[roid] = 0
MomentumY[roid] = 0
density[roid] = 0.1
CoordX[roid] = -4000
CoordY[roid] = -3050
roidradius[roid] = 425

-- Creation
a = AddAsteroidWithAttribs(CoordX[roid],CoordY[roid],0.5,0.5,0.5)
a.Owner = 1
a.TreeCap = 4
a:SetRadius(roidradius[roid])
a:Reveal(1)
a.Moveable = False




roidnumber = roid
-- END ASTEROID CREATION

[annikk.exe]

After my first gravity-based level is released I will publish a nice, user-friendly version of the gravity engine aimed at novice-to-intermediete level designers.

[annikk.exe]

New level is going well...  Asteroids are placed, comet orbit is 100% stable, cloaking/decloaking and wave-add works good also.  About 60% of the functionality is in place now.
I am having some trouble integrating the AI from Infected Empire into the map.  The AI seedlings don't seem to want to expand to their empty asteroids..

Hmm, maybe I can't check values with == GetAsteroid().TreeCap ...

Will try setting treecap with a declared variable tomorrow...

[Bonobo]

[..]

I am having some trouble integrating the AI from Infected Empire into the map.  The AI seedlings don't seem to want to expand to their empty asteroids..

[..]

Sounds like a GOOD THING to me

Greetings from insomniac Tom

[annikk.exe]

Hmm, maybe I can't check values with == GetAsteroid().TreeCap ...

Will try setting treecap with a declared variable tomorrow...

Note to self.

This wouldn't fully explain the behaviour.  When the comet is first sweeping in, seedlings only seem to want to take over player asteroids; not interested at all in colonising their own, empty asteroids.  It is as if when checking for targets the AI doesn't realise their empty asteroids belong to them.  This matches the problems seen in the wider AI engine.


Is the code to send them being run?
Is it being applied to the correct empire?
Is it being applied to the correct checkedroid, and a valid target?
Are the checks for friendly asteroids to jump to being carried out?
Is the normal AI interfering somehow?
Have I made some other random schoolboy error?

Mysterious mysteries of unexplained mystery...

[annikk.exe]

By the way the level is currently 1600 lines and 42kb making it the largest ever level, again :P

[Nightcro]

By the way the level is currently 1600 lines and 42kb making it the largest ever level, again

When will it be realesed
 

[annikk.exe]

This weekend!!  Friday or Saturday at the very latest.  :>
I should warn you though, this first level will have a very simple gravity implementation, with most asteroids static.
I will make another level shortly afterwards with a bit more going on.

I figured out what was causing the problem with the AI.  I had forgotten to Reveal the asteroids to him :>

[annikk.exe]

All functional elements of the new level are working now.  AI Engine and Gravity Engine seems to play nice with one another :>


As the level is almost complete, I will now briefly describe it.

The level places you in a relatively small asteroid field, with a large "Sun" asteroid nearby.  The Sun has a gravity well, and every 7 minutes or so a comet orbits very close to it.  The comet is heavily guarded and not meant to be attacked by the player.

Every time the comet comes past, hundreds of new enemy seedlings jump off, invading the galaxy, creating a serious problem for the player, and decisively changing the balance of power.

The object of the level is to take over the whole galaxy (excluding the Sun and the Comet).  In order to accomplish this, the player must recover swiftly from the previous Comet attack, and then take over the galaxy within 7 minutes before the next attack arrives.


The level will be of Medium difficulty.  This compares with all my previous maps which were Hard or Very Hard difficulty.

Release date is 2010/05/14 - 21:00

[Bonobo]

<salivating> and will you please put in some comment like

Code: [Select]

Tom, you can change THIS HERE if you need to cheat again

[annikk.exe]

Got 4-5 hours of balance testing done.  Going well, but still wild changes in seedling numbers, tree caps, etc... not quite down to small refinements yet.

I added a new feature - the Sun is not currently used by either the player or the AI, it just sits there providing a gravity well for the comet.  So I gave it a new job - now it's Core Energy changes according to how far away the comet is.  At the furthest point of the comet's highly eliptical orbit, the Sun's core energy is about 375....when the comet is orbting right up close to the Sun, the core energy drops all the way to 1.  It's like a distance counter.  :>  This lets the player check how long it will be until the next invasion - so far a method of telling the time has been lacking in all other levels.


Bonobo, the map shouldn't be that hard...hopefully you will be able to win without cheating this time :>

[Smokey]

New Map is cool ! try it !

[annikk.exe]

Level is good to go.  Just need to do the write-up.  On schedule for release at 21:00 as planned.
Smokey is a RL friend and beta tester, by the way...

[kennywalker1q2q3q]

hey annikk what time zone are you in?

[annikk.exe]

GMT :>

[annikk.exe]

I've taken a few days break after the mammoth learning/coding session that was required to build the gravity engine and Fluffy's Comet.
Now I am contemplating where to take things next.
Here are my priorities:

1. Create new gravity map.  Details of this soon
2. Post a tidied-up template of the Gravity engine for others to use in their maps, along with detailed instructions
3. Upgrade the gravity engine to feature collision detection... will do asteroid merging for sure, and possibly asteroid bouncing as well.
4. Big Bang map.



These plans will be hastily postponed if the bug with seedlings trying to plant on a moving asteroid is fixed..and especially if the bug with naming your asteroids is also fixed.  This is so that I can complete the half-finished Sol map.

[annikk.exe]

Incidentally I have a bet on with my cousin that I wouldn't be able to create a gravity engine and simulate the solar system, without resorting to getting planets to move in predefined circles.

So far I have Mercury, Venus, Earth, Luna, Mars, Jupiter, Io and Europa.

Yeah, he's gonna lose that bet.  Heh.

[Nightcro]

Incidentally I have a bet on with my cousin that I wouldn't be able to create a gravity engine and simulate the solar system, without resorting to getting planets to move in predefined circles.

So far I have Mercury, Venus, Earth, Luna, Mars, Jupiter, Io and Europa.

Yeah, he's gonna lose that bet.  Heh.

lol.good for you
how much did he bet ?

[annikk.exe]

No money... instead he will be forced to eat my proverbial hat, which I threw over a gigantic wall at the beginning of April.  :>

[annikk.exe]

Coding for a new level is in progress as of last night.

Similarly to the last, this map will feature the Infected AI Engine, as well as the Gravity Engine.

I intend to make more comprehensive and interesting use of the Gravity Engine for this level.  The map will feature 4 "suns", which are special asteroids that have a gravity well but do not move.  There will also be 2 fully-active asteroids which, when finished, should create interesting gravitational interactions as well as producing entirely symmetrical orbital patterns.  Yes I know that's a bit vague...but I don't want to give it all away just yet.. ;)

It is an extremely fine balancing act, though... the desired orbits are only possible with extremely precise values.  This will take a huge amount of fine-tuning, however as ever I am bloody-mindedly confident that I will eventually crack it.  The rest of the coding will be relatively easy.  The release date for this map depends entirely on how difficult it proves to attain the desired orbits.

[annikk.exe]

Going well now.  3 interactions and 5 suns round the orbital path, which is about 15 minutes worth of gameplay before the comets fly off into space.


The magic number is 0.606709...

[Nightcro]

No money... instead he will be forced to eat my proverbial hat, which I threw over a gigantic wall at the beginning of April.  :>

lol
i hope you will win

[annikk.exe]

Got the 4th interaction working.  Trying for a 5th...

[annikk.exe]

5th interaction almost there...  0.6067096207

[annikk.exe]

5th interaction working good.
Lining things up for a 6th interaction now :>

Hoping to hit 10 interactions by the end of the weekend, possibly a bit ambitious but we'll see how we go.

[annikk.exe]

New gravity map will be released in about 2 weeks time.

[annikk.exe]

0.60670962017185

[annikk.exe]

Created a distance meter, a timer, and an interaction counter to help with the fine tuning...

[annikk.exe]

Following some careful testing with the new orbital debugging tools I created, I have determined that I am either making far far too fine adjustments to have any effect on the 7th interaction, or I have reached the limit of Lua's precision ability at 16 digits.

Pondering my next move...

[annikk.exe]

Well, here's the magic number.


0.606709620171838


That's it.  Found through trial and error.  As accurate as it's possible to be.

[annikk.exe]

So since I can specify with at maximum 15-decimal-place precision the course that the comets will take, I was forced to consider 2 different options to extend the orbital lifetime.

1.  I could make course adjustments each time the interaction counter increments.
2.  I could store the comet gravity variables at one interaction point, then restore them at a subsequent, very similar interaction point.


Both of these methods kind of feel like cheating, but after giving it some thought I have decided to try option 2 first, as it offers the quickest solution.  Hopefully I can make it look good enough that nobody but the most anally anal will notice the tiny jump the comets make in order to have an endless orbit...

If I can't make it look awesome, I will try course adjustments...

[annikk.exe]

Added the rest of the asteroids last night, and introduced a few more key level-specific mechanics.  Unfortunately for some reason it's crashing at the moment, I am not yet sure why.  Troubleshooting shall occur this evening.

Then I will add Infected AI..
Then I will modify it to use the comets..
Then I will fix all the bugs
Then I will balance it
And then it's finished :>

[annikk.exe]

All asteroids are in, all map-specific mechanics are in, Infected AI is in....just bugfixing and balancing to go.  :>

The map is currently 61kb.

[annikk.exe]

At 2600 lines, this new map will be the largest Eufloria level ever made.  Again.

I've been playing it a bit for testing, and it is really fun!  Good to see that element wasn't lost beneath the mountain of pioneering mechanics.. :>


Due to be released this weekend or next.

[annikk.exe]

I am tinkering with the AI engine to optimise it for moving asteroids.  Substantial beta testing will take place tonight.

Inhouse beta testing only.  Sorry would-be beta testers... I will do a public beta for the next map.


I am really proud of how this one is turning out.  I hope that you guys will love it!

[annikk.exe]

AI possibly sorted..

Beta testing in progress.  Wildly unbalanced but the AI just successfully wiped Smokey out, using huge armies carried from distant galaxies...  so that shows the AI works in one scenario, at least... :>

[Nightcro]

Wildly unbalanced but the AI just successfully wiped Smokey out, using huge armies carried from distant galaxies

GJ
Keep going!!

[annikk.exe]

I am now satisfied with the AI's ability to move seeds from galaxy to galaxy, via comets that fly past.

One aspect I am still not happy with is the AI's tendency to immedietely attack a second player asteroid, the moment he has captured the first.  He will not stay and defend his new acquisition even if the player has a huge seedling army there.

The desired behaviour would be for him to play more defensively once he's established a beach-head in a new galaxy.  He need only survive until the next wave of reinforcements arrive.


Some thorough beta testing last night helped to fix a few more bugs, or just aspects of the level that were annoying.