Seminario eMadrid 2015 09 10 sobre Serious Games (UCM) Manuel Freire - RAGE: Creación de una infraestructura de Learning Analytics para Serious Games

1. RAGE: Building a Learning
Analytics Infrastructure for
Serious Games
seminario eMadrid del 2015.10.23
manuel.freire@fdi.ucm.es

2. 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/

3. 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’s
author

4. Learning Analytics for Games: Gleaner

5. 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

6. 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

8. 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
○ ...

9. Initial architecture

10. Redesign

11. Mapping Gleaner to RAGE

12. 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

13. 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!

14. Docker & docker-compose to the rescue

15. 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

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

17. Short demo
https://github.com/e-ucm/rage-analytics

18. 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

19. Quality control

20. 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_pub
2. 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 closed
4. Sensitive fields can be de-anonymized by applying t_priv(t_pub(s_key))

21. Thanks!
Questions?
Comments?
manuel.freire@fdi.ucm.es