inlist: intrusive linked lists for go

Surprising, not surprisingly, choose any two, the go community doesn't seem to have any intrusive linked list implementations. I'm currently working with data that has an html/dom like structure, i don't want to expose all of the existing code to a new container structure, and it would be nice for elements to have direct access to their siblings  -- all in all, a classic use case for intrusive lists.

After searching around a bit, the few i could find were incomplete or experimental attempts. This example, by Lex Sheehan, is nice; but, it's a tutorial, and it ends by introducing go's standard library list implementation ( which is not intrusive. )

So, i decided to write one myself. Package inlist ( via GoDoc, and github ) is a port of the go standard library list package. It hews close enough to the original that i could use the same test code with some tweaks necessary to support the intrusive changes.

See full post...

issues with go const

Here's a nice little gotcha. In go, "enums" are often defined using the iota generator like this:
type DaysOfTheWeek int

const (
 Sunday DaysOfTheWeek = iota
The downside, of course, is that when you want to print those values:
fmt.Println(Sunday) // prints 0, would rather it print "Sunday"
While the "stringer" code-generator is the recommend way of handling this, I'm often tempted to simply change the declaration:
type DaysOfTheWeek string

const (
 Sunday DaysOfTheWeek = "Sunday"
 Monday               = "Monday"
 Tuesday              = "Tuesday"
 Wednesday            = "Wednesday"
 Thursday             = "Thursday"
 Friday               = "Friday"
But, this is wrong in an important way.
Assertions, and reflection will fail.
import "reflect"

func ExampleDay() DaysOfTheWeek {
    return Friday
func main() {
    fmt.Println(reflect.DeepEqual(Friday, Friday)) // true
    fmt.Println(reflect.DeepEqual(Friday, ExampleDay())) // false!
We expect that both statements return true, but in fact the second statement is false. If you are using testify, an assertion on the value will also fail.
func TestSomething(t *testing.T) {
    // passes, these are the same type and same object.
    assert.Equal(t, Friday, Friday)
    // fails, these are of different types!
    assert.Equal(t, Friday, ExampleDay())
The reason is that DeepEqual requires types match, and that the definition of const lists, in effect, resets the type declaration for each line containing an equals sign.

In the first const example, using iota, there's only one equal sign: so all of the constants get the same type.

In the second const example, even though we started the list with Sunday as a type of "DaysOfTheWeek", the presence of the equal sign on the line which declares Monday resets the type declaration engine to its defaults. In this case, a string. So, only Sunday is of our enumerated type. Monday-Saturday are all of type "string".

Now, while ExampleDay() says it returns our enumerated type, Friday's actual type will never change. It's always and forever string. The fact the compiler lets this pass seems to violate the principle of least surprise, but there might be other common cases where this behavior makes more sense. ( While go is strongly typed, the way it handles literals and other edge cases sometimes leaves me wanting for warnings. )  I was writing off-the-cuff. Go underlying types only apply to interfaces, not primitive values.

The issue, then, for reflect.DeepEqual(Friday, ExampleDay()) is that the first parameter, Friday, is of type "string", while the second parameter, ExampleDay(), is of type "DaysOfTheWeek". The types don't match and DeepEqual returns false. Testify assert, which relies on reflect, therefore also fails.

If we redeclare our const list:
const (
 Sunday    DaysOfTheWeek = "Sunday"
 Monday    DaysOfTheWeek = "Monday"
 Tuesday   DaysOfTheWeek = "Tuesday"
 Wednesday DaysOfTheWeek = "Wednesday"
 Thursday  DaysOfTheWeek = "Thursday"
 Friday    DaysOfTheWeek = "Friday"
Then reflect, and asserts, will work as expected:
func main() {
    fmt.Println(reflect.DeepEqual(Friday, ExampleDay()) // true!
func TestSomething(t *testing.T) {
    // passes, these are of now the same type!
    assert.Equal(t, Friday, ExampleDay())
Unfortunately, unlike with iota, there's no pretty way to declare all of those strings without repeating the type. The closest we can get looks like this:
const (
 ParamTypeBlob ParamType = "ParamTypeUnknown",
Which is error prone, and looks a little gross with the default go formatter, but is at least easy to generate, and more importantly: it's correct.
See full post...

Galactic Travails

Lately, I've been working on an experimental text adventure engine, and a 2D adventure game built on top of that engine: "Alice and the Galactic Traveller."

A month ago I managed my first beginning-to-end play-through, compiled a few pages ( you know, only 12 or so.... ) of notes and issues, and identified a few critical story and user interface issues I want to fix before beginning to share it around. I just now finished up on the most important of those, and need to start testing on the AppEngine version.

"Alice" is a point-and-click based game. The code is split into two main parts, a Go-language backend and a browser-based Angular JS front end. The engine also supports command-line text adventuring, although the parser is extremely bare-bones: ordered lists matched against regular expression commands.

Currently, the graphical bar is also fairly low. All art is sourced from other people's Creative Commons and public domain work: namely Liberated Pixel Cup,  Skorpio's "Sci-Fi Pack", Sithjester's tiles, Sheep Art, Font Awesome's icons, and Glitch. Oh yeah, and nothing animates.

Part of the point of keeping the graphics simple has been to keep focused on the game itself. The design of engine, however, allows for arbitrary front ends that can be plugged on to it. I'm impatient to write a standalone Unity ( or, Lumberyard ) version -- but, I'll also need some more appropriate art.

In the long term, I have lots of ideas for both the browser front-end and the engine. The high concept would be an open-source web-based platform where anyone can easily make graphical point-and-click games; a visual editor to formalize some of the ideas raised by declarative scripting, subtext, and data scripting. I would like to put together full examples for stories like A Day for Fresh Sushi and the Cloak of Darkness. I would like to experiment more with engine fundamentals like relationships and queries, event filters, prototypes, object states, scenes, and chapters. Add visualizations of play. I could go on.

For now, I'm doing what can only be called the slog. Staying focused on making a fully playable game demo -- even if the graphics and the highfalutin tech ideas have to sit by the wayside... for now.
See full post...

Multi-core CPUs, the internet, testability, and text adventuring.

What in the world does AAA game technology have to do with text adventures? In my view, quite a lot. But, it takes a supporting trip through web development, and maybe some unit tests, to get there.

The web is data

I’ve long been curious about how to apply lessons from web development to the making of games. Games used to lead the way in new techniques and technologies -- but now there are plenty of leading edges out there: web, mobile, search, social, ar, robot drones, private space industries; it’s a big list in computer-land these days.

Games may be keeping pace ( sometimes just barely ) but game development hasn’t.

Take a look your current project. Can you easily validate every car has a proper set of physics values? Can you quickly present graphs comparing “rate of fire” versus “character level”? Can you show every encounter on a Google maps version of your world? Can you record the falling death of every member of your QA team? ( Virtual death, I mean, virtual death. If your QA team is jumping out windows, you may have other more serious problems.)

There are plenty of teams which don't have access to this kind of metadata. Plenty of teams which can’t process and test this kind of information in an automated way.

See full post...

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.

See full post...

Genetic State Trees

I’ve just moved to Tokyo and I start work at Square-Enix next week. My frequency of blogging is inconsistent at best, and will probably only get worse. I doubt I’ll be able to blog about anything I’m working on, and work generally provides the inspiration for my posts.

At any rate, today I just want to jot down some ideas I had while on the plane: a sketch of a method to use genetic techniques to evolve statechart based AI behavior.

First, some quick background: City Conquest, by Intelligence Engine Design Systems, is a tower defense game with some real time strategy elements, and Paul Tozour -- one of the company’s founders -- wrote a program called Evolver which was used extensively during development.

See full post...


Quick, computer. Do something useful.
I've been doing research for a new post on scripting with data, and my favorite find today was this picture lifted from a presentation on subtext.

On one side of the image: a programmer working hard to figure out what the heck all that code does. On the other side: a computer sitting idle, doing nothing but displaying text.
So. True.

See full post...