In the next 3 posts about Laboratory2D i will be covering some of the things I have been working on in Lab2D for my game, and how they benefit you as a user.

Networking.

Networking in Laboratory2D makes use of the small, lightweight and fast library called ENet. http://enet.bespin.org/ ENet is described as "a relatively thin, simple and robust networking communication layer on top of UDP". So, think TCP but over UDP. What this means in non-technical speak is that you can get reliable, in order delivery of packets. For example, a card game. The packets that are sent over the network are critical for the functionality of the card game to make sense. If player one has made a move that is not yet noted on player two side, the game cannot continue. ENet allows packets to be sent and internally it will order them, and ensure delivery for you. If a message gets lost along the way, it will resend if it needs to.

Now on the Lab2D side we have another lightweight wrapper. More specifically, the technology inside the C++ core is exposed directly as functionality in the script language side. Lab2D supports P2P, as well as 'master server' style networking. One client calls net.host(), and another can simply call net.join() and they can play. All the networking is managed by the scripting, and exploits the dynamic nature of the events and language features of javascript so your networking code will be easy to integrate. And, as it is just online networking it is possible that clients can play cross platform too. An iPhone client can connect to a PC client and be connected via P2P or a server. The details of this are up to the game to implement how it will work - but it is a possibility.

 Filesystem.

The file system in Lab2D was built to be as secure as possible. Not that it is possible to eliminate security holes, but to allow better control over what the client program can change. All files packed into the database use a two way system of encryption and compression. Data like textures, images, font files, and scripts - are all packed into the database. On their way in, they are compressed using LZMA (7-zip) compression, and optionally they can be encrypted using a public/private key pair encryption that is tamper proof. What it means - is that if the client or something else has changed the data in the file system at all - it will not be able to unpack the file. This ensures that the clients are playing fair, and that their client has some sort of integrity checking. 

Once your files are packed in, the file system tools will allow you to make a shipping package (like a zip file) and your code wll work as expected. There is nothing special required to load a file from the file system, as it maps itself onto the folders for you. To the average user of your game, your assets and scripts will be secure to an extent, to help distribution on digital portals.

The last interesting feature of the file system is that it is possible to do in place updates of files from a remote server. For example - let's say I had written a client script that fixed some issues in the pause menu. I can run a small dedicated server version of Lab2D with a flag that tells it to be able to serve the files to my game's clients. Instead of needing everyone to redownload everything Lab2D will listen for clients who start up. If a client has chosen to update their game, it will automatically update all the latest changes since the last time they updated by version number. It is almost like a 'push' or a commit to version control. You update the server code with a new minor version and whenever the client starts up, if it can access the server, it will notify them of the updates and allow them to update the game quickly and easily.

 That wraps up the first of three posts! While all of the features and systems are written in some form or other, certain parts of the above are still being wrapped up in the script engines. They should be in the beta within the next short while.