Launch Lessons

Today marks the official launch of TwitchTetris. I've progressed to a point where all of the required functionality is in place. Notable additions include:

• 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

TwitchTetris, the Beginning of TwitchCode

> HELLO, WORLD!
> Press Any Key to Continue...

I've created this blog to publish the projects that I'm working on or have finished, as well as to start discussion on whatever interesting ideas I stumble upon. Today marks the release of the first project I'm setting into the wild: TwitchTetris.

Currently, Tetris games on the web tend to fall into one of 2 categories:

1. High-Quality Flash games with obtrusive ads.
2. Low to medium quality games in flash or Html5 with noticeable game-play problems.

My problem is that when I want to play Tetris, I want to play it now, and I want it to play crisply and responsively on every platform. I don't want to wait for some video ad to finish before I can start playing, and there must not be any noticeable lag in the controls. And most of all, if the game does not follow the Tetris Guidelines (yes, Tetris has it's own regulatory agency), I'm not going to play it.

In short, I'm very particular in my choice of Tetris games, and as of now, no web-based implementation has met my requirements.

Enter TwitchTetris.

My first design decision was to not use the cluster-fustication that is Flash. Without even touching on the user experience problems of plugin dependencies, Flash implementations vary in quality and performance by operating system and browser. Tetris is one of the fastest games around, so differences in Flash run-times become very noticeable around level 12 of the game.

This leaves Html5/Canvas as the sole option.


By making this call, I knew that excanvas wouldn't be able to keep on par with the performance that I needed for the game. I basically had to accept the fact that I was telling IE users to get bent if they wanted to play the game.


I have no regrets.

So after doing a quick survey of the available libraries for writing simple games using Html5, I settled on JawsJs. It's a simple game development layer that is still early in development, but it was far enough along for me to make a half-decent game with it.

The projects that have been developed in JawsJS to date were considerably less complex than what TwitchTetris turned out to be, and I had to do a bit of creative rendering to make keep it running at the speeds I needed, but overall I think that JawsJS was the right direction for me.

As a whole, there are a lot of points where JawsJS could see some serious improvement, and if game development in Html5 starts to take the place of Flash, I hope that this library sees some serious development from the community.

So, then after weeks and weeks of development happening between lectures and labs at school, TwitchTetris is finally ready to be deployed. I'm using Google App Engine as a backend/hosting solution just because it's at the center of the cross-section of easy-to-use, and reliable.

My design theory was "no bullshit": meaning no ads which hinder the experience of the gamer and no extra "features" added on to the game to make it needlessly complex.

I came up with a "Teletype Console" theme for displaying the level and score information. The theme allowed me to create a relatively simple backdrop of green on dark green so that the action of the game really draws your attention with more dynamic colors. It also puts some movement into the side panels of the game display, so the game feels more dynamic.

So, head over to http://www.twitchtetris.com/, play a few games, try to set a high score, and let me know what you think!