Profile cover photo
Profile photo
Bill Burdick

Post has attachment
If anyone's interested in a religion system for TFT, I'd really appreciate feedback for this toolkit. I posted about this elsewhere and one person linked to it but now that there's a Game Design category, I wanted to post about it here...
Theurgy Toolkit
Theurgy Toolkit

First post here! Yes!

Post has attachment
Theurgy Toolkit: cleric rules for The Fantasy Trip

After Metagaming closed shop, it left a lot of quasi-announced items unpublished. One of these, called for in the July/August, 1981 issue of Interplae, was a "Religious Rules Module" with constraints that there shouldn't be any "gods that have any effect beyond what is done for them by their worshippers", "religion on Cidri is what you make of it, not what gods do," and no "separate and special form of magic" should be created.

After reading a long thread on the SJG forums about priests and theologians, I decided to create a religious rules module that was indeed based on a very separate and special form of magic, that feels "religious," and that doesn't overlap with or feel like wizard magic -- "theurgy". So it completely flies in the face of the third constraint. I think priests should NOT be reskinned wizards although they shouldn't crowd them out, either.

As for the first two constraints, those are supported, but optional. What I've created doesn't dictate terms to the GM, it's entirely up to them what sort of role gods play at their table (or even if there are gods). If you run an athiest game, theurgy can be simply a different form of magic. But if you want your version of Cidri to support stories with gods, you can do that, and theurgy can help you. It's your game.

Post has attachment
chr15m on GitHub Has another active Wisp fork!

Things Chris has done:

Merged some of the PRs that look sensible.

Compiled an easily downloadable, minified version people can use in their browser.

Tried to make the introduction and interactive repl friendlier.

Post has attachment

Why Wisp?
Wisp integrates well into dynamic computing environments because it generates clean, straightforward JavaScript and gives you lots of information so you can post-process it effectively

Compared to ClojureScript, Wisp acts more like an alternate JavaScript syntax. A reference to map in ClojureScript compiles to "cljs.core.identity", but in Wisp, it compiles to "map". Wisp's code generation is more like using direct linking for AOT code generation in Clojure.

The Wisp compiler returns a result rich in information, including three asts and the JavaScript sourcemap. We use these objects to post-process compiled code in all sorts of ways. Using this information, we were able to integrate Wisp in with Lounge's idea of modules and code results without much trouble at all. Also, we're using a special Scope class that lets us inject and change private JS variables so you can effectively edit and run Wisp code.

Some background: we have integrated Wisp into Lounge, which is Leisure's computing environment. Lounge is a long-term project we've been working on since 2011, to experiment with collaborative, web-based computing and something we're calling "illuminated programming".

Our current Lounge project is a MUD, hearkening back to our school days in 1988, when we wrote one in Lisp and let people all over the world into it (I think it even 12 people playing at one time!). I chose not to develop it in Leisure because Leisure is still very experimental and I didn't want to spend the whole time fixing language bugs while everyone else got to write the fun code.

For those interested in Leisure and Lounge, Leisure is here

but check out the latest commits because you may find interesting things there. At the time of this writing, the "mud" branch is where the action is:

Pattern matching and substitution for Wisp
Pattern-based let and defn and a pattern macro

I'm working on this now for my own environment, code is here: Currently it works for (arbitrarily nested) atomic values (strings, keywords, symbols, booleans, numbers), dictionaries, vectors, and lists. I'm eventually going to make pattern matching modular, so you can add support for more types.

If enough people are seriously interested in this, I'll be happy to put it in a separate project. I think this is fairly compatible with ClojureScript and Clojure as well but my experience with them is limited.

Some examples...

p-defn defines a function with pattern arguments

(p-defn get-name [{:name name}] name)

pattern is a macro that creates a pattern function you can use for both matching (one argument) and substitution (two arguments).

Matching takes an object and returns a dictionary of the variable names in the pattern that matched the object or nil if the pattern did not match.

Substitution takes an object and a dictionary and creates a deep transformation of the object with values of the pattern's variables that are in the dictionary spliced into the object. It returns a one-element vector with the result in it or nil if the pattern did not match.

((pattern {:name n :age a}) {:name "fred" :age 12}) --> {:n fred :a 12}

((pattern {:name n}) {:name "tom"} {:n "joe"}) --> {:name "joe"}

Using these, I've defined p-let, a pattern-based let and p-defn, a pattern-based defn. Eventually I'll probably do p-fn and p-defmacro.

Vector and list patterns do not yet support & but I plan to add that soon.

Post has attachment
Add a comment...

Post has attachment
Add a comment...

Post has attachment
Add a comment...
Wait while more posts are being loaded