I swear, I meant to keep this website up to date!
So… Since last time… Well, I’s too much time for a change-log to be relevant.
The releases can be found on GitHub here!
For this site/blog thing here, I think it would be more interesting to talk about what I’m think next.
So, right now, the engine permit you to to load in levels, execute gameplay code compiled in, or from script, and is compatible with Oculus OVR and OpenVR. Level are a collection of “GameObjects”. They are loaded from binary .mesh files (Ogre’s own serialized format).
There’s a pretty simple implementation of some physics. Basically gravity and collision between rigid bodies. This is achieved thanks to the awesome library Bullet Physics. There’s basic 3D sound with OpenAL-soft, and the rendering is done by Ogre 1.9 and it’s old RenderSystem_GL. What has been interesting it the big reorganization of the code. The formalization of the different component into what I call “subsystems”, and the added molecularity on the VR rendering (that permit to facilitate the integration and maintaining of any VR system used with the engine.
New shiny stuff!
The two most interesting changes made to the engine recently are :
- The ChaiScript based scripting interface
- The UserSpace Subsystem interface, that permit you to put some “engine-land” code outisde of your gameplay code
The scripting interface is here to permit to iterate quickly on things. You have access by name to any GameObject currently loaded on the scene, and you are attached to a “owner” object. A script must define a class that roughly follow an interface similar to the one used by Unity with a “setup” and an “update” method + methods that depends on event triggering.
Annwvyn is now organized as a “core” base running a series of “core subsystems”. Each subsystem is dedicated at one part of the engine’s funcitons : One for audio, one for physics, one for Level management, one for event dispatch…
You have the possibility of creating and adding your own subsystems via this interface, and even firering your own custom events. Theses events will be transmitted to listener by address and not by value, and as a generic parent class. They will hold a mandatory “type” field that is populated by hashing a string of text. That way, the user can test the exact type of the event without comparing strings (as the hash is a numerical value of type size_t). The payload (=content) can be anything you want.
The immediate future of things
I’m have to work on a student project using Annwvyn and doing networking. I want to try out RakNet for handeling some C++ network code since it has been released by OculusVR as OpenSource (I understand, it started open source, then closed and made compatible with every console imaginable…). I don’t have much idea on how it actually works right now, but I have demos and sample code running. I needed to correct a few odd things to make it build, it’s probably due to library differences of newer Visual Studio version.
This means that I’m not planning to change much inside Annwvyn for at least the next few months, and I’m going to try to do something real with it… But that’s good news, because I’m probably going to have bugs hitting me on my face, and they would probably be either stupid, funny, or *interesting*. Gonna be a fun ride!
Source: New feed