SuccessWhale: Considering the Reply UI

What was once my sim­ple Twit­ter client, Suc­cess­Whale, is under­go­ing a lot of changes in the build-up to ver­sion 2. One of the biggest changes is the sup­port for mul­ti­ple ser­vices, of which Face­book is the first to be inte­grated. This, com­bined with the Twit­ter website’s new design, brings into ques­tion SuccessWhale’s “reply” UI.

There’s no ques­tion that there should be a big “type your sta­tus update here” box at the top. Both incar­na­tions of Twit­ter do this, Face­book does this, every non-mobile client (and a few mobile ones too) does it. It’s what users expect, and I see no rea­son not to stick with it.

About a thou­sand years of inter­net time ago (2010), reply­ing to a tweet from Twitter’s web­site re-used that top sta­tus box for the reply. The user clicked the “reply” but­ton, and the sta­tus box got pre-filled with “@” plus the user­name of the per­son they were reply­ing to. It looked like this:

Old Twitter Reply UI

Suc­cess­Whale, then solely a Twit­ter client, copied this behav­ior. Its reply UI involved click­ing a “reply” but­ton and hav­ing its main “pub­lish sta­tus update” box update with the replied-to user’s name, like this:

SuccessWhale version 1 Reply UI

Now Suc­cess­Whale is attempt­ing to be a Face­book client, too. On Twit­ter, replies to a sta­tus update are given vir­tu­ally the same promi­nence as the orig­i­nal sta­tus. On Face­book how­ever, posts are more thread-based, with com­ments on a sta­tus update clearly being daugh­ter objects of the orig­i­nal update. Sta­tus updates them­selves use “newest at the top” order, just like Twit­ter, but com­ments on an update are “newest at the bot­tom”. So on Face­book, it makes sense for the “reply” field to be inline, like this:

Facebook Reply UI

In play­ing around with the UI for Suc­cess­Whale ver­sion 2, I intro­duced an inline reply box, which works some­thing like this:

Successwhale version 2 Prototype Reply UI

A third reply UI was intro­duced with the new Twit­ter web­site — a float­ing “lightbox”-style reply area which appears when the “reply” but­ton is clicked. Like this:

New Twitter Reply UI

So, between the two sites that Suc­cess­Whale cur­rently talks to, we have three UI par­a­digms for reply­ing to a sta­tus update. I feel it is very impor­tant for Suc­cess­Whale to have a con­sis­tent UI for reply­ing, par­tic­u­larly when we intro­duce columns that mix updates from Twit­ter, Face­book and poten­tially other sources.

So, my ques­tion to Suc­cess­Whale users is: which one do you like best? I have no par­tic­u­lar attach­ment to any of them, so let’s get our democ­racy on. Your choice is between:

  1. Using the main sta­tus update box (like Suc­cess­Whale ver­sion 1 and old Twitter)
  2. Using an inline box (like Facebook)
  3. Using a pop-up ‘light­box’ (like new Twitter)

The com­ments are yours, vote away!

Sea Battle: Of Ships and Submarines

The dis­tinc­tion between sur­face ships and sub­marines in Sea Bat­tle has turned out to be a more thorny issue than I orig­i­nally imagined.

The orig­i­nal plan was to have two classes of ves­sel, based on their hull types — ship or sub­ma­rine — and weapons that could hit ships, sub­marines, or both. A future update could also have included air­craft “hulls”. How­ever, the more I think about the game bal­ance issues, the less I’m con­vinced that this is a good deci­sion with the tech tree and play­ing field size that Sea Bat­tle cur­rently has.

Sea Battle’s tech tree, as it cur­rently exists, has four straight “trees” with 10 items in each. By and large, each com­po­nent that you research is bet­ter than its pre­de­ces­sor. (Later hulls are heav­ier and take longer to build, so small hulls are still use­ful. How­ever, you would rarely want to choose any­thing other than the best weapon, engine and radar that is avail­able to you.) Com­bined with the small play­ing field, this makes for a fast-paced game of a few min­utes, with each player research­ing and churn­ing out ships con­stantly to gain the upper hand.

There are a num­ber of rea­sons why the cur­rent tech tree is inap­pro­pri­ate for sub­marines. Firstly, the weapons that a sub­ma­rine could have: there’s only two. The Sting Ray tor­pedo (weapon 8) and Tom­a­hawk mis­sile (weapon 9) are the only weapons appro­pri­ate to be fired from a sub­ma­rine. This would make rush­ing down the hull tree to sub­marines point­less unless you’d already reached near the end of the weapons tree — and in most games, you don’t even get that far.

It also cre­ates a UI com­pli­ca­tion, in that cur­rently, any com­bi­na­tion of hull and weapon is per­mis­si­ble. Submarine-appropriate weapons would break that behaviour.

There’s an issue with anti–sub­ma­rine weapons too. Again, only two (Depth Charge (6) and Sting Ray (8)) are appro­pri­ate for use against sub­marines. But since a viable sub­ma­rine build wouldn’t exist until Hull 6 + Weapon 8, they would only exist in the late game, at which point Depth Charges just can’t hold their own against other weapons — so why have them at all?

To abuse game the­ory, the log­i­cal choice is for play­ers to build Depth Charge ships when they become avail­able, then hold them in reserve as insur­ance against their oppo­nent build­ing sub­marines. But if you see your oppo­nent stock­ing up on Depth Charge ships, you might as well not bother build­ing subs and just go for bet­ter weapons and radar instead. Who­ever com­mits to a strat­egy first ends up on the los­ing end.

To cure these prob­lems, per­haps we need to take another les­son from War­zone 2100’s book and have sep­a­rate tech trees for dif­fer­ent weapon types. So rather than one tree of 10 weapons, we have two trees for anti-ship and anti-sub. (And poten­tially anti-air later.) If we’re going down this route we ought to have dif­fer­ent hull trees for ships and subs too. But at this point it’s turn­ing into a rather dif­fer­ent game — a slower, more tra­di­tional rock-paper-scissors RTS. But these games ben­e­fit from larger play­ing fields, var­ied ter­rain and squad-based com­bat — none of which Sea Bat­tle is par­tic­u­larly well suited to in its cur­rent form.

So the ques­tion stands: Do I expand Sea Bat­tle sig­nif­i­cantly to include this extra com­plex­ity, on the under­stand­ing that I would prob­a­bly need to rewrite it in some­thing other than Pro­cess­ing and that may con­sign it to the pile of “projects I lost inter­est in”, or do I just ignore the issue and for the sake of sim­plic­ity not treat sub­ma­rine hulls as any dif­fer­ent from ships?

Sea Battle: Here Comes the Science Bit

Another day down, and some­how Sea Bat­tle is remark­ably close to the fin­ish line. (No idea what I’m talk­ing about? See pre­vi­ous blog entries 1, 2 & 3.)

First things first, my fail­ings: CPU use and mouse sen­si­tiv­ity are still not fixed. I’m now hav­ing to re-render more of the win­dow on each refresh than before, so if any­thing they might be slightly worse.

On the Face­book thread, Scott and Mark men­tioned an AI issue in that a suit­ably scary player ship, when parked close to but slightly off to one side of the enemy base, will be ignored by enemy ships in favour of attack­ing the player base instead — even when they have no hope of destroy­ing the player’s base before their own is destroyed. As far as I know that issue is still there, though improved enemy research and build AI should mean the enemy is pump­ing out ships just as scary as yours.

On to the new features:

  • All 10 hulls, weapons, engines and radars are now implemented
  • You can now choose between them when set­ting build orders, so you can build in what­ever con­fig­u­ra­tion you like
  • Research is now imple­mented — click on an unre­searched com­po­nent to start research­ing it
  • You start the game with only basic com­po­nents, and must research more to survive
  • Colours: Grey — not researched yet, Green — research­ing now, White — avail­able, Yel­low — selected (click­ing Build will build this)
  • Enemy AI now han­dles its own research
  • Enemy AI now builds intel­li­gently rather than randomly
  • You can now drag a box to select mul­ti­ple ships


And bug fixes / tweaks:

  • Base health sig­nif­i­cantly increased
  • Build­ing a sec­ond ship with­out mov­ing the first no longer places them on top of one another
  • Pathfind­ing code tweaked to cope with much faster/slower ships now all the hulls and engines are available
  • Fixed an issue whereby the blue radar cir­cles were drawn at half the ships’ actual radar range


Still to come:

  • Ship / sub­ma­rine hull and vs ship / sub­ma­rine weapon distinction
  • Tweaks to enemy AI
  • CPU use / mouse respon­sive­ness fixes
  • Menu sys­tem and dif­fi­culty picker


If you’d like a good strat­egy for beat­ing the game at this point, I rec­om­mend you begin by keep­ing your build queue about 3–4 ships full, build­ing the best thing you can at any point. Research-wise, rush down the weapons tree as far as Har­poon mis­siles, throw­ing in a cou­ple of hulls and radars. Avoid engines for now. As soon as you have Frigates with Har­poons and Radar Mk 4, keep build­ing them until you’ve fended off all the ene­mies near your base and you have a fleet of 15–20 of them, then move them all right up to the enemy base. With that fleet you should be able to destroy the base before the ships they build wear yours down too much.

You can play the cur­rent ver­sion of Sea Bat­tle as a Java applet by click­ing here.

Sea Battle: That’s what Guns are for!

Another day — or three, in this case — brings another ton of func­tion­al­ity for Sea Bat­tle. (Pre­vi­ous posts: 1, 2)

Today’s release reduces the tar­get frame rate from 60 to 30 frames per sec­ond, in an attempt to alle­vi­ate the CPU hog­ging reported by aefara­dien in the pre­vi­ous post’s com­ments sec­tion. As I said in the com­ments, it’s not an issue I see on every machine, so I’d be grate­ful if any testers could tell me what PC setup they have, and how much CPU power the game takes up.

Today’s ver­sion also fixes the spin­ning ships bug that just about every­one reported. What it doesn’t do is make mouse clicks any more respon­sive, which is annoy­ing me too. Please bear with it for today, I’ll see if I can work out how to deal with that soon.

Mostly this release is about new fea­tures. Sea Bat­tle now has:

  • Ships are now imple­mented as hav­ing sep­a­rate Hulls, Weapons, Engines and Radars
  • Ships can shoot at each other (finally!)
  • Ships have health (and health bars), and can be destroyed
  • Bases have health (and health bars), and can be destroyed
  • That means there’s now a win and a lose condition
  • Enemy ship AI now con­sid­ers your ships’ scari­ness — a fac­tor of fire­power and remain­ing health — to pick tar­gets it thinks it can defeat
  • You can now build, with appro­pri­ate build delays and an 11-slot build queue
  • The enemy can now build too
  • Colours have been tweaked to make ships’ alle­giances more obvious

The only real bit of func­tion­al­ity that’s still miss­ing is the research / build options. Cur­rently, click­ing the Build but­ton pro­duces a ship of a pre­de­fined con­fig­u­ra­tion — you can’t change that con­fig or research bet­ter ones. The AI builds ran­dom ships up to and includ­ing as pow­er­ful as your default one, and has a rea­son­able amount of ‘thought delay’ to its actions, mean­ing that you can achieve vic­tory fairly eas­ily. (Just fill up the build queue and send every ship North as soon as it’s built — you’ll lose a few, but enough should sur­vive to destroy the enemy base.)

You can play the cur­rent ver­sion of Sea Bat­tle as a Java applet by click­ing here.

Note: this blog post is old, and the applet now has more func­tion­al­ity than is described here. The next blog post in the sequence is here.

Sea Battle, now with more Processing

Nearly a month ago now, I blogged some sketches and ideas for a game I felt like writ­ing. mas­terofwalri made a pass­ing ref­er­ence to Pro­cess­ing in his com­ment, and hav­ing heard peo­ple men­tion it in the past, I fig­ured I should check it out.

I’m very, very glad I did.

It neatly deals with the issue of what I should develop for. The com­ments were lead­ing me down the Java path any­way, but Processing’s two-click export to Applet and bun­dles for Win­dows, Linux and Mac OS sealed the deal. And it’s easy to pro­gram in too — it’s clear that it’s beginner-oriented, but it’s also ideal for sim­ple games like this as it sim­ply removes all the start­ing faff, like sort­ing out JPanels and TimerTasks and all the rest. Time will tell if Pro­cess­ing over-simplifies things and stops me doing some­thing I want to do, but for now it is excelling at the main task of high-level pro­gram­ming lan­guages — reduc­ing the amount of brain over­head I need to allo­cate in order to talk to the computer.

One lunchtime has pro­duced 270 lines of code — which already includes the game area of the GUI, con­trol­lable player ships, and the begin­nings of AI for the enemy ships.

You can play around with it as an Applet here.

Note: this blog post is old, and the applet now has more func­tion­al­ity than is described here. The next blog post in the sequence is here.

Cur­rently there’s no real game­play — you can’t build, and ships can’t shoot or be dam­aged. You can move your ships (start­ing at the bot­tom of the screen) around, and the AI ship will hunt yours. Click on a ship to select it (blue cir­cle), then click else­where to set its des­ti­na­tion. Red lines, when they appear, show when ships would be shooting.

The next block of code will give the ships cus­tomised gear, health points, and the abil­ity to attack and sink oth­ers. With that will prob­a­bly come attack ani­ma­tions, which with my lack of skill in that depart­ment, will take a while. After that, dam­age­able bases and win/lose con­di­tions, then the build/research sys­tem. Finally, graph­ics tweaks, AI improve­ments and game bal­anc­ing will fin­ish it off.

More blog­gery will appear once more cod­ing occurs!

Alarm Apps, and the Lulz that can be had

I am in the mid­dle of cre­at­ing an Android app that’s a kind of super alarm clock. (God for­bid I should have less than six projects on the go at once.) In the run-up to your cho­sen alarm time, it pulls down var­i­ous feeds from the inter­net so that it can wake you with news, weather and traf­fic infor­ma­tion. A typ­i­cal wake-up mes­sage might be:

Good morn­ing Ian! It’s 6:15am on Wednes­day the 27th of Octo­ber. The weather today will be fore­bod­ing mist, with highs of 10 degrees and a wind speed of 14 miles per hour.
In the news today: Nick Clegg has been revealed to be a fic­ti­cious cre­ation of the Guardian news­pa­per. A man has shot a large deer, and appar­ently this is news. And, The dead are ris­ing, every­body stay indoors.
Lat­est traf­fic updates: A338 Bournemouth — One lane closed north­bound due to an ear­lier acci­dent. A35 Bere Regis — Sub­ject to road­blocks due to high zom­bie threat, find alter­na­tive routes.

There’s just one prob­lem, as pointed out by @TheHiddenPaw — that all of that text is going to get read out by the Android text-to-speech engine, and thus you’ll wake up to the sound of the news being read by a Dalek.

Ide­ally we’d like the voice to sound human, but that’s all-but impos­si­ble with cur­rent text-to-speech tech­nol­ogy. And short of a news source pro­vid­ing freely-accessible audio streams with time-based meta­data (BBC News karaoke any­one?), there’s no sen­si­ble way of chop­ping up actual news, weather and travel reports to push out as an alarm.

If you’re a fan of sen­si­ble soft­ware and sane ideas, you might want to stop read­ing now, because my thoughts then diverged somewhat.

First of those thoughts was “hey, I won­der if you could pay some­one on Mechan­i­cal Turk to read it for you?”. Now that costs money, so it would be the world’s first alarm clock with sub­scrip­tion fees. On the other hand it would prob­a­bly be the world’s first alarm clock which had its func­tion­al­ity out­sourced to India. Maybe that’s the future, or something.

The next thought was “since it’s only a few pence they’d lose out on, there’s not really any way to avoid peo­ple record­ing com­pletely fake stuff, or record­ing com­plete silence so you oversleep.”

My third and final thought was “oh boy, lulz can be had here”, after which I was declared legally brain-dead for actu­ally think­ing the word ‘lulz’.

What if we embrace people’s abil­ity to record what­ever the hell they like, and keep a whole data­base of what­ever audio we get, and pick from it ran­domly as an alarm tone?

This is AlarmRoulette.

(Thanks to @HolyHaddock for the name that sums it up perfectly.)

Through your phone or on the web, any­one can anony­mously record 30 sec­onds of what­ever audio they feel like record­ing. Then, every morn­ing, a ran­dom clip gets cho­sen by each user’s phone to be used as an alarm.

The pos­si­bil­i­ties are end­less, and end­lessly hor­ri­fy­ing. One morn­ing you could get woken by some sooth­ing Mozart, and the next by Aphex Twin. On Wednes­day you could hear an inspir­ing and encour­ag­ing mes­sage about how won­der­ful you are, and on Thurs­day you could get woken up by some­one giv­ing a run­ning com­men­tary of 2 Girls 1 Cup.

I can’t decide if this is the best, or the worst, thing ever. Maybe it’s both.

Game Idea Spam Time!

One of the games I remem­ber lik­ing from what I was shocked to dis­cover was 11 years ago was War­zone 2100. It’s actu­ally one of the rare exam­ples of an Aban­don­ware game that’s been taken and updated on by a loyal com­mu­nity — over a decade since it was first released, they’re work­ing on ver­sion 3.0. (You can down­load it from here, com­pletely free.)

The rea­son I’m men­tion­ing it today is for its vehi­cle con­struc­tion mechanic. Rather than sim­ply build­ing a Light Tank or a Heavy Tank and so on, each vehi­cle came in a num­ber of bits — body, tracks, tur­ret, and so on. You researched each item indi­vid­u­ally, then you could build vehi­cles with what­ever bits you’d researched.

For some rea­son this idea has been weigh­ing heav­ily on my brain over the last few days, so I’ve sketched out some ideas for a game that I’m half tempted to write.

It would be sort of like a naval ver­sion of War­zone, only 2D with a lim­ited play­ing field, and prob­a­bly rather sim­plis­tic graph­ics (espe­cially if I’m build­ing it on my own, since I can’t draw for tof­fee). There aren’t any build­ings apart from a sin­gle base for each player which builds your ships, and you lose if your base is destroyed. In order to defend it, you build ships from blue­prints you have researched.

Each ship is com­posed of four bits:

  • Hull — affects how much armour (health) the ship has.  More armour, roughly speak­ing, makes a ship heav­ier and also take longer to build.
  • Engine — engines pro­vide thrust, which along with the hull’s weight, affects its speed.
  • Radar — affects the range of the ship’s weapons.
  • Weapon — deals dam­age to other ships.  Weapons have a power (dam­age per shot) and a fire rate.

Ships can shoot at other ships (sub­marines are a pos­si­bil­ity too) and if they get close enough, the enemy base.  They can be moved around the play­ing field, and will auto­mat­i­cally fire on any enemy ship within range.

Here’s the rest of my thought processes (and doo­dles) in Awful Hand­writ­ing form:

My big ques­tion is, if I were to make this — and have the patience to fin­ish mak­ing it, which is a rare thing indeed — for what plat­form should I be mak­ing it?

  • For the Desk­top is the eas­i­est option.  I could code it com­fort­ably with tools I’m used to.  But it’d be yet another crappy down­load­able game that no-one would keep around.
  • For Phones would give it a more inter­est­ing mar­ket, though the UI would need some work on any­thing less than an iPad or Galaxy Tab.  Also, CBA devel­op­ing for Apple stuff.
  • For the Web is prob­a­bly the best way to get peo­ple play­ing.  But it’s prob­a­bly not doable in HTML5+JavaScript, I can’t afford Adobe Flash, and I can’t write a Java applet because it’s not 1995.

Does any­one out there in inter­net­land have any thoughts on which for­mat they’d like to see a game like this in?  (And while you’re there, do please wade in with any other sug­ges­tions, rants, rea­sons why the whole idea is flawed, etc…)!

a thousand words: Finishing Touches

The vast major­ity of user-reported bugs and requested fea­tures on “a thou­sand words” have now been sorted out. As requested by my co-conspirator Eric, we now have an ‘adult con­tent’ fil­ter based on a date of birth field in users’ pro­files, and a ‘report’ but­ton to bring prob­lem­atic sto­ries and pic­tures to the atten­tion of the mod­er­a­tors. There’s also a DeviantArt-style “request cri­tique” option to let users know what kind of com­ments you’re look­ing for.

Time­stamps have been fixed, “no stars yet” rat­ings intro­duced, and text field poli­cies such as “mustn’t be empty” have been added across the site. A few ren­der­ing issues in IE have been sorted out, so it now looks much the same across all platforms.

The biggest change is unfor­tu­nately some­thing most of you will never see — the mod­er­a­tor con­sole. Pic­ture sub­mis­sions and reported stories/pictures now sit in queues that can be dealt with by mod­er­a­tors. An item enter­ing a queue trig­gers an e-mail to all mods, who are invited to review it and make changes as appro­pri­ate. Once changes are made, the affected users are then e-mailed to let them know what hap­pened (and in the case of reported items, to give them a chance to chal­lenge it).

There’s one major fea­ture request that’s not yet been imple­mented: file uploads. Once in the sys­tem this would allow users to sub­mit pic­tures from their hard dri­ves rather than from the web by URL, and would allow mod­er­a­tors to copy URL-linked pic­tures to the site to avoid hotlink­ing. (At present we don’t hotlink, but we do there­fore have to copy pic­tures to the site man­u­ally using FTP.) It could also allow users to use a non–Gra­vatar pic­ture for their profile.

Depend­ing on how things go, that may or may not be ready by tomor­row night. On Sat­ur­day morn­ing I jet off to sunny Saudi Ara­bia, so any changes not made by then are going to remain unmade for a while. From that point it’s in Eric’s capa­ble hands as to whether she wants to release the site or not. Even if the site does advance to release sta­tus, I’m still tak­ing bug reports (they’ll sit in my inbox until I get back), so keep on let­ting me know what’s bro­ken and what you’d like to see added!

a thousand words: Alpha, Beta

“a thou­sand words” has now reached a stage where every fea­ture that I give a damn about is imple­mented. Thus, we’re open­ing it up to a lim­ited beta test to iron out the wrin­kles and get a list of any fea­tures poten­tial users would like to see us launch with. If you’re bored or sim­ply have a love of break­ing other people’s shit, head along to http://athousandwords.org.uk and see what hell you can raise. As the Big Red Box Text warns you, really don’t sub­mit any work of fic­tion you care about, just in case some kind soul finds an SQL injec­tion vul­ner­a­bil­ity and trashes the database.

Since last time I bored the hell out of you all, vot­ing and com­ment­ing has been imple­mented, reg­is­tra­tion has been fixed, fil­ter­ing HTML tags from sub­mis­sions has been added, as has a word count and the pic­ture selec­tor on story sub­mis­sion. There’s been a bunch of behind-the-scenes tweaks to improve secu­rity too.

The one fea­ture that Eric def­i­nitely wants is a way to mark sto­ries accord­ing to their con­tent. We could do this in sev­eral ways — I would pre­fer, if any­thing, to just have a “not for kids” option on each post and a Date of Birth field asso­ci­ated with user accounts, so we can hide sto­ries as required. Other options include a range of rat­ings (U, PG, 12, 15, 18…) or tags for cer­tain con­tent (vio­lence, sex, lan­guage) so peo­ple can avoid what­ever they’re picky about.

This prob­a­bly ought to come with a Report but­ton so that users can report incor­rectly rated sto­ries, and I would add a sim­i­lar fea­ture to report pic­tures. (Pic­ture sub­mis­sions are mod­er­ated, so Goatse isn’t going to make it through any­way, but the mod team might miss sub­tler things like licenc­ing terms and copy­right infringement.)

At that point, all that’s left on my list is the admin inter­face and any­thing that users sug­gest dur­ing this beta. Hope­fully we’ll be ready to launch by the time I depart for sandier shores at the end of the week!

a thousand words: Hot Profilin’ Action

A few days’ lazi­ness (by which I mean a few days’ Star­craft) have passed with not much work being done on “a thou­sand words”. That came to an end tonight, with a pro­duc­tive evening result­ing in a work­ing pro­file sys­tem so that users can now add and dis­play per­sonal infor­ma­tion, change their reg­is­tered e-mail address and pass­word, etc.

There’s now a data­base back­end for the vot­ing and com­ment­ing sys­tems, which will be com­ple­mented by their GUI pages tomor­row night.

Once that’s done, that’s the last of the main func­tions out of the way and we’re basi­cally down to tweaks. I think we ought to, in no par­tic­u­lar order:

  • Decide on what for­mat­ting users can add to sto­ries, and fil­ter for it
  • Add a word count, and pos­si­bly limit sub­mis­sions to e.g. 600‑1400 words
  • Add a means of report­ing sto­ries and pic­tures for e.g. copy­right issues
  • Add a means of rat­ing sto­ries, so users can mark them as con­tain­ing sex, vio­lence etc.
  • Cre­ate an admin inter­face, so we don’t just have to run the site with raw SQL queries
  • Add ranks, etc. (incen­tives for achiev­ing high Total Stars)
  • jQuery up some of the main bits to improve user experience
  • Imple­ment the scrolling list of pic­tures for users to select when cre­at­ing a new story

At that point, I think it should be ready for open beta. Hope­fully we can get it all done within a week, before I depart for internet-less shores!