Jump to content

April 2017 »

232425262728 29
- - - - -

Viewback - A Video Game Design Tool

user testing testing design tools playtesting
4: Adsense

Viewback is a tool that helps game designers conduct usability play tests. It forwards the debug information from your game to your wireless device, where you can see it and the player can't. Now you can diagnose problems with the game while your playtester enjoys her experience. You can see changes to internal game state and send commands to the game in real time.

You can watch this video to get an idea of how it works:

The Viewback server is written in C and can be easily integrated into any game engine. It uses a permissive MIT license, avoids blocking networking calls, and uses only a few hundred bytes of memory. The server compiles on any C compiler with no dependencies, and the monitor is available for Windows and Android, with OSX and iOS coming soon.

Since Viewback is written in C it can be used in just about any game engine environment. Any engine written in C or C++ (Id Tech engines, Unreal, Source) can use Viewback with no extra effort. Users of engines written in Java or C# (Unity, Minecraft) can either write language bindings or implement the Viewback network protocol on their own.

This repository contains the header and source code for the Viewback server, which will typically be integrated into your game's client, if your game is multiplayer. It looks like this:

Attached Image

Installation Instructions

First, download the source code from the GitHub page and copy all files in the server directory to a directory inside your source tree. If you're familiar with git, you can use a git submodule for this purpose. Then add viewback.cpp and viewback_util.cpp to your project files. In whichever files you want to use Viewback, add at the top:
#include "viewback_util.h"
Now you are ready to implement the API.

Sample Code

This code uses the vb_util interface, which handles memory allocations for you. If you care about how Viewback manages memory, see viewback.h for an interface that allows you to allocate the memory that Viewback uses.
#include "viewback_util.h"

vb_util_initialize(); // This is optional.

// A "channel" is a stream of data to be sent to the Viewback monitor for display.
// Here we create an integer channel called "Health".
vb_channel_handle_t health_channel;
vb_util_add_channel("Health", VB_DATATYPE_INT, &health_channel);

// The name you pass in here will be displayed in the server list on the monitor.
vb_util_server_create("My Amazing Game");

while (game_running())
    // Call this as many times as you like, but at least once per game frame.

    // You can send data once per frame, or only when the data changes. It's up to you.
    if (!vb_data_send_int(health_channel, player->GetHealth()))
        printf("Error sending to Viewback channel\n");

At this point you should be ready to use the Viewback monitor to see your data. If you are on the same WiFi network as the Viewback server then the monitor should automatically find the server. If your network is special then you may have to find the IP address and connect manually. Once connected you will asked to select a group to display, and then you'll be able to see your channels.



A channel is a stream of data to be sent to the Viewback monitor for display. Each channel has a type, currently supported types are integer, float, or vector. Depending on the type of the vector the data will be displayed in the monitor in a different panel. Floats and ints will be shown in the time display and vectors will be shown in the 2D display.


A group allows you to organize your channels. You can add a channel to a group and then activate a group to see all of the channels in that group. For example an "Animation" group may contain these channels:
  • PlayerYaw
  • ViewVector
  • PlayerVelocity
while the "PlayerMovement" group would contain
  • PlayerVelocity
  • JumpButton
  • OnGround
A channel can belong to multiple groups or no groups.


Integer channels are often enumerations - i.e. each value represents a state. These states often have names and looking at the names is nicer than looking at the numbers. So for integer channels you can specify that a certain value has a name, and this name will show up in the monitor instead of the number. For example for the PlayerState channel you may have these labels:

0: Dead
1: Respawning
2: Alive
3: DeathAnimation
4: Spectating

Whenever the channel has the value of "2", the monitor will show the "PlayerState" channel as being "Alive".


You can specify controls to modify parameters of your game in real time. These controls appear in the monitor and when they are manipulated by the user, the callbacks that you specify will be triggered in the game code. There are currently two types of controls supported.


When pressed, a callback function in the game will execute. For example, a "Pause" button could call this function:
void viewback_pause_callback()
Other ideas for buttons:
  • Take a screenshot without leaning over your playtester.
  • Turn cheats on and off.
  • Activate the bug report system.
  • Reset the level if your playtester got stuck.

When the slider handle is moved a callback in the game will execute. Sliders can specify integer or float values. Some ideas for sliders:

Adjust the difficulty of the game if your playtester is having trouble (or not enough trouble)
Adjust the number of bots in the game
Real-time tuning of a design parameter that you've been trying to get right, like the player run speed or jump height.


If your game has a console, you can forward the console to Viewback. Output from the console will appear in the Viewback monitor and the user can input commands into the monitor which will get forwarded to the game.

Don't have a console in your game? No sweat, you can use the Viewback monitor as your console. Just call the Viewback vb_console_append() function with whatever messages you want to see, and it will show up on the Viewback monitor.


The status string is like the console but it's always visible. New status lines replace old lines and they never scroll off the screen. Use it for things like the framerate, memory used, and how many monsters are currently spawned.

Aug 12 2014 01:46 PM

Will have to check this out when it hit OS X. Thanks for the heads up!

Aug 13 2014 01:29 AM

Very cool, looks like a great testing tool -- thanks for sharing! :)

Aug 13 2014 02:57 PM

Very interesting. Can you speak about the protocol a bit? Is it implemented using raw sockets (TCP/UDP), or are you building on top of a higher-level protocol like http/rest?


I've had some thoughts on something similar in concept, and I've been thinking about it from an HTTP/Rest perspective, with some HTML5 goodness. I'd be interested in knowing what you use, and how you came to your decision.

Aug 13 2014 03:59 PM

Protocol documented here: https://github.com/BSVino/Viewback/blob/master/NetworkProtocol.md


The server needed to be able to run with very limited memory and with very few dependencies. Building on top of an HTML/Rest library would have been too heavy. Google Protocol Buffers have a simple format that was easy to write some custom C code for (Well in truth I stole the C code from another project and modified it.) It also has built-in versioning so I can deploy new versions without breaking existing clients.

Aug 13 2014 06:09 PM

Interestingly enough, I've found some small http/websocket servers that are small enough for a reasonably-sized microcontroller, and written in C. I'm sure it uses more than 'a few hundred bytes' but It still seems small enough for any reasonable game and I'm inclined towards being able to access the game through a standard web browser. Of course, that's just my preference, and I haven'd dug into the weeds of it all yet.


In any case, this and some other great articles about being able to peek into your game remotely or record information about user sessions in a lightweight way really make an important point -- Its possible now to view in real-time and record users real-world play sessions and take advantage of that data to gain insights about how their game is performing with respect to user experience. That is, the beginning of 'big data' for the average game (Freemium games and probably MMOs -- server side -- have been doing it for awhile). I think any serious game maker would be insane to not build that kind of data gathering into their title (with appropriate disclosure / opt-in, of course).

Note: GameDev.net moderates comments.