Learning to Ship Code

How 26 Illinois Tech freshmen learned to code in Java by programming virtual battleships.

Don’t assignments like this fill you with curiosity to learn more about programming and computer science?

They make me want to sleep in.

Luckily we didn’t give our students those assignments. We gave them this:

Mission 005: students vs “drone ships”

At the Illinois Institute of Technology’s Exelon Summer Institute, we challenged 26 incoming freshmen to learn Java by programming battleships and competing in naval missions.

Our team wrote a framework for Battleships, so our students could focus on filling out one function to create their own ship. Here’s what a typical day in class looked like:

• Overview of the mission: most missions were variants of 3v3 battles
• Students work in teams of three to plan, code, and test their ships
• Students submit pull requests on GitHub with their entries
• Reflect as a class before seeing the battles
• Watch all of the battles on the projector

We ran a total of six Battleships missions. Each night, whenever a virtual ship sank, war cries erupted from the class.

Here’s what the students said after the course:

I felt most proud when I was able to create my own successful code for my battleship. At the beginning of the class, I had no knowledge of CS. Now, I feel more confident about the CS class I have to take in MMAE.

I learn more about the bash terminal and feel like a better problem solver because of all the errors

I loved it, it was really fun and engaging, I really liked how we were all able to work together.

I’m proud of the fact that with the help of my team and the TA’s I was able to take down a team when we battled our classmates. I’ve learned how to organize code in order to make it more appealing and easy to read. Furthermore, I just understand more code.

Difficult but the more you do it the better you understand

Aside from pumping our students with adrenaline, battleships helped our team of instructors tackle two challenges that threatened to sink the class:

• How might we serve a class of students with varying experience levels?
• How might we cultivate a culture of growth?

These questions are being asked in many STEM education circles and we want to share what we have learned about them through the maiden voyage of Battleships.

For context, here is the setting of our class:

• Goal: prepare incoming freshmen to succeed in college CS courses
• Students pursuing different STEM degrees, not all CS
• Prior programming experience ranging from none to AP CS
• Nine night classes on M/W/F from 6:45 PM to 9:00 PM
• Students concurrently taking four other courses in other subjects
• Classroom with laptops for every student, internet, and projector
• Four CS/EE upperclassmen to develop and facilitate activities

Challenge #1: How might we serve a class of students with varying experience levels?

Based on past courses, our team was shy about segmenting our students based on their current level of skill. We didn’t want the novice programmers to feel behind the ball, especially when some students were already complaining that they never had the chance to take a programming course before. We didn’t want the more advanced programmers to become complacent, either.

Of all the concepts we brainstormed and tested, flexibility attracted us to Battleships. All of the students could work on the same problem, but the challenge would scale with their skill. The relationship between skill and challenge was not perfect, but we were able to offer a learning experience to all of our students with a relatively small set of rules.

The Rules

Each ship has 10 points to distribute among four properties:

• Hull: number of hits it can withstand before being destroyed.
• Firepower: number of shots it can fire on a turn.
• Speed: number of spaces it can move on a turn.
• Range: number of spaces in any direction it can see or fire.

On its turn, a ship can move, fire, and conduct reconnaissance.

Observe

• Check any other ship’s x and y coordinates as well as all four of its properties.
• If on a team mission, determine which ships are allies or enemies

Move

• Can move up to X spaces, where X is the ship’s speed value.
• Must choose a direction to move in: North, East, South, or West.

Fire

• Can fire up to X times, where X is the ship’s firepower value.
• Must give the x and y coordinates of the square to fire at.

Strategies: Simple to Sophisticated

From these rules, creativity took over pretty quickly and students started weighing the pros and cons of different strategies their ships could utilize.

Frustration kicked in when it was time to implement those strategies. Java took the wind out of our students’ sails with its intimidating main methods, static keywords, and weird curly braces.

A big inspiration for Battleships came from “the Hunger Games,” a programming game created by Dr. Peter Dong at the Illinois Math and Science Academy. In the Hunger Games, students program animals and try to survive an ecological simulation. All a student needs to do to create a competitive animal is fill out a single method defining what their animal does each turn.

We wanted to achieve this level of simplicity by clearing away the object-oriented jungle that comes with Java and focusing students’ imagination on one method.

Here is one student’s implementation of their strategy:

For loops and conditionals don’t look so boring now, do they?

Giving students the chance to articulate their ship’s behavior in battle terms rather than programming terms lowered the barrier to entry for our class, and gave us as instructors a much better window into their comprehension.

When students compared the code they wrote to the outcomes that played out on-screen, they received rich feedback that we could never give them on our own. Some of the best learning moments included:

• Lots of friendly fire: nothing sets your if/else statements straight like the look on a teammate’s face after you’ve sunk their ship.
• Firing at ships but having no effect on their health: running out of shots on a turn.
• Matches that never finished simulating: infinite while loops and ships that camped on opposite corners of the arena.

Even students who had programmed before had to learn these lessons again the hard way. When their classmates asked for help fixing bugs, the problems were easy to spot. It seems that lessons learned in battle stick well.

Data structures were beyond the scope of this class, but in Battleships players can loop over a list of all ships in the arena of battle, offering an opening for anyone intent on discussing concepts like searching. A few students sharpened their ship’s targeting by implementing a minimization search, something they didn’t even have a term for at the time:

Challenge #2: How might we cultivate a culture of growth?

In our own coursework, our team has learned that there is no replacement for time spent outside of class to become better programmers.

However, our students had so much on their plate already. Their schedules were booked most days from 10am to 9pm, taking five classes in different subjects. Rather than compete with the workload from other classes, our team resolved not to require any work outside of class. We held “office hours” where we brought laptops to the students in the dorms so they could refine their ships.

To rock some boats and force the students to evolve their code, we changed up the missions. When the students got used to battling each other, we introduced a fleet of “drone ships” that were weaker, but faster than their ships. This agitated most students into upgrading their strategy, but not everyone transitioned smoothly.

Several students wrote a simple block of code that they could understand and that seemed to work well in battle, then spent the rest of class time tweaking their ship’s properties.

Properties: The Unsung Challenge

At first, we felt like these students had given up on improving their code.

Then we had the chance to ask them about their process for picking their ship’s properties. Though they weren’t coding, the students were analyzing the impact of their micro-level changes on the system-level mission outcomes.

This was not a glamorous task. We only played the exciting simulations at the end of each class day. During development and testing, students had to watch the battles in text files:

These students grew more confident in their observations about properties as the course went on. In team 3v3 and 4v4 battles, some of these students actually advised their “more advanced” teammates on how to distribute their 10 points among the properties. When a teammate pushed back on a suggestion, they offered their rationale, unfazed.

We’d love to see more of this kind of collaboration and communication in computer science classes. Given more time, we would have turned some of the deep conversations we heard into discussion questions, so students analyzing ship properties can share their critical thinking without an instructor.

That’s how one element of the game that we associated with struggling students turned into a huge opportunity to grow and feel valued by their teammates.

Tactical Support Blackout

The other way we measured student growth in Battleships was by the number of time they called for instructor help.

From interviews with college students at Illinois Tech and other schools where Java is a common introductory language, a major pain point that emerged was learning to compile and execute programs from the command line. We wanted to tackle that head on and expose our students to the terminal right away.

The first few class sessions were chaos. Even with nearly a 6:1::student:instructor ratio, we were overwhelmed with calls for help. Yet, by the middle of the course, when we introduced the students to GitHub (a mammoth challenge in its own right), the terminal concerns had reduced dramatically.

We took one more step to wean the students off their instructor dependence. For the first 30 minutes of class, after answering questions about the day’s mission, we declared a “Tactical Support Blackout.” Instructors would not answer any questions for that time period. The students lashed out at first, but sure enough, they turned to their neighbors and started knocking out issues without us. In fact, we managed to sneak about 15 minutes of peace after the blackout ended simply by not announcing that it was over.

Letter to the Class

Given that extra time, we took a play from the book of Dr. Todd Finley, an English Professor at East Carolina University who devised a method of providing his students with high quality feedback on their papers without giving up his free time. Adapting Dr. Finley’s Letter to the Class format to code instead of essays, we reviewed the the major strengths and weaknesses of the ships and gave our students relevant, targeted feedback to improve. This letter to the class took 30 minutes to write, instead of the six hours our team put in reviewing pull requests from the previous class.

After reviewing the letter with our class, we saw a 100% drop in cases of friendly fire.

Dropping Anchor

The course concluded with an epic battle between the student fleet (blue) and the instructor fleet (red and yellow). If you’re curious about which team won, you can watch it here!

To try out Battleships with your class or friends, check out the GitHub repository.

If you want to get an update when the next version of Battleships is ready or just give us your thoughts and feedback, you can contact us here.

Thank you to Andy Rasmussen, Eve Tulbert, and Peter Dong for reading drafts.

Thank you to April Welch and Stephen Grzenia for their leadership of the Exelon Summer Institute program.

The Battleships Team

Freddy Herrera (EE ’17, fherrer4@hawk.iit.edu)

Jorell Socorro (CS ’18, jsocorro@hawk.iit.edu)

Nick Li (CS ’19, hli109@hawk.iit.edu)

Vinesh Kannan (CS ’19, v@hawk.iit.edu)