Documenting a level

[PerfectlyDarkTails]

As levels and objects are not going to be carried over to the full game, I wonder if anyone is aware that levels could be documented. There are a few steps involved in preserving your level ideas like a hard copy. As with any system/software programming good documentation can result in better functioning software, if software goes bad I.e. The software is lost such as corrupt level backups and so on. In the LBP context, this could involve

1. Levels/objects drawn/photographed - this keeps a copy of what levels and objects look like so if a creator can't remember what levels and objects look like the photographs can be referenced.

2. Game Flow diagrams - exactly the same as program flow diagrams, this involves A little diagram how the level flows, for example begin level - if sackboy dies restart level, if lives remaining respawn at checkpoint - if enemy damage sackboy/object, destroy object, - if level end reached, finish or go to next level the link should provide some help http://www.google.co.uk/m/search?sit...ms%20in%20word

3. Logic diagrams - this can be a lot of hard work but it is worth it. If there's objects have logic in them, the logic can be documented, this could include each logic gate used in create mode, this could be drawn as simply as what the microchip looks like but for more complex logic systems such as numerous microchips connected then you can do them more professionally see this link to get an idea http://commons.wikimedia.org/wiki/Logic_diagram. This is also a good technique is also good for designing logic as well.

4. Testing documentation - in a programming sense, this involves listing, what has been tested from your own tests or others, so there's a reference to any bug fixes. This can be displayed in a table format. An example headings can be what needs testing which can be sackboy activates switch, when testing this can be carried out, another heading can be a presumed result which can be switch opens door, another heading can be actual result, wether the door is opened or not, the final heading can be a fixed? Heading, this is to confirm that the bug if fixed or not. This link will give you an idea of testing documentation is. http://www.google.co.uk/m/search?gl=...+documentation.

5.recording dialogue- if there's a lot of dialog this is a simple step, this can be simply be in the form of transcripts, who says what, when, and where. This step could also hold the actual name of the level, description of the level, and any other text used. This step should be word processed for best results. Music and sound effect timing can be referenced here also, this is also a good idea for designing.

6. Keep documents in a safe place - after all steps are are complete all documentation should be kept safely. This could mean that all documentation is kept onto a computer or any drawn diagrams are put into a folder and kept it of reach of harm, it is also recommended that the actual level backup is saved to a disk and also stored into a folder.

These steps are mostly designed so that more serious creaters can keep track and keep a permanent copy of their levels. Documentation like this can last forever even after the PS3 has long past it's functional lifetime. Anyone have any questions on other steps or techniques. This is a tutorial that was adapted from my own system software documentation knowledge and adapted into LBP. This is for LBP2 for beta creators looking to preserve their level ideas but it can easily be adapted for LBP1.

You would not want to try to reverse engineer from memory would you?

[nunsmasher]

Wait... we don't get our levels in LBP2?

[PerfectlyDarkTails]

For the beta levels, nothing is kept from the beta, lbp1 levels would be featured as most of the levels are backwards compatible.

Because some of the beta levels are so good it would be a shame to loose them.