FunEffect.com

Looking for a fun and immersive way to teach his 8th grade students about space, science instructor Chad Shumaker brought Activision's 1984 sim Space Shuttle: A Journey into Space to his classroom. He wanted to do more than just have kids play the game, though, so he decided to build on the experience by housing the 27-year-old game in a cabinet.

He teamed up with a fellow teacher/woodworker at the school and constructed a 3' x 5' x 4.5' wooden cabinet cabinet, spending around $250 on the project. Students sit on a chair with a joystick attached to an arm, as they navigate their ship. A strip of LED lights and a battery operated fluorescent light positioned over the console provide limited lighting inside the simulator.

For added realism, he has students wear headsets while piloting the game, and he guides them through with instructions delivered from a walkie-talking outside the cabinet. The rest of the cabinet consists of a 19-inch Zenith Space Command Television sitting on top a cabinet.

All that work has paid off, as his students have really taken to the setup. "The space shuttle simulator is amazing," says eighth-grader Dylan Sterling. "Even though the graphics weren’t very good, it still seemed very realistic thanks to Mr. Shoe talking to you from outside. The whole setup is great. I hope we keep toying with it for the rest of the year."

Shumaker says he plans to eventually use the simulator with Absolute Software's Tomcat: The F-14 Fighter Simulator.

[Via Dr. Kwack. The Times-Reporter]

Towlr is a puzzle. Towlr is an art movement. Towlr is an aesthetic with its own manifesto. Sort of. Towlr is frustrating. In Towlr, the cake is not a lie.

Towlr has a + sign in the screen. It has no meaning.

Towlr provides no rules, no tutorial, not even a minimalist statement of goals. You must deduce the goal.

Towlr tells you when you have failed, in a most annoying fashion.

Towlr displays only simple, geometric shapes such as you might see in an Atari 2600 game.

Towlr rewards success with cake.

In Towlr, the appropriate response when you succeed is "Doh!".

Towlr looks simple; but actually, there is a highly refined sensibility at work here, one that could only and can only derive from games. It's a sort of minimalism that rejects almost everything we know, or believe we know, about games. There is no hand-holding, no increment in skill, only a puzzle, with no hints and no support. The purpose of Towlr is to figure out how to play, and once you have, you are done.

And just as stark as its gameplay are its visuals and soundscape.

The first Towlr was created by PoV for a Ludum Dare competition, but a bunch have been created since. They are all available at the Towlr site. Some are web-playable, others are downloads, and the downloads vary in what platforms they support. But you should check them out, if only to experience a remarkably different aesthetic of the game.

Nominated for this year's IGF Nuovo Award, here's a trailer for Ian Bogost's 'A Slow Year'. It's a collection of 4 games, one for each season of the year, to be released for the Atari Video Computer System.

OK, so it will also be released for PC and Mac "in a custom Atari emulator", but it will indeed be available via a limited edition cartridge for the Atari 2600, along with a special poetry set! Lots of lovely information regarding the release over on Bogost's blog. Continue reading

Even if it weren't a finalist for the IGF's Nuovo Award this year, there are plenty of other reasons to feature this new trailer for Ian Bogost's A Slow Year here, chief of those arguments being its lead platform, the Atari 2600.

In a recent interview with UK-based PC game site Rock Paper Shotgun, Bogost described A Slow Year's premise of game poems for the different seasons, which draws on Imagism and the Atari 2600's limitations for inspiration:

"A Slow Year is a set of four small games about attention and the experience of observing things. I wanted to explore the kind of condensation and compression one usually finds in poetry, particularly in Imagism, but also in those poets’ inspirations in east Asian literary traditions, including the haiku. I’ve been calling them “game poems,” and the four of them together form a little collection, like a chapbook.

... each of the four games is limited to 1k in size (4k is a standard Atari ROM size), and each represents a season of the year. As games, they each offer a challenge about a familiar, banal idea: watching leaves fall or prolonging a morning cup of coffee, for example. They’re all played in the first person, but in unfamiliar ways.

One requires first-person coffee drinking. Another involves closing one’s virtual eyes in the game. As poetry, they evoke rather than clarify. As images, they are visually evocative in spite of the apparent primitiveness of the Atari as a platform. I hope the game makes the Atari seem beautiful."

Bogost will release A Slow Year as a "limited edition cartridge and poetry set" for the Atari 2600 later this year, and also plans to put out PC and Mac versions via a custom Atari emulator.

[In the latest Road to the IGF interview with <a href="2010 IGF finalists, we speak with Star Guard's Loren Schmidt, who explains why "retro" isn't always the best term for a "low-fi" game.]

Loren Schmidt's Independent Games Festival finalist Star Guard resembles an Atari 2600 game, but don't call it "retro."

The side-scrolling platform shooter is up for the Excellence In Design award for IGF 2010. It might appeal to a gamer's innate sense of nostalgia with its pixelated graphics, but from a design and artistic standpoint, creator Schmidt is living in the present.

Here, Schmidt explains why the term "retro game" makes him "uncomfortable," the inspirations for Star Guard, and expressing narrative within the confines of "low-fi."

What kind of background do you have making games?

My family didn't have a computer when I was younger, so I spent a lot of time playing with Lego, building castles out of blocks, and making up board games. I was always entranced with things that had moving parts or were interactive in some way.

I remember that when I was six or so, there was one block castle which I made over and over. It opened up and had a hidden slime pit inside. See, you'd put a little plastic knight right on the seam, and then you'd open it up and he'd fall into the slime pit below. The slime was made of green wooden blocks.

The first chance I had to make actual computer games was much later, in high school. And even then I didn't know how to program well. I was only allowed to take one elective, so I chose art instead of programming. I'm still playing catch-up in the code department.

What development tools did you use?

I used FlashDevelop to make Star Guard. I quite like it. If anyone out there is using Windows and is interested in Flash game development, I'd definitely recommend giving it a go.

There's also one tool which I really should have used, but didn't: an in-game level editor. Switching back and forth between an external editor and the game is unnecessarily awkward. In hindsight it would have been a really good idea to have taken a little time to make a simple real time editor for the game. I think it would have saved a lot of time and made level design a much more fluid process.

How long have you been working on the game?

About 16 months, though during that period I was only able to develop games part time due to school and other obligations.

How did you come up with the concept for the game?

What were its influences? I was making a large puzzle adventure game at the time. I didn't know how to organize myself, and though I still believed in the game, it wasn't going well. I had an urge to run away and make an extremely simple action game. I originally told myself it was just going to be a side project, but I had so much more fun developing Star Guard that it ended up becoming my main project. As influences, I'd list Another World, The Pit, Flywrench, Lode Runner, and Shotgun Ninja.

I'm not advocating abandoning projects- actually I think abandoning the other project was really unproductive and painful. I felt really guilty, and for the longest time I wouldn't admit to myself that I'd stopped development of the original game.

In hindsight, I think the problem was that I charged into making a large game too quickly. I was enthusiastic, but I didn't know how to develop a large project in a way that would stay fun and productive. (I'm still trying to improve my skills in that area.) I should have made one or two tiny games before beginning anything so large.

Why did you choose to go with such a retro-inspired style?

Personally, and this may sound strange coming from me, I feel rather uncomfortable with the word "retro." I'll try to explain where I'm coming from.

I feel that both high and low fidelity art can be effective, each in its own way. It's totally possible to make a stylish, self-consistent game in either category. Generally, I think working with higher fidelity assets allows a lot more freedom, and ultimately I think that's where most of our effort should go. But low fidelity art also has certain things to offer.

Firstly, I think that pixel art (and other restricted art styles) are a great fit for solo or small team game development. By working within constraints, it's possible to make a visually polished game without needing an army of specialists. Another thing that I like about pixel art is its cleanliness. It naturally encourages an even detail level, and it lends itself well to an uncluttered, readable style.

Low-fidelity art is also appealingly open to interpretation. If a character is only eight pixels tall, a large part of what we see is within our own imagination. Is he wearing a hat, or does he have a big nose? Are those tentacles or jointed legs? I played with that a lot in Star Guard. A lot of the art is deliberately ambiguous.

Why do you think the game was so successful in its design? IGF judges aren't the only ones to recognize the game for its tight design.

I haven't developed very many games, so if anyone else has a different way of going about things, by all means listen to them. I don't think there's a single right way to go about designing things.

So far I find it helps me to begin with a clear idea of the feel and activities I'd like to aim for. I try to start with a clean slate and develop the particulars with those goals in mind.

I think you end up with games that are more internally consistent when all the ingredients have been hand crafted to work well together, rather than borrowed wholesale from existing games and jury rigged to work together. You run into trouble when you assume a borrowed mechanic has the same role in an entirely new context.

Recharging health is a decent example of what I mean. Right now, a large number of action games have Halo-style recharging health. This kind of health system is a fairly good fit for cover based, stop and go firefights. It reinforces the feeling that cover is safe and taking the offensive is risky. Is someone shooting? Find cover. Is my health low? Find cover. There's also a fun risk/reward mechanic built in- it's possible to stay out in the open and keep dealing damage, but only if you can successfully dodge enemy fire for long enough to allow the shields to recharge. But while this mechanic works well in Halo, many of the other games that use it don't do so with as much attention to detail- they simply borrow the Halo system wholesale instead of creating a health system which is tailored to the game at hand.

Do you think the "retro" graphics could turn off potential players, or does that even concern you?

Definitely. It's hard to see a game that fits a preconceived category like that and not read a lot into it.

For instance, I think I harbor certain prejudices against Flash games: I'm probably inclined to assume they're rushed, have low quality standards, and contain tedious drawn out tutorials. It's really not fair at all, and I consciously try to be as objective as I can, but that's the prejudice I carry with me.

I think one of the burdens of choosing a low fidelity look is that some people assume the game is small, rushed, or all about evoking a particular era of history. Some people tend to dismiss the visual side of a game entirely if it's low fidelity. I hear statements like "it must be really refreshing to be able to spend so little time on visuals" or "this designer obviously chose to focus on design instead of art." The truth of the matter is that a lot of people who do low fidelity games are very visually focused. I spent a huge portion of the development time tweaking animation, adding special effects, and obsessively redrawing things, but it's not necessarily visible to people who aren't used to looking at crunchy low fidelity games from that perspective.

The narrative pulls you in too. Do you think people are surprised when such a minimalist game can create a compelling narrative? What's the key?

Personally, I think there are a lot of different effective ways of telling stories in games. Some games work perfectly with pages and pages of dialog, and others feel complete to me without any story at all. Both are right.

In this game, I want to use a pretty unobtrusive method of delivery. I want the story to reinforce the atmosphere of the game without impeding the act of playing it. Replay is a big part of what I'm going for here, and I also don't want to force the story on anyone who doesn't feel like reading it.

That's why the story is delivered through short messages on the walls. They're self-paced. It's possible to just run by them without pausing. It's also possible to stop and take them in at a slower pace if we prefer.

Another choice I'm making here is to tell the story in a fragmented way and leave a lot up to the imagination, rather than explicitly spell out all the details.

Were there any elements that you experimented with that just flat out didn't work with your vision?

Yes; for instance, I implemented (but did not use) a type of alien with a reflecting shield. I really like them, but they don't fit with the pace of the game well. They encourage a slower, more defensive style of play.

Also the structure of the game wasn't at all set in stone. The core ideas stayed- the feel, the general way combat works, the pace- but there were some other pretty large things about the game that gradually shifted over time. It wasn't a pure process of designing everything in detail, then executing it.

Have you played any of the other IGF finalists' games? Any games you particularly enjoyed?

I haven't had a chance to play most of the entries. I'm really looking forward to seeing them on the show floor.

The idea behind Miegakure is really appealing to me. (Meigakure involves the three dimensional projections of objects with more than three spatial dimensions.) I'm interested in seeing how well this implementation works. Can many people really model that sort of thing mentally, or do most people end up playing via guesswork? It's a neat idea, and I'm looking forward to seeing it in action.

What do you think of the current state of the indie scene?

It excites me that it's becoming easier and easier to make things. Tools like Game Maker, Construct, and MMF2 [Multimedia Fusion 2] are great, and I think that's only the tip of the iceberg. We still tend to make digital art like games in a very technical way, which is fine I think... but I think there's potential for other more expressive styles of creation too, things more analogous to performing a piece of music or drawing a picture. It's exciting to see new possibilities opening up.

I also want to say that I love how open and supportive the community is. It's really wonderful to see people teaching each other things, sharing techniques, and discussing ideas with each other. That's a constant source of inspiration for me.

[Previous 'Road To The IGF' interview subjects have included Enviro-Bear 2000 developer Justin Smith, Rocketbirds: Revolution's co-creators Sian Yue Tan and Teck Lee Tan, Vessel co-creator John Krajewski, Trauma creator Krystian Majewski, Super Meat Boy co-creators Edmund McMillen and Tommy Refenes, Sidhe's Mario Wynands, who worked on Shatter, Daniel Benmergui, creator of Today I Die, and Klei Entertainment's Jamie Cheng, executive producer on Shank]

For years, and especially during my extremely cumbersome move to a new apartment late last fall, I have been teased mercilessly for A) my harebrained attempts at upconverting older technologies so that they will integrate with new ones and remain functionally relevant, and B) keeping several boxes of "important game history" "stored" on my patio. (I'm not sure what cultural contributions I have packed away in there, but I'm sure someone reading this can relate.)

Aha! And here's author Clay Risen's piece, "Pac Rat: The fight to preserve old video games from bit rot, obsolescence, and cultural oblivion," from the March 2010 issue of The Atlantic.

The column serves really only as an overview of some of the reputable institutions attempting to archive and preserve "documents," "information," and "synthetic worlds," but it has more than its fair share of moments.

From the article:

Video-game preservation is tricky. First, a definitional question: Is a video game just lines of code, or does it include the disk, box, and console? "To preserve an Atari 2600, do you need a piece of shag carpet?" asks [English professor Matthew] Kirschenbaum. He’s only half joking: this year a team at Georgia Tech made an emulator that lets old games be played on today’s computers, but makes them look fuzzy, as if they were on a TV circa 1977.

Because I loathe emulators, I actually really like the idea of this one. I know I am not the only anti-emulation retro gamer around. I have been pro-tactile -- I am for exposed wires, for the clack a cartridge makes as it is worked into the machine's drive, for the rubber bellows at the base of a joystick slowly tearing away -- because these details are part of the fullest experience. So maybe I really do need the shag carpet, too.

But with archiving collections of old, aging games, there is the matter of "getting the games onto stable media" before the code somehow fails or erodes, and here, Clay Risen must be talking about the biggest emulation project ever:

You still need to find devices that can access them. Even big firms are nervous about sharing codes and production details of complex games, which can involve scores of patents. Moreover, games for different consoles were sometimes written in different programming languages; how do you make them universally accessible?

Pac Rat [Via Tiff Chow]

Digital archivist Jason Scott unveiled the beautiful throwback piece you see above as packaging art for Get Lamp, his upcoming documentary on the history of text adventure games and their creators. Illustrated by Lukas Ketner, the same talented fellow behind Panic's Atari 2600 boxarts, this artwork will grace the (two-disc) DVD case's inside three panels.

Scott says he's so happy with the commissioned artwork, he's looking into the possibility of creating high-quality prints and selling the image as a poster. He wants to hear from others, though, on whether they want to be notified if the poster ever goes on sale and what price they would like to pay for it. If you're interested, email him at poster@getlamp.com to sign up for a future mailing with further details.

The director also recently announced that watching Get Lamp is a "partially interactive" experience. Like the text adventures it examines, the documentary stops and splits into multiple directions, allowing different paths through the film. You can choose to ignore the branching feature and watch every clip or have the movie choose different paths for you:

"This is how I can have it have about 3 hours of movie (which is roughly what it is looking like) but not murder the audience. It will also allow you to address the Interactive Fiction story from multiple angles, which otherwise would be competing for your attention.

It will, of course, be possible to skip the interactive portion and just see the different mixes, and it will also be possible to say 'just go ahead and show me that 3 hour movie'. But this potential for having some amount of say on the film’s progress is, to me, part of the nature of interactive fiction, and the movie will reflect it."

You can read more updates about Get Lamp and interactive fiction on Scott's blog Taking Inventory.