Plan 9 from User Space

Space Glenda
Plan 9 from User Space
Plan 9 from User Space (aka plan9port) is a port of many Plan 9 programs from their native Plan 9 environment to Unix-like operating systems.

Plan 9 offered a fascinating service-oriented extension of the UNIX "Everything is a file" metaphor, treating the keyboard, the mouse, services on the network, and even individual UI elements in windows as pipe-able files. See also http://plan9.bell-labs.com/plan9/index.html .

Gamasutra - Features - A View Toward a Game Developers Guild

What would a Game Developers Guild (GDG) look like? Would we want such an entity? Would it hobble the world of game development with the kind of "not-my-department" surliness many associate with unions? Or could it be a tool that game designers, developers, producers, and unions can use to move game development into a new paradigm?

This recent Gamasutra post on the subjects of a game developers' guild (like the SAG) and a game production company (like a movie production company) seemed quite relevant to some of the ideas that have been floating around USC's IMD recently with respect to changing models of game production.

Action Button Dot Net - Prototype (**1/2)

People throw around the term “overpowered” because they’ve been abused for so long they don’t know what fun means. Prototype is the sort of game that abuses them.

...

I’m convinced that there was a time during its development when Prototype was one of the best games ever made. It has since been rendered into paste to make it similar to every other bullshit thing where some dude climbs walls and kills people with super powers.

The inimitable Action Button Dot Net reviews Prototype, and in the process considers the special kind of suffering that some games inflict upon the player: where a game fosters unhealthy codependence between player and game system, abandons mystery in favor of spoonfeeding, and arbitrarily limits the space of play.

Ascii Dreams: Towards a Moral Code for Game Designers

I suggest there should be a moral code for game designers: one which provides clear examples of the boundaries of which a game design should be careful straying beyond. This code should say nothing about the content of games: I'm not interested in whether a game offends religious or ethnic groups, could be considered pornography or explores issues which would be illegal in real life such as rape, pedophilia, murder or drug use. It would however, have everything to say about the way the game mechanics work so that we have a common platform to criticise games for breaking the code unwisely.

To construct such a moral code requires a dialogue between designers, about what is appropriate and inappropriate in game design. We can all point at grinding as the whipping boy of bad design, but as I pointed out in Permadeath, there is a delicate balance to be struct between grinding and necessary exploitation. I'd like to throw open the floor to comments, sugggestions and criticism, but I'll include some quick suggestions with which to start the discussion.

Andrew Doull suggests in this post and his follow-up that game developers should avoid operant conditioning and related families of mechanics that are "addictive" or "time-wasting" for the sole objective of keeping users in the game. Whether you agree with him or not that designers have ethical obligations about their players' time spent, the discussion is nutritious.

Editing executable code

...select a Lava construct for insertion by clicking an associated tool button. You need not know its syntactical structure in advance: LavaPE will insert a "template" of that construct for you which exhibits its syntactical structure and contains placeholders for nested constructs that you may insert subsequently.

Optional parts of a construct can be deleted or reinserted if required.

The description on this page isn't the strongest, but the idea of a structural code editor is very powerful. The benefits are clear: no syntax errors, customizable syntax representation, easier provisions for refactoring, etc. Bringing this design into the 21st century with modern search tools, UI paradigms, and shininess could be quite valuable.

Game Design Advance » Games Are Not Media

Games Are Not Media

Posted by Frank Lantz on 30 Aug 2009 at 09:53 pm | Category: Opinion

clearchannel

At last year’s GDC I spoke in Richard Lemarchand’s microtalks panel, the theme of which was “my idea of fun”. In retrospect, I should have talked about competitive Galcon which is, in fact, my idea of fun. But instead I made the dubious decision of giving a 5 minute presentation on the idea that games are not media. Since then, I have been asked several times to provide a better explanation of this rather strange claim, so I’m going to give it a shot.

I should start out by explaining the purpose of the claim. It’s meant to be a provocation. I want to challenge certain habits of thinking and talking about games. I’m not attempting to clarify a small point about our critical language or clean up a detail about our conceptual framework. I want to give these things a rude shove and shake us out of a bunch of comfortable and familiar assumptions so that we can look at games with a fresh eye.

I’m not going to present a carefully constructed definition of the word “media” and try to show that games don’t fit. Instead, I want to point out some common associations the word tends to conjure up and show how games challenge them. I know it’s difficult to talk about games as a subject without using the word media. I find it hard myself, and I’m sure there will be many situations in the future where I’ll use the term. But when I do I will feel an uncomfortable twinge that will remind me of the ways in which the word is a poor fit, and I hope to instill a similar impulse in you.

Frank Lantz delivers a strong defense of his assertion that the word "media" is a poor fit for what games are. He presents four assumptions that are connoted by the term and how they fail to apply to games, and pleads for a moratorium on—or at least a reduction in—the word.

ZZT - Wikipedia, the free encyclopedia

ZZT's graphics were obsolete before it was even created; it used the same style of text-mode graphics that Kingdom of Kroz used 4 years earlier. However, ZZT managed to become fairly popular because of its integration of a simple but effective object-oriented scripting language known as ZZT-OOP. At the time this was groundbreaking, as most functionality in prior games had been hard-coded. The language allowed extensibility that no other game was able to provide, and allowed a large degree of community involvement that extended far beyond simply creating level terrain with the built-in editor, but rather involved writing programs to make the game run.

It's awkward to link to Wikipedia, but ZZT is an example of what seems to be a fairly accessible—or at least, an extremely long-lived—game-making game. Its systems are object-oriented and its domain, though fairly limited, still provides for some surprises from its devoted developer community.