Upload
emadrid-network
View
487
Download
5
Embed Size (px)
Citation preview
RAGE: Building a Learning Analytics Infrastructure for
Serious Gamesseminario eMadrid del 2015.10.23
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))