Wednesday, May 11, 2016

I Learned How to Write Code From Reality TV

If a code base is going to stay clean, readable, and maintainable, then the developers working on it need to actively put in effort to keep it that way every time they touch the code. My personal philosophy when writing new or working on existing code can be summed up by three reality TV personalities.

The first is to "Make It Work."


Get the code accomplishing the task that you need it to. Doing TDD? Write your unit tests, then dive into the code and get to work. Change code until those new unit tests pass. Hack away at it. Just get something together that does what it is supposed to do and fulfilling the requirement you are working on. Make it work!

Second, "Make it Right."


If you cut corners or used ugly code to get your feature working, now is the time to pay the piper. Start refactoring that code. Look for places that you duplicated logic, and find a way to make that code shared between both places. If you did TDD, you have your unit tests to catch any time you break the working functionality. If you didn't do TDD, add your unit tests now. Look objectively at your code: is it maintainable? Or did you try out a cool coding trick that in retrospect over-complicates the logic? Will other developers after you be able to understand it? Do you need to extract some methods so it's more clear how things are flowing? In short, make sure your code follows good coding practices and standards.

Third, "Don't **** it Up."


Run the full unit test suite to make sure you didn't break anything else or create unwanted side affects. If you refactored other parts of the code, run through those flows on your own and ensure they still work the way you expect. Be your brothers' and sisters' keeper, and ensure that what you did won't block their work. Make sure you test your edge cases, and add unit tests for them if you haven't already.

Thursday, March 27, 2014

Hack n' Slash demo

There's an article on Kotaku about the demo for a game called Hack n' Slash, in which you play as a character with a sword trying to solve puzzles and move through dungeons. The difference is that her sword is USB compatible, and objects and enemies within the game have USB ports that she can plug her sword in to and hack the variables of the game objects. I'm really excited about it, and it's scheduled to come out this summer.

I did see one thing in the video that I hope they change between now and release: the bomb item. Using a bomb on an object will let you access an object's code, which can allow you to turn a non-hackable object into a hackable one. The below clip starts with the explanation of the bombs, and then shows them in action.


The developer running the demo says "...but if we set this to true now these blocks are hackable. Now we come up here, we can use our hack sword even though these [blocks] don't have ports we modified their code so that you can bring up their hack menu." In the rest of the demo what denoted a hackable object versus a non-hackable object was the presence of a port, but the bomb creates hackable objects that don't have ports.

I think objects that get their isHackable function set to true via the bomb should have ports appear on them to give the player visual feedback that changing the isHackable function worked. If I had not watched this demo, I would not have known that the port-less rocks could now be hacked. Maybe I would have got lucky and struck one with my sword after changing the function, but it makes the game's mechanic unclear. It goes from "you can only hack objects with ports" to "well, sometimes you can hack objects that don't have ports, too" that may make future puzzles more frustrating to solve because the player is confused about the game's mechanics.

Maybe ports do not appear because the designers thought they would have to add a showPort function to objects that the player could modify, which could also create confusion by adding ports to otherwise unhackable objects. I think adding code that hides or shows an object's port based on the isHackable function, but not allowing the user to access the showPort function, would improve the usability. It may mean that not every function in the game is available for changing by the player, but it would make the game's mechanics less ambiguous and the game more fun.

Saturday, March 22, 2014

Oven lids

I found this post on Reddit about stoves. The post was about how someone discovered that he or she could lift the top of their stove like a car hood to more easily clean underneath the heating rings. The comments I read seem to fall into two general categories: either "Yeah, stoves do that. Of course that's how you would clean it," or "I've never seen that before, and mine does it, too!"

An electric stovetop with it's surface lifted and propped open like a car hood
Photo from the Reddit post showing the stove top lifted up
I fell into the second category. In my parents' home, we have a glass-top electric stove which does not lift up, since there's no way for anything to fall underneath the surface. Because of that, I never saw them clean a stove like this as I grew up. To me, there are no visible signs that stove tops like this can lift up in this way, and before seeing this picture I would be hesitant to even try: what if I disconnect the power or pull the oven off the wall? What if I damage it?

To make it more obvious that this functionality exists, I would put small handles along the outer lip of the stove top, either labeled 'To clean, pull up' or a diagram of the lifted stove top on them.

I do agree with many of the Reddit posters: now that I know this, cleaning my stove it much easier.

Thursday, January 16, 2014

AVGN's Top 10 Worst Game Controls

I am a fan of James Rolfe (creator of The Angry Video Game Nerd and the Cinemassacre videos) and recently he looked back on the terrible games he has played and put together a top 10 list of the games with the worst control schemes. (Warning: his AVGN videos contain extreme amounts of profanity)


His list is:
  1. Action 52
  2. Terminator 2
  3. Kid Kool 
  4. Toxic Crusaders
  5.  Spider-man: Return of the Sinister Six
  6.  Batman Forever
  7.  Legend of Zelda: Wand of Gamelon
  8.  Conan
  9.  Winter Games
  10.  Dark Castle
There were some common themes in his list:
  • Platforming games that have less intuitive/less forgiving controls than Super Mario Brothers, the gold standard of how a 2D platformer should control (Action 52, Kid Kool, Spiderman)
    • Many games did not allow you to steer yourself mid-jump, making it hard to land in a specific place or dodge enemies while jumping or falling.
  • Games that mapped commands to the controller buttons in an unintuitive way
    • Platforming games that reversed the A=Jump, B=Action control scheme from Super Mario Brothers.
    • Platforming games that make up on the control pad the jump action instead of another button on the controller (Conan even mapped jump to up and a long jump to down).
    • Toxic Crusaders made one of the attack buttons the Select button on the NES controller, which is far away on the controller from the game's jump button. Reaching for the Select button meant that sometime the Pause button gets hit, accidentally pausing the game mid-action.
    • In Wand of Gamelon, one button combination is both "open item menu" and "go through door" depending on where you stand on the screen. If you try to access your items near a door, you will instead go through the door.
    • In Dark Castle, down+B ducks but only for a second. To stay crouched, you have to hold up+B.
  • Overly complex controls/interactions
    • In Wand of Gamelon, you have to strike Rupees with the tip of your sword to pick them up instead of just touching them like in every other Zelda game.
    • In Dark Castle, you can throw a rock. However, to aim the rock you rotate the character's arm clockwise or counter-clockwise to throw in different directions.
His complaints fall directly in line with tenants of good interface design:
  • Controls for similar devices/situations should emulate each other, so the user can rely on past experience to gain mastery of a new device quickly
  • Controls should allow the user to excel at their desired action, not to hinder or prevent his/her desired action
  • Control schemes should take great care when overloading the same action to have different results depending on the context of the action
  • Controls should be as intuitive as possible
A game with bad controls can become a bad game at best and completely unplayable at worst. Games are no different than any other interactive problem - if the user cannot perform the actions he/she is attempting because the user's desires cannot be properly translated into actions, then he/she will either find something else that can or abandon the interaction all together.

Sunday, July 28, 2013

Arkham Horror Mythos cards

Last night I played a new-to-me board game, Arkham Horror. I had a good time, but the rules were some of the most complex for a board game I've ever played. Once we had gone around a few turns and stopped numerous times to consult the rulebook, we started to understand it and the game began to flow.

Eventually it was my turn to draw a Mythos card and share with the group how it impacted our characters and the game board. I began to read from the top of the card down when my wife stopped me. She said I was doing the tasks in the wrong order and showed me how I was supposed to interpret the card.

The card looked like this:


A Mythos card from Arkham Horror

I assumed that I would read the card top-to-bottom and perform the actions in that order: Headline, Clue, etc. However, my wife was right; the rulebook shows how you are supposed to read the card:

Selection from the Arkham Horror Rulebook explaining Mythos cards
I do not understand why the card is laid out this way. You have to read in this zig-zag pattern to play it right:


Same Mythos card but with lines showing what eye movements are necessary


For the rest of the game, every time I drew a Mythos card I wasn't 100% confident I was playing it right, just because the order of events I had to do made no sense with what the card looked like.

The cards would make more sense if they were laid out in order, like this:
A mockup of the card with the ordering of data changed, made with the Balsamiq mockup tool

Thursday, April 4, 2013

Norman doors in a church

I was standing by a set of doors a few days ago that were a bit unusual to me. After watching a few people interact with them, I realized I was staring at a set of Norman doors.

It was a set of double doors, and the door on the right had the typical flat metal panel associated with pushing doors open. On the left there was a small metal square with an open center.


These doors were in a church that was hosting a concert with groups from North Carolina, South Carolina, and Virginia, so very few people going in and out were familiar with this building. Five people went up to these doors and tried to push open the door on the left, which didn't budge, before moving to the right and pushing the right door open. To open the door on the left, you have to curve your hand like you are going to pick up a glass and hook it into the opening of the panel to pull the door open. So why did people in this building for the twenty minutes I was around go 0/5 at the left door?

Maybe it is because both doors have flat metal panels we associate with pushing. In the picture above, you can see a door against the wall through the glass that has a handle instead of the flat-front pulling fixture. I witnessed a few other doors leading to other rooms in the church also had those same handles. These people may have expected the same handle fixture on this door if they were supposed to pull it open. It also could be these people didn't know that the black part on the left door was actually a hole.

Another question I thought about was why did these five people push the door on the left first instead of the door on the right to begin with? The left door has a much larger window build into it - maybe they were using it to see that no one was on the other side before trying to push the left door open first.

The usability of these doors would be improved by replacing the fixture of the left door with a more traditional "pull" fixture like a vertical bar. I do wonder if the existing fixture is more common in other areas, just not in this part of the country and therefore gave these people trouble.

Sunday, March 10, 2013

Guild Wars 2: New guild mission options need better tooltips

Almost two weeks ago, a new gameplay element was added to Guild Wars 2 called guild missions. When I got home that night I fired up the game to see what the deal was. Since my guild had upgraded the Architecture category of bonuses for our guild the farthest, I checked that first and found new upgrades had been added to the bottom of the list including Guild Puzzle Unlock. I hovered over it and a tooltip explaining the upgrade and the requirements to build it appeared.

The Architecture category of a guild's Upgrades tab
Close-up of the tooltip for Guild Puzzle Unlock
The tooltip shows two icons, but no text to describe or identify them. I was pretty sure the first one with the green up-arrow meant I needed to upgrade the Architecture category to at least the next level. I had no idea what the second icon, the orange shield with a lock on it, was for - it was a symbol I had never seen in the game before. I started searching through all the options in the Upgrade tab and eventually found the upgrade with the matching icon in the Art of War category menu.

The Art of War category of a guild's Upgrades tab with Guild Chalenges Unlock highlighted
It's frustrating that I had to root through all the new upgrades in all the categories to find out that Guild Puzzle Unlock under Architecture has a prerequisite on Guild Challenges Unlock under Art of War. These are the first upgrades that have dependencies outside their own categories, so it was even harder as a user to figure out what the dependencies were. The more time I spent trying to find the upgrades with matching icons, the harder it was to remember what upgrade I was trying to learn about in the first place.

To improve the UI, more information should be in the tooltips. They should say what the icons stand for, and if the required upgrade is outside the currently selected category it should say which one the requirement is in.

Tooltip for Guild Puzzle Unlock with icon descriptions added
A player who recognizes the icons can quickly see the requirements for an upgrade and move on, while a non-expert player can spend more time reading the text to understand what requirements are needed. Adding text will also ease the mental burden of the player - they won't have to remember which upgrade they are learning about and what the icons of the dependencies look like to try to match them up by browsing the other categories.