man I wonder if you could somehow "zoom-out" on the view and allow for multiple galactic collisions.

Thanks for the positive feedback. Yes, it does feel a little cramped with one galaxy taking up most of the screen. With the way the simulation is currently configured it seems that there needs to be a critical number of stars rotating around that central hub for the galaxy to have any coherence. Bit busy right now but when I get a chance I'll have a play with scale and see what two smaller galaxies might look like.

I'm really hoping Apple brings out this tablet and an SDK for it. Plenty of screen space and processing power for multiple galaxies. Of course iPhone/iPod remains the primary focus.

I mean considering it's on the iphone (480x320) you did a dang good job actually! Give yourself mad kudos! I'm not complaining about that at all.

Actually you know what, don't even worry about scale, that could just be a bonus feature. Do something where if you tilt the phone up/down/left or right it just 'scrolls' the view around. That seems pretty easy to do right? instead of the stars bouncing off the walls make them bounce off a border that is determined by the user.. or just do like a small(screen size), medium just enough to scroll around a bit, and a large (really huge boundaries)

Heck, even make it a seperate "pro" version of your current app for like 4.99. I'd gladly pay a few dollars if you had something like that.

once again, great job!

It's the area described by the borders rather than the size of the view that presents the problem. To give you a little insight into what's going on - In order to avoid having to explicitly calculate the gravitational interactions between each and every star I divide the space up into a hierarchy of cells and dynamically allot stars to cells. Too many cells and the app slows to a crawl, too few or the same number stretched over a larger area and the calculation resolution drops to the point where the galaxy degenerates into a boiling mass in a few seconds rather than a few minutes. On the PC version I used an adaptive hierarchy which put cells where they are needed but on the iPhone/iPod I avoided the programming/processing overhead and just put a fixed hierarchy in place.

As a result of this discussion I did try stretching the borders a bit with and without adding more cells but it looks like I found the sweet spot first time round. The results weren't really what I would want to trouble people with an update for. Its been helpful for me though. I've found at least that I can increase the number of cells quite a bit for apps like Gloop (which doesn't involve long range interaction) without affecting performance greatly. Not useful for Gloop but good to know for when I do some 3D apps where I can't mask the simplicity of the system with the confines of the screen,

It is a little annoying having stars bounce back and interfere with the natural evolution of the galaxy but there aren't so many to go around that I can just let them run off either

Good points indeed.

That's neat to hear about how that was implemented with the cells. I understand a bit b/c I did a simulation of gravity and interaction of bodies in flash a couple years ago and just adding more than 100 or so objects to the system made the whole computer (even a quad core!!) slow to a crawl. Amazing how inefficient it becomes... so yeh I agree to keep the 'sweet spot' like you said. Good call there as the developer.