Euflorium: The Eufloria Community

Eufloria => Eufloria Classic => Eufloria Classic Mods => Topic started by: annikk.exe on April 07, 2010, 01:49:30 AM

Title: Gravity Engine - dev blog
Post by: annikk.exe on April 07, 2010, 01:49:30 AM
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.  :>
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 07, 2010, 02:17:59 AM
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.




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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 07, 2010, 02:18:49 AM
It occurs to me I should really check out the Asteroid move functionality to see what it's like...  but eh... SCIENCE!!!
Title: Re: Gravity Engine - dev blog
Post by: njursten on April 07, 2010, 05:16:56 AM
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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 07, 2010, 06:38:12 AM
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.. :>
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 07, 2010, 04:34:45 PM
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? :>
Title: Re: Gravity Engine - dev blog
Post by: njursten on April 09, 2010, 04:45:29 AM
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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 09, 2010, 08:14:55 PM
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 :P


Actual coding hasn't begun yet, by the way.  It's all planning and contemplation at the moment.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 10, 2010, 07:47:36 AM
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?
Title: Re: Gravity Engine - dev blog
Post by: njursten on April 11, 2010, 08:25:00 PM
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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 20, 2010, 06:51:34 PM
Quote from: njursten on April 09, 2010, 04:45:29 AM
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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 21, 2010, 03:35:22 AM
I am probably still wrong though.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 21, 2010, 06:33:07 AM
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 :>
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 21, 2010, 08:05:00 AM
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... :>
Title: Re: Gravity Engine - dev blog
Post by: njursten on April 22, 2010, 05:15:58 AM
Quote from: annikk.exe on April 20, 2010, 06:51:34 PM
Quote from: njursten on April 09, 2010, 04:45:29 AM
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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 22, 2010, 06:26:34 AM
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).


(http://img163.imageshack.us/img163/1286/fluffysmatrices.png)

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.  :>
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 22, 2010, 06:30:06 AM
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.
Title: Re: Gravity Engine - dev blog
Post by: njursten on April 23, 2010, 05:51:48 AM
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?
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 23, 2010, 10:44:22 PM
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...  :>
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 23, 2010, 10:44:47 PM
By the way, regarding this:

Quote
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.  :>
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 24, 2010, 02:16:53 AM
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?
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 24, 2010, 02:32:06 AM
aaaaaand that's a negative.  It runs once.

for test = 0,-1 do runs zero times.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 24, 2010, 02:49:54 AM
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
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 24, 2010, 02:59:19 AM
Quote from: njursten on April 07, 2010, 05:16:56 AM
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
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 24, 2010, 06:31:31 AM
Started coding.  Got a brand new error that I've never seen before!  :>


(http://img14.imageshack.us/img14/6830/errorofdoom.png)
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 24, 2010, 07:13:40 AM
Am having difficulty with the part where I need to calculate seperation distance between asteroids based on their coordinates.  Need moar maths..
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 24, 2010, 08:18:20 AM
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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 24, 2010, 08:17:33 PM
Question for Njursten;  how is xdiff and ydiff calculated?
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 24, 2010, 09:04:27 PM
Sweet!!  Got it working! :D


edit... wait, nope.. :p
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 24, 2010, 09:27:43 PM
ok... seems to be working now.  Got 2 asteroids orbiting one another.  :>
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 24, 2010, 09:37:44 PM
Building trees on both asteroids, sending seeds between them while they orbit each other...

this is pretty magical... :>
<3
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 24, 2010, 09:40:21 PM
Ah screw it, have a test level.  :>

I included some instructions in the comments in case anyone wants to try changing the initial conditions :>
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 24, 2010, 10:01:21 PM
haha, flowers are so funny in this :p
Title: Re: Gravity Engine - dev blog
Post by: AWS on April 24, 2010, 11:27:07 PM
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....
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 25, 2010, 01:26:36 AM
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)




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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 25, 2010, 01:57:16 AM
Update to gravity engine to fix density bug:


Find code:
(click to show/hide)


Replace with:
(click to show/hide)
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 25, 2010, 01:58:10 AM
This will probably break the test level, heh.  :P
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 25, 2010, 08:28:59 AM
Got Mercury, Venus and Earth orbiting the Sun now..  and Luna orbiting Earth ^_^
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 25, 2010, 09:15:32 AM
Now if only I could name asteroids....
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 25, 2010, 10:45:27 AM
Added mars...

crashing for tonight, I think.  :>
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on April 27, 2010, 02:29:28 AM
Progress on this particular map has now plateu'd, due to problems with the maximim map size.
Hoping for some answers in this thread (http://www.dyson-game.com/smf/index.php?topic=802.0)..
Title: Re: Gravity Engine - dev blog
Post by: AWS on May 02, 2010, 09:29:34 AM
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!  ;D

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

otherwise, anything further to report annikk?

AWS
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 02, 2010, 11:15:35 AM
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... ;)
Title: Re: Gravity Engine - dev blog
Post by: Mihhaelo on May 02, 2010, 11:57:55 PM
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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 03, 2010, 07:40:50 PM
Wondering what Globals.Agents.BomVolume  (int) does...
Title: Re: Gravity Engine - dev blog
Post by: Alex on May 04, 2010, 06:34:36 AM
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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 04, 2010, 09:19:22 AM
Sweet :>  Thanks Alex!  ::heroworship::
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 04, 2010, 06:07:29 PM
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.
Title: Re: Gravity Engine - dev blog
Post by: Alex on May 04, 2010, 10:36:11 PM
Haha I wonder if one day we'll be able to recreate Osmos in Eufloria :D
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 04, 2010, 11:44:56 PM
That would definitely be possible, using very similar code as outlined above.. :>
Title: Re: Gravity Engine - dev blog
Post by: AWS on May 05, 2010, 07:00:55 AM
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?! :o
Title: Re: Gravity Engine - dev blog
Post by: Bonobo on May 05, 2010, 07:56:10 AM
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.
Title: Re: Gravity Engine - dev blog
Post by: Harsha on May 06, 2010, 11:00:20 PM
Quote from: AWS on May 05, 2010, 07:00:55 AM
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?! :o

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??  ;)
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 06, 2010, 11:38:46 PM
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!
Title: Re: Gravity Engine - dev blog
Post by: Sniped50 on May 07, 2010, 01:42:36 AM
Quote from: annikk.exe on May 04, 2010, 06:07:29 PM
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.  ;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:

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!  :)
Title: Re: Gravity Engine - dev blog
Post by: AWS on May 07, 2010, 05:12:01 AM
Quote from: annikk.exe on May 06, 2010, 11:38:46 PM
  In my view this approach results in a shortfall of awesomeness.

a decline in awesomness is not desired! awesomeness is necessary, carry on...
 8)
Title: Re: Gravity Engine - dev blog
Post by: Harsha on May 07, 2010, 05:32:28 PM
Quote from: annikk.exe on May 06, 2010, 11:38:46 PM

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??  :-\
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 07, 2010, 05:51:28 PM
Quote from: Sniped50 on May 07, 2010, 01:42:36 AM
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!


Quote
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



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



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



Quote
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


Quote
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.. :>
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 07, 2010, 06:07:40 PM
Quote from: Harsha on May 07, 2010, 05:32:28 PM
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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 10, 2010, 06:46:15 PM
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 ::
Title: Re: Gravity Engine - dev blog
Post by: Alex on May 10, 2010, 08:27:54 PM
What I'll probably do is when an asteroid is moved, the seedlings will move by the same amount.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 10, 2010, 08:30:02 PM
That'd do it.. :>  That is their behaviour when orbiting, so that should look and function perfectly :D
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 11, 2010, 09:19:22 AM
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)
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 11, 2010, 09:28:10 AM
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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 12, 2010, 08:32:41 AM
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...
Title: Re: Gravity Engine - dev blog
Post by: Bonobo on May 12, 2010, 09:11:15 AM
Quote from: annikk.exe on May 12, 2010, 08:32:41 AM
[..]

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 ;D

Greetings from insomniac Tom
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 12, 2010, 05:23:43 PM
Quote from: annikk.exe on May 12, 2010, 08:32:41 AM
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...
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 12, 2010, 05:40:54 PM
By the way the level is currently 1600 lines and 42kb making it the largest ever level, again :P
Title: Re: Gravity Engine - dev blog
Post by: Nightcro on May 13, 2010, 01:19:41 AM
Quote from: annikk.exe on May 12, 2010, 05:40:54 PM
By the way the level is currently 1600 lines and 42kb making it the largest ever level, again :P
When will it be realesed ????????????
 :o
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 13, 2010, 03:00:14 AM
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 :>
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 13, 2010, 04:15:42 AM
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
Title: Re: Gravity Engine - dev blog
Post by: Bonobo on May 13, 2010, 07:15:07 AM
<salivating> and will you please put in some comment like
Code: [Select]
Tom, you can change THIS HERE if you need to cheat again;D
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 13, 2010, 10:27:50 AM
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 :>
Title: Re: Gravity Engine - dev blog
Post by: Smokey on May 14, 2010, 03:04:38 AM
New Map is cool ! try it !
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 14, 2010, 08:50:37 AM
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...
Title: Re: Gravity Engine - dev blog
Post by: kennywalker1q2q3q on May 15, 2010, 06:20:04 AM
hey annikk what time zone are you in? ;D

Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 15, 2010, 07:26:16 AM
GMT :>
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 18, 2010, 07:46:21 PM
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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 18, 2010, 08:05:06 PM
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.
Title: Re: Gravity Engine - dev blog
Post by: Nightcro on May 19, 2010, 02:48:47 AM
Quote from: annikk.exe on May 18, 2010, 08:05:06 PM
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 ? ;D
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 19, 2010, 04:24:10 AM
No money... instead he will be forced to eat my proverbial hat, which I threw over a gigantic wall at the beginning of April.  :>
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 20, 2010, 12:35:29 AM
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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 20, 2010, 04:27:26 AM
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...
Title: Re: Gravity Engine - dev blog
Post by: Nightcro on May 20, 2010, 08:04:57 PM
Quote from: annikk.exe on May 19, 2010, 04:24:10 AM
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
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 20, 2010, 08:27:35 PM
Got the 4th interaction working.  Trying for a 5th...
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 20, 2010, 11:27:52 PM
5th interaction almost there...  0.6067096207
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 21, 2010, 06:45:00 PM
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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 21, 2010, 07:04:45 PM
New gravity map will be released in about 2 weeks time.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 22, 2010, 08:29:51 PM
0.60670962017185
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 23, 2010, 09:04:33 PM
Created a distance meter, a timer, and an interaction counter to help with the fine tuning...
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 24, 2010, 03:54:19 AM
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...
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 24, 2010, 05:08:13 AM
Well, here's the magic number.


0.606709620171838


That's it.  Found through trial and error.  As accurate as it's possible to be.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 24, 2010, 05:56:28 AM
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...
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 24, 2010, 06:06:13 PM
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 :>
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 25, 2010, 09:16:02 AM
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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 26, 2010, 10:15:56 PM
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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 27, 2010, 02:10:17 AM
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!
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 27, 2010, 06:49:45 AM
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... :>
Title: Re: Gravity Engine - dev blog
Post by: Nightcro on May 28, 2010, 07:13:24 PM
Quote from: annikk.exe on May 27, 2010, 06:49:45 AM
Wildly unbalanced but the AI just successfully wiped Smokey out, using huge armies carried from distant galaxies
;D
GJ
Keep going!!
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 28, 2010, 08:34:44 PM
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.
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 29, 2010, 08:23:07 PM
Much more AI-tinkering last night.  Now displaying Correct Behaviour™  :>
It's so close to being finished!
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 30, 2010, 05:58:19 AM
All the mechanics - AI included - work perfectly now.
We're doing final balancing and beta testing now, I am working closely with Smokey on this map - he has been beta testing like crazy and we have discussed the balancing of the map at length.  As I type this, he's playing the latest rebalance of the level.

Going to aim for a Medium-Hard sort of level of difficulty.  Level will be released very soon, tonight or tomorrow!
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 31, 2010, 01:59:26 AM
So, now it's released and the first dozen or so people are playing it.

I am very tired.  I also have been neglecting my various other creative projects for a while now, and I'm about to move house...
In short, it will probably be at least a couple of months before I start work on a new map.  It would take something pretty impressive to top this one, at any rate..

Also I thought I would share with you guys, the original concept drawing for Infinity, which I sketched out late one night in MS Paint.  :>


(http://img412.imageshack.us/img412/9030/originalconcept.png)
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on May 31, 2010, 02:03:12 AM
Also here is an extract from a log I kept whilst fine tuning the orbital path of the comets:

Quote
594 minimum on interaction 4 at 630 sec

it was about 240 on the wrong side.  i increased the density from 75 to 95


reduced it by 2


it was close, but didn't curve round far enough.


increased it by 3... now it's 966, up from 963.


that time it flung it too far round.

was 966, now 9659


that time it was _just_ on the wrong side


uhh..... ok, guess i'll try 9659 again

no change, new variable works good.

trying 96595


no big change.
need to try something drastic to get an idea which direction to push in.

i will try 96610


badly wrong direction.

trying drastic in the opposite direction then.  96580


no big change.  trying 96570


still no big change...weak....  trying 96550


STILL no big change... they might be a bit closer together though.
Trying 96350

oooh!! That made them collide!

Just a bit more...  trying 96330

Getting there now.  Need a little bit more tho.
Trying 96270

looking very good now.  but it's still a bit too much.
trying 96220


right, that was good.  4th interaction WORKS!!
after 2 more suns, the asteroid goes spinning up to the north-east asteroid instead of heading to the middle.
i have thought about it and reducing it further should fix this.  however, the increments must become small now.

trying 96210

ok that time they went more diagonal instead of straight up, so we are going in the right direction :>
maybe try reducing by roughly the same amount again...
so.... trying 96195

uh... i reduced it too much, i think...
trying 96205

still too much.  trying 96201

They collided!
Still too much.  96199?

Nope.  96198?

wrong side now.

trying 96208

correct side, but still far from each other.

trying 96207

still quite far from each other.  699 distance away

trying 96206

like 560 that time.  they got closer!

trying 96204

they got even closer that time, it seems.  started bending more.

trying 96203

ok they were only 100 or so away from each other that time!

962025

nope, needs to bend further.

96202

dude!! almost there!!!

trying 962015

looking good, that's a successful 5th interaction.  good job druids!
it comet is going the wrong way around sun #2 after the transitition, lowering a bit more to curve it around
trying 962005

that was too far - try 962014 next


they basically bounced off each other that time
14 is still bringing them too close together
so gonna try 149

trying 9620149


wrong!"!!! seedingn n00b druid

trying 96201495


trying 1520


stupid druid!!

trying 1510


nope, still landing on the wrong side of sun #2

trying 1503


ok i think i have been going in the wrong direction
now i will try 96201600


yeah i was indeed going in the wrong direction.  gradually increase the density to
bring the comets closer and closer to the first sun's corona

trying 96201675


that was good - first time with 5th interaction 2nd sun correct side!!

need to increase it slightly more
trying 96201705


today i will try 96201725

that seemed to work pretty good... but watch this one again when i wake up.
i'm not too sure whether need to increase or decrease at this point...too tired

ok.  it's morning now.  i have watched the interaction.
it sends it successfully around both suns, and into a 6th interaction!  This is
great news.  Good job druids.

Now I should set Fish Time to 1150.  that should wake me up just before the 2nd sun
prior to interaction 6.

Now, as to the value.  That time, they were slightly on the wrong side of each other
96201725 = slightly wrong side
lets try 96201721 and see if decreasing it slightly works well.

ok, that time they collided!  so that's going in the right direction, it seems.

Trying 96201713

ok, that was on the right side...but they didn't pass close enough to each other.
So I've gone a little too far.

Trying 96201717

they were close to each other that time... but need to be very slightly closer..

Trying 962017185

that produced a successful interaction.  watching the orbits...
ok it flung them a bit hard
they came a bit too close together i think

yeah

Eh, we need a new convention.
17185 before

they were being flung too hard, not getting close enough.
So i need the suns to make them cling closer, to prise them slightly further
apart during the interaction.  so i'll increase to 17188

still flings them rather hard.  lets see... yeah... he goes WAY round the first sun
he's not coming back anytime soon.

um, it's this counter-intuitive thing again... i need to decrease it
isntead of increasing it...

lets try 17182

this time they come a bit too close to the sun...
going straight through the middle of the corona, very close...
ok so i took it a bit too far.

try 171835


this curve looks more like it :>
went round the first sun nicely.  lets see how it lands on the second...

that makes it go all the way around, but they are comets fly on the wrong side
of one another on the next interaction.

lets try decreasing the value very carefully

try 171833

they were still on the wrong side from one another.  782 from the center at y = 0

trying 171838

woah.  OK.  that time they practically collided.  increasing seems the way forward !
still on the wrong side, sligthyl...
uh... setting a new fish timer of 1200
lets try 1718385


they were on the wrong side of each other by about 248


lets 1718405

that time they were over 2000 apart!
but on the right side, i think...
so lets try a much smaller increase...

1718388

ok, they were like 150 on the wrong side.

trying 1718394


ok...that time the interaction BEFORE didnt work... :S
they seemed to come on the right side, but far far too close
trying 1718388 again, just to confirm they have a successful first
interaction and come 150 on the wrong side on the second one


ok...yeah...it worked as described before.  hmmmmm....

guess i will try 1718389

that time it was 209 on the RIGHT side...

trying 17183887

was a little way on the wrong side

17183889

they pass close to each other on the right side, but not close enough...

171838885


they got within 206 of each other, in the right side...


ok, so seems like im reducing too slowly.

trying 171838865

that time they were wrong side

ok...
17183879

wrong side, by like 50...

171838881


that time they were on the right side, by like...tons...

so ah... 1718387925


wrong side, by about 50... >.<

171838798

wrong side, by bugger all, again.

giving up for tonight.



read over notes.  trying 171838883
also added interaction counter
proved game pausing doesnt affect asteroid orbits

interaction 5 works
interaction 6 seems to work..
interaction 7 fails - they are on the correct side but a bit too far
apart

ok, now should be easier to troubleshoot :>  try some new values when i
get back and lets see how we can steer it at interaction 7...


trying 171838888

interaction 6 works fine...
interaction 7

they were on the right side of each other, but 206 apart

need to find the distance after a change

trying 171838898

i have increased it by 10 basically
looking to see whether they are further apart than 206 this time
to figure out which direction to change in


....ok, that time they were 206 apart as well :/

trying 1718389

maybe i can get 1 more interaction to work...

correct side, 206 away...AGAIN

trying 171839

that causes them to be wildly too far apart, on the right side though.

so im guessing if i try 171837, which is the other side of the "most accurate
so far", it's going to be too much on the other side.

ok i haven't actually tried 171837
i guess i should try it, just to see what happens
this appears to be the very limit of the accuracy possible
good job all druids who participated in this project
we're at the end now.  lets confirm it.


Yes, I was going a bit crazy at the time.  :P
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on June 07, 2010, 10:23:35 AM
Had an idea for a new level.
Title: Re: Gravity Engine - dev blog
Post by: Bonobo on June 07, 2010, 04:01:58 PM
Annik, you never stop to amaze me (amaze us, I guess). And I believe you will always have new ideas for levels and whatever else. Just take care of yourself, get your household moved well and eat and sleep and talk some to your folks, will you? And then, I think, we all will happily await what comes next from you.

Best wishes, Tom
Title: Re: Gravity Engine - dev blog
Post by: annikk.exe on June 12, 2010, 12:59:33 AM
Well needless to say I am abandoning the idea I had a few days ago, as it was another idea bound by the constraints of not being able to build trees on moving asteroids.

Now that planting bug on moving asteroids has been fixed, my intention is to go straight for the most ambitious map of all - a fully procedural "big bang" style map.
It will be called "Big Bang", not "Fluffy's Big Bang", by the way :P

So I was just gonna lay out my intention for what this map will be like.



At the very start, there are no seedlings and no trees.  There are only tiny little space rocks - hundreds of them - all starting in a random location around the centre, and moving in a random direction at a random speed.

All of these will have their own individual gravitational fields, and all of them will move and be affected by gravity.

For the first 30 seconds or so, they will fly around bumping into each other.  When they touch, the two asteroids become one - they "snap together", sort of like two raindrops progressing down a car windscreen snap together when they come close enough.
The snapping effect will have an effect on their momentum.
The treecap and send distance for each asteroid are dynamically adjusted according to their current size.  The tiny initial rocks will be considered comets, and will have a treecap of 0.

After 30 seconds, this "snap together" behaviour will cease, and when they touch, they will instead bounce off each other.  The bouncing will be such that the asteroids cannot "settle" against one another, they should always bounce clear.

An asteroid that bounces off another asteroid loses one tree and a percentage of any seedlings orbiting it.

At 30 seconds of game time, a series of friendly and enemy seedlings are added.

The enemy seedlings will be - out of necessity, I suspect - controlled by the Infected AI engine, which I may or may not overhaul as part of the project.  The reason why I think it will be necessary to use the Infected engine is that I believe the original AI is not capable of recalculating traversable paths in a dynamic way during Function LevelLogic() While loops, therefore moving asteroids would completely confuse it.  I might be wrong about this... would need to do some testing.

The game then proceeds.  The player must traverse the procedurally generated galaxy, finding a way to reach all asteroids, and destroying the enemy empire wherever they lurk.  If the player owns all of the non-comet asteroids in the galaxy, they win.  If they own no asteroids, they lose.


In this way, every time you play the game, a brand new, procedurally generated universe is created, with all the asteroids in it moving and orbiting around each other in interesting ways.

This should hopefully provide a lot of replayability, and hopefully a lot of campfire-style stories about galaxy arms colliding and massive carnage will be the result... :>




However, I am currently moving house.  This massive level design project will therefore take considerable time to get underway, but I will be sure to post again when coding begins.  :>
Title: Re: Gravity Engine - dev blog
Post by: Bonobo on June 12, 2010, 06:18:38 AM
<speechless>

[..]

[..]

[..] and now, after recapturing a few vowels and consonants, I just want to wish you a good move and good luck with all. You’ve certainly got us all drooling for any news from annikk.exe.

Take care, Tom
Title: Re: Gravity Engine - dev blog
Post by: Rudolf on June 13, 2010, 12:04:46 AM
All I can say is that I am happy we made the game moddable :-D
Title: Re: Gravity Engine - dev blog
Post by: Pilchard123 on July 04, 2010, 04:13:08 AM
Had a problem with unstable asteroids (http://www.dyson-game.com/smf/index.php?topic=846.0).

If you change the size of an asteroid, you get the same sort of problem as with moving asteroids. See this post (http://www.dyson-game.com/smf/index.php?topic=774.msg5235#msg5235) for more details, particularly the picture.

Title: Re: Gravity Engine - dev blog
Post by: Jazz Ad on July 13, 2010, 08:51:55 AM
Next thing you know we'll have Eufloria and Osmos witihn the same game.
Title: Re: Gravity Engine - dev blog
Post by: Jeheace on August 05, 2010, 03:52:26 PM
Hey annikk.exe...

If you change the G at the beginning of your gravity equation to -G,

Fgx = (G * ((roidradius * roidradius) * math.pi * density) * ((roidradius[j] * roidradius[j]) * math.pi * density[j]))
Fgy = (G * ((roidradius * roidradius) * math.pi * density) * ((roidradius[j] * roidradius[j]) * math.pi * density[j]))

to

Fgx = (-G * ((roidradius * roidradius) * math.pi * density) * ((roidradius[j] * roidradius[j]) * math.pi * density[j]))
Fgy = (-G * ((roidradius * roidradius) * math.pi * density) * ((roidradius[j] * roidradius[j]) * math.pi * density[j]))

you get anti-graveity (though this can't co-exist with the regular G equation at the same time)

Now, I saw that you were gonna start all of the roids in random locations... but what if you started them all at the center with the anti-g set first and set HIGH, and then switched the -G to G after a few seconds, turned G down to normal, and THEN activated the code that tells them to merge on contact...

Either they'll all stay in one spot, or fly to ends of the world...

But then again, this could be an idea for a different level... or just not possible...