Lab 3

Deliverables

• Basic: Description of your experimental design and results of gameplay QA testing -- gather statistics of at least two different measurable quantities on at least two different controllers / firmware
• Extra: Gather more statistics and provide more analysis.

Objectives

You've now crafted your own custom controller, written some firmware, and made some thoughtful (or perhaps thoughtless) keymappings. Now in Lab 3, we will put your creations to the test! While there is perhaps no "wrong" controller design, an important part of marketing is giving the consumer what they want. This week's lab will deal with evaluating how well your controller gives gamers what they want -- gaming results!

To achieve this, during Lab 3 we will each modify a game engine to gather some statistical information about how we play when using our controller. This serves two primary purposes:

1. You will learn your way around a foreign game engine
2. Evaluate the "effectiveness" of your controller design and key mappings

While a hunch is often the inspiration for a first prototype, a quality developer will revise their prototypes when faced with statistical evidence of improvements or ineffectual design choices. While you are not required to use your statistics to make a new controller , it is valuable to use this data to reflect on how you improve your controller in the future (regardless of whether it ever becomes a reality). That being said, some of the less permanent aspects of your controller (i.e. the keymappings), are easily modifiable -- if your data implies a certain mapping isn't effective, don't be afraid to change it and see if your statistics improve!

Prerequisites

In order to compile any of the open source games you can use for this lab assignment, you first need to install the required packages. Run the following in a terminal:

    sudo apt-get install g++ libsdl-dev libsdl-mixer1.2-dev libsdl-image1.2-dev libopenal-dev git cmake

Download Source

You can use either Lugaru or Cube 2: Sauerbraten .

I personally would recommend Cube 2 since it has many more game modes and includes support for multiplayer game sessions, which will allow for you to test you controller while playing with others in the lab. That being said, Lugaru may be slightly easier to modify given its single player nature.

Additionally, Lugaru (which is developed by Wolfire) and Cube 2 have active coding and modding communities that regularly hang out on various Internet Relay Chat (IRC) channels. You can easily access Wolfire's IRC channels through a direct link on their website. Cube 2 also has an IRC client, but it is not as cleverly embedded into HTML -- you will need a IRC client like HexChat to use it. The address of the Cube 2 IRC channel can be found within the Cube 2 online README.

I've made a GitHub fork of Lugaru and Cube 2 in case you prefer to get the source from there.

Tips Building Binaries

• After downloading the games get them to compile before you start making changes
• To build the game you will need to use Makefile
• For Lugaru, you need to make a Makefile with cmake, then use make.

Using make

   make

Using cmake

   cmake .  

After make finishes, you should have an executable binary file. On Unix, you can run a binary, such as Lugaru, with...

   ./lugaru

Warning: Lugaru has been known to cause some of the video drivers on the Jetson to crash if you do not have the in game's fullscreen resolution configured correctly. If this happens, you will probably need to restart your Jetson. To address this, you can launch the game in windowed mode with

  ./lugaru --windowed

Once in game, you can navigate the menus to adjust your resolution. You will need to relaunch the game for the resolution change to occur.

Additionally, be warned that if you are running these games in windowed mode, you should not take them out of selection focus. These games can behave oddly if you start selecting external programs.

Collecting Data

How you collect your data and analyse it is up to you -- that being said, you need numbers! Thus, I strongly recommend you output the statistics you generate into a file and examine them in spreadsheet application like Excel. Since both of these games are written in C++, this link can be a valuable asset to learn (or remind yourself) how to write output files with C++. Alternatively, you can also use the C function fprintf() as we discussed in class -- a tutorial is linked here.

If you plan to use Excel or another spreadsheet application for your statistical analysis, it is strongly recommended you output your files as a .csv file (comma separated value). A .csv file is a text file that can be interpreted and opened by most spreadsheet applications. Imagine it as a spreadsheet where columns are separated by commas (,) and rows are separated by newlines (\n).

Here is a link on .csv files.

Example Statistics

Here are some ideas for statistics you want to gather:

• Reaction time -- latency
• Lifetime (survival)
• Score
• Accuracy
• Precision
• Throughput -- time, simultaneous actions
• APM
• Durability
• Comfort

Experimental Design

This is a very open ended assignment allowing you to test almost anything you want! Because of that, it is incredibly important you document your experimental design in your lab report -- otherwise we won't know what you tested and how.

Additionally, if you make any variations to your firmware as a result of your experiment, make sure you commit it and explain what changes you made and why.

Completed Lab Reports

• Tyler Smallwood
• Bryan Matsumoto
• Andy Russell
• Patrick Lu
• Sebastian Krupa
• Henry Huang
• Andrew Fishberg

This lab was developed by Andrew Fishberg.