|
|
QSDK 1.1 Documentation |
|
|
The art assets of the demo are not installed by the default QSDK installers, because of their size. They come with the QMedia installer available here. You need to download them if you want to build the Q data from the art assets.
The entire scene and the entities can be browsed and viewed by loading the QDemo2 project file in QStudio.
Entities are game things. Any item which has dynamic behavior that the game code must control is called an entity. For example, a static light in a room does not need to be an entity as the game code will never need to change the color, move it, make it flicker etc.. However, a flickering or moving light requires game code control to bring it to life and will normally be represented by an entity. Entity instances acts as entry points in the Q world for the world to act on it and control it. They are defined in the entity schema and placed in the entity placement.
Those two files also contain vital information about how entities relate to each other and to Q data. Because entities are essentially controlled by the user, they need to tell the Q engine what assets they use so that the engine can load them in time, when they are required. This is essential so that CD layout can be optimized to best fit these dependencies. If the engine has been told who uses what, it can then organize the data on the storage in such a way that makes this transfer as smooth as it can. The next paragraphs contain a part about preloading assets. It is strongly advised to also read the streaming notes about preloading and streaming.
The entity schema can be browsed by loading the QDemo2 project file in QStudio.
The entity schema defines all entity types and is therefore closely related to the character design. Each EntityInstance must be given a Type so that the game code knows what to do with it, e.g. if we create an EntityInstance of Type "TriggerVolume" the game code for a given game will know to watch for items entering an associated Region Instance and if one does, play a given script. This type is called the "Entity Type". All of the Entity Types supported by a specific game are defined in a "Game Schema".
The entity schema of the demo has been created and authored when building the demo using QStudio. It is stored in the Game Schema File samples/demos/qdemo2/assets/schema.qgs. Entity types are created by right-clicking on Game Schema in the Q Tree Tool and then clicking on Create Entity Type.
Because the schema defines the asset dependencies and the visualization marker, it requires the Q files mentioned by those, namely:
The game schema relates to the entire demo and synthesizes all game knowledge. So it requires, in general, most of the Q files and that is indeed the case here. The schema file can be viewed and authored in QStudio:
The game schema can then be explored by expanding the Game Schema section in the Q Tree Tool. We now illustrate some of the schema concepts by having a look at the Skrittle type. In the Q Tree Tool, expand the Game Schema node and right-click on skrittle to open its Properties box. The Entity Type panel indicates that skrittle is a moving time and that they may cross portals. This information is essential to the Q engine because it tells it to make sure the dependent assets are loaded throughout the Skrittle lifetime and located wherever it goes. The Skrittle extends the type shootable: this is game knowledge and the code uses to mark the entities that can be blown up by projectiles. The visualization panel associates the skrittle type with a puppet so that when entity instances of this type are placed in the level, they will be represented with that puppet. That allows viewing the level with representations of entities without any intervention of any game code. This is useful when profiling the geometry for performance in order to closely match what the viewer sees in the game but without the extra time spent in the game code. This operation is described later on in this section.
The Preload Assets panel is absolutely vital for building the project. It tells what assets the skrittle entity type use.
Because the entities are implemented by user code, the engine does not have any means to guess what may be used. By telling it this crucial information, it can preload the data before the skrittle entity actually becomes active and can organize the layout of the data in the Q file to closely match those relationships. This information is almost a translation of the information described in the character design: the Skrittle type requires loading the ClusterInstance skheart, its animation (all contained in the skrittle.q file), its QAM file and its sounds. It is also linked to other entity types, such as skrittle chunks and splat decals. By outlining these dependencies, the designer allows the engine to then gather them in the same storage place and to provide faster and smoother access to them. For more details about preloading and clumping, refer to the mastering section.
The placement of the entities of QDemo2 is fully described in this table. Entity placement can be browsed by loading the QDemo2 project file in QStudio.
Once the schema is defined, entities can be placed in the scene. Placement is therefore closely related to the level design. For instance, placement for zone_corridor1 is nothing else but a translation of its entity map into the engine.
Placing entities in the scene was done by designers when building the demo using QStudio. It requires to have an entity schema ready. To place an entity right-click either on some geometry in the scene window or on a relevant node in the Q Tree Tool and select Create Entity Instance. For more information on how to place entities within QStudio, read the entity placement tutorial.
Entity placement information is stored in Game Placement Files. The Game Placement File of the demo is samples/demos/qdemo2/assets/scene.qgp. Since placement relies entirely on the game schema, it requires it to be loaded as well as the Q files used by it before being loaded in QStudio itself:
As explained in the assets section, the scene is only a subset of what we call the level and, in particular, the level contains the placement data whereas the scene does not. To visualize the placement in QStudio as described above, you need to load the scene rather than the level.
You can browse the entity instances by browsing the Q tree or by using the Entity Instance Selection tool. When looking at the properties of an entity instance, you will see three panels. The scene graph section shows the group and the type of the instance. The scope instances section indicates what instances in the Q tree triggers the activation of the entity. Non-moving entities are only activated when those instances come into scope so they must be specified for that category. For instance, the entity instance door1 have two scope instances, 01corridor1 and 01outside, so that it gets symmetrically active when either of them come into scope. The last panel is about preloading and defining what assets are needed when this entity is active.
Once again, the preloading information is crucial to the application and the placement file provides some part of it. In the game schema, entity types specify what they need. In the placement file, entities specify what they need on top of it. Entities sometimes have individual asset dependencies: for instance, a trigger box may trigger some phenomenon that requires some assets and some entity types.
The entity instances can be split among 3 categories. The scenery entities, the moving entities and the effect entities. The scenery entities represent geometry of the scene that needs some extra level of control: bridges, doors, lifts, switches,... Their geometry is part of the scene and gets exported when the scene gets exported. They define scope instances that act as trigger points for their activation. The moving entities usually are characters and creatures. They do not have scope instances; they have a start position because their type is declared as moving. Skrittles, Margoss, Janseth are placed in the scene graph and become active when their Q Group enters the scope. The last category encompasses the effect entities. Those are entities whose lifetime is short, which are spawned at runtime by the demo code and which are not placed. Their type is defined in the game schema but you will not find any of them placed in the level: projectiles, decals, skrittle chunks, etc..
For more information about how doors, bridges, characters, etc... are handled by the code, refer to the Entity Code section in the guide.
The command line tool qview allows for quick viewing of the placement of entities in the level. The level contains the entity instances. The game schema file contains information on how to represent them using visualization markers. Feeding those two to qview, along with all Q files containing geometry for the markers, allows the user to navigate a scene whose geometry matches the one displayed at runtime more closely:
qview level.q assets.q janseth.q margoss.q skrittle.q -d schema.qgs
A empty zone and a zone with fifty skrittles are very different in terms of performance. This visualization mode can quickly give an idea of the geometry cost and an estimate of the time spent in game code.
QStudio also allows to view all markers at runtime. To do so, open the project the way it has been previously described and open the Entity Instance Selection tool. Select all entity instances and click on the Mark button. You can then navigate around the level: skrittles are represented by a puppet, lights by a flag, trigger boxes by a region, etc...
Authoring and importing the schema and the placement file are two slightly different processes. The authoring process is described in the paragraphs above. It produces schema files and placement files. The build process imports those files in the Q files and turns them into database knowledge and entity instances. The visualization data is lost in this import because it is not need at runtime by the demo. The schema file and the placement file work the same way QML file do. The schema file must be imported before the placement file. After this import, the Q file will contain the entity instances in the scene graph.
In a build process, the game schema and the placement file may be imported using qds:
|
||||||||
|
Textures Fonts Scripts |
|
|
||||||
| Particle Effects |
|
|
||||||
| Characters |
|
|
||||||
| Scene |
|
|
||||||
| Sounds |
|
|
||||||
|
||||||||
| Step 1: qds (import the QGS file) | ||||||||
| schema.qgs | ||||||||
|
||||||||
|
|
||||||||
| Step 3: qds (import the QGP file) | ||||||||
| scene.qgp | ||||||||
|
||||||||
|
|
||||||||
|
||||||||
|
|||
|
|
Qube Software Limited © 2000-2004
|
|