Posts

Showing posts from March, 2013

Modeling gameplay in Celf, Part 3

(This is another iteration of the example I developed in  Part 1  and  Part 2 , but barring incrementally understanding the code, I think this post is relatively self-contained. Celf-contained, if you will.) When I took a simple choice-based ("CYOA") game with a few bits of inventorial state and tried to add handles onto the rules so as to specify a specific sequence of player choices, something interesting happened: I had to make new decisions about which parts of the game  the player could control, and how. For instance, whether they win or get eaten by a grue depends on a prior choice to take the lamp from the den or not; they cannot control their fate after that point. This makes clear that "getting the lamp" and "opening the door" are player-facing game controls, whereas "getting eaten by a grue" is a choice made by the game. We wound up enumerating those actions as follows. 'start : action. 'opendoor : action. 'getlamp : a

Modeling gameplay in Celf, Part 2: Simulating Interactivity

Where I  last left off , I gave a toy example of using Celf to specify a game's causal structure, summarized by the following ruleset: start_to_den_or_cellar : start -o {den & cellar}. den_to_cellar_lamp_or_key : den -o         {cellar          & (nolamp -o {getlamp})          & (nokey -o {getkey})}. get_lamp : getlamp -o {gotlamp * den}. get_key : getkey -o {gotkey * den}. cellar_to_den_or_door : cellar -o {den & opendoor}. open_door_without_key : opendoor * nokey -o {cellar * nokey}. open_door_with_key : opendoor * gotkey -o {dark}. dark_with_lamp : dark * gotlamp -o {win}. dark_without_lamp : dark * nolamp -o {lose}. init : type = {nokey * nolamp * start}. As presented, this is effectively "half a game", with no delineation between player choice and game logic -- a fact that allowed us to randomly sample the space of all possible play sequences by querying any final gameplay state -- but that's ultimately uninformative about interact

How to create the PL culture I'd like to believe we deserve

I herein interrupt my (ir)regular schedule to post about something sociological rather than metalogical. I considered relegating this content to my personal blog, but honestly I think these words need to fall on the ears of exactly the folks who are mired enough in the technical community to follow research blogs. This is a post about "PL culture". What I mean by that is the characteristics, defined by the perceptions of its constituents, of "the PL community" -- or any subset of active programming languages researchers who find themselves in each others' company, perhaps at a conference or within a research group at a particular university. In particular, I want to understand how PL might be failing  as a community, and by that I mean either (1) fostering attitudes that make people within it feel othered/alienated/estranged or (2) serving as a barrier to the potential  people and ideas it could include but doesn't. I want to cast some attention on the e

Modeling gameplay in Celf, Part 1: Fuzz Testing

Image
I'm hereby resolving to stop biting off more than I can chew wrt blog posts - I've got two behemoths in drafts over just the past few days and nothing to show for them (yet). So right now I'm going to try to carefully explain a tiny example that I just worked out over the past half hour and I think nicely encapsulates a few ideas about using Celf and linear logic in the context of interactivity. Assumed background for this post: familiarity with linear logic connectives, some familiarity with logic programming and the forward/backward chaining distinction. Here's an informal spec for a simple branching game with a couple pieces of global state that track whether certain paths have been taken: The cellar and the den are connected rooms. The lamp and the key are in the den. The cellar contains a door, which is locked and must be opened with the key. Once the door is unlocked, the player enters darkness, and if they have a lamp, they win; otherwise, they are eaten by