The display name on iPhone is "Human Res...", which is really not good for me. Why not change it to HRM?
Looks like it works, great game! From the game dev perspective, any chance you can share a few details on what went wrong on the 6+ and 6S+?
Bugfix also fixes iphone 6. Now much much better on touch points, thanks a lot. Impressively quick bug fix
No way, a programming game that actually looks nice and gamey? I loved the presentation (but I'm not going to spoil the specific little things I enjoyed). Pretty addictive too, I completed everything except one final optimization challenge in one sitting yesterday evening. I would love to see an update that lets us make our own puzzles. It doesn't have to be very complicated. Just an open environment where we can somehow load or save sets of inputs and outputs, and make programs that work on them. I have one big point of criticism: This game is very openly about programming. The metaphors it employs are broken as soon as they get in the way of programming. IMHO this makes the game stop just short of being great. The implementation is stellar, but at the end of the day I can't call the puzzles innovative if they're just the same puzzles I've been solving for 20+ years. All of the puzzles were fun to solve, but because the solutions were very similar to solutions in other programming languages, satisfaction came mostly from being able to implement them on this limited machine, not from the process of discovering them. It almost seems like the game is slightly confused about its target audience. To elaborate, data is presented as little boxes that are being shuffled around by your human. But because this is about programming and not about boxes, pretty early on you will constantly see your human create and destroy them all the time. It's how programming works, but it's not really how humans and physical boxes work. For both of these reasons, the game is very intuitive to me as a software engineer. Meanwhile, my wife, who has no programming experience, keeps misreading what happens in game. For example, you can copy data to the floor, but she assumed that you could not copy it from there if you didn't have a box in your hands to put it in. So she tried to solve puzzles in a way that allows her to get a box from the inbox to put her data from the floor in before sending it to the outbox, and inevitably got stuck very early until I told her that that's not how it works after she gave up. But on the other hand, perhaps the challenge would have been more fun for someone like me with such added limitations, because that would make the puzzles different from normal programming and force me to experiment a bit more. As another example, it's weird that the human can do indirect addressing but can't simply walk in a given direction. Things that are very simple for real humans are harder for the game human than typical computer tasks that normally seem weird for real humans. You can implement going left and right by using one of the floor cells as a pointer. Now, in order to go right one step, your human has to run to a specific location on the floor, grab a note that reminds her of where she was last, increment the number on it by one, and walk to that location. This is not how real humans do this. But perhaps more importantly, with some programming experience, you don't have to learn anything at all to understand it. There are no new algorithms to discover that are based on the machine being a human who can walk around like a human and who stores data in boxes etc. Maybe one aspect of this is also that the commands aren't really adequately explained for someone with zero experience. This is not necessarily bad, all it means is that you need to experiment with the commands to figure out how they work. But the thing is, if you assume it works like any assembly language you've seen before, you're probably right. In other words, people most likely to enjoy the process of figuring out how a programming language works don't really get to experience it, because they don't need to go through it...
TomCorp, I just started playing this game. What a treat so far! I am intrigued to read about the second objectives in the game. There was a warning that many of the second objectives CANNOT be simultaneously achieved in a SINGLE solution. I presume, therefore, that there are such (however few) levels in which both objectives can be completed with a single solution. Can you share a list of those levels? This way, I can backtrack on those levels to re-investigate to see if I can discover a singular solution for each of these levels.
The majority of levels can be solved for speed and size at the same time. I only had different solutions for 11 puzzles, and after some googling I'm led to believe that for 6 out of those others have found better solutions than I have. If I didn't miss or misread anything, then at most 5 puzzles need separate solutions for speed and size (2, 19, 20, 28, and 38).
On #9, is it correct for it to treat the letter as a 0, and use the zero skip command? The solution I found uses 5 commands, but takes 28 steps, instead of 25, all because the letter is seen as a 0. I may need to return to that one later. --- I returned and figured it out. I'm loving the game.
I'm on stage 19... Wow. I take 10-20 minute breaks between each stage and just go set things on fire in little inferno for abit heehee. And yea the satisfaction of pulling a stage of, nothing compares. I'm not chasing optional goals yet, just clearing the stages. Will perfect the code once I've beaten the game. Thank you for bringing this to mobile! Ps; the last two titles had achievements, any chance of this one receiving the same treatment?
What a great game! I'm a programmer and found it a joy. My kids have a Kano, Robot Turtles, and that Minecraft programming thing, but I think this is a better introduction to coding than those. They've been watching over my shoulder and are champing at the bit for their turns. Soon enough...
I am not a programmer, so I am confused by the decision that the game is making on whether or not the program is "robust" enough to be deemed a valid solution. Here is an example. For level 2, to optimize the solution at Spoiler 25 steps, one needs to include Spoiler 2 sets of the inbox/outbox commands in a loop. However, one can further increase the number of the inbox/outbox commands in this same loop to get an even lower number of steps. But this depends on the exact number of boxes in the conveyor, thus it is situation-dependent solution and not a "robust" one that should be situation-independent. I understand the game "tests" a large number of situations to derive an "average". However, I can always include an absurd number of pairs of inbox/outbox commands to minimize this "average", and yet in many cases the program is clearly suboptimal because you are just wasting a number of commands. A more subtle and serious counterexample is in levels in which the "optimal" solution depends on, for example, that the second box in the conveyor, is also a 0. This way, one can include lead-in commands to handle only this specific situation and minimize some moves otherwise needed for a loop command. At first, I thought it was the task of the player to make this observation about some consistency between the test data sets, but I am not certain of this. This is particularly because one cannot scroll the conveyor to see all of the boxes, so I don't think it is the task of the player to make some general conclusion on some patterns about these boxes and use this to leverage to a better solution. Can someone explain this seemingly counter-factual requirements by the game between "optimization" and "robustness" that the game both demands?
When ever you get that robust enough fail on your code they mention offering you a example that would fail. Hit play and you'll run through the example that you would fail so you can see what their talking about.
Not sure what you mean. I don't think letters are zero. My solution for #9 has 5 commands and runs in 25 steps with no special treatment for letters.
Basically, you get to test your program on one set of inputs but to make sure that it is correct, the game tries it on a bunch of others. If it fails one of the other sets, you get an error and it'll actually let you test it on the set that it failed next. But there seems to be a limited number of input sets. It doesn't look like they're generated randomly, at least not totally randomly. The length is also limited, and some puzzles have other limits that you can find out and use for optimization (e.g. there are puzzles where all the inputs are numbers in a certain range that the game doesn't tell you outright, but you can of course find out by trial and error). Note that stuff on the floor never changes. So it's sort of valid to pre-process the floor in your brain if that helps with a challenge. (Mainly thinking of #32 here.) So in some cases the best speed will be achieved by a solution that is not universal but works for the inputs the game has for a given puzzle. Like I wrote, the best speed solutions aren't necessarily universal. In this case though I would argue that even a solution with exactly enough inbox/outbox commands in the loop for the challenge is "robust", because even though it will not achieve the optimal speed for larger sets than what the game offers, it will still generate the correct output. Since we can know how many inputs there are, we can remove the loop as well - this doesn't make the program faster, but it's shorter, so I would still call it better for the challenge, but I wouldn't call it "robust" anymore, because it will obviously fail for inputs the game doesn't provide. I would not call this "clearly suboptimal". It's only suboptimal for the challenge in the game. But not generally, because you can still get some amount of speed out of it for larger input sets that the game just doesn't test the program on. As a programmer, it's your job to decide how far you want to go. Just like in the real world, in this game I'd say a reasonable decision is optimizing for the input sets we're going to get. Loop unrolling is a really common optimization in the real world, so this is not something that only applies to the game. Here, we don't have access to some important tools, for example we can't make jump tables, which makes it harder to unroll loops with conditions. Otherwise we'd probably find some more ridiculous optimizations for some of the later puzzles. I'd say it's the player's task if the player wants to do this kind of optimization. The challenges certainly don't require it. But maybe you want to find out how to game the system because it keeps track of your best scores. I don't see anything wrong with that. It's basically an additional challenge. Even though you can't scroll the conveyor, you can experimentally find out what inputs the game has because it will keep giving you inputs for which your program doesn't work. I would just explain it with the limitations of testing correctness. Testing correctness is a hard problem, and this is a game, which also has to do it quickly because we don't want to wait. So the game assumes you're doing what you're told and for that, the test is good enough. That said, none of the speed challenges require knowledge of the possible inputs. It's just something you can do if you want. The speed targets are all very generous; we're never really required to find the optimal solution to get the green light. In some cases, my speed solution is just a fraction of the target without assuming anything about the inputs.
Hi, dannythefool, Thank you so much for your explanations. I have learned a lot just from reading your answers. It is very interesting to compare a player's take on the game depending whether or not the player has prior experience in programming languages. Your example of loop unrolling is a perfect one. To a programmer, this is a commonly known technique and is readily spotted to be a strategy to optimize the level's solution. If the player is not a programmer, however, the absence of this prior knowledge creates another barrier to overcome to complete this challenge. I just started playing this game, so I do not yet have a good grasp on what key programming concepts that this game will explore in later levels. I am a a bit worried that the game may not be giving enough clues or cues to the player to teach the player these concepts in a stepwise fashion to succeed in the later levels. For example, while bubble sort or insertion sort (I am not sure if these concepts are being explored in the game, but I am guessing that they may make for a good puzzle) may be known to any good programmer who will immediate leverage this knowledge to apply it to solve a level, a player with no prior knowledge of these computational sorting techniques will have little chance in ever succeeding in discovering the optimal solution for a level that is based on these concepts.
Dang it, another run to the market for iTunes. I watched a quick look on I think giant bomb, gameplay looks fantastic. Def buy this weekend. Cheers devs and players
I adored Little Inferno, so I bought this fast. Very good game, I'm enjoying it a lot! My only problem is with the default language. It's a nice touch to include hungarian, but I really would like to play this in english, can we change the language ingame?
Thanks for all the feedback so far! Re: Localization - We recommend you play in English if you can, if only because it's the original language we authored the game with. All translations were bravely written by community volunteers in their spare time, and we've heard that most languages are very well done! But since we're not proficient in any other language, we can't independently verify. On iOS the only way to change language currently is via your system setting.
