Solo Queue: An Exercise in Serenity

Programming, Video Games

This weekend I committed to finishing a small Twine game I’ve been dabbling with intermittently for the last year. It may seem a little esoteric (and rather silly) if you’re unfamiliar with the game genre being parodied, but hopefully it’ll still convey the general idea.

You can play it directly in your browser by clicking the title below:

Solo Queue: An Exercise in Serenity

Solo Queue is inspired by Dan Bruno’s Time for some Fire Emblem and Alex Austin’s Bioshoot Infinite + 1. I was intrigued by the notion of abstracting a game’s core mechanics into Twine as a form of critique. I wanted to apply the same approach to the lords management game (a.k.a. MOBA) I play most regularly: League of Legends.

While I was fiddling with Twine, I was also working (and eventually had some success) at climbing the season 3 ranked ladder in solo queue. There is a certain inherent insanity in attempting teamwork with four complete strangers. To quote Reservoir Dogs:

Mr. Pink: Why can’t we pick our own colours?

Joe: No way, no way. Tried it once, doesn’t work. You got four guys all fighting over who’s gonna be Mr. Black, but they don’t know each other, so nobody wants to back down. No way. I pick. You’re Mr. Pink.

Succeeding in solo queue requires diplomacy, flexibility and ego management. Ultimately, it’s a lesson in serenity; you must accept that you are going to lose many games regardless of your personal performance or skill.

Solo Queue in Twine

As I’ve indicated previously, I had some troubles working with Twine. In fact, halfway through development I moved the passages to a plain text file and began compiling them directly with twee. I also wanted to avoid mixing JavaScript code with story content, so I stored the macros in separate files and wrote a few quick Perl scripts to append them together at build time. The workflow worked quite well once I’d set all that up; I especially enjoyed being able to easily import Leon Arnott’s excellent Twine macros.

It felt great to work on a hobby game again, though I’d like to attempt something with more systemic mechanics for my next side project. In the meantime, I hope you enjoy my preposterous little game, and to all the League players: best of luck in season 4!

→ 1 CommentTags:  ·  · 

Twine Troubles

Programming

Photo by Daniel Schwen

The interactive fiction platform Twine has been around for many years, but recently it’s been at the centre of the DIY game creating movement. Rise of the Videogame Zinesters heralds it as an accessible development tool for those without programming experience. New voices are joining the game-making world, and the variety of Twine games is truly remarkable: personal games, satirical games, Kafkaesque games, sexual games, and many more.

Inspired by the creativity of this new wave of game makers, I decided to work on a small Twine game as a side project. I read a few tutorials, downloaded the application, and began assembling a story. Unfortunately, I started encountering minor hindrances much sooner than expected. I was digging through forums and documentation to implement functionality that I thought would be trivial. Disheartened, I frequently had to resort to kludgy workarounds.

Here are my four biggest frustrations with Twine:

No Nested Logic

Twine has built-in syntax for linking passages, displaying text conditionally and getting/setting variables. However, the syntax does not allow any of these to be nested. You can’t display a variable inside a link or a conditional statement. You also can’t embed any html inside a link, which makes image links difficult.

// Can’t print a variable in a link
[[Hello there <<print $name>>|Say Hello]]

// Can’t conditionally print a variable
<<if $name eq "Bob">>Is <<print $husband>> feeling better?<<endif>>

// Can’t embed an image in a link
[[<html><img src=”foo.jpg” /></html>|Link]]

The workaround is to write your own html in these cases, instead of using the built-in Twine syntax. You can access the Twine variables and link to passages using JavaScript, though that has its own headaches (explained in detail below.)

Verbose Macros

Twine allows you to write custom JavaScript macros, which is great! The process for doing so, however, is a tad obfuscated and verbose. To make a macro: create a new passage, add the tag “script”, then write your logic in a function with the following template:

macros['randomnumber'] = {
    handler: function(place, macroName, params, parser) {
	insertText(place, Math.random());
    },
  };

That’s the bare minimum script for inserting a random number. Here’s a fancy version with all the bells and whistles:

try {
  version.extensions['randomnumber'] = { major:1, minor:0, revision:0 };
  macros['randomnumber'] = {
    handler: function(place, macroName, params, parser) {
	if (params[0] === undefined) params[0] = 0;
	if (params[1] === undefined) params[1] = 1;
	var n = Math.round(Math.random()*params[1] + params[0]);
	insertText(place, n);
    },
  };
} catch(e) {
  throwError(place,"randomnumber error: "+e.message); 
}

None of it is egregiously verbose, but boilerplate phrases like “handler function place macroName params parser” are daunting. Twine is a great tool for first-time game makers, it would be nice if writing macros was equally approachable.

I also wish it were possible to import script functions from external files. That would allow authors to share and reuse modular components. A library of common functions would be a boon to those without the technical knowledge to write their own JavaScript. Dan Cox has a clever macro for loading external JavaScript libraries, which I’d love to see integrated natively.

File Format

Twine is a graphical interface wrapper for a simple plaintext format (called twee). However, the application saves stories in a .tws file, which is just a Python pickle serialization. Since this format is not human readable, it discourages the use of source control. Why bother tracking your changes when you can’t understand the incremental differences?

Thankfully, there’s an easy built-in way to get around this. In the Twine menu, call File > Export Source Code to export your story to a plaintext twee file. You can even modify that file in a text editor and reimport it back into Twine (though you’ll lose some of your previous passage arrangement).

Weak Documentation

There is some documentation for both Twine and twee. The former covers the basics and the latter alphabetically lists available functions (assuming robust JavaScript knowledge); neither is terribly useful for learning to write macros. I found the answers to my questions scattered across the TweeCode google group, Porpentine’s resource compilation and Dan Cox’s macro tutorials. Here are a few useful tricks I had to figure out the hard way:

Firstly, if you want to link to a passage (named “foo”) from embedded html (e.g. for an image map) use <html><a href="#" onclick="javascript:state.display('foo', this); return false;"> foo </a></html>. (If you neglect to return false, it’ll work on Chrome but not Firefox.)

Secondly, if you set a variable in Twine syntax using <<set $foo = true>>, you can access it from within JavaScript macros with state.history[0].variables["foo"]. You can use this to get around some of the nested logic issues I mentioned earlier.

Finally, a minor idiosyncrasy: Twine does not allow links back to the “Start” passage. Many authors get around this limitation by making a new first passage and displaying it in “Start” with <<display ActualStart>>.

Despite my criticisms, I still think Twine is a valuable and important platform. Fixing certain small issues would simply improve what the tool already does well: provide a accessible way for everyone to make personally meaningful games. Twine is free and open source with a passionate community, so I’m certain it’ll continue to improve and grow.

→ 5 CommentsTags:  ·  · 

The Principles of Programming in SpaceChem

Programming, Video Games

SpaceChem screenshot

SpaceChem is a remarkable puzzle game about fake chemistry. The game challenges you to build a factory in order to transmute the given input molecules into the given output molecules. While chemistry is the theme, on a mechanical level it has more in common with programming. The methods used to tackle challenges in SpaceChem are akin to real techniques used by computer programmers. I’d like to elaborate on these manifold similarities, as well as explore how games like SpaceChem could be used to promote procedural literacy.

The player commands two circular “waldoes” by laying out paths and instructions for them. The waldoes follow the path and sequentially execute any instruction they come across. They can grab, drop, rotate, sync, bond, fuse, request input or dispatch output. The waldo’s analogue in computing is the processor, a hardware component that sequentially executes basic operations defined by machine code. Like processors, waldoes are the engines that drive the control flow of a SpaceChem factory.

When a waldo grabs a molecule, it gains the ability to perform instructions directly on it. In other words, a grabbed element is more readily and rapidly available than one lying elsewhere on the grid. Conceptually this is analogous to storing data in registers, a form of computer memory that is accessed very quickly and that the CPU manipulates directly. Just as a waldo can only grab one molecule at a time, computers have very few registers and must therefore rely on caching.

If grabbed molecules are like data in registers, then molecules left on the grid are cached. The cache is a larger, cheaper form of memory, but it is slower to read and write. Data must be written from the cache to a register in order to be manipulated directly by the CPU. The amount of memory in SpaceChem’s “cache” is governed by the area of the grid (8 x 10). Each coordinate on the grid can therefore be considered a unique memory address. This analogy is enforced mechanically: a factory “crashes” if two atoms collide on the grid, since you can’t store two values in the same memory address.

SpaceChem screenshot

Each factory has two waldoes, and they must be properly coordinated as they move through time and space. This coordination is facilitated by the sync node, which tells a waldo to wait until its twin has also hit a sync node. Parallel waldo management is akin to parallel programming, and they share the same perils: deadlock, starvation, race conditions, etc. The waldoes are like threads operating on shared memory space, and sync nodes are functionally similar to semaphores (operations that tell threads to signal and wait.) Operating two waldoes simultaneously in SpaceChem forces the player to confront the same shared resource problems as parallel computing.

SpaceChem and programming involve similar challenges: laying out simple instructions to achieve a complex result while managing limited time and resources. Like a good software specification, each puzzle is clearly presented as a black box defined only by its inputs and outputs. The player lays out instructions, starts up the factory, observes errors and corrects them, iterating until the puzzle is solved. Solutions can then be further optimized to take less time and use fewer instructions. SpaceChem and programming are engaging, flow-inducing activities because they have an identical inner loop: implementing, debugging and optimizing.

At this year’s GDC, Michael John asserted that programming is 21st century literacy. If computer programming is currently considered esoteric knowledge, it’s because our general education is not preparing students to think about problems in an algorithmic or systematic manner. Ian Bogost calls this procedural literacy: “the ability to reconfigure basic concepts and rules to understand and solve problems.” SpaceChem may not be an ideal game for the classroom (it’s far too difficult, for one), but it strongly suggests that the best way to learn about and engage with complex systems it to play with them.

→ 1 CommentTags:

No Fun Games – CUSEC DemoCamp

Programming, Video Games

Back in January, Henk, Thomas and I presented two games we were working on (Norwegian Wood and an alpha build of Pax Britannica) to the DemoCamp at CUSEC 2010. DemoCamp is a really cool informal event where programmers can show off what they’ve been hacking on. The rules are simple: 15 minutes maximum, no powerpoint, show working code!

I think the talk went really well, we got by with some laughs and a little bit of casual swearing. Big thanks to the CUSEC organizers, host Joey DeVilla and A/V tech Guillaume Theoret for giving us a chance to show off our games!

Tags:  · 

Postmortem: Norwegian Wood

Programming, Video Games

The project that became Norwegian Wood began in late April of this year. With school winding down and the weather heating up, I felt the itch to tackle something new. By chance I had met a number of like-minded people over the winter; students with big ideas and aspirations of working in the game industry. Inspired by this collective potential, I decided to reach out to my local friends and colleagues about coming together to make a game over the summer.

The response was overwhelming; of the nine people I had e-mailed, seven of them were interested in participating. The project was suddenly much larger than I had anticipated, but I didn’t have the heart to turn anyone away. The eight of us (Henk Boom, Thomas Hibbert, Phil Jones, Renaud Bédard, Alex Charlton, William Mitchell, Kyle Sama and I1) formed the facetiously titled collective No Fun Games.

Pulp Characters by Phil Jones

You might be surprised to learn that our original game idea had nothing to do with music, shoot ‘em ups or The Beatles. While we explored a number of different game ideas, we settled on creating a murder mystery game set in an JRPG-style lumber town. We gave the development version the nickname Pulp2.

Pulp‘s main character was “Penny”, a local girl with a knack for mysteries. She teamed up with retired Sherlock Holmes analogue “Detective Powell” to solve the murder of his former partner “Dr. Watson” (we never really settled on official names). You can see Phil’s concept art for some of the characters above.

We developed an elaborate back story which outlined the motivation behind the murder and its connection to the protagonists. However, our ideas for the game’s actual plot and structure were little more than a skeleton. Truthfully, we possessed neither the inclination nor the talent to write good fiction and this was ultimately the game’s downfall.

No Fun Games - Pulp

On the programming side, we put together a basic game engine in Python with the help of the Pygame and PyOpenGL libraries. It gave us the bare essentials, allowing us to add actors to the screen and assign them behaviours. As seen above, we created a simple world for Penny to run around and interact with (the Fez spritesheet was placeholder art lent to us by Renaud).

Sadly, this is as far as the Pulp project ever got. Despite our best intentions, we drifted apart over the summer. Everyone had personal commitments, internships, and travel plans. We simply didn’t have the time or motivation for leisure coding. By July, Pulp had reluctantly become vapourware. Fortunately, this wasn’t the end of No Fun Games.

By late August, things in my life were starting to slow down. I was back living in Montreal (after spending the summer at IBM in Ottawa), and had a couple of weeks off before the fall semester. Blessed with free time, I decided to reconnect with my teammates for a final sprint. Naturally, we wanted to release something after all our hard work.

Of course, not everyone had the luxury of time off. While we all wanted to participate, only Henk, Thomas and I had the hours to spare. Our artist Phil was also interested, but couldn’t commit to the heavy art demands of the murder mystery concept. With this in mind, we decided to drop that idea and reuse the engine we had created to pursue an entirely different genre.

Branching Pulp into Norwegian Wood

The concept for Norwegian Wood came from our desire to explore the burgeoning intersection of music and gameplay. We wanted to create a game where listening and following the rhythm played a strong role in the player’s experience, but less directly than a game like Rock Band.

This idea manifested as a shoot ‘em up game where the bullet patterns are timed to the individual instruments. The decision to use The Beatles’ music was somewhat incidental; I happened to be listening to Rubber Soul when the game concept occurred to me. However, the song has certain qualities that make it rather ideal. For instance, the notes are quite discrete, making it easy to divide the instruments and record timestamps. More importantly, using a calm lilting ballad with subtle dark undertones contrasted nicely with the upbeat synth-metal used in most shoot ‘em up games.

Norwegian Wood Prototype

Henk, Thomas and I got together at school to work on the game, working nearly full time for two weeks. We managed to create a playable prototype within a few days, then put the majority of our work into refining and iterating on the core gameplay. We also placed a strong emphasis on player feedback, bugging everyone around us to playtest it.

After chasing down the cross-platform bugs and ironing out the details of deployment, we finally released Norwegian Wood in late September. Thanks in large part to friends on Twitter spreading the word, we’ve had thousands of hits, hundreds of high scores and some very positive feedback. We’re thrilled that so many people have enjoyed our game, and promise to put all that excitement right back into making more of them.

To summarize Gamasutra-style, here are some lessons we learned during development:

What Went Right

1. Working Together Locally
While most of the work on Pulp had been completed remotely, it came at a cost to communication and motivation. For Norwegian Wood we decided that there is really no substitute for face-to-face time and met up in person every day. This was extremely effective, both for making consistent measurable progress and sharing a common creative vision.

2. Recording Global High Scores
The online high score table was a minor last-minute addition to the game. However, as Eric Swain pointed out in his insightful Indie Spotlight, it added a ton of value in terms of competition and replayability. “Even after all these years and innovations it is still a huge motivation to play. [...] It isn’t all about competition, but the close knit community that get formed in that competition.”

3. Sidestepping Copyright
It took a lot of thinking to come up with a way to release a music game without infringing on The Beatles’ copyright3. Despite our doubts, having the user provide their own mp3 turned out to be a very successful strategy. Of course, it’s a shame that we picked the one band whose music can’t be downloaded legally. In the future, we’d very much like to reexplore this concept with Creative Commons licensed music.

What Went Wrong

1. Big Team Woes
Starting out with such a large development team on Pulp was a major challenge. Responsibility was spread too thin, and no one felt like they had creative control of the game on an individual level. In retrospect, I would recommend a team of no more than 4 for your first indie collaboration. Furthermore, it helps to have a fairly autocratic team leader.

2. Summertime Blues
I had assumed that summer would be the perfect time for students to pursue a side project. Working nine to five at an internship means having evenings off and lots of free time, right? Sadly, I was way off. The temperament of summer is lazy and leisurely; it’s hardly a season for picking up additional work. Furthermore, working full-time turns casual hacking into an unpleasant chore. Counter-intuitively, students would much rather attempt side projects while they’re juggling exams and assignments in the fall.

3. Storytelling Failure
We were incredibly naive about the process of writing a story for Pulp. We had the big picture ideas and the game mechanics, and just assumed that the moment-to-moment narrative experience would flow from that. We quickly discovered that writing a good story is an extremely demanding task, one we were ill-equipped to handle. Lesson learned: if you insist on having a narrative element to your game, make sure you have a dedicated writer (or semionaut) on the team.

Thanks again to everyone who was involved in Norwegian Wood, including those of you who playtested it and helped spread the word on release day. Making this game was a terrific experience, and it taught me a great deal about game design, programming and project management. I look forward to applying these lessons to my next game!

1 Ben Abraham was also briefly involved as music director, he wrote us a lovely dirge for Pulp.
2 Funny how Pulp turned into Norwegian Wood. The arboreal theme is coincidental.
3 Actually, Nick suggested this approach. Thanks Nick!

→ 8 CommentsTags:  ·  · 

© 2007-2014 Matthew Gallant, hosted by A Small Orange, powered by Wordpress, theme based on Basic.