Fun and Learning. In a Dungeon!

Matt Dray, March 2023
matt-dray.github.io/in-a-dungeon

tl;dr

Try project-driven learning. Have fun.

github.com/matt-dray/r.oguelike

rostrum.blog/tags/r.oguelike/

matt-dray.com

• ‘Too long; didn’t read’ for a summary. Snapshot this slide and then fall asleep.
• Basically: try small-scale, focused project-driven learning where you have fun and fail. I’ve often found found this preferable to what I’m calling module-driven development.
• Links are to these slides; an R package I’ll be talking about; to a series of blogs about its development; and to my own personal page.

[1] Hello

• We’ve got some exciting speakers today from a range of interesting organisations.
• …And you’ve also got me.
• I’ve been in the Civil Service for nearly a decade in multiple data and analysis roles across several orgs.
• I’m currently involved in statistics quality, production, presentation and Reproducible Analytical Pipelines (RAP). Part of that will involve advising on learning and development.
• I’m not here to tell you anything particularly clever. This is not a technical talk, per se. I’m going to talk about capability, and learning and development,m ostly.
• And yes, I’m using 1- instead of 0-indexing. Come at me bro.

Disclaimers

• These are my thoughts
• We’re all different
• This is context-dependent

• These are my personal experiences and I’m not speaking officially.
• I’m privileged: my managers have given me time and space; I have some time to learn as a hobbyist too.
• What works for me might not work for you. Approaches may suit one environment but not another.
• You might think about this from the perspective of a learner, or as a manager wanting to develop staff.

[2] The idea

• I had little experience of programming when I joined the Civil Service. I didn’t come from a computer science background.
• I think I’m competent now (in R at least). I have a good sense of what has helped me develop on that journey.
• Maybe one person will rethink their approach to learning and development.
• Maybe one person will be mildly be amused by making R go off-piste, or will feel a pang of nostalgia.

Learning approaches

A. Module-driven

B. Project-driven

• I need to start by setting up a bit of a false dichotomy.
• I want to tell you about learning with a project-driven focus, which requires a definition.
• But I will also need to define what I think is the status quo, ‘module-driven development’, for comparison.

[A] Module-driven

• Passive walkthroughs
• Comprehension tests
• It’s done to you

• I’m talking generally about short videos or static documents, probably followed with comprehension exercises.
• This extends to taking part in big workshops with a low teacher-to-student ratio.
• I’m not naming any providers, but you might be able to think of some.
• The training is administered to you, a participant.

[A] Module-driven

• Box-ticking? Badge-chasing?
• Too generic?
• Forgettable?

• I’ve been told to do these to tick a box in my learning plan.
• They’re rarely tailored to your specific needs.
• You’re at the mercy of the trainer.
• Often not a good mimic of how the world actually works.
• They often lack engagement; you just need to sit through them all and get a passing grade.
• I personally find it difficult to retain the information and the notes are often just the content.

[B] Project-driven

• Solve a small ‘problem’
• Discrete scope
• It’s done by you

• What do you need to learn? How can you make this a discrete project in the form of a package, an app, generative art, a series of scripts, etc?
• Limit its scope early, solve one problem, expand later.
• The learning is controlled by you, not administered to you. You are not a sponge.

[B] Project-driven

• Fail meaningfully
• Talk about it
• Have fun

• Making a mistake will engage you to solve it.
• Broadcasting can help keep you in check, bring other people on your journey, and help you in unexpected ways. I don’t think this is emphasised in modular learning.
• The data you use and the functionality of the thing you create don’t have to be meaningful. It might be something that helps your organisation. But it can be a bit silly, like in the example I’ll show in a minute.

[3] Example

• This is a project-driven example of mine.
• It’s slightly contrived because I chose a past example that involves connectivity and patterns (themes of this conference).
• It also panders to the nerds.
• I’ll tell you about some specific things I wanted to learn; the silly, discrete project I concocted to learn them; how communicating about it has helped me; and how this approach led to some unexpected bonus outcomes.

Goals

1. Interact with user
2. Detect and respond to IDE
3. Build simple algos from scratch

• I have a running list of things I want to learn. Sometimes these are really small things, like an individual function.
• A good exercise is to think how a few of them might be combined to achieve some goal.
• I expect to build packages for use by near-beginners; interactive confirmation is more friendly and could limit damage.
• Sometimes behaviour differs by operating system, but sometimes the development environment too. It’s easy to get stuck thinking about RStudio if you’re an R user, but what about people on the terminal or elsewhere?
• I mentioned coming into the Civil Service without computing experience. I think it’s a good exercise to think through the logic of an approach and ‘roll your own’ in a learning context.

Format

• An R package
• Openly available on GitHub
• Narrative devlogs

• So I know what I want to achieve, what project format makes most sense?
• Packages are a fundamental discrete structure for R code.
• This has the advantage of being open for others to use and contribute to.
• I also decided that I would write short blogposts, or ‘developer logs’, to explain my thinking out loud.

github.com/matt-dray/r.oguelike

rostrum.blog/tags/r.oguelike/

• The whole thing is bundled up in the r.oguelike package, which is available from GitHub.
• You can also read the devlog series.

• So what did I end up doing? Well, I made an interactive, turn-base, tile-based game for the R console. Which is… unnatural.
• I created functions to procedurally-generate dungeons, where the player collects useable items into an inventory and battles an enemy, which chases you around.
• This takes inspiration from Rogue, released in 1980, and later ‘roguelikes’ that it influenced.

Goals

1. Interact with user
2. Detect and respond to IDE
3. Build simple algorithms from scratch

• I used readline() to prompt the user and read the response.
• I detected whether the user was in RStudio, where they would have to use WASD keys to move, or Terminal, where I could use the {keypress} package for detecting keypresses directly (i.e. arrow keys).
• I also implemented procedural ‘cave’ generation and simple breadth-first pathfinding. I’ll talk about hose in a little more detail.

Procgen

• Step 1
• 2
• 3
• 4
• 5

# # # # # # # # # # # # # # # # # # # # 
# # # # # # # # # # # # # # # # # # # # 
# # # # # # # # # # # . # # # # # # # # 
# # # # # # # # # # # # # # # # # # # # 
# # # # # # # # # . # # # # # # # # # # 
# # # # # # # # # # # # # # # # # # # # 
# # # . # # # # # # # # # # # # # # # # 
# # # # # # # # # # # # # # # # # # # # 
# # # # # # # # # # # # # # # # # # # # 
# # # # # # # # # # # # # # # # # # # # 
# # # # # # # # # # # # # # . # # # # # 
# # # # # # # # # # # # # # # # # # # # 

# # # # # # # # # # # # # # # # # # # # 
# # # # # # # # # # # # # # # # # # # # 
# # # . . . . . . . . . # # # # # # # # 
# # # . # # # # # # # . # # # # # # # # 
# # # . # # # # # . . . # # # # # # # # 
# # # . # # # # # # # # # # # # # # # # 
# # # . . . . . . . . . . . . # # # # # 
# # # # # # # # # # # # # # . # # # # # 
# # # # # # # # # # # # # # . # # # # # 
# # # # # # # # # # # # # # . # # # # # 
# # # # # # # # # # # # # # . # # # # # 
# # # # # # # # # # # # # # # # # # # # 

# # # # # # # # # # # # # # # # # # # # 
# # # # # # . # # . # # # # # # # # # # 
# # # . . . . . . . . . # # # # # # # # 
# # # . # # . # # # # . . # # # # # # # 
# # # . # # # # # . . . # # # # # # # # 
# # . . # . # # # # . # # # # # # # # # 
# # . . . . . . . . . . . . . # # # # # 
# # # # . . # # # # # # # # . # # # # # 
# # # # # # # # # # # # # . . # # # # # 
# # # # # # # # # # # # # . . # # # # # 
# # # # # # # # # # # # # # . # # # # # 
# # # # # # # # # # # # # # # # # # # # 

# # # # # # # # # # # # # # # # # # # # 
# # # # # # . # . . # # # # # # # # # # 
# # . . . . . . . . . . # # # # # # # # 
# # . . # # . # . # # . . # # # # # # # 
# # # . # # # # # . . . # # # # # # # # 
# # . . # . # # # # . # # # # # # # # # 
# # . . . . . . . . . . . . . . # # # # 
# # # . . . # # . # . # # # . # # # # # 
# # # # . # # # # # # # # . . . # # # # 
# # # # # # # # # # # # # . . # # # # # 
# # # # # # # # # # # # # # . # # # # # 
# # # # # # # # # # # # # # # # # # # # 

# # # # # # # # # # # # # # # # # # # # 
# # . # # # . # . . # # # # # # # # # # 
# . . . . . . . . . . . . # # # # # # # 
# # . . # # . # . # # . . # # # # # # # 
# # # . # # # # # . . . # # # # # # # # 
# # . . # . . # # # . # # # . . # # # # 
# # . . . . . . . . . . . . . . # # # # 
# # . . . . # . . # . # # # . # # # # # 
# # # # . # # # . # # # # . . . . # # # 
# # # # # # # # # # # # # . . . # # # # 
# # # # # # # # # # # # # # . # # # # # 
# # # # # # # # # # # # # # # # # # # # 

• The basic process for dungeon building is to lay some randomised points; join them; expand randomly to the north, south, east or west over n iterations.
• The user can select a number of parameters like the size of the dungeon; the number of iterations, whether to join the points randomly or frin order (‘snakiness’).

Pathfind

• Step 1
• 2
• 3

# # # # # # # 
# . . . . . # 
# . E . . . # 
# . . . . . # 
# # # # # . # 
# . . . . . # 
# . @ . . . # 
# . . . . . # 
# # # # # # # 

# # # # # # # 
# C B A 9 8 # 
# B A 9 8 7 # 
# A 9 8 7 6 # 
# # # # # 5 # 
# 2 1 2 3 4 # 
# 1 0 1 2 3 # 
# 2 1 2 3 4 # 
# # # # # # # 

# # # # # # # 
# . . . . . # 
# . . E . . # 
# . . . . . # 
# # # # # . # 
# . . . . . # 
# . @ . . . # 
# . . . . . # 
# # # # # # # 

• How can the enemy navigate to the player?
• Generate a layer or ‘mesh’ that gives you the number of tiles away from the player.
• Move the enemy to a tile with a lower value in this ‘nav mesh’.
• Recalculate every time the player moves.
• This means the enemy will move around obstacles to meet the player.

Goals

1. Interact with user
2. Detect and respond to IDE
3. Build simple algorithms from scratch

• So that’s all the goals ticked off.

Format

• An R package
• Openly available on GitHub
• Narrative devlogs

• So that means that I met the discrete project structure of the approach.
• I have a minimum viable product that taught me what I needed; that exists openly for me and others to refer to; and that has some supporting narration that explains my thinking.

Bonus round

1. Package maintenance
2. Play in-browser with Binder
3. A third dimension?!

• But there were also some extra things I learnt as a bonus of the project-based approach.
• These are things I hadn’t set out to learn.
• I got suggestions as a result of the project being open.
• I was able to build on the output of my original goals to expand the project.

• Working in the open on GitHub and in writing devlogs meant that others could contribute.
• This user noted that I wanted to test my function for generating dungeons to make sure the output was what I expected.
• This introduced me to snapshot testing, where you can compare a function’s output to some known output on record.

• In a similar vein, working in the open meant that people could find issues.
• This user came across a bug.
• I was able to hunt it down and refactor the code a bit, given me more experience of package maintenance.

• This is RStudio running in the browser with the {r.oguelike} package pre-installed.
• This witchcraft is thanks to the Binder project.
• This means you can play {r.oguelike} in the browser, lol.
• Binder has implications for teaching people R concepts on the same ‘hardware’ without the hiccups that can come from everyone having slightly different set ups on their computers.

• At least one nerd in the room is probably wondering if you could run this in your mobile’s browser.
• Yes, you can.
• No, you shouldn’t.
• But I put a QR code there anyway. Is it a rickroll?

• And purely for fun, I did a series of extensions to the graphics using experimental packages.
• This example uses the {isocubes} package by Mike Cheng to draw my tiles as cubes This is made entirely within R, which is impressive for R.
• I also looked at the {eventloop} package by the same author for continuous keypress inputs.
• more impressively, Mike presented at last year’s Posit conference an R port of the 1991 game Another World.
• So R is not a language for statistical computing anymore, it’s a game engine!

Project-driven?

• Solve a small ‘problem’
• Discrete scope
• Fail meaningfully
• Talk about it
• Have fun

• So, did I meet my own definition of a project-driven learning?
• Yeah.

[4] Consider

• So hopefully my point is clear and the example is useful, if contrived.
• But where to start?
• There’s a few ideas for you to get started, or for you to share with your team.

In-gov

• Accelerators
• Volunteering
• Coffee & Coding

• There are some structured offers within government that implement contained, project-driven learning.
• Data Science and visualisation accelerators are cross-government.
• You are entitled to volunteering, where you could take on a project-driven approach.
• Coffee & Coding (or similar) let you share your progress, hold yourself to account and to network with the wider analytical community. This can improve your chances of those ‘bonus’ features for your project.

External

• tidytuesday
• 30DayChartChallenge, 30DayMapChallenge
• genuary

• There are several prompt-driven schemes that also work in the context of project-driven learning.
• Tidytuesday is a community-hosted event that provides a dataset on a weekly basis that you can go away and explore to produce some kind of output (a table, a chart, an app, etc).
• There’s a bunch of month-long events throughout the year that do a similar thing, but give you a daily challenge within the monthly theme (e.g. charts, maps, generative).

To reiterate

• Module-driven isn’t always bad
• Project-driven might be useful
• Think before you default

• There’s a time for module-driven learning, perhaps when you literally know nothing about a subject.
• But project-driven can be a really fruitful.
• Consider how you/your team can make best use of this approach.

tl;dr

Try project-driven learning. Have fun.

github.com/matt-dray/r.oguelike

rostrum.blog/tags/r.oguelike/

matt-dray.com