April 26th-29th 2013 :: Theme: Minimalism

Ludum Dare 26 — April 26-29th, 2013
[ Results: Top 100 Compo, Jam | Top 25 Categories | View My Entry ]
[ View All 2346 Games (Compo Only, Jam Only) | Warmup ]

[ LD26 Video Compilation (x3) | LD26 Supercut ]

IMPORTANT NOTE: If you want to place in the final results, you NEED votes. The easiest way to get votes is by rating other games. Judging lasts for 3 weeks following the end of Ludum Dare. For best effect, rate 20 games as soon as possible. Rating more games is encouraged.

MORE TIPS AND DETAILS AT THE BOTTOM OF THIS PAGE

Back to Browse Entries

Robopotato

by xyrix - 48 Hour Compo Entry

Downloads and Links


Ratings

#2059Coolness0%

Comments

xyrix says ...
Apr 30, 2013 @ 11:50am

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.

May 1, 2013 @ 7:07pm

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

xyrix says ...
May 1, 2013 @ 7:35pm

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.

Sylvain.p says ...
May 1, 2013 @ 9:05pm

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

May 7, 2013 @ 6:26am

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!

xyrix says ...
May 8, 2013 @ 11:34am

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 :-).

Suese says ...
May 14, 2013 @ 6:27am

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.

You must sign in to comment.


TEAMS: Teams entering the Jam should pick a single representative to submit your game, or create a team specific account you can share. We currently do not support Team Voting, but sharing an account and together playing and rating games is acceptable.

NOT LOGGED IN?: If you get a message about not being logged in, even though you are, it’s because your web browser cached the non-logged in page. You can fix this by either refreshing your cache or clearing your cache. CTRL+F5 in many browsers. Chrome is a bit more work. Press F12 to enable Developer Mode, then you can right click on the refresh button and select “Empty Cache and Hard Reload”. This option is unavailable if you are not in Developer Mode.

PORTS: Ports to other platforms can be done after the deadline. That said, the sooner you finish your port, the sooner people can play your game, improving your chances of placing in the final results. For best results, provide a Web version of your game, or a Windows version with no dependencies. Also be sure to rate about 20 games to improve your visibility.

MY GAME DOESN’T SHOW UP: If you can’t find your game, it’s usually because the URL to your downloads are missing ‘http://‘. Fix your URLs (http://mysite.com/mygame.zip) and you will show up.

MY GAME CRASHES, IS UNBEATABLE, OR I MADE A TYPO: We allow you to fix crash or win condition bugs after the deadline (in a sense, like “porting” to support more players). We also allow “typo” bugs. I.e. A true that should have been a false, a word that should have been a different word, very tiny changes that you would have caught if you had more sleep. We leave this open to interpretation, but generally speaking your game should be identical to the game you submitted. No new features, just things you messed up last minute. Typos.


[cache: storing page]