psyclonist's blog

Have a look at the previous entry first.

While it was nice to get this working, it required to run Lua code after the object has been acquired (from a creator, or a querying functions or ...). Not good. Especially, as it introduces the need to rework these functions to run this Lua code as well as run additional code to bind the 'native' Luabind-bound properties (urgh).

To make a long story short: The meta table operations are now handled from the C++ bindings libraries (Yake's bindings.lua) by hooking into the original Luabind meta tables. Works pretty well so far. Properties/Methods/Operators/etc bound with Luabind are correctly exposed (taking into account class hierarchy) while the dynamic elements (dynamic properties, dynamic events, finite state machines) are handled via meta table callbacks.

C++/Lua samples are in the 0.7.0 release. (Available as of today as a RC1.)

Compare these two pieces of Lua code which both do the same thing:
Assign an object's property 'visible' the value 'true'.





Now, which is more readable? Lua is a great language, especially for embedding.

I started with getting the first version to work. It's pretty close to the C++ interface for object/entity scripts. Extending this to the second, more readable version, takes just a handful lines of Lua code which set up the meta table for 'this.properties' (by overriding _index and __newindex and running some additional booststrap code).

Writing these bindings is a really enjoyable experience.

It took some time. And way too much of it. But finally the RC1 for Yake 0.6.0 is packaged and uploaded.

In the meantime, I threw together a boost::asio based prototype that could well replace the current yake::net packet layer. I like this library once I've managed to wrap my head around one or two design issues.

I recently finished the server side code for value replication over yake::net. The client side will be quite primitive in the 0.6.0 release.

I took the chance to test a design that favors static types and nearly completely avoids runtime decisions. On the other hand, it's flexible enough to allow runtime configuration of certain parameters (when useful) and hooking up with scripted properties (yake::property and yake::bindings.lua) and other libraries. I'm quite happy with it.

The books of the usual C++ suspects, err, gurus (Meyers, Alexandrescu ...) were helpful companions. There's always something new on each reread...

I may have to postpone the basic replicated objects library (yake::netrepsvc). I want to get it right the first time but a release is simply overdue.
 Furthermore, I came up with alternative design which may fit even better...

The transition to the premake based build script generation was quite painless. I'm surprised how easy it is to use after a few small initial struggles. Setting up a new component and/or demo takes copy'n'pasting two lines (additional lines depend on the number of dependencies, mainly).

While the MSVC output looks good the Linux makefiles need some more work. Especially, the detection of installed dependencies.

The main benefit is, of course, that most if not all of the build script management/maintenance can be done centralized in a small number of human-readable scripts independent of the platform in use.

Along with the changes in the build script management I took the opportunity to rework the naming scheme of the libraries (explained in yake/BUILD) as well as a slight but very useful restructuring of the directory layout.

Now on to the final work before releasing 0.6...

I'm quite happy with how the network service concept turned out. It's better explained in the upcoming manual (Yes, I'm actively working on it and a first draft will make it into 0.6).

The gist is that applications can register services with a net::IServiceHost which itself manages packet and event connections as well as starting and stopping attached services. Makes development and maintenance of different protocols easy. (Besides the obvious design benefits.) Services can make use of the IServiceHost's connection classes as well as subscribe to certain net::Events (by event and/or by channel).

0.6 will ship with 3 basic services (actually, it's 3 pairs of services: for each type of service there's one concrete service implementation for the client and one for the server): communication (chat, multiple channels, ...), time synchronization, basic object replication (for yake::ent objects).

I wanted to create a graphical demo but ran into problems trying to create to create a skin for the GUI lib used. I have an idea...

Time synchronization between yake::netsvc server and clients has been implemented several days ago.

On LAN it looks very promising: it reaches convergence in a very short time and the difference stays low enough (usually at ~2ms). Of course, Internet connections are different matter.

After cleaning up the existing code for the netsvc component and the demo services (time synchronization, communication/chat and replication) it's time for the 0.6.0 release of Yake.

I recently added the notion of 'services' to yake::net's high-level client/server host objects.

One of the first services that had to be implemented was synchronization of time between servers and clients. (Other services include 'communication' aka 'chat' and 'replicated objects').

After reading over Network Time Protocol (Version 3) Specification and Simple Network Time Protocol (SNTP) I decided to use a simpler approach.

Beside others I found an article on A Simple And Robust Time Synchronization Technique helpful.

Finally. Physically simulated avatars (physics::IAvatar) are now fully 3D, i.e. they work in varying gravity fields (e.g. using the yake::physics's body affector zones or global gravity settings). There're probably a few problems left in certain situations but it's already working quite well in the demo where the player can run and jump around on a little planet/sphere.

The tricky part was to find out how to properly define the avatar's orientation internally (as that can differ from the underlying physics object's).

Now it's time to clean up the demo, commit the changes to SVN HEAD and return to finishing the network code.

I'm working on the demo network component for Yake and ran into one or two design issues. It always amazes me what amount of pain we can avoid by doing a bit of thinking. In this case, I factored out the use of a dedicated network thread. Well, not completely, as it's now an option. But the official samples will be single-threaded at first. (Except perhaps for resource loading.)