If and User Input

Today I learned how to write if statements in java. This is done by typing if(condition) {execute}. If the condition is met the code will proceed. In if statements you can add an else. This allows you to execute something else, if your condition isn’t met. I also looked at getting a user input. This is just when you ask the user to input a string or integer, and then you print that value.  This is done using a scanner class. When dealing with classes you must import a statement at the top of the class file that imports the scanner class, so the program knows where to find it.

Preview of the app

Today I made this concept image of the app. More explanations will be on the week 2 progress post.

For and While Loops

Today I made a while loop and for loop in eclipse software. Java makes it very easy to concatenate strings with integers. This technique allowed me to keep track of the amount of strings printed in the console. Another useful technique I learned was printf, this allows used to format your print. Just remember when using printf instead of println you must add \n to bring your string to a new line. For loops are very useful to understand if you want to make an android app. As you can see in our code for loops are used frequently to do steps over and over again. Below we used a for loop to select one of the bodies in our app. Inside the parenthesis the first section contains code that executes before the loop is executed. The second section is a condition, as long as it is true the loop will execute. The last section allows you to increment i. The ++ after i increases that integer by one.

Week 2 Progress

Overview

This week, we made a lot of progress on the project. We are ahead of schedule to meet our goal of finishing within the ten week term. We've already made a few changes and are all excited about where the app is headed.

Major Changes

We've decided to change our game idea from having levels to being more of a creative/sandbox-mode sort of game. Players will be able to place planets, suns, asteroids, or any other solar bodies they want to make wherever they want in the virtual environment. They will be able to adjust their sizes, velocities, and positions relative to the other bodies on the screen. We are still trying to decide if we still want to incorporate some kind of game aspect or just make it a simulation. Making it a simulation would be cool because it would give the “game” more educational value. It would make more sense then to incorporate stats and numbers (like a body’s mass, velocity, and distance from other bodies) in a table. This would really help make it educational but it wouldn’t make a lot of sense to include it in a game.

If we were going to make it a game, however, it would need to have some kind of points system where players could get high scores. One idea we have is for a player’s score to be based on the number of bodies they can put on the screen without them colliding. This will become more difficult as they add more bodies because all of them will have gravitational forces acting between them. There would be a lot of strategy involved in deciding which moons should orbit which planets and which planets should orbit which suns. If we did go this route, we’d need to set boundaries in space and also other constraints to make the game more fun.

Progress

We made a lot of progress this week in the programming of the game. Much of this can be seen in the smaller posts we made over the last few days. As of right now, we have a working physics-based simulation running on Android and PC. Right now there are only three bodies in space but the code is set up so that it’s easy to add more. The gravity and physics is realistic and uses the real formulas for gravity and centripetal force. A user can launch the bodies around the screen and change the mass/size of one of them. We’re calling this one the test planet right now because we’re testing all of the future functionality on this one body before we extend it to work on all of them. On the desktop version, you can press the “O” key to make the test planet orbit the sun. You can use the arrow keys to zoom out and in and you can click and drag to pan the camera around.

Future Plans

We’re going to set it up so that there is a set of control buttons that slide out of the side of the screen where people can choose whether they want to be in view mode or edit mode. In view mode they will be able to pan and zoom the camera without worrying about editing the bodies. In edit mode, they will be able to select certain planets to edit by clicking on them. They can click and drag to launch them or click and then scroll the mouse wheel to change their sizes. There will also be an orbit button on the screen. All of this functionality will work similarly on the phone. People will be able pinch their fingers in and out on the screen instead of scrolling the mouse wheel to zoom and change planets’ sizes. All of the key commands will be replaced with onscreen buttons. (see picture below)

Here is a basic concept of the menu we plan to implement into the app. The "+" button is used to add a new body to the simulation. The view button is used to get to settings to adjust zoom and pan the camera. The settings button is for adjusting the properties of a specific planet. When a body is selected, a user will be able to use the buttons to pick an orbit, see info about it (see the stats in top left), and delete the body entirely. They will also be able to launch the body (change its velocity) by dragging back on it or adjust its size by scrolling or pinching the screen.

Challenges

One of the biggest challenges we’ve faced so far is scale. Because gravity is such a weak force and space is so spread out, we’re having a hard time fitting everything in a reasonable amount of space. We solved this mainly by making the gravitational constant equal 1 in the formula in the code. The real value is 6.674×10⁻¹¹ N⋅m²/kg² so this is obviously a major adjustment. We will account for this by scaling the radius and masses that we display on the screen. Instead of being 200 meters like it actually is in the game, it might be scaled to 200×10⁹ meters. Another problem is that libGDX has a maximum velocity of 2 units/frame. This is why we can’t set a realistic scale because at 60 frames per second that would mean a maximum velocity of 120m/s. That would be much slower than actual planetary motion and it would literally take years for a body to move across the screen. You also wouldn’t be able to see any acceleration due to gravity if the velocity was already at the maximum. This wouldn’t be good for the educational factor in the app. We’ve been working on solving this by, in addition to scaling G, adding a scaling factor for all of the numbers in our code. We all worked together to figure out the math behind this scaling because different numbers (e.g. distance and mass) need to be scaled differently. It seems to be working pretty well right now but we’ll see what other kinds of changes need to be made in the future.

Team Roles

Since Nick has the most experience with Java and Android development, he has been doing most of the actual programming so far. Ebed and Jiho have been watching Java lectures online to get up to speed. They are also working on graphics and helping to solve problems and plan for the future.

Learning Java and Graphics Update

Today I worked on Java code and looked up images for planet skins, and  fun facts about astronomy. I was confused with switch function in Java so I watched the tutorial, and it was not that different than C++. Also learned method parameter. It seemed really useful things to know when someone is coding for robots. It looked simple but I felt like it will be confusing when I need to write long program.

Among the pictures I found I like this one:

It will be cool when the planet mass is increased. 

I got some fun/interesting facts about astronomy from Cornell University Website. And for me the fact that "Saturn is the only planet in the solar system that would float on water" amused me.

Practicing Java

Working through more tutorials on java. The first tutorial explained how to define variables. In the tutorial variables are described as boxes. In java there are different types of boxes. Depending on the type you must use a key word behind the variable. For example if your variable is an integer you must put, int variable name = integer. Then using sysout you can run the program and it will output your integer in the console. Other key words include, char for charcter, boolean for true/false, and float for a floating number. When initializing a float you must put f at the end of the float. In the following tutorial I went over classes. A class is just a type, for example a dog is a type of animal. In the tutorial we used the class string which is a type of object that can hold text. The variable in a string allows you to refer to a thing that has the type string. What you set the variable equal to is called the object. An object is a particular instance of a class. For example if the class was a dog an example of an object would be an German Shepherd.

Solving Gravity

Today, I spent some time working on the realism of our simulation. I wanted to make sure the physics were realistic. I used the equation for centripetal force and set it equal to the equation for gravitational force and solved for the needed tangential velocity for a certain radius and center mass. After trying this out in our current simulation, I found that it wasn't working the way I expected. I created a couple different values for the radius and then experimented with the velocity until I got a perfect orbit (the radius and velocity stayed constant). I found that for a sun with a mass of 100 and a planet at radius 100, the planet's velocity would need to be 100. These units are all arbitrary and our gravitational constant (G) is 1. According to the math, v should = sqrt(GM/r), and the needed velocity should have been 1. This was obviously not the case. I found also that for the same mass, at a radius of 25, the velocity was 50. After some more experimenting, I plotted some of the points in excel (see the graph below) and found that for a constant center mass of 100, the equation for velocity was roughly 10*sqrt(r).

I noticed that the 10 out front was equal to sqrt(M) for M = 100 and I hypothesized that v = sqrt(Mr). I then created a function in Java called orbit() that takes in a mass and radius and returns a velocity. I set this up to make the planet orbit at a variety of different values of M and r and it worked perfectly. This made me think that perhaps I had messed up the force of gravity calculation in the code and the simulation we were seeing was not accurate. At first glance, I couldn't find anything wrong with it but after stepping through with the debugger, I found the problem. Here was the original code:

Vector2 f = r.nor().scl((float) (m1 * m2 / Math.pow(r.len(), 2)));

This is the basic formula for gravity in vector form. The two masses are multiplied together then divided by the magnitude of the radius squared and finally everything is multiplied by the unit vector in the direction of r. The problem here was that calling the function r.nor() didn't simply return the unit vector of r. It also changed the value of the vector object for r in memory. So then later in that same line when we took the magnitude of r with r.len() we were actually taking the magnitude of the unit vector instead, which was 1. This made get rid of the magnitude of the radius entirely from the formula for the force of gravity and it would just equal (Mm)(r-hat). Then when we calculated the velocity for a circular orbit, we would get v=sqrt(Mr) instead of v=sqrt(M/r) like it should have been. I fixed the code by declaring the magnitude and unit vector before plugging them into the formula. I made sure to put the declaration for r_mag before r_hat so that the magnitude of r wouldn't be affected by the normalizing of r. Everything is now working the way it should.

float r_mag = r.len();

Vector2 r_hat = r.nor();

Vector2 f = r_hat.scl((float) (m1 * m2 / Math.pow(r_mag, 2)));