A team of Carleton researchers is trying to find out why so many computer games shy away from using nonlinear storytelling techniques – that is, techniques that help present stories out of chronological order. Traditional media like films and novels use all kinds of interesting nonlinear techniques, like those found in Run Lola Run, Groundhog Day and Memento. Many games tend to stick to fairly simple techniques like flashbacks, but more sophisticated approaches could result in more games with critically acclaimed stories.Read the rest here!
Wednesday, December 19, 2012
Research Article About Me: Creating Compelling Computer Games
There's a nice story about my research on the Carleton website. I'm particularly happy to see it because it hasn't been easy to figure out my exact thesis project, and it feels good to have finally found my path.
Monday, December 17, 2012
Celebrating One Whole Year
Yesterday was Molly's first birthday, and we had a wonderful family celebration. Looking back, I realized just how much I've accomplished this year! With Christmas and New Year's around the corner, what a perfect time to reflect on all the good things.
In the last year, I have, in no particular order:
In the last year, I have, in no particular order:
- Recovered quickly from an unwanted but complication-free c-section.
- Had 8 months of leave to be with Molly.
- Taught my mini-course on games and computer science for girls.
- Ran a study in my mini-course about teaching computer science with story, and wrote and submitted a paper about it.
- Brought Molly car camping twice.
- Figured out my thesis project.
- Set up an awesome back room play area for Molly.
- Got my wisdom teeth out.
- Had my first of two eye surgeries to help halt my keratoconus.
- Taught a Processing workshop for Girl Develop It.
- Gave a talk at a local sci-fi convention.
- Did a TEDx talk on women in tech.
- Travelled to Baltimore for this year's Grace Hopper Celebration of Women in Computing.
- Submitted and presented a paper on my augmented reality work.
- Got a great team together for Gram's House, and helped move that project forward.
- Got a draft together of a paper on nonlinear stories in traditional media and games.
- Finished my QR code iOS app, and am about to submit it to the App Store.
- Edit to add: Interviewed and got short-listed for a faculty teaching position.
Friday, December 14, 2012
An Update on Tracking My Time
You may recall back in September that I was bringing back time sheets to help myself manage my time between looking after my baby girl and doing schoolwork. Now that a semester has passed, I can reflect on how that actually went.
I did manage to keep track of my time usage quite accurately the entire term, which even I'm impressed by. Granted, I did not use a stopwatch for long, but if anything, the times I recorded were less than actual time spent. This week I decided to take a break from it since things are winding down for the holidays, but I have a tab in my Google spreadsheet for every week until now.
One of the most interesting things that has resulted from time tracking is seeing how many hours I put into research work and TA'ing. I averaged about 20 hours per week, with 25 hours in really good weeks. I admit this seems kind of low at first glance, even to me. But it doesn't mean I worked 4 hours a day for 5 days. Rather, 20 hours is the exact amount of time I spent on task after removing any and all distractions. Put that way, it makes more sense.
Even if I am spending less time on research than before (which I don't think is true, to be honest), I have actually felt a lot more productive in terms of actually finishing things. Just the act of writing down times has been a huge help in cutting out procrastination because I feel more accountable than ever (for example, I have somehow avoided withdrawal symptoms from not looking at Reddit at all for a few months!). I've also gotten better at working on things in smaller bursts, which hasn't been easy when it comes to programming and paper writing.
All in all, the time tracking has obviously been very beneficial to me, so I'll give it another go next semester as well!
Don't Forget To Punch In / Philo Nordlund
I did manage to keep track of my time usage quite accurately the entire term, which even I'm impressed by. Granted, I did not use a stopwatch for long, but if anything, the times I recorded were less than actual time spent. This week I decided to take a break from it since things are winding down for the holidays, but I have a tab in my Google spreadsheet for every week until now.
One of the most interesting things that has resulted from time tracking is seeing how many hours I put into research work and TA'ing. I averaged about 20 hours per week, with 25 hours in really good weeks. I admit this seems kind of low at first glance, even to me. But it doesn't mean I worked 4 hours a day for 5 days. Rather, 20 hours is the exact amount of time I spent on task after removing any and all distractions. Put that way, it makes more sense.
Even if I am spending less time on research than before (which I don't think is true, to be honest), I have actually felt a lot more productive in terms of actually finishing things. Just the act of writing down times has been a huge help in cutting out procrastination because I feel more accountable than ever (for example, I have somehow avoided withdrawal symptoms from not looking at Reddit at all for a few months!). I've also gotten better at working on things in smaller bursts, which hasn't been easy when it comes to programming and paper writing.
All in all, the time tracking has obviously been very beneficial to me, so I'll give it another go next semester as well!
Tuesday, December 11, 2012
The Zombie Game That's Not Really About Zombies
My brother got me a copy of The Walking Dead, which includes all five of the episodes that were previously released separately. He said he got it for three reasons: he likes the associated TV show and wanted to borrow it later, it got great reviews, and it advertised a story that is tailored to the choices you make. This last reason was quite thoughtful, given my interest in games and stories for my thesis!
We started playing right away, and have thus far completed two and a half episodes. Two interesting observations I've made so far are how much like a game this game isn't, and how it's really not about the zombies.
I say it's not much like a game because there isn't a whole lot of gameplay. It's said to be a point-and-click adventure game, and it does have many scenes that fit that genre. But it also has many (many) cut scenes, and any time you have to "fight" a zombie, the buttons sequences demanded of you are pretty amateur compared to most shooter zombie games (which, to be honest, works perfectly well for me!). There also isn't really any choice outside of the dialog options available to you - everything else is very constrained, right down to the camera angles. The funny thing is that none of this bothers me at all because the story is so engrossing.
Which brings me to the point about the zombies. Yes, the premise of the game is that zombies have taken over, making for extreme and dire conditions. And yes, zombies make appearances, and you even have to fight them off once in a while. But that isn't really the main point. It's really about the dynamics of a group trying desperately to survive. Of the lengths people will go to protect their families. Of the horrors you are suddenly willing to commit given the circumstances. In other words, it's really about the story.
I think that this game could be a breakthrough. Although I don't know for sure yet how much the story actually changes according to my choices, it does a great job of making me believe it changes a lot. This seems to replace my need for gameplay freedom, and makes the many cut scenes interesting instead of boring. The fact that the game won several awards, including Game of the Year, suggests that even many so-called hard core gamers must agree. I think this is remarkable, given that The Walking Dead is really more of an interactive cinema experience than a game.
There is hope for the future of interactive storytelling!
We started playing right away, and have thus far completed two and a half episodes. Two interesting observations I've made so far are how much like a game this game isn't, and how it's really not about the zombies.
I say it's not much like a game because there isn't a whole lot of gameplay. It's said to be a point-and-click adventure game, and it does have many scenes that fit that genre. But it also has many (many) cut scenes, and any time you have to "fight" a zombie, the buttons sequences demanded of you are pretty amateur compared to most shooter zombie games (which, to be honest, works perfectly well for me!). There also isn't really any choice outside of the dialog options available to you - everything else is very constrained, right down to the camera angles. The funny thing is that none of this bothers me at all because the story is so engrossing.
Which brings me to the point about the zombies. Yes, the premise of the game is that zombies have taken over, making for extreme and dire conditions. And yes, zombies make appearances, and you even have to fight them off once in a while. But that isn't really the main point. It's really about the dynamics of a group trying desperately to survive. Of the lengths people will go to protect their families. Of the horrors you are suddenly willing to commit given the circumstances. In other words, it's really about the story.
I think that this game could be a breakthrough. Although I don't know for sure yet how much the story actually changes according to my choices, it does a great job of making me believe it changes a lot. This seems to replace my need for gameplay freedom, and makes the many cut scenes interesting instead of boring. The fact that the game won several awards, including Game of the Year, suggests that even many so-called hard core gamers must agree. I think this is remarkable, given that The Walking Dead is really more of an interactive cinema experience than a game.
There is hope for the future of interactive storytelling!
Wednesday, December 5, 2012
Review / Think Like a Programmer: An Introduction to Creative Problem Solving
Programming involves a particular flavour of problem solving. If you're a beginner trying to get better at it, an educator teaching beginners, or just someone who enjoys thinking about thinking, then I may have just the book for you: Think Like a Programmer from No Starch Press.
This book is, as its subtitle promises, an introduction to creative problem solving. It starts with a chapter on general problem solving techniques such as breaking problems into smaller pieces and looking for answers in what you already know. It then devotes a chapter to solving non-programming problems with code. After that, most of the book covers some of the basic problem types all programmers encounter, including arrays, dynamic memory, class design, recursion, and code reuse. The last chapter summarizes general techniques for thinking like a programmer.
I read this book as someone interested in computer science education, particularly for beginners. But despite the fact that I'm an experienced programmer of ten years, I actually enjoyed reading about things I already know how to do. It ended up being an interesting exercise in thinking about thinking, and it brought my attention back to some of the details about programming that I now take for granted.
The author has an easy-to-understand, approachable, discussion-based style of writing. There is a good progression through topics — as a course instructor, you could certainly mirror the flow of the book even if you didn't want to use it as the official text. The numerous diagrams are clear and genuinely useful. I also love that good programming practices are embedded in the discussion, and that many other aspects of CS (for example, data structures) make an appearance in a natural way.
One of the chapters I was most curious about is the one on recursion, given how difficult this topic can be to teach. I liked that this topic was introduced with a detailed real-life example of head and tail recursion. I'm not sure if I was never explicitly taught these concepts or if I've come to take them for granted by now, but I have at the very least not thought about the difference in a long time. I appreciated bringing these ideas back to my conscious mind, and felt like the discussion should be helpful to beginners. I also liked the suggestion to solve problems as if there was no recursion, and to just trust the recursive call to do its thing. (Incidentally, you can read this chapter online, where it is offered as a sample.)
There were a few things I didn't like as much, such as the unnecessarily long paragraphs. I also thought some of the sample problems were cliched and rather dull (how many of us actually care about keeping track of student records?). Each chapter begins with a very fast review of relevant C++ syntax, and while I understand why this is done, I find it ends up being too sparse to be useful to anyone who actually needs it.
Probably the thing I struggle with the most is the choice of C++. I actually think C++ is a reasonable early language for computer science majors (at least in terms of what's currently available), and the rationale for choosing it for the book is sound. However, I don't really know of many post-secondary programs that teach C++ first. The problem is that the book would become a lot less relevant after the first course or two in a good CS program since the concepts will already have been covered, but it's difficult to make use of it unless you already know some C++.
Nonetheless, given to a new programmer at the right time, I think the book has the potential to be very valuable. It comes highly recommended in my mind.
This book is, as its subtitle promises, an introduction to creative problem solving. It starts with a chapter on general problem solving techniques such as breaking problems into smaller pieces and looking for answers in what you already know. It then devotes a chapter to solving non-programming problems with code. After that, most of the book covers some of the basic problem types all programmers encounter, including arrays, dynamic memory, class design, recursion, and code reuse. The last chapter summarizes general techniques for thinking like a programmer.
I read this book as someone interested in computer science education, particularly for beginners. But despite the fact that I'm an experienced programmer of ten years, I actually enjoyed reading about things I already know how to do. It ended up being an interesting exercise in thinking about thinking, and it brought my attention back to some of the details about programming that I now take for granted.
The author has an easy-to-understand, approachable, discussion-based style of writing. There is a good progression through topics — as a course instructor, you could certainly mirror the flow of the book even if you didn't want to use it as the official text. The numerous diagrams are clear and genuinely useful. I also love that good programming practices are embedded in the discussion, and that many other aspects of CS (for example, data structures) make an appearance in a natural way.
One of the chapters I was most curious about is the one on recursion, given how difficult this topic can be to teach. I liked that this topic was introduced with a detailed real-life example of head and tail recursion. I'm not sure if I was never explicitly taught these concepts or if I've come to take them for granted by now, but I have at the very least not thought about the difference in a long time. I appreciated bringing these ideas back to my conscious mind, and felt like the discussion should be helpful to beginners. I also liked the suggestion to solve problems as if there was no recursion, and to just trust the recursive call to do its thing. (Incidentally, you can read this chapter online, where it is offered as a sample.)
There were a few things I didn't like as much, such as the unnecessarily long paragraphs. I also thought some of the sample problems were cliched and rather dull (how many of us actually care about keeping track of student records?). Each chapter begins with a very fast review of relevant C++ syntax, and while I understand why this is done, I find it ends up being too sparse to be useful to anyone who actually needs it.
Probably the thing I struggle with the most is the choice of C++. I actually think C++ is a reasonable early language for computer science majors (at least in terms of what's currently available), and the rationale for choosing it for the book is sound. However, I don't really know of many post-secondary programs that teach C++ first. The problem is that the book would become a lot less relevant after the first course or two in a good CS program since the concepts will already have been covered, but it's difficult to make use of it unless you already know some C++.
Nonetheless, given to a new programmer at the right time, I think the book has the potential to be very valuable. It comes highly recommended in my mind.
Subscribe to:
Posts (Atom)