The Barnes-Hut algorithm is the way to go with this one. It's been used in supercomputer simulations to solve your exact problem. It's not too hard to code, and it's very efficient. I actually wrote a Java applet not too long ago to solve this problem.

Visit http://www.neurofuzzydev.com/Utilities/nbodyapplet.php and press "start" and "show quadtree".

In the options tab, you can see that the particle count can go all the way up to 200,000. On my computer, the calculation finishes in about 2 seconds (the drawing of 200,000 dots takes about 1 second, but the calculation runs on a separate thread).

Here's how my applet works:

1. Create a list of random particles, with random masses, positions, and starting velocities.
2. Construct a quadtree from these particles. Each quadtree node contains the center of mass of each subnode. Basically, for each node you have three values: massx, massy, and mass. Every time you add a particle to a given node, you increase massx and massy by particle.xparticle.mass and particle.yparticle.mass respectively. The position (massx/mass, massy/mass) will end up as the node's center of mass.
3. For each particle, calculate the forces (fully described here). This is done by starting at the top node and recursing through each subnode of the quadtree until the given subnode is small enough. Once you stop recursing, you can calculate the distance from the particle to the node's center of mass, and then you can calculate the force using the node's mass and the particle's mass.

Your game should easily be able to handle a thousand mutually attracting objects. If each object is "dumb" (like the bare-bones particles in my applet), you should be able to get 8000 to 9000 particles, maybe more. And this is assuming single-threading. With multi-threaded or parallel computing applications, you can get many more particles than that updating in real time.

The Barnes-Hut algorithm is the way to go with this one. It's been used in supercomputer simulations to solve your exact problem. It's not too hard to code, and it's very efficient. I actually wrote a Java applet not too long ago to solve this problem.

Visit http://mathandcode.com/programs/javagrav/ and press "start" and "show quadtree".

In the options tab, you can see that the particle count can go all the way up to 200,000. On my computer, the calculation finishes in about 2 seconds (the drawing of 200,000 dots takes about 1 second, but the calculation runs on a separate thread).

Here's how my applet works:

1. Create a list of random particles, with random masses, positions, and starting velocities.
2. Construct a quadtree from these particles. Each quadtree node contains the center of mass of each subnode. Basically, for each node you have three values: massx, massy, and mass. Every time you add a particle to a given node, you increase massx and massy by particle.xparticle.mass and particle.yparticle.mass respectively. The position (massx/mass, massy/mass) will end up as the node's center of mass.
3. For each particle, calculate the forces (fully described here). This is done by starting at the top node and recursing through each subnode of the quadtree until the given subnode is small enough. Once you stop recursing, you can calculate the distance from the particle to the node's center of mass, and then you can calculate the force using the node's mass and the particle's mass.

Your game should easily be able to handle a thousand mutually attracting objects. If each object is "dumb" (like the bare-bones particles in my applet), you should be able to get 8000 to 9000 particles, maybe more. And this is assuming single-threading. With multi-threaded or parallel computing applications, you can get many more particles than that updating in real time.

See also: http://www.youtube.com/watch?v=XAlzniN6L94 for a large rendering of this

The Barnes-Hut algorithm is the way to go with this one. It's been used in supercomputer simulations to solve your exact problem. It's not too hard to code, and it's very efficient. I actually wrote a java applet not too long ago to solve this problem.

Visit: http://www.neurofuzzydev.com/Utilities/nbodyapplet.php

  and press "start" and "show quadtree".

in the options tab, you can see that the particle count can go all the way up to 200,000. On my computer, the calculation finishes in about 2 seconds (the drawing of 200,000 dots takes about 1 second, but the calculation runs on a separate thread).

Here's how my applet works:

1. Create a list of random particles, with random masses, positions, and starting velocities.
2. Construct a quadtree from these particles, Each quadtree node contains the center of mass of each subnode. Basically, for each node you have three values: massx, massy, and mass. Every time you add a particle to a given node, you increase massx and massy by particle.xparticle.mass and particle.yparticle.mass respectively. The position (massx/mass,massy/mass) will end up as the node's center of mass.
3. FOR EACH particle, calculate the forces. (described fully here) This is done by starting at the top node and recursing through each subnode of the quadtree until the given subnode is small enough. Once you stop recursing, you can calculate the distance from the particle to the node's center of mass, and then you can calculate the force using the node's mass and the particle's mass.

Your game should easily be able to handle a thousand mutually attracting objects. If each object is "dumb" (like the bare-bones particles in my applet), you should be able to get 8000 to 9000 particles, maybe more. (and this is assuming single-threading. With multi-threaded or parallel computing applications, you can get many more particles than that updating in real time)

The Barnes-Hut algorithm is the way to go with this one. It's been used in supercomputer simulations to solve your exact problem. It's not too hard to code, and it's very efficient. I actually wrote a Java applet not too long ago to solve this problem.

Visit  http://www.neurofuzzydev.com/Utilities/nbodyapplet.php and press "start" and "show quadtree".

In the options tab, you can see that the particle count can go all the way up to 200,000. On my computer, the calculation finishes in about 2 seconds (the drawing of 200,000 dots takes about 1 second, but the calculation runs on a separate thread).

Here's how my applet works:

1. Create a list of random particles, with random masses, positions, and starting velocities.
2. Construct a quadtree from these particles. Each quadtree node contains the center of mass of each subnode. Basically, for each node you have three values: massx, massy, and mass. Every time you add a particle to a given node, you increase massx and massy by particle.xparticle.mass and particle.yparticle.mass respectively. The position (massx/mass, massy/mass) will end up as the node's center of mass.
3. For each particle, calculate the forces (fully described here). This is done by starting at the top node and recursing through each subnode of the quadtree until the given subnode is small enough. Once you stop recursing, you can calculate the distance from the particle to the node's center of mass, and then you can calculate the force using the node's mass and the particle's mass.

Your game should easily be able to handle a thousand mutually attracting objects. If each object is "dumb" (like the bare-bones particles in my applet), you should be able to get 8000 to 9000 particles, maybe more. And this is assuming single-threading. With multi-threaded or parallel computing applications, you can get many more particles than that updating in real time.