Before we go any further I would like to point out a couple of bits of terminology you may encounter as you explore Skyline. Don’t worry about understanding this yet as this is the lowest level of abstraction. There are many workflows that operate at a higher level and as such are easier to follow.
Oh what do I mean with “Abstraction?” This is a way of hiding complexity in Skyline, we have provided a rich feature set with many workflow routes and this can be very daunting to a new user or someone who just wants to have fun in a 3D environment. We hide the complexity with a range of editors and tools to create a range of abstraction from low level to high level, where high level provides the easiest and fastest workflow and low level for the experienced user who wants maximum control over their games development.
The scene is the main 3D view where all the main fun happens. Skyline is WYSIWYG so you get to see what your game looks like from the scene view as you develop it.
Is the rendered asset in the scene, it is the base type that all other types are built upon. An Entity on its own is generally a static device such as a light, model, empty node and we build upon these by adding actions, scripts and graphs to make a more dynamic object. This is a low level feature.
IMAGE
A manageable list of all the entities in the scene. These can be dragged in to folders and renamed to help you manage a larger scene.
This is an entity add-on and Skyline provides many of these actions that do different tasks. It is a C++ side widget that adds functionality to the entity. Any functionality added via an action is very performance friendly but the least user customisable, although many actions are provided with a variety of user tweak-able options. An action can be used to make the entity become a physics object, lenflare object, water object, scripted object and so on the list is big and growing as we find new ideas for actions. Actions are also a low level feature.
IMAGE
Properties or options are setting that can be changed to make various parts of Skyline behave how you want them to.
Panels are editor tabs which can be grouped together or torn off the editor and placed in another location. These panels contain properties and sub editors such as the Terrain tools and particle effects editing.
Is an entity that has been upgraded through the use of an action or via script to act as a physics interactive player capsule for user as a game player or ai player.
IMAGE
Is a fully loaded entity complete with user properties that control the objects features. These go objects interact with the go players and are seen as reusable game ready items that you can just drop in the scene and with little or no changes that will run in the game.
Game objects are Skylines highest level of workflow abstraction and makes it very easy for you to develop your game idea.
IMAGE
Each Game object has easy to use customization parameters ready for you to mod:
IMAGE
Now when it comes to scripting and movement the differences between entities, rigid bodies and controllers are very important. Please see the scripting section: here…..
[Move to scripting section] Entity and Controller - What is the main difference between these especially when we need to move AI characters with script?
1a) An Entity that has no physics applied in the scene, can be moved by the entity.move() command. The entity’s properties are available through the Lua entity.library().
1b) However, if you have physics action “Physics Rigid Body” attached to the entity you are scripting, then you would have to use the physics.library() commands (generally these are forces for controlling dynamics) to move the body as the physics body moves and rotates the entity in the scene automatically as part of skyline's main frame update. This is why when you place a dynamic ball in the scene it falls but there is no more movement code required.
Now, this paradigm changes when it comes to characters and there are 2 different routes:
2) Using the action “Simple Character Controller”(SCC) which is a kinematic physics device that has no automatic forces applied to it. If you use this action, then the character capsule is setup via the action and you need to use the character.library() functions to move the capsule around. Lua Character
3) If you have no actions applied apart from a micro script and you dynamically spawn the character capsule at runtime through the DCC system again this is a kinematic controller. Then you need to use the lua controller.library() commands instead of the character ones. Lua Controller
For both of these character/controller systems, since a physics character capsule does not rotate, the forward movement applied to the character.library() functions is that of the entities forward axis. So for example, if you call move on the character controller using character.move(obj, 1), then the character will move in the entities forward direction. If you were to rotate the entity using the entity.yaw() command, the move of the character controller would start the turn the character around.
This is the same for both the character and controller lua libraries.
So to recap:
- No physics at all and you want to manipulate an entity: entity.library() commands.
- Rigidbody applied to entity: physics.library() commands to influence the automatic physics calculations via forces.
- SCC action applied (no rigidbody action): character.library() commands to control the SCC Action.
- DCC action applied (fully scripted): controller.library() commands to control spawned controllers.