Everything in Context

I briefly interrupt this recent series on Twine to announce that I've recently completed a paper draft on my thesis programming language, Ceptre ( pdf, 8 pages ): Abstract We present a language called Ceptre in which we unify the concepts underlying several rule-based game design tools, such as Kodu, PuzzleScript, and Inform 7. We illustrate how to capture common mechanical idioms found in these frameworks, such as movement, item acquisition, and agent-based simulation, without specializing anything in Ceptre to those ideas. By distilling the essence of several systems in one using a small, general set of primitives (based on linear logic), we provide a setting in which to recombine fragments of existing world models and to define new ones, freeing designers from genre constraints and assumptions. Our eventual aim is to implement this language as a prototyping tool for game logics and mechanics. From a PL perspective, this paper introduces the ideas behind forward-chaining li

This  preliminary discussion  introduced my thoughts on using Twine as a tool for creating prototypes for games research. I'll start with documenting my first case study: a hack-and-slash RPG-like setting where the player character has a record of attributes ("stats") that evolve through actions that turn certain resources (money, health, items) into others. I've selected this hack-and-slash example because it falls outside the canonical "branching story" domain thought to be Twine's primary use case, but it is not too much trickier to implement. It relies crucially on the management of state in ways that simple branching stories would not, but it does so in a fairly straightforward way. If all goes well, this post may also serve as a tutorial on the "basics" of Twine (links + variables + expressions). In particular, I'll be using  Twine 2/Harlowe , and I haven't seen many tutorials for this new version published yet. To me, the mai

Recently, someone sent a request over the DiGRA list for experiences and information related to academics learning to make games. I replied with a bit of handwavy proselytizing for Twine , copied (and slightly edited) below: For a surprisingly diverse range of game design logics, Twine makes an excellent prototyping tool for research. Carolyn Vaneseltine writes about using Twine for prototyping here: http://www.sibylmoon.com/ twine-as-a-prototyping-tool/   I'd really like to see Twine in use especially for games *research*, for a few reasons: Deployability. It's absolutely the "most time-effective path" from game idea to "an arbitrary person with the internet can play it." Resilience to bitrot. As long as people care about creating backwards-compatible web standards and supporting JavaScript, Twine games will be playable. If we consider our research to be describing "permanent ideas," then people need to be able to play with those ideas dec