Technical Underpinnings of Physics Playground

• In Event: 18.057 - Physics Playground, a Game for Learning: Demonstration and Posters

Abstract

Physics Playground (PP) is a 2D game (Shute & Ventura, 2013) with simple game mechanics (i.e., drawing objects or manipulating physics parameters to guide a green ball to a red balloon). This paper describes the technologies used to implement both the player and administrative interfaces to the games and their communication with analytical systems.

The technologies used to run the game and how they communicate with each other. PP was implemented in the Unity game engine and is hosted on a Linux-based Google server. The admin site allows educators to select playgrounds and levels to present, add/remove activities associated with a level (e.g., insert a Hewitt Video at the end of a level), and create usernames and profiles. The admin site is implemented using php, HTML, JavaScript, and Yii; and a git repository called Bitbucket tracked different versions of the source code and updates the game code on the server. LearningLocker (LL), installed on the server, collects and stores log data generated by players. These records can be accessed by the measurement engine and other analytical systems.

The design of the game in Unity. The Unity implementation consists of four scenes: (1) Entry: handles the login information and matches the users credentials with the user’s profile data; (2) Menu: downloads data from the server, builds the playgrounds, and hosts the game’s dashboard (My Backpack); (3) Game: serves as the presentation process of the four process architecture (Almond, Steinberg & Mislevey, 2002) and controls the game play. The work product from the game level is a log of game events that are sent to the LL. The fourth scene is a Level Editor that game designers use to build and test new game levels.

Communication between Unity and Measurement Engine. The measurement engine (also presented in this session) is implemented in R (R Core Development Team, 2018). The OpenCPU package will be used to run R as a server, implementing the evidence identification (EI), evidence accumulation (EA) and activity selection (AS) processes. The unity engine will send a message that a given user has complete a given level (or other activity). The EI process will query LL to fetch the relevant events and send a list of key observables to the EA process, which will update the user’s competency profile. Finally the AS will send back recommended next activities to the Unity client to make the adaptive version of PP.

Lessons learned and recommendations. As many users can hit the server at the same time during testing, load balancing is critically important. Temporarily upgrading the server to have 16 virtual CPUs and 124 GB of virtual space during periods of active testing resolved performance issues in early testing. Larger scale pilot tests occurring over the next several months should provide us with more lessons by the time of the conference.

Authors

• Seyedahmad Rahimi, Florida State University

• Russell Almond, Florida State University

• Valerie J. Shute, Florida State University