Search Results for: ios

Hadean Lands on sale this week!

You may have noted that Steam has launched its Thanksgiving sale. It's not Black Friday yet; I dunno, maybe it's Purple Wednesday. They don't tell me these things.

Anyhow, Hadean Lands is part of this sale. My first Steam sale! Until Nov 29th, you can buy the game for 35% off. Exciting times indeed.

While you're at it, you might want to nominate your favorite text adventure for the Steam Awards. Interactive fiction winning such an award in the braoder gaming market? Sounds unlikely, doesn't it? I guess we'll find out!

We do not neglect other platforms! I've applied the same 35% discount to Hadean Lands on Itch.IO, the Humble Store, and the iOS App Store.

(Yes, the iOS version has a lower base price. That's just the way things are right now.) (Also note: due to the way Apple prices bundles, the "Zarf's Interactive Fiction" bundle is not available this week.)

...Oh, and since somebody is going to ask: no. The Steam DLC Solo Adventurer Pledge Certificate is not discounted. Discounting the certificate would only make it less valuable. Sheesh.

Posted in Zarfplan | Tagged , , , , , , , , | 2 Comments

The irritating case of Hadean Lands pricing on Steam

(Cases that are "curious" are as overdone as things "considered harmful". This one is just a nuisance, but I still have to solve it.)

When I started planning HL for iOS, I figured that I'd charge $5. It wasn't a casual-tiny price, it wasn't full-on-desktop-game. (2010 was early in iOS history but we could already see what "race to the bottom" meant.) I wrote up the Kickstarter page and offered $3 as the basic backer pre-order level -- "a $5 value!" So that was pretty well locked in.

During development I decided to release the game for Mac and Windows as well, but I kept the $5 price point. I'm not sure I had any hard logic for this beyond "I don't want to think about it." With a dash of "nobody will complain if it's the same price everywhere." I've had a couple of limited-term sales, but HL has basically been $5 since it launched.

Now I'm (slowly) approaching a Steam release. Scary! And worth revisiting my old assumptions. Should I raise the price?

(I'm not lowering the price, don't be silly.)

The good example on everyone's mind this week is Stephen's Sausage Roll, which launched with a $30 price-tag and an equally brazen attitude of "I'm worth it". Or, more, precisely: "Do you want this particular kind of puzzle? Are you going to jump up and down on it until your knees catch fire? If so, I'm worth $30 to you. Everybody else, just walk on by."

Also, as my friend Chris noted: "if this was a $5 game i'd just put it down and say 'whatever, too hard' [...] but being invested means i have to play it." Buying a game is buying into the game. We all know this, but the difference between $5 and $30 really throws it into the spotlight.

So maybe this all describes Hadean Lands too? Parser IF is niche appeal in a nutshell. Maybe I should kick it up to $7 or $10 on Steam. Or more?

I asked around my IF friends, and several of them said sure, they'd pay $10. Of course, they all own the game already, so it's not exactly a useful sample!

Many factors collide here.

  • What price? Dare I go beyond $10?
  • Do I also raise the iOS price?
  • Do I also raise the Mac/Win price? (On Itch.IO and the Humble Store.)
  • I'm adding the journal and map features (which exist on iOS but have never been seen on Mac/Win). I could say it's an "enhanced version" because of that.
  • I'm also fixing some minor but long-standing bugs. It's probably asinine to call it "enhanced" on that account, though.
  • I really don't have time in my schedule to extend the game in any way (beyond the journal and map UI).
  • When it comes down to it, will Steam users come after me in a torch-bearing mob for raising the price of an already-released game? Or is "new to Steam" good enough?

(But one major point of the "I'm worth it" strategy is to signal to the torch-bearing mob to go elsewhere, because they wouldn't be interested in the game to begin with! SSR has a delightfully high rating on Steam, because it's only purchased by people who want it.)

Comments? Opinions?

Posted in Zarfplan | Tagged , , , , , , , | 17 Comments

Pocket Storm for the new Apple TV

I'm happy to announce that Pocket Storm for the Apple TV is now available in the new Apple TV App Store. Apple's new set-top box ships today, and you can get your favorite thunderstorm on it.

To find it, open the App Store app on the TV's main screen, select Search, and enter STORM. (Or POCKET, or ZARF -- the text search is actually pretty good.)

Better yet -- if you've purchased Pocket Storm for iOS, you can download the Apple TV app for free! And vice versa. It's a joint purchase, which means you can buy it once and then install it on any iOS or tvOS device you own.

As always, I am donating 10% of Pocket Storm revenues to, because of the awesome service they provide to indie game designers and other artists. In particular, they provide CC-licensed thunderstorm noises to me!

Posted in Zarfplan | Tagged , , , , , , , | 1 Comment

Pocket Storm on sale today

(If I was sensible I would have posted this last night...)

I just kicked Pocket Storm 1.1 out to the App Store, and to help spread the news, I'm lowering the price to one dollar -- today only. Call it Thunderstorm Friday! (In real life it's just drizzling out there in Boston, but with technology, we can do better.)

I got the download size down below Apple's 50-meg limit, so you can install the app over 3G now. There are a handful of other small improvements. (The fade-out timer behaves more sensibly now; you can use headphone controls on PS; and I plugged in the necessary vacuum tubes for the new iPhone 5 display size.) But app size is the important change. Apparently people make impulse purchases -- who knew?

And, as before, I am donating 10% of Pocket Storm revenues to, because of the awesome service they provide to indie game designers and other artists. In particular, they provide CC-licensed thunderstorm noises to me! Thus far Pocket Storm has not been a huge moneymaker, but I am hoping that over time, people support it.

Posted in Zarfplan | Tagged , , , , , , | Leave a comment

Pocket Storm

I am delighted to announce Pocket Storm -- a generative audio environment for your iPhone, iPad, or iPod touch. Pocket Storm is my first Boodler project for iOS.

It starts with a calm summer night. Soon you'll hear thunder in the distance, then wind and a spatter of rain. After half an hour you'll be in the thick of the storm. By the end of the hour it will have faded into the night again. Then the cycle begins again.

The Pocket Storm is not like other environmental audio apps. Every thunderstorm is different! Wind, rain, thunder -- even chirping crickets -- every sound is chosen from a library, with subtle variations of pitch and timing. The Pocket Storm weaves these elements into a tapestry of sound which will never repeat.

Here's my Pocket Storm web page; or snarf it straight from the App Store.

Boodler is an open-source soundscape project which I invented years ago. Boodler is designed for any kind of complex audio environment -- weather, traffic, alien worlds -- but I've never developed it as it really deserves. The Pocket Storm is my first attempt to bring Boodler to a consumer audience.

Rather than trying to sell a complete "Boodler for iPhone" app, I'm taking the approach of do one thing, very well. So Pocket Storm is a one-hour thunderstorm, which plays as background audio. Or you can stream it to AirPlay. You can set the timing as desired, or adjust the weather manually. There's also a timer option, if you want to go to sleep to it.

Audio samples from Pocket Storm, at different stages, are posted on the web site.

Owen Williams created the first Boodler thunderstorm soundscape, more than a decade ago. My app doesn't use his code, though, nor the old Boodler sound samples. I've built an all-new thunderstorm -- or rather, a set of thunderstorm variations -- using sounds from the project.

The sound libraries that I've compiled for Pocket Storm are now posted on the Boodler web site. (They're all Creative Commons Attribution, Sampling Plus, and Zero licenses.) The agents (source code) that assemble the sounds are not currently available; as usual, I'm trying to find a balance between open-source work and secret sauce. But you are, of course, welcome to compose your own Boodler thunderstorms from these sounds, or use Owen's original.

(Speaking of which: a percentage of the App Store revenue from Pocket Storm will be donated to the Freesound project.)

Posted in Zarfplan | Tagged , , , , , , | 4 Comments

Hero Tracker is now in the App Store

Icon 512I am pleased to follow up with my last app-release announcement post to announce another app I made. This one is Hero Tracker, a player aid for Hero Academy — which, yes, is the subject of the post before that.

The timing catches me a little by surprise because the app spent a couple of extra weeks in limbo while Apple tut-tutted and waited for me to secure permission from Robot Entertainment to make use of their game’s name and art assets like this. But I did, and the app spontaneously went live late last night, a few days after I forwarded Robot’s acknowledgment to the opaque machine of switches, pulleys, regular expressions and interns that manage the App Store’s approval system.

As its description on the App Store states, Hero Tracker is a free, simple tool for iPhone and iPod Touch that lets players track the progress of their active games, mainly to note which pieces have been played by either side. I admit that if someone were to pull something like this out during a face-to-face strategy game I’d look at them funny, but since turns in Hero Academy might be days apart, I feel no qualms about using a memory aid like this with it.

That counts N-ple when one is playing several games in parallel, a situation which Hero Tracker handles gracefully. So now I can remind myself with certainty that the Council player who finally took their turn after a fortnight is out of Inferno spells but still has one high-powered Cleric in reserve. I can calculate the chance that that Cleric sits on their rack, ready to deploy next turn, and plan my own move accordingly.

FAQ: How does it know what pieces you have played? Does it update itself automatically while you play?

Nothing like that, I’m afraid. It’s entirely manual in operation; after either side commits a move, you must call up the app and decrement that side’s remaining-supply section accordingly. You can also jot down notes about the game in a textfield for this purpose, available underneath the supply tables.

If that sounds cumbersome and inconvenient, I respectfully suggest that you haven’t been in my position of having no idea whether the skillful opponent you’ve been battling with for five weeks has a healing potion left or not, while fully aware that such knowledge would determine whether you make an all-out attack or a more conservative play. Hero Tracker scratches this itch, and so I made it. I’ve been using it happily (and alone) for the last couple of weeks, and now I share my secret with you.

Image credit: Hero Tracker icon, drawn by Yours Truly, using the wondrous Paper app.

Tagged , , | 2 Comments

The Warbler's Nest: now available for iOS

I am pleased to announce the release of my interactive short story The Warbler’s Nest for iPhone, iPad, and iPod Touch. You can find it in the App Store for 99 cents American (or your local equivalent thereof). The original, free web edition of the game remains playable, but this native app brings enough unique and lovely features specific to a touch-based and text-philic platform that I hope you’ll find it worth your dollar.

It comes to you by way of Zarf’s iOS Fizmo, the open-source framework he released to the world in May as a milestone of the Hadean Lands project. I ship this new edition of Warbler in a similar spirit to Zarf’s re-release of 2004’s The Dreamhold alongside iOS Fizmo. Much as that game served as a reference implementation of sorts for the new framework, I hope mine to act as an early test case of selling modern interactive fiction on contemporary, touch-driven platforms.

I hope you have the chance to play and enjoy the game in this new format. If you do, then I would be thrilled and humbled were you to leave a brief review in the App Store as well.

Tagged , , , , | Leave a comment

Why I love Hero Academy

Robot Entertainment’s Hero Academy is my favorite new videogame of 2012, and far and away the best original-to-platform tabletop game I have enjoyed on iOS. I have felt more intense highs and lows playing this strictly player-versus-player game than any other videogame of the last year, to the point where it rekindles my interest in tablet games and their potential for great multiplayer experiences. Beyond that, I admire the publisher’s sales approach, and hope that it becomes a model for other game studios to follow.

On reflection, the fiero that fills me when a Hero Academy sally goes well (and the hunger for same I feel when things go badly) is identical to the thrill of a face-to-face boardgame that’s really engaged my attention. I credit this to Hero Academy’s various smart design nudges that make starting (and, subsequently, managing) games with real-live opponents a pleasure, doing it better than any cardboard-to-digital adaptation I’ve seen so far. It helps remind me why I tend to treasure my experiences with great multiplayer games far more than any solitaire game.

Hero Academy presents a simple two-player wargame with fantasy-RPG trappings. Players alternate turns of five actions apiece, maneuvering pieces on on a shared nine-by-five grid. Each player has a Scrabble-style rack of seven available pieces they can play, hidden from their opponent: some combination of heroes (this game’s equivalent of chessmen), powerups that affect individual heroes, and one-off magic spells. Playing a piece to the board counts as an action, as does moving a hero already on the board. To win, a player must accomplish one of two goals: either eliminate all their opponent’s heroes, or destroy all their opponent’s “victory crystals”, tough but vulnerable targets located on the opposite half of the board. Generally, one accomplishes this with one’s heroes, all of whom have move-and-attack patterns that vary with type, and many of which have extra powers such as healing allies or weakening distant opponent pieces.

While heroes have “hit points” and animatedly bonk each other with swords and lightning bolts and such, the game contains none of an actual RPG’s dice-rolling: the outcome of every move is transparently deterministic, and the game takes pains to make every action’s modifiers (such as a powered-up weapon or an on-board defense-boosting square) clearly labeled, effectively preventing any unwelcome “why did that just happen?” moments. A Knight unit, for example, will always deal base damage of exactly 200 to an enemy hero or crystal. If he’s on an attack-boost square, that will add 100 points, but if the target’s player has equipped it with armor, it’ll reduce that blow’s damage by 60 points.

These sorts of stacked modifiers can get a bit hairy, so the game softens the risk of analysis paralysis by giving the current player a safe transactional space to experiment with their five allotted actions. They can spend, take back, and re-spend them as many times as they like, exploring the full possibility-space of their current position until they settle on a satisfactory outcome, at which point they tap the “Submit Turn” button. I find this an ingenious way to let players feel like they are always in control of their game — not once have I ever felt that I ended a turn too early by accident, the way that I quite often do with other turn-based iPad games.

Taking a cue from tabletop games like Brawl, each player starts play by selecting a “team” that is essentially a bag of pieces (or a deck of cards, if you like) of predefined composition. There are (at present) four available teams, each themed around various western fantasy tropes; everyone starts with the Council, comprising a familiar fighter/wizard/cleric/ranger quartet, along with a selection of healing potions and fireball spells. Other teams, like the steampunky Dwarves or the goblinoid Tribe, feature different loadouts of heroes and equipment, and are acquirable as in-app purchases. Robot clearly cares about keeping all these teams mutually balanced, and very occasionally releases mandatory updates that boost or nerf various units’ capabilities a bit to keep things even.

Players don’t have control over what they draw onto their rack, either at the start of a game or after their turn, when they replace played pieces. These are essentially blind draws from a bag containing their remaining pieces, and this represents the sole purview of luck in Hero Academy. The fixed teams keep this from being an exercise in total randomness, however; wise players will know the composition of both teams, track both contestants’ expenditures, and plan accordingly. To me, this feels just right: play remains satisfyingly strategic, with just enough unpredictability to keep things tense and give weaker players a fighting chance, but not so much that good play ever goes unrewarded. (I think often of Greg Costikyan’s excellent lecture on the role of luck in strategic games, when I think of Hero Academy.)

Hero Academy takes the correct approach among turn-based digital games in welcoming asynchronous (a.k.a. “play-by-mail”) play; players are free to quit the app and attend to other matters at any time, and the game will continue as long as they take their turn within a week or two of their opponent’s last move. (Terminal slowpokes are punished with an automatic loss, though the game is nice enough to pop up an iOS-notification warning about imminent forfeiture.) To mitigate the waiting-time brought about by opponents selfishly having a life, Hero Academy allows one to play many games in parallel, giving you an easy and obvious UI to hop between them. I find my play-style to be rather bursty, taking a bunch of turns across a bunch of games, and then letting the whole thing stew for a few days. I’ve been playing this way for months, and it’s lovely.

The game has no AI players, which I find a bold and interesting move on the part of the designers. There’s no reason inherent to the rules of a turn-based game like this to omit them, and in fact their absence initially seemed quite counterintuitive to me, particularly given the amount of care and polish that went into this work; the conventional wisdom for digital strategy games states that they must always offer a single-player mode. Hero Academy, however, wants you to always play against other people, and if you don’t have a friend to play with, it directs you to start a new game against a random opponent. (Or, indeed, ten new games against random opponents.) Enough people play this game that such requests get filled quickly, and with each instance you’re playing against a wholly unfamiliar mind who might possess any skill level and play style possible. I find the turn latency that human opponents require a price worth paying for the unscripted uncertainty they also bring.

A downside of this, combined with Hero Academy’s pricing structure, means that any random game you start is likely as not to be against a brand-new player, taking the title for a trial spin. In many cases, these players will take between zero and three turns before deciding the game’s not their thing and walking away, handing you a thoroughly unexciting victory when the turn-timer expires several days later. But even though this might happen with as many as half of the random-opponent games I’ve start, I forget them quickly because the other half of the games I start take up all my attention, by virtue of their actually playing out. (And, I have to admit, I can’t complain too loudly about a few low-effort notches on my tally-stick…)

Hero Academy also represents the best, least exploitative implementation of the quote “free-to-play” unquote model I’ve experienced. Downloading the app costs nothing, includes the Council team, and lets you play as many online games with it as you like. This includes games involving one of the three other team flavors — you just can’t use those teams on your own side until you pony up. (Each one costs US$2.) The result feels less like an incomplete demo and more like a fully functional base set with available expansion packs, a strategy from the tabletop world — except, here, much less expensive for the customer, with no initial monetary investment at all. While the app is not shy about its in-app wares, I never felt hassled to buy any. I became a paying customer only after playing several games against a variety of teams with the base set, winning a few and losing a few, and knowing with certainty that I really liked it.

Naturally, I’m curious how well this strategy is working out for Robot Entertainment. I imagine that players who love the game as much as I do join me in buying all the available teams, as well as a couple of additional one-dollar tchotchkes like alternate team colors or player avatars. I don’t know how many players are like me, but I do note that the game’s reviews in the App Store are overwhelmingly positive. I don’t see a single upvoted one-star review inveighing against the outrage of in-app purchases, which seem to haunt so many other games and apps that take this route. I have to guess that’s from a combination of waiving the entrance fee and delivering a polished product that really sweats the details of presenting a great multiplayer experience. I do hope it succeeds and encourages many more works using a similar model: selling in-app purchases not through cynical psychological ploys, but by publishing genuinely fun and rewarding work.

Posted in Essays, Jmac on Games | Tagged , , | 7 Comments

Apple's turn-based game API (and what it needs)

As I have alluded in some blog post or other, I've been working on an iOS port of the board game Fealty, designed by R. Eric Reuss. For the project, I chose to use the "turn-based game" API which is built into iOS 5.

(This is part of the GameCenter toolkit, aka GameKit; but not the whole thing. The original GameKit, in iOS 4.1, supported achievements, leaderboards, and peer-to-peer games, but it didn't have a system for turn-taking games. That came along in iOS 5. Just to be clear about the background.)

Building a game using Apple's API was kind of an adventure, which I may document on this blog someday. But the thing is, Jmac and I spent 2005 and 2006 building a platform for these sorts of games, with servers and APIs and everything. It was called Volity; it was very clever. (We weren't nearly so clever about PR, which is why nobody used it, which is why we took it down a few years later, which is why I'm not linking to it.)

We are not Apple, but we are gamers, and our Volity system is more general than Apple's toolkit. It can be used for more kinds of games. This blog post is my attempt to rattle off the differences. Not for bragging rights (Volity is down today, GameCenter is up, end of story) but to point at features that GameKit will (I hope) adopt in future releases.

Here's the one-line summary:

Volity supports Rock-Paper-Scissors. GameKit doesn't.

Okay, it's implied by the name: Apple's API is for turn-based games. RPS doesn't involve taking turns! But we thought it was one of the fundamental game models of the world. (The others were Tic-Tac-Toe and Hearts.) If you can implement those, you should be able to implement all strategic games. Our system covered it. Apple's doesn't.

What's missing? Basically, Apple's turn-based API presumes that it's always the turn of exactly one player at a time. The game starts up with one player in the hot-seat, so to speak. That player gets to decide What Happens Next. The game absorbs that move, updates its state, and puts a new player in the hot-seat. Continue until game over. A player not in the hot-seat cannot affect the game at all (except by dropping out of the game entirely, which is always possible).

It's clear enough why Apple chose their model. It's simple, and it bypasses all synchronization questions: only one player has the write bit at a time. It requires Apple to run a game server, but the server doesn't have to run game-specific logic; it just coordinates the hot-seat. All of the game logic (deciding what happens and who plays next) runs on the device of the hot-seat player.

But RPS doesn't fit this model. Instead, both player decide on moves independently. The game doesn't care who moves first. When both moves have been submitted, the game absorbs them and decides the outcome.

To cope with this, Volity just didn't have a turn model at all. Players submit moves, which are valid or not. (We offered sample code for strict turn-based games, because it's a common case; but it wasn't wired into the platform at all.)

Of course you can do RPS in a turn-based way. You just keep the moves concealed. First it's Alice's turn to pick a move, then it's Bob's turn, then the game reveals the moves and decides the outcome.

But this doesn't generalize very well. Many board and card games have this sort of parallel-move structure. Consider Werewolf: a bunch of players sit around and vote. When votes reach a majority, the day is over. Or Charades/Pictionary variations: someone posts some kind of picture, and the first player to submit a guess gets a point (or not). It comes up in Fealty, for that matter -- all players choose a card to play and reveal it simultaneously. It's common; the underlying architecture should support it.

You may say, well, Werewolf is a real-time game -- it should be using the real-time GameKit API, not the turn-based one. My point is, Apple draws this sharp line between synchronous games (all players logged in at the same time, all players can move in parallel) and asynchronous (players can log in and out freely, but exactly one player has the hot-seat at a time). Real gaming doesn't have this distinction. Games have parallel phases, and one-at-a-time phases, and some games have both. Really, it's just players submitting moves. Any strategy game can be played "real time" or "by email". Werewolf or RPS by email is slow, but so is any other game-by-email.

(In case it's not clear, when I say "logged in", I mean "the app is running and authenticated with GameCenter". A player logs out either by exiting the app or sleeping the device.)

It's true that you need one device to be in charge of game state. You don't want the central server running game logic. That would involve Apple running third-party apps on their server, which is just asking for abuse. (Volity's solution was for the game designer to run his own server, but it could be a really simple server -- just a Perl or Python process hanging out on the Internet and processing game moves. It didn't have to coordinate player communication or anything like that. This was very clever, but I understand if Apple doesn't want to go there.)

This isn't a huge problem, though. You just pick one player to be the game logic hot-seat, and relay all moves to that player. It's a common enough model in real-time games. (Easier here, because latency can be seconds rather than milliseconds.) Occasionally a player logs out and you have to switch hot-seats, but that's fine. And you have to think about race conditions in the moves. If Alice keeps changing her mind about her RPS move, and sending updates to Bob's device, one of them might arrive after Bob has made a decision (and ended the game). None of these are difficult situations to deal with; you stick on some sequence numbers and allow a move invocation to return a "sorry, the game has moved on" error.

In Volity, we found that it all worked, as long as you remembered to keep the game UI clean. You select a move, push the "that's my move" button, and the game doesn't do anything special with the UI. Just keep everything in place. It doesn't even have to react to the "sorry" error response. When the game-logic sends a new move state, that's when the UI updates. (Again, a latency of a few seconds is fine.)

With a little bit of care, this can all be made a superset of the current GameKit functionality. That is: if the game sticks to a one-move-at-a-time model, the player hotseat is always the same as the logic hotseat, and it works the way it does today. If the game decides to permit more players to submit moves, you have the generalized model.

Timers and clocks and off-moves, oh my!

This architecture has other advantages. For example, you can build a chess clock: run out a timer on somebody else's turn. (Either to force them to forfeit, or just to skip their turn.) That's currently tricky: if the other player logs out during their turn, nothing can force their turn to end. If you allow the game-logic hot-seat to jump to whoever's currently logged in, the problem goes away.

(If nobody's logged in, then nothing can happen, but that's fine -- if nobody's logged in, nobody cares! The next time a player fires up the app, the game logic runs and all the necessary timeouts will be handled.)

This is a real-life issue. In the original iOS version of Ascension, if your opponent abandoned a game, your only choices were to keep the incomplete game on your list forever, or hit "Forfeit". Neither feels right. Recently, the designers added a game-clock on every game. Now, whoever abandons a game gets credited for forfeiting. This is a clear improvement, but you can't do it with GameKit as it stands today. (Ascension uses its own server and protocol, although it ties into GameCenter for authentication.)

Here's another advantage: since any player can submit a move at any time, you can implement chat! A chat message is a just a game move that doesn't update the game state (except for the chat display on each player's screen.) Not every game would want this, but it's important for Werewolf and other such party games.

You also want a feature like this for trading games, and games with trading components. (Settlers of Catan, M.U.L.E...)

As long as we're discussing Ascension...

Yes, Ascension is pretty much the gold standard for iOS turn-based games right now. As far as I'm concerned. (Ignore the awful menus for now.) So here are some features that GameKit should suck into its turn-based API:

  • Display a list of open invitations. (As opposed to silently matching people up and starting the game.)

I fire up the online game list. I see open games featuring "Steve621", "RoboMaster", and "OpenAsshole". Guess which one I'll decide not to game with. Even in a game system with no chat, I like having this social context.

Also, in a game with variations, I like being able to browse and see what variations people are offering to play. GameKit has a notion of game variations -- it only matches up games with identical playerGroup values -- but you have to pick one and post an invite. You can't browse, and you can't post a general invite (covering several game variations.)

  • Display whether your opponents are logged on or not.

Is that slowpoke contemplating a move, or disconnected from the network? Or contemplating a move in a different match? Ascension shows this as a three-value status indicator. It's good to know.

  • Allow spectators in public matches.

Ha! Gotcha! Ascension doesn't have this -- but Volity did. You could browse a list of in-progress matches (if they weren't marked private), and jump in on any of them. You got all the (public) game status updates. It was generally easy to program, because the UI code is already built to receive game status and display it; you just have to disable the move controls.

(I should probably make a reference here to Isotropic and its vast repository of online Dominion match records. Not exactly the same deal, but close.)

Okay, enough blathering. I'll probably think of two more feature as soon as I post this; that's always the way.

Tagged , , , , | 4 Comments

Meanwhile update -- and a one-day sale

I've just released an update to Meanwhile. Is this exciting? I hope it is, because this release contains new high-definition artwork. Digitally remastered from Jason Shiga's original files!

(I've always wanted to say "digitally remastered". One has fewer and fewer opportunities these days.)

On iPhone 4 (or other retina-scale displays, such as the newer iPod touch) you will see a sharper, clearer Meanwhile. You can also zoom in farther than before, a full 2x, to see this art in all its detail.

Older devices (such as iPad 1 and 2) cannot display the sharper artwork at normal zoom. But you can still zoom in to 2x to see the high-resolution art.

To celebrate this, I am offering Meanwhile for a impulse-buy-delighting $0.99 -- for today only. Jason and I think that the app is its own best advertisement -- everyone who plays with it is immediately in love with the design. So, we want more people to play with it. Pass the word around to your friends.

Posted in Zarfplan | Tagged , , , , , , | Leave a comment

Meanwhile for iOS is available

Last week, I wrote:

In other news -- or rather, the news I started with: Meanwhile has been sent off to App Store review. If nothing goes wrong, it will be available Tuesday, November 8th...

Nothing went wrong, and so Meanwhile is available, right now, in your local iOS App Store.

Full press release is below the cut.

And Hadean Lands? It's on my "make progress every day" list now. I should have the puzzle structure completely outlined by the end of this week. That's a small step, but comforting to me.

Zarfhome Software is pleased to announce the release of "Meanwhile for iOS". Jason Shiga's acclaimed interactive comic is now a truly interactive app for iPad, iPhone, and iPod touch.

On the way home from the ice cream store, little Jimmy discovers a mad scientist's wonderland: an experimental mind-reading helmet, a time machine, and a doomsday device that can annihilate the human race. Which one would you like to test out first?

Jason Shiga's graphic novel redefined the "choose your own adventure" format by combining artwork, story, and pathways into a looping, branching narrative structure -- a story in which your choices are surrounded by the cloud of possibilities you didn't choose. Now he has redesigned "Meanwhile" for the infinite canvas that iOS provides. The entire story is woven together on a single, enormous page. You can follow the pathways, or zoom out to view the entire structure at will.

"Meanwhile" is set in a mad scientist's laboratory, but it is grounded in probability and the Many-Worlds theory of quantum mechanics. To decipher the full story, a reader will need a grasp of logic and an eye to the playful possibilities of changing history. (Or, indeed, an ear! "Meanwhile" is fully playable through VoiceOver, making it one of the few graphic novels accessible to the visually impaired.)

Zarfhome Software is Andrew Plotkin's new studio for interactive fiction, narrative experiment, and things you haven't seen before. Zarfhome was launched last year with an astonishingly successful Kickstarter effort, and is now pursuing several projects, including "Hadean Lands".

Posted in Zarfplan | Tagged , , , , , , | 3 Comments

The part where I tell you about Meanwhile

Two months ago (gad!) I said:

After I ship Hideout, I will be concentrating on [Secret Project] M37, because it too is just about finished. (And the paperwork is just about settled...) Even though M37 isn't IF either, I promise you will be excited and you will understand why I made time for it this past spring.

My Secret Hideout shipped last month, and the secret project remained secret. Because sometimes it really does take a month for the last contract details and then another month to get all the paper signed. So it flows. But now it is October, and I can finally say...

Meanwhile for iOS will be released this fall. It is a collaboration between Jason Shiga (the author of Meanwhile) and myself. And it will be awesome.

(Footnote: these are production screenshots. There will be some changes before release, particularly in the buttons.)

Okay, I can't promise you will be excited. I'm sure some of you are saying, "What the heck, this is a comic book. You are not a comic book guy. You are an IF guy."

I can only reply: I picked up Meanwhile at PAX East in 2010. (My blogging cohort Jmac posted about it at the time.) I immediately fell in love with it -- a thoughtful, beautifully-designed take on the Choose-Your-Own-Adventure genre. When I got my iPad, I immediately said "That. I have to do that. In people's hands. Interactively. It will happen."

But these are generalities. What is Meanwhile?

On the way home from the ice cream store, little Jimmy discovers a mad scientist’s wonderland: an experimental mind-reading helmet, a time machine, and a doomsday device that can annihilate the human race. Which one would you like to test out first?

This is of course a great story hook. But look deeper.

The basic idea of a branching narrative is context-free -- if two branches come back together, the book can't remember how you got there. Some CYOAs ask you to keep track of items or stats, but it's a hack and a nuisance. Basically, the CYOA model is poor at stories where you focus on a problem, explore it, and try many approaches. CYOA stories really want to, well, branch out and take you to new situations. (See Sam Ashwell's ongoing posts about classic CYOA books.)

(IF, of course, is for precisely this -- you explore a problem and try many solutions, most of which will fail.)

Now look in particular at Meanwhile, at what Shiga has done with the CYOA concept. Each story element is about context. The helmet lets you loop back through a character's memories and see what's happened from a different point of view. The time machine lets you loop back through events and change them. And the doomsday machine -- well, something has to kick off the plot.

So you have this problem -- the destruction of all humanity -- and multiple ways to approach it. It wedges experimentation into a CYOA model. Since it's ultimately an intellectual problem, story branches can merge together; your history is what you've learned, not what you've done.

This is already cooler than 90% of the CYOA books I've seen. But because it's a branching comic, Shiga has a whole range of artistic tools that the old books never considered. Two story branches can be laid out in parallel on the page. You can't jump tracks, but you are aware of one path as you follow the other. Panels can be juxtaposed and contrasted. You can see storylines as you flip pages. Again: context. Even on your first run through the story -- which will almost certainly end badly -- you get a notion of your goals, your options, and the chances that you missed.

All of that works on the printed page. What does it gain from the dynamic, interactive form? Fluidity, I'd say. You aren't bogged down with the mechanics of page-flipping and line-tracing. You can zip forwards at a natural reading speed, and then back up easily, without the accumulation of finger-bookmarks that CYOA books invite.

Also, you can zoom all the way out.

So that's why I had to do Meanwhile for iOS.

Beyond the enthusiastic handwaving, I should probably answer some obvious questions about this.

The book is organized in pages, but this app uses a giant square layout. Did I rearrange it?

No, Jason Shiga did. I originally prototyped this as a page-turning app, following the book layout. When I pitched it to Jason, he said he loved the idea, but did I think maybe it might work better as a single giant scrolling page? Like in this photo?

I said, heck yes.

Is the artwork and story identical to the book?

Almost identical. A couple of panels have been updated.

All the secret stuff is there. But the secret codes are different. If that's what you're asking. Heh.

Why "Secret Project M37"?

The book has 37 full-page spreads of artwork. I originally prototyped this as a page-turning app, see... no, I've already told that story.

Does it work on the smaller iPhone screen?

Sure does. You can see less of the surroundings, so there's less context -- it's not as cool. But the experience comes through.

(Again, screenshot does not final button design.)

The web site says "Voiceover enabled". Is this really a comic book readable by the visually impaired?

Sure is. If you turn on the iOS text-to-voice mode, it will read out each panel as you reach it, and then read the choices for the next panel. You can navigate the whole thing with standard Voiceover gestures.

(Fortunately, this is a very talky comic, so I didn't have to describe a lot of action!)

Could this interface work for other comics?

Maybe. Are there any other comics out there like Meanwhile?

This interface took a lot of tuning to get right. I didn't just slap yellow squares onto Meanwhile. (There's a blog post in that design story, eventually.) So the code is very specific to this book. But I am interested in other interactive storytelling projects, and maybe this code will be adapted to something else someday.

How long will it be before Meanwhile ships?

As I've said, the delays in this project have an up side: the thing is practically finished now. There will be final design decisions, and beta-testing, and of course Apple takes a week to approve apps. But I anticipate getting this thing into the go-pipeline in early November.

And Hadean Lands?

I realize it's frustrating that my last word on the subject was in August, and was "no change until the current project is done". And then I've been silent about the current project.

But the silence is over, the project is almost over, and it will be IF time again soon.

What does that mean? Well, several things. The past year has made clear to me that I need to have several project-trains moving at the same time; and (to jump metaphorical tracks out of the frying pan) I need fingers in several pies at once.

I started out 2011 thinking that Hadean Lands had to be my big money-making breakout. That was, in truth, kind of a paralyzing notion. But it was also kind of illusory. Here I am; I've finished one project, nearly finished another, and I also have some iPad contract work lined up. (Not story-related; it's a board game port.) None of these projects now has to be The One That Succeeds And Pays My Rent Forever. But they all could be. (Okay, not My Secret Hideout, probably.)

Thus, I retreat from a promise: I will not be working on IF full-time for the rest of this year, or next year. I apologize for that. But I will be working on IF again, and that includes Hadean Lands.

The iOS interpreter engine is in better shape than the HL game design. So it is likely that I will ship some of my old IF as iOS apps before HL goes out the door. I'll start with The Dreamhold, probably -- as a free app. (I'm not going to charge money for a game that's been free since 2004. Plus, it's already included in iPhone Frotz. Plus, one goal is to stress-test the iOS interpreter code. Gonna get a lot more coverage with free apps than with cashy ones.)

So, you'll see me release other work -- and other IF work -- before Hadean Lands is done. I regret that but I don't apologize; that's the way my life is going to work, if it works at all.

What I can tell you is this: by the time Meanwhile ships, Hadean Lands will be my "work on this every day" project. That doesn't mean it will be my first priority on any given day, but there will be steady progress. Sometimes I get wrapped up on a project and crunch on it for weeks; Meanwhile was like that. But the steady progress works whether I'm obsessed or not.

(What's my current "work on this every day" project? I do have one. Shall I say, River-and-Swamp design work? But it's not a high-priority project; it will probably be shelved next week, until either the board game or at least one IF project reaches fruition.)

In the long term, I hope to offer you an ever-growing tally of interesting projects across the game and narrative domain. And I hope that, in aggregate, they pay my rent.

All for now.

Posted in Zarfplan | Tagged , , , , , , , | 2 Comments

My Secret Hideout: available now

I am delighted to say that My Secret Hideout -- first mentioned here a couple of weeks ago -- is available right now on the App Store. Runs on iPad and iPad 2 (iOS 4.2 or later).

Really, it's been available for most of a day -- in some time zones. You may not know this, but Apple treats its App Store as a separate store for each country (or a bunch of countries, anyhow). Apps appear in a given store at midnight in that store's time zone. So from my point of view, My Secret Hideout was released to the New Zealand App Store at 8 AM on Monday. It's been cruising across the hemispheres all day, and it just hit the US a few minutes ago. (Maybe up to an hour. Don't worry, you can get it even if you live in California.)

The down side is, I don't have any sales reports yet, so I don't know how it's doing. But the up side is that I don't have to figure out tax compliance in 90 countries.

I'm glad I don't have to organize everything, is what I'm saying.

No; strike that. What I'm saying is:

My Secret Hideout is a wacky, creative thing set in a treehouse. It’s not like any app you’ve seen before. Buy it! Play around with it!

My Secret Hideout has no goal, no score, no trophies. Explore it, or play with it, until you find a result you like. Will your treehouse be simple or complex? Can you guide it? What will you discover inside?

That's the blurb. There's the link. Go for it.

And as always, please rate the app if you try it out. Ratings are what keep the sales going, and income is what keeps me going. (I mean, yes, the hacking and the laughs are what keep me going -- but also the income.)

Thank you for your continued generosity. More project news soon.

Posted in Zarfplan | Tagged , , , , | 3 Comments

A preview of My Secret Hideout (plus catching up)

Introducing My Secret Hideout -- my first iPad app release. Coming soon!

I already mentioned this on Twitter and then (welcome to the new world) my Google+ stream. But you folks signed up for news, and news I owe you. So here's a little more detail.

My Secret Hideout is an interactive text toy for the iPad. You build a little tree on the right half of the screen. As you do, the left half displays a description of your secret treehouse fort. Every change you make to the tree causes the text to evolve. The larger your tree, the larger your treehouse gets.

(If this screenshot doesn't work for you, scroll down -- I've copied the sample text at the bottom of this post.)

This is not a game. It's not really a construction kit either. You don't decide what rooms and elements go into your treehouse; you can only make changes and watch the variations. But I think that has its own charm. It's a toy, and a toy should be discovered through play. Just like IF, really -- there is no menu of treehouse elements, so you will keep finding new ones as you explore.

I also think that the tree is a pretty good toy on its own. Dragging around the leaves is fun! The tree reacts as you play with it; it's subtle animation, but it adds a lot of bounce and snap and physicality to the interface. I spent a lot of time making sure that was satisfying.

My Secret Hideout is just about finished. I need to add another couple of room options, and polish the usual list of UI edges which nobody but me will ever care about. I've said that I intend to ship it -- at least into Apple's hands, for approval -- by Labor Day (Sept 5). I'm still good with that deadline.

This thing has a wacky history. The concept started out as "The Folding Book of Fairy Tales". Imagine a picture book, but rather than turning pages, you fold them, bringing together different elements and forming new shapes. Wacky, eh? I have no idea where that goes. I would like to get back to that someday.

Well, I didn't have a picture book ready to go, but I started writing some paper-folding code. You Twitter followers saw me starting to rant and mutter about origami a couple of months ago. I got that working pretty well, too. Then I pulled out this idea of a fantasy world of procedurally-generated text. I put them together, and presto:

That worked nicely. But I wasn't satisfied with it. Playing with paper-folding is fun, but it feels destructive -- or rather, it feels bounded. You fold the paper, and it gets smaller and smaller, until you have this little angular spitball that won't fold any more. (Memory limits, you know, even with infinitely thin paper.) I don't have a full origami simulator, so it's not like you can make a crane. And it just didn't seem to fit the treehouse theme.

So I tossed all that paper-folding code off to the side. (I will definitely do something with it someday, even if it's not the Folding Book of Fairy Tales.) I started over with this tree-building toy... and that worked much better.

Will I develop this further? Maybe. If My Secret Hideout turns into a hit, I'll be happy to expand it to My Secret Underwater Hideout and My Secret Cave Hideout and My Secret Hideout in Space. (In-app purchase would be great for that, if it weren't for the patent situation. We'll see how that goes.)

Now the elephant-in-the-treehouse question. My Secret Hideout is obviously not a text adventure. (Although I've brought some of my text-adventure skills to bear on the descriptions.) Where is Hadean Lands in all of this?

For that answer, let's go back to February, when I started prototyping what I am still referring to as Secret Project M37. I was pounding away on HL design documents and iOS interpreter code. But I knew that would be a long process of pounding, and I wanted a relatively fast project that I could crank out and start making some money. (And iOS dev credibility.)

I created a prototype for M37. It looked good. I got excited and worked on it for a couple of months (while still working on IF code).

Then M37 got bogged down in one of those annoying delays. As a software developer I want to imagine that any problem can be solved by sitting down and hacking all night -- but that's false. This wasn't a technical issue, it wasn't anybody being incompetent, it was just paperwork that was slow. (I won't go into the whole story, because it doesn't matter.)

So that was frustrating. If I were a perfect person, I would have used the delay to push Hadean Lands forward. But I got stuck on the idea of "fast project, crank out, make some money". So I pulled out the origami idea and the procedural text idea and threw together My Secret Hideout.

I started that at the beginning of June. So it's looking like a "fast project" for me is three months -- except that, remember, I wrote a whole origami library and then took it out. So really two months. (And now I have an origami library in reserve.) That's pretty good; that gives me confidence that I can keep an iOS dev cycle going.

After I ship Hideout, I will be concentrating on M37, because it too is just about finished. (And the paperwork is just about settled...) Even though M37 isn't IF either, I promise you will be excited and you will understand why I made time for it this past spring.

Once both of those are out the door, it will be IF time again. I realize that you all have extended your faith to me, and I've been less stringently focused on Hadean Lands than I could have been. I beg your further indulgence. It will all come together.

Here's the text from the sample screenshot, in non-screenshot form:

My secret hideout is a cluster of sturdy rooms hung around a majestic oak. The walls are roughly cut but fit tightly. The well-lit living chamber is restful and quiet.

Behind that is a room with leftover paint cans scattered everywhere.

To the left, past a secret arch, is my library. Maps are piled everywhere. A plate of cheese sits on a side table, and the smell of old paper permeates the place.

The entire construction is powered by raincatchers that funnel water down through the branches past tiny turbines.

And just for kicks, here's a second one:

My secret hideout is a meshwork of tree branches, low in an elm. The walls flutter gently in the wind; vines weave through them. The uneven sleeping chamber is restful and quiet.

The treehouse is easily defensible. A ladder of heavy boards runs down the tree. I can also parachute out if necessary.

Posted in Zarfplan | Tagged , , , , , | Leave a comment

That crazy software patent situation

Many people have asked me -- that is, I have been asked -- that is, Jmac asked me last weekend -- anyway, this iOS software patent situation. What do I think?

Catching up: back in May, a handful of iOS software developers (and at least one Android developer) received legal documents from a company called Lodsys. Lodsys declared that the use of an "upgrade to full version" button (the normal sort of thing you'd see in trial, demo, or lite-version apps) infringed patent 7222078, and the developers needed to either pay off Lodsys or get sued. (Macworld news story, May 13th) Two weeks later, Lodsys filed a lawsuit against seven developers. (Florian Mueller blog post, May 31st)

You can peruse the patent document. It starts "Methods and systems for gathering information from units of a commodity across a network", which tells you nothing, and it gets less useful from there. The upshot, according to Lodsys:

In the case of an Application doing an in-application upgrade (and only this scenario), Lodsys is seeking 0.575% of US revenue over for the period of the notice letter to the expiration of the patent, plus applicable past usage. (Lodsys web site, May 15th)

For added confusion, Apple licensed this patent (and thus paid Lodsys) long ago. It's a finesse: Apple claims that when an iOS app implements in-app purchase, it's using Apple software and services (the App Store) which are covered by Apple's license. Lodsys claims that each app developer needs to license the patent separately. (Open letter from Apple, as reprinted by Macworld, May 23rd)

Obviously, I have no way to judge the validity of the patent. It dates from the 1990s. Common sense says that software has been using this sort of in-app upgrade since at least those days; no license fees have ever been exchanged for it, except for the kind of big-block patent maneuvering that giant companies (Apple, Google, etc) engage in. Common sense has nothing to do with the patent system, and so we leave it to rot. I refer you to Florian Mueller's FAQ on Lodsys for informed (though not lawyerly) commentary.

What does this mean for my life as a nascent-we-hope iOS software developer?

In the short term, I just proceed with caution. I will avoid using in-app purchase and upgrade for my apps. (These were not a big part of my plan anyway, but I was considering them. Now I'm not.)

You might say -- and Lodsys is certainly hoping that I'll say -- "0.575%, what the hell, that's tiny. Just pay it."

So look. First of all, screw them. Second of all, you don't spill blood in the water. There are at least two other patent-exploitation attempts affecting small developers right now: MacroSolve and Kootol. (The latter is targetting the big boys as well as independents.) More must be waiting to pounce. There is no known upper bound to the number of bullshit patents that might be out there, hanging over every software practice I might have learned in the past twenty years. If this is a viable means of predation on developers, it won't stop at half a percent.

Therefore: screw them. But also: this is not a stable situation. It developed just this summer, and it will develop further by the time I ship my first game. So there's no point in me freaking out or changing my life plans.

(Besides, I'm basically an optimistic person. Or maybe I like living in a state of self-delusion. My current situation could be taken as evidence of either. So what the hell, why quit now?)

In the medium term, several things could happen:

  • Lodsys could stop suing more developers until their current set of lawsuits are resolved. Yeah, I'm not exactly counting on that one.

  • Apple could say "We are squelching this stupidity." That probably doesn't mean changing the entire patent system. But they could sue Lodsys. Or they could provide legal resources to help the developers now being sued. The whole point of suing small developers is to batten onto defenseless targets; if the targets are getting pro bono legal aid from a company with $75 billion, the point gets blunted.

  • Apple could say "Eh, developers can take it in the nuts." I don't take Steve Jobs for a saint. If Apple thinks they can survive with fewer developers in the world, they could let the world change. (The letter they've already sent is encouraging, but it really just says "Cut that out, please, wouldja?")

The problem with these options is that they're indistinguishable on current evidence. Apple doesn't telegraph its legal moves. They might be helping developers already, and I wouldn't know it until they make an announcement.

And in the long term? This is not just Apple and in-app purchase, after all. Kootol is going after Twitter developers; MacroSolve has something about electronic form entry.

I suppose independent software development could become a wasteland. We've seen some predictions in that direction, such as this post from Craig Hockenberry. (His company, the Iconfactory -- of Twitterrific fame -- got walloped by Lodsys and Kootol.)

At the opposite extreme, some of these patent-trolling companies could get their asses handed to them in court, and the whole mess could blow over.

I can also imagine software developers banding together into patent-defense collectives. You don't have to have more money than Apple, after all; you just have to have more money than the patent trolls. I would pay a percentage of my income to a legal defense fund, a "not one red cent" plan. Of course there ways that could go horribly wrong, but we're speculating here.

Or, I suppose, the patent system could be reformed to not support this kind of crap. I'm not counting on that either.

In case you care, my basic position on software patents hasn't changed since the GIF debacle of the late 1990s. I think software patents are not an inherently broken idea; they just need to be scaled to the speed of Internet innovation and software release cycles. Say, eighteen months. If you can't get ahead of your imitators in that span of time, you're screwed anyway.

Update, August 20:

Looks like Google has jumped in on this too. They've filed a legal request to re-examine Lodsys's patents. According to Groklaw, Google has a strong position:

These five items of prior art go to the fact that the critical elements of the '078 patent claims are not even novel! (-- Groklaw post, August 18th)

That is, Google has found five earlier patents that already have the important elements of Lodsys's patents. So it's not even "somebody else invented this first"; it's "somebody else invented this first and the patent office knew it".

However, Florian Mueller is not so encouraging:

I don't consider those reexamination requests -- unless they will be accompanied by more forceful and useful measures very soon -- a serious commitment to supporting Android app developers against trolls. If this is all that Google does, it's too little, too late, and calling it "half-hearted" would be an overstatement. (-- Florian Mueller blog post, August 13th)

He thinks the ongoing lawsuits are unlikely to be stayed on this basis, so Google's filing doesn't change anything for developers today.

It's worth noting that Google's position is at odds with Apple's, which is that the patent is valid but only Apple is using it -- app developers are just using Apple's service -- and Apple is licensed to do that. (Apple has filed to intervene on this basis.) Developers can use both defenses, of course.

Posted in Zarfplan | Tagged , , , , , | 3 Comments