Aug 12, 2013
The Commodore 64 in 64 minutes.
seen from Russia
seen from Guatemala
seen from China
seen from Japan
seen from Japan
seen from South Africa
seen from Japan
seen from United States
seen from United States
seen from China
seen from China
seen from Türkiye
seen from China
seen from Russia
seen from Malaysia
seen from China
seen from China
seen from Malaysia
seen from Malaysia
seen from United States
The Commodore 64 in 64 minutes.
The Challenges with Challenges
These past few days, I've been working on the auto-graded assignments for #8bitmooc. I've managed to get three out of the nine assignments done, two of the easy ones (doing controller input and drawing sprites) and one of the hard ones (Game of Life).
So far, each of these has taken about eight hours to work on each, since I first have to develop the game around the solution I want students to develop, and then I have to solve it myself. After writing a solution (to make sure it's solvable and not insanely tedious) I come up with acceptance tests and then make sure my solution passes those. However, since I haven't had the opportunity to actually test my emulator, I end up using this experience to debug my emulator, and I've found some particularly horrifying bugs. Luckily the emulator I've written is only looking at a subset of the architecture, but the last thing I want to happen is for a student to make a working solution and then wonder why they aren't getting credit for it.
One thing I've been grappling with lately is this notion of "speed". Whenever you get a correct solution, you are scored on how small and fast your program is. The size is easy to deal with, since it's just a ROM. But the speed is another matter - how do I decide how fast your program went? Do I have a single test case for speed? Or do I average the speed across all of the test cases? I'm leaning towards the average approach, since it seems the most fair, but I'm still on the lookout for a better idea.
The reason I'm working so quickly is because I have a workshop on NES programming coming up in Atlanta, GA next week, and I really want to use #8bitmooc as my environment. This weekend, I'm going to be doing a few more autograded exercises and bringing up the quality on some of the wiki pages - especially the pages on the hardware and memory mapped registers. The tutorial has been put on hold for the time being, since I'm questioning some of its utility (especially since there are very few interactive segments, it's basically a written lecture). Sometimes I feel like I need very concise reference pages, but I really want the help center to be highly conversational with an approachable reading level.
Progress Update and Radio Silence
Hello everyone! Long time no post! I've been working on other projects this summer (namely the ones that keep the bills paid and food on the table) so #8bitmooc has been suffering from some radio silence. However, big things have been happening lately!
New Interface
I've recently overhauled and streamlined the user interface for the website to make it much more efficient for students to see where they are in the class. I've also decided to do away with logging in and out and offload that to Github instead so that Github can deal with account verification and whatnot - I just use them for logging in. This should help since it will not only make my life easier, I would like - at some point - to make it possible to publish your NES games to Github from #8bitmooc. I think that would be pretty awesome, since it would hopefully encourage more programming in the future. :)
Even though it seems like a waste of time to be redoing the interface when I should be working on content, I simply can't keep my thoughts straight when I'm not happy with the interface. By redoing the interface, I become happier, and that encourages me to keep working on other things, such as the course content!
An In-Person Version
At one point, I considered doing a podcast or something to have some sort of verbal interaction with the course content. Even if there aren't that many students, talking things out is therapeutic and helps me think about what I want folks to get out of this course. However, I thought that an even better way to help me evaluate my process would be to hold an informal, in-person version of #8bitmooc. So I was thinking that I could take over a classroom one day a week on campus and see who I could get to come to attend an in-person work session around the content. I could record the interaction, and use it as an opportunity to answer questions about the content.
The only problem with this plan is that I would need more time to publicize the course. Granted, I've been doing a pretty sorry job of publicizing if I want the course to go live in September, but I feel like that's not a big deal, since I should probably have a smaller "MOOC" before trying to cast a large net.
Design Changes
I've made a lot of design decisions lately around simplifying what I'm trying to do. I've scrapped the entire levels and experience points system of the course in favor of the much simpler "gamification" that I enjoyed when I took my assembly course. I feel like the high score board that motivates students to optimize their solutions does a good enough job of requiring students to explore the language space, so I shouldn't have to add arbitrary experience points on top of that. While it complicates my message board system (I was really looking forward to the level-locked message boards), I feel like this puts less cognitive load on the user, leaving more mental capacity for actually engaging in the course content.
I'm going to start working on the challenges now - I've got them drafted, but I need to try to solve them myself before I'll be happy trying to make others do them. Also, I'm giving a workshop on NES programming in two weeks, so I'm hoping to use #8bitmooc as a demo platform for this purpose.
Discussions in #8bitmooc
For the next 23 hours, #moocmooc is in full swing again. We recently came across the issue of discussion forums, something that I've been wanting to address in #8bitmooc.
As we know, in #8bitmooc, I had the problem of trying to figure out why students would want to get experience points and gain levels. Originally it was a secondary thing that students could do while completing the course, but now I've turned the experience points and the levels into the grade itself. Once you reach Level 8, you pass. That's it. If you've worked enough to get that many points, you've either decided you care enough to learn the material, or you are so concerned with gaming the system you won't care no matter what we do. :)
So the first gating comes from the challenges. As you get to the higher levels, you unlock harder challenges and more opportunities to get more experience points. This is obvious, but I want to do something else - something tangible, without arbitrarily affecting the games that they can make.
Then I had it - as students gain levels, they unlock new forums that are only accessible to students who have also reached those levels. Part of the problem of discussion forums is the signal-to-noise ratio, where newbies are in all of the forums, drowning out the posts with redundant posts that disrupt deeper conversations you see on hobbyist forums that do quite well. By locking out forums based on levels, you won't have anyone in the thread about the affordances and limitations of the 4-bit sprite format who hasn't at least learned the basics of how the sprite format works. The point of #8bitmooc is to try it, and then discuss it.
Also, there's even a "Level 8" forum for the alumni of the course to stick together after they pass and move on!
The hope is that by gating the forums and trimming the noise, there will be people who are genuinely interested in a deep discussion about the content who won't be scared away from participating. I would love for students to be able to get experience points for deep discussions as much as shiny games, so maybe this is the first step to that goal.
Progress Report
What's stopping #8bitmooc from getting done? Let's take a look at the Issue Tracker... most of the things here have to do with infrastructure stuff.
Need a way for teachers to grade Game Jam submissions! Game Jams are a very important part of #8bitmooc. Once students get finished with the introductory material, the only way to really get through the course is by making games of their own. Game jams are worth 1000 XP each, so it's very important that they get graded correctly.
Create a way for students to get experience points for their posts on the forum (I have a really basic one right now, but it's not very flexible).
As for content, which is even more important...
"Hello world!" tutorial series - a series of readings and lecture videos about how to make games for the NES. I've gotten started on this, but it needs some work, especially since this is the tutorial series for newbies.
I need to actually make the autograded challenges, which means I need to make some games that partially work that I can break out subroutines for students to complete.
I need to make some sprites for the aforementioned games. :/
Finish the rest of the Wiki.
It's so much easier to do infrastructure than content. :/
Spoilers!
Recently I've been devoting my attention to the "help pages" pseudo-wiki for the course. #8bitmooc is entirely challenge-driven, meaning that rather than the lecture videos telling students how to complete the challenges that immediately follow them, the challenges tell the students what needs to be done, and the students turn to the help pages to figure out how to complete them. I've written a help page for every opcode and all of the status registers on the 6502, and moving on to do the assembler directives and memory map for the NES directly.
The reason for this is that when it comes to programming, the ability to get information from a help page or spec sheet is extremely important. This helps contextualize the features of the language without looking at them artificially in isolation. On the other hand, I feel like it's extremely irresponsible to simply write a reference document and expect students to learn anything from that. I'm trying to strike a balance between inspiring students to think about the possibilities available through the NES and getting them to uncover these capabilities on their own through the challenges. The last thing I want to do is connect the lecture videos to the challenges, since that conflates the purpose of the tutorials.
So what I've decided to do as a compromise is develop a series of pages in the help center alongside the reference. It's proven to be very difficult to keep to "just the facts" while writing these pages - I find myself going off on tangents about all the possible uses of particular opcodes rather than offloading those to their own pages (like discussing all the ways you can use the stack in the opcode page for PHA). This will allow me to develop my Tutorial as I need to, and then link back to reference pages for deeper reading if necessary. Students get nice video lectures, without having the challenges spoiled for them. Everybody wins. :)
You know, I don't know why I thought I could make a MOOC while getting away from doing the content. I spent the last four months building the infrastructure, so this part had to be done sooner or later, right?
What will I do with this blog when #8bitmooc is done?
The front page of #8bitmooc features an RSS reader that pulls from this tumblelog and displays all of the nonsense I write about here. So I've been wondering... how do I continue having an informal space where I talk about #8bitmooc while also providing important news to my students?
One idea I've been tossing around in my head came from the Virginia Tech Conference on Higher Education Pedagogy that came from a session on an interdisciplinary course on... not kidding... zombies. Bringing together an all-star team of profs from different disciplines, they came together to teach their students about literature, psychology, and literature about zombies. While #8bitmooc won't have zombies (probably), the one feature that made that class really stand out was their weekly zombie podcast, where the students got a candid look at their professors geeking out over how zombies had to do with their various specialties.
Wouldn't it be awesome to do a podcast or google hangout every week or so for #8bitmooc? Part of the beauty of the flipped classroom is that professors aren't spending their time in the classroom going over routine material. Normally, we talk about how that opens the classroom up for working out examples. But it also opens up time for the professor to talk about the things he or she is really passionate about! Since #8bitmooc is completely automated, having a personal blog like this or a podcast that talks about whatever I happen to be thinking about the NES at any given moment shows that there is a human leading this class. The exercises can cover the technical content, while the podcast can look at the more humanities-related content, and students can even earn experience points for partaking in the discussion on the forums or on Twitter!
Right now, most of this blog is related to the development and research of #8bitmooc, but I would love to re-focus it towards more NES-specific content and discussion later on. Right now, "my students" (if I even have any) probably just care about what I'm doing and when the class starts. I can start talking about course content after that milestone.
I am so excited about this project. Does anyone have any ideas of their own?
"Like" this post!
One essential part to making a successful online community is enabling the community to curate content on its own. When there is a massive contributor base, the least you can do to facilitate this is to enable something as basic as "liking" and "unliking" posts.
My idea:
A student can only upvote/downvote 'X' posts each day, where 'X' is her level.
A student can not upvote/downvote her own posts.
TAs can upvote/downvote as many posts as they like
Students can upvote/downvote the same post multiple times.
Why am I doing this? Why don't I just keep track of who liked which posts? I would, but that gets very expensive, very quickly, since it has to keep track of the ID for the user and the comment every time something is liked, and that takes a tremendous amount of database space. Having that detailed information is not particularly interesting, and it slows down rendering the forum/games. This also gives a tangible value to having a higher level, as it gives them more influence in the community as they master the content.
Thoughts?