DesignDocument

Springies Design Document
Davis Treybig
Jacob Lettie

In order to represent Spring-Mass models, we envision that there would be three key classes 
that perform the majority of the functionality. These three classes would be the Mass class, 
the Spring class, and the Muscle class, and these classes would fall under two hierarchies. 
The Mass class would be an independent class, whereas the Spring class would be a superclass 
of the Muscle class (though both would be instantiable). We decided to structure the classes 
in this way because, based on the Sodaplay constructor application, muscles are simply springs
 with extra functionality (a varying rest length), but masses and springs/muscles behave in 
 fundamentally different ways. The overall design of this system would be that, every frame, 
 every single Spring and Muscle class would automatically used their ApplyForce methods to 
 every attached Mass object. Afterwards, every Mass object would accelerate based on the net 
 force being applied. 

The Mass class would contain all the variables needed to read in and store data from the masses
in the simulation, and all the methods needed to implement the physics of how the mass moves. 
Since masses all are affected by gravity in the same way, a static class variable for gravity
would be shared by all the Mass objects. Mass objects would have instance variables 
representing their location and their mass. They would also have x and y net spring force instance 
variables to store the forces applied by all the springs and muscles connected to them. This is all 
the information we need the masses move correctly. 
	To give the Mass object its expected behavior, we would have a Move method that calculated 
the net force on the Mass object, and moved it accordingly. In order for this method to work 
properly, we would also need to add a receive spring forces method (a setter method) which attached 
Springs could call. This method would allow Springs and Muscles to add their force to NetXForce and 
NetYForce instance variables. 

The Spring class would contain all the variables needed to read in and store data from the 
springs in the simulation, and all the methods needed to calculate the forces the spring 
exerts on its corresponding masses. Springs will need to store both their spring constant and 
their rest length as instance variables in order to calculate the force they apply. Springs
would also store references to the two masses they are connected to via instance variables. 
This would allow easy calculation of the length of the spring at a given moment 
(and thus the force it should exert) by utilizing position data from the masses. These 
references to the masses would also allow the Spring to easily know where to apply its force 
every frame. 
	To give the Spring object its expected behavior, we would have a method that calculates 
the force that it exerts on each Mass, ApplyForce. This calculation of force would 
be based only on length and the spring constant (length would be calculated via the two 
attached objects). ApplyForce would function by calling the RecieveForce method of attached
objects in order to alter their current state of applied force. 

	The Muscle class would be a subclass of the Spring class and, for the most part, would 
function in a similar way. It would store the two Mass objects it is attached to as instance 
variables and would use methods to calculate what force it should apply to each of those 
objects every frame. The difference, however, is that a muscle in the Sodaplay constructor
has a "rest length" that varies over time. As a result, it would have an additional method 
that would be used to increment or vary its rest length every frame. Since this variation is
sinusoidal,  As such, this class would need to hold both the maximum amplitude of the sine wave
as well as its frequency. Based on the constructor, both of these values should be static final
class variables since they are the same for all muscles. In addition, each muscle would have an 
individual instance variable for its factor of the maximum amplitude as well as its phase. 
Setter methods would also exist in this class to change those variables. As mentioned earlier, 
ApplyForce would be the primary method that applies the muscle's force to attached mass objects
by calling their RecieveForce methods. 

Overview: 

Mass class
Class Variable: Gravity
Instance Variables: Location, Mass, NetXForce, NetYForce
Methods:
	Move: Acceleration of the mass based on NetYForce and NetXForce
	ReceiveForce: Method called by Spring and Muscle classes to add to the NetXForce and NetYForce variables
	Setter methods for Gravity, Mass

Spring Class
Class Variable: Spring Constant, Rest Length
Instance Variables: The 2 connected Mass Objects
Methods: 
	ApplyForce: Apply the total force from this object to attached objects
	Setter methods for Spring constant, rest length, connected Objects

Muscle Class (extends Springs)
Class Variable: Max amplitude, frequency (period), Spring Constant
Instance Variables: Amplitude factor, offset (Phase), 2 Connected Mass Objects
Methods: 
	ApplyForce: Apply the total force from this object to attached objects
	ModifyRestLength: Alters the rest length based on the sine wave
	Setter methods for its phase, amplitude factor, Spring constant, rest length, connected objects