Benedict’s Babeldom

I had a fantastic experience with the Judith earlier this week. The game is extremely simple, with an anachronistic style rarely found in games today. Experienced from a first person perspective, the game uses the arrow keys for movement and turning. Although the storyline is extremely linear, I found it gripping, always pushing to see what happens next. The simplistic visual style was complemented with a similarly spartan sounds. The music was sparse, only coming in occasionally, and the sound effects were frighteningly lo-fi.

The most notable thing about the experience for me was the control scheme. I was reading some comments and came across one that said something along the lines of “How can you release a first person game nowadays, and not have wasd and mouselook controls?” I found one of the most compelling aspects of the game was the control scheme, which by most standards today would be considered poor. This lead me to ask myself the question, “is it okay for a game to have bad controls?”

Controls are an essential part of the gameplay experience, perhaps even the most central aspect of it. Controls are the vehicle for making the player experience something. Most games revolve around feeling good at something. Guitar Hero is enjoyable because it offers an interface of control to make the player feel like they’re a rockstar. The Splinter Cell series is good because its controls allow the player to have the experience of being a spy, sneaking into bases, assassinating people, and just being an all around badass. These controls give the player a sense of responsibility and achievement in return for their actions; the controls aim to lower the player’s abstraction from the game, and immerse them in the feeling of accomplishment.

If movies were like games, every movie would be an action film. Most games offer little emotionally besides feeling like a badass. Sure, a character with a hamfisted relationship to the player might die in a cutscene. But in the end, you still blast off heads with ease and conquer evil. Movies don’t always end happily. More importantly, film characters aren’t always in control of their destiny. No matter how hard they try to achieve something, they fail.

This is something that Judith achieved. It took control away from the player, and made them feel awkward in their world. In retrospect, it’s amazing how fearful I was every time I had to stop and slowly turn with the arrow keys to see what was in a newly opened room. I wasn’t able to do what I wanted: I couldn’t strafe to the side and take a peek into the next room, and I wouldn’t be able to quickly turn around, and run out of the room. Films always have this effect, where the viewer has no control over what happens. Games only try emulating this by creating cutscenes. Instead, they should use the strongpoint of the medium, control, to evoke more complex feelings from the player. I want to fail while I’m in control of the game, because actually failing always has a greater impact than being told that you fail.

Most importantly, this is not an excuse for “poor” control. By this I mean, controls should achieve what they set out to do. If you’re a space marine blasting away thousands of aliens and you’re supposed to feel boss, don’t have unresponsive controls with poor auto-lock. Designers should explore control. Exploring control in games is like experimenting with the cinematography in a film. Movies are not games, and innovation should not be approached in the same manner. I’m not saying art direction, camera, and story are unimportant, they’ve just already been explored more deeply than control. Controls are means to a narrative end in games, and if they don’t deliver that, then they’re not doing their job.

I’ve decided to learn to use Emacs. This came after reading one of Steve Yegge’s rants where he proclaimed “Emacs is the 100-year editor.” In addition to this he says “All of the greatest engineers in the world use Emacs. The world-changer types. Not the great gal in the cube next to you. Not Fred, the amazing guy down the hall. I’m talking about the greatest software developers of our profession, the ones who changed the face of the industry.” These look like some bold statements to me, but you can’t argue with the great software that Emacs has helped create. After reading several other blogs, and lots of comments, I seemed to gather this from the community: Emacs and Vim are old. They used to be the best way to get things done, and can still be incredibly powerful today. However, they are not essential to coding as some zealots would have you believe.

So why learn emacs? I want to see what all the rage is all about. After reading how powerful it is, the potential to never have to touch the mouse, and learn some lisp along the way to fully customize it; it just sounds like something fun to do. When I’m moving around my OS, or working on something, I love the long periods where I can alt-tab, ctrl-tab, and copy/paste my way around without having to touch the mouse. I always crave more hotkeys for doing things. From what I’ve seen, emacs has more than enough hotkeys to keep me sated.

Why not Vim? I had started trying vim about a week ago, before starting to explore emacs. It seemed neat, but the separation of normal and insert mode definitely bothered me a little bit. I didn’t like having to take my hands off the keyboard to hit escape in order to move around and actually use vim how you’re supposed to. After starting to use emacs, I immediately preferred the ctrl-x commands. At my level of understanding, the differences between the two aren’t really apparent yet either. All I’m doing right now is moving around using the keyboard, and using some basic commands (yank, kill line, jump up and down pages, etc.), so it’d be foolish for me to say that one is better than the other.

I’ll keep updating with my progress, and how I feel about emacs. Maybe I’ll switch to trying vim again, maybe I’ll abandon both. But for now, I’ve got my Emacs cheat sheet taped to the wall, and I’m excited to give it a shot.

Tonight we held this semester’s WES-CS dinner. There were a disappointingly low number of attendees, as I believe only 5 students showed up (even though about 14 said they would). I guess it was a nice day out, but still. That didn’t stop the speakers from being great though. WES-CS is a supplementary 1-credit course to CS302 (Intro Programming) for students to increase understanding, and interest in CS (basically, recruit more people into the major). The speakers for this dinner were supposed to share the interesting work, and experiences that they’ve had with a CS degree. I was especially impressed by the second speaker, Evelyn Eastmond (.

Evelyn was born in South America, grew up in Everett (MA), and attended MIT. During her sophomore year she discovered CS, and joined the research team that created Scratch. She’s been working on it for 6 years now. In high school she was especially interested in art, and had no programming experience outside of building some websites. After taking a web-development course, she joined a group of students who went to Africa to teach Java to young “slum kids.” There she taught herself Java while teaching it to others. She then took the introductory programming course the following semester, and decided to pursue a degree in the subject. Then in the summer of her sophomore year she joined the research team developing Scratch, a visual programming language for young kids. Here she got to combine her love for art by doing graphic design for the project, while also coding.

While she fondly described the project for her introductory programming class where she built simple AI for a game involving game characters using cell-phones to call each other, she said something along the lines of “for loops and if statements just aren’t enough.” This statement really resonated with me. For someone toying with the idea of a CS degree, CS302 would probably not coerce them to do it. Students emerge with this idea that programming is task that is obsessed with syntax, and boring procedures producing bland tools. The course gives you the impression that you’ll just  end up just “slapping a keyboard” 9-5. 

Evelyn is making something that will change the lives of lots of children, and already has. She doesn’t spend all day doing mindless coding. She’s exercising her artistic abilities creating graphics for the application. She interacts with children weekly, seeing them interact with what she’s made. She writes new code, improving her software, making it more accessible, and allowing it to reach a greater audience. She travels the world, spreading her work to more children and educators. She sees the effects of her work in the hundreds of things kids make and post on the Scratch website. She’s created something meaningful. 

At the end of her presentation she said something along the lines of “CS is used everywhere. Learn to code, and apply it to something you love.” Becoming a programmer doesn’t cause you to sprout a neckbeard, lose social skills, and abandon all interests outside of computers. Eskil Steenberg, lone developer of the game Love, recently wrote a blog on a similar subject. For some reason people think programmers can’t code and be artists at once, or programmers can’t code a game and design it at the same time. This misconception really seems to have somehow made its way into the mainstream, deterring those who would otherwise make great programmers.

I don’t know what I can do to change this. Everyone seems to aknowledge there’s a huge problem with CS education, but no one does anything about it.

Hopefully I can get my young brother into Scratch in a couple years. Who knows, maybe he’ll be the next rms because of it.

Scratch: overview from andresmh on Vimeo.