Thanks to a tweet (in Spanish!) from Zona Fi, I have learned of not one but two series of adventure games being written in my toolkits for building Scott Adams-format adventure games!
The first is written in ScottKit, the newer and better of the two:
It is Jason Compton’s Ghost King, an interpretation of Shakespeare’s Hamlet, which you can play online at Netlify (though I can’t find a way to download it). Continue reading
After the recent sequence of ScottKit tutorials (building games, rooms and items, actions, occurrences, darkness and light), there remain only two major concepts left to introduce: counters and saved rooms. But before we launch into those, we’ll take a break and look at some standard bits and pieces we’re likely to include in most or all games. We’ll use the same map as last time, since we’re making no major changes:
Last time out, we learned how to have things happen to the player in ScottKit; that was the natural complement of the player doing things, which we covered the time before. Today, we’ll use that knowledge to deal with darkness, light, light sources, and their expiry and refilling. Here’s the expanded map:
Last time we looked at how ScottKit games handle the player’s actions. But sometimes you need actions to happen independently of what the user does. If you’re in a frozen wilderness, maybe there’s ten percent chance each turn of freezing to death; or if there’s a thief here and you’re carrying a crown, he might steal it.
That’s what we’re going to look at this time. Here’s the map for today’s version of the game we’re working on:
Last time, we saw how to make rooms and items in ScottKit. We used these to build a small but not completely trivial game with three rooms, in which you can move through from the start room to where a coin is found, and bring it back to where you started.
Now we’re going to see how to use actions to code up puzzles. Here’s how the map of the game is going to look when we’ve finished with it today:
As you can see, the rooms and exits are basically the same as the map for the previous iteration, But we’ve added a couple of items and — crucially — the first puzzle.
Last time, we learned how to write, build and play games with ScottKit. But the game we made was absolutely trivial: two rooms, connected. The only thing you could do in the game was to move back and forth between the two rooms — and even that only worked because GO (and the six directions acting as verbs) are built-in commands. This time, we’ll expand the game: here’s a map of the expanded version.
Compared with last time, we’ve added one more room (the cell) and our first two items. One of the items is a treasure, as indicated by its name starting with an asterisk.
So, I finally published ScottKit. Now what? What can you do with it?
You can build your own games, that’s what! Adventure games of the GO NORTH, GET LAMP, KILL TROLL variety. If that seems limited to you, consider that the same mechanisms can easily underlie games in any setting, and with any theme. It’s a style of gaming that gets you a lot of game for relatively little work: for example, the source code for Scott Adams’s own classic Adventureland, as decompiled with scottkit -d, comes to only 22 Kb.
The original late-1970s artwork for Adventureland. In those days, any kind of cover art was unusual: quality was not always assured.
I’ll write more about the charms of this kind of game creation in a subsequent post, but today I want to get you started in creating games.
Those of you who have been reading this blog since 2nd March 2010 — just three days after the blog was born — might remember the fourth post I ever made here: Learning a language vs. learning a culture, on my switching from Perl to Ruby. Way back then, I wrote about “ScottKit — my first non-trivial Ruby program”. Here it is!
I’ve been aware in a backgroundy kind of way of IFComp for a long time. It’s an annual competition for Interactive Fiction (IF), a genre of computer games that are based on text — though, within that rubric, many forms are included: not just traditional text adventures, but hypertext “games” and choose-your-own-adventure branching paths.
This year, inspired by the efforts of Jason Dyer on his excellent IF blog Renga in Blue, I am playing and judging some of the entries myself. (Anyone is allowed to judge: there are no qualifications and only a few rules.)
Spellbreaker is the climax of the Enchanter trilogy, preceded by Enchanter and Sorcerer. Unlike its predecessors, it is ferociously difficult — though most of the solutions feel fair, once you realise what they are.
But, boy, is it hard. With this one, I followed the maxim Cheat Early, Cheat Often, and I don’t regret it one tiny bit.I read a ton of invisiclues, and at one point resorted to a walkthough in the hope of finding the exact command I needed to get past a problem I had already solved. In the end, I wanted to experience Spellbreaker more than I wanted to beat it. And beating it would have taken months or years, if I managed at all.