Gluon: Difference between revisions

    From KDE UserBase Wiki
    No edit summary
    Line 18: Line 18:
    <dd>Contains information needed by the people working on Gluon itself, such as header listings, coding guidelines, internal APIs and the like. If you want to simply use Gluon to build games, this section is irrelevant to you.</dd>
    <dd>Contains information needed by the people working on Gluon itself, such as header listings, coding guidelines, internal APIs and the like. If you want to simply use Gluon to build games, this section is irrelevant to you.</dd>
    </dl>
    </dl>
    ==Gluon Basics==
    Games built using the Gluon game engine, <em>GluonEngine</em>, are called GameProjects. They consist of a variety of different types of objects, which work together to create a game. The following is a short introduction to how the structure of a GameProject works. You can start working with Gluon Creator without this knowledge, but it will make your life easier if you understand these basic terms, as they are used throughout the rest of the documentation.
    <h1>The GameObject Hierarchy</h1>
    At the top of the Gluon GameObject Hierarchy is the <em>GameProject</em>, which is basically your entire game. A GameProject contains one or more <em>Scenes</em>, which can be anything from a level map or a menu screen. A Scene is composed of one or more GameObjects. A <em>GameObject</em> is a tree of GameObjects or any number of Components. A GameObject represents a functional unit in a scene, like a Car object, which can also be made up of other parts which are GameObjects in themselves (like a rocket backpack or a weapon). <em>Components</em> provide the logic that operates on the GameObject they are attached to. Components can be attached to any number of Assets. <em>Assets</em> simply represent a piece of data stored on disk, like a sound file or an image file.
    The GameObject hierachy is made up of instances of GluonEngine::GameObject in a tree structure with a parent-child system, each with any number of GluonEngine::Component instances. The Components provide most of the logic in the game, and since so many are usable in so many places, Gluon would ship with a number of pre-created Components (such as a Camera, Input handlers, MeshRenderer, TextureRenderer and so on).
    The logic behind creating this system is to enable the game programmer to enforce encapsulation and create reusable components, which can then be applied to numerous GameObjects. It also allows for sane separation of the different types of logic required for each part of a GameObject, thus potentially creating cleaner, more readable code. At the same time, the structure described here would allow for the creation of a graphical tool to manage all of the components' settings. Components are implemented as plugins, making the code even more flexible and separated.
    <h2>More on Components</h2>
    Components are like properties that you can attach to GameObjects, such as a "render" Component that actually makes the GameObject visible, or a "SoundListener" Component that gives the object the ability to listen to sounds. Components can also be scripts that controls the behaviour of the GameObjects attached to them. All GameObjects in Gluon have their Transform properties built-in, giving the object its position, rotation, and scale (it doesn't make much sense to have an object that doesn't have at least a position). Components do not have Transform properties, but the GameObject to which a Component is attached to does.

    Revision as of 08:52, 6 July 2010

    Intro


    This section gives you a set of documentation for the various parts of Gluon:

    Gluon Basics
    Games built using GluonEngine are all built in the same way. This chapter describes shortly how this works. If you do not already understand how systems based on the GameObject/Component paradigm work, this is where you want to start.
    Introducing Creator
    Once you understand the basic layout of a game built with GluonEngine, you are ready to look at Gluon Creator, the tool with which you build the games. This chapter describes the user interface and the workflows of the tool.
    Creating Games
    Once you have read the two first chapters and feel ready to start building games with Gluon, go right ahead and do so. Should you get stuck at some point and need further help with specifics, this is where you want to look.
    Using the Libraries
    This chapter contains the information needed by those who wish to use the libraries directly for building games. GluonInput, GluonAudio and GluonGraphics are presented within.
    Hacking Gluon
    Contains information needed by the people working on Gluon itself, such as header listings, coding guidelines, internal APIs and the like. If you want to simply use Gluon to build games, this section is irrelevant to you.


    Gluon Basics

    Games built using the Gluon game engine, GluonEngine, are called GameProjects. They consist of a variety of different types of objects, which work together to create a game. The following is a short introduction to how the structure of a GameProject works. You can start working with Gluon Creator without this knowledge, but it will make your life easier if you understand these basic terms, as they are used throughout the rest of the documentation.

    The GameObject Hierarchy

    At the top of the Gluon GameObject Hierarchy is the GameProject, which is basically your entire game. A GameProject contains one or more Scenes, which can be anything from a level map or a menu screen. A Scene is composed of one or more GameObjects. A GameObject is a tree of GameObjects or any number of Components. A GameObject represents a functional unit in a scene, like a Car object, which can also be made up of other parts which are GameObjects in themselves (like a rocket backpack or a weapon). Components provide the logic that operates on the GameObject they are attached to. Components can be attached to any number of Assets. Assets simply represent a piece of data stored on disk, like a sound file or an image file.

    The GameObject hierachy is made up of instances of GluonEngine::GameObject in a tree structure with a parent-child system, each with any number of GluonEngine::Component instances. The Components provide most of the logic in the game, and since so many are usable in so many places, Gluon would ship with a number of pre-created Components (such as a Camera, Input handlers, MeshRenderer, TextureRenderer and so on).

    The logic behind creating this system is to enable the game programmer to enforce encapsulation and create reusable components, which can then be applied to numerous GameObjects. It also allows for sane separation of the different types of logic required for each part of a GameObject, thus potentially creating cleaner, more readable code. At the same time, the structure described here would allow for the creation of a graphical tool to manage all of the components' settings. Components are implemented as plugins, making the code even more flexible and separated.

    More on Components

    Components are like properties that you can attach to GameObjects, such as a "render" Component that actually makes the GameObject visible, or a "SoundListener" Component that gives the object the ability to listen to sounds. Components can also be scripts that controls the behaviour of the GameObjects attached to them. All GameObjects in Gluon have their Transform properties built-in, giving the object its position, rotation, and scale (it doesn't make much sense to have an object that doesn't have at least a position). Components do not have Transform properties, but the GameObject to which a Component is attached to does.