Monday, April 14, 2014

My FDG 2014 Cruise Ship Conference Experience

You may recall that I was going to a conference on a cruise ship in April.  Well, I'm back from Foundations of Digital Games 2014 and am happy to report that I have found another new favourite conference and community.  The conference went well and I made some wonderful friends. Win win!

It was a strange experience, being on a cruise ship for (mostly) academic purposes.  This was my first time on one, and to be honest, I actually prefer the resort experience more when it comes to vacations.  An overwhelming sense of "fake" was prevalent on the ship, and while resorts aren't necessarily better, on a cruise all you have is the boat.  No beach, no grass, etc.  I also didn't love the dark, cavernous feeling on most decks of the boat or the lengthy process to embark and debark.  Even the mall was kept dark and lit with neon lights most of the time.


But there is a big advantage to hosting a conference on a cruise ship: nobody can leave! This was really great for building community.  It was easy to find other attendees and spend some social time with them.  For example, on one of the early nights, there was a disco party happening in the mall.  At that point I was alone, wandering around, wondering what to do.


When I ran into some friends (old and new), I finally had someone to dance with, even if we were stuck with disco for quite some time.  I would not have danced disco alone, but with them, I had a blast.

I have to admit that the upper deck with the pools was a nice place to prepare for my paper presentations (lab mates, if you are reading this: pretend I prepared weeks in advance and practised at our meetings).  Sitting on a swinging chair looking out on the ocean is a good way to relieve last-minute stress.


And boy, was I stressed.  I wasn't worried about the actual presentation being good, but rather whether the audience of heavy-hitters in the stories-in-games field would think the work itself was any good.  It was a rare moment of feeling the imposter syndrome.  To make matters worse, I had two talks almost in a row! Good to get them over with, but no chance for feedback in between.

Fortunately, everything went very well.  The talk was good, and the questions afterwards were even better.  A lot of the people I was intimidated of in the first place made a point to tell me that my talk was interesting.  Later in the conference I even got to have an extended conversation with one of them, giving me both confidence and ideas.  (Learn more about what I presented if you're interested.)

After my talks and a couple of other interesting paper sessions, I escaped on my own for a bit to decompress.  The sun was starting to set, which was the perfect time to take a stroll around the boat.



The next day, the ship docked in Cozumel, Mexico, where two of my new friends and I went on a tour of Maya ruins (apparently you aren't supposed to include an "n") and visited a gorgeous beach.  I was really glad to have my talk behind me at that point as I could completely relax and enjoy it!





The last day of the cruise included more interesting talks and a lovely reception and dinner to cap it all off.  I left the following morning on a high, and already trying to figure out how to ensure I attended next year's conference.  I left feeling like I had finally found "my people," from my awesome roommate to the researchers with the same interests.  Thanks FDG, and hope to see you again soon!


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!

Wednesday, February 12, 2014

Hitting a Block and Feeling Stuck

I recently received an email asking whether I've ever faced programmer's block.  The emailer was referring to those times you sit and stare at a problem but never make any progress.  You feel stuck and, in some cases, just give up.  How does one get past that?

Stupid Computer!!!
Stupid Computer!!! / f1uffster

The good news is that I think all programmer's face this feeling at one time or another, and most likely, they feel it rather often.  The thing that changes with experience is usually the level of complexity of the problems causing stuckness, not whether a programmer will get stuck in the first place.

That might seem really depressing, especially if you hear this after your first extremely frustrating moment of stuckness.  But it's not all bad news.  As you learn more strategies for getting unstuck, you don't stay stuck nearly as long.

Some strategies: learn to experiment.  When you first start programming, many tend to be a bit afraid of tinkering with code, trying different things with an eye toward understanding better what's going on.  It's not just trial and error; you have to be strategic.  You have to take the time to understand why something finally works, even if you hit upon the answer randomly.

To improve your experimentation skills, you need to learn to debug.  Whether you just print the values of variables at key locations or use a fully-featured graphical debugger, learn how to display as much as you can about your code so you can ensure your mental model of it is correct.  You must learn techniques that help you first narrow down where the problem is, then you can tackle figuring out what the problem is.  For example, you might narrow down that a problem appears inside a loop.  From there, you can start printing out the variables you are changing in the loop to see if they are what you expect.

As you learn more and more about programming, algorithms, data structures, and so on, your toolbox of problem solving techniques grows and grows.  Things that seemed so hard in the beginning are now no problem to spot, all thanks to experience.  Of course, new problems are introduced, but you know how to tackle them, thanks to your ability to experiment and debug.  It takes time, but damn, it feels good when you finally get unstuck again!

If you'd like to read about some more specific programming problem solving techniques, check out Think Like a Programmer, which I've reviewed here.  (I wasn't compensated to say this - I just really like the book!)