Week 8 – Skype with Dark Sky

The Introduction to Computer Programming Class had a Skype Q and A with Jason from Dark Sky (Dark Sky is an iOS weather app, check it out, it’s fantastic. They also make the great weather site forecast.io.) Super nice guy, I just emailed and asked, and it was scheduled a day later. Great experience for these kids.

Here’s some student responses to the prompt: “What blew your socks off? What’d advice/stories/information was surprising?

  • When how he told that if you really want to learn something. you need to be able to do it on your own time
  • I think it is motivational that someone who is successful had a hard time and still does sometimes and still does what he wants to do.
  • I thought it was really interesting when he talked about “reverse engineering” video games, and that was how he learned trigonometry. But now that I think about it, it isn’t surprising that it was easier for him to learn something difficult while immersing in something he was passionate about.
  • The most surprising fact was that he wrote 45,000 lines of code to make the app originally, and then he modified it to do more, but only required 8,000 lines of code. I also really liked how he encouraged people to go on their own and explore other programs by themselves.
  • What I guess what surprised me the most was how he compared computer programming to dance or singing or art. Going into this class I perceived computer programming as a very technical and systematic subject…that everything is by the book. While this may be true… talking to the developer brought to my attention that computer programming can be largely reliant on self discovery and self error.
  • I was shocked when Jay told us how long it took to create his app and how many lines of code it required (45,000).

IMAG0262 IMG_4075

Week 7 – Mandelbrot

Here’s the PreCalculus H classes playing with the Mandelbrot code to create their own variants of the Mandelbrot/Julia/Experimental fractals. More to come on this lesson, I’m presenting on it at the NYS Math conference in November and at NCTM in Boston in April.

IMG_4077 IMG_4078

Week 6 – Max Min Word Problems and Economic Analysis

With about 10 minutes after a Calculus BC test, I quickly did an introduction to Max Min word problems. Instructions: Pick an x value and find the volume of the (open) box (I gave the diagram, but didn’t have the 11-2x and 8.5-2x, those came after the class came up with them).

2014-10-07_10h42_56

They entered in their x and their volume on a google spreadsheet at a couple of computers and built the following chart.

2014-10-07_10h42_44

 

Also fun economic analysis – piecewise function maximization:

FullSizeRender

 

 

2014-10-09_11h14_23

 

 

Week 5 – Groupwork

(Re)Inspired by a tweet from Alex Overwijk,

unnamed

unnamed (1)
I used my “Vertical Non-Permanent Writing Surfaces” and “Visibly Random Grouping” in two classes today:

Precalculus H2014-10-03_08h56_242014-10-03_08h57_07

 

and BC Calculus

2014-10-03_10h16_35

2014-10-03_10h16_51

 

The goofy outfits are to be blamed on Spirit week.

Week 4 – Graphing f'(x) and Peardeck

Peardeck is a neat program. Students given f(x) and had to graph f'(x). Next time they’ll be given f'(x) and will have to graph f(x). Here’s what the teacher sees:
2014-09-26_10h24_59

And here’s the classroom action:
IMG_3738.JPG

Week 3 – Distance Formula, Desmos, and Calculus Groupwork

Here’s some students using paper, pencil, and calculator to check their Scratch program output (they needed to calculate the distance between two points).
IMG_3676-0.JPG
Desmos and transformations, a match made in (precalc) heaven.

IMG_3675.JPG
Lastly here’s calc doing what we do nearly every day, group work.

IMG_3673.JPG

Week 2 – Turn and Talk

My two intro to programming classes have started off well. Lots of work with Scratch, so lots of clicking. Silent clicking. At least once per day I have a “turn and talk” time where one student must turn off their screen and talk to a neighbor about programming difficulties. At least right now, they default to silently working (not a bad thing), but I want them to see their fellow students as resources as well. Python next week!
IMG_3663.JPG

Week 1 – Desmos Name Tags

PreCalc H students were tasked with graphing their full (first) name in desmos as homework for the first night. Here’s the results:
2014-09-05_10h02_35
I printed the images out and they now sit on their desks. Fun!

Week 0. New Setup

Hello Dear Readers,
This photo blog will have a new setup this year, 40 weeks – 40 posts. The 180 days of photos for the past two years was to much of a drain on my other blog and my writing in general, so I’m cutting it back to once a week. It’s an exciting year, so remember to visit.
Thanks,
Dan

161 – Dark Sky

For the rest of the year, I’m going to highlight some impressive final projects in Computer Programming and BC Calculus.
The computer programming students have had the majority of the term to work on their projects and one of the requirements was to write a blog post about their experience.
Here’s a crosspost of a game called Dark Sky. A fun 2D overhead game which has a cool unique game setup. The enemies only come toward you if you make move and make noise. Really polished game.

The Original Idea (Before)
darkskyoriginal
The Current Game (After)
darkskynew1

Game Demo and Controls

http://www.greenfoot.org/scenarios/11624

Left Arrow or A moves the player left.

Right Arrow or D moves the player right.

Up Arrow or W moves the player up.

Down Arrow or S moves the player down.

Holding Shift while moving allows you to “sneak”.

Pressing B when over a shop item allows you to purchase it.

Left/Right Click to fire your weapon.

Enemies and Bosses

The enemies of the game began as a simple graphic bug graphic as shown in the “Before” image and were only planned to be used for testing rather than actually being in the game. The bugs became the base for most enemies and the bosses of the game. The code for collision was spread to almost every enemy and modified to suit the enemy’s size. It would select a random direction and go a certain distance. If it hits a wall/enemy/portal, it turns in the opposite direction. If it goes the certain distance, it changes into a different random direction or continues on its path.

Example for Big enemy:

if (x < 50 && randdirection == 0) // Turns the Big left
{
if (Wallleft == null && Bigleft == null && Launcherleft == null && Portalleft == null) // Checks for collision
{
setLocation(getX() - speed,getY()); // Moves the Big left
setRotation(270); // Rotates the graphic to look to the left
}
else
{
rand = 1; //Turns the Big right
}
}

Some of the enemies also react to “sound”. The sound level changes depending on your movement. If you move without holding shift, the sound level is loud. If you hold shift, you move slower but the sound level is low. If you don’t move at all, there is no sound level. The Big enemy reacts if any sound is made, and stays stationary if no sound is made.

Example:

if (!Greenfoot.isKeyDown("shift"))
{
mode = 2;
if (!Greenfoot.isKeyDown("up") && !Greenfoot.isKeyDown("w") && !Greenfoot.isKeyDown("down") && !Greenfoot.isKeyDown("s") && !Greenfoot.isKeyDown("left") && !Greenfoot.isKeyDown("a") && !Greenfoot.isKeyDown("right") && !Greenfoot.isKeyDown("d"))
{
mode = 1;
}
}
else
{
mode = 3;
if (!Greenfoot.isKeyDown("up") && !Greenfoot.isKeyDown("w") && !Greenfoot.isKeyDown("down") && !Greenfoot.isKeyDown("s") && !Greenfoot.isKeyDown("left") && !Greenfoot.isKeyDown("a") && !Greenfoot.isKeyDown("right") && !Greenfoot.isKeyDown("d"))
{
mode = 1;
}
}

The Player

The player has the biggest amount of work put into it than any part of the game. The code for the player controls many aspects of the game including purchasing items, movement, going into different worlds, healthbar, etc. The design of the player graphic went through several iterations before becoming the blue robot that is in the present game. The player, as told below in the problems section and the before image, started off as a human. The weapons for the game were going to be things like a bow, sword, rock, and other things. Then I realized three things. One, making the weapons on the player would be infuriating as I would have to change the hands and the arms. Two, the footstep sound effect (Discussed in problems section) wasn’t working as well as I hoped. Three, the player graphic didn’t really look too much like a human. So I changed it into a robot due to it being easier to make, the weapons wouldn’t be as hard to put on, and the sound effects would be easier.

Weapons and Beginning Area

The weapons of the game have different characteristics but share some general code (Mostly collision code). The first weapon I give the player to use is the laser. It is meant to be a simple weapon with not very good range to start the player off. The weapon is also not given to the player at the start, as it is in pickup form in front of the player. This is to teach the player that when you move the enemies move. The bigs also usually go on ice which shows what ice does when you step on it.

Problems

When you run into a problem with your code, its like running into a brick wall. Whether that wall has two paths only a few feet away to proceed or one path that is three miles away depends on the problem.

Sounds

One of the very first and most persistent problems I ran into was sound. The most common was movement. There are two sounds for movement, which is for sneaking and for regular movement. When I first implemented these sounds, they were meant to be footsteps (Due to the player being a human at this point) but ended up being a continuous noise whenever I walked. I fixed the problem by putting in a “timing” system which basically plays a sound whenever an integer is divisible by a certain number.

wait = wait + 1;
if (wait % 14 == 0)
{
Greenfoot.playSound("moveslow.wav");
}

The problems didn’t stop there, as the sound began to sound annoying. Then, when I decided to change the player into the robot, I had to make new sounds. The sound for regular movement I made almost made my ears explode, but I used them for the time being and kept the sound on low. The sneaking one was great though. Eventually I decided that the sound for regular movement was too loud and I made it so the sneaking sound was used for both regular movement and sneaking until I made a new sound. The sneaking sound was kept until very recently (5/27/14) when I made a new sound which kind of sounded like running over rocks. That was made into the sneaking movement sound. The original regular movement sound was lowered and was made into the collision sound for the lightspike enemy.

Portals

The other thorn in my side was the portals. In the holes between two walls is a portal class that is meant to take you to the next level. Of course, the first time I tried to do this the portal didn’t work. I would briefly be in the second world but then it would kick me right back into the first world. The problem that I thought it was is that the getOneIntersectingObject() function was causing something to go wrong. Surprisingly, using a different collision function fixed it. The next problem was to transfer health, weapons, and other variables into the different world. It took about 2-3 days until I figured out I could just use a constructor to transfer the variables. As time went on, more and more variables had to be added to both the player constructor and the world constructor.  Then another problem arose. Putting more than one portal in a room did not work. I figured out a solution that I didn’t like using, but is still used now. The portals are rotated and those rotations decide where the portal is taking you depending on what world your in (Ex. 180 degrees would be the portal in the “after” image at the top). I also had to use an integer to specify where I wanted the world to put me (ex. 1 = put me in preset location 1).

Unused Content

Things are usually made to be used in a game but some aren’t ever put in due to problems with functionality or it no longer being relevant to the game. When I made the game, I had different ideas on what the enemies were going to be, how the game would work as a whole, and other functions and mechanics. These are some things that I never got around to using.

shieldpickup

shield

Shield

The Shield was going to be an essential part of the game along with the health bar. It would regenerate over time and would give you enough time to either get away or get more health. It wasn’t implemented because, due to the fact you could increase you health and a module idea(Adding effects like regeneration, speed boost, etc. to the player) I had, I decided it wasn’t necessary.

nosoundskill

 

Level-Up System

Before the store system was made, I was going to develop a level-up system. Basically, you would collect experience points from an enemy and each enemy would yield a different amount. After the player collects a certain amount of experience, the player could “purchase” a skill from the experience screen. It was never completed and was replaced with the store.

“Rock” Weapon

playern rockpickup

The “Rock” weapon was a weapon idea to drop from the special variation of the Giga boss. Ideas of what I was going to make this weapon be was a larger rocket/explosion, launching a huge rock, or firing a wave-looking projectile. It was never added and was replaced with the rocket launcher drop.

 

lightspikespecial

Special Graphic for the Lightspike 

Originally the lightspike had a special graphic that was bigger than the original sprite. This was too give the player a challenge and the special variety would appear 1/7 times. It was removed when the collision code was not working. The lightspike no longer has a special image and the special image was reworked into the lite enemy of the game.

enemyrobot

Enemy Robot

The enemy robot is an enemy that I just never got around to adding. It was to act like the player using both the laser weapon and the blaster weapon. Of course, it looks visually different that the player, making it seem it was more designed for battle than the player.

playere (Blaster weapon for player)

Also, the enemy was also going to have a shield with it as well.

launcher4

Alternative Constructor for Launcher Enemy

The Launcher enemy has a constructor to turn and change the way I wanted it to. (ex. 2-sided turret that is rotated 90-degrees). This constructor was used until a better and more efficient one was made.
public Launcher(int rot, boolean u , boolean d, boolean l, boolean r, int amt, int s, int wt) //amount of turret sides, rotation
{
rotate = rot;
setRotation(rotate);
if (rotate != 0 && rotate != 90 && rotate != 180 && rotate != 270 && rotate != 360)
{
System.out.println("The allowed rotations are 0,90,180,270,360. Setting to 0 degree rotation.");
setRotation(0);
}
(More variables equaling the constructor variables here)
if (amount == 5)
{
setImage("launcher2alt.png");
}
if (amount == 4)
{
setImage("launcher4.png");
}
(More setting images code here)
if (amount != 1 && amount != 2 && amount != 3 && amount != 4 && amount != 5)
{
System.out.println("Not an acceptable amount of sides. Set to default 4 sided mode.");
setImage("launcher4.png");
}

The current constructor also isn’t really used, as there is only one variation of the launcher present in any of the worlds at the moment.