Calling all Suggestions

What did you draw?
Locked
branney
Posts: 4
Joined: Sat Sep 21, 2013 3:22 pm

Re: Calling all Suggestions

Post by branney »

i am taking osmos as my inspiration. the gravity levels were my favourite, and i always wanted something like gravity simulator to do my own experiments - thanks for that!
http://www.hemispheregames.com/osmos/
(available in GBP from steam)

1. we should be able to drag items once placed and reposition, rather than deleting and adding a new one.
2. we should be able to slow down and speed up time (mouse wheel to be used for either this or zooming in/out)
3. we should be able to change the radius and mass of any body
4. the stars should also move (ie every body acts like a planet, differing only in size, mass, colour)
5. the asteroid number and spread should be definable before flinging
6. we should be able to delete the orbit and not just the object by shift-clicking, and an undo button for deleted objects
User avatar
robly18
Posts: 413
Joined: Tue Jun 04, 2013 2:03 pm

Re: Calling all Suggestions

Post by robly18 »

branney wrote: 1. we should be able to drag items once placed and reposition, rather than deleting and adding a new one.
2. we should be able to slow down and speed up time (mouse wheel to be used for either this or zooming in/out)
3. we should be able to change the radius and mass of any body
4. the stars should also move (ie every body acts like a planet, differing only in size, mass, colour)
5. the asteroid number and spread should be definable before flinging
6. we should be able to delete the orbit and not just the object by shift-clicking, and an undo button for deleted objects
1-Sure
2-Okay
3-You kind of already can. Except asteroids, but that's kind of their point.
4-No. The point of stars is to stand still. Andy will add a way to recolor planets, use that if you want a moving white thing.
5-Eh. Can't you just pause and fling them? Or use code shenanigans to do it?
6-Okay, sure.

These are my opinions anyway.
Convincing people that 0.9999... = 1 since 2012
A Random Player
Posts: 523
Joined: Mon Jun 03, 2013 4:54 pm

Re: Calling all Suggestions

Post by A Random Player »

robly18 wrote: 5-Eh. Can't you just pause and fling them? Or use code shenanigans to do it?
Code shenanigans aren't very easy to do :P
$1 = 100¢ = (10¢)^2 = ($0.10)^2 = $0.01 = 1¢ [1]
Always check your units or you will have no money!
branney
Posts: 4
Joined: Sat Sep 21, 2013 3:22 pm

Re: Calling all Suggestions

Post by branney »

what i really meant by '3' was so we can build a more realistic looking system, with planets looking a lot smaller than stars, and moons a lots smaller again (was going to use asteroids as moons).

7. once bodies collide, the lower-massed object should annihilate. i don't want it flying off and interfering with another body's orbit which until that point is looking promisingly stable. and by having this object deleted it allows me to add another body if i have reached the limit. stage 2 of that should be to program the masses to fuse and momentum be conserved :)

update to '1' when dragging and repositioning (while paused would be fine) we could perhaps hold 'shift' to allow us to do a 'relative' fling rather than 'absolute' fling, so we can make slight adjustments to orbits (this type of fling should therefore be 1/3 as strong or so as the absolute fling). and maybe holding 'ctrl' while flinging could do a fling relative to the centre of mass of the system - not sure how this would work, just flinging out ideas ;)

8. 'spacebar' is used in much other software as 'pause' (games and media players!) so it would be great to have it as that to a) allow pausing to be much quicker than using the mouse, and the quickest key to find on the keyboard, in fact, and b) stop newbies like me from deleting things by accident (of course an undo button would help). a quick pause can be useful when a body is leaving the screen (of course a mousewheel zoom would help). the 'del' key seems far enough away from the main part of the keyboard for deleting items, since it should not be used very often

i am also wondering what does that variable constant R do? is it to do with how quickly gravitational force changes proportional to distance? is this something to do with why my planets currently orbit in less time the further out the orbit?
A Random Player
Posts: 523
Joined: Mon Jun 03, 2013 4:54 pm

Re: Calling all Suggestions

Post by A Random Player »

branney wrote: i am also wondering what does that variable constant R do? is it to do with how quickly gravitational force changes proportional to distance? is this something to do with why my planets currently orbit in less time the further out the orbit?
Yes: Usually
F=G*m1*m2*r^-2
You have it at
F=G*m1*m2*r^1.5
.
$1 = 100¢ = (10¢)^2 = ($0.10)^2 = $0.01 = 1¢ [1]
Always check your units or you will have no money!
User avatar
testtubegames
Site Admin
Posts: 1148
Joined: Mon Nov 19, 2012 7:54 pm

Re: Calling all Suggestions

Post by testtubegames »

branney wrote:what i really meant by '3' was so we can build a more realistic looking system, with planets looking a lot smaller than stars, and moons a lots smaller again (was going to use asteroids as moons).

7. once bodies collide, the lower-massed object should annihilate. i don't want it flying off and interfering with another body's orbit which until that point is looking promisingly stable. and by having this object deleted it allows me to add another body if i have reached the limit. stage 2 of that should be to program the masses to fuse and momentum be conserved :)

update to '1' when dragging and repositioning (while paused would be fine) we could perhaps hold 'shift' to allow us to do a 'relative' fling rather than 'absolute' fling, so we can make slight adjustments to orbits (this type of fling should therefore be 1/3 as strong or so as the absolute fling). and maybe holding 'ctrl' while flinging could do a fling relative to the centre of mass of the system - not sure how this would work, just flinging out ideas ;)

8. 'spacebar' is used in much other software as 'pause' (games and media players!) so it would be great to have it as that to a) allow pausing to be much quicker than using the mouse, and the quickest key to find on the keyboard, in fact, and b) stop newbies like me from deleting things by accident (of course an undo button would help). a quick pause can be useful when a body is leaving the screen (of course a mousewheel zoom would help). the 'del' key seems far enough away from the main part of the keyboard for deleting items, since it should not be used very often

i am also wondering what does that variable constant R do? is it to do with how quickly gravitational force changes proportional to distance? is this something to do with why my planets currently orbit in less time the further out the orbit?

Branny, welcome, and great suggestions!

It sounds like a lot of your ideas revolve around making it easier to add/tweak/remove/change objects in the game. And I'm totally on board with that goal. I'm planning on allowing players to click a pre-existing object, for instance, and have it pull up a list of stats that you can change. So you could change the mass, position, velocity, color, radius, etc of an object. I like your idea of smaller 'modification' flings... maybe I could incorporate that idea into how velocities are changed -- for those people who aren't interested in typing in new values for vel_x and vel_y, say.

Undo is a nice idea -- I should be able to figure out a way for that to work. Going backwards in time is a bit dodgy with the orbits drawn the way they are, but I'd like to have a 'reverse time' option... so I'll persevere with that challenge.

I'd like to add an option where planets *do* collide when they impact one another, and combine in a way that conserves momentum and mass. This would be able to be turned on and off, since you wouldn't always want that going on.

Thanks for the feedback!
branney
Posts: 4
Joined: Sat Sep 21, 2013 3:22 pm

Re: Calling all Suggestions

Post by branney »

Thanks for your comments!

I was going for options which would be easy to code for the most part. For 'undo' you only need a snapshot of the state of play when the last body was added or removed (of course, you could have several) and it would jump back in time to that point (could have a redo button to jump forward for where undo is pressed by accident!). This would not require calculation of the sim in reverse (which would have it's own issues due to rounding).

You could take a snapshot every frame and allow the user to define how much RAM can be used for this. This is how racing games used to do it before RAM was cheap! The other trick they use to save RAM is only take snapshots every few seconds, and allow the sim to calculate the intermediate steps. This could allow someone to play time in reverse, and every eg. 5 seconds the bodies will snap to the snapshot from that instance. Keeps things in sync but the motion may jerk slightly if the snapshots are far apart and the speeds are great. Or you could only let people rewind to a snapshot and continue forwards from there in real time, and not play in reverse at all. Going with the option which allows reverse naturally also allows playing at faster or slower speeds since the snapshots are keeping physics rounding within the calculation 'fineness' constraints you have already chosen.

In terms of masses colliding, you are lucky all the objects are spheres! Having non-symmetrical objects collide can be a pain if they are moving so fast that the collision is detected when they are already 'inside' each other (or sometimes they are so fast they do not collide!). What fps does your physics run at, or is it variable depending on the speed of the calculations?
A Random Player
Posts: 523
Joined: Mon Jun 03, 2013 4:54 pm

Re: Calling all Suggestions

Post by A Random Player »

branney wrote: You could take a snapshot every frame and allow the user to define how much RAM can be used for this. This is how racing games used to do it before RAM was cheap! The other trick they use to save RAM is only take snapshots every few seconds, and allow the sim to calculate the intermediate steps. This could allow someone to play time in reverse, and every eg. 5 seconds the bodies will snap to the snapshot from that instance. Keeps things in sync but the motion may jerk slightly if the snapshots are far apart and the speeds are great. Or you could only let people rewind to a snapshot and continue forwards from there in real time, and not play in reverse at all. Going with the option which allows reverse naturally also allows playing at faster or slower speeds since the snapshots are keeping physics rounding within the calculation 'fineness' constraints you have already chosen.
Actually, don't we already save each intermediate position when drawing lines? We could just use those for reversing time.
$1 = 100¢ = (10¢)^2 = ($0.10)^2 = $0.01 = 1¢ [1]
Always check your units or you will have no money!
User avatar
testtubegames
Site Admin
Posts: 1148
Joined: Mon Nov 19, 2012 7:54 pm

Re: Calling all Suggestions

Post by testtubegames »

branney wrote:You could take a snapshot every frame and allow the user to define how much RAM can be used for this...

In terms of masses colliding, you are lucky all the objects are spheres! Having non-symmetrical objects collide can be a pain if they are moving so fast that the collision is detected when they are already 'inside' each other (or sometimes they are so fast they do not collide!). What fps does your physics run at, or is it variable depending on the speed of the calculations?
Yeah, having the state of all the objects logged would be straightforward. I just need to figure out what would be best/possible for the orbit lines themselves. I could save the entire orbit lines picture at each undo-point... but that would get prohibitive very fast. What I'll need to do, then, is break it down somehow -- either into groups of 'new lines' for each checkpoint... or labeling each pixel with the time it was drawn. Since I'm interested in exploring a 'going backwards in time' option -- in addition to/connection with the undo button -- I might be able to pair the two methods together.

As for collisions, the refresh rate is variable, mainly depending on the quality setting of the game, but is at least 800 calculations/states per second. Hopefully that will be enough to log collisions properly in 'normal' use of the game (check out the Strange Oscillations topic for a more extreme example). I don't know that I'm going to worry too much about bullet physics, unless this system works poorly. Because if the game can't detect a collision at 800 checks per second, I'm hoping your eyes won't be able to, either. Generally.
A Random Player wrote:Actually, don't we already save each intermediate position when drawing lines? We could just use those for reversing time.
Interesting thought. My plan for the new version is to draw individual pixels -- so that information wouldn't stick around. (This should prevent the game from lagging even when there are tons of orbital lines on the screen.) Finding out where the objects *were* isn't that hard, though. I could either track it, or even more simple, just reverse all the velocities. The sim should be accurate enough for that to work in most situations.

That said, I'm sure you're all capable of finding the situations where that *doesn't* work! :D
DavidAllyn68
Posts: 28
Joined: Thu Aug 01, 2013 2:28 pm

Re: Calling all Suggestions

Post by DavidAllyn68 »

Just my two scents :)...

I would think the direction you would take would have to do with the primary purpose of the simulator. As a game... an engine for creating art and exploring the effects of gravity... I wouldn't think that "hyper" undo (i.e. saving every state of every change) wouldn't be necessary. I think simply saving the changes that have occurred in the script/code would be enough so when you're erasing -- you're not erasing everything -- just the "last" thing.

Now, if you were building a particle accelerator sim to model the effects of... <continue down that path of thinking>... ok... we would want to know where all of the objects are all of the time and be able to recall any given state of any object. We'd even maybe want a "jogging" mechanism for running it forward and backward at any given point in the run.

But for this, personally, I would rather you put your effort into merging/colliding objects, colors, trail length, etc.. -- ya know, the pretty stuff.
Locked