A novel style of programming

It's been a few years since I did the regular blogging thing.

I was in Japan, working at Square-Enix for a bit, now I'm back in the states, and working on a sort-of interactive fiction engine called "Sashimi" (さしみ、刺身 ?) My hope now is to start writing a bit about the development process. I tend to write a lot for my own sake when coding something new; so I figure, why not share?  ( Sashimi itself, for what it's worth, is all open-source. )

I say Sashimi is "sort-of" an IF engine because my ultimate goal is to create a system for writing in a straight-forward IF fashion which can drive a variety of modern game styles far beyond just text adventures. This follows from my feeling that while developers, over the last ten years or so, have created awesome reusable libraries for graphics, physics, sound, animation, etc. what we haven't managed so well is the gameplay side of things.

In fact, when people talk about "engines" they almost invariable mean "graphics." Gameplay tech largely comes after the fact, using scripting languages like Lua, Squirrel, or Python; with Unity it's C# ( or EMCA/Unity/Javascript ), with Unreal it's Unreal Script and Kismet.

The world of graphical editing -- like Kismet, connecting lines and boxes to form logic -- is definitely cool, but I feel inevitably limited. Those sorts of systems tend to create large complicated graphs that are hard to untangle, hard to debug, and hard to reuse.

Kismet Examples
cool, yes. but what's going on here exactly?
And, even those graphical editors tend to replicate a certain amount of C-like iterative programming, if-this-then-this linear flow.  Occasionally LISP-like ( Jax and Daxter ) alternatives show up, or concurrent procedural objects ( Eve, and stackless Python ) -- but we are largely "skinning" variants of the same languages over and over.

That -- for me -- is where interactive fiction comes in: bending modern times backwards to look at alternative ways of implementing gameplay that mostly have been left behind.

That "mostly" is important. Because there are some really interesting paradigms out there, first and foremost of which is Inform7.

If you haven't seen Inform before, take a look. It's literally the only place where something like: "North of the Hallway is Freedom. Instead of going north from the Hallway when in darkness: say 'You stumble and cannot find your way.'" is actual code. To repeat: those two sentences compile. It runs.

For instance, how about:
The candle-stand is a supporter in the Palace. The description of the candle-stand is "The candle-stand is a tall metal branch for holding lights, but someone has added casters to the bottom." It is pushable between rooms. Three candles are on the candle-stand. Instead of removing something from the candle-stand: say "[The noun] is fixed quite firmly in place."
Or, for something slightly more mathematical in nature:
A weight is a kind of value. 10kg specifies a weight. Everything has a weight. A thing usually has weight 1kg. A container has a weight called breaking strain. The breaking strain of a container is usually 50kg. Definition: A container is bursting if the total weight of things in it is greater than its breaking strain.
I find this fascinating.  Beyond the English text ( which, at times, I have found difficult to write correctly ) there's something much deeper at... play. 

An Inform script asserts the existence of the world into being. It tells simply what *is*, and the compiler does the work of making that do something useful.

For the most part, a writer of Inform does not define strange classes and variables in a syntax arcane. In a few sentences, a writer sums up what might be hundreds of Kismet mouse clicks, or a handful of source files including the occasional candlestand.cpp.

One of the more interesting side-effects of this style of "asserting" means that -- just as C-programmers eventually got to move their local variables down from the top of every function to the point in the code where they are actually used -- in Inform, new classes of objects can be described at the point they are needed, not separated into some special class definition syntax space.

And, as long the script does not contradict itself --
A person can be asleep or awake. The Spinning Tower is a room. Sleeping Beauty is an asleep woman in the Spinning Tower.  Sleeping Beauty is awake.
Problem: You wrote 'Sleeping Beauty is awake' , but in another sentence 'Sleeping Beauty is an asleep woman in the Spinning Tower' : this looks like a contradiction, 
-- a writer can add new properties to objects at any time; where ever seems most natural.

To put that all another way:

Instead of forcing some programmer to organize a script for the sake of the computer, an author writes in a more human-friendly flow: a novel style of programming. It's the computer -- the tools -- which work to collate and correlate the script -- providing type indices and story overviews -- for the sake of the author.


Merging assertions, databases, and other techniques ( I've not even begun to scratch the surface here regarding what's cool about Inform ) with the tricks of the trade from AAA development can yield new ways of building game worlds.

Not just new for the sake of new, but new for the sake of more reliable, richer, deeper, better games.

0 comments: