It’s September 2016, and Apple showed once again some pretty cool hardware: dual cameras, clever asymmetrical core design, water resistance, blah blah. I’m not interested since I already have the very recent 6S (I’m not that rich or desperate) but it’s a very nice piece of technology.

The change that will create the most ripples on the rest of the market however is the removal of the headphone jack, I think. Actually, scratch that. The removal in itself is not that important – it’s what they replaced it with that’s important. Yet, 90% of the press gets hung up on the removal.

I think they’re all missing the point.

The matter of the jack port removal is temporary. It’s going to be very annoying for those of us whose audio needs are not limited to “one phone and one pair of headphones”, but it will be temporary. Hopefully.

I don’t imagine Lightning port headpones will take off – as a manufacturer you’d have to be crazy to invest in a proprietary connector for which you need to pay licensing fees, which is something you didn’t have to do before, and which would also prevent you from selling your products to half of your market. Plus, even low-cost manufacturers are already able, to some degree, to produce relatively cheap Bluetooth headphones. So that’s where the market will go, and where Apple wants to go anyway.

The real problem is that in my opinion Apple opened a can of worms with their wireless headphones: they run with a proprietary “secret sauce” layer on top of Bluetooth. Some people are worried about the potential for DRM but I’m mostly wondering if we’ll see some kind of “wireless protocol war” starting in the next couple years.

Right now, Apple’s “secret sauce” is supposed to be backwards compatible with normal Bluetooth devices, but you know how these things go. The proprietary layer will get bigger with each new release – I’m even expecting that you’ll have to download firmware updates for your headphones on a regular basis soon – but all those cool features will create envy. You can bet that someone like Samsung will come up with their half-assed version of another proprietary layer on top of Bluetooth, as a “me too” feature. Maybe there’s going to be a couple of those out there. Some of those implementations may have some kind of DRM, added under pressure from the movie or music industry, in exchange for some short term IP, marketing, or financial boost.

Eventually the Bluetooth SIG will try and draft some new version of Bluetooth that tries to fix all the basic problems that really should have been fixed before anybody decided to remove the jack port… and meanwhile, Apple has a 5+ year lead on wireless technology, keeps growing their accessory licensing revenue, and is laughing at how everybody else is still having trouble pairing headphones correctly. It’s like the dark ages of the W3C all over again, for audio.

So yeah, Apple is really clever here. I’ve got no doubt iPhone users will be buying increasingly more “W1” enabled headphones from approved manufacturers… it’s a smart move. But not a courageous one. Courage would be to open-source their Bluetooth layer. Courage would be to work with the Bluetooth SIG (which they’ve been a member of since last year) to improve wireless audio for everyone.

Hopefully Apple finds some real courage soon.

Gruber, about Apple probably removing the jack and maybe shipping wireless earbuds by default with the next iPhone:

[…]not that one port is better than another, but that wireless is better than wired.

It’s not that wireless is better than wired – it’s that Bluetooth (as it’s widely speculated that Apple would still stick to that technology) is a far better alternative than something proprietary like the Lightning port. The complete absence of the “proprietary vs. compatible/open” considerations from the Apple bloggers is not only baffling but incredibly worrying to me. If Apple was to use, say, AirPlay, that would still be a terrible choice.

A transition towards Bluetooth as the replacement to the venerable jack port would be tolerable in the short term, and would maybe (hopefully) drive improvement on how OSes and devices work with it – for instance, the experience of switching your wireless headphones between devices is far from ideal, and that’s a very common scenario for me, almost on a daily basis. But frankly, I’m not looking forward to having to manage yet another battery level, and having headphones become obsolete with wireless protocol updates.

The “Apple removing the headphone jack plug” story is warming up again.

The 2 best arguments against removing the jack plug in favor of a digital port, in my opinion, have been put forward by Patel and Streza in the previously linked articles:

• Opportunities for audio DRM.
• Necessity to move the DAC and amp into the headphones – which will most probably sound worse than before on average, or raise the price of headphones in general.

I can add one more that I haven’t seen yet:

• A shared connector like Lightning or USB (as opposed to a port dedicated for headphones) means a connector that will change in a few years. Some of us buy expensive headphones that we expect to last for 10 or 20 years – well below the life expectancy of those digital ports.

The interesting thing though is that pro-removal people often make a weird logical leap. For instance, Gruber:

Should the analog headphone jack remain on our devices forever? If you think so, you can stop reading. If not, when?

He does his best to compare the jack plug to floppy disk drives, and how eventually it will all work out and Apple will once again be proven right in their forward thinking awesomeness… but the floppy disk drives weren’t replaced with a proprietary Apple device. They were replaced with USB sticks and downloads, all of which are superior in every way to floppy disks. It’s definitely not the case for the Lightning port – to quote OSNews’ Thom Holwerda: “as far as I can tell, there are only downsides”.

The whole point isn’t whether the jack plug is up for grabs or not – it’s debatable whether it should be right now, but nothing is sacred in technology. The whole point is that the replacement needs to fulfill the basic requirements that we expect from something to use headphones with. The Lightning port fails so many of those requirements (“standard” being probably the most important one) that it’s a really bad and, yes, user-hostile choice.

It’s a great choice for Apple however. It grows their accessories revenue, strengthen their hold on their users, and generally speaking puts them even more in control. It’s such a great idea for Apple that I can actually totally see them doing it. A lot of people will complain, but pretty much everybody will put up with it, as the cost of switching is much higher than the cost of tagging along. And what does it matter if it splits the audio market in two because of the proprietary port? It’s not like Gruber and other Apple bloggers are very sensitive about life outside of the walled garden anyway.

These past couple days most of the video games development community was set on fire by some pretty bad article written by some pretty famous guy on some pretty high traffic website. I’m not going to comment on it – other people like Rami Ismail did that very well already. Interestingly enough, it revived the old debate about “passion” and “crunch”, and we’ve seen a fair number of interesting articles about it as a result. This is not one of those articles either.

What this is is just a simple look at what’s going in my team, Frostbite Cinematics, which I think is interesting because Frostbite is in a fairly unique position in the industry, and that translates to a fairly different approach to overtime.

Spoiler alert: there’s pretty much none.

Pretty things

For those who need a refresher, Frostbite is EA’s proprietary game engine. Originally Battlefield’s engine, it now powers a growing number of EA games, including the Bioware franchises, Need for Speed, Mirror’s Edge, or PvZ: Garden Warfare. Where Unity or Unreal have thousands of customers that are external to them, we only have a dozen, but with which we have very close partnerships.

On the cinematics team (around 6 people), we build the tools that let people make, well, cinematics. If you know Unreal, a very simplistic but easy way to look at it is that we’re responsible for something that looks like¹ the Matinee editor.

(we also get to work on gay sex scenes)

Going undercover

One thing that sets us apart (but that other groups inside Frostbite are increasingly adopting) is that we like to be embedded with our customers. We spend months at a time (co-)developing new features, or polishing existing ones, directly in a team’s codebase.

During that time we’re often treated as temporary members of the team: we attend team meetings and stand-ups via Skype, we’re active on their JIRA boards, we break their build, and we get some cool swag².

The one thing we can’t afford however is to do overtime: if we started doing overtime for one team, we’d have to do overtime for all teams. So we just make it clear, and we try to manage our task load accordingly and realistically. While helping ship Dragon Age: Inquisition, I think we must have stayed late only a handful of times.

Of course, that’s quite unique to us. Other groups in Frostbite, especially in Stockholm, had a vastly different (and grueling) experience while shipping Battlefield 4, for instance.

The drive

Most people on the overall “Frostbite Animation & Cinematics” team (around 20 people) are what you’d call “passionate” to some degree. And this quest to hire other “passionate people” is all fine and dandy – of course we want to hire people who will care about what they do here. But the biggest fallacy about it is thinking that the entirety of this passion has to be spent sitting on that one office chair, on that one project.

Furthermore, this “passion” takes a different form when you start looking at core tech teams. Generally, people who care about games want to work on games, period. People who work on core tech care about something slightly different.

They may care about games, but dislike the often “throw-away” nature of AAA game dev, seeking a position where the code you write is longer lived and multi-purpose. They may care about, say, “animation in games” (in our case), and want to make a difference at a deeper level. Or they may not care about games at all, and instead just love a good technical challenge with an end product that’s fun to press F5 for. This means that the end result of a “crunch”, which may be at least appealing to a game team member (because that’s the game they want to make) may not be so appealing to a core tech dev (because it’s often hacky code or crappy UX that will have to be fixed).

Just say no to drugs

So when faced with the possibility of having to do overtime, it’s easier as a Frostbite Cinematics dev to just say no if it feels unnecessary. Sometimes it can still require some guts, like when you have a multi-Oscar winning CTO from Lucasfilm who calls you at 3pm on a Friday to suggest that you stay over the week-end to fix a problem… but it’s possible.

It doesn’t even have to be about “staying late” overtime. For instance, I personally consider eating at one’s desk to be a capital offense. Maybe it’s my French upbringing, coming from a country where 1-hour lunch breaks are the norm. It’s also just incredibly sad. But so many people do it – and probably only a small fraction of them have a good reason to do so (like a lengthy commute to their kid’s school).

I once bumped into one of our junior devs who was heading for his desk with a plate from the cafeteria. He gave me a lame excuse about having bugs to fix or something, when I knew there was absolutely no time-sensitive factor. I gave him a very tongue in cheek speech about perpetuating a culture of overtime and constant pressure because of impostor syndrome-induced fantasies of how an ideal game dev performs. He sighed, smiled, and joined us for lunch.

Once you foster a culture where things can generally wait 30 minutes so you can get a healthy lunch, it gets easier to foster a culture where things can generally wait until tomorrow so you can get a healthy evening.

One more thing

We’re hiring! Hit me via email or twitter if you’re interested.

Since I reached an acceptable milestone with PieCrust performance recently, I had some free time again to catch up with some of my other projects. The first one to get some love is Gutentags, my tag-management Vim plugin, which was sitting there with a bunch of pull requests and bug reports.

The newest version of Gutentags includes better support for project-specific settings via the .gutctags file, some progress on supporting Cscope (not quite finished yet), and various bug fixes, all from a few generous (and patient) contributors.

Grab it from Bitbucket or Github, depending on your preferred source-control poison.

While I was working on the documentation for PieCrust 2, I decided I might as well do something proper, like support for translations and versioning. The documentation is now in the same repository as the code, and it’s easy to bake the documentation pages for each release.

To do this, I needed a simple tool that could do the basic work of cloning a repository, syncing back to given points in times, and do something. In theory, this would be a simple bash script or something, but I also wanted it to do nothing if it already did something for that same specific point in time.

Thus September was born (if you don’t get the reference, even with the picture above, I can’t help you).

It’s a simple Python script that still packs some goodness to it. It basically lets you roll your own readthedocs kinda website (in a very basic way of course), with appropriate hooks to your repositories.

You run it from inside your repository (Mercurial or Git at the moment) and it will sync back to each tagged changeset and run a command of your choice. You can specify a bunch of stuff in a configuration file, like the command itself (which supports interpolation with a few useful values), the oldest tag to start from (in case you don’t want to go all the way back to the first release), and a couple of other things. It will work out of a temporary directory in which it clones your repository, and stores a cache file that describes what it’s doing. If you keep that temporary directory around, it won’t re-do the work it previously did (so it will only rebake my documentation pages if I moved a tag or added some new ones, and it will re-use and update the repository clone).

It’s still all new and a bit squeaky, so make sure to file some bug reports if you see anything wrong. Oh, and it’s on Github too for you Git kids.

After the nice one-shot “The Murderer of Thomas Fell”, my new gaming group decided to continue with the 1930s horror genre and we played through roughly a third of the Realm of Shadows campaign for Call of Cthulhu.

It ended with a near-total-party-kill.

You can read the actual-play for “Kith and Kin” (the first chapter) and “Provender of the God” (the second chapter) over in the RPG section.

One thing that I realize now that I’m writing those things up is how often I feel the need to explain why, as a GM, I’m doing this or that – making the bad guys attack here, adding some clues there, etc. Most of the “actual plays” out there only focus on what happened around the players’ side of the table. But I’m finding it more interesting to also include what’s happening behind the GM’s screen.

This is especially interesting because investigative adventures rely a lot on the GM improvising events and moving around clues to keep the story going, as opposed to, say, a dungeon crawl, where most of the design decisions can be done upfront during the preparation phase, and the improvisation is mostly about adjusting enemies to keep combat balanced.

Adding the GM side of the game makes it easier for me to see what I did right and what I did wrong, and may even get me some constructive feedback on some of those decisions. I’ll try to keep adding things like that in the future reports.

This week-end in Vancouver was FanExpo, with the shopping frenzy, celebrity line-ups, cosplay contests, and friendly comic-book sketching that you’ve come to expect from such conventions, albeit at a smaller scale for our relatively young Vancouver edition.

Here’s my artist-commission-focused loot this year:

Nadia (from Kukuburi) by Ramon Perez, Conan by Cary Nord, and Iron Fist by Kaare Andrews. And a nice Thundercats t-shirt because I always need a new t-shirt.

After the jump you can see some cosplay pictures I took, although you can probably see better ones elsewhere on the internet.

You can see the other pictures in my FanExpo 2015 album.

Sarah Baird talks about what us left-handed people have put up with all our lives, and all the way back through history:

Day in and day out, though, the biggest hurdle faced by lefties isn’t discrimination — it’s mundane, basic functioning. Almost all facets of society, from ink pens to urban design, are crafted and structured to support, abet and cater to the right-handed majority. For lefties, functioning means a constant, conscious consideration of how they can reverse or modify their natural behavior in order to most effectively move around in the world.

The funny thing is that most of the time, I’m not even thinking about it. I’ll be, say, getting hot air blowing all over me from holding the vacuum-cleaner “the wrong way”, and not really realize that this wouldn’t happen if I was right-handed. It’s just like living in a world that’s slightly less well-designed.

Generally speaking, I’ve probably encountered less hurdles growing up in France than most North-American lefties: spiral notebooks were not used a lot (we had properly bound notebooks) and student chair/tablet combinations were pretty much inexistent.

The last time I really felt the pain of being part of a market minority was when I was shopping for a new computer mouse. Being a palm gripper, I ideally need a so-called “ergonomic” mouse. But those mice are only ever manufactured for right-handed people. The only left-handed ergonomic mouse that I’ve been able to find is the Razer Death-Adder Left-Handed Edition. Many people dislike Razer for their annoying configuration software but I figured I still needed to vote with my money. And, you know, I needed a mouse.

As expected, the configuration software is annoying, but the mouse is really nice.

To celebrate 2015 (happy new year!) I’m starting a new section on this website: actual play write-ups of RPG games. I got back into gaming a few months ago, GM’ing a few Call/Trail of Cthulhu games.

The first one is “The Murderer of Thomas Fell”, a simple, one-shot adventure that acted as an introductory adventure to my new group of players. If you’re the kind of person that reads actual-plays, or if you plan on running that adventure, you can head over here.