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.

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!"

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.

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.