Euflorium: The Eufloria Community
Eufloria => Eufloria Classic => Eufloria Classic Mods => Topic started by: annikk.exe on March 22, 2010, 04:37:26 PM
-
This functionality exists now. Anyone going to code a level that uses it? :>
I am still knee-deep in my AI map and I've been sidetracked for the last 2-3 days with Minecraft... so if someone wants to pip me to the first moving-roid map, now would be the time :>
Incidentally, my plans are no less than to build a functioning gravity system..
-
Incidentally, my plans are no less than to build a functioning gravity system..
0_0
-
No really! It's not that hard...
First you check each asteroid once per game cycle, and perform calculations based on its size and distance of all the other asteroids in the map, and their sizes, and that will give you all the forces acting upon that asteroid.
Then you create variables for the angle the asteroid is travelling and its current momentum.
By calculating what effect the net gravitational forces are having on the asteroid, you can calculate (for each game cycle) the changes to its angle and momentum, and then move it in that direction by however much the momentum value dictates.
That's the engine of the gravity system. To create an actual solar system, you would need to create all the asteroids in LevelSetup() and give them just the right initial angle and momentum to cause them to orbit whatever body they are nearest.
By coding it with a proper gravity engine and not just a bunch of fixed asteroids with given properties, the whole thing will be highly adaptable and re-usable, and I will be able to create some really stunning features like asteroids that fly off their orbit into space, binary star systems, etc. By adding an asteroid density variable into the gravity engine I could also potentially create black holes...
-
As a bit of fore-warning, asteroids won't move out of the world space, which is divided up into a quad tree. The tree's size depends on what exists in the level post-setup, so you might need to create some asteroids initially way out in the wilderness just to encourage the game to make a big world for you.
-
Alex, thanks for the information - I will keep that in mind!
(hmm.. what is a quad tree..?)
What is the maximum size of the game area, by the way? Seems to be +/- 20,000 or so on each axis?
-
Don't know off-hand - try massive numbers and see what happens!
-
This is an indescribably awesome concept. The basic game has given me endless hours of fun (to say nothing of the game as it existed previously, and the levels created in the old format) but a level that simulated real gravity? You'll be a legend for all time ^^
-
Do a Barnes-Hut gravity implementation and you'll also get to learn about quad trees. :)
https://agora.cs.illinois.edu/display/transformation/Barnes-Hut+N-Body+Simulation
-
That was quite an interesting read. It mentions an OcTree though, not a Quad Tree. I am pretty sure they are different things..
-
An octtree is like a quadtree but in 3D. So instead of squares split into 4 squares, you have cubes split into 8 cubes.
-
Ah! I see. That makes sense. I suppose you would need a way to split up the space...
So, how does that work with placing asteroids far away?
If you put one at (10000,0) and another at (0,10000) does that mean the entire area with corners (0,0) (10000,0) (0,10000) (10000,10000) is ok for asteroids to move around in?
But if I were to try to move an asteroid to, say, (-2000,-2000) this would not work?
-
I'd have to look at the code - the likelihood is you'd get an area of... 2^15 so about -16k to +16k in each direction. Something like that.
-
Hmmm, not sure I understand where you are getting those figures from..
Oh well, I will have a play about with it soon and hopefully all will become clear. :>
-
The quad tree works with powers of two, so that each successive finer layer in the hierarchy works with squares half the size of the one above - so the eventual size of the entire tree is governed by powers of two, and the game makes a quad tree that's big enough to fit the whole level inside it. If it's bigger than say 4096 (2^12) units (e.g. you have an asteroid at (2050, 2050) and one at (-2050,-2050)), then we have to go up one to 8192 units, and the world boundaries become (-4096, -4096) to (4096,4096). I *think* that's how it works but I will have to confirm it.
-
Ah right! Awesome. :>
Does the quad tree always extend outwards from the origin? Or does it extend outwards from the center of the asteroids on each level?
heh, so many questions.. :P
-
I think it's extending from the origin. I'll have a look, I... I just don't know.
-
Interesting, that has some implications for the placement of asteroids in level design. For example, in Return To Fluffy Land the first asteroid is at (0,0) and the last asteroid is way way down in the southeast - the other asteroids extend in a curvy line between these two points. But if the quad tree always extends outwards from the origin, I could potentially have made the game use 1 size smaller of quad tree by placing the asteroids around the origin instead of starting there and working outwards in one direction. That might mean the game runs faster on slow machines.. :>
Also, it means that by placing asteroids around the origin you can have a great area in which asteroids are allowed to be placed, rather than only using a single quadrant like in RTFL.