Worst-case scenario: the UEd Goblin wipes the map and burns down your house.
Difference between revisions of "Unreal Wiki:Layout guidelines"
m |
m |
||
| Line 22: | Line 22: | ||
UnrealScript class pages have a mostly similar layout. Class members are grouped by the kind of member, for example variables, functions and states, with members being sorted alphabetically or, in the case of operators, by precedence. If it makes sense, variables and functions may be further divided. For example in classes with lots of variables that are mainly used in the editor, it makes sense to divide variables into their property groups, while in classes that are mainly used by programmers it might make more sense to separate localized, configurable or unmodifiable variables. Similarly it might make sense to separate functions into static functions, native functions, events, and so on. | UnrealScript class pages have a mostly similar layout. Class members are grouped by the kind of member, for example variables, functions and states, with members being sorted alphabetically or, in the case of operators, by precedence. If it makes sense, variables and functions may be further divided. For example in classes with lots of variables that are mainly used in the editor, it makes sense to divide variables into their property groups, while in classes that are mainly used by programmers it might make more sense to separate localized, configurable or unmodifiable variables. Similarly it might make sense to separate functions into static functions, native functions, events, and so on. | ||
| + | |||
| + | [[Category:Policies and Guidelines|{{PAGENAME}}]] | ||
Revision as of 09:57, 20 February 2008
This page will help you find pages that have been developed enough to warrant them being used as examples for further new pages in the same general category they are in. For example, you would look at Add an Actor to see the general layout for a basic procedure page.
Game Pages
Example game pages: Unreal Tournament, Unreal Tournament 2004, Unreal Tournament 3
Game pages have a very simple layout and flow that we would like to keep consistent. If you need to add additional subsections, place them under a heading that makes the most sense. If you want to add a new section to an already created game page, please post in the Discussion page about it.
Tutorial Pages
Example tutorial pages: TODO
Tutorial pages do not have to follow any specific guidelines as far as page creation goes. They can include images or not, they can be formatted in any way that makes sense. A tutorial page that is part of a series of tutorials should include links to the next and previous tutorial in the series and, if applicable, to the overview page of that tutorial series. All pages of a tutorial series should have a similar format to one another. For example in a tutorial series about creating a Warfare map, the part that covers setting up the power nodes should not look drastically different from the part covering special objectives.
Commonly required basic steps, like bringing up the properties window to change actor properties, should not be explained on the tutorial page itself. Instead, there is a dedicated set of "mini tutorials" for these steps, called Basic Procedures. Tutorial authors are encouraged to identify basic procedures in their tutorials and factor them out into dedicated basic procedure pages.
Basic Procedure Pages
Example basic procedure pages: Add an Actor, Create a subclass
Basic procedure pages all have a similar layout. If there are several different ways to do things, the page should contain a main section header for each of them. Also, if procedures differ significantly between games, each game should get its own section.
UnrealScript API Pages
Example class pages: Actor, Projectile, Light
UnrealScript class pages have a mostly similar layout. Class members are grouped by the kind of member, for example variables, functions and states, with members being sorted alphabetically or, in the case of operators, by precedence. If it makes sense, variables and functions may be further divided. For example in classes with lots of variables that are mainly used in the editor, it makes sense to divide variables into their property groups, while in classes that are mainly used by programmers it might make more sense to separate localized, configurable or unmodifiable variables. Similarly it might make sense to separate functions into static functions, native functions, events, and so on.
