Little Big Script

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:

Code:

---

//"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/littlebig...tle_big_script

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.

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

Quote:

---

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/wikipedi...screenshot.jpg


something similar. at least in form, if not over all function.

I'd like it better if it was Lua.

Code:

---

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

---

I just summed up what you said 200% simpler.

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 :p

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

Quote:

---

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

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.

Oh they changes name and description, then it's ok.

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

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.

Quote:

---

Originally Posted by Foofles

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.

Quote:

---

Originally Posted by Foofles

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

Quote:

---

Originally Posted by Foofles

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

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

Quote:

---

Originally Posted by tetsujin

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.

Code:

---

count = 0;
for(i=0 ; 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 :p 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.

Quote:

---

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 :p

yeah look at the few of you.

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

Not sure how well I'd be able to use it :p

Quote:

---

Originally Posted by rtm223

Code:

---

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

Code:

---

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

---

;)


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

Code:

---

void myfunc()
{
    myfunc();
}

---

...or even...

Code:

---

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.

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 ;)

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 friendship

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.

Quote:

---

Originally Posted by rtm223

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.