Mile Zero http://www.milezero.org/index.php this space intentionally left blank en Bloxsom on PHP Loot Pack http://www.milezero.org/index.php/gaming/design/aaa/loot_pack.html If you wanted to look at the general direction of AAA game development, you could do worse than <i>God of War</i> and <i>Horizon: Zero Dawn</i> (concidentally, of course, the last two titles I finished on my usually-neglected PS4). They're both big-budget tentpole releases, with all the usual caveats that come with it: graphically rich and ridiculously detailed, including high-priced voice/acting talent, but not particularly innovative in terms of gameplay. But even within this space, it's interesting to see the ways they diverge &mdash; and the maybe-depressing tricks they share. <p> Of the two, <i>Horizon</i> (or, as Belle dubbed it for some reason, <i>Halo: Dark Thirty</i>) is the better game. In many ways, it's built on a simplified version of the A-life principles that powered <i>Stalker</i> and its sequels: creating interesting encounters by placing varied opponents in open, complex environments. The landscape is gorgeous and immense, with <a href="https://www.guerrilla-games.com/read/gpu-based-procedural-placement-in-horizon-zero-dawn">procedurally-generated vegetation and wildlife</a> across a wide variety of terrain with a full day-night cycle. It's pretty and dynamic enough that you don't tend to notice how none of the robotic creatures you're fighting really pay attention to each other apart from warning about your presence &mdash; you can brainwash the odd critter into fighting on your side with a special skill, but otherwise almost everything on the map is gunning for you and you alone. <p> In fact, <i>Horizon</i>'s reliance on procedural generation and systems is both its strong suit and its weak point. It's hard to imagine hand-crafting a game this big (<i>Breath of the Wild</i> notwithstanding), but there's a huge gulf between filling a landscape according to a set of gameplay rules and depicting realistic human behavior. One-on-one conversations and the camera work around them are shockingly clumsy compared to the actual (pretty good!) voice work or the canned animation sections. Most of the time, during these scenes, I was just pressing a button to get back to mutilating robot dinosaurs. But you can see where the money went in <i>Horizon</i>: lots for well-rendered undergrowth, not so much for staying out of the uncanny valley. <p> By contrast, <i>God of War</i> is <b>really</b> interested in its characters, as close-up as possible. The actual game is not good &mdash; the combat is cramped and difficult to read, ironically because <a href="https://deorbital.media/god-of-wars-battles-tell-a-story-with-confused-intentions-127e8c197c58">of its love affair with a single-take camera</a> (which is kind of a weirdly pointless gimmick in a video game &mdash; almost every FPS since <i>Half-Life</i> is already a single-take shot). It's small and short by comparison to open-world games, with its level hand-crafted around a linear story. I was shocked at how quickly it wrapped up. <p> But there's no awkward "crouching-animation followed by two-shot conversation tree" here: it may be a six-hour storyline, but it's beautifully motion-captured and animated. When Jeremy Davies is on-screen as Baldur, it's recognizably Jeremy Davies &mdash; not just in the facial resemblance, but in the way he moves and the little ticks he throws in. There's maybe five characters to speak of in the whole thing, but they come through as real performances (Sindri, the dwarven blacksmith with severe neat-freak tendencies, is one of my favorites). In retrospect, I may wish I had just watched a story supercut on YouTube, but there's no doubt that it's an expensive, expressive production. <p> Where both games share mechanics, unfortunately, is a common trick in AAA design these days: crafting and loot systems. Combat yields random, color-coded rewards similar to an MMO, and those rewards are then used alongside some sort of currency to unlock features, skills, or equipment. It extends the gameplay by putting your progress behind a certain number of hours grinding through the combat loops, as this is cheaper than actually <a href="https://www.raphkoster.com/2018/01/17/the-cost-of-games/">creating new content at the level of richness and detail that HD games demand</a>. <p> If your combat is boring (<i>God of War</i>), this begins to feel like punishment, especially if it's not particularly well-signposted that some enemies are just beyond your reach early in the game. It bothered me less in <i>Horizon</i>, where I actually enjoyed the core mechanical loop, but even there playability suffered: the most interesting parts of the game involve using a full set of equipment to manipulate encounters (or recover when they go wrong), but most of that toolkit is locked behind the crafting system to start. Instead of giving players more options and asking them to develop a versatile skillset from the start, it's just overwhelmingly lethal to them for the first third of its overall length (a common problem &mdash; it's tough to create a good skill gate when so much of the game is randomized). <p> Ironically, while AAA games have gone toward opaque, grind-heavy loot systems, indies these days have swung more toward roguelikes and Metroidvanias: intentionally lethal designs that marry a high skill ceiling with a very clear unlock progression. It may be a far cry from Nintendo's meticulous <a href="http://www.gamasutra.com/blogs/ChristianNutt/20141212/232178/Captain_Toad_and_the_core_of_Nintendo_game_design.php">four-step teaching structure</a>, but since indie developers aren't occupied with filling endless square miles of hand-crafted landscape, they've sidestepped the loot drop trap. Will the big titles learn from that, or from the "loot-lite" system that underlies <i>Breath of the Wild</i>'s breakable weapons? I hope so. But the economics of HD assets seem hard to argue with, barring some kind of deeply disruptive new trend. Sat, 10 Nov 2018 15:01:39 -0800 http://www.milezero.org/index.php/gaming/design/aaa/loot_pack.html/gaming/design/aaa Generators: the best JS feature you're not using http://www.milezero.org/index.php/tech/coding/generator.html People love to talk about "beautiful" code. There was a book written about it! And I think it's mostly crap. The vast majority of programming is not beautiful. It's plumbing: moving values from one place to another in response to button presses. I love indoor plumbing, but I don't particularly want to frame it and hang it in my living room. <p> That's not to say, though, that there isn't <i>pleasant</i> code, or that we can't make the plumbing as nice as possible. A program is, in many ways, a diagram for a machine that is also the machine itself &mdash; when we talk about "clean" or "elegant" code, we mean cases where those two things dovetail neatly, as if you sketched an idea and it just happened to do the work as a side effect. <p> In the last couple of years, JavaScript updates have given us a lot of new tools for writing code that's more expressive. Some of these have seen wide adoption (arrow functions, template strings), and deservedly so. But if you ask me, one of the most elegant and interesting new features is generators, and they've seen little to no adoption. They're the best JavaScript syntax that you're not using. <p> To see why generators are neat, we need to know about iterators, which were added to the language in pieces over the years. An iterator is an object with a <var>next()</var> method, which you can call to get a new result with either a value or a "done" flag. Initially, this seems like a fairly silly convention &mdash; who wants to manually call a loop function over and over, unwrapping its values each time? &mdash; but the goal is actually to enable new syntax once the convention is in place. In this case, we get the generic <var>for ... of</var> loop, which hides all the <var>next()</var> and <var>result.done</var> checks behind a familiar-looking construct: <code> for (var item of iterator) { // item comes from iterator and // loops until the "done" flag is set } </code> <p> Designing iteration as a protocol of specific method/property names, similar to the way that Promises are signaled via the <var>then()</var> method, is something that's been used in languages like Python and Lua in the past. In fact, the new loop works very similarly to Python's iteration protocol, especially with the role of generators: while <var>for ... of</var> makes consuming iterators easier, generators make it easier to create them. <p> You create a generator by adding a <var>*</var> after the function keyword. Within the generator, you can ouput a value using the <var>yield</var> keyword. This is kind of like a <var>return</var>, but instead of exiting the function, it pauses it and allows it to resume the next time it's called. This is easier to understand with an example than it is in text: <code> function* range(from, to) { while (from <= to) { yield from; from += 1; } } for (var num of range(3, 6)) { // logs 3, 4, 5, 6 console.log(num); } </code> <p> Behind the scenes, the generator will create a function that, when called, produces an iterator. When the function reaches its end, it'll be "done" for the purposes of looping, but internally it can yield as many values as you want. The <var>for ... of</var> syntax will take care of calling <var>next()</var> for you, and the function starts up from where it was paused from the last yield. <p> Previously, in JavaScript, if we created a new collection object (like jQuery or D3 selections), we would probably have to add a method on it for doing iteration, like <var>collection.forEach()</var>. This new syntax means that instead of every collection creating its own looping method (that can't be interrupted and requires a new function scope), there's a standard construct that everyone can use. More importantly, you can use it to loop over abstract things that weren't previously loopable. <p> For example, let's take a problem that many data journalists deal with regularly: CSV. In order to read a CSV, you probably need to get a file line by line. It's possible to split the file and create a new array of strings, but what if we could just lazily request the lines in a loop? <code> function* readLines(str) { var buffer = ""; for (var c of str) { if (c == "\n") { yield buffer; buffer = ""; } else { buffer += c; } } } </code> <p> Reading input this way is much easier on memory, and it's much more expressive to think about looping through lines directly versus creating an array of strings. But what's really neat is that it also becomes composable. Let's say I wanted to read every other line from the first five lines (this is a weird use case, but go with it). I might write the following: <code> function* take(x, list) { var i = 0; for (var item of list) { if (i == x) return; yield item; i++; } } function* everyOther(list) { var other = true; for (var item of list) { if (!other) continue; other = !other; yield item; } } // get my weird subset var lines = readLines(file); var firstFive = take(5, lines); var alternating = everyOther(firstFive); for (var value of alternating) { // ... } </code> <p> Not only are these generators chained, they're also lazy: until I hit my loop, they do no work, and they'll only read as much as they need to (in this case, only the first five lines are read). To me, this makes generators a really nice way to write library code, and it's surprising that it's seen so little uptake in the community (especially compared to streams, which they largely supplant). <p> So much of programming is just looping in different forms: processing delimited data line by line, shading polygons by pixel fragment, updating sets of HTML elements. But by baking fundamental tools for creating easy loops into the language, it's now easier to create pipelines of transformations that build on each other. It may still be plumbing, but you shouldn't have to think about it much &mdash; and that's as close to beautiful as most code needs to be. Tue, 02 Oct 2018 06:55:17 -0700 http://www.milezero.org/index.php/tech/coding/generator.html/tech/coding The Best of Times http://www.milezero.org/index.php/journalism/professional/the_best_of_times.html About two months ago, just before sneaking out the back door so that nobody in the newsroom would try to do one of those mortifying "everyone clap for the departing colleague" routines, I sent a good-bye e-mail to the Seattle Times newsroom. It read, in part: <blockquote> <p> I'm deeply grateful to Kathy Best, who made the Interactives team possible in 2014. Kathy doesn't, I think, get enough credit for our digital operation. She was always the first to downplay her expertise in that sphere, not entirely without reason. Yet it is hard to imagine The Seattle Times taking a risk like that anymore: hiring two expensive troublemakers with incomprehensible, oddball resumes for a brand-new team and letting them run wild over the web site. <p> It was a gamble, but one with a real vision, and in this case it paid off. I'm proud of what we managed to accomplish in my four years here on the Interactives team. I'm proud of the people that the team trained and sent out as ambassadors to other newsrooms, so that our name rings out across the country. And I'm proud of the tools we built and the stories we told. </blockquote> <p> When I first really got serious about data journalism, the team to beat (ironically enough, now that I've moved to the Windy City) was the Chicago Tribune. It wasn't just that they did good work, and formalized a lot of the practices that I drew on at the Times. It was also that they made good people: ex-Trib folks are all over this industry now, not to mention a similar impact from the NPR visuals team that formed around many of the same leaders a few years later. I wanted to do something similar in Seattle. <p> That's why there was no better compliment, to my ears, than when I would talk to colleagues at other newsrooms or organizations and hear things like "you've built a pretty impressive alumni network" or "the interns you've had are really something." There's no doubt we could have always done better, but in only four years we managed to build a reputation as a place that developed diverse, talented journalists. People who were on or affiliated with the team ended up at the LA Times, San Francisco Chronicle, Philadelphia Inquirer, New York Times, and Pro Publica. We punched above our weight. <p> I never made a secret of what I was trying to do, but I don't think it ever really took hold in the broader organizational culture. That's a shame: turnover was high at the Seattle Times in my last couple of years there, especially after the large batch of buyouts in early 2017. I still believe that a newsroom that sees departures as an essential tool for recruiting and enriching the industry talent pool would see real returns with just a few simple adjustments. <p> My principles on the team were not revolutionary, but I think they were effective. Here are a few of the lessons I learned: <ul> <li> <b>Make sacrifices to reward high performers.</b> Chances are your newsroom is understaffed and overworked, which makes it tempting to leave smart people in positions where they're effective but unchallenged. This is a mistake: if you won't give staff room to grow, they'll leave and go somewhere that will. It's worth taking a hit to efficiency in one place in order to keep good employees in the room. If that means cutting back on some of your grunt work &mdash; well, maybe your team shouldn't be doing that anyway. <li> <b>Share with other newsrooms as much as possible.</b> You don't get people excited about working for your paper by writing a great job description when a position opens up. You do it by making your work constantly available and valuable, so that they want to be a part of it before an opening even exists. And the best way to show them how great it is to work <i>for</i> you is to work <i>with</i> them first: share what you've learned, teach at conferences, open-source your libraries. Make them think "if that team is so helpful to me as an outsider..." <li> <b>Spread credit widely and generously.</b> As with the previous point, people want to work in places where they'll not only get to do cool work out in the open, they'll also be recognized for it. Ironically, many journalists from underrepresented backgrounds can be reluctant to self-promote as aggressively as white men, so use your power to raise their profile instead. It's also huge for retention: in budget cut season, newsroom managers often fall back on the old saw that "we're not here for the money." But we would do well to remember that it cuts both ways: if someone isn't working in a newsroom for the money, it needs to be rewarding in other ways, as publicly as possible. <li> <b>Make every project a chance to learn something new.</b> This one is a personal rule for me, but it's also an important part of running a team. A lot of our best work at the Times started as a general experiment with a new technology or storytelling technique, and was then polished up for another project. And it means your team is constantly growing, creating the opportunity for individuals to discover new niches they can claim for their own. <li> <b>Pair experienced people and newcomers, and treat them both like experts.</b> When any intern or junior developer came onto the Interactives team, their first couple of projects would done in tandem with me: we'd walk through the project, set up the data together, talk about our approach, and then code it as a team. It meant taking time out of my schedule, but it gave them valuable experience and meant I had a better feel for where their skills were. Ultimately, the team succeeds as a unit, not as individuals. <li> <b>Be intentional and serious about inclusive hiring and coverage.</b> It is perfectly legal to prioritize hiring people from underrepresented backgrounds, and it cannot be a secondary consideration for a struggling paper in a diverse urban area. Your audience really does notice who is doing the writing, and what they're allowed to write about. One thing that I saw at the Times, particularly in the phenomenal work of the video team, was that inclusive coverage would open up new story leads time and time again, as readers learned that they could trust certain reporters to cover them fairly and respectfully. </ul> <p> In retrospect, all of these practices seem common-sense to me &mdash; but based on the evidence, they're not. Or perhaps they are, but they're not prioritized: a newspaper in 2018 has tremendous inertia, and is under substantial pressure from inside and out. Transparent management can be difficult &mdash; to actively celebrate the people who leave and give away your hard work to the community is even harder. But it's the difference between being the kind of team that grinds people down, or polishes them to a shine. I hope we were the latter. Mon, 24 Sep 2018 05:37:46 -0700 http://www.milezero.org/index.php/journalism/professional/the_best_of_times.html/journalism/professional Spilled Ink http://www.milezero.org/index.php/gaming/software/splatoon/spilled_ink.html <img src="/blog/gaming/software/splatoon/practice_resized.jpg"> <p> I took a risk on <i>Splatoon 2</i>. Multiplayer shooters are not, generally, something I enjoy, and I'd never played the first game. Also, it's a weird concept: squid paintball? This is Nintendo's new franchise? <p> It turns out, yes, <i>Splatoon</i> is pretty great. It hits that sweet spot between the neon pop aesthetics of <i>Jet Set Radio</i> and the swift lethality of <i>Quake 3</i>, like a golden-age Dreamcast game decanted onto modern hardware (thankfully, without Sega's torture controller). And yet I'm surprised that there doesn't seem to be a lot of discussion of the game's central design mechanic, which is odd (but maybe common now that streaming has taken over from blogging). <p> <i>Splatoon</i> is not technically a first-person shooter, but it plays much like one. A typical FPS is about navigation and control of space, although the precise application of this depends on a number of other design decisions: switching from respawning power-ups to hero abilities, for example, emphasizes strategic <b>position</b> over an optimal <b>path</b>. Regardless, like many video games, play is less about the literal violence onscreen and more about range, line of sight, and predicting (or manipulating) the opponent's movement. You very much see this in the 2016 <i>Doom</i> reboot, where monster speed is actually quite low, and all the mechanics encourage players to rapidly pinball from one to the next in a chain of glory kills. <p> What <i>Splatoon</i> does is take all this implicit negotiation over space and make it explicit, by letting players alter the "distance" of the map with ink. All weapons in the game inflict damage, but they also paint the floor and walls with your team's color. Areas belonging to the other team damage you and slow down movement, while you can get a speed boost in your own color by swimming through the ink with the left trigger. In the primary game mode, you don't win by damaging the other team, although that helps. Instead, the winning team is the one that covered more of the stage floor when the timer sounds. <p> The paint mechanic is simple, but a lot of really interesting strategy falls out of it: <ul> <li> Offense needs to balance broad territory coverage (slow, but stable) against aggressive movement on a narrow path (faster, but easier to cut off). <li> This balance shifts throughout the match, especially since narrow paths don't establish a defensive bulwark to slow down the other team. <li> Inking the walls is the best way to get height on a map, but doesn't count for points at the end of a match. <li> Spraying around a player to slow them down makes them easier to target. Likewise, creating an oblique path and dashing down it is a fast (but risky) way to alter range. <li> Swimming through ink refills your ammo faster than staying still. Covering new territory boosts the special meter, but you're vulnerable during most specials. Between the two, you're incentivized to constantly alternate between moving forward and dashing back. </ul> <p> Since players are effectively redefining space within the geometry of the level itself, and because its weapons are still aggressively short-ranged, <i>Splatoon</i> levels are less like the sprawling expanse of a map from <i>Team Fortress 2</i> (I suspect the most of them would fit neatly in the gap between that game's historic two forts) and more like <i>Gears of War</i> combat bowls. They're relatively open, with long lines of sight and maybe a few chokepoints to force the teams to interact. The question isn't whether you can find the other players, because you almost certainly can. It's whether you can reach them, and what paths you'll take (or create) to get there. <p> This leads to one of my favorite moments in the game, at the end of the match, when the screen displays a top-down view of the paint-covered map. It pauses there for a moment to build suspense while you eyeball this Pollock-esque splatter and try to figure out which color covers more area, then a pair of tuxedo cats (don't ask) award the game to "good guys" or "bad guys" (your team is always the "good guys"). But beyond the raw score, you can see the history of the game written on that map: <i>this</i> is the place someone got behind our line and painted over one of the less-traveled nooks, <i>that</i> is the stippling of the ink storm we fired off to clear out that sniper position, and <i>over there</i> is the truncated brush stroke where I was chasing someone with the paint roller when the buzzer sounded. <p> <img src="/blog/gaming/software/splatoon/victory_resized.jpg"> <p> It's been suggested that building a shooter around an oddball mechanic like this is very typical Nintendo: just as they have built consistently profitable business around novel use of less capable (read: cheaper) graphics hardware, they carve out a niche within genres by refusing to compete directly with the standard design conventions. If you want a <i>Halo</i>-like, you have plenty of choices. There are few other terrain-painting shooters to compare (favorably or otherwise) with <i>Splatoon</i>. The closest I could imagine was <i>Magic Carpet</i> &mdash; and that's a wildly different game from more than two decades back. <p> But while this is to some extent true, none of that matters if you can't execute, and Nintendo is very good at execution. The paint mechanic at the core of <i>Splatoon</i> is interesting at a macro strategy level, but what actually makes it successful is that it <b>feels</b> great. Painting every possible surface for your team is a really satisfying thing to do. The art design is bold and colorful (as it would have to be). The music is great, and syncs up perfectly with the timer in the last minute of each match. <p> This has been a rough year, and the trend isn't upward. <i>Splatoon</i> has, to some extent, become my pomodoro exercise for anxiety: alterating a three-minute round of neon vandalism with a couple minutes checking RSS feeds for our impending doom while the lobby fills back up. The in-game experience is relentlessly upbeat and cheering &mdash; even while, apparently, the background fiction is a dark post-apocalyptic story about climate change. Welcome to 2018: even my coping strategies are terrifying. Tue, 30 Jan 2018 20:53:19 -0800 http://www.milezero.org/index.php/gaming/software/splatoon/spilled_ink.html/gaming/software/splatoon Hacks and Hackers http://www.milezero.org/index.php/tech/web/hacks_and_hackers.html <div class="aspect-ratio sixteen-by-nine"> <iframe width="560" height="315" src="https://www.youtube.com/embed/e8_SgOj0DDo?rel=0" frameborder="0" allowfullscreen></iframe> </div> <p> Last month, I spoke at the first SeattleJS conference, and talked about how we've developed our tools and philosophy for the Seattle Times interactives team. The slides are available <a href="https://docs.google.com/presentation/d/1_yBB3o4mbb_cEBDVnC5F12iYNt_wnWw6dWolJ9J3nYA/edit?usp=sharing">here</a>, if you have trouble reading them on-screen. <p> I'm pretty happy with how this talk turned out. The first two-thirds were largely given, but the last section went through a lot of revision as I wrote and polished. It originally started as a meditation on training and junior developers, which is an important topic in both journalism and tech. Then it became a long rant about news organizations and native applications. But in the end, it came back to something more positive: how the web is important to journalism, and why I believe that both communities have a lot to gain from mutual education and protection. <p> In addition to my talk, there are a few others from Seattle JS that I really enjoyed: <ul> <li> <a href="https://www.youtube.com/watch?v=jqIjR6KYcpA">Ashley Williams: JavaScript close to the metal</a> - a typically charming look at abstraction, operating systems, and the web platform <li> <a href="https://www.youtube.com/watch?v=qWY-olIEeAw">Steve Kinney: Building musical isntruments with Web Audio</a> - A really funny talk on building and playing a modular synthesizer <li> <a href="https://www.youtube.com/watch?v=fDfxy8Z7X3U">Shagufta Gurmukhdas: Web-based VR</a> - Although I'm still not convinced of the value of WebVR, I do love the way this talk shows how custom elements create a beginner-friendly language for new tech </ul> Sat, 16 Sep 2017 15:37:55 -0700 http://www.milezero.org/index.php/tech/web/hacks_and_hackers.html/tech/web Quantity of Care http://www.milezero.org/index.php/journalism/new_media/quantity_of_care.html We posted <a href="http://projects.seattletimes.com/2017/quantity-of-care/">Quantity of Care</a>, our investigation into operations at Seattle's Swedish-Cherry Hill hospital, on Friday. Unfortunately, I was sick most of the weekend, so I didn't get a chance to mention it before now. <p> I did the development for this piece, and also helped the reporters filter down the statewide data early on in their analysis. It's a pretty typical piece design-wise, although you'll notice that it re-uses the watercolor effect from the Elwha story I did a while back. I wanted to come up with something fresh for this, but the combination with Talia's artwork was just too fitting to resist (watch for when we go from adding color to removing it). <p> I did investigate one change to the effect, which was to try generating the desaturated artwork on the client, instead of downloading a heavily-compressed pattern image. Unfortunately, doing image processing in JavaScript is too heavy on the main thread, and I didn't have time to investigate moving it into a worker. I'd also like to try doing it from a WebGL shader in the future, since I suspect that's actually the best way to get it done efficiently. <p> In the end, I'm just happy to have worked on something that feels like such an important, powerful investigative story. Tue, 14 Feb 2017 16:30:25 -0800 http://www.milezero.org/index.php/journalism/new_media/quantity_of_care.html/journalism/new_media Catch Up, 2016 http://www.milezero.org/index.php/journalism/articles/catch_up_2016.html 2016 was a busy year for interactive projects at The Seattle Times. According to our (very informal) spreadsheet, we did about 72 projects this year, about half of which were standalone. That number surprised me: at the start of the year, it felt like we were off to a slow start, but the final total isn't markedly lower than 2015, and some of those pieces were ambitious. <p> The big surprise of the year was <a href="http://projects.seattletimes.com/2016/under-our-skin/">Under Our Skin</a>, a video project started by four young women in the newsroom and done almost completely under the radar. The videos themselves examine a dozen charged terms, particularly in a Seattle context, and there's a lot of smart little choices that the team made in this, such as the clever commenting prompts and the decision not to identify the respondents inline (so as not to invite pre-judgement). The editing is also fantastic. I pitched in a little on the video code and page development, and I've been working on the standalone versions for classroom use. <p> Perhaps the most fun projects to work on this year were with reporter Lynda Mapes, who covers environmental issues and tribal affairs for the Times. The <a href="http://projects.seattletimes.com/2016/elwha/">Elwha: Roaring back to life</a> report was a follow-up on an earlier, prize-winning look at one of the world's biggest dam removal projects, and I wrote up a <a href="http://dev.seattletimes.com/2016/02/roaring-to-life-how-we-built-our-elwha-watershed-package/">brief how-to</a> on its distinctive watercolor effects and animations. Lynda and I also teamed up to do a story on <a href="http://projects.seattletimes.com/2016/collateral-damage/">controversial emergency construction for the Wolverine fire</a>, which involved digging through 60GB of governmental geospatial data and then figuring out how to present it to the reader in a clear, accessible fashion. I ended up re-using that approach, pairing it with SVG illustrations, for our <a href="http://projects.seattletimes.com/2016/st3-guide/">ST3 guide</a>. <p> SVG was a big emphasis for this year, actually. We re-used print assets to create a fleet of Boeing planes for our <a href="http://projects.seattletimes.com/2016/boeing-timeline/">100-year retrospective</a>, output a network graph from Gephi to create a map of <a href="http://www.seattletimes.com/entertainment/visual-arts/in-seattle-art-world-women-run-the-show/">women in Seattle's art scene</a>, and built a little <a href="http://www.seattletimes.com/seattle-news/marijuana/deas-marijuana-eradication-program-still-targets-washington/">hex map</a> for a story on DEA funding for marijuana eradication. I also ended up using it to create year-end page banners that "drew" themselves, using <a href="https://jakearchibald.com/2013/animated-line-drawing-svg/">Jake Archibald's animation technique</a>. We also released three minimalist libraries for working with SVG: <a href="https://www.npmjs.com/package/savage-camera">Savage Camera</a>, <a href="https://www.npmjs.com/package/savage-image">Savage Image</a>, and <a href="https://www.npmjs.com/package/savage-query">Savage Query</a>. They're probably not anything special, but they work around the sharp edges of the elements with a minimal code footprint. <p> Finally, like <a href="http://www.seattletimes.com/business/seattle-times-to-cut-newsroom-jobs/">much of the rest of the newsroom</a>, our team got smaller this year. My colleague Audrey is <a href="http://dev.seattletimes.com/2017/01/farewell-audrey/">headed to the <i>New York Times</i></a> to be a graphics editor. It's a tremendous next step, and we're very proud of her. But it will leave us trying to figure out how to do the same quality of digital work when we're down one newsroom developer. The first person to say that we just need to "do more with less" <a href="https://www.youtube.com/watch?v=gKM34ijnhzI">gets shipped to a non-existent foreign bureau</a>. Tue, 17 Jan 2017 13:44:46 -0800 http://www.milezero.org/index.php/journalism/articles/catch_up_2016.html/journalism/articles Guns and glory http://www.milezero.org/index.php/gaming/design/guns_and_glory.html If you'd told me a few years ago that my favorite shooters in 2016 would be reboots of <i>Doom</i> and <i>Wolf3D</i>, I'd probably have been surprised, or depressed, or both. Surprised, because both of them were very much games of their time, and it would seem impossible to recreate their peculiar arcade-oriented chemistry now. Depressed, because I probably would have seen it as a part of the stagnation of the shooter genre, with which I have a love-hate relationship. <p> But it's true: after I upgraded my graphics card as a birthday gift to myself, I've been going back and replaying a bunch of FPS games (for better or worse, they're the graphical showcases in my Steam library), and the two standouts have been <i>DOOM</i> and <i>Wolfenstein: The New Order</i>. I'm as shocked as anyone! They're both excellent revivals of old id Software franchises, and part of what's so interesting about them is that they're excellent in such completely different ways. <p> Of the two, <i>The New Order</i> (and its prequel mini-expansion, <i>The Old Blood</i>), have a heavier lift: although it's vaguely connected to the 2001/2009 games, most people are only aware of the original, which was (despite mind-blowing graphics for its time) two-dimensional in both gameplay and character. They weren't great games even back then, and they haven't aged particularly well (<i>TNO</i> includes "nightmare" remakes of the 286 levels, in case you forgot how tedious and confusing <i>Wolf3D</i> could be). <p> The team behind <i>TNO</i> is the same group that made <i>Chronicles of Riddick</i> and <i>The Darkness</i> at Starbreeze, both of which took ridiculous licensed properties and stretched them past both the source material and the Steam category: <i>Riddick</i> asks players to engineer multiple prison-breaks with not much more than a knife, a black-market night-vision mode, and a lot of Vin Diesel dialog. Half of <i>The Darkness</i> is shooting light bulbs! The shape and flow of a Starbreeze game could be odd &mdash; linear chunks connecting free-form adventure hubs &mdash; but they were almost always as interesting in the downtime as they were in the action sequences. <p> By virtue (such as it is) of this being a Wolfenstein game, going too far outside of "open door, shoot Nazis, repeat" was probably too much to ask. But <i>The New Order</i> does pack a surprising amount of pathos into what is otherwise a totally bonkers 1960's alternate history in which the Fourth Reich won the war via mad science. It tilts on the action side of things, but there's still definitely a Starbreeze flavor, if you liked their other titles. Parts of it are brilliantly cinematic, including a ten-year flash-forward sequence that separates the first and second acts. <p> And while the gameplay doesn't go full retro, it has elements of old-school flavor. There's no regenerating health system or trendy cover-hugging mechanics here, and <a href="http://www.gamasutra.com/view/news/223752/Game_Design_Deep_Dive_Ammo_Collection_in_Wolfenstein_The_New_Order.php">the use button gets a workout</a>. My favorite refinement is the commander system, where many of the battle setpieces will introduce one or two radio-equipped officers. If you're spotted, they'll call in reinforcements, so a good approach is to stealth-kill them before mopping up the troops. Or you can play the way I do: take out one officer and then charge the other with guns blazing, before they can stack the odds too far. That this is still a viable (and fun) strategy strikes a nice balance between players who want the stealth experience, and those (like me) who are mostly in it for the instant gratification. <p> <i>DOOM</i> has no such such balance, and does not suffer for it in the slightest. There is no clip reloading for any of the weapons, and the run speed is entirely unrealistic. Unlike most shooters since <i>Halo</i>, everything in <i>DOOM</i> is designed to encourage non-stop movement toward (and through) enemies. Which is a big part of the reason why, even though it changes from its predecessor in significant ways (mouselook, a jump key, lots of upgrades and collectibles), it still manages to feel like playing deathmatch in 1996. <p> The two primary mechanics for maintaining player momentum in the game are a fast mantle, which gives players the ability to very quickly ascend vertically, and the "glory kills," which reward players with a half second of invulnerability (during the animation) and a quick piƱata pop of health and ammo. There's no reward for staying still &mdash; in fact, <a href="http://www.gamasutra.com/blogs/ChristopherGile/20160627/275839/How_DOOM_Encourages_Aggression.php">like a bullet-hell shooter</a>, players are immediately punished for remaining stationary</a>. The goal is not to block or absorb damage, it's to avoid getting hit at all. <p> <i>DOOM</i> levels are primarily structured as a series of loosely-connected arenas, which also keeps the deathmatch feel: while hallways and platforms are used to set the mood and create checkpoints, the most intense gameplay is set in wide, 3-D spaces with multiple "circuits," just like the best Quake DM levels. <i>Gears of War</i> is also famous for "combat bowls" as a gameplay tool, but it strongly emphasized cover over movement, whereas <i>DOOM</i> almost never places waist-high walls to serve as partial cover (and they'd be useless in a game with lots of high vantage points anyway). <p> There's a moment at the very beginning of the game where your character, having ripped out of a set of shackles and punched through the initial set of undead, pulls up a video screen reading "DEMONIC INVASION IN PROGRESS." As mission statements go, this is pretty much <i>DOOM</i> in a nutshell: crank everything up to 11 and <a href="https://www.youtube.com/watch?v=vsoVQWnSOfM">embrace the inherent, b-movie absurdity of the thing</a> (a similar process took place <a href="http://www.pcgamer.com/doom-composer-mick-gordon-one-of-the-pre-conditions-of-the-project-was-no-metal/">music direction</a>, which started with no guitars at all and ended up a metal shredfest). <p> All combined, the end result is about as pure a video game as you can get with a high-budget, AAA studio product in 2016. It's the interactive equivalent of a <i>Fast and Furious</i> movie: mixing comforting aesthetics (as far as the intended audience is concerned, at least) with the maximum amount of intense parallax motion. Nobody's going to mistake it for fine art &mdash; it has none of the thoughtful playfulness of, say, <i>Dishonored</i> &mdash; but not everything should be fine art. It's a great game. Tue, 13 Dec 2016 20:34:32 -0800 http://www.milezero.org/index.php/gaming/design/guns_and_glory.html/gaming/design Return values http://www.milezero.org/index.php/tech/return_values.html This is a tale of two algorithms. <p> Every now and then, someone publishes a piece of crossover writing that blows me away. Last week, Claudia Lo at Rock Paper Shotgun <a href="https://www.rockpapershotgun.com/2016/11/02/rimworld-code-analysis/">examined the algorithms behind relationship simulation</a> in the indie game <i>Rimworld</i> by decompiling its code: <blockquote> The question we're asking is, 'what are the stories that RimWorld is already telling?' Yes, making a game is a lot of work, and maybe these numbers were just thrown in without too much thought as to how they'd influence the game. But what kind of system is being designed, that in order to 'just make it work', you wind up with a system where there will never be bisexual men? Or where all women, across the board, are eight times less likely to initiate romance? </blockquote> <p> I want to take a moment to admire Lo's writing, which takes a difficult technical subject (bias in object-oriented simulation code) and explains it in a way that's both readable and ultimately damning to its subject. It's a calm dissection of how stereotypes can get encoded (literally!) into entertainment, and even goes out of its way to be generous to the developer. I haven't talked much about games journalism in the last few years, but this is the kind of work I wish I'd thought to do when I was still writing. <p> In short, Lo notes that the code for <i>Rimworld</i> combines sexuality, gender, age, and emotional modeling in a way that's more than a little unsettling: women in the game are all bisexual and may be attracted to much older partners, while men have a narrower (and notably younger) attraction range. The game also models penalties for rejection, but not for being harassed, which leaves players trying to solve bizarre problems like "attractive lesbians that destroy community morale." <p> Part of what makes Lo's story interesting is how deeply this particular simulation reflects not just general social biases, but the particular biases of its developer. It took a lot more work to encode a complex, weighted system of asymmetrical attraction than it would to just use the same basic algorithm for everyone. Someone planned this very carefully &mdash; in fact, since the developer jumped into the comments on the piece with a pseudoscientific rant about the non-existence of bisexual men, we know that he's thought <i>way too much</i> about it. He's really invested in this view of "how people are," and very upset that anyone would think that it's just the slightest bit unrealistic or ignorant. <p> Keep that in mind when reading <a href="https://www.propublica.org/article/facebook-lets-advertisers-exclude-users-by-race">Pro Publica's investigation into Facebook ad preferences</a>, in which advertisers can target ads toward (or against) particular "ethnic affinities" in violation of federal laws against discrimination in housing and other services. "Affinity" is Facebook's term, a way of hiding behind "we're not actually discriminating on race." Even for the blinkered Silicon Valley, it's astonishing that nobody thought about the ways that this could be misapplied. <p> The existence of these affinities may be confusing, since Facebook never actually asks about your ethnicity when setting up a profile. Instead, it generates this metadata based on some kind of machine-learning process as you use the service. As is typical for Facebook, this is not only a very bad idea, it's also very badly implemented. I know this myself: Facebook thinks I have an ethnic affinity of "African-American (US)," probably because my friend group via Urban Artistry is largely black, even though I am one of the whitest people in America (there doesn't seem to be an "Ethnic Affinity: White" tag, maybe because that's considered the default setting). <p> <img src="/images/facebook_affinity.jpg"> <p> Both Facebook and <i>Rimworld</i> are examples of programming real-world bias into technology, but of the two it's probably Facebook that bothers me more. For the game, a developer very intentionally designed this system, and is clear about his reasons for doing so. But in Facebook's case, this behavior is partially emergent, which gives it deniability. There's no source code that we can decompile, either because it's hidden away on Facebook's servers or because it's the output of a long, machine-generated process and even Facebook can't directly "read" it. The only way to discover these problems is indirectly &mdash; such as how some news organizations are trying to collect and analyze Facebook's political ads <a href="https://addons.mozilla.org/en-US/firefox/addon/adtrack-new-york-times/">via user reporting tools</a>. <p> As more and more of the world becomes data-driven, it's easy to see how emergent behavior could reinforce existing biases if not carefully checked and guarded. When the behavior in question is <a href="http://www.urban.org/urban-wire/pokemon-go-changing-how-cities-use-public-space-could-it-be-more-inclusive"><i>Pokemon Go</i> redlining</a>, maybe it's not such a big deal, but when it becomes housing &mdash; or job opportunities, or access/pricing for services &mdash; the effects will be far more serious. Class action lawsuits <a href="http://arstechnica.com/tech-policy/2016/11/facebook-users-sue-over-alleged-racial-discrimination-in-housing-job-ads/">are a reasonable start</a>, but I think it may be time to consider stronger regulation on what personal data companies can maintain and utilize (granted, I don't have any good answers as to what that regulation would look like). After all, it's pretty clear that tech won't regulate itself. <hr> <h4>Addendum: on journalism and public policy</h4> <p> I'm posting this the night before Election Day in the USA. Like a lot of newsrooms, The Seattle Times has a strict non-partisan policy for its journalists, so I can tell you to vote (please do! it's important!), but I can't tell you <i>how</i> I think you should vote or how I voted, and I'm discouraged from taking part in public activities that would signal bias, such as caucusing for either party. It's a condition of my employment at the paper. <p> Here's what I think is funny: in the post above, I lay out a strong but (I think) reasoned argument for public policy around the use of personal data. While I'm not particularly well-sourced compared to the journalists at Pro Publica, I am one of the few people at the Times who can speak knowledgeably about how databases are stored and interact. I can make this argument to you, and feel like it carries some authority behind it. <p> But I can only make that argument because our political parties do not (yet) have any coherent preference on how personal data should be treated. If, at some point, the use of personal data was to become politicized by one side or another, I'd no longer be free to share this argument with you &mdash; the merits of my position wouldn't have changed, nor would my expertise, but I'd no longer be considered "objective" or "unbiased." <p> The idea that reporters do not have opinions, or can only have opinions <i>as long as the subjects don't matter</i>, seems self-evidently silly to me. Data privacy is a useful thought experiment: in this case, I'm safe as long as the government never gets its act together. If that seems like a terrible way to run the fourth estate &mdash; indeed, if this sounds like a recipe for the <a href="https://www.buzzfeed.com/craigsilverman/how-macedonia-became-a-global-hub-for-pro-trump-misinfo">proliferation of fact-free publishing outlets</a> encouraged by the malicious inattention of Facebook &mdash; I can't disagree. But to tie this to my original point, however this election turns out, I think a lot of journalists are going to need to ask themselves some hard questions about the value of "objectivity" in an <a href="https://www.washingtonpost.com/news/the-intersect/wp/2016/10/12/facebook-has-repeatedly-trended-fake-news-since-firing-its-human-editors/">algorithm-powered media universe</a>. Mon, 07 Nov 2016 21:01:13 -0800 http://www.milezero.org/index.php/tech/return_values.html/tech How I built the ST3 guide http://www.milezero.org/index.php/journalism/new_media/st3_guide.html On election day, voters in the Seattle metro area will need to choose whether or not to approve Sound Transit 3, a $54 billion funding measure that would add miles of light rail and rapid bus transit to the city over the next 20 years. It's a big plan, and our metro editor at the paper wanted to give people a better understanding of what they'd be voting on. So I worked with Mike Lindblom, the Times' transportation reporter, and Kelly Shea in our graphics department to create <a href="http://projects.seattletimes.com/2016/st3-guide/">this interactive guide</a> (<a href="https://github.com/seattletimes/st3-voter-guide/">source code</a>). <p> The centerpiece of the guide is the system map, which picks out 12 of the projects that will be funded by ST3. As you scroll through the piece, each project is highlighted, and it zooms to fill the viewport. These kinds of scrolling graphics have become more common in journalism, in part because of the limitations of phone screens. When we can't prompt users to click something with hover state and have limited visual real estate, it's useful to take advantage of the most natural verb they'll have at their fingertips: scroll. I'm not wild about this UI trend, but nobody has come up with a better method yet, and it's relatively easy to implement. <p> The key to making this map work is the use of SVG (scalable vector graphics). SVG is the unloved stepchild of browser images &mdash; badly-optimized and only widely supported in the last few years &mdash; but it has two important advantages. First, it's an export option in Illustrator, which means that our graphics team (who do most of their work in Illustrator) can generate print and interactive assets at the same time. It's much easier to teach them how to correctly add the metadata I need in a familiar tool than it is to teach the artists an entirely new workflow, especially on a small staff (plus, we can use existing assets in a new way, like <a href="http://projects.seattletimes.com/2016/boeing-timeline">this Boeing retrospective</a> that repurposed an old print spread). <p> Second, unlike raster graphic formats like JPG or PNG, SVG is actually a text-based format that the browser can control the same way that it does the HTML document. Using JavaScript and CSS, it's possible to restyle specific parts of the image, manipulate their position or size, or add/remove shapes dynamically. You can even generate them from scratch, which is why libraries like D3 have been using SVG to do data visualization for years. <p> Unfortunately, while these are great points in SVG's favor, there's a reason I described it in my Cascadia talk as a "box full of spiders." The APIs for interacting with parts of the SVG hierarchy are old and finicky, and they don't inherit improvements that browsers make to other parts of the page. As a way of getting around those problems, I've written a couple of libraries to make common tasks easier: <a href="https://github.com/seattletimes/savage-query">Savage Query</a> is a jQuery-esque wrapper for finding and restyling elements, and <a href="https://github.com/seattletimes/savage-camera">Savage Camera</a> makes it easy to zoom and pan around the image in animated sequences. After the election, I'm planning on releasing a third Savage library, based on our <var>&lt;svg-map&gt;</var> elements, for loading these images into the page asynchronously (see my <a href="https://source.opennews.org/en-US/articles/tag-soup-using-custom-elements-cover-elections/">writeup on Source</a> for details). <p> The camera is what really makes this map work, and it's made possible by a fun property of SVG: the <var>viewBox</var> attribute, which defines the visible coordinate system of a given image. For example, here's an SVG image that draws a rectangle from [10,10] to [90,90] inside of a 100x100 viewbox: <div> <svg viewBox="0 0 100 100"> <rect x=10 y=10 width=80 height=80 fill="white" stroke="black"></rect> </svg> </div> <p> If we want to zoom in or out, we don't need to change the position of every shape in the image. Instead, we can just set the viewbox to contain a different set of coordinates. Here's that same image, but now the visible area goes from [0,0] to [500,500]: <div> <svg viewBox="0 0 500 500"> <rect x=10 y=10 width=80 height=80 fill="white" stroke="black"></rect> </svg> </div> And here's one where we've zoomed in on the lower-right corner, by viewing a 40-unit box starting at [60,60]: <div> <svg viewBox="60 60 40 40"> <rect x=10 y=10 width=80 height=80 fill="white" stroke="black"></rect> </svg> </div> <p> Savage Camera was written to make it easy to manipulate the viewbox in terms of shapes, not just raw coordinates. In the case of the ST3 guide, each project description shares an ID with a group of shapes. When the description scrolls into the window, I tell the camera to focus on that group, and it handles the animation. SVG isn't very well-optimized, so on mobile this zoom is choppier than I'd like. But it's still way easier than trying to write my own rendering engine for canvas, or using a slippy map library like Leaflet (which can only zoom to pre-determined levels). <p> This is not the first time that I've built something on this functionality: we've also used it for our <a href="https://projects.seattletimes.com/2016/custom-paper-hawk/">Paper Hawks</a> and for visualizing connections between <a href="http://www.seattletimes.com/entertainment/visual-arts/in-seattle-art-world-women-run-the-show/">Seattle's impressive women in the arts</a>. But this is the most ambitious use so far, and a great chance to practice working closely with an illustrator as the print graphic was revised and updated. In the future, if we can polish this workflow, I think there's a lot of potential for us to do much more interesting cross-media illustrations. Fri, 28 Oct 2016 10:20:58 -0700 http://www.milezero.org/index.php/journalism/new_media/st3_guide.html/journalism/new_media