About Gluon Creator

So, I originally planned to talk about this in my blog post about the Gluon sprint, but that post became really long so I decided to split it up into two parts. In this part I will talk about Gluon Creator, what it is, what we have planned and how far we are.

About the Creator

Modern game engines can be split up in basically two ways: those that compete for "Best Graphics" and those that compete for "Most easy to use". Many of the AAA-games run on an engine classified as the former, but a fairly large market is growing for the latter, the market of "Indie games". The studios developing these games often do not have the resources to pay for a big-budget AAA-style engine, or to develop their own. These studios have a limited budget and therefore want to be able to develop games as fast as possible. Tools like Unity3D and Flash are therefore very popular in that they provide an environment to allow fast game creation, with a low cost for the actual engine.

Our goal with the Gluon Creator is the same, create a tool that allows designers and artists to easily prototype and create games. We are using several ideas from Unity3D, but do not restrict ourselves to that program. We want to create a tool that is very easy to use, yet still has all the power necessary to create complex games. The Gluon libraries are an important part of this, as well, as it is the GameObject structure that enables us to modularise most of the editing and creation stuff.

One of our main "Unique Selling Points" will be the fact that we are an open source project. We do not want or need to keep everything closed and locked down. Instead, we can provide a tool that is flexible and customizable. We can provide a tool that with some minimal configuration allows for a multitude of games to be created. In fact, we are planning of several things that will make it very easy to do just that - customize and extend.

The Interface

Interfaces for complex content creation programs are quite hard to do. Every developer and designer has his own way of doing things, his own way of handling things. (This is of course a general problem with interfaces, but more so with content creation programs.) One way to solve it is to allow for easy customization of the interface. This is in general the "KDE-way" and is done by many professional content creation programs. Like many of these content creation programs, we want to create an interface consisting mainly out of docks. It allows for very easy customization of layouts, which means users can easily adopt it to their needs. We discussed the interface at the sprint a bit and came to the following docks:

• Scene: Displays a tree of current objects.
• Project: Displays the contents of the current project. (Scenes, assets, etc.)
• Properties: Displays and allows one to edit the properties and components of the current selected object.
• Components: Displays a list of available components, to be dragged onto objects.
• Preview: Displays a preview of the current scene
• Edit: Displays the current scene and allows one to edit it.

Later on I added the following:

• Messages: Displays messages posted during editing or previewing of the game.

These are the core elements of the interface. We will also be adding some utility tools that will pop up as separate windows or dialogues. For example, the code editor will be done is this manner. Both the docks and tools will be pluggable, to allow others to create plug-ins for specific things. The standard docks and tools will also be built using the same plug-in structure, giving people the freedom to replace docks and tools as they see fit. (Note that I came up with the idea of a pluggable Creator while writing this blog post, so we do not have anything concrete set down for that yet.)

Creation of a game using the creator will most likely have a work flow like the following:

1. Create a new project
2. Create a scene
3. Add some objects to the scene
4. Add components to the objects
5. Set the properties for the objects
6. Test
7. Repeat
8. ???
9. Profit!

(Yeah, ok, the last two should probably read "Publish" and "Play"...)

Of course, this leaves out many things like interactions between objects and all that stuff. But these are the basics, a work flow that is, in our opinion, very simple and nice and also quick to learn. For example, creating a breakout-like game would be quite easy. First, you need to create a paddle, a ball and a block. Then add collision and sprite render components to all three. The paddle also needs a KeyboardInput component that moves the paddle left and right. The ball needs a KeyboardInput component that gives it some starting velocity when you press space bar. As a last thing, the block needs to be destroyed on collision with the ball and the ball needs to be destroyed when it collides with the bottom of the screen. All that's left is some glue scripting to define win/lose conditions and we're set to play. :)

Gluon Definition Language

At the heart of any Gluon game will be the Gluon Project. This describes all the content of the game, the assets, scenes and everything. One of the core elements of a Gluon project is the scene and the file that describes this scene. For describing this scene, Dan Jensen has created a very simple declarative language. One of the things I worked on during the sprint, was helping Dan to get this code up and running. Therefore, I created a very simple application that would parse and display a file using GDL syntax. The following is the GDL code I have been using to test the parsing:

{ GameObject(root)
    { TextureAsset(PaddleSprite)
        file string(paddle.png)
    }
    
    { GameObject(Paddle)
        position vector3d(0;0;0)
        
        { KeyboardInputComponent(PaddleController)
        }
        { CollisionComponent(PaddleCollision)
        }
        { SpriteRenderComponent(PaddleRenderer)
            sprite asset(root.PaddleSprite)
            size size(5;1)
        }
    }

    { TextureAsset(BlockSprite)
        file string(block.png)
    }
    
    { GameObject(Block)
        position vector3d(0;10;0)
        
        { CollisionComponent(BlockCollision)
        }
        { SpriteRenderComponent(BlockRenderer)
            sprite asset(root.BlockSprite)
            size size(5;1)
        }
    }

    { TextureAsset(BallSprite)
        file string(ball.png)
    }
    
    { GameObject(Ball)
        position vector3d(0;1;0)

        { KeyboardInputComponent(BallController)
        }
        { CollisionComponent(BallCollision)
        }
        { SpriteRenderComponent(BallRenderer)
            sprite asset(root.BallSprite)
            size size(1;1)
        }
    }

}

This structure describes a breakout-like game with a paddle, a single block and a ball. A more in-depth explanation of the GDL syntax can be found here. The end result of my work during the sprint was the following:

This example shows the entire tree of objects on the top and only the GameObjects on the bottom.

Current State

As I basically implemented the Scene tree model for Gluon Creator, it was decided that we would expand on the example program I wrote to build the creator. So, I set out to create some additional docks and a few basic actions to define the basic interface for the Creator. After a bit of hacking, I had the basic interface set up.

Later on, when I did some more hacking I discovered the "setDockNestingEnabled" switch of QMainWindow. This switch allows for quite complicated dock layouts. The first time I tried it I was using an empty QWidget as main widget. This gave some problems with the docks, because it would not collapse the centre between the dock widgets. After browsing a bit through the Amarok source, specifically their MainWindow class, I discovered that they do not use a central widget. After removing the central widget from the creator code, I discovered that now it collapsed the centre area, giving us basically a fully dock-able, fully customizable interface.

Below is a screenshot of the latests version of the creator:

(Click here for full version)

Yes, we have a lot of work ahead of us. But the beginning is there, the vision is there and the will is there. Now all we need is time. :)