RAGE: Building a Learning Analytics Infrastructure for

Serious Gamesseminario eMadrid del 2015.10.23

manuel.freire@fdi.ucm.es

Realizing an Applied Games Eco-system

● H2020, 20 partners, 9M € budget, ~1K man-months effort● Ambitious goal

○ develop applied games assets for game developers■ including analytics and many others that depend on it!

○ place assets in online repository ○ build a self-sustainable ecosystem around repository, connecting stakeholders

■ game-developers■ education providers■ learners■ asset contributors

RAGE

http://rageproject.eu/

e-UCM

● In charge of WP2: User Data Analytics; ~7% of total effort (second-largest)● Building on top of GLEANER

○ developed by Ángel Serrano at e-UCM○ reference learning analytics platform for GALA NoE

http://www.e-ucm.es/

GLEANER’sauthor

Learning Analytics for Games: Gleaner

Users & Tasks: basic● Admin: setup system● Game dev: adds traces to game; configures analytics● Instructor: gets students to play game, providing them with identification● Student: plays game; also, identifies self to system● Instructor: looks at student progress via analytics● Game dev: improves game based on analytics

Users & Tasks: advanced● Privacy & profiles

○ support “educational supervisor” profiles that can compare class aggregates○ game dev should not see personably-identifiable information○ students can access own data, but not others○ system should not expose PI information even if database compromised

● Scalability○ support large numbers of simultaneous players and analytics requests○ resilience: no central points of failure

● Ecosystem○ allow authorized “server-side” applications access to raw data, analytics○ allow new types of analytics & visualizations

RAGE Analytics● Part of core assets to be developed● Main LA assets

○ CITA: client-side tracking library (makes it easy to send traces to collector)○ SISA: server-side storage and analytics (stores, analyzes collected traces)○ SDA: server-side dashboard and analytics; must be highly customizable

■ heatmaps■ level transitions

● Other assets depend on LA, can benefit from above○ Real-time assessment: wants analytics data to perform “stealth assessment”○ Emotion-detection: wants to display its own data in the SDA○ ...

Initial architecture

Redesign

Mapping Gleaner to RAGE

A2: Authorization & Authentication Server● Gateway for all client-server communications

○ clients authenticate, receive auth code (JWT) to include in future requests○ A2 proxies all service requests; simplifies configuration○ initial “admin” can

■ create roles, users■ assign roles to users■ define new proxies for server-side components

○ proxied applications can mark specific endpoints as “do not require registration”○ can be queried to check for permissions

● Why?○ provides authentication/authorization for all services○ single-sign on drastically simplifies security

Deployment problems● Runtimes

○ JRE 7+○ Node.js

● Search/Query support○ Elastic Search○ Kafka○ Storm (x3)○ ZooKeeper

● Storage○ REDIS○ Mongo

● OpenLRS

● e-UCM LA support:○ A2○ frontend○ backend

● Demo-only○ a trackable game!

Docker & docker-compose to the rescue

Advantages (1/2)● Docker becomes only dependency; 1-step install

○ wget -O - https://raw.githubusercontent.com/e-ucm/rage-analytics/master/launch-all.sh | /bin/bash

● Increased security: unexposed containers cannot leak● Deployment conditions greatly standardized● Can launch, monitor, inspect logs for each container independently

Advantages (2/2)● Free hosting of docker-files at docker-hub● Free, automated builds from github - guaranteed to match with sources

Short demo

https://github.com/e-ucm/rage-analytics

Work in progress● Deployment: check (and retry a few times)

server dependencies to increase resiliency● Add analytics + visualizations as simple-to-deploy packages

(think Firefox Extensions)● Add support for trace anonymization● Documentation

Quality control

Anonymization scheme● each session, sensitive fields in traces are encrypted with new keys

○ student-id by default; others on-demand

● sensitive fields are only stored in encrypted format○ enough for class comparisons○ does not leak personally identifiable information… if developers mark sensitive fields as such

● (only) instructors can decrypt sensitive fields○ with their private keys, which are only used client-side, and never sent to the server

Steps:

1. Server generates t_pub, t_priv pairs for teachers; stores only t_pub2. Server generates random s_key for each session; stores t_pub(s_key)3. Fields anonymized using symmetric s_key; s_key is lost when session closed4. Sensitive fields can be de-anonymized by applying t_priv(t_pub(s_key))

Thanks!

Questions?Comments?

manuel.freire@fdi.ucm.es