Friday, March 21, 2014

Planning for Go Code Girl 2014: Python and Pis

Last year's Go Code Girl was a great success.  This year, we wanted to build on that as well as try something a bit different.  Keeping the same overall format, we're hosting two days of coding fun: the first at University of Ottawa and the second at Carleton University.


Instead of teaching the girls Processing again, we'll use the turtle module to draw fun pictures in Python, LOGO-style! Then, on day two, we're going to see what we can do with the Raspberry Pi.

I'm a big believer in teaching programming to beginners in a visual way.  Not only is it more exciting than printing text out onto a console, but it can help understand commands in a more concrete context.  In can even allow for an embodied understanding of concepts, for example by imagining yourself as the turtle moving around the screen, leaving a pen trail behind you.

It's no surprise that I'd favour using something visual to introduce Python.  But as you may know, I tend to favour Processing over Python as a first language.  Why use Python? Partly to get more first-hand experience in teaching it as a first language, and partly because it seems to be the language of choice for the Raspberry Pi.


I know that in the three hours we have on the second day, we won't be able to do that much with the Pis.  I want to try to give the girls enough knowledge and confidence to continue exploring on their own, should they wish to purchase a Pi of their own.  Thus, it's important that they know a bit of Python.

As an added bonus, I can experiment with the turtle approach for teaching programming to my arts and social science students next year.  I imagine it would be a big improvement over how I did it last fall.

I'll report back on how things went and provide a link to the workshop materials when it's all over.

Wednesday, March 12, 2014

Our Two FDG Papers On Games and Stories Are Now Online

Our two papers accepted to Foundations of Digital Games 2014 have been edited, improved, and uploaded.  I'd love to hear your thoughts on them.

A Framework for Coherent Emergent Stories

This paper is based on my thesis work.  The paper can be downloaded from the project page.
Crafting satisfying narratives while preserving player freedom is a longstanding challenge for computer games. The quest structure used by many games allows players to experience content nonlinearly, but risks creating disjointed stories when side quests only minimally integrate with the main story. We propose a flexible, scene-based emergent story system that reacts to the player’s actions while maintaining a reasonable amount of authorial control over the story. Based on the philosophy of story scenes as kernels or satellites, we define a minimal story graph that initially contains mostly disconnected nodes. Over time, the graph is built dynamically from offered to the player. In this paper, we describe the framework of our system and present an early prototype game as a case study. We end with a vision of how our framework could be used to create more coherent, emergent stories in games.


Chronologically Nonlinear Techniques in Traditional Media and Games

This paper was accepted as a work in progress.  A colleague of ours seem interested enough in working on it even further, which may lead to a journal paper in the future.  The paper can be downloaded from the project page.
Although stories in games have become more sophisticated over time, their use of nonlinear techniques has not yet become as prevalent as in traditional media like novels and films. Writers have largely excluded nonlinear techniques from their toolbox, possibly because of fears of introducing inconsistencies when player actions alter past events. However, as we show through a survey of common nonlinear techniques seen in television, novels, and film, games can and have avoided these inconsistencies while maintaining gameplay agency. Many players prefer a high quality static story incorporated into strong gameplay, making the insight from this discussion immediately useful in designing nonlinear game stories. We also discuss some ways in which nonlinear techniques can offer both gameplay and story agency, hopefully bringing the quality of game stories one step closer to their traditional counterparts.

Monday, March 3, 2014

Why Functional Programming Leads to Reliable Software

Patrick Prémont, functional programming architect from local consulting firm Tindr, came to speak to my Programming Paradigms class last week. We're currently learning functional programming in Racket, so who better to speak to the class than someone who actually uses the functional paradigm in industry? The theme of Patrick's talk was that functional programming can create very reliable software when you combine the safety of functions without side effects with the compile-time checking of a good type system.



I personally got a lot out of the talk, so hopefully my students did, too.  I appreciated hearing that real companies are using functional programming in real applications.  I've really enjoyed learning Scheme/Racket as a student, but never really heard of anyone using the paradigm beyond perhaps the ability to create anonymous functions in otherwise imperative or object oriented languages.  The pitch about reliability made a lot of sense to me.

Another theme that struck a chord was the focus on using types to make the compiler tell you when you've done something wrong.  I've developed my own philosophy of effective programming throughout my (almost) 12 years of experience, and getting the compiler to catch your mistakes is a big part of it.  I always try to write code that doesn't assume its user will use it correctly, but instead try to produce an error when it's used incorrectly.  I usually think about this from an object-oriented viewpoint, so it was neat to learn how carefully designed types in a functional language can accomplish the same.

Check out the slides above for more details, and share your thoughts on the potential of functional programming when it comes to reliable software!