Foon → Ludum Dare Explorer → Users → xyrix
| Year | LD | Theme | Game | Division | Rank | Co | |
|---|---|---|---|---|---|---|---|
| 2013 | 28 | You Only Get One | Gauntlet | compo | 24 | ||
| 2013 | 26 | Minimalism | Robopotato | compo |
I may be wrong, but on an odd by odd board, if I am the first player and I play the centre square, then mirror my opponent's move (rotational symmetry), don't I always win? And if either of the sides has an even number of sqaures along it, can the second player not mirror her opponent's moves (reflectional across the centre) and always win?
I'm sure you've already thought of this, I just can't immediately see why that doesn't work.
@CrazyGage - I was originally intending to play symmetry against you, but I miscounted the squares. I played a lot of symmetry against you, but not the perfect strategy as it were, and I noticed a useful trick - i.e. if there are an even number of moves left from your position you should play moves to leave empty squares isolated in pairs. When your opponent then plays in one of the two in a pair, you take the other - this guarantees an equal exchange in the worst case but gains you points most often.
To be honest, I was playing on a crappy laptop, and I kept misclicking with the mouse on it, which didn't much help :-P. Playing second in the game just happened to be a huge advantage.
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.
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.
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 :-).
I like the mechanic - this being Ludum Dare I'm absolutely prepared to play lots of half-baked platformers, so playing one that stands out in gameplay is a treat :-).
The mechanic fits the theme perfectly, but works out as being pretty frustrating. If you get a decent item (e.g. the watch) then you kind of want to save it for a later level - which sucks 'cause the items are the most interesting point.
Also, as a general point, the enemy's instakill method is, in my opinion, really harsh on the player. Personally, I prefer to err on the side of being generous to the player as that makes for fewer frustrating deaths.
Still, a I enjoyed it :-).
I really like the graphical style of this, and dig this kind of gameplay. That said, I have stopped playing before completing this because every time I die I have to press three buttons just to try again (and I'm dying a lot). Which is a shame - in my opinion, if you polish the respawn on death you achieve a lot for your game (e.g. Super Hexagon, VVVVVV). Also, the instant game over message on death is very jarring - a small delay and a death animation would go a long way.
I got 124. That's enough clicking for me, I think :-).