Author Topic: Gravity Engine - dev blog  (Read 11518 times)

0 Members and 1 Guest are viewing this topic.

Bonobo

  • Achiever
  • Old Oak
  • ****
  • Thank You
  • -Given: 79
  • -Receive: 8
  • Posts: 630
  • Was born, still alive.
    • German Mac Mailing Lists
  • Eufloria: Yes
Re: Gravity Engine - dev blog
« Reply #105 on: June 07, 2010, 08:01:58 AM »
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
Google+
Do you play Go? (aka iGo aka Baduk aka Weiqi)

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 1,794
Re: Gravity Engine - dev blog
« Reply #106 on: June 11, 2010, 04:59:33 PM »
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.  :>

Bonobo

  • Achiever
  • Old Oak
  • ****
  • Thank You
  • -Given: 79
  • -Receive: 8
  • Posts: 630
  • Was born, still alive.
    • German Mac Mailing Lists
  • Eufloria: Yes
Re: Gravity Engine - dev blog
« Reply #107 on: June 11, 2010, 10:18:38 PM »
<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
Google+
Do you play Go? (aka iGo aka Baduk aka Weiqi)

Rudolf

  • Administrator
  • Old Oak
  • *****
  • Thank You
  • -Given: 4
  • -Receive: 13
  • Posts: 635
  • Euflorian Ambassador
    • Omni Systems Limited
  • Eufloria: Yes
Re: Gravity Engine - dev blog
« Reply #108 on: June 12, 2010, 04:04:46 PM »
All I can say is that I am happy we made the game moddable :-D
-----------------------------------------------------
Rudolf Kremers - Grand Poobah

http://www.omni-labs.com
http://www.rudolfkremers.com
http://rudolfkremers.tumblr.com/

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 17
  • Posts: 904
  • Eufloria: Yes
Re: Gravity Engine - dev blog
« Reply #109 on: July 03, 2010, 08:13:08 PM »
Had a problem with unstable asteroids.

If you change the size of an asteroid, you get the same sort of problem as with moving asteroids. See this post for more details, particularly the picture.


Jazz Ad

  • Sapling
  • **
  • Thank You
  • -Given: 0
  • -Receive: 2
  • Posts: 52
Re: Gravity Engine - dev blog
« Reply #110 on: July 13, 2010, 12:51:55 AM »
Next thing you know we'll have Eufloria and Osmos witihn the same game.

Jeheace

  • Seedling
  • **
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 32
    • Jeheace's Art
Re: Gravity Engine - dev blog
« Reply #111 on: August 05, 2010, 07:52:26 AM »
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...