Everything is looking really really good here. Great work. I can see some items that I would like to change if we were going to move this screen to production, for example about how it has an empty ControlPanel that it has to pass to the supertype.
I think the main items that I see that we may want to fine tune here on the branch is to refactor Trajectory so that it doesn't take the model anymore. That sort of obfuscates the inputs that it actually needs. For now, the only value that is different from the model is the initial speed, but I think we will definitely want more control in the future, and it seems prudent to spend time making Trajectory more flexible.
From there I think we should work with designers to discuss a couple of items:
What is the future of the stats screen
What variables do we want to see this statistical variability in?
Put together a direction to work, like some sort of goal (even if not the end point), to get to. This could be some sim state to put in front of students for interviews, or even just to help us all be on the same page about the direction we are working.
@matthew-blackman, another item you could work on (which I plan on talking with you about soon) is creating files in common code that are much more generalizable, like a Property type that takes a numberProperty and a Stats algorithm to apply variance on it. Something like this, isolated in common code, could provide a different but also very helpful sandbox to experiement with. We can create unit tests to ensure the functionality that we are going for (instead of visuals like in PM).
Everything is looking really really good here. Great work. I can see some items that I would like to change if we were going to move this screen to production, for example about how it has an empty ControlPanel that it has to pass to the supertype.
I think the main items that I see that we may want to fine tune here on the branch is to refactor Trajectory so that it doesn't take the model anymore. That sort of obfuscates the inputs that it actually needs. For now, the only value that is different from the model is the initial speed, but I think we will definitely want more control in the future, and it seems prudent to spend time making Trajectory more flexible.
From there I think we should work with designers to discuss a couple of items:
@matthew-blackman, another item you could work on (which I plan on talking with you about soon) is creating files in common code that are much more generalizable, like a Property type that takes a numberProperty and a Stats algorithm to apply variance on it. Something like this, isolated in common code, could provide a different but also very helpful sandbox to experiement with. We can create unit tests to ensure the functionality that we are going for (instead of visuals like in PM).