Showing posts with label UI. Show all posts
Showing posts with label UI. Show all posts

Friday, April 22, 2016

Screenshots that Clear a Path

Recently, I've been thinking about UI, about presentation, about gifs and screenshots.

When I think about screenshots and gifs, I assumed I would think about visually impressive games. But normally, that's not what I see at all. I see a deluge of charming images from smaller, indie games that happen to fit well into a screenshot.

I think this is easy to explain: indie devs are naturally attracted to games that make for good screens and gifs. They tend to develop those games, because when they share an impactful screen or gif, they instantly get feedback on how cool it is.

And I think that's great. A powerful screenshot is forever. It doesn't require you to be curious, or interested, or click through, or even care: you just happen to see it and you're drawn in. A video ad or an LP requires you to already be interested, to be willing to start up a video and sit through it. In the long run, I think a screenshot might be better than a video if you want to try and get strangers interested in your game.

I started thinking about what screenshots and gifs I like to see, and the answer was simple: I like the ones that show me the game's potential.

Whether the game is a tiny indie title or a huge blockbuster, just showing off a game's visuals or basic appeal doesn't affect me at all. I need to get a feel for what it would feel like to play the game.

This doesn't mean taking a screenshot of a cool moment, necessarily. For example, Among Thorns doesn't have any screenshots of "cool moments". But it does have evocative screenshots that make an impact.

The screenshots show hints of what the game contains. Mood, story, play - it's all hinted at, at least in the first and last screenshot. You get a feel that the game contains many subtle, cool things, even though there's not really anything amazing shown right up front. No boss getting shot, no diving from an airplane, not even any real UI.

And I started to think: what if we design our games specifically to always look good in screenshots? Specifically to always gif well? What if there was literally no way to take a screenshot or gif which did not give a casual viewer a sudden attack of curiosity?

Inside a good screenshot or gif are a few common elements. Obviously, it might be of something funny or moving, like a dog glitching through a floor or whatever, but let's put that aside and look at universal elements.

A good screenshot is visually readable, even at lower resolution than the game. Even if we don't know what's going on in the play of the game, we have to know what's going on in the world of the game. We don't know if the player set up the two people at the noodle shop, but we know there are two people at a noodle shop.

A good screenshot shows the mood of the game. The cool lighting and dark night immediately speak to us, as would a cheerfully primary-colored children's game. Screenshots with generic tones or giant spreadsheets don't appeal.

A good screenshot shows us hints of what we can accomplish or experience. Not necessarily as play, but during play. For example, we don't know whether we can choose to stop by the noodle shop and interact with it. We just know that we will stop by the noodle shop and interact with it. The distinction is important, because it means we don't have to show interaction cues or whatever. We can just show, by context, that you're going to be involved in these things.

Let's talk about a game that does this really well: Minecraft.

In Minecraft, it's almost impossible to take a screenshot without accidentally showing all these things. If you take a picture of an empty landscape, you know that Minecraft is about vast expanses of land that you can freely explore, and the open, adventurous mood shines through. If you take a screenshot of a deep cave, you know you can explore scary caves. If you take a screenshot of a little hut you built, you show that Minecraft is approachable at a small scale - anyone can bung something together. If you take a screenshot of a vast city, you show the upper limits of what Minecraft can achieve.

But that's not the limit.

If you take a picture of a multiplayer game, you can immediately tell it's multiplayer rather than containing NPCs, because of the subtleties of how multiplayer characters are portrayed (name tags, unique costumes, off-kilter pathing, etc). If you take a picture of your inventory, you can immediately see the scope and scale of the item management and crafting. If you take a picture of the title screen, not only is there a world in the background that shows you what's up, but the actual title elements show you can do mods and stuff.

In fact, the screenshots of Minecraft are much more powerful than the actual play. When you're actually playing Minecraft, it starts opaque and confusing and you punch trees. I mean, they've softened it recently, but when it was getting popular, it was almost unapproachable. But because you knew what Minecraft could do, you stuck with it.

I think there is merit to designing a game specifically to force this. Specifically so that whatever screenshot the player takes, it will plant the play and tone and experience of your game into everyone's head.

"Aren't all games like that?"

No. Think about GTAV. A lot of people really love this game. But screenshots of GTAV are almost universally of scenery. You sometimes see hints that your player can drive, or hang-glide, or shoot guns, but you don't get a feel for what it feels like to do those things or what effect it has. Moreover, despite the beauty of the scenery, interacting with that scenery is not a core part of the game, it's just space you can cross.

On the other hand, Minecraft is about half scenery and half houses. Even just taking the shots of scenery into account, you can clearly feel the interactability of the scenery because of its voxel nature and first-person perspective. Anyone with an experienced eye can tell that GTAV's scenery is canned, non-interactive. But Minecraft's scenery is weird and clunky, and even if you didn't know anything about Minecraft you can still tell there's something unusual about it, and it doesn't trigger your "oh, it's just canned shit" sense.

Whether accidentally or on purpose (almost certainly on accident), Minecraft has nothing in it that is just glitter. Every screen shows something you can do or feel or experience. Even menu screens, even "sleeping at home" screens, even "just loaded up the game for the first time" screens. Moreover, none of the screens show something tropey or standard (well, except in that they've been cloned since then).

By either cutting out all of the fluff or engineering the fluff to reflect the unique things you can do, I think we can have the same sort of result. No more noninteractive worlds that are filled with set pieces nobody cares about. No more menus that show you can "equip guns". Those say nothing about what makes the game new or interesting or unique.

Anyway, I've been thinking about it a lot, because I'm making The Galactic Line, and in my head it was not screenshotting well. Now that I've started to think about it, I've suddenly found my path forward is super-clear. I've come up with ways to present gameplay that was foggy and spreadsheety before. I think I've found a great basis for how to make the game look and feel great - by simply imagining how any given system would look if someone screenshotted it and put it on Twitter with the caption "hey, anyone want to play this game?"

And part of that came from looking at other space games, other Sims games, and seeing what screenshots were the most powerful and evocative.

I think it's really improved the game. It's certainly improved my vision and motivation!

... next step is making it gif properly, but I'm not sure I can manage that with The Galactic Line. It's not exactly an action game.

What are your opinions?

Wednesday, September 19, 2007

Joy of UI

At work, we got Microsoft Office ULTIMATE 2007! Wow! ULTIMATE, huh?

A lot of people seem to like Office 2007's "upgrades". What I notice is their "ribbon" design that has replaced toolbars and drop-down-menus. Some people like ribbons. To me, they're a retarded bastard child with the worst features of both toolbars and drop-down menus.

See, I like customizing my workspace. I'm the kind of guy who actually changes the resolution of my monitor depending on which program I'm working in. Toolbars - lovely, customizable, dockable-undockable toolbars - were my favorite feature. Because I know how to copy and paste, I simply delete the "copy" and "paste" icons from my toolbar. I will never need them. I add obscure macros, delete "save as", etc, etc, until I am happy with my work environment.

In Office ULTIMAAAAAAAATE 2007, you have ribbons. Ribbons are drop-down menus with graphics. Presumably, the idea is to provide you with everything you need in a given "editing mode" without having to actually use a drop-down menu. Except they can't be undocked, so you can't operate in more than one mode simultaneously, and they can't be easily customized, so you're stuck with half your "ribbon" being filled with large icons for things that you'll never use and certainly don't require a hundred-pixel-wide icon for. However, if you minimize it then you can't do ANYTHING without wasting your time clicking on the menu.

The "quick access toolbar" is not a viable alternative, because it isn't dockable, partitionable, or segmented so that you can open or close subsets of it.

I'm sure someone will chime in with how wonderful ribbons are and how they solve all the problems mankind has faced in word editing. The only possible reason I can think of to like Ribbons is if you're trying to appeal to the most primitive users, and even then there's no reason to actually block customization.

It's kind of interesting. Being a gamer and a programmer, my priority is on efficient UI. Since UI makes or breaks programs of those sorts, you can see a clear evolution from decade to decade.

Doom had a giant bar across the bottom of the screen that really did nothing besides display your health. These days, HUD overlays are the way to go - tiny little displays that usually vanish when you're not actively in need of them.

Similarly, 3D design programs have added feature after feature after feature every year. Their user interfaces are cumbersome and complex, but actually get a little cleaner with every new program to emerge. Modern programs like ZBrush have a UI that isn't much more complicated than ULLLLLLLTTTIIIIIIIMMMAAAAAAAATE Office 2007, despite dealing with a data space two orders of magnitude more complex.

Presumably, the fact that Office 2007 has this nasty, useless "feature" is because a writer's real UI is the keyboard. So the toolbars and crap are really just add-ons. A car's interface is very sharp and well evolved for dealing with driving around at 80 mph - but the car radio and air conditioner generally have really shitty interfaces. Similarly, Word has a very sharp and well evolved way of letting you type onto the screen, but the toolbars or (gag) ribbons are add-ons that aren't under the same kind of pressure for efficiency.

:P

Tuesday, March 06, 2007

UI

User interfaces. Very important. That's really all I want to say. But that's kind of short, so I'll keep talking.

There's more to user interfaces than where you put your toolbar options or whether your ads are on the right. Everything has a user interface, even tabletop games and movie theaters. And they all have the same basic tradeoffs to decide on.

1. Ease of use. The clearer and easier a user interface is to use, the less mistakes users will make and the easier it will be for beginners.

2. Agility of use. The faster and more complexly a user interface allows you to control a situation, the better advanced users will like it and the more skill you can allow to be involved. Interestingly, "faster" and "more complex" are deeply related, sort of like MC2 equalling E. But that's a topic for another day.

3. Use of resources. The more resources your interface uses, the less resources will be available for other things. This is perhaps the most important, mostly because nobody thinks of it. Everything has limited resources, and I don't mean RAM. I mean players only have so many fingers, so much screen space, etc. Customizing your interface to perfectly suit your system is basically optimizing your resources.

For some examples of this: most computer games use a mouse and/or keyboard input. But that's not the end of the UI. It's the beginning.

A mouse has a high-fidelity response. It's naturally an extremely agile input, although it is generally considered to only have two buttons and a scroller, which is a critical limitation.

Some games use a mouse as a straight pipe. For example, a first person shooter, where the mouse controls the view. This maps to the mouse's capabilities extremely well: two axes of high fidelity. Of course, there aren't enough buttons, so FPS games also map key controls - lower fidelity but more speed and resources.

Other games like, say, a MMORPG, mostly use the mouse as a selector tool. They abstract away the interface, using the screen as an intermediary. Basically, they create a "custom keyboard" using the mouse and screen. Unfortunately, you only have one finger (two, if you count the right click) and can't really move very fast. So, in order to create a highly suitable UI, they've sacrificed speed, fidelity, and resources. Of course, their UI are perfectly suited for the game, which makes those limited resources stretch a long, long way.

Amusingly, tabletop RPGs have made the same choice. But unlike a MMORPG, they have no intermediary. They don't limit themselves to a screen or a mouse. They fill up a sheet of paper - or, if they run out, many sheets of paper - with the relevant details, and all those details can be accessed pretty quickly because of the virtually unlimited amount of visual space and the speed of paper-swapping.

Still, every GM is horrified by the amount of "paper-shuffling" that players - especially newbies - do. "What's your attack value?" "ummmm..." "Come on... it's right next to the freaking weapon you're using!" "Oh, um, the rifle?" "YES!"

This is because although showing everything is very agile, it is overwhelming and therefore the exact opposite of easy. Careful layout can minimize this problem, but most character sheets (and rulebooks) are built by experienced players for experienced players. Ease of use is less important to them than agility. Of course, when they run into a new game system with radically different rules, they revert... "ummmmm... so how many cards do I draw?" "It's right next to your edge style!"


The wiimote has enough potential to be worth it's own essay, but for now I'll simply limit myself to "It's not a fucking gimmick."

Anyhow, think about your user interfaces - tabletops, games you've programmed, hell, even LARPs. What tradeoffs did you make? How did it synergize with your system?