
Rob Chadwick is a 3D programmer and artist who has been working in the 3D content field for more than ten years. In that time, he has designed custom game engines, managed render farms, and written productivity tools. He has taught entry level video and photo editing, and offered courses on advanced 3D animation. He has designed simulations for the FBI and the US Navy using custom and off-the-shelf game software, and animated virtual spaces for architecture and interior design companies.
As a contractor with Katmai, Robert provides support to the Advanced Distributed Learning (ADL) Initiative. The views expressed are those of the author and do not necessarily represent the views or policies of ADL.
I’ve recently been doing some work on an open source project called the Virtual World Framework (VWF), mostly writing demonstration code to show off how the system could be used. Naturally, I thought this would be an opportunity to hook in some performance tracking from a virtual world to an LRS. The VWF is based on open standards and runs completely within a web browser, so it’s the perfect platform for this sort of demonstration. In the video above, you will see several browsers connecting to the same virtual environment and interacting in the 3D space. When a player logs in, logs out, or shoots a missile, a small statement is sent up to the ScormCloud LRS system. At the end of the video, you’ll see me drop into the statement viewer to examine the data that was captured during the game.
The VWF is a system designed to synchronize computation between browsers connected to a url. It’s based on WebGL, WebSockets, XMPP, and other open standards. When a user arrives at the URL of a VWF environment, the browser is sent a list of objects, event handlers, functions and data that describe the currently running simulation. On the VWF server, a document describes the static scene, and this description is sent down to the clients. In this case the only static entity is the terrain, but the VWF also sends down code to be executed. This code bootstraps the VWF, and begins executing the logic to populate the login GUI. Importantly, the code sent at this stage also includes the LRS connection data – the endpoint, App ID and Secret Key. When the user logs in, the client side code sends a message up to the VWF server which triggers the creation of a new VWF entity. This VWF entity references a Collada document, which will be loaded into the 3D scene of each connected browser. Interestingly, the 3D model does not necessarily need to live on the server, but can be a full URL. In this case, we retrieve the 3D object from the ADL 3D Repository API.
The VWF handles the synchronization of these objects. The objects come packaged with code that tells the browser how to control the 3D model, so each user can drive around their own Humvee and interact with the other clients just as you would expect in a multiplayer game. In this case, when a user fires a missile, the same connection data that was originally delivered with the VWF scene and the username entered during the log in process are used to send a statement to the LRS. For this example, the connection data is hard coded into the scene description on the VWF server. A more mature system would probably take the connection data as URL parameters, but otherwise would work in a similar way. This would allow an LMS to send the user over to the virtual world, and supply that virtual world with data that would allow it to connect back to the LRS of the users’ choice. Several players could come together to compete in the same shared space, and each have their performance tracked back to their personal (or organizational) data store.