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

How breakproof are you?

Archive: 32 posts


I've just read Fjonan's blog on testing levels and making them unbreakable, and it got me thinking about how I work and use testers myself.

I think from creating so much, I've now got the knack of just not making things that people will be able to break. Brnxblze tests my levels and he's pretty much the only person I use other than my girlfriend, (wordly badly, nevermind ).

He may post here himself to confirm/deny this but I don't think he's ever really found a bug or managed to break anything while testing (and he's done a lot of it). I've got to the stage now where I can just kind of look at everything and pretty much see all the things that could go wrong myself.

When it comes to breaking levels I don't even think I really need anyone to test it anymore (but of course, I will always use them just to make sure). I think I have them test more to reassure me that my ideas are okay.

I'm not saying my levels aren't unbreakable, because trust me they. Even my levels are they are now online can actually be broken, it's just that you'd have to do a sequence of events that are so unlikely that pretty much no one will even encounter them.

So, it got me thinking, how much do you need/use testers?
2009-07-14 01:40:00

Author:
jackofcourse
Posts: 1494


I usually just test my levels myself and try to tear apart everything.

If I do get someone else to play my levels before I publish, it's either to show off my mad skillz or to get their opinion on how it looks, not to find glitches/bugs.. but if they find one... :kz:
2009-07-14 01:45:00

Author:
Trap_T
Posts: 431


Haha On my current project i thought the part i had done was 100% breakproof.

I got my Mom to play it!
And she found a Problem! needed a restart to fix it!
And she cant even play the playstation!

Theres a ball that needs to be pushed to the right. Since she can use the controls very well she didnt push it hard enough and just grazed her arm on it a couple of times making it falls to the left so you couldnt progress in the level.

It always happens haha. That is life

Sometimes i make things with some variable in them like falling rocks to fill a chasm.
i find trying to make this 100% breakproof can make it look horrible with barriers and such.

You can Never Ever predict How Players will Play Your Level!
2009-07-14 01:57:00

Author:
BlackToof
Posts: 172


I've never used a tester in any of my levels, I just test them myself and make sure absolutely nothing can brake even if a player is trying to brake the level. My last few levels nobody has reported any bugs or glitches, so I think I've been doing good.2009-07-14 01:59:00

Author:
Dr_Vab
Posts: 134


There's always something I miss.

For my last level I had an 'open beta' and while the level wasn`t broken, it brought up a few things that I just hadn`t realised.

Next level I make, I'll be doing the same thing as the early feedback was excellent.
2009-07-14 02:12:00

Author:
Matt 82
Posts: 1096


I usually have Silverleon go through it at least once. If it can break, he'll find it. I've actually gotten better at making levels unbreakable (meaning a total restart) but I always have stuff that doesn't quite go right and needs to be fixed. I think a few people running through it before launch is always a good idea.2009-07-14 02:54:00

Author:
Morgana25
Posts: 5983


I tend to playtest my levels to death. I love trying to break them.
I have only missed one part on all my levels.
But it's annoying how you can't playtest 2 player sections by yourself.
2009-07-14 07:50:00

Author:
midnight_heist
Posts: 2513


Ha!
Unbreakable level, that's a good one.
I usually test my levels myself, sometimes i get someone else to test them, but its rare.
I usually find bugs/ glitches, and break levels w/out even meaning to, sometimes i do look on ways to break the level on purpose, but sometimes it just happens, wether it'd be in a good way or a bad way.
And even my levels have a couple of glitches (game glitches, not building glitches) which really make me want to go and just delete it all...
But i just end up finding a way to work around it.
So yeah, you should test your levels and have others test it, just in case a game glitchoccurs as that's not the creator's fault, just a freak accident.
2009-07-14 08:18:00

Author:
Silverleon
Posts: 6707


Silverleon is good at breaking things, as is Catiers, xkappa's husband. I test my own levels a LOT, but you can always bank on something you haven't spotted or plainly didn't think of trying.

I generally use the same group of people, some are good at breaking, some at offering improvements, some to stroke my ego
2009-07-14 08:49:00

Author:
GruntosUK
Posts: 1754


My MGS level is actually kind of breakable. The problems are rare, but the complexity makes them hard to completely get rid of.2009-07-14 12:24:00

Author:
TripleTremelo
Posts: 490


Unbreakable level, that's a good one.
Heh, so true. It's probably possible if you exclude uncontrollable engine glitches and you have a very simple level. With a moderate amount of technical complexity, a non-linear or multipath level, you are never going to be able to "just see" everything that could go wrong. Treating my first level as a "system" there are just too many paths and variables for the human mind to take into account. I'm now offloading analyses of the variables onto paper and I'm still stuggling to take eveything into account, and my control systems continue to expand.

Anyone who fancies breaking my first level in 2-4 weeks time will be more than welcome to try
2009-07-14 12:41:00

Author:
rtm223
Posts: 6497


Heh, so true. It's probably possible if you exclude uncontrollable engine glitches and you have a very simple level. With a moderate amount of technical complexity, a non-linear or multipath level, you are never going to be able to "just see" everything that could go wrong. Treating my first level as a "system" there are just too many paths and variables for the human mind to take into account. I'm now offloading analyses of the variables onto paper and I'm still stuggling to take eveything into account, and my control systems continue to expand.

Anyone who fancies breaking my first level in 2-4 weeks time will be more than welcome to try

I'll try and break your level xD.



Anyway my level doesn't just go boom and its ******, i constantly mess everything up, i cant even get a zipline to go over gas without it being ****** but it does give a new idea.

I cant even get a piston to go up and stay there.
2009-07-14 13:09:00

Author:
Adam9001
Posts: 744


Interesting thread.

If you're a good engineer and understand the LBP physics pretty well, most likely you're going to design a pretty break-proof level. If you're going to do complex mechanics, it may even be necessary to design in "back up" plans for things that can break.... make sure even if something can break, the level can be finished.

Couple examples:

In testing NinjaMicWZ's "Free at Last" (yes... I actually get to test his stuff!!!) the tall robots would sometimes just tip over - making it impossible to continue. It wouldn't happen often, but when it did that was it.

It wouldn't be possible to keep the current design of the robots (which was REALLY cool) and have them never tip over, so you could either a) design the robots so that when they tipped over you could still jump over them or b) install an AND switch off-screen that made the robots self-destruct if they tip over.

In Splat Invaders, originally the invaders simply had a paintinator switch on them that made them blow up and reduce a counter. When the counter hit zero, the door to the next room would open.

However, dissolve and cardboard can easily be broken off with a paintinator gun. So, sometimes a person would shoot the invader and it would dissolve without the paintinator switch going off - which caused the door to never open.

So, instead I put a magnetic key on each invader and had a single magnetic switch that activated when all the invaders disappeared... this was completely break-proof.

So, there's definately ways to break-proof even complex things - sometimes you just need to do things a slightly different way.
2009-07-14 13:35:00

Author:
CCubbage
Posts: 4430


It really depends on the level. Generally though the more complex a level is the more issues you can find.2009-07-14 13:43:00

Author:
wexfordian
Posts: 1904


I make my stuff pretty rock solid, and try to anticipate as many variables and foolishness as I can... I also run through every single thing hundreds of times over ad infinitum and yet again when anything new is added in succession after that point. Sometimes I do get lazy though, and hope no one notices, or that I can get by on luck, and try to let some things slide - ie: I simply don't have any thermometer room for a failsafe solution to a small problem in some cases. Doesn't work out that way very often, and I end up with alot of last minute fixes on launch day, and don't have the lock-and-key approach to safeguard it, but recklessness is fun and I'm always excited to get a new level out.

The bugs I encounter are usually 11th hour, massively unforeseeable time-delayed bugs where ultra-complex machinery gradually desynchs itself after a much, much, much greater time than I alot in my own play time passes... that or having everything so close to burst that I always run the risk of the paintinator failing to fire at SOME point with 4 players, even though I activate all emitters and effects in a level, and fire like a maniac to see if and when it will fail.

Even MM's levels mildly break in some spots, or do/allow things they shouldn't, and I've never played any community level that hasn't.
2009-07-14 13:44:00

Author:
Unknown User


I think that Crystal Cave and Centralia are pretty unbreakable for the most part, because Larry and Vmethos extensively tested them. I know you can still tip the mine cart though, if you try really really hard, but we try our best to make it so you can't break things. Usually when we approach a level, we look at an object and say "I can get that stuck on this, this and that"

I'm not saying that they're perfect, I'm sure they're not, but we try really hard to make it so you don't get stuck 90 percent of the way into a level, because that would suck.
2009-07-14 13:55:00

Author:
xkappax
Posts: 2569


So, there's definately ways to break-proof even complex things But you've just given two examples of very, very simple things there...

Last night I spent about two hours analysing sequences of events through a very small section of level. There are various paths that can be taken, things fall apart and if you die they need to be reset, if they don't fall apart then other things need to happen, to prevent them falling apart during a backtracking section, during your backtrack I need them to not reset, etc etc... I've got two pages of diagrams ready to be implemented to (hopefully) ensure that no matter what happens, baring a game engine error over which I have no control, it will be robust. The sheer number of variables involved and interacting (including the player, that most horrible of variables) means that there is no way I could have just looked and assesed the failure modes, my head would have popped

Of course, this is largely down to me overcomplicating sections of my level, refusing to compromise on the gameplay, and my overzealous attitude to failure-safety, but still. I'm not disagreeing with you that break-proofing is possible. But in a moderately complex situation, like I have, it's often not a case of just adding a NOR gate to a room full of enemies...
2009-07-14 14:00:00

Author:
rtm223
Posts: 6497


This is a constant problem I have with levels that I make that are heavily based around machinery, or even AI. One thing goes wrong and its hours of work to fix it. Sometimes, the process is as drastic as:

1. Isolate problem
2. Reproduce problem
3. If simple, implement a fix. If not, go to step 4.
4. Sketch out a work around on paper
5. Implement work around
6. Test new method of function for error and problem
7. If new problem exists or old problem persists, restart problem solving cycle or design a completely new system.
2009-07-14 14:00:00

Author:
BSprague
Posts: 2325


But you've just given two examples of very, very simple things there...

Last night I spent about two hours analysing sequences of events through a very small section of level. There are various paths that can be taken, things fall apart and if you die they need to be reset, if they don't fall apart then other things need to happen, to prevent them falling apart during a backtracking section, during your backtrack I need them to not reset, etc etc... I've got two pages of diagrams ready to be implemented to (hopefully) ensure that no matter what happens, baring a game engine error over which I have no control, it will be robust. The sheer number of variables involved and interacting (including the player, that most horrible of variables) means that there is no way I could have just looked and assesed the failure modes, my head would have popped

Of course, this is largely down to me overcomplicating sections of my level, refusing to compromise on the gameplay, and my overzealous attitude to failure-safety, but still. I'm not disagreeing with you that break-proofing is possible. But in a moderately complex situation, like I have, it's often not a case of just adding a NOR gate to a room full of enemies...

Try the crash landing on False Idols III and trying to compensate for the incalculable change in physics every time a single object, key, or emitter is changed or added in the construction process of the level... had to readjust, test, rebuild, and realign it's entire trajectory at least a few hundred times and each fix would take anywhere from 20 minutes to an hour.

The errant debris in space would effect it (and they would behave differently as they're struck EVERY TIME), the circular movement of the two opposing wheels (the moon and the fiery, explosive background) would create an odd center of gravity that changed it's trajectory depending on how fast any of it was moving or wether they were moving counter clockwise or not... their size would cause variation. The height at which I placed the level in the template area would mess it up. Even changing the material set in other parts of the level would change it. EVERYTHING would change it's behavior. I finally got it to where 1 to 4 players, no matter how they're behaving, will land perfectly, and stop on a dime in the same spot almost every time without being blown to pieces, phasing through the walls of the meteor and vanishing into a cloud of smoke, being tossed into the nearby gas along with the only active checkpoint, or launched sky high in any number of directions to bypass the whole intro area, skipping key sensor switches, or see any unwanted logic and effect "behind the scenes stuff"...

The entire sun-refinery, and the fancy shmancy door at the end would behave the same way and undergo what seemed to be a total change in gravity and mass, far beyond my understanding, when any minute change was made to the level. I finally had to just wait until the very end of the construction process to even bother trying to test and fine tune them. I was a brain dead zombie after I finished that level.
2009-07-14 14:18:00

Author:
Unknown User


I must admit I've not played that level yet (still haven't played #2 yet in fact), but that does sound like an absolute 'mare. Luckily the physics-based issues I had were nowhere near as subtle and were permenantly fixed (I hope) a while back, and I only have to deal with 1 sackboy.

I have noticed that simply adding a mag key to an object will subtley alter it's properties though. I've pretty much vowwed never to try and implement anything that is that finely balanced on this physics engine - you're a far braver man than me
2009-07-14 14:42:00

Author:
rtm223
Posts: 6497


I hate logic too, though. It's a nightmare for some of the simple things in my levels, when any player input is involved so I can't imagine dealing with multipath, resetting logic (when I rely so much on permanent switches). I think that's why I end up getting lazy on some things, because I know people are going to break it no matter what I do.

Try out ep 3 though... you should coast in on your speed-sensor controlled rocket thrust smoothly and get some nice explosive butt burn from the flash bang and collapsing terrain you crash into, and get launched a hair to the left off the explosion to land smack dab on that one single point bubble sitting on a tiny corner, and stand in a nice scenic view of the stalactite background with the GLS readjusting your alien eyes to the new terran dusk - every time... and the checkpoint will always launch to your right.

Even still, the checkpoint lands further to the right on some turns, and sackboy will tiptoe mount the corner or slip down a foot or two after landing on it. With more than 1 player, 50% of the time a player will get killed and spawn out of the checkpoint while the other lands perfectly. I'm proud of making that 100% break proof, and never need a restart.

The big sun machine still fails with time though... slowly desynchs the wheels if a player lollygags for a half hour down below, and I have yet to find a solution for it. It sucks.
2009-07-14 15:01:00

Author:
Unknown User


But you've just given two examples of very, very simple things there...

Last night I spent about two hours analysing sequences of events through a very small section of level. There are various paths that can be taken, things fall apart and if you die they need to be reset, if they don't fall apart then other things need to happen, to prevent them falling apart during a backtracking section, during your backtrack I need them to not reset, etc etc... I've got two pages of diagrams ready to be implemented to (hopefully) ensure that no matter what happens, baring a game engine error over which I have no control, it will be robust. The sheer number of variables involved and interacting (including the player, that most horrible of variables) means that there is no way I could have just looked and assesed the failure modes, my head would have popped

Of course, this is largely down to me overcomplicating sections of my level, refusing to compromise on the gameplay, and my overzealous attitude to failure-safety, but still. I'm not disagreeing with you that break-proofing is possible. But in a moderately complex situation, like I have, it's often not a case of just adding a NOR gate to a room full of enemies...
Yes, they're 2 simple things.... but common mistakes. I was trying to mention a couple simple examples that could help people reading this.

The first time I shot the cardboard target completely off the tank at the very end of Voltiars H.A.T.E. 2 it was frustrating because it took me SOOOO long to get to that point. Or the part with the bouncing fat ninja's in the MM story mode where the ninja fell over and was impossible to jump over.

There are many things that are much more complex that boil down to engineering skill... whether it's breakable or not is going to depend on how you design it.

One thing I've found that helps with break-proofing is to emit complex objects as you get near them, so that they don't have time to fail.
2009-07-14 15:27:00

Author:
CCubbage
Posts: 4430


One thing I've found that helps with break-proofing is to emit complex objects as you get near them, so that they don't have time to fail.

I second this... that's exactly what I had to do with those enemies. I think they would have been fine without being so top heavy or metallic, and if they were using their creature brain for navigation... but like rtm, it's no fun not to overcomplicate simple things. I've been drilling that into a friend of mine who asks me alot of questions - anything from a door opening to an object rotating is way more awesome to me if it's unnecessarily complex ala scifi world. LBP, to me, is all about cool stuff that does cool stuff.
2009-07-14 15:41:00

Author:
Unknown User


LBP, to me, is all about cool stuff that does cool stuff.

Am?n.

For trying to break my level, normally it's enough with just myself; I'm always curious about "what if" and so, it results in heavy machinery-that-you-weren't-supposed-to-see falling from the sky.
But if that isn't enough, make a child play it, if you have the opportunity to. I completely ignore how my sister's mind works, but it looks like it always tries the opposite thing of what you're supposed to.
I mean, why would somebody go back while that big, shiny door is open, suggesting something along the lines of "go trough me, enter me, search for the other side of the former closed door"? Well, she went back. She broke the level.
And my heart.
I guess that my main problem is, that even being curious, there are some things that don't ever croos my mind; I just can't think of those, specially some of the obvius ones.
2009-07-14 15:58:00

Author:
Keldur
Posts: 628


When it comes to breaking levels I don't even think I really need anyone to test it anymore (but of course, I will always use them just to make sure). I think I have them test more to reassure me that my ideas are okay.


Does that mean you don't need me anymore... . I'll just be on my way then...It was nice while it lasted...

Lol, anyway, yeah the whole time I was testing Jack's levels (Since Flaming Timberland 1 I think?) I don't think I ever found 1 bug. There was just one tiny thing in FT2 where there was a bolt and a platform which fell down and when you got on top you could get stuck between the wall and the platform.

To answer your question, I really only use testers to see if a part is too hard to figure out or if they like the level. My levels are pretty simple so there aren't much bugs.
2009-07-14 16:30:00

Author:
brnxblze
Posts: 1318


Yes, they're 2 simple things.... but common mistakes. I was trying to mention a couple simple examples that could help people reading this. Gotcha. Think I read the paragraphs as being more closely linked than you intended, my bad :blush:


like rtm, it's no fun
2009-07-14 17:03:00

Author:
rtm223
Posts: 6497


I basically do break proof levels. It's too important for me. It's the kind of polish a level need. It's rare I don't find a workaround even if my levels aren't perfect at all.

I think it's a matter of being meticulous and testing everything all the time. As soon as do something I immediately test it. I never pile up stuff before testing it. If you test your stuff or create your stuff while having in mind "how to possibly break it", your levels should end up very good.

I know my Crazy Train levels can totally break (especially at the end with the truck) but I decided it wasn't likely enough to happen for me to fix it.

.
2009-07-14 18:16:00

Author:
RangerZero
Posts: 3901


I have only made two levels, but both of them have a lot of moving parts which makes it difficult to play test them without just playing through the entire level, which is time consuming. Luckily I think I've gotten all the bugs worked out of them now.2009-07-14 20:24:00

Author:
Walter-Kovacs
Posts: 542


Probably all of my levels are breakable, it's just that most of em' are probably really hard to break and really unlikely to break. I playtest my levels A LOT. Even when they're in early development.2009-07-14 20:36:00

Author:
lk9988
Posts: 1077


I have a few friend 'volunteers' who help me play test. My biggest problem is usually spending so long on a particular section (or even an entire level), that I can sometimes overlook simple things - much like re-reading an article/story/letter you've written so many times, only to find out you've missed out an entire sentence.

I can only echo what a few others have said - other people, friends or not, will always play your level differently, and as a creator you can only do so much testing yourself. Other opinions and suggestions are always valid.
2009-07-14 20:41:00

Author:
MrsSpookyBuz
Posts: 1492


One thing I've found that helps with break-proofing is to emit complex objects as you get near them, so that they don't have time to fail.
That is a generally good solution, but it can't be used too heavily in a level because an emitted version of it is going to be slightly more thermometer intensive than it just being there.
2009-07-14 20:47:00

Author:
BSprague
Posts: 2325


That is a generally good solution, but it can't be used too heavily in a level because an emitted version of it is going to be slightly more thermometer intensive than it just being there.
To a point... haven't had too much of a problem with this myself. Generally it's the "separate objects" thermo that goes up a bit, but controlling the different thermo levels usually helps with this.

One of the key things about LBP creation is learning to control the different thermos to your advantage. I have had VERY little issue with emitters taking more thermo (I have over 85 of them in Splat Invaders Saga). And in Splat Invaders II virtually everything except the floor is emitted as you get to it.
2009-07-14 21:02:00

Author:
CCubbage
Posts: 4430


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.