Hacked (phone game review)
I've been playing a programming-puzzle game on my phone called Hacked, and enjoying it a lot. It feels really good to be coding again, to be thinking algorithmically, to go "OK, how will I code this?" and then "Let's figure out exactly how it's not working and fix it." I hadn't realised how much I missed that. I've hardly coded anything since I left work nearly six years ago (apart from one time when we were doing the 2012 CiSRA puzzle hunt, there was one puzzle which we were failing to solve analytically and I decided it would yield to computational brute force, and wrote a 300-line C program to solve it).
In Hacked, you have a deliberately stripped-down language, and you have coding puzzles to solve in it, and the more you solve, the more language features you unlock. For example, in one early level you have to square integers, without a multiplication or exponentiation function; but once you've done that, you have access to those functions in later levels.
It reminds me of interview questions. (That's a good thing. I like technical interview questions; I just don't like the soft-skill ones. And at least here you don't have anyone watching you get it wrong.)
The review of Hacked currently displaying first on the Google Play store gives one star and says "So much lost potential It could be soooooooooo awesome but it fails because even though my code is right it won't accept it u less it's exactly the characters they want." I nearly let this put me off, but luckily I had the sense to check with Alex (who recommended me the game) and he said it wasn't his experience. And, indeed, I've found that it lets you solve the puzzle any way you want as long as it passes the tests (and Alex and I have had fun comparing notes afterwards and saying "Whoa, why would you do it that way? That seems really weird!") So the reviewer is just completely wrong. Maybe he thinks his code works and it doesn't.
(The game does have "hidden tests" in addition to the three examples it tells you about - so that you can't solve it by just hard-coding the three examples, you need to understand the general rule - but it is very explicit about telling you if you're failing the hidden tests, and you can spend coins (earned for solving previous puzzles, or actually paid for) to see what the hidden tests are - or make an educated guess. There was one level where you had to test whether an input number was prime. They give you the examples (3->true, 12->false, 17->true). My code passed those, but failed the hidden tests. So I thought about some possible edge cases, and double-checked it would succeed for 2 and for a square number, but then realised it was failing for 1. I didn't need to spend any coins.)
(Or maybe the reviewer meant the output has to be exactly the characters they want? In which case, yes, but then he's using a very... idiosyncratic meaning of "my code is right".)
It's quite a frustrating coding environment. You have a tiny screen, and you don't get to name your variables (you have to use the built-in var_a, var_b etc) and you can't add comments; so when re-reading your code to correct it, it's easy to lose track of which variables are which. And there's no debugger. You can always see the final output, so you can stick a temporary return var_a in somewhere if you want to see what var_a is. It's harder if you want to peek at something on, say, the fourth iteration through a while loop. You could bung in an extra variable, increment it, and go if var_b == 4 return var_a but I haven't resorted to that yet (partly because in the scoring for each level you're penalised for the number of edits you make!)
I'm not sure how I feel about these limitations. On one hand, they are frustrating. On the other hand, it's not real-world programming, it's a deliberately limited and gamified setup, where working round the limitations is part of the challenge (the integer-squaring level I mentioned would be pointless if you had a fully-featured language). I can't decide whether the difference between limitations of the language and limitations of the programming environment is relevant here (or even well-defined).
There are also some genuine bugs. It gives you a little on-screen keyboard containing all the tokens it thinks are valid at your current cursor position, and 99% of the time it's correct, but I was once trying to enter a closing bracket and it was complaining "Expected: )" at me while not letting me input one. Also, data types are a bit of a mess. The (brief) documentation explicitly says that characters are integers; and indeed you can compare them using > and <. But you can't pass them to the max and min functions (it complains "Integer expected") and you can't multiply them by -1.
Now I'm about half way through, it's getting more challenging to figure out what the requirements are. They don't give you a spec like "Return the input array with all the missing integers filled in from 0 to the largest number present", they give you three examples along the lines of "[2,4] -> [0,1,2,3,4]", plus a puzzle title which may be a blatant or subtle hint. In the early levels, it's very obvious what the rule is; but I'm currently stuck on a level where I've stared at the three examples and have no idea! This is also an enjoyable part of the game: it makes it like a rule-guessing game like Zendo or Penultima.
In Hacked, you have a deliberately stripped-down language, and you have coding puzzles to solve in it, and the more you solve, the more language features you unlock. For example, in one early level you have to square integers, without a multiplication or exponentiation function; but once you've done that, you have access to those functions in later levels.
It reminds me of interview questions. (That's a good thing. I like technical interview questions; I just don't like the soft-skill ones. And at least here you don't have anyone watching you get it wrong.)
The review of Hacked currently displaying first on the Google Play store gives one star and says "So much lost potential It could be soooooooooo awesome but it fails because even though my code is right it won't accept it u less it's exactly the characters they want." I nearly let this put me off, but luckily I had the sense to check with Alex (who recommended me the game) and he said it wasn't his experience. And, indeed, I've found that it lets you solve the puzzle any way you want as long as it passes the tests (and Alex and I have had fun comparing notes afterwards and saying "Whoa, why would you do it that way? That seems really weird!") So the reviewer is just completely wrong. Maybe he thinks his code works and it doesn't.
(The game does have "hidden tests" in addition to the three examples it tells you about - so that you can't solve it by just hard-coding the three examples, you need to understand the general rule - but it is very explicit about telling you if you're failing the hidden tests, and you can spend coins (earned for solving previous puzzles, or actually paid for) to see what the hidden tests are - or make an educated guess. There was one level where you had to test whether an input number was prime. They give you the examples (3->true, 12->false, 17->true). My code passed those, but failed the hidden tests. So I thought about some possible edge cases, and double-checked it would succeed for 2 and for a square number, but then realised it was failing for 1. I didn't need to spend any coins.)
(Or maybe the reviewer meant the output has to be exactly the characters they want? In which case, yes, but then he's using a very... idiosyncratic meaning of "my code is right".)
It's quite a frustrating coding environment. You have a tiny screen, and you don't get to name your variables (you have to use the built-in var_a, var_b etc) and you can't add comments; so when re-reading your code to correct it, it's easy to lose track of which variables are which. And there's no debugger. You can always see the final output, so you can stick a temporary return var_a in somewhere if you want to see what var_a is. It's harder if you want to peek at something on, say, the fourth iteration through a while loop. You could bung in an extra variable, increment it, and go if var_b == 4 return var_a but I haven't resorted to that yet (partly because in the scoring for each level you're penalised for the number of edits you make!)
I'm not sure how I feel about these limitations. On one hand, they are frustrating. On the other hand, it's not real-world programming, it's a deliberately limited and gamified setup, where working round the limitations is part of the challenge (the integer-squaring level I mentioned would be pointless if you had a fully-featured language). I can't decide whether the difference between limitations of the language and limitations of the programming environment is relevant here (or even well-defined).
There are also some genuine bugs. It gives you a little on-screen keyboard containing all the tokens it thinks are valid at your current cursor position, and 99% of the time it's correct, but I was once trying to enter a closing bracket and it was complaining "Expected: )" at me while not letting me input one. Also, data types are a bit of a mess. The (brief) documentation explicitly says that characters are integers; and indeed you can compare them using > and <. But you can't pass them to the max and min functions (it complains "Integer expected") and you can't multiply them by -1.
Now I'm about half way through, it's getting more challenging to figure out what the requirements are. They don't give you a spec like "Return the input array with all the missing integers filled in from 0 to the largest number present", they give you three examples along the lines of "[2,4] -> [0,1,2,3,4]", plus a puzzle title which may be a blatant or subtle hint. In the early levels, it's very obvious what the rule is; but I'm currently stuck on a level where I've stared at the three examples and have no idea! This is also an enjoyable part of the game: it makes it like a rule-guessing game like Zendo or Penultima.