Today I took a break from working on gameplay code to get a little distance from the details and break up the sort of tasks I’m doing at any given point in time—this also keeps me from having a lot of dull “un-fun” code to write at the very end after all the main stuff is finished, something I learned from this blog entry. It went through some interesting iterations through the process of this first rough draft, so it’s worth talking about some of the concerns that came up.
This is going to be a bit of a short one, relatively, and I won’t get very code-heavy. It’s much more a post about user experience and the like. In a lot of ways, it’s very much a continuation of my last post about designing around the constraints and use of the phone. It also won’t be the last.
Let’s Get this Show on the Road
First off, a look at the screen as it currently stands, primarily because I didn’t think to take a bunch of screenshots while I was working on it. I just didn’t realize I was going to want to write about the work that went into it while I was mired in that work. Not an uncommon failing when I get deep into focusing on a project.
There’s a nice additive blend on the orbs as they pan back and forth over each other at different speeds. The FPS counter is, of course, a temporary benchmark.
I like simple designs, because I feel they have a certain elegance to them. So the plan was always for a black field with some simple white text and buttons.
The original idea for visual interest was to have three orbs—red, green and blue—floating around on separate orbits around the top-left corner of the N (the title was originally right-aligned). Each of these orbits would rotate, much like the planetary orbits do. It worked and it looked pretty decent.
However, while getting this working, I messed up my transformation numbers a little, using a zero for a scale value when I meant to use a one. That resulted in the three orbs oscillating back in forth. Sydney saw this and thought it looked really interesting. More so than the original plan did. So, knowing when feedback tells me an accident is a good one, I revamped the orb animation and added the other colors that appear in the game, trying several different positions and sizes relative to the text. Most of the time, I used them to make a sort of interesting color-shifting underline for the text, but it didn’t feel it was relevant enough to the look of the game. Thus, the current version.
Changing the orb setup removed some constraints on where the rest of the elements could be. I realized, while thinking about how I’d use the phone that the buttons weren’t convenient for typical right-handed use, so I moved the text to the left and the buttons right, since it would make them a more natural reach for how I expect the phone to be used. That said, I’m going to write some code to swap the sides based on a setting, because I realized a bit later that I was making assumptions based on handedness. I’ll do similar for the buttons on the game screen. Colorblindness is also an issue, but the game is based around color-matching, so at least for the short term, I’m not going to worry about it and accept there’s a segment of the population it won’t work for (at least for now).
Moving things around also let me increase the size and spacing of the buttons for easier touch control, based on the guidelines Microsoft has laid down in their UI guidelines. I’ve gone with a graphical button style using what I hope are pretty universal symbols for play, settings, and help. The idea here is if I can provide information without text, language barriers wont’ be a big issue. I dunno how well this will work across everything, but I guess we’ll see.
Side note: It’s kind of irking me that the only version of Segoe UI MS has lisenced for free redistributable use in XNA is the monospace typeface. Not that I feel like I should be looking a gift horse in the mouth, but it’s noticeably different from the non-monospace all over the rest of the phone. Bothersome when you want to try and be part of a consistent experience.