To anyone wanting to get something running quickly that they can mess around with - Open up an old game and the corresponding solution (perhaps filter through the solutions for one that is particularly long first). Then copy and paste the solution into the text box for the old game (minus the "Submitter: ..." line, so the first line is the INITIALSTATE line). Then press compile; then run; then play. Hopefully you will now see the robot grabbing some potatoes :-D!

As an aside, sometimes if you press "run" it will take a while - this is normal and the robot has most likely gotten into a loop. In this case, it waits until it runs out of moves (which I set waaay too high, having now tested things). But the important thing is you just have to wait a little - I don't think it will have crashed!

Anyway, enjoy.

Well I stuck with it for a while, it's certainly got more depth than I could wrap my head around though, I managed to write a script that picks all the potatos, though I did it by just putting all instructions into a single case's OTHERWISE and avoided anything that might trigger the case.

Honestly I feel the game asks more of me than I was prepared to give it, that might be remedied if you lost the 'scripting' part all together, do something icon based perhaps, with such a limited number of options to type it would be much faster to click what I wanted rather than type it, even with my cheesy/lazy approach I ended up copy/pasting most of my code :P

I feel if it was quicker to make changes in this way the game would feel a lot more 'alive' and I'd get to the meat of it which I imagine is in keeping the code short by using multiple states and cases. as it is everything seemed to pull the player as far back from what was going on as possible. perhaps it's a limitation of your tech but having to separately 'compile' then 'run' and then 'play' is probably something you want to avoid. just have it interpret instructions in real-time? it'd be cool to watch a playhead pass over the code you write too :)

anyway, certainly an impressive project for a weekend! props! :D

I did have most of these things in mind - alas, time proved to be a real issue (I had only scheduled a couple of hours for creating an interface, and didn't realise I'd given myself too much stuff to wrap my head around - animating the robot is what really ended out killing this project - I did not realise that I could not just launch a background animation thread naturally in JavaScript*. Unfortunately, the technical limitations on implementing the animation are what ate up my time and caused the compile, run and play to be separate functions - I'll be looking into libraries to abstract further away and make coding easier for future Ludum Dares).

The fact you can just put the entire solution into one state's otherwise clause is something I, somewhat embarrassingly, didn't anticipate at all when I was writing it. I finished bang on the deadline, and then on the first play tests went through the most epic facepalm moment ever XD! Unfortunately, even the brevity of code aspect isn't a good heuristic for determining what is a good solution, as the syntax is so cumbersome that just writing out a full solution is often the briefest solution.

The time barrier also made the level generation bad, too. I had an algorithm in mind to generate levels (i.e. generate random robots, and put them at the same place on a random grid, then analyse their paths and and put potatoes at extreme points of the best path there was - removing random squares that were never visited). This would have been easy to code if I had had an hour, but level generation is something I literally had to touch type straight in, try out, and then hope it worked (as I had about five minutes). Instead, I opted to just discard all puzzles for which no one gave a solution and hope that the "old games" list would eventually have some decent puzzles in it. Altogether, this didn't turn out as badly as I had anticipated :-).

Anyway, thanks a lot for playing the game and commenting :-). I hope you got something out of it XD. It's certainly taught me a good amount that I will be trying to use in my next LD ^_^.



*I actually used Brython, but it has the same limitations.

I think the web version doesn't work on mac (or maybe I haven't understand)

I really like this concept, no doubt. However, I had a hard time motivating myself to play it.

The reason is: your example solution to puzzle "apcxptadou" is 58 lines long. Those potatoes can all be gotten in 48 lines if you hard code the journey. It is probably possible to get the journey down below 48 lines, but not much. The overhead of each state makes the trade-off a very rough one. Maybe that is just one example, but I think it is probably telling (I solved two new puzzles, but each time found the hard coded solution shorter).

Think of a time when you have used "magic numbers" or string literals in your code. Why did you do it? Probably it was an extremely particular case, like the numbers zero, one, or two; or it was a value that you really knew wasn't going to change. Mostly it is a lazy decision, but it can also be a very cost efficient decision: if the value is only used in a few places and the overhead of generalizing it would be costly, this is a good decision.

In your game, the cost of generalizing a move is immense. Adding a new state costs at least 5 lines of overhead! Since the goal, beyond getting the potatoes, is to minimize lines of code I just can't see this going the way you want it to (read: the way I would want to play the game just isn't rewarded).

If the goal of your game had been to develop a program that could solve more than one maze, then we would need to generalize rather than hard-wire our solutions. Similarly, instead of "get all the potatoes" you could have made the goal "explore as many tiles as possible." Then measure the length of the solution against the quality of the exploration it produced, and you would have yourself a fascinating little game (I imagine).

Still, what you do have is really cool and impressive enough to deserve a good score. You also succeeded in really getting people talking: that's got to be worth bonus points!

Hey - thanks for the feedback!

Your suggestion regarding doing multiple mazes with the same robot is one I had considered - though the problem (with regards to the constraints of this competition) was generating puzzles. Unfortunately, the time I spent creating the GUI ate into my overall time to the extent I couldn't play test and make an actual game :-(!

I've learnt for next time, though - and hope to actually spend some time learning to create GUIs/animation so it won't eat into my time so much next LD :-).

The concept was interesting, a robot scripting game, but it was clunky and unpolished, not particularly fun in any way. The scripting language was a bit confusing, I couldn't get it to compile with the tutorial provided.