PaperWorld is many things - it lets you create multi-user applications, yes, but it also gives you the tools to create large games, quickly, localise them to a particular language or region, and manage everything in your workflow - so your designers don’t need to code, and your coders don’t need to design, and anyone with a basic knowledge of xml can edit a config file and setup or edit a game quickly without having to recompile and deploy.
So how does it do all this?
The basic building block of a PaperWorld application is the module - A module is made up of a set of files (referred to as ‘components’ in PW3D) - each of which has a specific purpose.
By creating these files and putting them into a convenient directory you can load them when you need them as a single block - PaperWorld takes care of the heavy lifting - you just list the modules that are needed for a game and PaperWorld takes care of it all for you.
Each module has its own conf.xml file, which describes all the files that it contains. When you tell PaperWorld3D you want to load a particular module it loads this xml file and then loads each component of the module that’s listed, so when the module is ready all the contents of these files are available to you.
That’s all very interesting, but how do i create a multi-player game?
Creating a multi-player game with PaperWorld couldn’t be easier (trust me, i’ve tried) - if you’re familiar with using Papervision3D you’ll have no trouble at all. A new type of Scene - RemoteScene - handles all the difficult bits for you - and a new type of object - PaperworldObject handles syncing itself with the server and among all the connected clients. You just have to tell PaperWorld which model your object will use:
var scene:RemoteScene = new RemoteScene();
scene.addChild(GamePlayer.getInstance().avatar);
That’s it, simple enough?
The RemoteScene registers with the server, if there’s already a scene there, it makes sure that any objects already in the scene are given to your client and presented to you. If not then a new Room is created and a new simulation starts up.
The PaperworldObject handles keeping itself updated and synced amongst the clients, so you don’t have to worry about client-side prediction, adapative smoothing, handling latency - it’s all done for you, transparently, by the PaperWorld3D framework.
There Can Be Only One.
In PaperWorld3D there is only one simulation and it runs on the server. All the clients connected to that simulation see a slightly delayed version of it. So everyone is slightly wrong, but the server knows what’s right.
When a user does something with an input device (!) like pressing a key to go forward or moving their mouse then that input is sent to the server. It’s sent as a Boolean value (like forward=true or roll=false etc. etc.) and the server interprets that input using an Avatar object.
The Avatar ecapsulates behaviour
The Avatar is a class that interprets input. So it could interpret forward=true as moving itself forward by 10 units, or it could just as easily interpret forward=true as ‘make a hotdog’ or ‘tell a joke’ - you write the Avatar so you decide what action it takes for a given input command - it can be as simple or complex as you like.
The same Avatar exists on the client and the server for each object in the scene, so the client’s local object will interpret input in the same way as the server does, it then just gets corrected when an update is received from the server.
Is That All?
Absolutely not, there’s a huge amount of functionality and cool stuff in the PaperWorld3D framework (and even more coming very soon) this post is just designed at giving you a rough idea of how things work and how easy it is to use.
If you want to know more about how all this works then there’ll be a series of articles on this blog giving you the low-down on what happens behind the scenes (pun intended) and how you can extend and build upon what’s in the libraries.
