August 13, 2017 at 11:32PM

Today I Learned: 1) ...how to make hash browns! It's, uh, embarassingly easy, in retrospect. You start with a potato. You peel the potato. You grate the potato (the hardest part). You heat some oil on medium-high heat, and dump the (peeled and shredded) potato onto the pan. You flip it when it's nice and toasty on the bottom; you take it off the pan when it's nice and toasty on the *other* bottom. Salt and pepper to taste. Eat. (Advanced techniques include pan-flipping the hashes and adding chopped shallots. Yeah.) Thanks to Erik Jue for teaching me hash-brown skills! 2) Watched a talk by Greg Foertsch, the art director on Firaxis Games' XCOM games. Some advice that's specific to art direction for video games: * Don't make textures until the last possible minute! Textures take a ton of time to make, and they *don't help you iterate faster*. If you spend time making textures, you're going to end up texturing a lot of things that don't end up in the final game. Better that you'd used that time to figure out what things work and what things don't. * Presentation > style. How you present your game's art and assets is ultimately more important than the exact look and feel of those things. Also, presentation informs style more than the other way around. * Early on in a game's development, it's insanely helpful to make a "vertical slice", which is basically a playable demo where everything's in place, even if it's only for a tiny chunk of the game. Turns out that usually, the first time you make a game, that first vertical slice isn't very fun. But you need that to tell you what to do to make your *next* vertical slice better. It's also a good rally point to keep everyone focused and engaged. * Level of detail really isn't that important. Or rather, having *high* level of detail isn't really that important. Firaxis ended up scaling *back* the level of detail on a lot of objects (guns and character models, in particular), because they looked better as simple, over-stylized versions. Some advice that's good for team projects (or just complex projects) in general: * An early period of intense collaboration can be really, really good for the team. XCOM's art team was stuck without any engineers for about the first six months of development, so they all crammed into a much-too-small workspace and hammered out a "gameplay video" that helped them work through a lot of the art design elements -- things like what the UI might look like, how tall to make various game objects like houses and cover and people, how and where to place the camera, etc. At the end of that, the combination of a) intense work on b) a concrete goal c) in an enclosed space gave the team a really strong sense of "buy-in" that fueled them through the rest of the project. * Drawing from the same vignette, I suspect what a team does while stuck says a lot about how that team works. At first blush, it might look like an art team can't really do anything useful without an engineer, but XCOM's art team did without one for *six months* and ended up solving a lot of the art and presentation problems of the game. * One of the things that I've seen over and over again from the various stories I've read of XCOM's development is that it's REALLY IMPORTANT to be able to tell your teammates that something sucks. It seems that Firaxis managed to screw up almost everything about XCOM at some point during development. What saved them was a strong culture of criticism. People were expected to say when something did or didn't work, and they *did*. That's what let Firaxis push the game through two complete overhauls and come out the other end with one of the best strategy games out there. * Scale back early. Set production goals early, and if they don't get met, either change the end goals or rethink how you are making things. 3) Matplotlib's colormaps all come with inverses -- just append a "_r" to the end of the colormap name and you'll get the reversed version.