[PS3] LittleBigPlanet 2

Just as an example of how difficult top-down vehicles can be to make, here is as response I got from Cyber_wolf after I posted up my vehicle settings on the beta forums and asked how others were doing it.

I use a direction combiner onto an up/down input of an advanced mover to allow one button for accelerating(R2) and one for reverse(L2) (currently use reverse for brake but I guess I could use the anti gravity object with dampening for braking). The mover has deceleration to slow the car when no buttons are being pressed.

I have an anti gravity thing with no dampening and 100% anti grav.

I use 3 advanced rotator for turning.

The first has its left/right input connected to my left analog. It has 0 deceleration. It's on/off input if connected to my accelerator so that this steering only works when driving forward.

The second is for reverse, also has 0 deceleration. I wanted it to feel like a normal car so I had to swap the turning directions when going in reverse. Its left/right input comes from my left analog but I use a direction splitter followed by a combiner with +I've and -I've swapped around. It's on/off if connected to the reverse button (L2) so that it is only enabled when reversing.

The third is used for turning deceleration only. I found that because I disable the rotators used for steering if you are not moving, then even if I used deceleration on those rotators the deceleration is disabled when you are not moving. So if you were turning when you release the accelerator it would not stop turning. I use this third rotator with high deceleration which is enabled all the time to solve this issue. It is not connected to anything.

The result is: R2 to drive forward (speed is affected by amount pressed) and L2 for brake and reverse. The steering is disabled while not moving and both turning deceleration and movement deceleration can be tweaked separately to create nice powersliding at high speeds (this is the advantage of not using the global anti gravity dampening). The reverse steering is as it would be in a normal car.
 
Need serious enemy AI. Is it possible to program sophisticated AI into SackBots ? Can you write logic that depends on user input, player position, life, etc. ?
 
Probably, but it'll get messy. You can, AFAIK, only switch between behaviour chips to change behaviour, so AI will consist of selecting between following, fleeing, and playing captured animations, all in response to whatever measures you can make. That's one thing that's a bit disappoint, that you can't expose component variables to input. Every component has one control in, which is either on/off or speed or strength, sort of thing. You can't have one input into a SBt brain to control speed, and another awareness. Creating sophisticated SBt's will be the domain of the more serious creators.

One thing I did think of though, as Cornsnake quotes a solution above, and sharing is possible, and MM have spoken of certain gameplay kits; there's nothing stopping them offering official mechanisms (other than them making them!). They could get a prebuilt top-down car chip that you can slap on any object to enable it, and tweak the parameters. MM are looking to the community to manage this side, but as they have their own MM Picks section in the Community Levels, they can link directly to the best solutions and reach the larger community, rather than just the players who visit LBPCentral.
 
Probably, but it'll get messy. You can, AFAIK, only switch between behaviour chips to change behaviour, so AI will consist of selecting between following, fleeing, and playing captured animations, all in response to whatever measures you can make. That's one thing that's a bit disappoint, that you can't expose component variables to input. Every component has one control in, which is either on/off or speed or strength, sort of thing. You can't have one input into a SBt brain to control speed, and another awareness. Creating sophisticated SBt's will be the domain of the more serious creators.

One thing I did think of though, as Cornsnake quotes a solution above, and sharing is possible, and MM have spoken of certain gameplay kits; there's nothing stopping them offering official mechanisms (other than them making them!). They could get a prebuilt top-down car chip that you can slap on any object to enable it, and tweak the parameters. MM are looking to the community to manage this side, but as they have their own MM Picks section in the Community Levels, they can link directly to the best solutions and reach the larger community, rather than just the players who visit LBPCentral.

So kind of a Tools & Solutions section. Might as well have a Parts & Scenery section too. I like the idea, it'd go a long way to making creation more user friendly.
 
Need serious enemy AI. Is it possible to program sophisticated AI into SackBots ? Can you write logic that depends on user input, player position, life, etc. ?

I've been trying to something like this. Although it's fairly simple right now with just 2 different enemy behaviours it can switch between in my published level, and a 3rd behaviour working in an unpublished updated version.

There is a piece of logic that is ideal for it. The selector. It has 4 inputs and 4 output, and will only output the highest active input. So you can use it to set up priority behaviour. The inputs can be connect to whatever you want trigger it, like sensors and switches. And the outputs to whatever you want it to do, like movers or emitters, ect. You can also use it to cycle through all of the outputs. Or use a randomizer to switch it's outputs randomly or have it follow a pattern.
 
I had forgotten all about the selector! Because it's prioritised, you could have progressive behavior. Although the fact it's triggeded by on/off rather than a scale is annoying. I can't see any nice way to do a progressive scale - only a load of strung together timers. But I suppose that works.
 
I had forgotten all about the selector! Because it's prioritised, you could have progressive behavior. Although the fact it's triggeded by on/off rather than a scale is annoying. I can't see any nice way to do a progressive scale - only a load of strung together timers. But I suppose that works.

Can't you build something that moves one step each time it is activated until it reaches a goal or something like that?
 
The question is how to measure how far something has gone. In a typical language, you'll have a conditional IF statement to select. With a timer, you could have

IF (time >= 5.0){ do stuff }
ELSE IF (time > 2.0){ do other stuff }
ELSE IF (time >0.0){ do different stuff }
ELSE {do nothing }

Although theres's a convenient timer control in LBP2, AFAICS there's no such measurable output from a timer that can be tested. Now having poked around a bit, you can string together a series of timers so they gradually fill up, which provides the selection criteria of the above IF statement. As each timer fills, it'll output an ON signal, which you could pass into a selector. In the case of Sackbot, you could use a Selector and have each timer output to one of the inputs, and the outputs to a different brain, and as the time changes, you'd switch between behaviours. For measuring distance from a player, you could use a collection of proximity sensors, each set to a different distance. And you could do the same to measure distance from a specific point. I can see this working.

I do miss a simple accumulator though. I suppose like the timers, you could string together some counters, or build a binary store with Toggle switches, but I haven't figured out a way to decrement counters. Let's say a player has a shot limit of 5 shots, and can pick up ammo. You would instinctively turn to a counter, and every time you picked up ammo you could increment it, but every time you shot you couldn't also decrement it. There may be a solution, but it's getting into the realms of LBP complexity then!
 
There is more basic logic that's strangely absent, like the permanent switch and the flipflop. Just like before the community is providing these through How to ... levels, but it would be nice to have these as standard in the pop-it menu. It would reduce the amount of added basic logic needed to get those functions. Microchip can quickly become cluttered with logic. It sure looks impressive to anyone that doesn't understand how it works, but it's needlessly difficult to work with while building it.
 
There are a LOT of bugs in the Beta. I find a new one every time I play or build something. One month to squish them all would be a tight deadline. sony certainly don't want to miss the Christmas period, but they have to get the final product up to standard or they'll destroy word-of-mouth momentum.

I'm not in the Beta forum so can't see what the current bug list looks like, so can't give a more educated guess on how much MM have to do. Plus if they want Move integration, they may as well launch with it.
 
Actually... that is just perfect for Playstation Home. Upload proven (and approved) creations to Youtube, and then stream them to PS Home spaces (e.g., the music lounge in the Central space). I assume if it's safe for LBP, it should be safe for PS Home ? :p

Seriously, Sony has enough breadth to start linking all the assets together now. Use the web API to promote the community and content.

EDIT:
There are a LOT of bugs in the Beta.

Then they should definitely delay it. v_v
 
That second song is very good.
Thought I'd fill you in on the music sequencing aspect.

It's very similar to tracking on the ST and Amiga. There are a range of instrument components, the squares arranged on the track. Each component covers a sound or library of sounds in the case of a drumkit which different sounds on different pitches, like a GM MIDI drumkit. I think all sounds are sample based, just like an Amiga tracker, although the chip sounds may be synthesised. As such, some sounds take up more memory than others. There's a separate blue thermometer for music sequencing that fills up with sounds like the normal thermo does with adding a new texture. The range of sounds in the Beta sounds very 'chippy'. There are a few real instrument types, like a piano, but they're of the cheap keyboard variety. Unstandable, but that's definitely going to colour the music produced.

Each component block opens up to a grid of nodes with pitch up and down, time left and right. There are 64 beats, shaded as four bars, so is by default akin to 4 bars of 4/4 time at a resolution of semiquavers, although anyone who's done tracking will know there's nothing to stop you running it double time or more (which has a reason I'll describe later). As the YouTube vid shows, and which I didn't know, you can extend the length of the component to more beats. I'm presuming it's still a multiple of 64 for the timing, but you never know.

When inputting notes, you set the length with R1/L1 to lengthen/shorten, and stick it down on the grid at the pitch and start point you want. A placed note can be copied or moved, and nodes can be selected and moved to change start time, pitch, or note length. A note doesn't have to stick at the same pitch; you can have the end node placed higher or lower, allowing for portamento. Each node can also have its volume and tone set with the right-stick I think. Tone is seemingly per-instrument filter, typically filtering out higher frequencies and adding modulation from what I tried. You can also add nodes to a note, or stick nodes together to join notes. Coupling this with the volume and tone settings, you can vary notes with some sophistication, having a long note with a crescendo, or modulating in the middle.

You can also add funky pitch slides, and that's where double time would be useful. Old chip music used a lot of portamento. My tune on my shooter level incorporates it in the drums as well as lead and it sounds pretty authentic. You can also group select notes and change their volume, tone, and copy them, allowing for tracker-style echo.

One noteable downside is no direct note input, which means you have to know what note you want to put in, or listen out for it as you move the current note around. On the Amiga, the keyboard provided a 2 octave keyboard for not input so you could effectively play your tune, just cursoring down for rythmn. LBP2's sequence needs a pretty laborious note-by-note input with very little musical performance. You're basically deconstructing you musical vision to a set of instructions! I had to skip over to the digital piano to pick out a tune and then remember the notes to put them into LBP2. Properly educated musicians won't have any trouble, and it's open for people to experiment. Plus MM offer a few input types like Major or Minor, so you don't have to wrestle with all twelve tones, although music without accidentals is IMO like food without flavourings!

And that's that, for all 1 or 2 people who may be interested!

Shifty Geezer, the master of TL;DR (or at least giving Joshua a run for his money :p)
 
I am actually intrested. :LOL: I did tracking back in the 16bit days, even managed a whole song that was sort of listenable ... (sort of, lol).
 
The timing seems off for a delay to happen now. Just this week the gaming press was allowed to share their impressions from the beta, and the beta testers are also allowed to do it. If there really is a reason for a delay that probably wouldn't have happened. Yes the beta has bugs, but that's to be expected.
 
Back
Top