Game Development Reference
In-Depth Information
It may be hard to make out, but the image is encoded at about 50% JPEG quality and is running at about
20 frames per second. The engine frame buffer was 960 x 540 pixels, and encoding it as a JPEG took about three
milliseconds. At medium quality, I was easily able to obtain 30 frames per second with “good enough” image quality.
This type of remote viewer requires a large amount of bandwidth. Each frame amounted to about 64 KiB of JPEG data.
Running at 30 frames per second, the tool needs 1920 KiB per second. This bandwidth requirement is fine for a local
area network (even a WiFi one) but is inappropriate for streaming over the Internet. For reference, the engine was
running single-threaded on an Intel Core i5 CPU.
Various forms of testing are possible with an ET-API system. You can do regression testing, for example, by
capturing performance data such as memory used. Each day, the engine can be spawned, and a remote browser
can create a fixed set of objects while observing total memory used. If this total amount has changed, the tool can
notify developers of a potential memory leak. Testing the renderer becomes possible with the remote viewing
capabilities. On each test run, the browser tool constructs a scene, places the camera, and requests a screenshot.
This screenshot is compared with a previously approved screenshot. If they do not match, a bug may have been
introduced into the renderer.
Technical Details
Implementing ET-API for your engine requires a WebSocket server, a system for managing multiple connections,
report generators, and command processors. This section will cover each of these in turn.
The WebSocket Protocol
A WebSocket connection begins life as a regular HTTP connection. The connection is upgraded from HTTP to
WebSocket. This upgrade is one-way; you can't revert back to an HTTP connection. Listing 10-4 shows a sample
upgrade request.
Listing 10-4.
A Sample Upgrade Request
GET /servicename HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin:
http://example.com
Listing 10-5 shows how the server responds.
Listing 10-5.
Server Response to an Upgrade Request
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Most of these HTTP fields are self-explanatory, but not
Sec-WebSocket-Key
and
Sec-WebSocket-Accept
.
Sec-WebSocket-Key
is a string sent by the client as a challenge to the server. The challenge is there so that the client is
sure that it is communicating with an actual (and up-to-date) WebSocket server. This example leads to the question,
how does the server calculate the value of
Sec-WebSocket-Accept
and complete the challenge? The answer is
quite simple. The server first takes
Sec-WebSocket-Key
and concatenates it with a GUID string from the WebSocket
specification. Then the SHA-1 hash of the resulting string is computed, and finally,
Sec-WebSocket-Accept
is the
base64 encoding of the hash value. Let's work through an example, starting with Listing 10-6.
