Tag Archives: Full Sail Retrospective

Plagiarized Checkers

This article is part of a retrospective on my experiences teaching at Full Sail.

Most of my experiences at Full Sail were pleasant, but there was a recurring issue of plagiarism in several of the programming-oriented classes there. I received plagiarized assignments every month in almost every class I taught.

To facilitate the detection of plagiarized code, I set up an account with Stanford’s MOSS system, which helpfully cross-checked hundreds of submissions in the background while I worked on other things. If you’re teaching a programming class, and you’re not using a tool like this, then you are letting lots of students get away with not doing their own work.

The most commonly plagiarized program was this checkers game that I had written for fun:


Part of the academic honesty process involves a conference call with the accused student & the student services department. It was always painful hearing students try to explain their creation process for something that they neither designed nor developed.

The plagiarists got the message, finally, after I added this comment to the top of the checkers source code:

// Please do not plagiarize this game.

Teaching at Full Sail

Between April of 2012 and March of 2014, I was a course director at Full Sail University. I taught various classes in the Game Design Online Bachelor’s degree, but my primary class was Programming Foundations. This article is part of a retrospective on my experiences there.

Unity Logo

During my first weeks at Full Sail I spent my time taking the course I would be teaching, Programming Foundations. It was a Unity course, designed as a gentle introduction to programming,. He had laid out the class into 9 lab assignments, with nice supporting documents and videos for each.

Luckily, I wasn’t alone in this process. I had help from an interim teacher of the class, Fernando De La Cruz, who many of my former students would have met near the beginning of Final Project. He had the advantage of an additional 2 weeks of experience with the class, but that was enough to make him seem like an expert to me. In retrospect, this should have made me feel quite comfortable going into teaching mode on my own.

This was still a scary and exciting time for me, though, since it had been almost 6 years since I had taught anything at all, and I was pretty green at both Unity and C#.

In general, though, the curriculum and online platform did their thing without requiring any intervention, and I just filled in the gaps while trying to get a better sense of the course and its place in the degree.

The role of a course director in an online class is different from that of a traditional classroom teacher.  Since most of the instruction is asynchronous, students are best served by having a large amount of prepared materials to look at (videos, readings, tutorials) along with an opportunity to ask questions in a chat or voice call if they are confused about anything.

Not too much later, my good friend and coworker Zack Hiwiller sent me a link to clever little game engine, Perlenspiel. He he evaluating its potential use in his class, Game Design 2.

Perlenspiel was the game engine used in PGF

This was exciting to me. Perlenspiel isn’t a production game engine, and it isn’t meant to be. By shedding a lot of the features and requirements that you’d need for something you want to sell, Perlenspiel finds a great niche as a tool for practicing game design.

In just a couple of hours, I had made my first Perlenspiel game, Road Racer. In the next couple of weeks, I had finished Box Dropper. I have since made many more games with it – I was absolutely enamored with this engine.

☃ ☃ ☃

Several months later, I was able to see how the new Game Design 2 class turned out, and I decided to rewrite Programming Foundations from the ground up. This time, it would be a Perlenspiel class instead of a Unity class, and I would know all of the material in and out. It would also solve a couple problems I had found from working with Unity in a class setting:

  • Large project size
  • Slow project loading/testing cycle (bad for grading days)
  • Unity editor learning curve

Being a pure JavaScript/HTML 5 engine, and lacking any art assets, Perlenspiel addresses these inefficiencies pretty handily.

Desert Ruins, a Perlenspiel Game by Brandon Scott
Desert Ruins, a Perlenspiel Game by Brandon Scott (Click to play)

While I could handle the extra grading time, the overhead of dealing with the Unity had a very real effect on my students. The class after mine, Prototyping 1, had to re-teach many basic programming concepts, wasting valuable time that could have been used focusing on the point of that class, prototyping games. Programming Foundations didn’t have enough time in it for students to practice programming. It was being crowded out by having to also learn to use the Unity editor to import, manage, and lay out art assets.

I really wanted to get my new class up and running sometime soon so that I could address the problems that Prototyping 1 was seeing. It was time to get busy.

☃ ☃ 

Ultimately, I spent roughly 20 hours a week for 6 months building the Perlenspiel curriculum. I managed to cram part of this in between grading and helping students, but I also spent a lot of time after hours and at home.

I had decided on a basic schedule for the 4 short weeks I have with my students. There would be 8 lessons, divided into an even 2 for each week of the course. Each lesson had a chapter or two of background reading from a textbook, then a tutorial to complete (which I was calling an experiment in the hopes that students would actually experiment with the results), and finally a lab assignment which would build off of the concepts in the reading and experiment.

To go along with each lesson I had also recorded videos, though they usually covered things that were also in the experiments or books. Students feel like they get a better value if there are videos.

This layout followed my predecessor’s course structure pretty closely, though the experiments were a new addition. I ended up emphasizing them pretty heavily, and they carry a bulk of the effort that I produced during that time.

By the time I was done writing everything, I had produced:

  • 3 and a half hours of recorded lectures
  • 39,000 words in 8 Labs and 8 Experiments
  • 10 quiz questions (Ha ha)

After some waffling, I published the new course for February of 2013. Many thanks to my students who suffered through that first rough month!

Luckily, with the reduced grading load that Perlenspiel offered, I was able to iterate on the class materials quite quickly. By March I had already refactored two of the labs, Calculations (into its current state, Calculator) and Patterns (into Box Drawer).

The troublesome lab 7 underwent the most changes, from the difficult Patrol lab to the indecipherable Loot before finally becoming the polished Frogger lab. By then I had also cut lab 8, to allow students to work without dividing their attention between two projects the last week.

There’s something magical about having so much control over your class, and I always loved to see what students were able to create for the lab assignments.

I’ll be back soon with an article about one of the tougher parts of teaching this class – plagiarism!

Optional Lessons

Between April of 2012 and March of 2014, I was a course director at Full Sail University. I taught various classes in the Game Design Online Bachelor’s degree, but my primary class was Programming Foundations. This article is part of a retrospective on my experiences there.

The familiar Programming Foundations header

While I was working on my class, I had broken down the class materials into what I thought they were providing to/requiring of my students:

Detailed reference

Walk-through to create a working example
Motivation to continue through to lab

More examples
The process of programming
Clarify concepts that are tough to communicate in text

Lab Assignment
Apply concepts
Problem solving

Each one of these types of materials provides something that the others don’t, and each one of them was thus important for students to complete. I made sure to include one of each of the first three items for every one of the 7 lab assignments in my class.

For the sake of grading sanity, only the labs were delivered and graded. Usually, I could trust students to use the other materials. If not, they wouldn’t be prepared for the labs, and if they could do the labs regardless, then they must not have needed the other parts of the lesson.

The challenge here, then, was designing lab assignments that test enough of the game creation process to be a useful judge of ability when completed. Since this was an introductory class, most of the early lab assignments were simple versions of the same concepts covered in the corresponding readings, videos, and experiments.

The work that the students had to do for an assignment can be thought of as a “gap” between what they had already completed in the experiment (and can simply reuse) and what they needed to have done in the lab requirements. They had to spend real effort (time and cognitive work) analyzing their existing code snippets and then synthesizing them into something workable.

For example, if an experiment covered the use of mouse clicks, coordinates, and arithmetic operations, the lab might require students to put those together into a calculator program. It could be a direct product of the basic pieces that they already knew and had working examples for. The end result is that the mouse clicks feed their coordinates into the calculations that are displayed to the end user.

Each successive assignment had a larger gap, until the final pair of assignments, which provided a framework to build off of in the experiments, and required students to turn it into a unique game. While these were a challenge to grade, they were also the most interesting, and students felt like they got a lot out of them.