Home    LittleBigPlanet 2 - 3 - Vita - Karting    LittleBigPlanet 2    [LBP2] Suggestions
#1

Little Big Script

Archive: 52 posts

The logic in LBP2 is amazing, it lets us do incredible things. Alas however, some things require a unbelievable level of complexity.

That is why computers use user friendly code to be programed. It lets us do things without having to work out all the logic. So pose I want to use 4 switches to control a set of lights.

If any ONE switch is ON the light is green.
If any TWO t is red.

now for one its easy, use a XOR gate with 4 inputs.

but for any 2, but only 2?
this can be done, and it is not even the most difficult thing to do. but it is a order of magnitude harder than just 1 switch on.


OR I could say:


//"var1-4" are variables
Get input(switch1)=var1; //gets the input coming from switch1, a number between -100 and 100
Get input(switch2)=var2;
Get input(switch3)=var3;
Get input(switch4)=var4;

arithmetic(var1+va2+var3+var4)=TotalInput; //adds all the inputs together, all ons are worth 100, offs are 0. this allows for analog handling.

IF(TotalInput==100) THEN //if the total is 100 then one switch is on
Give output(100,green_light); //send a full on to green
Give output(0,red_light); //send full off to red
ElSE IF(TotalInput==200) THEN
Give output(0,green_light);
Give output(100,red_light);
ELSE //if its isn't 100, or 200 then both lights should be off
Give output(0,green_light);
Give output(0,red_light);

This handles it all, and I could easily add another color for 3 switches or add 20 more colors and 100 more switches. Now in implementation you would add a "code block" to your circuit board, it would open up and you could place things like ifs and loops, and such on it. rather than typing it all out.


http://getsatisfaction.com/littlebigplanet/topics/little_big_script		2011-02-14 22:50:00

Author:
zeel
Posts: 61

Hmm. Being a hobbyist programmer myself, I can see how this would be really useful - but the problem is that the scripting language would have to be specific to LBP2's logic. I mean, I don't think Mm could just give us a C++ editor in LBP2 and let us go wild, so it would probably require a lot of work, for a very small section of the overall LBP2 community. Let's face it; a full blown code editor hardly fits into Mm's "anyone can create" philosophy.

A nice idea, but probably wouldn't be used by nearly enough people to justify implementing.		2011-02-14 23:07:00

Author:
alexbull_uk
Posts: 1287

something basic. its only inputs and outputs are -100--100 values, directly to components. it dose not need much fancy stuff. and by encapsulating elements like "If" and "for" in specialized blocks, it would be very user friendly.

Take a look at Alice (http://www.alice.org/)

Alice is an innovative 3D programming environment that makes it easy to create an animation for telling a story, playing an interactive game, or a video to share on the web. Alice is a teaching tool for introductory computing. It uses 3D graphics and a drag-and-drop interface to facilitate a more engaging, less frustrating first programming experience.

http://upload.wikimedia.org/wikipedia/commons/5/57/Alice-2-screenshot.jpg


something similar. at least in form, if not over all function.		2011-02-14 23:13:00

Author:
zeel
Posts: 61

I'd like it better if it was Lua.


If input = "1"
Then light3 = "On"
But
If input = "2"
Then light3 = "Off"

I just summed up what you said 200% simpler.		2011-02-15 04:25:00

Author:
kodymcq
Posts: 281

Well i don't know what to thing about it, logic do the great job and imo it's more understable for the people, also 2 systems would make people confused. I would not expect from MM to implement this.

Oh and that getstisfaction page is only about LBP.me service

AS we on that topic you might be interested to watch this: http://www.bafta.org/access-all-areas/videos/media-molecule,1383,BA.html


I'd like it better if it was Lua.

Plz god not that, i hate LUA . I would prefer Perl more. And keep in mind that we on the console, so text editor coding have 0% chance of implementing		2011-02-15 04:36:00

Author:
Shadowriver
Posts: 3991

you are incorect. it is about all of LBP (LBP 1, 2 as well as LBP.me) the specific suggestion is for LBP2, and is properly posted as such.

For some tasks this is far simpler than logic. It is really not a hard concept to grasp, a short tutorial should have people scripting in no time.


@ kodymcq
that would not do the same thing. at least not in those 5 lines.		2011-02-15 05:20:00

Author:
zeel
Posts: 61

Oh they changes name and description, then it's ok.2011-02-15 15:35:00

Author:
Shadowriver
Posts: 3991

The logic system is essentially a visual scripting language. And that's as deep as it would get.2011-02-15 18:15:00

Author:
Foofles
Posts: 2278

yeah, no. i know this would allow you to use your "special" skills, but its completely contrary to the concept of lbp as a whole.2011-02-15 18:27:00

Author:
Deftmute
Posts: 730

The logic system is essentially a visual scripting language. And that's as deep as it would get.

^^ This

While there definitely have been times where I'd love to see basic scripting inside of LBP2, I think that if we had it, we'd probably lose a good portion of the creating community and a lot of innovative levels would never exist. The node-graph logic system we have is actually pretty sophisticated and I think we'll see mm expand the range of options on the nodes we do have currently...maybe even add some new ones.		2011-02-15 18:32:00

Author:
Chazprime
Posts: 587

The logic system is essentially a visual scripting language. And that's as deep as it would get.

Yea and not to mention it's lowest programing language possible, CPU is made based on logic circutry. First thing that teachers teach you about digital electronics is bool algebra and logic gates.

Imo LBP logic circuitry is more like automatize control circuitry on same basis as production robots are made, output and inputs are ready devices		2011-02-15 18:35:00

Author:
Shadowriver
Posts: 3991

The logic system is essentially a visual scripting language. And that's as deep as it would get.

Somewhat... A notable (and somewhat subtle?) difference is that it's not strictly sequential. It actually takes extra work to create something that responds differently depending on some notion of "current state". The simplest behaviors are those that always work the same. A typical procedural programming language is the exact opposite: barring multi-threading there's always one specific point in the code which is the point being currently evaluated, and it takes extra work (busy-loops scanning for important input, or something like select() or interrupts) to make the sequential code behave like asynchronous logic. Handing these problems via threading is legendary for its difficulty and synchronization issues. Handling these issues without threading is merely very difficult.

I think LBP2's system of logic gates is pretty fascinating as programming experiences go, honestly. Dealing with real-time inputs correctly is kind of a challenge in sequential programming languages. LBP2 logic lends itself very well to simple stuff and scales nicely. After doing a couple elaborate logic machines in LBP1 (Conway Life, and a control system for a tank) - working in LBP2 is like having a ball-and-chain removed from my leg.

Oh, and "True if exactly two of (A, B, C, D) are true"? Easy:
((A & XOR(B, C, D)) | (XOR(A,B) & XOR(C, D) | (XOR(A,B,C) & D)). Of course you add another clause for each additional input...

If it were "True if exactly three" (out of five) the easiest way would be to use the "true if exactly two" logic and invert the inputs. ("True if exactly two are off" -> "true if exactly 5-2 are on")

Calculating "exactly n out of m" gets more complicated as (max(n, m-n)) rises. The way you tackle a problem like that is express each successively more complicated version in terms of the simpler ones.

f(1, xs) = xor(xs)
f(n, x:xs) = ((x & f(n-1, xs)) | (!x & f(n, xs)))
(Second line: "There are exactly (n) true values in the list (x:xs) if (x) is true and there are exactly (n-1) true values in the remainder of the list (xs) - or if (x) is false and there are exactly (n) true values in the remainder of the list(xs))

Basically, that's the same pattern I used to create "exactly two of four" from "exactly one of four" - you can apply that pattern repeatedly to get whatever combination of desired count and number of inputs that you need. Applying this pattern does result in creating some redundant logic that could be optimized out (for instance, you would have multiple XOR gates covering any given set of nodes) - but it's a lot easier to build the counter if you just build the logic circuit by repeating that rule as many times as necessary.

That said, it would be nice if they just provided a "count the inputs" device. I think that's probably the main limitation of LBP2 logic - they're just missing a few pieces that would make a few specific things a lot easier. Hopefully they'll add more logic devices in future updates to the game.

As for scripting - I think personally what I'd want to see, what I think would fit best with the overall design of LBP (whether it's textual source code or new graphical logic bits), would be something in the vein of Erlang, operating by sending "messages" from one logic system to another - or a state machine operating on (and emitting) a stream of "signals" to which the logic responds... That would be a bit outside the current system of signals and gates due to the discretization of individual messages on a line..		2011-02-15 18:46:00

Author:
tetsujin
Posts: 187

you said it yourself zeel, it is possible with the logic we have already, so why implement something that most people wont ever go near?
remember that LBP is at its heart a game aimed at kids (+7 rating in UK) so adding tools in that require vast knowledge of programming is not gonna give back to Mm as much as they have to put in to implement it		2011-02-15 18:54:00

Author:
Skalio-
Posts: 920

Oh, and "True if exactly two of (A, B, C, D) are true"? Easy:

.... [lots and lots of logic] ....

Calculating "exactly n out of m" gets more complicated as (max(n, m-n)) rises. The way you tackle a problem like that is express each successively more complicated version in terms of the simpler ones.

The best way to tackle a problem like this is to use a tool that is well suited to the job.



count = 0;
for(i=0 ; i<totalInputs ; i++)
{
if(input[i])
count++;

output[i] = 0;
}

output[count] = 1;
return;


So... I can script that in roughly 15 seconds*... what percentage of the logic do you think you could place in that time The scripted version, if implemented well, would be far more efficient too, because of the other points you raised about the logic simulation being a nightmare to synchronise in an essentially sequential programmatic way (which is the reality of what is happening behind the scenes). You've just highlighted a the perfect example of a place where a scripting language would be undeniably preferable.


As for scripting - I think personally what I'd want to see, what I think would fit best with the overall design of LBP (whether it's textual source code or new graphical logic bits), would be something in the vein of Erlang, operating by sending "messages" from one logic system to another - or a state machine operating on (and emitting) a stream of "signals" to which the logic responds... That would be a bit outside the current system of signals and gates due to the discretization of individual messages on a line..

I posted an overview of a simple scripted concept that would logically extend a microchip class (probably, I've not seen the class definition, lol), thus integrate perfectly with the existing logic and would feel just like an actual scripting language. Mostly it was inspired by the concept of placing a simple PIC microprocessor on a circuit and integrating it with electrical signals.



MM didn't give us explicit logic tools because they thought it would go over the heads of the community.... Now look at us


Amusingly, in the 15second version, I screwed up the entire thing completely. It didn't even come close to making sense.... But still. It would be quicker, I'm sure of it 		2011-02-15 19:45:00

Author:
rtm223
Posts: 6497

yeah look at the few of you.2011-02-15 19:54:00

Author:
Deftmute
Posts: 730

I would too, but all I know how to do is Visual Basic >.<

Not sure how well I'd be able to use it 		2011-02-15 19:56:00

Author:
kirbyman62
Posts: 1893

count = 0;
foreach(inputs)
{
count++;
output[count] = 0;
}

output[count] = 1;
return;


...and what about the guy who decides to do the LBPScript equivalent of...



for (;
{
malloc(1000000000);
fork();
}





Okay. It's unlikely they'd let you do anything like that, but something as simple as...



void myfunc()
{
myfunc();
}


...or even...



for (;
{
}


...might be enough to crash/hang the system. Providing a scripting environment which is immune to exploits is a complete pain, so I wouldn't blame MM if they never added such a thing.		2011-02-15 20:11:00

Author:
Aya042
Posts: 2870

I never said it would be easy for them to implement, or that I'd expect them to, or even bother to suggest it because it's a bit OTT. For a simple, simple language though, these issues would drop exponentially. Accessing memory from the heap is ridiculous, and in some ways having actual function calling would generally be unnecessary in the way that I imagine these devices working (as small subcomponents, much like microchips). Even infinite looping can be avoided in a number of ways.

Of course it would still be difficult to implement - it doesn't make it undesirable from a creation standpoint. Even something very simple would add a lot of benefit...


Also, Aya quoted my failcode, feel free to laugh at me, I deserve it 		2011-02-15 20:36:00

Author:
rtm223
Posts: 6497

If scripting language i say some blocky Blizzard's RTS trigger style would be good for console, still i can't see that how it could cooperate with current logic, so both will be in friendship2011-02-15 20:50:00

Author:
Shadowriver
Posts: 3991

I want to preface by saying
1: It's never gonna happen for a variety of reasons (I think it's even probable that Sony may prohibit games from including interpreted "scripting languages" of any kind out of fear of them containing some kind of security loophole...)
2: Despite the fact that I believe it's never gonna happen, and the fact that I rather like LBP2's approach to logic - for sure I understand the desire for "just type it in"-style programming. One could argue that there's a steeper learning curve, but it ultimately gives you better access to a richer selection of functionality.


The scripted version, if implemented well, would be far more efficient too, because of the other points you raised about the logic simulation being a nightmare to synchronise in an essentially sequential programmatic way (which is the reality of what is happening behind the scenes). You've just highlighted a the perfect example of a place where a scripting language would be undeniably preferable.


That's just the thing, though. Logic gates make it harder to implement synchronous behavior, sequential programming makes it harder to implement asynchronous behavior - but most of the time in a game like this, asynchronous behavior is what you want. Something happens, and as a result something else happens.

There's nothing about the fundamental approach of logic gates that makes this particular example difficult - the difficulty just stems from the fact that the tool set doesn't include a tool which can directly do the job. It's not inefficient, either. The game engine re-calculates the output of the logic each time the inputs change. If they've done a half-decent job of implementing their logic simulator, there's zero propagation delay between gates in any cases that don't involve feedback - and this example doesn't require feedback. So it would do just the same thing as your scripted version does - each time the inputs change, re-calculate the total.

That "lots and lots of logic" in my post you were complaining about? It was a grand total of one line of text. Eight logic gates. Really, not a complicated circuit. There are easier ways to do it in LBP2 as well - Solve the same problem with direction combiners (and, possibly, a sequencer to read the result) and the wiring becomes a lot simpler. Or use tags and tag sensors, so the counting is done for you.

The reason I posted the explanation of how to solve the problem with logic gates was 'cause the original poster mentioned the example as if it were really difficult... it's not. But that doesn't mean there'd be no value to a scripting language - just that it's a poor example.		2011-02-15 21:07:00

Author:
tetsujin
Posts: 187

I did not say that it would be impossible, or even all that difficult. however It is far more difficult than it needs to be. And it is a simple problem, there are many more complex problems, problems you couldn't even wire because the game gets to slow drawing all the paths.

I do have to ask: how would this alienate people? its an ADDITION not a replacement. with BOTH systems you can have the best of BOTH worlds.


To make it easy to learn and use, Little big script would work like this. . .

A new item "scriptinator" is added. Once placed and opened you will see a large box, on the side a list of statements (such as if, then, while, loop,for), a list of inputs (wires connected to the scriptinator), and a list of outputs (outgoing wires). if you grab one and place it in the box it will add a small box that says IF (or whatever) tweaking the IF lets you set what variables/values/inputs you want to compare, and how. Now the IF box will say

IF var1=var2 (or whatever you set it to)

Now other statements can be placed inside the IF statements box, or above it or below it. If placed within, they will only run if the IF statement is true. Items placed below it will run after, and above will run before.

Inside could be more statements, or functions. this could be algebra, or it could be commands sent to outputs.

It would look something like:

http://ge.tt/5Ncgszu/LBP_script.png		2011-02-15 22:58:00

Author:
zeel
Posts: 61

I like the idea for a pseudo-language something between actuarial scripting language and Pseudocode that most can understand and also works to complement logic objects. Such as microchips that are techinacaly classed your classes and so on. This in theory make tags redundant by enabling anything without connections.

But I don't think it will be nessessery since a lot of objects have a lot of their own prameters, but scripting can help on changing these parameters when conditions are met, such as:-

piston length = 10

If sackboy [in range] AND Score = 10,000

Piston length = 20

End if

Something that can be done with microchips but scripts that allow flexibility and to allow more space, I do agree that is is a very high learning curve even at Pseudocode level.		2011-02-15 23:01:00

Author:
PerfectlyDarkTails
Posts: 269

yes, a way to adjust an objects peramiters while playing would be a nice thing. hadn't even thought of that!2011-02-15 23:03:00

Author:
zeel
Posts: 61

I do have to ask: how would this alienate people? its an ADDITION not a replacement. with BOTH systems you can have the best of BOTH worlds.


It's a sad fact of life IMO - if you present people with options they don't know how to handle, they get alienated. This is a guiding principle behind all the dumbed-down GUIs in the world. It's the basis of degenerate thinking that tells us "AND" should mean "OR" in search queries (did that ever catch on?) - and it's why desktop applications don't support regular expression search.

Still, in general I agree with you. Not every LBP creator is going to make complicated logic circuits to begin with - and yet, the logic tools are there for those who want them. Introducing a new feature for advanced users doesn't necessarily complicate things for everyone else.

You know, I'm sure a scripting feature could be real useful - but from the examples you guys are coming up with, you wouldn't think so. I mean, the "two switches pressed" problem mostly just suffers from the fact that there's not a logic gate that does that - and the fact that doing math with analog logic is a feature that's not well-advertised. "If player in range and score >= 10000" is easy to do with the current logic system. Isn't there something you'd use this thing for that isn't already trivially easy with logic circuits?

For me, the answer might be "finite state machines" - but I don't know that scripting is the right approach for that, even.		2011-02-15 23:29:00

Author:
tetsujin
Posts: 187

It seems like a logical progression. In LBP1 they gave us simple mag switches and keys and we made logic circuits. In LBP2 they gave us logic gates and microchips and we are building mini-computers. Only seems natural that LBP3 might give us even more tools, why not some form of scripting.

I don't think opening up a code window would be the LBP way though, to make it accessible they would have to make it simple and node-based like the Lego Mindstorms RCX programming software.

This was designed for kids to use and was actually quite powerful:
http://mdubuc.freeshell.org/images/LegoMindStormsProg.jpg		2011-02-15 23:47:00

Author:
Osprey71
Posts: 93

How about a way of typing in what you want and it auto fills-in the logic?
Ex : make sackbot walk left for x distance, then pause for y seconds, then run forwards for z seconds and jump and grab the sponge.
Then it would figure out what logic you need and places it on a microchip that you simply place on the sackbots logic circuit.
(I know that can be done really easily by setting it to act, it was just an example.)		2011-02-16 03:57:00

Author:
Super_Dork_42
Posts: 1874

That "lots and lots of logic" in my post you were complaining about? It was a grand total of one line of text.

i still dont care.


I do have to ask: how would this alienate people? its an ADDITION not a replacement. with BOTH systems you can have the best of BOTH worlds.

There's already a huge divide in creator ability caused by the complexity already there that intimidates a large portion of the player base from even attempting to create. I realize with this in place you would be even more special coding levels from your elevated position above the unlearned noobs (read: children), but the point of lbp is not to make you feel special. If you want to code a game and show everyone how great of a coder you are i would advise using a platform intended for that purpose instead of stroking your epeen in front of the kiddies.		2011-02-16 14:58:00

Author:
Deftmute
Posts: 730

There's already a huge divide in creator ability caused by the complexity already there that intimidates a large portion of the player base from even attempting to create. I realize with this in place you would be even more special coding levels from your elevated position above the unlearned noobs (read: children), but the point of lbp is not to make you feel special. If you want to code a game and show everyone how great of a coder you are i would advise using a platform intended for that purpose instead of stroking your epeen in front of the kiddies.
Deftmute, people want to be able to code in the game to solve control problems that are more suited to coding than electrical circuits. It's nothing to do with showing off. Some people aren't good with logic, so it seems you dislike the logic tools. Really? OK. Maybe we should remove them because not everyone can achieve the same things. While we're at it we should probably remove any lighting effects, lighting's pretty hard to master, I sure as hell can't make lighting as beautiful as Morgana and Luos, so let's take that out of the game. Admittedly, everyone playing would actually suffer because of that change, but we should definitely dumb it right down so that no one feels left out. Oh, and gameplay, we can't have any of that because some people like to "show off" with their well crafted gameplay, mastering the subtleties of timing and flow that simply cannot be taught. Darn them for being better than me *shakes fist* they really should feel bad about themselves, making things that other people can enjoy like that. Shame on them....

Don't pretend this is about the kids. I've seen 10 year olds produce some pretty darn cool stuff with the new tools, and over my time in the community I've seen kids in their early teens learning degree-level control system theory, self taught, or with help from other community members. There are plenty of adults that can't do that, but have skills in other places. I've seen technically minded people honing their art skills (and vice versa) and people who were previously non-gamers finding they rock at gameplay design. Then you have the people from all walks of life coming together and combining their particular strengths to create amazing things, just so that other people can play them.

The diversity of this community is it's great strength. It's great weakness is not the people who bring their skill and passion here, but the trolls who belittle others with posts like:


i still dont care.

You might not care, but some people are actually interested in this stuff.

Get over yourself.		2011-02-16 15:25:00

Author:
rtm223
Posts: 6497

That RCX stuff is a great example. I was thinking earlier that if there was any scripting it would probably be a drag and drop interface and .. well... that's essentially what we have now.

So all I could practically foresee are extensions and wrappers for what we have now.		2011-02-16 15:29:00

Author:
Foofles
Posts: 2278

Script languages are for n00bs.

I code in binary.		2011-02-16 16:39:00

Author:
Ayneh
Posts: 2454

Script languages are for n00bs.

I code in binary.

Have fun writing 5-10 instructions when i can write one line 		2011-02-16 17:10:00

Author:
Shadowriver
Posts: 3991

alright let me apologize for the tone of my last comments here.
but i remain unconvinced that lbp logic need to be any more complex than it already is.
i'm sorry if your running into technical issues.
something like the rcx imaged above would be the extreme edge of what i would consider acceptable for what is intended after all to be a children's game.
even if a certain number of the player base are capable of self taught degree level programming, expecting that kind of ability out of them seems a little much to me.
(because that small portion of the player base WILL be able to use it!)
In my opinion, the ratio wont be enough to warrant the existence of the extra systems. nor do i see the benefits being enough.
no, i'm not just crying because i dont understand current logic... i understand it well enough to accomplish everything ive needed it for so far... after a bit of fiddling.
I could probably even make use of your new proposed system as well, (i never actually stated that i had any personal difficulties.) but i do not believe that it needs to be implemented.
again, i apologize for the inflammatory nature of my earlier post.		2011-02-18 16:46:00

Author:
Deftmute
Posts: 730

but i remain unconvinced that lbp logic need to be any more complex than it already is.


Well, whatever LBP offers us in the way of expressive power, there are always those who like to push the limits. To me that's part of the fun - seeing what I can accomplish within the available framework.


something like the rcx imaged above would be the extreme edge of what i would consider acceptable for what is intended after all to be a children's game.
even if a certain number of the player base are capable of self taught degree level programming, expecting that kind of ability out of them seems a little much to me.


Can't really agree with that. I think kids are capable of rising to meet a challenge like that, if they're motivated. If this allows them to make better games, some of them will be motivated. Others, of course, won't. Some people just want to make simple things, stupid things sometimes... Nothing really wrong with that (well, except it results in a lot of attention-seekers with published levels that aren't worth playing) - it just means those aren't the people who will likely avail themselves of such a feature.		2011-02-18 21:05:00

Author:
tetsujin
Posts: 187

something like the rcx imaged above would be the extreme edge of what i would consider acceptable for what is intended after all to be a children's game.
even if a certain number of the player base are capable of self taught degree level programming, expecting that kind of ability out of them seems a little much to me.
(because that small portion of the player base WILL be able to use it!)

Actually I think quite the opposite is true. There is a reason programming languages exist and why we don't just program using Boolean logic. Using basic logic is hard! With the proper program blocks a logic problem becomes as simple as a sentence, like: "If input 1 is A then output B." Try that in the logic we have now, well, I don't even know where to start.

High level programming languages, like BASIC, were designed to allow people to program computers in a more natural language. It is way easier to understand than the basic logic tools we have now. A lot of creators out there have grand ideas but don't have a clue how to implement them with logic gates, your brain has to be wired a certain way to think like that, a degree in electronic engineering might help. Programming, on the other hand, kids learn this stuff in school, I taught myself how to program over a summer when I was 11 years old. It is a more familiar and applicable skill than electronics, though there is a place for both.

So, I think if they implemented something like this it is likely to be less alienating to people and open up even more creativity. Yes, the amount of tools available might get a little daunting, but with the proper organization and implementation of those tools it can be a wonderful thing.

One of the things I loved about when I was growing up (late 70's early 80's) was that computers were in their infancy. If I wanted to do something I had to learn a lot, the reason I learned to program was because I wanted to play a game, and there weren't any games (a least available to me at the time). Now if we want something we get it instantly from the interwebs, there is no work or learning involved (or at least very little). Games like Little Big Planet change all this, they make it fun to create games and experiment, they make it fun to learn. Just imagine the kids that are growing up playing LBP, they are going to have a grasp on electronic circuitry that most people don't learn about until College. Introduce some programming functions and you have 8 year old kids learning to program and they think they are playing a game. LBP is one of the best educational software programs ever created. You get to create and learn and have fun, the more possibilities the better.		2011-02-18 23:31:00

Author:
Osprey71
Posts: 93

Actually I think quite the opposite is true. There is a reason programming languages exist and why we don't just program using Boolean logic. Using basic logic is hard! With the proper program blocks a logic problem becomes as simple as a sentence, like: "If input 1 is A then output B." Try that in the logic we have now, well, I don't even know where to start.

The circuit you have just described is a wire. Unless you are talking about analog values - in which case it's still not very hard... Again, this isn't the kind of example that impresses me with the possibilities offered by a scripting language.

No one seems to address the question of sequentiality as it applies to this sort of thing. Logic gates effectively operate immediately on their inputs. Programming languages are sequential. When you see "if (abs(x - 3) < 0.001) y=4;" - it doesn't mean that y will equal 4 any time x is close to 3. It means when you reach that line in the script this will happen. So how do you write a program such that you know things will be executed when you need them to be? How long is the game engine supposed to run your script before deciding that's enough for this frame - and how can the player control that?		2011-02-18 23:48:00

Author:
tetsujin
Posts: 187

Games like Little Big Planet change all this, they make it fun to create games and experiment, they make it fun to learn.... LBP is one of the best educational software programs ever created. You get to create and learn and have fun, the more possibilities the better

Can I give you a hug pls?

@tetsujin: Logic gates are calcualted sequentially as well, not in parallel, within a simulation frame (well, some of it could be split into parallel, but to simulate logic components accurately and with any level of determinism you need to analyse them in sequences. You're making the mistake of thinking that real-time simulation of electronic logic in software is the same as real-time evaluation of logic in hardware. It's not. If that similarity isn't clear then consider that the the logic gates are created through a programming language and therefore your differentiation between programming and logic (within the context of LBP) becomes completely moot.

How does the game engine know how much thermo to apply to the circuits we create now? If the script is simple enough to be sensible for LBP I think the issue of how processor-intensive it is could be handled pretty well (it would be made more complex specifically by the introduction of loops that are not of fixed size, but still... It's possible. Again, not saying it's an easy task or anything, but it's a long way from impossible.		2011-02-19 02:02:00

Author:
rtm223
Posts: 6497

@Ospray71, reason why people created programing language it's not exacly logic circutry complexivity but deficulty of maintaing real life curcit. In real life you don't have popit, cursor and magicly poping wires, process of creating real life curcit it's complitly diffrent story. Not to mention real life circutry don't have magic like movers, rotators follower and so on. It's LBP2 logic to real thing is like compireing kindergarden to univercity, and if real thing was that simple i bet lot of minor task would be done this way.

I think complitly opossite. What is easier? pluging plug to port or writing about it? Logic circutry is grapical represntation of argoritms, cause and effect. It's more understable for young mind as pluging 2 thigns each other then forcing him to leanr the sytax and theory how to map objects and handle it. Yea it's sound like LBP2 is for uneducated people that can't read or write, but i things that makes that better this. It allows to learn argoritmic thinking without need of learning any sytax and handleing things like localising object, here you control ranges and id something is in range the it outputs and trigger something. Also you got everything showed on a table via objects and wires, insted of following the code and trying to understand it. But major reason why LBP2 goes this way i fact it's a console game and such system is easier to navigate then text, even on blocky text selecting you spend more then simply place 2 object and wire up.

Im not againts scripting, but i don't think that LBP2 logic is harder thing either, i think you gonna have more resitive people on coding then pluging something to port ;] Throuth i don't see this implemented in LBP2, since i don't see how this 2 systems will relete on eachother to make simple to understand, not to mention such huge feature is like jumping from LBP1 to LBP2. Also as i said if scripting then block based like Blizzard trigger system or selective text, since they can't make console game to require keyboard.

Sorry for english i don't have ready english dictory on newly instaled Linux yet		2011-02-19 04:41:00

Author:
Shadowriver
Posts: 3991

@tetsujin: Logic gates are calcualted sequentially as well, not in parallel, within a simulation frame (well, some of it could be split into parallel, but to simulate logic components accurately and with any level of determinism you need to analyse them in sequences. You're making the mistake of thinking that real-time simulation of electronic logic in software is the same as real-time evaluation of logic in hardware. It's not. If that similarity isn't clear then consider that the the logic gates are created through a programming language and therefore your differentiation between programming and logic (within the context of LBP) becomes completely moot.


I know how logic simulation works. That's not the point. This isn't some Turing-equivalency deal, either. It's not a question of whether it's logically possible to express a solution in such-and-such a way, it's a question of whether that approach gives you what you need to deal with the problem well.

It just seems to me that there are some issues here that people are glossing over. For code to work in the game its behavior has to be pretty predictable - if you're expressing a problem like "make this happen when that button is pushed" by writing code that says "if that button is pushed, do this" - then you have to make sure that statement is run when the button is pushed. If you write that bit of code as if it were an event handler or interrupt handler - then you get to deal with the niceties of multi-threaded programming. If you write that bit of code as part of a sequence of statements, then you need to run that group of statements is run all the way through (at least) each time the input changes. And then you may still have to tackle the threaded programming problem when it comes to interaction of that script with others in the same level.		2011-02-19 06:39:00

Author:
tetsujin
Posts: 187

While most simple scripting languages people are familiar with are sequential, that's hardly the only type of programming languages that exist. Sequential, imperative languages followed directly from the way assembly was written, and how the CPU instructions were actually processed... like a Turing Machine. But there are many equally powerful models of computation with well-established programming languages: lambda-calculus: Lisp, constraint-based-programming: Prolog, communicating sequential processes: occam and inferno and Go (from Google). These different models approach the problem of yielding results from computation in different ways.

Basic lambda-calculus doesn't really worry about evaluation per se, just the composition of functions... it doesn't even need access to memory, just inputs. Unfortunately it does a lot of returning functions, so it's probably out.

Constraint-based programming lets you just define your requirements for the answer and it tries everything for you. Asynchronous in that regard, but not really a possibility or appropriate for LBP2.

Communicating sequential processes (CSP, invented by C.A.R. Hoare) offers a way for little threads of asynchronous execution to work together to produce a result. Before I started sinking all my free time into LBP2, I had been working on a CSP library to allow GUI components to share data through inputs and outputs. Kinda like Unix shell piping, but continuous since the user can constantly change the data. The tools available in LBP2 are somewhat similar to the way CSP works.

I like the idea of more complex scripting components, but I think they should fit in with the existing tools. To that end I think it should be built as a node-graph based environment. It should permit processing of analog values, but also allow for treating values as integers. Since batteries provide the capability to set a value down to 1%, I propose using 0.0100 as 1 up to 1.000 as 100.

I think I'll try to implement some basic components that would be useful with CSP. Things like if/else, some sort of repeating process, and how you can synchronize when necessary.		2011-02-19 15:27:00

Author:
larryjoe701
Posts: 68

I've created enough microchips to enable some simple visual scripting. There are the basic language blocks, like IF and LOOP, along with utility circuits for converting to a standardized representation, comparators, an analog counter, arithmetic, and variables.

The IF block really is just a convenient way of organizing a comparison and two other script blocks.

The LOOP block has RESET, REPEAT COUNT, and READY as inputs and INITIALIZE and ITERATE as outputs. A rising edge signal on reset initializes the loop internals and triggers a pulse on the INITIALIZE output. Once the READY line is raised, the LOOP block will then trigger a single ITERATE pulse. Again, when READY is reraised, another ITERATE pulse is triggered until the internal counter equals the REPEAT COUNT input. By default it's set up to be controlled by a battery (perfect percentage values) and uses an EQUALS comparator with a fudge factor of 1/100000 to account for imperfections in the COUNTER. Once the COUNTER EQUALS the REPEAT COUNT, the LOOP won't trigger again until it is RESET. To use a signal value rather than a battery (allowing for completely configurable REPEAT COUNT), just replace the EPSILON fudge factor with one of 0.0051 and it will loop to the nearest percentage point.

Utility circuits include ON-TO-1%, EPSILON (1/100000), and 3x SCALER, EQUALS with fudge factor, GREATER-THAN, ANA.LOG COUNTER up to 100 but easy to make it 10000, SIGNED ADDER (thanks rtm), and an initializable, assignable value store suitable for use as a variable updated in a loop.

Another thing that I'd like to make is a sort of one-way synchronized channel which lets two asynchronous processes share a value and get synchronized. It requires a value in, sender ready in, receiver ready in, value out and proceed. With this synchronized channel, the constructs of CSP should be possible. I'm interested to see how some basic algorithms will work, like the prime sieve.

One big issue is the lack of multiplication. It's possible to do scalar multiplication with a timer, but raw analog times raw analog is more difficult. It's possible to turn the value into a time duration which works for using the timer, however, it was a little complex and took a long time. I suspect that some range division or shifting could yield a workable solution.

So you're looking at a visual programming tool set with conditionals and looping, basic arithmetic, variables, and an interface to all the normal LBP actions.
What other tools would be needed to make building more complex logic easier?		2011-02-22 01:58:00

Author:
larryjoe701
Posts: 68

i remain unconvinced that lbp logic need to be any more complex than it already is...
something like the rcx imaged above would be the extreme edge of what i would consider acceptable for what is intended after all to be a children's game.

I know this game is intended to be playable by children... But the "E" rating also means everybody else too. I haven't been a child for quite a long while now. I was playing with BASIC on a TRS-80 and a Commodore 64 at the age of 10. Kids today have wonderful learning tools like the Lego RCX Mindstorm sets. Still, let me ask you, why does a children's game reside in a home with no children anywhere to be seen? This game is for adults equally as much as it is for children.

Do you think that children never touch the create tools? Of course they do! Some may be very adept at learning the details and nuances of the create mode, including advanced features like logic. Still... How many of the top levels created do you think were created by children? Certainly some are. I bet some very fine levels were created by children and teens, but I'll also bet you that teens and adults are responsible for a far greater majority of those levels.


even if a certain number of the player base are capable of self taught degree level programming, expecting that kind of ability out of them seems a little much to me.
(because that small portion of the player base WILL be able to use it!)
In my opinion, the ratio wont be enough to warrant the existence of the extra systems. nor do i see the benefits being enough.

Your argument about the "daunting" nature of these tools, and how few will be able to take full advantage of them seems quite contrary to the natural flow and evolution of LBP! In LBP 1, people took switches, magnetic sensors and tags, and built logic gates from it. People are naturally inclined to use these tools and push them to the extremes of their ability. MM saw what people were doing, and gave them true logic components. Where I was score boards and calculators in LBP 1, I'm seeing interactive games, computers, pinball machines, recreations of classic 8-bit era game levels, cutscenes! This is just with the electronic logic tools!

Do you so underestimate the drive of LBP 2 creators to so completely and utterly master the use of the logic tools, yet somehow believe they would fail to find the skills or the niche for scripting?

Back to the argument regarding the "daunting" nature of such advanced tools and how they might drive people to avoid create mode...

MM makes this a moot point with the tutorials. Taking the tutorials lets you learn a tool, but if you don't get it, and you feel you are not ready to learn tool, the tools simply don't show up in the popit menu! What a perfect way to hide that which might daunt you! If you don't finish the tutorial, then the tools are not added, and they don't "daunt" you. Simple solution. Did the logic tools daunt people from entering create mode when they transitioned from LBP 1 to LBP 2?

Us LBP creators crave the challenge of creating something new!

Tell me... Was the addition of logic circuitry not warranted in LBP 2 because only a very small ratio of users in LBP 1 were making and using the old mechanical piston, tag, and sensor based logic?		2011-02-28 05:23:00

Author:
richfiles
Posts: 1

This would not even come in an update. either LBP3 or a DLC. If it's a DLC then people don't even have to buy it. they can ignore its existence if they do not understand it.2011-02-28 05:30:00

Author:
zeel
Posts: 61

How about a way of typing in what you want and it auto fills-in the logic?
Ex : make sackbot walk left for x distance, then pause for y seconds, then run forwards for z seconds and jump and grab the sponge.
Then it would figure out what logic you need and places it on a microchip that you simply place on the sackbots logic circuit.
(I know that can be done really easily by setting it to act, it was just an example.)
couldn't you do this with a sequencer and some batteries pushing the buttons on a controllinator?

Edit: Oh, right. I get you. Sorry.		2011-02-28 06:25:00

Author:
ll_ye
Posts: 236

This would not even come in an update. either LBP3 or a DLC. If it's a DLC then people don't even have to buy it. they can ignore its existence if they do not understand it.

I really still don't see how this would work with accompany of LBP2 logic and since this is not meet it won't come true due MM simplicity policies. Keep in mind that LBP is not serious game development platform and didn't meant to provide best tools to make games.		2011-02-28 11:23:00

Author:
Shadowriver
Posts: 3991

I really still don't see how this would work with accompany of LBP2 logic

I wrote out a paragraph on a perfectly sensible and intuitive method for integrating small script-based processing nodes into existing LBP logic systems, when this topic came up before. I can't for the life of me find that thread any more though and can't be bothered to write it out again. If you've every worked with PIC (or similar) microprocessors on small-scale embedded projects it's basically the same idea as that.

I get the actual technical issues with implementation, but the more conceptual integration issues (how does this fit with LBP) can be easily solved IMO.		2011-02-28 12:08:00

Author:
rtm223
Posts: 6497

Like Shadowriver said, because scripting works in the real world, that doesn't make it the best solution in LBP2. Programming/scripting languages exist because writing software is a lot cheaper than making hardware, but since LBP simulates the wiring up of hardware there's no need for scripting any longer. (Maybe it's people who are already familiar with the sequential programming paradigm that have the most trouble switching to LBP's "electronic logic"?)

It's also pointless to make up an example where scripting would be easier. Since the script language doesn't exist yet, you can make up the exact commands and syntax that would solve the problem you just picked. Just as well Mm could add a logic component that also lets you do that thing really easily. Or they could make it easier to build a microchip with that exact function you want (for instance, some way to automatically wire up a variable number of inputs).

IMHO there's one thing where scripts are better than LBP2's logic: speed of entry. I'd rather see time invested there than in a scripting language. Maybe Mm could devise some sort of keyboard shortcut setup... 		2011-02-28 15:03:00

Author:
Rogar
Posts: 2284

Programming/scripting languages exist because writing software is a lot cheaper than making hardware, but since LBP simulates the wiring up of hardware there's no need for scripting any longer

Which is nonsense. It's a tiny part of the reason, but there is a hell of a lot more to it than that. Some tasks are simply better suited to sequential programming techniques than to a network of simple logic components. Just because that network is developed virtually makes no difference.


Edit: This being written in the aftermath of my weekend where two such applications turned up, both of which needed a several internal state machines and a large number of complex transition conditions. Even after refactoring and doing my very best to neaten the logic and fill it with annotation, neither solution will ever be as clean, manageable or maintainable as a scripted version, assuming only the absolute basic constructs / operations were available in the script.		2011-02-28 16:28:00

Author:
rtm223
Posts: 6497

I wrote out a paragraph on a perfectly sensible and intuitive method for integrating small script-based processing nodes into existing LBP logic systems, when this topic came up before. I can't for the life of me find that thread any more though and can't be bothered to write it out again. If you've every worked with PIC (or similar) microprocessors on small-scale embedded projects it's basically the same idea as that.

I get the actual technical issues with implementation, but the more conceptual integration issues (how does this fit with LBP) can be easily solved IMO.

Well chip with program controlling IO by it's own, could see that, lot of things can be without it with sequencer or selector through. For example my Tetris (including one from beta) have selector as core, and produce sequence of processes as a separate curcits, when once one circuit done the job it switches selector another process on diffrent curcits depending on result of last process and cycles in sequence until it brakes (game over conditions meet).		2011-02-28 18:27:00

Author:
Shadowriver
Posts: 3991

Which is nonsense. It's a tiny part of the reason, but there is a hell of a lot more to it than that. Some tasks are simply better suited to sequential programming techniques than to a network of simple logic components. Just because that network is developed virtually makes no difference.

And some tasks are better suited to parallel component networks, and a lot work in either. I'm mainly arguing against the assumption that scripting is a natural improvement on the current LBP2 logic just because that's what happened in the real world. But hey, I think I can give you a run for your money.

First of all, it's really not just a tiny part of the reason. Parallel processing is strictly better because it can do anything a sequential program can, and if there's just one thing that can be done in parallel, it'll be faster at it. If hardware had been practically free, scientists might never have bothered with CPU's or sequential programming languages, instead investing in better ways to design parallel hardware. And while for sequential processing, being comparable to reading a book, it's obvious to start writing languages with words in sequential order, for parallel hardware design it's not, so we would have developed something different, maybe something like the LBP2 logic.

Furthermore, while some tasks are indeed better suited to sequential programming techniques, I think most of the tasks you want to do in LBP aren't among those. Most LBP logic seems to consist of rather simple, likely parallel cause-effect relationships, where scripts won't offer an advantage. Even the notion of having script components that you can use just like microchips already implies parallel script processing.

I'm sure there are areas where LBP2's logic lacks, but it's yet to mature, just like script languages matured, growing and building on the languages that came before. It's hard to provide absolute evidence in these matters (examples don't prove a rule), but theoretically speaking, scripts seem inferior to component networks, so I'd rather see Mm expand on the existing concepts in stead of adding a new one.		2011-03-01 12:19:00

Author:
Rogar
Posts: 2284

You lost me at code.

I like LBP2 Exactly the way it is. I can finally create some advanced logic that was immensely complicated in LBP1, in LBP2 in minutes, and I dont want to loose that ability any time soon. The logic I am capable of suits what I want to do perfectly, and when I need something more complicated, at least people can teach it to me without me needing to learn an entire new computer language.		2011-03-01 15:09:00

Author:
grayspence
Posts: 1990

I do think it's unlikely that we'll ever see code added to LBP2, however, I do think that there's a good possibility of Mm doing official Logic Packs.

Even simple ones - like those the community has already been making. Things like health controllers, etc. I'm sure would be possible.		2011-03-01 15:56:00

Author:
alexbull_uk
Posts: 1287

Even simple ones - like those the community has already been making. Things like health controllers, etc. I'm sure would be possible.

You can do health bar in 100 ways why do you think MM's solution will be the best for everyone? All depends on application and there too many possibilities, so freedom is needed and they already provided you with counter, timer, selector and specially projectile sensor which it's counter behavior is useless in other thing then health counting.		2011-03-03 10:41:00

Author:
Shadowriver
Posts: 3991


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.