Reasons why you should write a libRocket plugin and News!

libRocket provides something very useful, the Plugin.

Its just an interface class, you define its methods, and it works like a charm right after registering an instance with the rocket library.

It can be really useful, because you need to maintain only one instance of it, as libRocket has a global initialization nature as well.

Having a plugin you could:

• Dynamically initialize/shutdown libRocket support
• Keep track of all contexts alive
• Keep track of all documents alive, and even what context they belong
• Have a global event dispatcher, that you can bind to, and get events directly to your app
• Register custom documents as specific tags easily
• Maintain the loading/unloading of fonts required by each context, as they go alive or die

Parabola Engine went with this approach and its looking good so far, expect big things soon.

The first public release of the engine is near, you will be able to use it steadily, soon enough.

This means that most low-level systems are almost done, and fully documented. Things such as complex scene graphs with component systems, with skeleton animations and quad trees for rendering are planned, but will be made right after the low-level systems.

The big surprise is that the AngelScript support is looking awesome. The base for dealing with scripts is just doing great!

Its actually possible to render stuff and do other tasks by scripting right now, but they are yet tests.

As soon as i decide the public scripting API, i will implement it full power, along with a nice documentation wiki page.

Expect a series of tutorials to make games with Parabola Engine, by using ONLY scripts. Aimed at all ages!

Status update - 07/10/2011

Heys,

Been so busy lately, always working in the engine and demonstration/testing of its features. Whenever i'm home from work, i do my best to advance the code a little further. I'm aiming my effort at publishing the engine 1.0 version as something usable to make a full game. I would really appreciate having someone helping me with this task, at least with the testing part, which could help greatly to mantain bugs and create new features.

I'm focusing 50/50 in improving consistency of what is done, while inserting new features whenever they seem relevant.

Since i'm constantly learning to go through difficulties in implementation of so many systems, i feel in the duty to share my experiences a little more. So i will make an effort to build little tutorials to share with the world how to do little things. Then, bigger tutorials may come, which may use little tutorials in the middle, but that's for later :)

One big thing that was implemented into the engine lately is scripting support! AngelScript is integrated in Parabola Engine. What does this mean more precisely? Well, anytime, you can create an "AngelScriptEngine" object. It allows you to hold scripts, compile them into bytecode ( possibly saving to files, later), and running them at a specific entry point. You have the freedom to compile and run a script with 2 lines of code, at a function of your choosing, in the script of your choosing. Once you create a new "AngelScriptEngine", it is pretty much useless, tho, it provides auto-configuration utilities. That means you can limit your scripts access to the engine, to make different kinds of scripts for different ends. You can also configure the engine with everything and have a of freedom. This auto-configuration part is being done slowly as the engine goes further, since its passive to changes any time. There will be a scripting manual for each auto-config "module". Right now, you can print things to the screen from a script and use strings. Also, if the GameCore functionality is added to the engine, its scripts will be able to control the game that it was configured for by referencing the "Game" var. "Game.SetWindowTitle("New title")" is an example of a working function, usable already from the scripts.

Also, i've been writing engine documentation for doxygen api reference, as well as writing a wiki with tutorials for engine usage and general game making.

The physics system, Kinesis, an extension of Box2D is really easy to use, completely controllable as intended by Box2D specification. Besides, the physics world is renderable through the SceneRenderer for debugging the simulation. More importantly, i've written a small file format for handling physics. This means you can specify and configure physics entities through a CSS-like text file. Then, you take a KinesisWorld and tell it to parse and open the file, and everything specified enters immediatly into the simulation already existing. Here's a small example:

- Case Insensitive
- Comments as below are not allowed. You can use # to mark the rest of a line as a comment.

World {
            Unique: yes; // is this world to be added to the destiny KinesisWorld, or completely replace it?
             Gravity: 0,10; //gravity force
}

Body.mybody1{
       Position: 300,400; //where in the world is this body center of mass?
                                    // Position coordinates are converted internally automaticly, for optimal sizes
                                    //(see Box2D manual)
       BodyType: Dynamic; //is the shape dynamic or a static one? maybe  a kinematic?
     
       Shape {
                  ShapeType: Circle;
                  Pin: 0,0; //where to fix this shape, relative to the body position;
                  Dimensions: 20;
                  Friction: 1;
       };

       Shape {

                  ShapeType: Box;

                  Pin: 100,0; //where to fix this shape, relative to the body position;

                  Dimensions: 20, 30; //dimensions of the box

                  Friction: 1;

       };

}

Hopefully, in the middle of everything i will find time to write a proper website with a proper documentation for releasing the engine as it deserves :)

There is more to say, but i will leave it to a next time!