I believe that in recent years, while looking for revenue models that work for electronic games, game designers and publishers have stumbled upon some formulae that work only because they abuse segments of their player population. Games can have addictive properties – and these abusive games are created – intentionally or not – to exploit players who are subject to certain addictive behavior.
It’s a good read, as Garfield tries to formalize what’s OK and not OK in games, with clear guidelines about gameplay aspects that make a game become “skinnerware”, while still allowing some gray areas. Of course, many people were quick to point out that his own game, Magic, falls, at least, in these gray areas. After all, a certain percentage of Magic players are known to spend huge amounts of money to acquire rare cards, and, generally speaking, buying more packs give you better cards which gives you some advantage.
What saves Magic from the skinnerware category, in my opinion, is largely that it’s a physical game, not a video game1, so whatever you buy still has value and can be sold back. The other thing is that its “power-ups for money” mechanism is not quite open-ended. True skinnerware games typically let you buy an endless amount of coins or jewels or energy charges or whatever. Magic, on the other hand, has a limited (although quite big) catalog of cards. Trying to get them all by buying booster packs quickly gets you diminishing returns because of the rarity of many cards, so you would quickly turn to individual purchases at market price. It’s still a shitload of money, but it’s a finite shitload.
I’ve never had even the slightest opportunity to get my own office1 so I frankly have no idea whether a private office would be an improvement – I just don’t know any better.
We do a fair bit of asynchronous communication, however. This is pretty much unavoidable, since, over here on the Frostbite Engine team, we have to deal with customers and co-workers that are spread across a dozen various places on Earth with up to 9 hours of time difference.
In some ways, however, it’s funny that Larson recommends replacing meetings with emails since a lot of my coworkers mainly complain about having to deal with too much email already. Also, the way he describes how a “quick” email conversation can replace a lengthy meeting is misleading since – having turned off all notifications and checking email only a couple times a day to improve productivity – this “quick” 4-message back and forth would actually take 2 days to complete.
In the zone
The part that caught my eye the most is the part about reaching a “flow state” – something that most people call being “in the zone”.
I have almost no problem reaching that state – even in an open floor plan.
Arguably, I’m not important enough to receive enough emails or meeting invites to experience the problems a lot of other people (most of them more senior than me, I assume) complain about, so that must help… but I basically get “in the zone” often enough that, on a regular basis, I finish a task, take off my headphones, and realize that it’s 2pm and that everybody had lunch already.
While most people use the Pomodoro technique to help protect themselves from distractions, I was, for some time, using that technique to help me take a break every now and then… because being “in the zone” for too long would frequently give me painful migraines (at least once a week). Even when I used Pomodoro timers on my phone, I would frequently not notice them going off!
Then again, I’m one of those people that most of you probably hate: the ones who can fall asleep in less than 5 minutes. So I suppose my brain and I really get along well when it’s time to shut off distractions. Yay brain.
Video game companies are almost all using open floor plans, and nothing will change that any time soon. ↩︎
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.
[…]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 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 like1 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 swag2.
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.
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.
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:
