So I've read a good bit of a couple of books on Java. Java: The Complete Reference 8th edition by oracle press, and Java: How to Program 8th edition by Deitel. Mind you, I never finished either book, only halfway through each, so maybe that's why I can't figure this out. Or perhaps I'm just being a complete retard that's been working all day on his first real class and has brain freeze, lol. So anyway, here's the code:
[source lang="java"]import java.util.Random;
public class Planet {
private Random rand;
private double mass;
private double xPos, yPos;
private double xVel, yVel;
/** constructors */
Planet(){
setMass();
setPos();
setVelocity();
}
Planet(double m){
mass = m;
setPos();
setVelocity();
}
Planet(double x, double y){
setMass();
xPos = x;
yPos = y;
setVelocity();
}
Planet(double x, double y, double m){
mass = m;
xPos = x;
yPos = y;
setVelocity();
}
Planet(double x, double y, double i, double j, double m){
mass = m;
xPos = x;
yPos = y;
xVel = i;
yVel = j;
}
/** returns distance from calling object
*
* @param x is the xPos of the calling object
* @param y is the yPos of the calling object
*/
double distance(double x, double y){
double distX = Math.abs(xPos - x);
double distY = Math.abs(yPos - y);
return Math.sqrt(distX * distX + distY * distY);
}
/** returns unit-length x vector pointing from this to calling object
*
* @param x is the xPos of calling object
* @param dist is the value returned from distance()
*/
double dirX(double x, double dist){
return (x - xPos) / dist;
}
/** returns unit-length y vector pointing from this to calling object
*
* @param y is the yPos of calling object
* @param dist is the value returned from distance()
*/
double dirY(double y, double dist){
return (y - yPos) / dist;
}
/** calculates acceleration scalar for calling object
*
* @param m is the mass of the calling object
* @param dist is the value returned from distance()
*/
double accelScalar(double m, double dist){
return (6.674e-11 * m) / (dist * dist);
}
/** translates this object on XY plane.
* should be called before accelerate.
*/
void translate(){
xPos += xVel;
yPos += yVel;
}
/** determines delta V for calling object.
* should be called after translate.
*
* @param as is the value returned from accelScalar()
* @param dX is the value returned from dirX()
* @param dY is the value returned from dirY()
*/
void accelerate(double as, double dX, double dY){
xVel += as * dX;
yVel += as * dY;
}
void setMass(){
double d = rand.nextDouble() * 10.0;
int e = (Math.abs(rand.nextInt()) % 6) + 22;
setMass(d, e);
}
void setMass(double d, int e){
mass = Math.pow(d, e);
}
void setPos(){
int w = 800;
int h = 600;
double x = rand.nextDouble() * w;
double y = rand.nextDouble() * h;
setPos(x, y);
}
void setPos(double x, double y){
xPos = x;
yPos = y;
}
void setVelocity(){
double x = rand.nextDouble() * 50000.0;
double y = rand.nextDouble() * 50000.0;
setVelocity(x, y);
}
void setVelocity(double x, double y){
xVel = x;
yVel = y;
}
double[] getPos(){
double[] pos = {xPos, yPos};
return pos;
}
double[] getVelocity(){
double[] vel = {xVel, yVel};
return vel;
}
double getXPos(){
return xPos;
}
double getYpos(){
return yPos;
}
double getXVelocity(){
return xVel;
}
double getYVelocity(){
return yVel;
}
public String toString(){
return "X: " + xPos + "\tY: " + yPos;
}
}
[/source]
I'm getting a NullPointerException argument at line 129, the setMass() method. It works perfectly fine when I build the object using the full set of constructor arguments. Can anyone tell me where my problem is?
Help me figure out what I'm doing wrong, please!
You forgot to initialize rand. you should initialize in every constructor. It should look like this.
rand = new Random();
rand = new Random();
I see some broader issues which you might want to think about.
The first is the granularity of that Random instance. Generally, you do not want to create lots of Random instances. Each Random instance seeds itself with the time, so if you create lots in a short space of time (which is typical when you are initialising your game) you can end up with the Random instances sharing seeds, which means that the sequence of numbers it generates will be identical. The result is that your game will be "less random" than if you create a single Random instance and pass that to any class that needs it. Alternatively, consider using Math.random().
The second is that your class design is poor because it expects that you pass the results of methods to other methods on the same object. This externalises object logic, and leads to the possibilities for bugs where the results of method calls on different objects are mixed.
Consider my understanding of how one uses your current class:
Here is an alternative:
Then you put whatever code you need in Planet#update().
Another idea is to split the code that deals with distances and positions into a mathematical vector class. Here is a simple* implementation:
(If you are wondering, the API is similar to that of a physics library I have used before, where fooLocal() indicates mutating operations - Java has no value semantics for user defined types unfortunately).
Here is a quick* example of how your code might use the mathematical vector:
This is an example of what I was talking about earlier - the details of how planets move is managed by the planet objects themselves.
By separating the ordeal of actually representing a planet from the mathematical hoops we have simpler Planet class and gain the ability to re-use this mathematical vector class for other objects in your game (e.g. space ships, artifical/natural satellites, projectiles).
There are a few other minor issues in your code (magic numbers instead of named constants).
* [size=2]Caveat emptor: code neither compiled nor tested!
The first is the granularity of that Random instance. Generally, you do not want to create lots of Random instances. Each Random instance seeds itself with the time, so if you create lots in a short space of time (which is typical when you are initialising your game) you can end up with the Random instances sharing seeds, which means that the sequence of numbers it generates will be identical. The result is that your game will be "less random" than if you create a single Random instance and pass that to any class that needs it. Alternatively, consider using Math.random().
The second is that your class design is poor because it expects that you pass the results of methods to other methods on the same object. This externalises object logic, and leads to the possibilities for bugs where the results of method calls on different objects are mixed.
Consider my understanding of how one uses your current class:
Planet p = /* ... */;
double x = p.getXPos();
double y = p.getYPos();
double distance = p.distance(x, y);
double accelScalar = p.accelScalar(p.getMass(), distance);
double dirX = p.getDirX(x, distance);
double dirY = p.getDirY(y, distance);
p.accelerate(accelScalar, dirX, dirY);
p.translate();
Here is an alternative:
Planet p = /* ... */;
p.update();
Then you put whatever code you need in Planet#update().
Another idea is to split the code that deals with distances and positions into a mathematical vector class. Here is a simple* implementation:
class Vec {
// No particular invariants so these fields are public!
public double x;
public double y;
public double getLengthSqrd() {
return (x * x) + (y * y);
}
public double getLength() {
return Math.sqrt(getLengthSqrd());
}
public void addLocal(Vec vec) {
x += vec.x;
y += vec.y;
}
public void mulLocal(float scalar) {
x *= scalar;
y *= scalar;
}
public void normaliseLocal() {
// ...
}
// ...
};
(If you are wondering, the API is similar to that of a physics library I have used before, where fooLocal() indicates mutating operations - Java has no value semantics for user defined types unfortunately).
Here is a quick* example of how your code might use the mathematical vector:
class Planet {
private final Vec position;
private final Vec velocity;
// ...
private double getAcceleration(float distanceSqrd) {
final double G = 6.674e-11;
return (G * mass) / distanceSqrd;
}
public void update() {
double distanceSqrd = position.getLengthSqrd();
double accel = getAcceleration(distanceSqrd);
velocity.normaliseLocal();
velocity.mulLocal(accel);
position.addLocal(velocity);
}
};
This is an example of what I was talking about earlier - the details of how planets move is managed by the planet objects themselves.
By separating the ordeal of actually representing a planet from the mathematical hoops we have simpler Planet class and gain the ability to re-use this mathematical vector class for other objects in your game (e.g. space ships, artifical/natural satellites, projectiles).
There are a few other minor issues in your code (magic numbers instead of named constants).
* [size=2]Caveat emptor: code neither compiled nor tested!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
