= How to create Orxonox Levels =
[[TracNav(TracNav/TOC_CC_Tut)]]
It it recommended to first have a look at some of the existing levels. In the single player menu at the tab all to the right you find a complete list of all orxonox levels.
== Create the basic file ==
1. Go to the folder __../data/levels__. The level files ending with .oxw are simple XML files and can be opened with any editor. Each level file stored in this folder can be selected later in Orxonox.
2. Copy „empty_level.oxw“ and paste it again in the folder.
3. Rename the copy. Try to use a name that sounds good. Avoid whitespace – use „_“ or CamelCase instead.
4. Open your level with your favourite editor.
== About XML ==
XML is a description language that looks similar to HTML. We use '''tags to describe objects''':
{{{
#!xml
}}}
A '''''' can contain several '''attributes'''. An attribute is the place where '''a value is set'''.
{{{
#!xml
}}}
The syntax is '''attribute=“value(s)“'''. If only one value is set, the quotation marks are not necessary.
Tip: XML files do not have to be compiled. If you changed a level file (and didn't forget to save it), you simply have to reload the level to view the changes. If your level doesn't load have a look at the terminal by pressing [alt] + [tab].
== What it's all about ==
By describing a level via XML you actually '''add C++ objects''' to the level. Each tag starting with a capital letter refers to a class that contains a XMLPort function. In order to understand better what a certain tag is doing it is recommended to read the corresponding source files.
Example: The tag shown before refers to the [http://www.orxonox.net/browser/code/trunk/src/orxonox/graphics/Light.h light class].
== First steps ==
1. Define the level's '''name''' in the menu. The '''description''' will be displayed in the level selection menu when a player hovers his mouse over your level's "name". '''screenshot''' should be a *.png image placed in the __data_extern/images/levelpreviews__ folder. This should be the first tag in the XML file.
{{{
#!xml
}}}
2. Decide wether you create a level for a specific '''gametype''' or a '''single player mission'''. The gametype is set in the tag.
{{{
#!xml
}}}
3. Set the level's backgroud (skybox). The skybox is an image of what you can seen on the horizon. You can add an new skybox by changing the corresponding parameter:
{{{
#!xml
}}}
Possible values for skybox are:
|| "Orxonox/Starbox" || "Orxonox/skypanoramagen1" || "Orxonox/skypanoramagen2" || "Orxonox/skyBoxMoreNebula" ||
== Basics ==
* '''Worldentity''': Point in space with orientation ( ~point with a vector attached to it).
* '''Static Entity''': Worldentity with a fixed position and fixed orientation.
* '''Movable Entity''': Worldentity that can rotate or move constantly.
* '''Controllable Entity''': Completely freely movable point. Usually steered by a controller.
* '''Model''': Each visible 3d-Object. A model consists of a mesh (the form) and a material (the surface colouring).
* '''Collisionshape''': A Collisionshape is the physical representation of a model. Currently collisionshapes only have the form of a sphere, cube/ashlar, cone or plain. For StaticEntities the collisionType is „static“. Movable Entities have the collisionType "dynamic". At the moment static collisionshapes do not provide a shield against bullets. The collision of projectiles is only detected by dynamic collisionshapes. Another significant difference: If you collide with a static collisionshape, you'll be pushed away. If you collide with a dynamic collisionshape you'll push the dynamic collisionshape and it's movable entity away.
Or even more vivid - if you place two movable entities with collisionshapes too close together, such that the collisionshapes ovelap, they'll burst apart. If both objects are static they will stay as they are, although their collisionshapes overlap.
== Worldentity + Model + Collisionshape = adding objects to the level ==
{{{
#!xml
}}}
The StaticEntity defines the model's place and orientation (and some other values). The Model (a cube) is attached to the StaticEntity. With the proper sized collisionshape attached to the StaticEntity you have a "solid" cube. Without a collisionshape, the cube wouldn't be solid and your spaceship could just fly through it. This exampe is quite useful, since you usually can't see a collisionshape's size. If you combine an invisible collisionshape with a fitting model you can see where a collisionshape is for testing purposes. In this special case both the '''scale3D''' and the '''halfExtents''' parameters are identical.
== MovableEntity - Let's get the world moving ==
Worldentities can be attached to other worldentities. If you want a model to move in circles, you can create a MovableEntity that rotates and a StaticEntity attached to it. The model that should be rotating is attached to the StaticEntity.
{{{
#!xml
}}}
Note that in this example the Model is created by a lua script that is called in a lua tag. Lua is a scripting language that is a very powerful tool for level design.
== Models ==
A level depends on its models. All finished models are stored in __../data_extern/models__. If you want to view most models in the gallery.oxw level.
At the moment we have several asteroids, spaceships, a satellite, two different space stations and some smaller models.
== Spawnpoints ==
A Spawnpoint is the '''entrance point''' for controllable entities (spaceships). Without a spawnpoint no level can work!
{{{
#!xml
}}}
You can define which kind of spacecraft a player/ bots can use. Additionally the corresponding template has to be included:
|| '''pawndesign''' || '''include()''' || '''additional information'''||
||spaceshipassff||"templates/spaceshipAssff.oxt"||default spaceship - equipped with rockets||
||spaceshippirate||"templates/spaceshipPirate.oxt"|| ||
||spaceshipswallow||"templates/spaceshipSwallow.oxt"||fast, nice design||
||spaceshipHtwo||"templates/spaceshipH2.oxt"|| ||
||spaceshipghost||"templates/spaceshipGhost.oxt"||stealth aircraft ||
||spaceshipHXY||"templates/spaceshipHXY.oxt"||||
||spaceshipHXYSL||"templates/spaceshipHXYSL.oxt"|fast||
||spaceshipTransporterSL||"templates/spaceshipTransporterSL.oxt"||slow transporter||
||spaceshipTransporter||"templates/spaceshipTransporter.oxt"||slow transporter, equal to SL version||
You find all spaceship files in __../data/levels/templates__. The first entry in a file reveals the pawndesign:
{{{
#!xml
.
}}}
If the level is designed for several teams you have to use team spawn points.
{{{
#!xml
}}}
== [http://www.orxonox.net/doxygen/classorxonox_1_1_pickup_spawner.html Pickups] ==
Pickups give a player a temporary bonus when collecting it. Bonuses are invisibility, health, boost, shield, a drone, ...
1. Include the pickups.
{{{
#!xml
}}}
2. Add a PickupSpawner. An invisible device that puts pickups in the level.
{{{
#!xml
}}}
'''Pickupspawner - attributes''':
* '''triggerDistance''': Distance to collect the pickup. The larger the triggerDistance, the easier it is to get the pickup.
* '''respawnTime''': After respawntime seconds a new pickup will appear, if the pickup had been collected.
* '''maxSpawnedItems''': After maxSpawnedItems no further pickup will appear.
'''Pickups - have a look at pickups.oxw''':
|| ||||||
|||| ||||||
|| || ||||||
|| ||||||
|| || ||||||
|| ||||
== Billboards ==
Pickups are represented by billboards. Billboards are 2D images that are always facing the viewer. A 2D circle image seems to be a 3D sphere. E.g. The blinking lights on the assff wing are realized via billboards. Example of a static light sphere:
{{{
#!xml
}}}
Billboard in action:
* Mark points of interest with a light. Maybe this will attact the player.
Have a look at "theTimeMachine.oxw" to see some further billboards in action.
== ForceFields ==
ForceFields push the player in a certain direction if the ForceField was triggered.
{{{
#!xml
}}}
As you maybe already have noticed - you don't have the ForceField to be attached to a Worldentity.
ForceField in action:
* Place the ForceField next to the Spawnpoint to give the player extra boost when entering the level.
Have a look at "asteroids.oxw" and "theTimeMachine.oxw", to see how to make ForceFields visible in the level.
== Lua ==
Lua is the scripting language we use in our levels. At the beginning of the file templates for spaceships, the hud and more are loaded. What lua does in this context is editing the XML file and inserting the concerning XML (of the spaceships, hud, ..) before the level is loaded. That's why you cannot rely on the line numbers displayed when an error occurs, since before loading lua changes the file.
A quick overview over Lua: [http://tylerneylon.com/a/learn-lua/ Learn Lua in 15 minutes]
What lua can do:
* load external skripts: for example the cuboid spacestation.
{{{
#!xml
}}}
* Create a bunch of objects (depending on the index i). Whatever is placed within those lua tags will be created several times.
{{{
#!xml
}}}
Note that '''''' directly inserts the calculated value when the level is loaded.
* Randomized values, sinus, cosinus and more. (Via sinus and cosinus circular shapes can be created easily. The randomization changes your level's appearance whenever it is reloaded.)
{{{
#!xml
}}}
== Triggers && Events ==
Example: ../data/levels/events.oxw
So far your level design is static. Everything is placed in the level, when it is loaded (except the spawned objects) and doesn't change its behaviour once loaded. Via the trigger/event system you can make the level react on what the player does.
A trigger is like a button. When you activate it an event is created. This event can change the status of objects.
This way objects can be activated/deativated and be made visible/invisible.
=== Distance Triggers ===
{{{
#!xml
}}}
'''DistanceTriggers''' are activated, when the target (e.g. a pawn, a spaceship, ...) is close enough to the distance trigger (defined via "'''distance'''"). The '''stayActive''' attribute keeps the switch activated once triggered - the event can only be created once. The name '''flying1''' is needed in order to catch the event, when the trigger was activated. The '''SimpleNotification''' is sent to the player when the trigger is activated. Note that the trigger is activated with a delay of 6 seconds.
The problem of distance triggers is that you have to rely on that the player is actually activating it as intended. Try to attract the player by using bliking billboards, pickups to reward the player, ... and make the radius large enough such that the player can hardly miss it.
Another problem might be that the distance trigger is triggered by another Pawn/Spaceship/... (whatever is specified as target). To exclude certain objects to activate the trigger or to only allow a specific object to activate the trigger, the DistanceTriggerBeacon was created.
{{{
#!xml
}}}
{{{
#!xml
}}}
=== Other event sources ===
{{{
#!xml
}}}
=== Advanced Triggers ===
{{{
#!xml
}}}
=== What events can do ===
* Making objects (in)visible:
{{{
#!xml
}}}
* (De)activating objects:
{{{
#!xml
}}}
* Executing ConsoleCommands (= executing code):
{{{
#!xml
}}}
== Quests ==
Example: ../data/levels/quests.oxw
== Content from External Sources ==
* http://www.blendswap.com
* http://opengameart.org/
* http://freesound.org/