Yesterday, for the first time in about a year, I played Bit Pilot. It's an astonishingly good game, and I found myself pondering what qualities made it fun. Games aren't made via checklists, of course. You can't take these elements, tick them off, and expect to have a fun game. There's also a standard disclaimer. But that doesn't mean we shouldn't try to learn from the work of others. So, why is Bit Pilot fun?
Bit Pilot has a simple concept, well-executed. You control a spaceship in a restricted playing area. Dodge the asteroids and laser beams. Collect power-ups if you can. That's it: there's no sprawling back-story, no giant sandbox, no growling beefy protagonist. Just you versus the game – and you will always lose. There's also no victory screen: you're pitted against your own prior performance (your high score) and any friends you can persuade to play too. This simplicity is an attraction. But a simple idea, no matter how elegant, isn't going to make people play for hours unless there's something more at work.
Balancing a chair on two legs
You're sitting at a desk and you push yourself away from it and now this four-legged chair is balanced on its two hind legs and you. are. awesome. We've all delighted in that, right? There's two unconscious thoughts that ping-pong back and forth while you're doing this:
- I'm so skilled. Check out my goat-like balance. This is ace. I'm ace.
- WHOA FUCK I ALMOST LOST IT phew I'm fine
It's this interplay that Bit Pilot replicates. Most of the time you feel in control and impressed with your abilities, but there's these little nudging pokes that knock you off balance. It's not a stable system; sometimes you'll get away with it, but in the end you'll lose. You come back for more because of the times you get away with it, and because the feeling of control is so addictive.
Pushing your boundaries
The reason you always lose is because Bit Pilot gently but constantly pushes on your boundaries. The special asteroids and laser beams are part of this, but the main pressure is the asteroids becoming bigger. Over time there's less space and more asteroid. You can't win; eventually there'll be no space left.
Super Hexagon is another game that got its hooks into me. It's difficult in a different way; it's far more overwhelming at first1. There's so much happening on-screen it's hard to grasp what's happening. And just when you start to get a grip, the game speeds up, or reverses direction, or introduces a new obstacle. Super Hexagon doesn't give me the same balanced-on-a-knife-edge feeling, though maybe I've played it too much. When I die in Bit Pilot, I think "I should have avoided that." When I die in Super Hexagon, I think "Yeah, you got me." Infinite runners like Canabalt have the purest implementation of this: they speed up the longer you play, giving you less time to react.
A balanced difficulty curve
Some games don't forgive mistakes. Super Hexagon and Canabalt both have instadeath: one mistake and you die. Other games give you lives. Bit Pilot has a lives system – your ship starts with two shields, and you can accumulate more – but it's more effective than your standard 3-lives-then-game-over mechanism.
There's no penalty for losing a life – no going back to the start of a level or losing your power-ups. The graphics and sound tell you you messed up, but there's no immediate consequence beyond feeling more exposed than before. You can also pick up extra shields, until your ship is nestled in the centre of a giant hexagonal onion. But it gets harder and harder to keep them: the more shields you have, the bigger you are. You can't slip through tiny gaps any more. Conversely, you become a smaller target as you get closer to death. The stakes are higher, but the odds are more in your favour.
No time to reflect
A key hook in both Super Hexagon and Super Crate Box is keeping the time between "game over" and "new game" as short as possible. One quick reflexive tap and you're back in the action. No time to think about the previous game; stay in the zone, and keep playing. It's not a case of thinking "Just one more go." It's a case of not thinking at all.
A game has perfect controls if you never think about them. Bit Pilot has a neat two-thumbs method that is a devil to explain, but it feels fantastic. Essentially, your two thumbs sum together. You can't understand it without playing the game, but it enables tiny intricate moves as well as big sweeping manoeuvres. You won't make many of those, though; part of its appeal is that (despite the fast pace) it's a game of subtlety. You'll die quickly if you pinball around the screen. Patiently wait in the middle, though, and make small adjustments... you'll live a little longer.
Super Crate Box, by contrast, has infuriating controls2. PC to touchscreen ports are always hard because on-screen buttons suck. Around 50% of my Super Crate Box deaths are down to a lack of control; things going awry between my fingers and the device. I end up jumping when I meant to shoot, shooting when I tried to jump, my jump going awry. It's frustrating, and it never happens in Bit Pilot or Super Hexagon. The chair-balance feeling depends on creating a feeling of mastery; you can't get that if it doesn't feel like your avatar3 obeys your commands.
Making it happen in your own work
I'm not a game developer, so I can't tell you how to build the perfect controls or chair-balancing feeling into your own games. I suspect it's art, not science; tweaking and playtesting until it feels right. I never got obsessed by Canabalt, but the developer spent a lot of time tweaking it until it played well.
And if your game lacks these qualities, don't worry. These principles aren't universal. Plenty of great games are made of different elements. There are games I love that are story-driven, or subverting the form, or wonderful art, or are simply absurd. But if your game lacks tension, excitement, and stickiness, think about whether you're lacking that chair-balanced-on-two-legs feeling.
November 10, 2013
When I got my iPhone I wanted a desk stand to accompany it. A friend had a stand that was simply a rubber strap with notches at each end. It seemed ideal – simple, portable, hard to break. But I couldn't find it online & my friend disavowed all knowledge, so I made one instead.
Unlike my laser-cut iPad stand, this one didn't go so well. Choosing silicone was my first mistake. It seemed the ideal material: safe to laser cut, reasonably priced, a good balance of stiffness and floppiness. But silicone's also heat-resistant – that's why it's used for cookware – and laser cutters use heat to cut. It didn't cut cleanly; no matter what I tried I had to finish each stand with a craft knife. I used 4mm silicone; thinner might have worked better, but it would be less rigid & durable.
My second mistake was also born of ignorance: few iPhone apps have landscape mode. iOS itself won't switch to landscape, so if you use the stand you'll be tilting your head a lot. The stand works in a portrait orientation, just about, but I don't trust it.
I can't recommend using this stand. But if you've been looking for a rubber strap stand, can't find one to buy, and want to make one of your own: this might be a good starting point. There's nothing wrong with the design, it's just not that useful. (And pick a different rubber).
October 20, 2013
I had an interesting conversation recently. It was something of a role reversal; the product person came at it from a data perspective, and I came at it from a product perspective. We were trying to figure out the roadmap – what features we could build, what features we should build, and their priority.
I produced a useful metaphor as part of this, but let's talk about the issue first. When you're developing a product or service, you should start at the front. What is the service? How will people interact with it? Why are people paying you for it1? How does it fit in with your existing/future services? You need this in a little more detail than an elevator pitch, but not to the level of a specification for external developers.
Once you've got this planning done you can figure out how to build it. That's the point to start thinking about the data you'll need to execute your plans – not before.
My conversation partner approached this from the other direction. "We're going to need data from our users for whatever we build," he thought, "And data is going to drive the business. Let's start there. What data is easy to collect? What can we do with that?"
That's a valid starting point for brainstorming. It can help you think up enhancements and quick wins. But it's not a good way to design your core product2. Chances are if it's easy, other people are already doing it. And even if it was really hard to collect or quantify certain data, if it's core to your business you'll have to figure out a way to capture it.
The data you collect & process is the crucial base for your product, but you don't start there. The metaphor:
If you're building a house, you'll need solid foundations. But you don't design the foundations first and then ask, "What can I build on top of this?"
July 1, 2013
Google Reader gets turned off today. It's still working now, but the pop-ups were persistent. I know we're in the last few hours. Despite that I'm nowhere near acceptance; I don't want it to die. It's a new experience: the first time I've lost an online service I loved. I've drifted away from other products & communities over the years, but nothing else was part of my online life until the owners took it out and shot it.
I've used RSS for over a decade but I was a late convert to Reader. I used Opera's built in RSS reader for years, which was... alright. I had some janky unison setup that synced unread items between my desktop and my laptop1. That satisficed for years, but I switched when I could no longer tolerate the lack of feed organisation2. Over the years my habits changed – less reading at a desk on a PC, more on the sofa with my iPad – but Google Reader was the underpinning for all of that.
Reader wasn't an eyecatching product. It wasn't beautiful; it didn't feel fun. You didn't sign up and have your mind blown. But it was reliable, and versatile, and always available. It was a Volvo, not a Porsche. It's breathable air: you don't think about how much you depend on it until it's running out.
The first secret of Reader is that it's a tool – just like a car, or a laptop, or a Leatherman. Everybody used it differently (and some people not at all3). There's no one RSS world. When the shutdown was announced, most friends reacted in one of two ways: they were distraught, or they were incredulous. "Wait," the second group asked. "You guys are still using that? It's 2013! What are you still using RSS for?"
Well, like any tool, a lot of different things. Some people who won't miss Reader used it for discovery – finding new stuff to read. That's a solved problem for many people. Interesting stuff will surface on Facebook, Twitter, Hacker News or Reddit4. But that's not how I use RSS. Some other people use it as a firehose – to follow BBC News, The Guardian, or other big sources that publish multiple times a day5. But that's not me either. Personally, I use RSS as a combination of:
- Post-discovery reading. You get linked to something. It's so good you read 10 other pages, or consume the entire archive. You'd like to read the new stuff in the future, so you add it to your RSS reader.
- Niche updates. I have a thing for newspaper corrections so I'm subscribed to the Guardian's feed. I like reading the blogs of my friends, even though they only update 3 or 4 times a year. Sometimes it's something delightfully weird. They update irregularly and take seconds per post to read.
- Personal alerts. I've got a bunch of saved searches for relevant job adverts in London, eBay items, Kindle special offers, gig alerts, and music recommendations. There's also some social networks I don't log in to, but still get notifications if someone comments on my stuff.
If you're not a completist and follow the right people on Twitter, number 1 might not be a problem for you. But there's a lot of great writing that I only see in my Reader account, and social networks won't help with 2 or 3. Maybe other people use email for that and filter relentlessly; I think that keeping up with 300+ infrequently-updated sources is better suited to RSS6.
The second secret of Reader is that it was the foundation of an ecosystem. I use Reader on my desktop, and Reeder on my phone/iPad. I save links to Pinboard, Instapaper, & occasionally Tumblr. I hoped that the 3 month lead time would be enough for a credible alternative to emerge, but all seem flawed. Reeder for iPad hasn't been updated in months and lacks support for any alternatives; thus two components must change. I have a lot of sympathy for the people working on replacements: as I said, people used Reader in hundreds of different ways. I want a public API, the ability to keep feeds in folders, support for Instapaper, and good keyboard navigation so I can go through a feed of 30 items in 60 seconds7. Other users will have a completely different list. And that's not to dismiss the technical challenge of polling millions of feeds in a timely manner.
I don't know yet what my replacement will be. I'm cautiously optimistic about Digg Reader. Marco went for Feed Wrangler & Mr Reader, which is a strong enough endorsement for me to try it too. Another friend found email to be his replacement, but his love for Reader came from the social features; I barely used those. I'll probably try going cold turkey for a while too, to see what I miss.
Part of me is excited to look back on today. What will future me think of this? Right now, it feels painful, the end of an era. Maybe it will be. Maybe my reading habits will change yet again. Or maybe it'll be no big deal; the switch to some other service will feel seamless. Only time will tell.
Yes: this is insane, in retrospect. But it was a different time; having two machines made me a power user. Normal people didn't do that. There was no Dropbox, no iCloud. Wifi was not ubiquitous; smartphones barely existed. And you could hold doubts about free hosted services without seeming like a kook; I mean, what would happen if they decided to turn everything off one day? ↩
Opera has folders now. ↩
Which is fine, obviously. I'm not trying to convert you to the Church of RSS; I'm just explaining why I liked Reader. ↩
Those people are crazy. ↩
Some people have asked why I need this. The truth is, I don't – in the same way I don't need Twitter, or my iPad, or a latté over my morning code review. But I do like it. It's part of the texture of my life and makes things easier. I don't want to give it up or change it, but I'm forced to. ↩
Ideal for photo blogs, one-hit wonder Tumblrs, or just culling a firehose. ↩
May 14, 2013
I've been helping a client with their technical hiring. They need more developers and it's notoriously hard to select the good ones. It's extraordinarily difficult to tell the difference between someone who sounds good and someone who is good. It's practically impossible if you're not a developer yourself; that's where I came in.
One standard tenet of screening programmers comes from Joel Spolsky:
How do you know whether to hire someone? In principle, it's simple. You’re looking for people who are
- Smart, and
- Get things done.
That's it. That's all you’re looking for.
That's definitely a great starting point. But I think the list needs one more item: opinionated.
It's not enough to be smart and to get things done. I've interviewed a number of candidates who had a strong history of both. But as soon as I tried to get an opinion out of them I found myself stuck in a bog of equivocation.
Sometimes the opinions are matters of taste. I like to ask candidates what websites they like, what tools they use, and what they like about them. The last part's the key. I'm not trying to bond with you when I ask what websites you like; I'm trying to get a sense for your taste, your critical eye, and your ability to intuit what's under the bonnet. I'm not going to rule you out for using NetBeans when I like vim; if you're interviewed by someone who will, you probably don't want to work there anyway. I'm trying to figure out how you approach problems, what crutches you have1, and how much thought you've given to how you work.
Here's an example: you interview two candidates and ask them for their favourite websites. Both say they like Twitter. "Why?" you ask. Candidate A mumbles something inoffensive about how he likes talking to his friends. Candidate B talks about the problem of distributing messages to millions of people, near-instantaneously, pushing the data to web browsers and mobile devices. Who's the stronger candidate?
But delivery is important, too: what if candidate A had spoken confidently about how Twitter's changed how he interacts with his friends, how the public interacts with celebrities, and completely reinvented breaking news: all of a sudden it's not so clear-cut. One candidate is more focused on technology, the other on sociological impact. The right choice depends on your company & the job role, but now you've got more information to make the decision.
Sometimes the opinions are about technology. I always try to include an open-ended design question in an interview; lately I've been using "How might you design a system that lets people play Monopoly with each other over the internet?"2. The openness is a feature; good candidates will ask a few questions before diving in, and there are lots of dramatically different ways of answering.
One candidate proposed a peer-to-peer solution. That's uncommon, but not insane. You can make that work. But he couldn't explain the strengths or drawbacks. He couldn't explain why he'd chosen that instead of a client-server approach. "There's a number of factors involved" isn't an answer if you can't name some factors. I'm totally fine with a candidate changing their mind! A great answer would be "I started this as a peer-to-peer solution, but now I see problems with synchronisation and preventing cheating. So, in retrospect, I think a client-server model would be better." Unfortunately I couldn't get anything out of this candidate; I encouraged and cajoled, but he stuck with neutral platitudes.
The best people I've worked with all have strong opinions about how software & the Internet should work. We don't always agree, but being unafraid to express an opinion means we can discuss a problem and find a decent solution.
There's one final nuance: the people you want have pragmatic opinions and respect other points of view. I don't want people who insist they're right, don't listen to others, or ignore reality. Sometimes there are valid reasons to cut corners, do a hacky job, or do something that stinks. You need people who will roll up their sleeves and get stuck in. But equally, you should expect to hear about how you screwed up, how the situation should never have reached that point, and how to stop it happening in future.
I'm a developer. What am I supposed to do differently?
- Be fearless in interviews. Your goal is to demonstrate your skills & knowledge, not avoid offence. Let's say you discovered the company's using a PHP-based stack, your CV says you just migrated from PHP to Java because PHP was unscalable, and now the interviewer's asking you what the problem was. Trust me: he's not feeling hurt. He's not saying that PHP's great and Java's crap. He wants to know what the problems were, and how changing language fixed them. Don't apologise, or equivocate, or say things like "That's just my opinion." It's obviously your opinion. Explain why you hold it.
- Look at things with a critical eye. Pick a website or app you use daily. What's good about it? What sucks? If you could wave a magic wand, what would you change? What would you change it to? Why do you think it's not that way already? If that change made things better for you, would it make things worse for others? If so, do you still think it should be changed?
- Ask questions. An opinion isn't a snap judgement, and it's only useful if it's been thought through. Interviews aren't interrogations – you get to ask questions too. Don't immediately jump into an answer if someone asks you to design a system; you don't know enough yet. How many users are we expecting? How technical are the users? Are there budget constraints? Is it web-only, desktop-only, mobile-only, or some combination thereof? Is performance an issue? Is it more important to optimise for server-side performance or client-side performance? Can we presume that all our users speak English? Can we trust our data to be valid? Can we hand-wave past a particular bit for now, or would you like me to outline that first?
- Work on your interpersonal skills. Disagreement is fine. Discussion is great. But you must express that disagreement constructively, otherwise you're just being an asshole. Dale Carnegie wrote the classic book on this; The Usual Error is also worth reading.
- Sometimes you have to watch the world burn. Maybe your interviewer is offended by your dislike of PHP, your belief in semantic HTML, or your system design. Be open to the possibility that you're wrong, and be humble, but remember the interviewer's done you a favour. Do you really want to work with someone who isn't open to other people's ideas and won't listen to explanation? Do you want to work somewhere where disagreements are settled with "I'm right because I've been here longest?"
Everybody has crutches; they're not a bad thing. Why wouldn't you want the computer to make your life easier? Some of my favourites include syntax highlighting, auto-indentation, and auto-lint-on-save. IDE users probably like automated refactoring, inline help, and code generation. ↩
March 31, 2013
Earlier this year, a Hackspace member offered the mailing list a free MIDI controller. I'd been considering taking part in FAWM – February Album Writing Month – and this pushed me over the edge. I accepted the MIDI controller. I signed up for FAWM and announced my intentions. So how did I do?
FAWM sets a simple goal: 14 songs, 28 days. People take part for all kinds of reasons and have different criteria for what constitutes a song. It's a challenge, not a competition: you're only accountable to yourself. Personally, I wanted to write chiptunes – 8-bit/retro computer game music. I've admired the genre for a long time, and I messed around with making some a couple of years ago. But I didn't manage more than a couple of 20-30 second snippets back then. It taught me how to use the software/hardware (I'm working on a separate article about that), but this would be the first "proper" music I've written since my GCSEs.
I wasn't expecting electronic music to be so time consuming. At full speed, with no blocks on inspiration, I could make one track a day. But that's an entire day of effort; 8-10 hours doing nothing else. More realistically, I could write 1 song every 2 days. I thought this would be enough, especially if I worked hard on weekends. But by February 10th I'd only managed 3 tracks and I knew I wasn't going to catch up. Between work, Valentine's day, & a friend's week-long visit from the USA I was never going to hit 14 songs. I intended to make a couple more songs with what was left of the month, but I wasn't enjoying it. So I gave up.
I've got a few half-written tracks left over, including one that's a "proper" chiptune (written with the Gameboy's hardware limitations in mind). One of my worries was that although I was using simple synths and tone generators, I wasn't making "real" chiptunes. The chiptune police would kick down my door, NES zappers drawn, shouting "Imposter!". Thus I tried sticking a bit closer to the original medium. I'd like to finish them off at some point, but I'm waiting for the desire to return.
So here they are: 3 songs that were meant to be chiptunes but probably count more as "chiptune inspired":
Would I do it again next year? Probably not. The FAWM community itself is amazing and I really appreciated the encouragement I received. But I don't think I can cram 14 chiptunes into one month without putting everything else on hold; even if I could, that doesn't seem like a fun activity. If I did take part again it would probably be something acoustic.
March 18, 2013
Much has been written about Google's self-driving cars. To recap: Google has started publicly demonstrating a car that can drive on public streets all by itself. It's deeply impressive technology, and is a manifestation of a decades-old prediction. Cars that drive themselves! No more congestion! No more accidents! Tomorrow's world today!
Because this technology is still stuck in the lab, demonstrated under carefully controlled conditions, my instincts are to dismiss it as speculation or decades away. But I've learnt that my instincts are basically slaves to my lack of long-term imagination. When I was 14 I read about e-ink and flexible displays. They seemed far-fetched then, but Kindles have been around for years and flexible displays seem just around the corner. Self-driving cars are probably closer than I think.
So how would that affect the tech world? Why would Google bother? Google say it's to advance society, which is probably partially true. But to me, the interesting part is the data. A self-driving car necessarily involves a whole bunch of sensors and cameras. A GPS and internet link are practically a given. So when this technology makes it into commercial vehicles Google's going to have a huge competitive advantage when it comes to maps and local data.
You won't need a dedicated street view team because you can use the imagery from people's cars. 3D maps like Apple's come from laser rangefinders and cameras, both of which will be built in to people's cars. Traffic flow data already comes from people's phones; it's a tiny step to pull it from the car directly. Updating maps with new/missing/altered roads is a similarly small step. As mobile bandwidth increases, the idea of a live streetview might actually be feasible. Scary as hell, but feasible.
This is all obviously good news for Google and good news for Google's users, but mapping competitors should worry. It's not about taking the human out of the process; it's taking the employee out of it. Other companies would have to pay people to gather data that Google's harvesting ambiently.
And now something completely unrelated
For a while I've been trying to figure out how to fit this thought into 140 characters, and failed:
You may think that with iPads and private space travel and drone strikes that we're living in the future. But your washing machine's UI begs to differ.
But trying to get a thought into a tweet can leave it open to misinterpretation. Is it a less-pithy version of "The future's already here, it's just not very evenly distributed"? Did Warren Ellis pre-emptively skewer it? The answer to both questions is "Yes and no."
My intention wasn't to normalise the age we're living in. I was trying to express the concept that some things are mind-blowingly amazing, whereas others remain mundane and niggling. I thought the great promise of the future isn't a few giant things, but a thousand tiny ones. Maybe we're condemned to overlook them; progress itself is a thousand tiny steps rather than one giant leap.
The shape of my life now is radically different compared to my life in 2003. And yet I still have to do my best Egyptologist impression when doing the laundry. A courier can't be more specific about a delivery time than a 12 hour window. I still buy pasta from the supermarket and find 3 unopened packs when I get home.
All I'm saying is there's still some room for improvement.
November 30, 2012
You're a web developer and you've discovered your web app's sending a lot of static assets over the wire with every page load. These are static assets, so there's no need – they don't ever change. If you configure your web server with the right headers, you can tell browsers to cache them forever. Pages will load faster, and your server will be under less load. So you create a
.htaccess file with something like this in it:
Header set Cache-Control "max-age=604800, public"
You load your website and watch the network inspector in Chrome. You hit refresh, but you still see loads of requests for your static files. You hit refresh again. Maybe it cached this time, or maybe not. But refresh again, and everything gets retransferred! You start looking at individual requests. The headers are being set properly. You read the spec, and everything looks fine. Other browsers are respecting the headers and doing the right thing. What the hell's going on?
You're not going mad, and you probably haven't messed up. Chrome's trying to be helpful: it can't tell you're a web developer, and it doesn't know you're tapping that refresh button to test the server. Chrome's detecting the multiple refreshes, presuming you're doing it because the page is broken, and reloading everything from the server. I haven't figured out the exact behaviour it uses to do this, but it seems it involves whether you click through to other pages or not. As a result, you'll get more reliable testing if you navigate around your app a bit rather than clicking refresh.
October 31, 2012
I've lived in London for 6 years now, but tonight was the first time I was visited by trick-or-treaters. Every year prior I indulged the Guardianista fantasy of making friends with the local youth – and the Daily Mail fantasy that I must bribe my way to safety via sweeties – by buying a giant bag of fun-size chocolate bars. And every year prior nobody came. I was left with broken dreams and a lot of chocolate.
But tonight was different. I arrived home late, and had just collapsed on the sofa when there was a sudden knock on the door. Standing up, I gazed down the half-lit hallway to see the silhouette of a teenager in a bad costume. "I'll pretend I'm not in," I thought. Then a couple of braincells kicked in and I realised the lights were on. I had to answer it.
I rushed to the kitchen and looked in the cupboard. Nothing. No sweets, no pastries, no chocolate. But there was one thing. One vague possibility. I grabbed it and headed to the door.
When I opened it the two teens had cut their losses and were halfway across the road, but they turned around when they heard the door open. "Err, trick or treat?" one asked, hopefully, not moving closer. And that's when I found myself possessed by a spirit infinitely older than my own, speaking words I'd promised myself I would never utter.
"I'm really sorry, I've just got home from a long day at work and I haven't got any sweets in the house," I said. "But I can give you this pomegranate if you wanted."
At some point – some point in the past year – I have changed from the person who buys sweets for Halloween to the person who offers trick-or-treaters fruit. Children tell playground horror stories about people like me. I can make excuses and plead special circumstances, but let's face facts: they asked for sweets. They got fruit.
The ghouls shrugged non-committally and walked off, and I thank them for that. No egging of the house, no shouted abuse. Perhaps they understood that the crashing realisation of what I have become is the greatest trick of all. But they probably just thought they'd try next door.
September 30, 2012
It's 2005. I'm in Australia, technically. I'm on a boat sailing round the Whitsunday islands with 30 other people. We put to sea for 3 days. 3 days of beautiful scenery, deserted beaches, and giant card games below decks. 3 days of diving, sunbathing, and talking. 3 days of whales. 3 days of no shaving, no warm running water, and no phone signal.
I got talking to one of the English women in our group. We soon discovered we'd gone to the same university. But not only that: at the same time. But not only that: we had some friends in common. But not only that: I had been to her house. One of our friends in common was her old housemate, and we'd met there for pre-club drinks. And here we were, in the middle of nowhere, on the opposite side of the planet.