Home    LittleBigPlanet 1 - PSP - Tearaway -Run Sackboy Run    LittleBigPlanet 1    [LBP1] Suggestions [Archive]
#1

Logic Switch Creator Pack

Archive: 74 posts


EDIT 6/25/09

4 months ago I posted a suggestion for Mm to have a logic gate creator pack as an alternative to complex mechanical devices. The suggestion received a single response. 5 days ago the thread was brought back and received tremendous interest, spanning a 4 page discussion. In light of changes to the game since my initial post and the many opinions expressed over the last week, I feel it is appropriate to revise and expand upon the suggestion. The original suggestion can be found below.

Opposed to a level pack how about a creator pack that was designed to assist those doing more technically complex creations. Currently many people use mechanical logic gates. It would be nice to see non-mechanical ones in a creator pack. Basically I'm talking about is at a bare minimum two additional switches.

AND switch. This accepts on/off connectors from other switches. However, unlike other objects in the game it can accept multiple connectors as inputs. If all the connectors are on then the switch activates (and does whatever it is set to do on/off, direction, 1, etc). If any of the inputs are off, the switch does not activate.

OR switch. As above but if one or more are on it activates.

Obviously more logic gates would be nice but just these would be an enormous gift to those users who make complex levels. Mechanical logic gates operate at 10Hz and take up a lot of thermometer. I'm sure if they were coded directly into the game as switches they would operate near instantaneously and take up far less thermometer space.

In looking at the responses most people (although there were some exceptions) strongly agreed with the suggestion itself. Differences of opinion most commonly occurred when discussing the specifics of how such a suggestion would best be implemented into LBP. So I will break up this post into two parts. I will start by discussing the general concept of a logic gate creator pack without going into specifics. I then, as separate section, discuss a possible implementation of the idea.

Section 1: Logic Switch Creator Pack
Currently in LBP many creators have seen a need to be able to attach multiple wires to a single object. These can range from very basic implementations such as wanting two switches that open and close a door (one on each side) to prevent players from getting stuck all the way up to complex mechanical computers that allow creators to essentially write custom programs that control pieces of their LBP creations.

Many people who would like to include such things in their levels find these mechanical contraptions too challenging to implement. On the other side, for those currently using such devices in their levels find a number of limitations. I present these in no particular order:

1) The minimum timing is 0.1 seconds. This sounds quite fast on paper. In practice it can be a long time. Picture a 0.1 second delay between hitting the x button and sackboy jumping or hitting R1 and having the paintinator firing. Delays on the order of milliseconds are noticeable in control schemes. 0.1 seconds is actually a very long time for some applications.

2) These devices are very thermo intensive. In particular they tend to eat up one?s moving object thermometer. They can also eat into the maximum number of collected objects one can include in a level. This is a big trade-off for creators.

3) Even for creators who are familiar with these devices, they can be difficult to keep organized. If you go back to a level a week or month or year later you might have no idea which device does what.

4) Typically these mechanisms are created using ugly dark matter because they can jam up if they are placed on moving parts. Generally speaking these devices need to be placed away from the objects they control to create a clean looking level. However, this also means that it becomes very hard to emit objects using these mechanisms or give them out as prizes.

So as a general concept, I am suggesting a logic switch creator pack. I recommend doing this as a pack, rather than an update, so only people interested in pursuing this complexity need to be effected by it. This basic suggestion makes the assumption that Mm can implement it in a manner that will improve upon the 4 points I've noted above, make it simple enough for the average gamer to use without being intimidated but include enough room for complexity that people who want can get a lot out of it.

******************

Section 2: A Possible Interface for Realizing a Successful Logic Switch Creator Pack

Okay, so now that we?ve talked about what a logic switch creator pack should do, it's time to talk about how it can deliver.

Were going to build on what already exists in LBP. Logic switches will be placed in a level in the same way that a proximity switch or magnetic key switch is placed. This will immediately You will have several options in the tweak menu:

First off you can set the behavior. Is it on/off, direction or one shot? Speed will not be an option here. You will also have the option to invert the switch. The standard option of making thing visible or invisible in play mode will also be available.

Basically, you will grab the wire coming off the device and tie it to whatever you want, just like any other switch. The real issue here is that these objects, unlike all the other ones in the game, will allow you to connect more than one wire to them at a time. This number could be unlimited. However, I?m going to recommend that each can only accept 8 input wires to make things easier.

These input wires can only have on/off behavior. They will not allow directional, one shot or speed switches. Invalid wires will appear red, exactly the same as it is implemented throughout the rest of the game.

So, the first hurdle of these devices becomes how to handle multiple wires. I recommend something I?ll call the magnifying lens, which is just a cute name for a cool looking pop-up window. Basically, if you leave the cursor (either empty or holding a wire) hovering over the logic switch for a second or so, a magnifying lens will pop up showing you a close up image of the circuit. The close up image will show 8 spots where input wires can be attached. All you need to do is place the cursor holding the wire over one spot and hit the X button to attach it as normal. This will then close the magnifying glass. If your hand was empty you can place it over one of the inputs that has a wire attached and hit x to pick it up, as normal. Really the only change here is the magnifying glass to help with the management of multiple wires. Otherwise the interface is the exact same one that we are used to for wires.

Proximity and magnetic key switches have a visual indicator to let you know if the switch is active or not. These switches will feature a similar indicator. However, they will also have input indicators to make it easy for people to see what is happening. A light bulb appears where each wire is placed. It will be on if the wire is sending an on signal. It will be off if the wire is sending an off signal. There will be no light bulb, just an empty socket, if there is no wire attached. This will make it very easy for people to follow what is happening.

There will be more than one type of switch. Right now I think three switches are needed.

http://upload.wikimedia.org/wikipedia/commons/thumb/4/4c/Or-gate-en.svg/128px-Or-gate-en.svg.png
OR Switch: The physical appearance of the switch will look something like this, plus the indicator lights for input and output discussed above. The inputs are on the left, the output wire and indicator on the right. This does a simple OR operation using all the wires that are attached. It activates if any of the wires are on. It is off if there are no wires attached.

http://upload.wikimedia.org/wikipedia/commons/thumb/b/b9/AND_ANSI_Labelled.svg/120px-AND_ANSI_Labelled.svg.png
AND Switch: The physical appearance of the switch will look something like this, plus the indicator lights for input and output discussed above. The inputs are on the left, the output wire and indicator on the right. This does a simple AND operation using all of the wires that are attached. It activates if all the wires are on. Unused inputs are ignored rather than being counted as off wires. If no wires are attached it is off.

http://upload.wikimedia.org/wikipedia/commons/thumb/0/01/XOR_ANSI.svg/128px-XOR_ANSI.svg.png
XOR Switch: The physical appearance of the switch will look something like this, plus the indicator lights for input and output discussed above. The inputs are on the left, the output wire and indicator on the right. This activates if an odd number of wires are on. It is off if an even number of wires are on or if no wires are attached.

There will be a tutorial for each of these, with examples for practical uses to make them accessible to the average player. I?m also happy to add in additional ones suggested by people on this thread. I've already mentioned some others in my posts but I want to get this done today so I?m only putting the basic 3 in for now.

Finally, we come to limitations.

The first and most obvious limitation is thermometer. Since these do computer calculations rather than simulated physics they will take up less thermo than the mechanical gates they are replacing. However, they will take up some thermo. Put too many in a level and you?ll get a message saying to use less. Continue putting them in and you?ll eventually get the message that the level has overheated.

The second limitation, and this is a big one, is that the logic switches will not accept wires from other logic switches. You can still wire them together indirectly, just not directly. This will prevent having circular logic. Indirect circular logic is okay, as it will just cause the switch to turn on/off at the mechanical interval. As a side effect this will also prevent nesting, which is extremely limiting. However, we introduce one more element to the mix to make nesting easy for beginners and advanced users alike:

The Circuit Board
The circuit board is placed the same way as the switches. However, it contains a tweak menu that is unlike any other. Instead of having the standard settings you get a screen where you can place logic switches on sockets that are arranged in a grid. A satisfying soldering noise can accompany placing a logic switch. Information must always flow left to right. The left side of the screen has spots for wire inputs. Attaching wires here is done with the magnifying glass as described above. The right side of the screen has spots for output wires. You then link these inputs on the left to the outputs on the right through logic switches in the middle.
http://www.lbpcentral.com/forums/picture.php?albumid=448&pictureid=4658
http://www.lbpcentral.com/forums/picture.php?albumid=448&pictureid=4659

Again, I?ll repeat this because it is very important, unlike the normal creator where you can place wires in any direction, here you can only place them left to right. As an additional idea, to help people troubleshoot, the wires that are currently receiving on signals will glow, while the wires that are receiving off signals will not.

The total number of inputs, outputs and logic switches allowed in one of these circuit boards will not be unlimited. There will be a set number of maximum inputs and outputs as well as a set number of positions for logic switches to be placed. An additional failsafe will limit the total number of connections with a ?this circuit is too complex? message, just like the number of corners on an object are limited. Mm will need to experiment with this to find out what these maximums should actually be to ensure that no slowdown occurs and the calculation is virtually instantaneous.

Logic switches and the circuit boards cannot be directly wired together. As before, they can be wired indirectly by placing mechanical parts between them (as this slows them down so circular logic stops being a problem and error checking would be too complicated to prevent it).

That is all for now. As I said earlier, there are obviously more switches we could come up with that could be included in this pack (or a logic switch pack 2 ). A delay switch would be the most important as it would be possible to allow logic switches to be hooked together through delay switches. However, just what is written above should give people an idea of the sort of implementation Mm might be able to achieve.
2009-02-22 18:55:00

Author:
dcf
Posts: 468


It would look awesome if they either released some "curcuit boards" (that looked like actual circuit boards) with logic functions, then people might be ahppy to have them showing in their level, and they would be easy to use for the less experienced
Or if they gave us a "circuit board" pack, where we could design our own circuits, with exact time capacitors and such
2009-02-22 19:35:00

Author:
Pinchanzee
Posts: 805


It would look awesome if they either released some "curcuit boards" (that looked like actual circuit boards) with logic functions, then people might be ahppy to have them showing in their level, and they would be easy to use for the less experienced
Or if they gave us a "circuit board" pack, where we could design our own circuits, with exact time capacitors and such

I currently average a couple hundred mechanical logic gates per level. This is why I made the suggestion. Virtual circuit boards would be a really cool expansion of it. Basically its a way to make complicated switches and have them computed directly instead of being physics simulated in order to save thermometer, space and key colors.
2009-02-22 19:40:00

Author:
dcf
Posts: 468


I really like this idea. I'm working on a level where the boss got so complicated that it has to be released on it's own, due to all of the logic required.2009-06-20 00:18:00

Author:
comphermc
Posts: 5338


I think we'd see the general quality of levels shoot up as well - currently you either need the knowledge to make them yourself or the drive to get one from any one of the "logic giveaway" levels and learn how to use it. I think it would definitely benefit everyone to have a standard switch (or set of switches) instead. I think a basic set would be best - I'm sure even that could make more complicated logic even easier to set up.2009-06-20 00:32:00

Author:
ConfusedCartman
Posts: 3729


Code 18 in the LBPC Best Suggestions List (https://lbpcentral.lbp-hub.com/index.php?t=t=9323) hint, hint 2009-06-20 00:43:00

Author:
dcf
Posts: 468


I personally don't think this is a good idea...
This will generalize stuff a lot, most of the best creators discovered their own ways to surpass the basics which gave them the opportunity to go beyond expected.

If this was done many people will just follow that pack's instructions and won't care on going through another route, leaving them stuck in the average where thousands are doing the same...

Thinkof it like a bird about to come out of its shell.
It is a lot better to leave the bird come out of its shell by itself, even if struggling than helping it out.
2009-06-20 01:05:00

Author:
Silverleon
Posts: 6707


That's an elegant little comparison, but I foresee the overall quality of logic use improving. No more annoying lifts that go up before you are on them, no more ugly green dissolve floating around for newbs making permanent switches, things of this sort. It also opens the doors for experienced creators to make more complex logic-based elements. I have a comparison as a response:

You can tear down a house with your hands, but it's much more efficient to do it with a sledge-hammer.
2009-06-20 01:45:00

Author:
comphermc
Posts: 5338


Maybe even permanently shutting doors, too?2009-06-22 04:34:00

Author:
TheMarvelousHat
Posts: 542


i wouldnt see the problem with adding these "circut boards"
its not like its that much effort to go out an find a level that will provide and,or and permanent switches for you so why not just have them readily available?

They would be a boon to those who could really use them and those who couldnt wouldnt really be all that better off because in order to properly use one of these switches you have to know how they work and if you know how they work you could probably just make one yourself.
2009-06-22 04:43:00

Author:
redmagus
Posts: 667


I'm in awe of comphermic's strong hands

I agree. Admittedly a lot of what I use are strange custom mechanical circuits which would likely have no comparison to a digital circuit. But a set of primitives with AND / OR / XOR / NOT gating, and some generic latches and timers would improve efficiency for many creators and improve accessibility for many others. The only downside I would see is that it breaks the perception of simplicity and it would just be less fun
2009-06-22 09:25:00

Author:
rtm223
Posts: 6497


I don't think i would use them because it would probably get to complicated i prefer just to use logic i created then i know what going on.2009-06-22 09:35:00

Author:
robotiod
Posts: 2662


Hmm it could be useful to others, i've already created my own of course.

And MM has all they're logic doodah's imbedded into they're floor of a lvl so you can clearly see when a switch is moving around.
2009-06-22 13:00:00

Author:
BlackToof
Posts: 172


I think that it is a great idea. Imagine if we didn't have buttons and we had to make a platform, attached to a spring, attached to a magnetic switch, attached to a magnetic key. It would be much more thermometer intensive and it wouldn't be uniform.

Now think of an AND gate. If you want to add more (assuming its pistons attached to wood), you would have to expand the dark matter, add in another piece of wood and piston and hope everything is set up correctly and goes well. If MediaMolecule had an object that was simply a box you could connect on/off switches to and choose the output, it would be worlds simpler and less thermometer intensive, because no real object data has to be loaded or physics computed. I'd imagine that it would be very simple to code in, much simpler that the objects they've released in the past. Honestly, I see no negative side to this.
2009-06-22 15:14:00

Author:
BSprague
Posts: 2325


I think that it is a great idea. Imagine if we didn't have buttons and we had to make a platform, attached to a spring, attached to a magnetic switch, attached to a magnetic key. It would be much more thermometer intensive and it wouldn't be uniform.

Now think of an AND gate. If you want to add more (assuming its pistons attached to wood), you would have to expand the dark matter, add in another piece of wood and piston and hope everything is set up correctly and goes well. If MediaMolecule had an object that was simply a box you could connect on/off switches to and choose the output, it would be worlds simpler and less thermometer intensive, because no real object data has to be loaded or physics computed. I'd imagine that it would be very simple to code in, much simpler that the objects they've released in the past. Honestly, I see no negative side to this.

This is largely the key point. It should have huge thermo savings. Right now logic gates can quickly eat one's moving object thermo. It is also much simpler in terms of making self contained objects. For example, imagine being able to put AND gates directly on a creature instead of needing to wire the creature to something off screen.

This isn't really a suggestion for enabling new things. What it does is let us do things we've already been doing in a more efficient, cleaner manner.
2009-06-22 16:36:00

Author:
dcf
Posts: 468


Lower Thermo, less build time creating your own switches... sounds like a win win situation to me. How anyone could see this as a negative is beyond me?2009-06-22 19:33:00

Author:
Rustbukkit
Posts: 1737


Lower Thermo, less build time creating your own switches... sounds like a win win situation to me. How anyone could see this as a negative is beyond me?

Not to mention easy to read symbolic logic and routable wiring. But yeah, MM may well see this as a no-go as it breaks their veneer of simplicity.
2009-06-22 19:38:00

Author:
rtm223
Posts: 6497


Not to mention easy to read symbolic logic and routable wiring. But yeah, MM may well see this as a no-go as it breaks their veneer of simplicity.

Not really, they could disguise it as a circuit or something as someone had said before. They already have many different types of IF/THEN statements programmed into the system, why not expand upon that in a way that is both user-friendly and powerful.
2009-06-22 19:40:00

Author:
BSprague
Posts: 2325


Not really, they could disguise it as a circuit or something as someone had said before. They already have many different types of IF/THEN statements programmed into the system, why not expand upon that in a way that is both user-friendly and powerful.

The logic systems that exist are hidden from the surface in the sense that you have to build the components from scratch. A tool that explicitly allows you to build electrical circuits and digital systems is actual far more advanced and far less intuitive than any other of the primitive tools in the game. It brings the complexity out of the shadows and into the light. The complexity of the system has always been hidden.

I'd happily use the tool if it was provided, don't get me wrong. I'd also happily use a scripting tool if they gave us one, but I very much doubt MM would consider that either fit with their marketing strategy.
2009-06-22 19:48:00

Author:
rtm223
Posts: 6497


The logic systems that exist are hidden from the surface in the sense that you have to build the components from scratch. A tool that explicitly allows you to build electrical circuits and digital systems is actual far more advanced and far less intuitive than any other of the primitive tools in the game. It brings the complexity out of the shadows and into the light. The complexity of the system has always been hidden.

I'd happily use the tool if it was provided, don't get me wrong. I'd also happily use a scripting tool if they gave us one, but I very much doubt MM would consider that either fit with their marketing strategy.

I think that even people without a computing background (young kids and just people in general), can figure out that if you want something to only happen when two or more things do at once, then you can't do it without an AND switch.

I can see it going under the Special objects section, and be as simple as tweaking the output and if both have to be active at the same time to work. Then you just connect two separate ON/OFF switches to it and drag the wire output to whatever you need it to be on.

MediaMolecule can add in powerful tools without losing the simplicity of their product. It's just having a user-friendly interface that doesn't shun or shrug off the needs of more advanced users. This would cut down drastically on some very complicated levels, because instead of having an AND set up and having the game have to load it, it can load an AND switch in a fraction of the time.
2009-06-22 20:41:00

Author:
BSprague
Posts: 2325


Not to mention easy to read symbolic logic and routable wiring. But yeah, MM may well see this as a no-go as it breaks their veneer of simplicity.

This is why I suggested it as a downloadable pack opposed to an update. People who don't download it will never see it. They will only enjoy the benefits of it in levels that they play online.
2009-06-23 00:13:00

Author:
dcf
Posts: 468


This is why I suggested it as a downloadable pack opposed to an update. People who don't download it will never see it. They will only enjoy the benefits of it in levels that they play online.

So basically in the same manner as the Creator Pack. Sounds like a good idea to me.
2009-06-23 00:31:00

Author:
BSprague
Posts: 2325


So we are talking about a gate object (or set of objects), that you could tweak to be an AND, or an OR, etc, and that's it? Meh, it'd be alright, but the majority of my control systems would still need creating physically. I can see how it'd be useful to many though.2009-06-23 13:19:00

Author:
rtm223
Posts: 6497


So we are talking about a gate object (or set of objects), that you could tweak to be an AND, or an OR, etc, and that's it? Meh, it'd be alright, but the majority of my control systems would still need creating physically. I can see how it'd be useful to many though.

We're talking about something that looks like a logic gate and is called a "gate switch" and is placed into the editor the same as a magnetic switch. It would be found in the switch menu.

The tweak menu would have the standard visible, inverted options, as well as the on/off, direction, 1 and speed settings. The final option would be the type of gate AND/OR/XOR/NOT. To help people, there should be a visual change to the appearance of the board when this option is tweaked.

A final option should be to allow a delay.

The key feature of the gate switch is that it becomes the only object in the game that allows multiple wires to be attached to it. (Probably only on/off wires though). It has a wire that can be attached to other things.

This therefore becomes the mainstream method for tying multiple inputs to an object. Advanced users might tie these together to make more complex circuits. However, even without making complex circuits, users would still have the advantage of being able to use these functions in a compact manner and without hurting their moving parts thermo.

Perhaps an additional item, which would work in a similar manner could be a latch type switch. Actually, I'd probably call it a 'switcher.' The switcher would only accept a single input but it would have numbered outputs. Only one is active at a time. Each time the switcher gets the 1 signal it cycles to the next output.

I think there's a number of these, relatively simple and easy to use, functions that could exist.

As a final item, to help people organize, we could have what was suggested a while ago to have a circuit board, which essentially would let you build a nested logic board to make custom gates. This would basically work similar to capturing and is just provides a size/organization advantage.
2009-06-23 13:59:00

Author:
dcf
Posts: 468


The closest comparisen of adding logic gates to LBP is when Wiremod was made for garrys mod.
(garrys mod is a half life 2 engine physics sandbox mod of which I used to be a bit of a pro)

This is the difference between nonwiremod and wiremod garrys mod.

Nonwiremod;

YouTube - Garry's Mod Rocket Building 101 ( Tutorial ) Putting thrusters on a explosive barrel tower.

YouTube - combine car tutorial Putting wheels on a plank.

Wiremod;

YouTube - Garrys Mod Mechanical Auto-Cannon Auto cannon with assembled munition.

YouTube - Garry's Mod engine with transmission Piston engine with transmission.

YouTube - Slapper 8 Engine GMOD Slapper 8 Engine.

YouTube - Gmod megastruct cannon video. Gmod megastruct cannon.


IF ANYTHING ELSE WATCH THAT MEGASTRUCT CANNON VIDEO IT IS RIDICULOUS


Ok, now, without A LOT more added to LBP it will never reach this level of complexity, but I think it will bring up the average quality of levels.

There was some backlash in the Gmod community, but that was only be people unwilling to learn how to use wiremod and jealous of the cool things other people were making.
2009-06-23 14:10:00

Author:
Asbestos101
Posts: 1114


Personally, I wouldn't like this to happen. I feel that part of the fun of LittleBigPlanet is the challenge of complicated switch mechanisms. Further simplifying the create tools would only detract from the enjoyment.2009-06-23 14:54:00

Author:
Killian
Posts: 2575


Perhaps an additional item, which would work in a similar manner could be a latch type switch. Actually, I'd probably call it a 'switcher.' The switcher would only accept a single input but it would have numbered outputs. Only one is active at a time. Each time the switcher gets the 1 signal it cycles to the next output.

I like this idea, but I think that it should also have a variation of the common relay as well. I remember I had a level where I needed to have something run to an emitter and a piston changing direction, and I had to put in around 45 relay switches. Needless to say, my thermometer skyrocketed.


Personally, I wouldn't like this to happen. I feel that part of the fun of LittleBigPlanet is the challenge of complicated switch mechanisms. Further simplifying the create tools would only detract from the enjoyment.

I'm looking at it from a different standpoint. The way I see it, this would allow for more thermometer space to be used for creating other things that are actually seen and enjoyed by the players, rather than complex logic that hogs up thermometer space.
2009-06-23 17:24:00

Author:
BSprague
Posts: 2325


Personally, I wouldn't like this to happen. I feel that part of the fun of LittleBigPlanet is the challenge of complicated switch mechanisms. Further simplifying the create tools would only detract from the enjoyment.

I definitely see your point here, and it seems that many agree with you. Aside from the lower thermo attraction, I think what interests me is that it would give those who don't understand logic gates a bit of help with creating better levels... at least, that's what I would hope it would do.

To be honest, I'm not someone who easily comprehends many of the logic gates out there or how to effectively make or use them. I still don't understand a few of them and how they work or what their applications are good for. I understand the basics, but I'm one of those who still use the ugly green dissolve in order to achieve a permanent switch that works (though it's always well out of sight ).

I'm no dummy either, I can have in depth conversations about many intricate things in the world... but I'm not a programmer and certainly don't think like one. As an artist and visual person, I simply have a tough time with logic gate concepts without either seeing them at work or having hands on experience. I know there are many others out there like me, who's creations and levels would have benefited early on in our development as creators.

I'm completely dumbfounded that the community has created these logic gates to begin with, and I hadn't even heard of them until playing the game to be honest. I seriously doubt the folks at Mm expected the community to be developing and using them either. Now that they are though, I think it would be a good idea for Mm to embrace and support the communities use and need of good logic gates. Especially for those new-comers, or just folks like me who don't have someone to sit us down and explain to us how to make some of them.

Again, I completely appreciate your point and it's a good one... but for those like me who have never heard of these switches until this point, it can be a bit frustrating at times when we want to achieve an effect similar to one we've seen and have no clue as to how it was done. I just think it might open up the creative possibilities to those who are more creative, and less technical thinkers.
2009-06-23 17:25:00

Author:
Rustbukkit
Posts: 1737


To be honest, I'm not someone who easily comprehends many of the logic gates out there or how to effectively make or use them. I still don't understand a few of them and how they work or what their applications are good for. I understand the basics, but I'm one of those who still use the ugly green dissolve in order to achieve a permanent switch that works (though it's always well out of sight :-)).

Having a tool that is a gate and having a gate made out of pistons (or transistors or a set of reed relays for that matter) will make no difference to your understanding of how to use them. Understanding the applications of them is a completely separate issue to the implementation. Also, in some ways a mechanical switch is far easier to unserstand - if you slow it down you can see how it works. With a ready made implementation you are literally looking at a magic box that you have to understand conceptually before it can be used. This is in no way meant to be patronising to anyone BTW. Also, everyone seems to use green dissolve for permenent switches...

As for MM not expecting the community to make them.... I couldn't disagree more, MM use them extensively in their levels (just look at the collector boss!!) and I'm sure the software engineers at MM fully expected engineers in the real world to take 1 look at a mag switch and a piston and put the two together. I think they deliberately didn't tell us about them until later and let the info ripple through the community online - if the game was full of electronics theory it would put people off, but let people discover it for themselves, or learn tricks from their friends and it seems a whole lot more appealing.

BTW, many technical fields require a large amount of creative thinking to excel - it's a common misconception. We just suck at making things pretty
2009-06-23 17:44:00

Author:
rtm223
Posts: 6497


Having a tool that is a gate and having a gate made out of pistons (or transistors or a set of reed relays for that matter) will make no difference to your understanding of how to use them. Understanding the applications of them is a completely separate issue to the implementation. Also, in some ways a mechanical switch is far easier to unserstand - if you slow it down you can see how it works. With a ready made implementation you are literally looking at a magic box that you have to understand conceptually before it can be used. This is in no way meant to be patronising to anyone BTW. Also, everyone seems to use green dissolve for permenent switches...

As for MM not expecting the community to make them.... I couldn't disagree more, MM use them extensively in their levels (just look at the collector boss!!) and I'm sure the software engineers at MM fully expected engineers in the real world to take 1 look at a mag switch and a piston and put the two together. I think they deliberately didn't tell us about them until later and let the info ripple through the community online - if the game was full of electronics theory it would put people off, but let people discover it for themselves, or learn tricks from their friends and it seems a whole lot more appealing.

BTW, many technical fields require a large amount of creative thinking to excel - it's a common misconception. We just suck at making things pretty

Excellent points! It wasn't until I was able to get my hands on some logic switches made in community levels that I myself was able to make the connection as to how to apply them in-game. I failed to mention that, but you are absolutely correct... good point. You are definitely not coming across as patronizing to anyone... just making good sense.

Your "magic box" explanation is spot on. That's how I regarded the various diagrams I saw here on the forums that members with knowledge of the switches used to illustrate their workings to other members who were trying to figure them out. I guess I would like to see them implemented still, knowing that if players needed to get a better understanding of what they do they could still have access to the ones made in community levels offered as prizes or come to forums like this to have it explained and get the help they need. Even better, Mm could offer them with an in-depth tutorial as a mini-pack. There were many things left out in their tutorials from the game that left many people confused.

I think Mm may have expected some members of the community to create their own Logic systems, but I don't think they would have expected the average player or even the majority of players to go that route though. As you said... Engineers, absolutely. It is for this reason alone that I fell in love with the community and the Play, Create, Share mind set of the game.

If it wasn't for Engineers and artists coming together, this game and it's community wouldn't have succeeded and be nearly as fun and intriguing as it is.

Also... glad to hear I'm not the only one still using dissolve in this way.

Cheers!
2009-06-23 18:29:00

Author:
Rustbukkit
Posts: 1737


Glad I'm not being patronising, I just didn't want people to read it as "I understand it but you don't, nah n-nah n-nah nah!", or something along those lines.

An advantage of the magic box approach (the technical term is "black box", but I have no idea why) is that you would be able to match the diagrams on forums to what you create in create mode, so there is that. But conceptual understanding is still required, and having the right mindset helps a lot with that. But then a lot of players now have the basic concepts down, so releasing a pack at this time wouldn't be so bad.

I'm still not convinced about the expectations of MM, they would have expected the engineers to share ideas and as BSprague says, the average player can understand the use for basic AND and OR switches so IDK. Not much point in trying to second guess them though.


BTW, BSprague, what exactly are you meaning by a relay, because unless you are dealing with speed, a relay can be implemented in LBP using an AND gate...?
2009-06-23 18:59:00

Author:
rtm223
Posts: 6497


As an additional point to the issue of complexity:

How many times have you seen beginners ask how to put two wires on a single piston, light, etc? I've seen it plenty and I'm sure other people have as well. I've also seen numerous times where you explain how to do it and people's eyes glaze over (or at least the psn version of it). This tells me that it's something many people in the community want to be able to do.

I think it's fair to say that many people can understand conceptually how to use these things/why they should be used. However, making them and keeping track of the inputs and outputs is challenging. It's not intuitive or obvious to non-engineers. Even for engineers it can be difficult to keep your logic organized.

This argument doesn't even acknowledge my major reasons for the suggestion: lower thermo and cleaner designs. (Also, back when I first suggested this the capture bug would kill wires between separate objects so that was another motivation.)

Right now I'm working on a standard enemy. The type with a single brain that moves about on the wheel monster piece. I'd love to have an AND switch on the guy. However, putting it on means shrinking it down and hoping it doesn't break or get messed up by the nested movement physics. Alternatively, I can make it a two part creature, with the logic hidden off-screen. However, having a gate switch would be infinitely cleaner. It would allow me to give out the enemy as a collectable and people could pop it into their levels without any instructions.

Therefore, it would seem to me that such a pack would bring up level quality by making things accessible to all players and freeing up more thermo for those who could already do such things mechanically.
2009-06-23 19:12:00

Author:
dcf
Posts: 468


BTW, BSprague, what exactly are you meaning by a relay, because unless you are dealing with speed, a relay can be implemented in LBP using an AND gate...?

When I say relay, I mean an input that results in two different types of outputs (ex one-shot and direction). It's easy to implement, but if you need 30+ relay switches, the thermometer tends to take a substantial performance hit.


Right now I'm working on a standard enemy. The type with a single brain that moves about on the wheel monster piece. I'd love to have an AND switch on the guy. However, putting it on means shrinking it down and hoping it doesn't break or get messed up by the nested movement physics. Alternatively, I can make it a two part creature, with the logic hidden off-screen. However, having a gate switch would be infinitely cleaner. It would allow me to give out the enemy as a collectable and people could pop it into their levels without any instructions.

This is another very important point that I'm surprised nobody has mentioned in detail yet. Spawning fairly complicated enemies dynamically is a terribly complex task. If the enemy isn't spawning in the exact same spot every time, you have to make sure that your logic gates spawn in a position that they won't interfere with anything else in the level, or the creature won't even spawn. Being able to invisibly place logic gates directly onto the enemy would be an enormously easier solution.
2009-06-23 19:18:00

Author:
BSprague
Posts: 2325


i think the technicality would be good for ppl would would like to become level designers making it to simple will only make it harder for them in the long run also challenges are fun =) wats bad about melding uer creativity and tech smarts together it can only make a better end product2009-06-23 19:24:00

Author:
jemc
Posts: 19


A further problem with provided gates is propogation delay. At the moment, anyone using a physical gating system can see the propogation of signals (parts move). Because they can see the parts moving, they can actually see (and correct) race hazards without having to understand the theory of them in an intuitive manner.

With the proposed system propogation delay would almost certainly still exist (otherwise it would break the existing swithc model and make little sense) but the only real way to deal with race hazards would be at a theoretical design level. You say people give you blank stares when you explain mehanical AND gates to them. Try teaching the average gamer strategies for race hazard prevention as a purely theoretical issue. And if making logic becomes this easy, then far more people are going to hit this problem, because they will be using more logic.

Look, I'm not saying it's a bad idea and I'm not saying I wouldn't like to see it, but I can see many ways in which it could actually make life harder for many people.
2009-06-24 23:30:00

Author:
rtm223
Posts: 6497


A further problem with provided gates is propogation delay. At the moment, anyone using a physical gating system can see the propogation of signals (parts move). Because they can see the parts moving, they can actually see (and correct) race hazards without having to understand the theory of them in an intuitive manner.

With the proposed system propogation delay would almost certainly still exist (otherwise it would break the existing swithc model and make little sense) but the only real way to deal with race hazards would be at a theoretical design level. You say people give you blank stares when you explain mehanical AND gates to them. Try teaching the average gamer strategies for race hazard prevention as a purely theoretical issue. And if making logic becomes this easy, then far more people are going to hit this problem, because they will be using more logic.

Look, I'm not saying it's a bad idea and I'm not saying I wouldn't like to see it, but I can see many ways in which it could actually make life harder for many people.

You would only get delays if you nested an enormous number of these things together. It doesn't take the ps3 very long to do an AND operation. Far less time than the 0.1s mechanical delay.
2009-06-24 23:42:00

Author:
dcf
Posts: 468


I know the computational impact, my point is that EVERYTHING in the game is linked into that whole 0.1s thing. I would expect these gate devices to be as well, especially if they are using the same wires as everything else.

And even if it isn't implemented this way and your network of logic propogates through instantaneously (or as close as), the gates still have to be calculated in some order and therefore the propogation effect still exists. The only difference is that now you definately cannot see the propogation, no matter what you do, and your race hazards would be even harder to understand.
2009-06-25 00:04:00

Author:
rtm223
Posts: 6497


I know the computational impact, my point is that EVERYTHING in the game is linked into that whole 0.1s thing. I would expect these gate devices to be as well, especially if they are using the same wires as everything else.

And even if it isn't implemented this way and your network of logic propogates through instantaneously (or as close as), the gates still have to be calculated in some order and therefore the propogation effect still exists. The only difference is that now you definately cannot see the propogation, no matter what you do, and your race hazards would be even harder to understand.

I got to really disagree here. It's going to be so close to instantaneous that there will be no impact at all. It's only with mechanical logic gates with the 0.1 second timings that one runs into delay errors.
2009-06-25 02:16:00

Author:
dcf
Posts: 468


I'm coming into the discussion a bit late here, but if I'm understanding this correctly, we are talking about the length of time it takes for a complex gate to complete its actions.

So, as far as my understanding of LittleBigPlanet is concerned, if you have a mess of AND, OR, XOR, NOT, STATE, etc gates connected in the current (mechanical) set up, there will be a delay, one that will affect gameplay if the logic gate is complex enough. The 0.1 speed is for an entire cycle, meaning for it to move one direction, it is actually 0.05, if we are to believe LittleBigPlanet's system. In an oversimplified example, if you had a pyramid of AND gates:


x
xx
xxxx
xxxxxx
xxxxxxxx
xxxxxxxxxx

with each one having one of two inputs already activated, and the other input attached to the previous AND gate to the right, with the furthest on the left linking to the one furthest on the right on the next row up, etc. The setup of x's above, each x representing an AND gate, would take approximately 1.55 seconds to reach the top, which is actually a substantial delay that increases exponentially with more layers of complexity. This exact same setup placed into an array of MediaMolecule programmed items would most likely happen instantaneously. Hopefully that settles it, as I do not think that an item programmed by MediaMolecule would actually have to go through all of the steps that a mechanical object has to go through to reach its goal.
2009-06-25 02:47:00

Author:
BSprague
Posts: 2325


I think this would definitely improve the quality of levels. I personally wouldn't use it, because i'm not a technical kind of person. But other people would definitely benefit from this! I would love to see this plan put into action.2009-06-25 03:19:00

Author:
Sage
Posts: 2068


It's only with mechanical logic gates with the 0.1 second timings that one runs into delay errors. Source?


Hopefully that settles it, as I do not think that an item programmed by MediaMolecule would actually have to go through all of the steps that a mechanical object has to go through to reach its goal.
Sadly, it's not as simple as that. Delay effects occur in real world electronic circuits, no matter what speed they are running at. Whether the components have fast propogation or slow propagation there is still a propogation time that is non-zero. One gate has to process its inputs into outputs before the next one in the chain can process its inputs. This leads to timing issues and some quite subtle effects and design constraints known as race hazards / race conditions. They are a pain to understand and account for. In the proposed system there would be no way to understand them intuitively, as there currently is due to the moving parts. You'd just have a magic box that doesn't do what you want/expect and no visual clue as to why.

ZOMG!!11!! logic craet pk GLITCH!!11!! Lulz!

It has nothing to do with the processing speed, it's a fundamental issue with logic design and a perfect example of why being able to see moving parts makes the system more accessible.

Also, not exactly a downside but they would have to introduce specific delays so it would make sense to match these up to the 0.1s model. If it was all calculated as quickly as possible, a loopback could potentially kill a processor core and knacker the engine. Contrived example where setting the input to 1 would result in the system never settling:

output <= input AND NOT(output)

.

|-----|
input ----- | |
| AND |-------------- output
|--not--| | |
| |-----| |
| |
|-------------------

.


I'm not just naysaying here btw, it's just that the whole thing is way less simple than it seems on the surface.
2009-06-25 10:25:00

Author:
rtm223
Posts: 6497


output <= input AND NOT(output)

.

|-----|
input ----- | |
| AND |-------------- output
|--not--| | |
| |-----| |
| |
|-------------------

.

If I'm understanding that right, one input is always active and the other NOT is active when the output isn't. So then at the start of the cycle, both inputs would be true, because the output isn't active yet. This would cause the output to become true, making the NOT false, and therefore inactive, correct? In that case it would simply shut off, not jump into an infinite loop. I'm not sure if it is possible to do in LittleBigPlanet. For example, try making a bomb that shoots out a bomb that shoots out a bomb that shoots out a bomb, etc. You'll realize that you have to nest each one inside the previous one, and it will only go as far as you have the patience to set up. You can't simply make it a never-ending setup, LittleBigPlanet just doesn't work like that. And I understand the 0.1 mechanical delay thing, but it could be applied to the whole system, so that instead of every action taking 0.1, it would recognize the complex logic at work and calculate it all, while maintaining that 0.1 second for syncronization's sake.

And there still could be a visual cue, like each wire is set up in a row, and if it is active, a check appears next to it. When all are checked, a green light appears and the AND gate fires. That is one of the many ways a visual cue could be used to show off how an AND gate in LittleBigPlanet works. Now I just wish there was an option to show wires in play mode somewhere under the lighting section that toggled them all on or off for demonstrational purposes.
2009-06-25 12:40:00

Author:
BSprague
Posts: 2325


An explanation of that circuit as it changes with time:



.
Columns are time, input, output, NOT(output)


| t || i | o | !o |
|---||---|---|----|
| 0 || 0 | 0 | 1 |
| 1 || 0 | 0 | 1 |
| 2 || 0 | 0 | 1 | Stable until input goes to 1
| 3 || 1 | 0 | 1 |
| 4 || 1 | 1 | 1 | Input AND NOT(output) = TRUE
| 5 || 1 | 1 | 0 | NOT(output) = FALSE
| 6 || 1 | 0 | 0 | Input AND NOT(output) = FALSE
| 7 || 1 | 0 | 1 | NOT(output) = TRUE
| 8 || 1 | 1 | 1 | Same as state 4.

.


Note that at time 4 and 8 the state is the same - therefore the system will oscillate through states 4-7 until input drops to FALSE again. If you try to process this accurately all at once, the function will never end and the CPU core will lock down. There is no neat solution to that, really - you can bail after a certain number iterations, but that's a very sloppy solution. It should also be clear that the interval between each time increment is irrelevent - it can be as long or as short as you like.

You example of nested emitters is correct, but doesn't apply to loopbacks on wired systems. It is perfectly possible to wire up this system in LBP with mechanical gates - I currently use a similar, stable system for P-switches. I can't see why it wouldn't be possible to wire up a supplied gate object in this way. You wouldn't want to create an oscillator like this in LBP (it's a contrived example) but you can. The fact that the diagram alone isn't enough to indicate the unstable nature supports my statement that it's difficult to know what's going on when all you have is a diagram (or a set of functional blocks wired up).



so that instead of every action taking 0.1, it would recognize the complex logic at work and calculate it all, while maintaining that 0.1 second for syncronization's sake. Assuming the complex logic has no loopbacks in it.


And there still could be a visual cue, like each wire is set up in a row, and if it is active, a check appears next to it. When all are checked, a green light appears and the AND gate fires.
Yes I thought of this, the gates would likely have a light built into them just like the mag switches. The problem here is you want all the logic to be caluclated at once, so you will just see inputs and outputs to the entire network, no intermediate / internal signals. You can still get race conditions and problems due to delay effects even if there are no loopbacks and would have to understand the theory to deal with it. If you can't see intermediate signals changing then you would be back at the magic box analogy. So, you slow down each gate to propogate in 0.1 seconds as I suggested earlier - I wouldn't fancy following even a moderate network of logic gates as flashing light signals, switching at 0.1s, in real time.
2009-06-25 13:12:00

Author:
rtm223
Posts: 6497


The main point here is that the speed of the gates is an advantage of the suggestion. It's a disadvantage of the current mechanisms.2009-06-25 14:28:00

Author:
dcf
Posts: 468


Except it isn't. Speeding up the gates to be faster than the 0.1s synching point is an absolute nightmare for various practical reasons as I have described above.

The only way around it realistically is have 0.1 second registers and create a pipeline. This would require the player to understand the relevent design concepts so would be bad. Alternatively you ban loopbacks, which means that some wires can't be connected to some gates, which breaks the existing model of wiring, may be confusing for some and extremely limiting to others. More limiting than the existing system. It also wouldn't solve the issue of race hazards in "1-way" logic.

Keeping it slow is a far more practical option.
2009-06-25 14:43:00

Author:
rtm223
Posts: 6497


...but I know this...

A logic gate creator pack is a must... I'm like a lot of posters in this thread before the topic went all Einstein Theoretical... It would be a great boon for LBP in general. Those who understand gates already and have built their own would have a new toy, in which to; theorize, scavenge, deconstruct, experiment, and generally use in ways that nobody appreciatively foresaw. The averagely informed creator would have one less thing to fret over... rather than having to entirely comprehend logic he would have a tool (and don't forget those cute Mm mini-tutorials) that would allow maximum effect with a minimum of tinkering outside of some good ol fashioned trial and error. For those creators who have no interest in any understanding of logic gates... yet want to emulate something they've seen... well now these pursuits would be attainable. And those who didn't want to be bothered... well, wouldn't be bothered. A Mm gate packs would not benefit everyone... and a bad level would still be a bad level... but generally speaking It would be a 'smart tool' to have access to as a creator.

A Logic pack that accomplishes all this and eases demands of the thermometer... I'm all in. In fact, I demand it! Now what are you gonna do with all your newly found 'free' time, RTM?
2009-06-25 15:42:00

Author:
Gravel
Posts: 1308


rtm:

I still say that you are fundamentally incorrect with this. Not because you don't have a good grasp of electrical engineering but because you are misapplying it.

LBP does not use real world physics. The assumption you are making here is that somehow LBP code will create a virtual computer circuit and simulate it. Very simply put, that's not what is going to happen.

All that's going to happen is the game will run a computer function. An incredibly basic one at that. It's not a hardware simulation. It's a software algorithm.

I know you're looking at this from a hardware perspective and your concerns would be correct if the game ran a hardware simulation. However these points simply don't apply to the incredibly simple software functions that these logic gates would get translated into. If I can do it on a 10 year old computer with a billion times the variables using an excel spreadsheet, the ps3 isn't going to have a problem.

The thing you're objecting to seems to be people creating recursion loops by wiring something to itself. This is a very simple limitation that can be placed on the tool to stop this. Excel does the same thing. If you try to create circular logic it stops you and tells you that you can't do that. I know this is a powerful feature in real logic gates but that also leads to all the real world complexities you describe.

There are things that can be done with real world physics that can't be done with LBP physics and the reverse is also true. The same would be true with LBP logic gates. Probably the two limitations I would expect to see placed on these things would be no circular logic and some sort of nesting limitation, implemented through the thermometer, to prevent slow-down from occurring.
2009-06-25 15:45:00

Author:
dcf
Posts: 468


I'm actually looking at this from the POV of a software engineer considering the implications of developing a system to simulate digital logic gates in exactly the way you describe. "Just running a computer function" to porcess logic is a hell of a lot more complex than actually running the real world logic. For example, the circuit I described is perfectly reasonable in hardware. In software, you cannot run that as fast as possible without a lot of implications. It's the running as fast as possible I have an issue with. This will impact ANY computer, it's a simple limitation of calculating logic networks in real time.

I know excel prevents looped logic and this could be done in LBP, or you could limit nesting. Rememeber that Excel is not really capable of realtime simulation. My point is that applying similar limits to a realtime simulation means thar the logic pack would be a step backwards from the current system, because it would be so limiting. A better limitation IMO is the timing limitation. This solves the problems of looping in a far neater manner. You stay at the same speeds you were before but still get many of the benefits and you don't lose the ability to do things that you can do now. It also means that you aren't putting limitations on the user design for cryptic reasons, so this would certainly help with being intuitive.

Nothing is going to prevent race hazards so that's an issue regardless. The only thing to hope is that the people who would struggle to comprehend them would stick to simpler systems.

As I've said several times through this thread, I'm not against the idea in itself, there are just a lot of practical implementations to it.

And gravel, I'll be using my free time to answer all the threads entitled ZOMG!!11!! logic craet pk GLITCH!!11!!!11!!
2009-06-25 16:22:00

Author:
rtm223
Posts: 6497


rtm:

What I'm really pointing out here is that you are making the assumption that it will be implemented incorrectly.

Clearly interface is important. Designing good interfaces is not easy. However, a good interface will make this suggestion not only easy to use for the average player but implicitly prevent these problems.

I'm certainly not suggesting that Mm include the industrial transistor gate simulators used by the computer industry to design computer chips. What I'm suggesting is that Mm gives users some basic switches so creators can more readily make cleaner mechanisms.

I will update the OP shortly with a suggested implementation.
2009-06-25 16:57:00

Author:
dcf
Posts: 468


I'll see what your suggested implementation is and post up a counter one if I feel like it. We can always resort to just kicking the *bleep* out of each other in a carpark to resolve this if necessary!

Edit, so it looks like DCF is being slow today, my guess is he's drawing pictures of his interface? Who knows. I've just drafted my proposal for how such a system could be implemented, in such a way that it can be practically designed and implemented from an engineering POV and also should be very easy to use. It has no downsides VS the current mechanical system and would not be limiting for advanced users. I'm pretty sure I managed to squeeze in all the features that people have suggested (I think).

My Proposal

Basic Stuff
The proposal consists of a set of primitive devices (that can just be slapped down in a level and used "out of the box") and a more complex circuit device. I will cover the primitives first then move on to the circuit.
Primitive devices will take on/off signals as inputs and output whatever signal they like. Potentially they could take direction inputs, but this doesn't really make sense.
Each of the primative devices I describe here will take 0.1s to propogate (i.e when an input changes, the output will update 0.1s later).
The devices are designed to be placed on objects and wired up in the same way you would existing tools, except that they will have an input and an output and in some cases multiple inputs.
Each device will only have a single output (see converters below) and the output state will be indicated with a light.
For the basic gates, standard symbols will be used.
All devices will have tweakable visibility.


Gates:

AND - taking multiple inputs
OR - taking multiple inputs
XOR - taking multiple inputs
NOT - taking single input

Multiple inputs should be user defined (i.e as many as you like)

Latches:
RS - Set-reset, with option to favour set or reset if both are held high
T - toggle, will change output state when input goes from low to high
P - The permenant switch, this should have an option to reset it in case you trigger it in create mode!

Converters:
A single device to change from any signal type to any other signal type (input and output tweakable)
Included so that multiple inputs can be pumped out of a single gate without the multiple wires getting confusing.
These will also propogate in 0.1s, for consistancy.
By setting both input and output to the same signal you can create a D-type latch.


Timers:
Various timers that can stay on for t seconds, or trigger a one shot after t seconds etc. t would be expressed in increments of 0.1s. I couldn't really be bothered to think this one through, but these would be an exception to the 0.1s rule.

Note on wiring
The above solution still allows for loopbacks, you can wire anything to anything else in the network. gates can wire to other gates, gates can wire to themselves etc. The downside is that the networks will run slowly (though no more slowly than currently)

Circuit device:
Is a little box which takes n inputs and m outputs (n and m user defined). Inside the user is allowed to create a circuit from the primitive devices above. The following limitations are in place:

All wiring must be 1-way, there can be no loops
All inputs must be connected to something
All outputs must be wired to something inside the circuit.
The timers and the D-type latch may not be used.

Behaviour of the circuit device:

Wiring within the circuit device will be routable to aid design
The circuit device will calculate it's entire contents within 0.1s
A circuit capture tool will be provided to allow you to debug your circuit with slow propogation times, then move it into the efficient circuit device
Whilst loopbacks will not be available inside the circuit, circuits may loop back to themselves externally



Summary
The primitive devices will allow a beginner user to throw down a gate or two and wire them up, with no need to understand the mechanical processes currently employed. Thermo and development time will be improved, as will the compactness of creatures that require logic. The logic will run around as fast as it currently does, so there is no loss in this proposal, compared to the existing system.

The circuit device will allow intermediate users to create a logic network and have it compact and switching very fast - much faster than the existing methods, with only small downsides of not being able to loopback.

Advanced users will be able to use multiple circuits to create Register Transfer Level systems, using a 0.1s clock pulse and so will be able to create pipelined systems.


I recon this has only benefits and no downsides to the existing mechanical implementations.
2009-06-25 17:05:00

Author:
rtm223
Posts: 6497


Okay, my idea for an implementation has been edited into the original post. Please note that I only show AND/OR/XOR switches. Others can certainly be added later. The key things that I'm looking for in the solution are:

1) Ease of use.
2) Speed.
3) Low thermo.
2009-06-25 20:26:00

Author:
dcf
Posts: 468


Pretty similar then eh. Great minds think alike, although you could blame the fact that we were running off al the same info in this thread.

I really like the way you laid out the circuit builder, you could even have it so the editor won't let you move a wire to the left the gate it's coming out of - you wouldn't even need to explain it then! I was thinking of it being just haphazard!

Adding implied delay in each gate outside of the circuit would allow you to have no restrictions on wires though (gates can wire to each other and themselves etc)
2009-06-25 21:45:00

Author:
rtm223
Posts: 6497


Both proposals are great and virtually the same

I would love a logic gate pack and these sound like it would be easy to make complicated logic because it will be a uniform setup and all in a nice compact environment
2009-06-25 21:47:00

Author:
dorien
Posts: 2767


I'm happy to combine things to make the best possible suggestion.

I should also mention something I'd like feedback on. Currently I have it written that logic switches can't be wired together. This could be made more intuitive by adding an additional behavior digital logic (maybe called electricity with a lightning symbol). Only logic switches would accept this new behavior. However, logic switches wouldn't have this as an option in their tweak menu. This would implicitly prevent them from being wired together (except in circuit board mode). This would also enable the delay switch to work intuitively simply by allowing this as a behavior in the tweak menu. In circuit board mode, the logic gates would automatically be set to electricity and it couldn't be tweaked.

I don't know if the extra clarity is worth the addition of a new behavior type for switches though. Ultimately I left it out of the implementation proposal.
2009-06-26 02:27:00

Author:
dcf
Posts: 468


DCF, if you make the gates have an implicit 0.1s propogation time outside of the circuit board (as per my proposal), then restrictions on wiring become unnecessary because each gate will only be able to update once every 0.1s anyway, so calculation of loops would be stable and stretched out over time. Only restriction is that all signals feeding into gates must be on / off type signals and the left-right restriction inside the circuit.2009-06-26 08:40:00

Author:
rtm223
Posts: 6497


DCF, if you make the gates have an implicit 0.1s propogation time outside of the circuit board (as per my proposal), then restrictions on wiring become unnecessary because each gate will only be able to update once every 0.1s anyway, so calculation of loops would be stable and stretched out over time. Only restriction is that all signals feeding into gates must be on / off type signals and the left-right restriction inside the circuit.

This is true, however it also limits the use by failing to solve the speed issue. The idea of an adjustable delay that goes from 0.1 seconds and up is a sound one. However, it would be really nice to be able to have players with little logic experience be able to just plot an AND gate into their level and not worry about a delay.

This is why I'm suggesting the delay as a separate component. Also, because people may want to use the delay outside of logic switches. In fact, I can't remember where I heard it, but supposedly a delay relay is one of the things Mm currently has in the pipeline.
2009-06-26 12:43:00

Author:
dcf
Posts: 468


The speed issue is solved in the circuit device. A player with little logic experience dropping an AND gate would not even consider the delay, I think. I can't think of an application where you would want a single AND gate and the 0.1 second delay is a major problem. It's what we have now and it seems to be fine for simple applications...2009-06-26 12:54:00

Author:
rtm223
Posts: 6497


The speed issue is solved in the circuit device. A player with little logic experience dropping an AND gate would not even consider the delay, I think. I can't think of an application where you would want a single AND gate and the 0.1 second delay is a major problem. It's what we have now and it seems to be fine for simple applications...
I think I've suggested this before, but why not calculate the 0.1 second delay globally, so the entire circuit updates in that time, not just a single gate. I think that speed gains are the major thing that everyone wants out of this, in addition to simplicity.
2009-06-26 13:18:00

Author:
BSprague
Posts: 2325


Because that limits applications by limiting the wiring for processing reasons, as I have tried to explain.

My proposal allows for an entire logic network triggering in 0.1s, by using the circuit device as I outlined. You do get the speed increases if you need them. I don't really get why the 0.1s synchronisation is a major deal, it is how LBP works and it exists as a feature of all of the existing switches etc (except the paintball switch, most of the time) and is how things works atm.

edit - it's probably worth noting that I wouldn't expect the technical details of timing to be part of the tutorial, further than on the circuit they could say that it goes really fast. The more advanced users that will want to do more advanced tasks would notice the effect anyway.

further edit - some examples of applications with the timing I suggest:
Simple AND gate application. Slap down a gate & wire it up. Takes 0.1s to switch - is exactly the same as mechanical gates.
Simple network ( a AND (b OR c) ). Slap down 2 gates & wire them. Takes 0.2s to switch - is exactly the same as mechanical gates.
Complex network with many many gates. Put it in the circuit device. Switches in 0.1s. Is much much faster than the existing mechanical gates
A processor core, with working ALU, PC and local registers, that could process a stored program. Has a throughput of 10Hz (i.e 1 instruction processed every 0.1 seconds).


Plus of course the general thermo and neatness benefits in all of them. And you don't have the limiting factor of chaining them through mechanical parts if outside of the circuit device, which would need to be explained to the players, without really explaining why...
2009-06-26 13:26:00

Author:
rtm223
Posts: 6497


I don't use this logic stuff, but I always have a lot of problems (I still haven't done my first proper level since day 1), so if this stuff can help, and so it seems, I'm with it.2009-06-26 14:19:00

Author:
OmegaSlayer
Posts: 5112


dcf, I'm in total agreement with this concept.

Another thing to consider is efficient use of one's time, which the concept would provide this benefit. Any concept that makes sense, and could save the creator some time, is a neccessity in my book. We already spend months on levels, with no compensation other than a rating, heart, positive comment, or token recognition.

Regarding timing, I see the increments as being a major obstacle. Presently we can go from .1s to .2s, and so on, as you stated, but there have been personal applications where I needed to go from .1s to .11s, and being unable to do so prevented me from implementing what I truly desired. I believe an increase in resolution is a neccessity as well, even if the fastest time is .1s. 10ms increments in timing would go far to resolve a lot of timing issues.

Rick
2009-06-26 19:52:00

Author:
RickRock_777
Posts: 1567


out of curiousity Rick, what was the application where 0.01s increments were vital?

I'm not doubting you had one, but I was working on the basis that any synchronous system will theoretically work at any clock speed, the only real issue to LBP is how fast it goes and thus affects the user. On this basis I can't see an application for 0.01s timings because we can't see things happen that fast! If you have an example that blows my whole theory out of the water then it would be good to hear (for some reason I actully like to be proven wrong )
2009-06-26 20:03:00

Author:
rtm223
Posts: 6497


out of curiousity Rick, what was the application where 0.01s increments were vital?

I'm not doubting you had one, but I was working on the basis that any synchronous system will theoretically work at any clock speed, the only real issue to LBP is how fast it goes and thus affects the user. On this basis I can't see an application for 0.01s timings because we can't see things happen that fast! If you have an example that blows my whole theory out of the water then it would be good to hear (for some reason I actully like to be proven wrong )

Hi rtm223. I'm referring to the Plasma Generator I designed for my level Takken. Initially I wanted to emit 100 Plasma rings with lifespans of .05s, spaced 10ms apart with 1 ring dissapearing in a specified location and the next appearing 10ms later and placed slightly above the previous ring. So, each emitted ring (or object) would overlap a space previously occupied by an object. I tried this with .1s intervals, but the net result did not have the fluidity I preferred and it significantly increased the amount of time it took to complete 1 full cycle. I resorted to decreasing the number of rings emitted to 10, and using .2s intervals. I guess this would be an acceptable compromise for most, but it's not what I wanted.

Using some analogies for clarity:
1. If I were to create a wave effect for a level that had water, my desire would be for the movement to appear as fluid-like as possible (near perfection, seamless to the eye), which cannot be accomplished with the present timimg limitations.
2. Also, consider the default refresh rate of a typical monitor, which is 60 cycles per second, and compare that to a refresh rate of 10 cycles per second. At 10 cycles per second, the brain is capable of seeing the scan lines as the image is refreshed, and the difference between the two refresh rates is very noticeable.

Rick
2009-06-26 23:05:00

Author:
RickRock_777
Posts: 1567


Hey Rick, just wanted to point something out... the human eye can only see a "refresh rate" of about 24/second. Granted, 10 is still nowhere near 24, but they could do well with even a .05 interval, instead of a .01 interval2009-06-27 00:10:00

Author:
comphermc
Posts: 5338


Hey Rick, just wanted to point something out... the human eye can only see a "refresh rate" of about 24/second. Granted, 10 is still nowhere near 24, but they could do well with even a .05 interval, instead of a .01 interval

The human eye can pick up delays on the order of ms (1/1000th). 24 is the number from video that is sufficient to create the illusion of continuous movement. Human eyes can however tell that there is a delay between, let's say, you press R1 to grab a grab switch and the mechanism engages 1/10th of a second later.
2009-06-27 02:26:00

Author:
dcf
Posts: 468


Hey Rick, just wanted to point something out... the human eye can only see a "refresh rate" of about 24/second. Granted, 10 is still nowhere near 24, but they could do well with even a .05 interval, instead of a .01 interval

24 is definitely better than 10 comphermc.

In my earlier post above, I was taking into consideration the optic nerve being capable of transferring data at a rate of 7Mbits per second, and the brain having the capability of processing a full image in 34ms. The brain will also divert processing power to scrutinize image anomalies, which results in a significantly higher processing rate, as the non-critical data is discarded. Obviously this rate will vary, as it is dependent on the amount of data representing the anomaly. In our case, the anomaly could be a transient spectral spike or spectral void.

So, in my humble opinion:blush:, any change in timing resolution should be at least 1 order of magnitude, to ensure a more seamless effect. I guess that mindset has been instilled over many years of designing products that exceed a customer's specification--erroring on the side of caution so to speak.

Rick
2009-06-27 05:33:00

Author:
RickRock_777
Posts: 1567


Makes sense to err on the side of caution. I agree that being able to further tweak timing would be nice, but I don't see MM working on a patch for this.

Related: would allowing a .01 second timing interval slow the system down? It seems like there are enough things to process as it is without having to refresh at ten times the rate. I'm no computer/programming expert, so I'm grabbing in the dark here. I do understand that if you decrease the time step, then the game would have to run the iteration to check for logic/triggers at ten times the current rate. Would this cause a lag or slowdown, or are these iterations so minuscule by comparison to all the other calculations going on?

Edit: let me guess...Engineer?
Edit2: Your public profile tells me so. It appears that we share a few interests, although I'm no Engineer. I was studying Engineering for a while, but switched to just plain Math and Physics...teaching, ftw.
2009-06-27 05:56:00

Author:
comphermc
Posts: 5338


A very good question comphermc!

Since I didn't write the code, I can't give a definitve answer, and would be speculating.

However, I can say a common programming practice, used to avoid such issues, is the use of a technique referred to as multi-threading. I'm 99.5% confident Mm's Programmers used this technique, as it is a standard.

In basic terms, each thread performs a specific action/actions for a designated period of time, then it relinquishes control to the next thread in the queue. The time that a thread is waiting is referred to as Sleep time. Since Sleep times are determined by a thread's priority ranking for a given action, Sleep times can be adjusted to optimize an application's performance.

Rick
2009-06-27 06:53:00

Author:
RickRock_777
Posts: 1567


Rick, so you are looking at an increase in sychronisation for the entire system. Effectively speeding up the heartbeat of the LBP engine by a factor of 10. Fair enough, I can see many visual applications that would benefit from this. With regards to DCFs example of a grabswitch delay being visible... It's true, I can't argue with the fact. I just can't think of any time when the individual 0.1s delays on switches etc ruin gameplay, you kinda have to be looking out for it to notice that IMO. But maybe thats just me?


Yeah, so most of this post is a big ramble that isn't gonna interest most people, so I thought I would summarise it Feel free to skip to the end to get the jist


The following is largely based upon speculation, Not having access to MMs code and bearing in mind I'm used to different achitectures and OS than the PS3. I've made about 20 assumptions / guesses below and you know what they say about assumptions

We currently see the phsics engine lag under certain situations (even if we discount network lag), so the engine is struggling. Upping the heartbeat by x10 would multiply the procesor overhead would need to increase greatly. Imagine 10x as many emitter collision calculations, magswitches, proxswitches, etc in your level and what that might do to your thermo. I'd also imagine that collision detection would be upped, based upon the fact that if you are going fast enough that you can go through walls (the movement of my ordered inputs tool relies on being synced with the 10Hz heartbeat else it does just that). My guess is that a large amount of the engine is synced into the 0.1s heartbeat, and it's mostly the visuals that aren't. That's a fair bit more processor overhead to find in a system that is already struggling, and that will result in a direct hit on thermo.

Not to mention breaking existing levels - if you have a piston timer, that triggers after 0.6s and then they up the heartbeat. You might find that it now triggers a 0.52s. Not much of a deal unless you've synced stuff along the way and now it's all out of sync with each other.

But, ignore the last point and assume its a purely processing issue. I'd say with 100% confidence LBP is multithreaded, an app like this would be rediculous to write without, and it's a multi-core system with the cores all working together, so it would need to be. It's still lagging under certain conditions though, so an increase in calculations could not be saved by something that already exists.

What could be done is to increase the CPU useage. I think I read somewhere that Uncharted 2 was going to be the first game to use all 6 cores. This implies that LBP doesn't... So the game could be enhanced to utilise the full processing power of the Cell. Would this be an easy change? I don't know. It could be a simple as setting some register bits and letting the scheduler do it's thing, but I very much doubt it. It would probably be a major effort to re-optimise it to 6 cores.

Also, Multiprocessing does give a perfomance increase but scheduling and sychronisation overheads are also significant so it doesn't give you as much as you might think. If I recall correctly the jump from 1 to 2 cores gives around a 70% increase in performance, but once you take the step from 8-16 you can actually lose performance, even if the application is optimised.

-------------------------------

Summary
Basically, I'm not against the idea of increasing the heartbeat, but it's another thing that would be nice but may well not be practical. In simple terms, the computational overhead on a system that already struggles would be increased and that surplus would need to be found from somewhere. Now I think that might be possible but it's probably a big old job to restructure the engine for it. If not you are looking at a reduction in total thermo available.

And I can think of common examples where the upping of a heartbeat could break existing levels. Timed systems could take a massive hit, and MM have taken pains so far to not break existing levels (not always successful, but they have tried). All the glitched materials etc. still work - they didn't have to do that, but they did to stop people's levels from breaking.
2009-06-27 12:13:00

Author:
rtm223
Posts: 6497


I like the idea of being able to not have a delay if one doesn't want it for the grab switch activating an attack mechanism. So unless a delay is needed, such as when hooking multiple of these things together, I'd like to see it avoided if at all possible.

In this particular suggestion, for logic switches, I'm going to suggest the delay tool works in 0.1 second increments, like the rest of LBP.

I think RickRock_777 should make an additional suggestion for some sort of video tool. A video tool could create essentially a video screen on a flat layer that could operate much faster than everything else. This would be because the physics never change, only the visual. The video screen would be the object as far as the physics engine is concerned and it would operate at the same frequency as everything else. The image on the screen could change. 3D stickers already work this way. They move about without appearing to jerk and they can even be placed on moving objects. True, there is a glitch if you put too many close together but still. I think a tool that is a video screen that essentially lets you load a bunch of stickers into it and let it play during the level, changing pictures at whatever interval you set from 30 times a second (LBPs visual speed) to a slide show that switches every several seconds. This could be a very useful and cool tool for creators!

However, I'm going to suggest this goes to another thread. Logic is intimidating enough for some people without the addition of these technical discussions! I'd like people who see the suggestion and read the thread get the feeling that this is something they can do, even if they have no background in computers!
2009-06-27 14:30:00

Author:
dcf
Posts: 468


In this particular suggestion, for logic switches, I'm going to suggest the delay tool works in 0.1 second increments, like the rest of LBP.

I think RickRock_777 should make an additional suggestion for some sort of video tool.

Forgive me dcf...apparently I misunderstood your intent when you mentioned the .1s delay being noticeable, and assumed you were looking for improved resolution with the implementation of more complex logic gates.

Rick
2009-06-27 18:08:00

Author:
RickRock_777
Posts: 1567


This is a good thread. This would save me time AND thermo. Enough said.2009-06-28 23:55:00

Author:
DrunkenFist_Lee
Posts: 172


This is a good thread. This would save me time AND thermo. Enough said.

That's the basic idea
2009-06-28 23:56:00

Author:
dcf
Posts: 468


I didn't bother reading much of the first post but i think the OR/AND/XOR switches are a great idea, and although i didn't really understand it the circuit board would be a great alternative to having a load of dark matter floating around

I'll read through it properly at another time, i'm a bit tired at the moment
2009-06-29 01:28:00

Author:
Dexiro
Posts: 2100


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.