Additions:
It's about utilizing the resources most efficiently. It's not about adding puzzles or powerup balance... It's about making a level load and render as smoothly as possible. Making sure players don't spawn in a wall, that all the scripting works, that sounds can be heard where they should...
====Remove Unused Items From the MN3 and GAM Files====
Quite often I will add custom object to a level then remove them later, for one reason or another. This leaves an unused object, texture, or sound in the mn3. Remove them, using the QuickTest toolbox, when you are sure you won't be using them. I don't know for sure that this has any effect on the level's play, but it does reduce the download size if nothing else. But now you are half done this job, you need to remove the entries for these items from the GAM file. I do know if you have entries in the GAM file with no related objects in the MN3 it will crash the level when you access the auto-map.
When you've completed a level, you'll need to do some testing before releasing it to the public. There are two phases of testing, alpha and beta. Alpha testing is generally done in-house, or with perhaps a few friends. Beta testing begins in house, but may grow to include a public beta. Generally it's best to keep testing private. Make sure everyone knows what the ground rules are before handing over the level for testing! For alpha testing, any tester should be appraised of any known quirks. Testers should be strongly encouraged to give honest feedback. It's very difficult to objectively view your own work. And you are intimately familiar with every nook and cranny of your level, where power-ups and bots are, how the scripting works, etc... How can you possibly honestly evaluate your own level? On the other hand, if you release a beta to the public too early, and it's buggy, or is unfinished, your level might be dissed as 'bad', releasing too many updates will turn people off. No one will want to play it //again//, even though you might have fixed all the problems brought up in public beta, it's still the same level. Make sure you test everything you've scripted, check for sufficient way-points, player starts (for multi-player) and don't forget to test the auto-map. If it's a multi-player level, be sure to include a url so the auto-download feature will work. Nothing kills a new level faster than making players go look for it... they will just play another level instead.
needed for this page:
====Remove Unused Items From the MN3 and GAM Files====
Quite often I will add custom object to a level then remove them later, for one reason or another. This leaves an unused object, texture, or sound in the mn3. Remove them, using the QuickTest toolbox, when you are sure you won't be using them. I don't know for sure that this has any effect on the level's play, but it does reduce the download size if nothing else. But now you are half done this job, you need to remove the entries for these items from the GAM file. I do know if you have entries in the GAM file with no related objects in the MN3 it will crash the level when you access the auto-map.
When you've completed a level, you'll need to do some testing before releasing it to the public. There are two phases of testing, alpha and beta. Alpha testing is generally done in-house, or with perhaps a few friends. Beta testing begins in house, but may grow to include a public beta. Generally it's best to keep testing private. Make sure everyone knows what the ground rules are before handing over the level for testing! For alpha testing, any tester should be appraised of any known quirks. Testers should be strongly encouraged to give honest feedback. It's very difficult to objectively view your own work. And you are intimately familiar with every nook and cranny of your level, where power-ups and bots are, how the scripting works, etc... How can you possibly honestly evaluate your own level? On the other hand, if you release a beta to the public too early, and it's buggy, or is unfinished, your level might be dissed as 'bad', releasing too many updates will turn people off. No one will want to play it //again//, even though you might have fixed all the problems brought up in public beta, it's still the same level. Make sure you test everything you've scripted, check for sufficient way-points, player starts (for multi-player) and don't forget to test the auto-map. If it's a multi-player level, be sure to include a url so the auto-download feature will work. Nothing kills a new level faster than making players go look for it... they will just play another level instead.
needed for this page:
Deletions:
outline for this page:
1) what it is... what it is not
1) why... benefits
1) what kinds of levels
1) error free shell
1) remove extra verts and faces
When you've completed a level, you'll need to do some testing before releasing it to the public. There are two phases of testing, alpha and beta. Alpha testing is generally done in-house, or with perhaps a few friends. Beta testing begins in house, but may grow to include a public beta. Generally it's best to keep testing private. Make sure everyone knows what the ground rules are before handing over the level for testing! For alpha testing, any tester should be appraised of any known quirks. Testers should be strongly encouraged to give honest feedback. It's very difficult to objectively view your own work. And you are intimately familiar with every nook and cranny of your level, where powerups and bots are, how the scripting works, etc... How can you possibly honestly evaluate your own level? On the other hand, if you release a beta to the public too early, and it's buggy, or is unfinished, your level might be dissed as 'bad', releasing too many updates will turn people off. No one will want to play it //again//, even though you might have fixed all the problems brought up in public beta, it's still the same level. Make sure you test everything you've scripted, check for sufficient way-points, player starts (for multiplayer) and don't forget to test the automap. If it's a multiplayer level, be sure to include a url so the auto-download feature will work. Nothing kills a new level faster than making players go look for it... they will just play another level instead.
Revision [1914]
Edited on 2009-07-04 07:10:28 by WillyPs [added more to "testing" and item 9 to outline]Additions:
1) remove unused items from the mn3 and gam
When you've completed a level, you'll need to do some testing before releasing it to the public. There are two phases of testing, alpha and beta. Alpha testing is generally done in-house, or with perhaps a few friends. Beta testing begins in house, but may grow to include a public beta. Generally it's best to keep testing private. Make sure everyone knows what the ground rules are before handing over the level for testing! For alpha testing, any tester should be appraised of any known quirks. Testers should be strongly encouraged to give honest feedback. It's very difficult to objectively view your own work. And you are intimately familiar with every nook and cranny of your level, where powerups and bots are, how the scripting works, etc... How can you possibly honestly evaluate your own level? On the other hand, if you release a beta to the public too early, and it's buggy, or is unfinished, your level might be dissed as 'bad', releasing too many updates will turn people off. No one will want to play it //again//, even though you might have fixed all the problems brought up in public beta, it's still the same level. Make sure you test everything you've scripted, check for sufficient way-points, player starts (for multiplayer) and don't forget to test the automap. If it's a multiplayer level, be sure to include a url so the auto-download feature will work. Nothing kills a new level faster than making players go look for it... they will just play another level instead.
When you've completed a level, you'll need to do some testing before releasing it to the public. There are two phases of testing, alpha and beta. Alpha testing is generally done in-house, or with perhaps a few friends. Beta testing begins in house, but may grow to include a public beta. Generally it's best to keep testing private. Make sure everyone knows what the ground rules are before handing over the level for testing! For alpha testing, any tester should be appraised of any known quirks. Testers should be strongly encouraged to give honest feedback. It's very difficult to objectively view your own work. And you are intimately familiar with every nook and cranny of your level, where powerups and bots are, how the scripting works, etc... How can you possibly honestly evaluate your own level? On the other hand, if you release a beta to the public too early, and it's buggy, or is unfinished, your level might be dissed as 'bad', releasing too many updates will turn people off. No one will want to play it //again//, even though you might have fixed all the problems brought up in public beta, it's still the same level. Make sure you test everything you've scripted, check for sufficient way-points, player starts (for multiplayer) and don't forget to test the automap. If it's a multiplayer level, be sure to include a url so the auto-download feature will work. Nothing kills a new level faster than making players go look for it... they will just play another level instead.
Deletions:
Additions:
Where possible, multiple small faces should be combined into larger faces. Be careful not to break portals or create bad faces doing this! To combine faces, select a face, then holding down Control (Ctrl) and Shift, click on an adjacent face. If the face would be non-planer or concave, or if the second face does not share an edge with the first, D3Edit will tell you, and refuse to combine the faces. When you are done combining faces, remove all the extra verts. Combining faces will automatically remove any verts that would no longer be attachment to an edge. However you most likely will have some verts that are in an edge but are not needed. These can be removed with the verts magnet.{{image class="center" url="http://www.prepare4descent.net/descentiapedia/LevelOptimization/files.xml?action=download&file=vertmag.jpg"}}
Deletions:
Additions:
====Combine Faces====
Where possible, multiple small faces should be combined into larger faces. Be careful not to break portals or create bad faces doing this! To combine faces, select a face, then holding down Control (Ctrl) and Shift, click on an adjacent face. If the face would be non-planer or concave, or if the second face does not share an edge with the first, D3Edit will tell you, and refuse to combine the faces. When you are done combining faces, remove all the extra verts. Combining faces will automaticly remove any verts that would no longer be attachment to an edge. However you most likely will have some verts that are in an edge but are not needed. These can be removed with the verts magnet.
====Testing====
When you've completed a level, you'll need to do some testing before releasing it to the public. There are two phases of testing, alpha and beta. Alpha testing is generally done in-house, or with perhaps a few friends. Beta testing begins in house, but may grow to include a public beta. Generally it's best to keep testing private. Make sure everyone knows what the ground rules are before handing over the level for testing! For alpha testing, any tester should be appraised of any known quirks. Testers should be strongly encouraged to give honest feedback. It's very difficult to objectively view your own work. And you are intimately familiar with every nook and cranny of your level, where powerups and bots are, how the scripting works, etc... How can you possibly honestly evaluate your own level? On the other hand, if you release a beta to the public too early, and it's buggy, or is unfinished, your level might be dissed as 'bad', releasing too many updates will turn people off. No one will want to play it //again//, even though you might have fixed all the problems brought up in public beta, it's still the same level.
{{files}}
Where possible, multiple small faces should be combined into larger faces. Be careful not to break portals or create bad faces doing this! To combine faces, select a face, then holding down Control (Ctrl) and Shift, click on an adjacent face. If the face would be non-planer or concave, or if the second face does not share an edge with the first, D3Edit will tell you, and refuse to combine the faces. When you are done combining faces, remove all the extra verts. Combining faces will automaticly remove any verts that would no longer be attachment to an edge. However you most likely will have some verts that are in an edge but are not needed. These can be removed with the verts magnet.
====Testing====
When you've completed a level, you'll need to do some testing before releasing it to the public. There are two phases of testing, alpha and beta. Alpha testing is generally done in-house, or with perhaps a few friends. Beta testing begins in house, but may grow to include a public beta. Generally it's best to keep testing private. Make sure everyone knows what the ground rules are before handing over the level for testing! For alpha testing, any tester should be appraised of any known quirks. Testers should be strongly encouraged to give honest feedback. It's very difficult to objectively view your own work. And you are intimately familiar with every nook and cranny of your level, where powerups and bots are, how the scripting works, etc... How can you possibly honestly evaluate your own level? On the other hand, if you release a beta to the public too early, and it's buggy, or is unfinished, your level might be dissed as 'bad', releasing too many updates will turn people off. No one will want to play it //again//, even though you might have fixed all the problems brought up in public beta, it's still the same level.
{{files}}
Deletions:
1) testing
Additions:
Descent3LevelEditing
UpDateNeeded
UpDateNeeded
