[yorwba]

> we decided to move forwards with a game based software that:

> Would have a low ‘barrier of entry’

> Be easy for students from any background to pick up

> Be visual and simplistic to wrap your head around

> Have some level of a competitive / addictive nature and well defined metrics of success

...

> ... For the frontend, we had to create a clear visualization of what the processes were doing, and also had to build a UI that allowed for intuitively creating programs in Redcode. The latter was especially important for us as the goal for this project was to require as little technical experience as possible, and we also knew that Corewars was a challenging game.

This sounds like a typical case of listing your requirements (low barrier to entry, easy to pick up, simplistic to wrap your head around), but picking something that doesn't satisfy those requirements (a challenging game) while thinking that you can make it work somehow (build a UI to make it more intuitive).

I'm not surprised they ran into a problem with that approach.

> ... Before deployment, we’d assumed that Corewars could be learned and played by students at a semi-competitive level within a sitting. Even with the beginner mode that featured a scoped back set of assembly commands and high visibility into the game’s processes, it took Adi an hour and a half of 1:1 teaching time within the groups to get them comfortable with the game. We can estimate from this testing it would take students ~3 hours to learn the game individually, and another ~3-4 hours of logical challenge questions to get to a competitive level.

(I think those numbers are more likely to be underestimates, except for students with a lot of prior knowledge.)

My high school CS teacher assigned writing a Corewars interpreter as a project, likely because he thought it would be a fun way to expose his students to assembly language. I did enjoy it, but most other students were already pretty lost just trying to understand how programs were executing in the reference implementation, let alone writing their own interpreter.

I think something like AntMe ( http://wiki.antme.net/en/Main_Page ) would've been a better choice of programming game (I only have experience with the two my CS teacher tried on his students, so it's likely I'm missing something better): the game world is an abstraction of physical reality, so it's not hard to visualize, and there's a variety of tasks of different complexity (from just making the ants walk around like LOGO turtles, to foraging for food, to waging war against other ant colonies).

[aramachandran7]

[op here] - thanks for the recommendation, we'll check out AntMe.

In hindsight, Corewars was a stupidly hard game to try to teach the intricacies of in a few hours, and because it's based in Assembly it's also mostly irrelevant to 98% of modern day programming students or new grads will be exposed to.

However, as an experiment in UI design and offering a visual portal into the internal game mechanics, this was a dope project.

[MikeTheGreat]

First - I strongly agree with everything you said. It's a steep learning curve to climb for something that doesn't really relate to any prior computing experience a typical student could be expected to have today.

The teaching time will go down if they stick with this - they'll learn what the common errors are, what the common conceptual misunderstandings are, and how best to present the material to their students. The 1 on 1 tutoring they did this quarter (hopefully) will have given them a lot of insight into what the student experience is like.

It looks like they mostly learned a lot about teaching, and how their educational system in particular works. If they're hoping to keep working in the educational space these two things alone will make their time worthwhile.

Anyways, it's a really interesting article by people who are both passionate about and new to teaching - it's a fun read.

[aramachandran7]

[op here] - thanks for your kind words.

This entire project really exposed us to some of the challenges of the edtech space - mainly how solving the problems of the current edu system and making an edu product that people want rarely actually overlap.

But regardless, developing a sort of custom curriculum for those couple hours of 1:1 teaching and refining that curriculum on the fly, and seeing what concepts kids picked up quicker was super interesting and honestly one of the most rewarding parts of the project.