Hacked By GeNErAL
Console Wars does a great job capturing Sega’s willingness to try new ideas. And a lot of the ideas involve celebrities.
It was interesting to read about them planning the Sega Star Kids Challenge and bringing celebrities to the Sonic 2sday event:
A practice session may seem trivial, but it was important to Sega that these young celebrities give the impression that they really did love videogames and weren’t just heartthrobs for hire.
Wouldn’t ever want to make them look foolish.
Again, the best parts of Console Wars are the behind-the-scenes looks at Sega’s marketing strategies. The Super Nintendo had Mode 7, which made games like Star Fox and Mario Kart possible. Now that I’m doing some image searches, I’m learning it was also used in other games for certain sequences, like every overworld map.
I like imagining a .ppt from Nintendo with a slide titled “Guidelines: fitting races into stories” with 7 bullet points underneath.
Sega didn’t have an actual thing to strike back with, so they decided to strike back with not an actual thing:
While looking through the manual, Latham found something that kind of, sort of, maybe fit the bill: Burst Mode, which in theory allowed the Genesis to process code faster than Nintendo’s chip could. Although this sounded like exactly what the marketing team wanted, Latham explained that Burst Mode actually had very little to do with the graphics, velocity, and overall performance of Sega’s games. To say that Burst Mode was the reason that Sonic could move so fast would be like saying that cheetahs were faster than elephants were because of their spots.
Burst Mode turned into Blast Processing.
I remember always checking the “Graphics” rating first when reading EGM or GamePro. But I knew that high gameplay scores went further for how much I’d enjoy the game. (There’s something about UX in there.)
The book ends in the very early stages of the 32-bit era. When our family got a Playstation, one of the first giant-jeweled-case games we got was NBA Live 96.
I remember thinking my dad would think this purchase was totally worth it if he saw the graphics. So one day I told him close your eyes okay now open them.
“Can you tell it’s not live TV?”
And we had english TV channels, but they had weird mixes of syndicated shows. The oddest part was that instead of commercials for products, there would be commercials about military life and American history. So most of the American marketing I experienced was through video game magazines.
They talk about the impact of a particular GamePro cover where Star Fox is on the front of it. From Console Wars:
“But why?” Arakawa asked Tilden, looking at the April 1993 issue of GamePro magazine. On the cover, right there in front of them, was artwork from Nintendo’s Star Fox. Not only had this artwork been intended for Nintendo Power, but White had specifically met with Arakawa, Tilden, and Harman to discuss sharing it with outside magazines and had explicitly been told not to do so.
As long as I remember, our parents let us subscribe to at least one video gamemagazine. And any time we went to the book store I’d first look at Goosebumps for the newest release then read the game magazines.
Game Players magazine had a newsletter that, looking back, seems like weird internet before the internet became what it is today.
Something I remember is one issue where a reader wrote inn asking how the magazine makes the stitched together maps. And they said it was software that costs hundred and hundreds of dollars.
I remember picturing some kind of mega-expensive super computer. Where like they’d make the brontosaurus in Jurassic Park and then in another window they’d have Link to the Past maps. Now I realize it was probably Photoshop.
Game Players turned to Ultra Game Players then disappeared altogether. Then we switched to an EGM subscription. GamePro (of PROTIP fame) skewed younger. We had some of those but they were usually one off purchases from the book store.
Nintendo’s side project was publishing a magazine with more than a million subscribers. As far as I remember, the book store didn’t have Nintendo Power. So the only kids that had copies had subscriptions.
I remember the Star Fox cover but really had no idea it was a big deal. I was probably in 2nd grade or 3rd grade so I didn’t understand that anything was a big deal. I really had no idea that Nintendo Power was a giant monthly advertisement.
(Then one day you find out Saturday-morning cartoons were toy advertisements and the world falls apart. That’s the adult version of finding out Santa Clause isn’t real. In between those discoveries is finding out wrestling isn’t real.)
Okay I exaggerated, Console Wars mentions RPGs exactly once:
Oshima partnered up with Yuji Naka, a brilliant hothead in the programming department who was responsible for one of Sega’s most popular series: Phantasy Star, a sci-fi role-playing game (RPG) about a resilient young female warrior bent on galactic revenge with the help of a muskrat named Myau and a wizard named Noah.
Side note: I thought Zelda was generally considered an RPG. According to my research (clicking a few links on a Google search), most people don’t consider it an RPG. And get pretty passionate about it not being an RPG. Anyway, I guess that further helps the case that Console Wars has one single mention of an RPG.
Searching the book for “Final Fantasy” returns nothing. In America, RPGs might not have had as much an impact on the 16-bit console war as, say, Mortal Kombat. But Final Fantasy III should get at least one mention. (The book ends before Chrono Trigger’s release, so there’s at least some explanation.)
RPGs make up 6 of the top 20 best selling SNES games.
Anyway, if RPGs were mentioned I would’ve had a better excuse for writing about a top–3 life achievement of mine…
I grew up in Japan on a U.S. Navy base. Which means it’s not really like growing up in Japan and not really like growing up in America, either. Families would go off-base at night or on weekends. And you’d also live off-base while you were on a waiting list for on-base housing.
On these weekend trips out, my and I would wander around the videogame section of a department store (Daikuma or Da’e) while our parents got groceries. On one of these trips, we noticed people gathered around a spinning wheel and walked over.
After watching a few times, it looked like you paid 2000 yen, spun the wheel, and got to pick from either 1, 2, or 3-game packages. Anyway, our mom let us spin and we got the 2-game choice. We picked the package with Super Smash TV and… some game with a bird on the cover. My brother had heard of the game but we were mostly in it for Smash TV.
The other game was Final Fantasy V. I was extremely bored any time I watched my brother play it. Then one day I tried it out and it didn’t make sense at all. Literally. It was in Japanese, after all.
I started out wandering aimlessly. Then I continued wandering around aimlessly. For dozens of hours. And just memorized the menu location for some useful potions (mostly just elixir and HP recoveries).
A main character blinks away, teleporting somewhere. Some girl joins the party for unknown reasons. Then I realize the guy teleported to heaven because guess what actually he died.
Dozens of hours turned to dozens and dozens of hours. Memorizing the +100HP potion became memorizing the +1000HP potion. Then I beat it.
I still have basically no idea what the story is about.
So, you know, don’t make your UX like that.
“Let me show you something.”
I stepped aside and an older kid—picture young John Connor—took the joystick. A few moments later Sub-Zero ripped someone’s head off with their spine attached. Awesome.
This was my first time seeing a fatality in Mortal Kombat. Apparently some parents didn’t think this was great, so the first Mortal Kombat had sweat instead of blood. Except for the kids with a Genesis.
“Some sort of blood code,” Garske explained to Kalinske. “So when you buy the game, it comes without any of that over-the-top gore and violence. But then all you have to do in order to get the game to look just like it does in the arcades is enter a code. A combination of buttons and then boom—blood everywhere.”
So on the SNES when I’d try to rip a spine out, instead I’d see this:
“As long as the shattered body parts aren’t red ice, we’re Gucci.”
I made the last quote up. My point was going to be that the SNES had watered down fatalities. But… this seems pretty brutal too. But these seemed much tamer as a kid.
I remember being really aware of how the first game had sweat. Nobody was buying the SNES version and most of my friends were Nintendo kids. And that it was a big deal that the sequel would have blood without a code.
I have cloudy memories of going to an AAFES store with my brother and our parents to get Mortal Kombat II. And it was behind this glass case with a rating on it. (Though it wasn’t one of the ESRB ratings that would eventually come out.)
Anyway we got it and then played it. A lot. I remember seeing MKII the first time at an arcade in an airport. And someone (again, an older kid) had what looked like a strategy guide but it was just a bunch of printouts.
And these printouts had all the moves and fatalities. That might have been my first exposure to anything related to the internet.
Console Wars talks about the different approaches toward violence that SEGA and Nintendo took.
One of the patterns is called “Familiar Tools” talking about the tools programmers use.
Write down a list of your familiar tools. If the list has less than five items, start hunting around for tools that will fill the gaps in your toolbox. This may simply be a matter of identifying a tool you already use but don’t know well enough, or it may involve finding new tools altogether.
I’ve written some in-depth posts about learning the basics of prototyping tools like Form, Origami, and Framer. The “Familiar Tools” pattern reminded me to take a look at my current toolbox.
There are a lot of different tools out there, and if you’re just starting out it can be overwhelming to pick some out to learn. You might even be frozen by all the options.
As far as a hard-skill toolbox goes, here’s what I’d recommend to a new designer. Learn a different tool in each fidelity well.
Pen and paper for lo-fi thinking: Sometimes completely overlooked. Tools for animating microinteractions are fun to use. They’re fun to play with so it’s tempting to jump into super high fidelity and work with motion.
If you’re designing in high fidelity and not testing with actual users, it’s probably too early. Pen and paper can take you a long way when thinking through ideas on your own.
Static mocks for going through flows: Sketch. It’s become pretty standard. At least as far as the echo chamber goes.
High fidelity prototypes for mobile: A good old “it depends”. Just try them out and see which ones click for you. Framer and Origami have great communities and that goes a long way toward the usefulness of a tool. I still want to try Principle.
High fidelity prototypes for desktop: The advantage of the mobile interaction design tools is that they let you try things out without learning Swift/Objective-C or Java and learning the respective development processes.
HTML/CSS is more approachable than any toolset for native development. Right click in the browser, click “Inspect”. Tinkering around, changing values, and seeing the changes might be the best way to start learning CSS.
Get proficient with Chrome developer tools. Or the equivalent in the other browsers. Sit with a developer you work with and have them show you around the inspector and console. It’s a great investment of time.
Visual design: Here’s my biggest gap. Illustrator seems to still be the tool of choice of digital illustrators. I’d love to learn.
As far as soft skills go, they’re harder to sit down and practice. A lot of it comes through experiencing different situations firsthand. (I’d recommend actively avoiding the soft skills such as getting offended about interchanging UX/UI/interaction/product designer titles and thinking up UX analogies.)
Apprenticeship Patterns has a pattern called “Practice, Practice, Practice”. Adewale and Dave talk about having a place where you’re comfortable making mistakes. Again, I’ll connect this apprenticeship pattern to something I read In Deep Work. A lot of the ideas in Deep Work also overlap with the idea of deliberate practice:
Its core components are usually identified as follows: (1) your attention is focused tightly on a specific skill you’re trying to improve or an idea you’re trying to master; (2) you receive feedback so you can correct your approach to keep your attention exactly where it’s most productive.
Many designers already receive plenty of feedback during the design process. (If not, check out my book notes on Discussing Design. It’s a great book by Adam Connor and Aaron Irizary about giving and receiving good critique.)
Deep Work is more about the focused-attention component. If you’re going to spend deeply focused time on something, you’ll want to make sure it’s the right thing. Apprenticeship Patterns provides some guidelines for picking exercises for practice:
Make sure that it’s just a little harder than one you know you can easily solve. You should have to struggle to solve it the first time. Solve this exercise from scratch once a week for the next four weeks, and observe how your solutions evolve. What does this tell you about your strengths and weaknesses as a programmer?
Day to day design work might not always stretch those skills. If that’s the case, sit down and identify areas you want to grow. Then find or create exercises of your own for practice.
When I started learning Framer, I learned a lot by trying to re-create animations from different apps. These exercises were usually scoped to a single interaction. I tried re-creating pull-to-refresh animations, I tried re-creating parts of the Material Design launch reel, I tried re-creating examples from the Framer docs.
The great thing about Framer is that the source code is available for a lot of things you’ll want to do. You can always attempt and then compare your approach to a working example and see where you can improve.
It’s a little different for Sketch and the other interaction design tools. It might not be as easy to find source files to learn from. This is where it’d be great to have a mentor to look at your work. You can share your approach to different things and they can explain where you can improve. I seem to always learn some sort of technique when I watch others using Sketch.
Apprenticeship Patterns talks about going deep into new subjects as a good way to learn. The risk with going in the deep end is that you’ll sometimes get in hairy situations. Competence can be the edge of the pool: something familiar that you can grab onto. They discuss applying the “Retreat into competence” pattern:
I tried thinking about how this could be applied by designers. A lot of the apprenticeship patterns have you looking at how you can stretch your knowledge. You look at valuable tools and techniques you’re not familiar with and deliberately practice with them.
As a side effect, you’re thinking through tools you are familiar with. These comfortable tools are the ones you can retreat to. That might mean taking a break from the latest prototyping tool to retreat into Sketch. Or taking a break from thinking through multi-screen flows to focus on some motion interaction with Framer.
(I’m trying to write book notes compilations one section at a time. One excerpt per day with the goal of filling one iA Writer screen up. About 350 words.)
This week, I’m focusing on Apprenticeship Patterns, by Dave Hoover and Adewale Oshineye. Dave and Adewale talk about software as a craft and give guidance on how you can improve as a craftsman. It’s targeted toward developers, but a bunch of it applies to designers. (And even beyond that.)
One of the patterns is called “Expand your bandwidth”:
Expanding your ability to take in new information is a critical, though sometimes overwhelming, step for apprentices. You must develop the discipline and techniques necessary to efficiently absorb new information, as well as to understand it, retain it, and apply it.
They discuss setting up Google Reader to consume RSS feeds. They discuss one of the pitfalls that seems all too common today:
It’s possible to become obsessed with gathering and consuming new information, particularly as it becomes easier and easier to get at up-to-the-second thoughts on the most prolific thinkers in our industry. Some people could become lost in the sea of interesting information, and never come back to actually crafting software.
The book is from 2009 and there’s no mention of Twitter for keeping up with the latest information. That said, I was a pretty heavy Reader user and was just as addicted or even more so I ever was of Twitter. Reader made a lot of full content readily available.
One day, I remember stepping back and thinking, “Do I really need to see basically the exact same news from Engadget and Gizmodo?” That started the culling and then I was able to really cut things down and then eventually accept that I don’t need to read every. single. thing.
Because there’s value in all the available information out there, it might seem like a good idea to seek out as much of it as possible. Cal Newport discusses this in his book Deep Work:
This argument, however, misses the key point that all activities, regardless of their importance, consume your same limited store of time and attention. If you service low-impact activities, therefore, you’re taking away time you could be spending on higher-impact activities. It’s a zero-sum game. And because your time returns substantially more rewards when invested in high-impact activities than when invested in low-impact activities, the more of it you shift to the latter, the lower your overall benefit.
It’s important to remember that time taken by shallow activities could be applied to more important activities. Having taken extended breaks from different social media, there’s major FOMO. It goes away once you realize enough times that you never really miss much.
I started a refresh for this site. I want to continue writing regularly. However, I don’t think it will take the form of long articles about design sprints and design tools. I started writing newsletters to experiment with shorter writing, but even those took longer than I expected each time. I still want to send something out. For the next issue, I’m going to try writing a short post each day and collecting those to send together bi-weekly.
I would write the newsletter and then re-write over and over and try to make the whole thing coherent. Sometimes things got a bit forced because links just don’t always relate. And I was finding myself putting it off because I was looking for very large chunks of time to work on it. And of course, I wasn’t finding those large chunks of time.
Writing seems similar to working out in that you’ll see improvements through consistency. You can’t work out for 8 straight hours to make up for 8 individual hour-long workouts.
I’ll share links and book quotes and share some thoughts to how they can relate to different stages of a design sprint. Sometimes. Other times I’ll share how they relate at least to design.
Thanks for bearing with me.
Last week, I read Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. I picked it up after seeing Ale Muñoz (designer/developer working on Sketch) recommend it as a resource for learning how to teach in a response to Koen Bok (Framer co-founder).
It’s about improving as a developer and looking at programming as a craft. A lot of it can be applied to improving as a designer. (Not to mention a ton of other careers.) One of the patterns discusses the importance of writing down what you learn:
When Dave was Reading Constantly during his apprenticeship, he kept a text file in which he transcribed all the quotes that shaped his learning. Over the years, that file grew to contain over 500 quotes, and Dave eventually decided to upload it and share it online.
(And “Reading Constantly” is another pattern I’ve been trying to apply.) Over the years, I’d like this site to have over 500 quotes. This is one of the first.