The document outlines the RAGE project aimed at developing a learning analytics infrastructure for serious games, involving a budget of 9 million euros and a collaboration among 20 partners. It discusses the development of analytics tools like Gleaner, aimed at ensuring privacy, scalability, and an ecosystem connecting game developers, educators, and students. Additionally, it details the use of Docker for deployment and data anonymization strategies to protect sensitive information.

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