- Configurable Controls
- Configurable Auto-Repeat
- A few T-spin recognition bug fixes
- Changes in the color scheme to accommodate a wider range of monitor color temperatures.
- General UI improvements
It's an awesome feeling to have taken a project from a blank canvas to completion, and then finally share it with the world. I'm in an odd state of relief, anticipation, and excitation.
TwitchTetris has taken up the better part of my spare time, class time, and sleeping time for the past 3 months, so I though I'd share some of the lessons that I've learned during the development of the game.
Lesson #1: Acquire Nerves of Steel
Before posting it to the world, I shared the game to my class's Facebook page (about 100 engineers), and to /r/indiegaming on reddit. These were essentially the two least flaming-prone communities that I could think of publishing a soft-release to, as /r/indiegaming sees lots of games in all kinds of stages of development, and my class, all having gone through Engineering Co-ops, is fairly seasoned in the world of QA and constructive criticism. And the criticism I received from both sources was overwhelmingly constructive.
But, even when you get intelligent constructive criticism and recommendations about something that you've been working on for months, you feel like crap. It's like someone gave you a sincere recommendation on how to make your face less ugly. No matter how well intentioned it is, you feel your heart sink a bit.
My first response to the criticism, constructive or negative, was to get defensive. Across the board, my first thought was always:
The problem isn't a flaw in my app, clearly, you just happen to be an idiot who doesn't know how to use the app.
And the first thing I'd want to do is post a reply, informing the commenter about the correct way to play the game. Obviously, this is the worst thing I could have possibly done.
The only way to increase the quality of your app is to take all of the feedback in stride, and address each problem as a new technical requirement. It's tough to stay objective about feedback directed towards work that you've put a lot of yourself into, but fixing the problems as they are brought up is the only way you're going to turn criticisms into complements.
Lesson #2: Your Own Opinion is Irrelevant
I had a good friend in High School who was a very gifted writer (of English, not code) help me proof-read and perfect the myriad of essays and reports required for university and scholarship applications. One tip she gave me for writing was:
Always proofread by reading your sentences in reverse order. When you read forward, you're just reading out of your own memory of writing that paragraph and everything will make sense to you. Read the sentences in the wrong order, and you'll notice what doesn't make sense.
It makes a lot of sense, when you read backwards, all of the extraneous ideas that you formed in your head stop putting themselves in front of what you've written, and you'll be able to focus on the wording and syntax of the document. What I've found is that the same clouds of preconception about your own work apply to user experience design in the same way that they do to writing.
You'll probably run and use your own app hundreds of times before you manage to get to a state that you would call 'complete', from a user experience point of view. Every time you do that, you'll get a little more used to the 'oddness' of the incomplete app, to the point where all of the little quirks of your app just seem natural. In fact, the technical term for this is Classical Conditioning.
Unfortunately, that 'oddness' that you no longer notice, is very noticeable by your users, and as I mentioned above, they will let you know about it. As of now, I'm currently unaware of any kind of 'reading backwards' applied to UX design, so the only conclusion that I can draw is that a user's opinion of what seems broken in your app, should always trump your own opinion.
Lesson #3: Every Assumption You Make is Wrong
I know that this point tends to be cliche, but I felt like it needed to be mentioned. So instead of rambling on about the concept of assumption, I'll just leave you with a list of invalid assumptions which I tried, and failed, to get past the users in earlier versions of TwitchTetris:
- Users will read instructions located somewhere on the page
- Users can accept a slightly different control scheme from what they might be used to.
- Users will read instructions located very closely to the thing they're working with
- Users will wait for more than 5 seconds before assuming the page isn't going to load, and try refreshing
- Users will read instructions located directly on top of the thing they're working with
- Users will understand that you need a device with a keyboard to play a game with keyboard input