LBPCentral Archive

Home

LBP Showcase / Reviews / Recommendations

Level Showcase

Sackbot Programming Puzzles

Archive: 19 posts

I had an idea last week and spent the weekend working on it as much as I could and got a 95% complete level. It's playable, but needs a little more narration/instruction, and I think I need to do a test run through the whole thing once to make sure everything is still in working order. It just takes a lot of time to create levels. I did a lot of learning creating this, my first complete LBP2 level (I did LBP1 levels in the past). I'd appreciate any comments that others might have before I publish the 1.0 version (assuming I can find the time for it... I guess a weekend is a relatively *short* time for creating levels, but I'm a programmer myself so I can learn quickly... and it's a relatively short level, but does have some interesting features to make it worth playing, I hope).

Anyway, this level is about programming sackbots to achieve specified tasks. There's a programming interface where you use L1/R1 to select a cell, the left stick to select a command, and X to write the selected command to the program cell. Then you run the program with R2. The instructions are in the level too of course. The one thing I am puzzled by is something I just read in the FAQ. I went to a lot of work figuring out how to make movie cameras work the way I wanted to show a specified area for an unlimited time (finally figured it out), but then I read on the FAQ that you can use a game camera to follow a sackbot? When I tried to use a game camera to look at a particular area of the map, it seemed to not be very responsive and/or insist on keeping the player in the frame even with 0% follow. So I ended up using my movie camera tricks instead. Did I miss something? Does a game camera behave differently when attached to a sackbot?

Anyway, if anyone sees anything interesting in this level, I look forward to discussing it. I hope *someone* will play.
http://lbp.me/v/y63vw3

2011-03-21 12:28:00

Author:
Unknown User

The concept definitely sounds interesting. Queued.

Please provide feedback on my level in my signature.

There is a robot at the beginning of the level that says some stuff in an once only type of way. It can actually step on you and kill you which means that the player can miss some information. Since it's probably not supposed to be a trap, a hazard, or an obstacle, you should probably find some other way of letting it move around.

The first mini-level/puzzle is significantly harder than the second one. I would make the second one first.

In the first level, the vase of flowers is not glued down and can be knocked over by the sackbot running on top of it. Not sure if this is intentional, but it seems like a fairly significant challenge for a first puzzle.

The programming interface is pretty slick. It would be better if the tool selection had the same kind of grid-based selector as the command queue. Also, it would be somewhat more intuitive if the command queue selector advanced a grid block after a command is set. One other thing that I found myself doing was pressing R1 to get to the end of my list of commands after every run. It would be better not to reset the command queue selector back to the start after a run.

It's possible that I missed this information, but in the second and third puzzles, there is a speech bubble and a controlinator and both are activated by the triangle button. The speech bubble has priority even though it's farther away and the only way to enter the controlinator is to do so while the speech bubble is opened up. It would be better if the speech bubble required that something be grabbed so that it doesn't interfere with entering the controlinator.

The last thing with the interface is minor, but it would be good to allow each puzzle to have its own command queue since there is no benefit to retaining the commands (in this particular level) and it's work to have to delete all the commands when starting another puzzle.

Aesthetics-wise, the level looks pretty good. The only thing I would suggest is to try to avoid using the default floor since most players have been conditioned to associate it with unfinished levels and falling through broken parts of levels into unplanned territory.

2011-03-21 14:36:00

Author:
Unknown User

I added the scientist kind of hastily at the end, so it's not surprising he has a couple problems. I'm kind of confused about the mouths -- I thought you could chain them together to activate them in sequence, but that didn't work, so I had to do some screwy microchip to activate them in sequence. You should be able to get the message again by leaving and re-entering his proximity, but ideally I wish you could just press triangle and get all 3 messages in sequence. Did I miss something -- is it supposed to be easy to chain mouths together. I ask because I later tried to use a mouth and couldn't get it to activate at all, so putting the mouths on a sequencer or microchip may have permanently altered the mouth's mode of operation, and maybe it would work better if I start over.

Rather than swap the first and second level, do you think it would be just as good if I found a way to alter the first level to make it easier? (Should I also alter the second one to make it harder?) The style of the levels kind of follows a progression and story, so I want to keep the same style, but I could certainly make small alterations to make them easier or harder.

My decision not to glue the plan down was actually intentional -- I find that levels without everything firmly glued into place are more natural and entertaining, allowing for a little more play and exploration. When everything is so firmly set in a predefined manner you don't get any variety or natural experience like you would in reality. However, it was not my intention that the plant interfere with reaching the goal, so I will try to make sure that when I make the level easier, the plant doesn't interfere too much.

Thanks for the suggestion about a grid based command selector. Hopefully I can find a good way to implement it -- I do tend to have trouble selecting the desired command occasionally. Also thanks for reminding my about the auto-advance on the program selector. I think that thought occurred to me but never bugged me enough to actually do something about it. That would feel more natural, though. Hopefully it's as easy as I think it will be.

However, leaving the selector at the end after each program run will be more difficult because the selector is actually what is moving when the program runs too. Hopefully that's not too big a pain to have it reset if I implement the other improvements. I would either need to save and restore the position, which would not be easy with a 21-way selector chip, or I would need to have a separate set of tags (tags are used to draw the highlight to a cell) and program runner independent of the program writer.

Would it be just as good to clear the command queue when a puzzle is successfully solved rather than having separate command queues? (BTW, are you aware that you can overwrite commands? Is that important information?) I'm not clear what all the implications of duplicating the command queue might be, but I suppose I could try it. It is quite complex. However, I think I did avoid running any external wires to it, so at least I've got that going for me... unless many of the internal wires get lost when I duplicate it like they did when I duplicated the controlinator in the sackbot's behavior circuit.

I was going to avoid using the default floor, and then I thought, bah, why do I always bother... the default floor looks fine? Now I see the reason, though, if indeed it's a sign of lack of effort.

Thanks for your comments. I've added your level to my queue, and will get back to you after next time I play LBP2.

2011-03-22 00:10:00

Author:
Unknown User

IIRC if you put mouths in a sequencer that doesn't get reset and doesn't loop, it's a once only deal.

The order of the puzzles is fine aside from the level of difficulty. One of the things that makes things complicated in the first puzzle is the fact that it seems necessary to use a lot of run left or right commands and the amount of distance covered depends on whether it was in the air, whether it was running before the run command, and what the terrain is like. I had to use a lot of trial and error to get the right combination of run left, run right, and no-ops to position the sackbot in the first puzzle- much more than I had to do in the second.

I think you can record the position with another 21 value selector and connect all the outputs of the first selector into the inputs of the second selector. Route that circuitry through a chip that you can deactivate when you're in execution mode and you should have a way of saving the first selector's original value. Restoring the value is more work since you will probably have to stick in an additional OR gate for each of the 21 inputs to your original 21 value selector.

A command to clear the command queue would probably be just as good. A possible use case for having multiple command queues would be to allow players to go back to an old puzzle and watch each of their earlier completed solutions. It's got to be balanced against thermometer concerns, though.

2011-03-22 03:55:00

Author:
Unknown User

i queue your level i wil write a in game review

can you check my level in my sig?

2011-03-22 04:15:00

Author:
KRX

Posts: 110

As requested, F4F from my level.

Firstly, you are trying (and pretty much succeeding) to do something very different in LBP. Nice one. The concept of what you have to do is very clear. A few pointers:

The professor can sometimes get in the way so you can't get in a controllinator. Instead his speech bubble keeps popping up. Maybe make the professor a big sackbot to make him look more LBP2? He'd have more ability that way to act along when you complete tasks etc.

I like the use of the programming 'code' logic - very original. Maybe for less programmy types consider a puzzle at the start that solves itself. If you can make the professor solve an intro room for you then it would firstly offer a demo of what to do and secondly be pretty sweet logicwise.

I echo the thoughts above where there is no gain in keeping the programming 'code' between puzzles. I also agree that the second puzzle is easier.

Cool stuff though!

2011-03-22 20:30:00

Author:
faulky

Posts: 80

IIRC if you put mouths in a sequencer that doesn't get reset and doesn't loop, it's a once only deal.
I found that the mouths don't seem to behave very consistently in create mode, but I removed all the complexity and just linked the mouths together in a circuit board, and they work fine now. I think the trick was to set the last 2 mouths to be 1-shot triggering instead of power-on. I haven't re-published yet, but I think that problem is taken care of.

The order of the puzzles is fine aside from the level of difficulty. One of the things that makes things complicated in the first puzzle is the fact that it seems necessary to use a lot of run left or right commands and the amount of distance covered depends on whether it was in the air, whether it was running before the run command, and what the terrain is like. I had to use a lot of trial and error to get the right combination of run left, run right, and no-ops to position the sackbot in the first puzzle- much more than I had to do in the second.

Yeah, it's strange, when I went back to play this latest round, I found the first level more difficult than I recall. It must be partly luck of the draw in selecting the right first attempt. Maybe I should make the table longer and/or closer to the shelf... that would probably make it much easier. I do still have one open command slot. Maybe I should use that for a jump straight up command.

I think you can record the position with another 21 value selector and connect all the outputs of the first selector into the inputs of the second selector. Route that circuitry through a chip that you can deactivate when you're in execution mode and you should have a way of saving the first selector's original value. Restoring the value is more work since you will probably have to stick in an additional OR gate for each of the 21 inputs to your original 21 value selector.

Yeah, I'm sure I could figure out a way of doing it, but I was hoping not to have to create another chip with 21 of anything.

I'll probably focus a little more on aesthetics first. I feel like some people are judging this book by it's cover, so I need to spice it up a bit and get a better starting point and background... maybe some music.

A command to clear the command queue would probably be just as good. A possible use case for having multiple command queues would be to allow players to go back to an old puzzle and watch each of their earlier completed solutions. It's got to be balanced against thermometer concerns, though.

Yeah the thermometer's halfway up already. How can a small level like this put the thermometer so far up when there are levels with so much more? Is it because the thermometer is more affected by the level of variation, (which goes up sharply when you start and not as much later), than how much content there is? If that's the case, then cloning the command queue probably wouldn't add too much... I'll have to give it a try just to see. But I won't do it for real until I'm sure the command queue I have is working the way I want. I don't want to have to fix everything thrice!

2011-03-23 02:52:00

Author:
Unknown User

i queue your level i wil write a in game review

can you check my level in my sig?

I will also respond to yours with an in-game review. (It's added to my queue.)

2011-03-23 02:54:00

Author:
Unknown User

Firstly, you are trying (and pretty much succeeding) to do something very different in LBP. Nice one. The concept of what you have to do is very clear.

I actually had and implemented a similar idea in LBP1 (where I had a level called robot programming puzzles), but somehow that level was not compatible with LBP2. The keys that got emitted when solving the puzzles in the LBP1 version were missing tags or something, and it relied on stickers that you can't get in LBP2. So I marked that one as LBP1-only. I've seen a similar problem at other times when working in LBP2. Tags or something were lost after putting objects into emitters. Fortunately, I haven't seen any more of that lately. Also, fortunately, LBP2 allowed me to do a much better implementation of my idea.

The professor can sometimes get in the way so you can't get in a controllinator. Instead his speech bubble keeps popping up. Maybe make the professor a big sackbot to make him look more LBP2? He'd have more ability that way to act along when you complete tasks etc.

I moved the professor so he doesn't interfere. I'm still stuck in the mindset that not all non-player characters should be sackbots -- feels like cheating -- it's too easy

... and sackbots are all the same general shape, which is somewhat limiting. I did change him though and removed his annoying hopping. (Still haven't re-publiched yet, though.)

I like the use of the programming 'code' logic - very original. Maybe for less programmy types consider a puzzle at the start that solves itself. If you can make the professor solve an intro room for you then it would firstly offer a demo of what to do and secondly be pretty sweet logicwise.

Wow, that sounds difficult. Is that what you mean by "pretty sweet logicwise"?

I echo the thoughts above where there is no gain in keeping the programming 'code' between puzzles. I also agree that the second puzzle is easier.

Thanks for your thoughts. I'm off to reply to the F4F levels that have had replies here, so look for another reply in your thread.

2011-03-23 03:05:00

Author:
Unknown User

I love the idea. Queued and I will check it soon.

2011-03-23 08:19:00

Author:
Agarwel

Posts: 207

Wow, that sounds difficult. Is that what you mean by "pretty sweet logicwise"?

I'm sure it will be difficult. Maybe a sequencer will help you to get the Professor to 'solve' the demo puzzle for you?

And yes, I meant the logic behind a demo would be pretty interesting to make.

2011-03-23 10:44:00

Author:
faulky

Posts: 80

Ok. It is nice. But because of the word "Programming", I expected something little more complex :-D This is nice puzzle with crerating lists of commands. But still has big fun potential.
I would just suggest to change the layout so player can see comands + the room at the same time. (for example "writing" the program on the upper part of the room).

And a idea for your next project. Did you ever hear about programing language "Karel"? Especially in its simplified Czech version? It works like this:
1 - You have a top-down grid field (does not need to be big)
2 - There is a "robot" in one corner.
3 - Player can modify the grid by placing two objects "Walls" (not accesible squares) and "Marks" (in the more advanced vrsion there can be 1..9 marks placed on one square)

Now the player can program the robot using four simple commands:
1 - Step = Robot will move one square forward in a way it is facing (if that fiesld do not contain Wall or end of the grid)
2 - Turn left = The robot will change the direction
3 - Place mark = he will place (or add) one Mark on the field it is standing
4 - Take mark = it will remov eone mark from the field it is curently standing

And then player can use two version of condition. (standart IF statement).
1 - IF there is a wall before robot THEN... ENDIF
2 - IF amount of the marks on current field = x THEN... ENDIF

And of course you can create procedures. Like "Define TurnRight AS turnleft, turnleft, turnleft, end"

This one is used t oteach kids masic programming techniques. It has easy basics, but can be really powerfull too (I was playing with it for a while and managed to create pathfinding algoritm, so the Robot always find the way throught maze created from walls)

And I must admit - I would love to see some similar project in the LBP2 :-)
So its just a idea for your future projects :-D
http://en.wikipedia.org/wiki/Karel_%28programming_language%29

2011-03-23 12:06:00

Author:
Agarwel

Posts: 207

2011-03-23 15:22:00

Author:
Kanada Ten

Posts: 87

^ This ^ It has a lot of potential, but right now it feels like a tech demo. Please keep working on it!

[EDIT]
This is from a similar type level, maybe it'll give you some inspiration...
(Snip)

How do I find that level?

2011-03-24 12:30:00

Author:
Unknown User

Oops, should have made it clear that I linked the picture to the level. But here's a link for this post to: Programmable Sackbots Puzzle (1 Player. Hard!) (http://lbp.me/v/y581n6)

Having played a few of his puzzles, your challenges are actually pretty different from his. It did reinforce some nitpicks I had about your interface, though. That cursor you use for choosing the various commands is clumsy - and really unnecessary since your dragging it over each one anyway.

2011-03-24 13:34:00

Author:
Kanada Ten

Posts: 87

I tried clicking on the picture, but it didn't take me to the level, just another view of the picture. So I'm glad you posted the link.

I have significantly improved the cursor, but not republished yet. I don't know exactly what you mean by "dragging it over each one anyway" -- why "anyway"? Perhaps playing this other level will give me a clue. Anyway, in my updated version the command selection cursor is grid based like the program queue cursor. But I'm waiting to re-publish until I have made all the corrections I have in mind, since the number after 0.9 is 1.0, and I don't wans to start using "0.91" etc

.

BTW, any comments on the advisability of including a version number in the level's title? When I release the finished version, should I include or exclude "v1.0"?

2011-03-25 12:17:00

Author:
Unknown User

BTW, any comments on the advisability of including a version number in the level's title? When I release the finished version, should I include or exclude "v1.0"?

I went with a beta tag until released. Version in description at the end with latest update. When publishing the 'final' one I locked the beta level and started fresh with a new one as a few sad faces were put on along the way due to bugs. I want the happy/sad faces to reflect the final level, not all the testing stuff as well.

2011-03-25 12:23:00

Author:
faulky

Posts: 80

I don't know exactly what you mean by "dragging it over each one anyway" -- why "anyway"? Perhaps playing this other level will give me a clue. Anyway, in my updated version the command selection cursor is grid based like the program queue cursor. But I'm waiting to re-publish until I have made all the corrections I have in mind, since the number after 0.9 is 1.0, and I don't wans to start using "0.91" etc

.
I think that's exactly what I mean.

The only advantage of a point and click system is that you can move in a straight line between points A and Z (rather than cycling through or highlighting each icon), but when all your points are in a line, there's no advantage, only the disadvantage of a cursor, which is inaccuracy of the pointer. So, that's the anyway.

2011-03-25 17:46:00

Author:
Kanada Ten

Posts: 87

I've re-published the level, but it seems to have caused the link to the level to be lost for this thread, so I guess I'll start a new one.

Edit: Link to the level is back in order now. Don't know what was going on earlier this morning.

2011-03-28 12:14:00

Author:
Unknown User

LBPCentral Archive Statistics

Posts: 1077139 Threads: 69970 Members: 9661 Archive-Date: 2019-01-19

Datenschutz

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.