I’ve begun work on a new game engine, inspired by Perlenspiel, but with an additional focus on modern development methodologies and the latest in Javascript. It uses the Pixi.js rendering engine, Keydrown for key handling, and likely many additional libraries as I add functionality.
It’s not ready for general use yet, since it’s missing some major features like Audio and a solidified API. There is, however, a README that you can look at if you want to start using Spielmatrix right away.
If you have a Perlenspiel game that you want to share with everyone, http://itch.io/ is a great place to do it. There are only a couple things to prepare a game:
This article is part of a retrospective on my experiences teaching at Full Sail.
Full Sail University has a program structure different from that of traditional universities, and it’s important to know how it can impact you as a student before you really dig into a degree like Game Design Online.
In each online degree program, you’ll take one course per month for the 32 months of your studies. There are rarely any chances to take them out of order, or to take two classes at once. A definite benefit to this style is that you know ahead of time that you can concentrate on one subject at a time. Some students really thrive in this atmosphere, especially if they can stick with one cohort of students throughout.
The problems with this structure only become apparent when you run into a problem. First of all, if you fail a single class at any point, you get bumped back into a different cohort. If you’re lucky, this happens early on, and you have plenty of time to make new friends & contacts in your new cohort. If you’re unlucky, or unprepared for the dramatically faster pace of later classes, you might find yourself bumped back multiple times, even near the end of the degree when there are high stakes team classes coming up.
The second bad situation can occur if you have a flexible work schedule, one with different hours or a different amount of hours from week to week. Because you only take at most one class per month, there is no practical way to take a half load for some time when you know you need to spend more time at work or at other tasks outside of school. In a traditional University setting, it’s usually easy to cut a couple credit hours, or choose your easy classes (the ones you’ve been saving, right?) for when you are going to be busy outside of school.
At Full Sail, the best option is to take an entire month off, and you can only do this a limited number of times. While this might seem dire, keep in mind that most of my students were able to stay abreast of the situation at least most of the time, and many of the workload problems could have been ameliorated by coordinating with student services & asking for help early on in a course. Keep this in mind while you are planning your education.
If you were a student at Full Sail, how was your own experience? Did you find the month-long classes to be liberating or suffocating? Let me know by commenting below!
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:
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.
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.
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 (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!
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.
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:
Book
Examples
Detailed reference
Experiment
Walk-through to create a working example
Motivation to continue through to lab
Video
More examples
The process of programming
Clarify concepts that are tough to communicate in text
Lab Assignment
Apply concepts
Problem solving
Deliverable
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.
I’m excited this week to bring you an interview with Ed Crundle, a road developer on the Red Bug Lake Overpass in Orlando, Florida. Ed is a genuinely brilliant crafter of roads, and he’s known for his “show, don’t tell” philosophy of street signage design.
Ed Crundle, Famous Road Designer Photo by Bill Ruhsam
DiehrStraits: What do you do?
Ed Crundle: I’m a road developer & sign engineer for the independent road studio, Black Road Construction.
DS: When did you get started with driving on roads (and what was the first road that you remember)?
EC: I’ve been driving ever since my parents got me a Cozy Coupe for christmas when I was 4. Been driving ever since. The first road I drove on was the road in front of my house – same as most drivers who grew up in the 80s.
DS: How did you get started with developing roads?
EC: When I was in school, I would always scribble roads and highway interchanges on all of my homework. I think my teachers all knew that I was obsessed with roads, then. I made my first road in my backyard with a shovel and a bag of gravel. It wasn’t very good, but I drove on it until it got washed out in a thunderstorm. I’ve been making little roads in my spare time ever since.
DS: How did you get started with Black Road?
EC: I went for a B.S. degree in asphalt engineering at MTU, and I had a good portfolio of my own roads that I’ve worked on, including some great student projects that I did, like the section of road between 4th and 5th along Jefferson street. Harold Carlisle, the CTO at Black Road, reached out to me after he saw some of my roads that I posted on Twitter. I was a good match for the types of projects they had been working on – small, self-contained roads that offer a smooth ride from start to finish.
DS: How many roads have you worked on so far?
EC: Twelve, if you include canceled roads. Since we’re a small construction company, we try to fail fast when we’re building a new road, so that we can put our efforts into only the roads that are really clicking with us. That way we can try out more interesting designs and really break away from the clichés that you always see while driving.
DS: What are the specs on your driving rig?
EC: It’s an 8-cylinders custom Toyota engine, 5.8k RPM overclocked to 6.2k. I like to stay on the cutting edge so that I can drive on the latest roads with maxed-out settings.
DS: What’s it been like working on the Red Bug Lake Overpass?
EC: It’s been great so far. The alpha build has been done for a couple of weeks, and we’ve been having road nights at the studio where we all drive over it for a couple of hours to see how everything is coming together. I think you’ll all have a blast with what we’ve come up with here. The signage will blow your mind when you see it.
The New Overpass Photo by Janne Moren
DS: How did you come up with the concept for this Overpass?
EC: We kind of lucked into it. We were watching Live Free or Die Hard for inspiration, and decided to try our hand at some ramps. There was some open ground in the Red Bug Lake area where we were making our test builds, and we noticed that there was some hype building up at the stoplight nearby. People were interested in what we were building – so we decided to drive with it.
DS: How does your signage philosophy play into the design of this road?
EC: We went with a wide, sweeping on-ramp design to draw the eye to where it needs to be – the apex of the overpass. This is augmented by abstract signs – primary colors and solid black symbols only, no words or numbers. It had to be easy to drive on to, but still rewarding to get over, so there’s a wall along the side so that you can’t see Red Bug Lake Road until after you crest the peak. It’s utterly spellbinding when the sun is rising.
DS: Sounds fantastic, I can’t wait to drive on it. Any words of advice for budding road designers?
EC: Keep your spade handy, and always drive with confidence.
Here are some good articles I found while looking for research into the design of puzzle games.
Designing the Puzzle, by Bob Bates, is an article that focuses on the design of puzzles in an adventure game. Regardless of whether an adventure game focuses more on the story or puzzles, bad puzzles will distract the player from the better parts of a game. It includes a list of the fundamental types of puzzles found in games, things to avoid, things to shoot for, and techniques to mitigate the damage that overly difficult puzzles can do.
The overall mantra is to play fair with the player, and avoid such things as player paranoia:
It is very unsettling for a player to worry that the reason he can’t solve a particular puzzle is because there is some tiny area of the screen he has overlooked. If he finds out that this is the case, he will get mad at you.
How are puzzle games designed?, by Herman Tulleken, is a series of articles that begins with some great historical information about puzzles. One of the early examples is the ancient Ostomachion, a tangram-style puzzle originating from mathematical research that Archimedes was doing regarding the division of the square.
Moving Beyond Alchemy is a classic article by Daniel Cook about the use of skill atoms and skill chains for any type of game design.
