Monday, July 30, 2012
I'm really excited to be attending this year's Grace Hopper Celebration of Women in Computing in Baltimore, and I hope you'll consider going, too! Tomorrow is the last day for early bird prices, so register now!
This year is a particularly special year for me. I've been hoping to get my husband to Grace Hopper for a while, but it's never quite worked out. I really want him to get a glimpse into my world of 'women in tech' since I do so much work in the area (outreach, trying to improve curriculum, and so on). I imagine he'll have lots of useful insight and information to bring back to his workplace. I also think he'll really enjoy the technical talks.
Since this year's conference is just nine hours from home, we're planning on driving there. Not only that, but we're hoping to bring our daughter, who will be 9.5 months old at the time. Being able to introduce both of them to all the amazing technical women I now call friends thrills me to no end.
I'm also going to be one of the co-chairs for the Communities Committee this conference, so it's shaping up to be my best year yet!
Whatever your reasons for attending (and there are many!), I hope to see you there. Remember: early bird registration ends tomorrow (July 31)!
Wednesday, July 25, 2012
Quests in video games are a nice way to give players choices to make and offer a story line that seems a bit less linear. Have you noticed, though, that most quests seem to follow the same pattern? Usually, they're all about picking up a certain number of items or killing a certain number of enemies. They tend to be a list of tasks to complete rather than offering an overall goal that could met in a variety of ways.
Anne Sullivan, a recent Ph.D. graduate from UC Santa Cruz, spent at least some of her years as a grad student working toward making quests more interesting. She calls goal-based quests playable because they offer players meaningful choices in terms of how the quests are completed.
In her framework, Anne focuses on the use of social (as opposed to attack-based) mechanics. Players are able to complete social-oriented quests that are dynamically selected by the framework. What quests are available is partially based on what plot points in the overall game narrative the player has seen so far. The quests are goal based, so players can decide for themselves how they would like to complete them.
For example, if the quest involves breaking up a dating couple, the player might be able to get one person to distrust the other, or start dating one him or herself. Or, he/she might even cause the opposite to happen and encourage the couple to elope! The overall game story may change based on what the player chooses to do — something you rarely see happen with quests these days!
I really like this concept, not only for the new type of social mechanics (fighting gets old for me), but because the quests actually affect the rest of the game's story. This does occur in small ways now, but the main plot points hardly change if ever.
I also noticed in Anne's publications some similarities between what I read way back when in Chris Crawford's book on interactive storytelling and the structures used to capture the social mechanics in her own framework. I didn't follow the citations back to see if the framework (and what it was built on) was directly inspired by Crawford, but it does make me a little bit happy to potentially see Crawford's work becoming useful considering this sad article about him.
I am likely to do work in the area of quests and non-linear story, so hopefully I'll also be able to help make a difference in the quest to make stories more playable!
Friday, July 20, 2012
Were you ever the type to pick up a newspaper just so you could complete the crossword puzzle? Apparently this was a point of entry into the paper for many people, but the concept didn't get translated very well when journalism went digital. In his Games for Change Festival talk Ian Bogost suggests that newsgames might be a new way to draw people in.
But here's the problem: making games is kind of hard. And newsgames — “any application of journalism in video game form” — have to be made quickly so they are relevant to current events. Should we start training journalists in computer programming? That might be useful, but it's not a short term solution.
Instead, Bogost has created Game-O-Matic, a tool that can quickly create simply microgames based on a concept map anyone can put together. This allows journalists to work at the ideation level. It's kind of like being able to take a snapshot of the world with a point-and-shoot camera; it's a point-and-shoot game maker.
The concept is really interesting because it distills games down to their most basic pieces. If the idea ends up working well, I could see it going much further with story generation based on concept maps. If nothing else, it could be quite useful as a brainstorming tool.
Monday, July 16, 2012
We've got two computer scientists in our three-person family. Would it surprise you that our daughter, currently seven months old, is not allowed to watch any TV, videos or games, and does not play with our iPhones at all?
Yup, that's right. We're actually trying to follow the 'no screen time before 2' advice.
Before I go any further, I would like to emphasize that I am not judging any family that allows their babies to watch TV (or play games, or whatever) for any length of time. This post is about exploring our attempt at avoiding it because doing so felt right for us. I know there are many who find screen time tremendously helpful and/or educational!
This PBS article does a good job of summarizing the research related to television and children under 3. It starts with some startling statistics that show how many infants and toddlers are exposed to television despite warnings against it (I haven't found anyone I know that is doing what we are). But it then points out that there has been surprisingly little research done into the actual effects of TV. Unsurprisingly, research does show that the role of a caregiver in watching programs is even more important than the content itself.
The American Academy of Pediatrics (AAP) released a statement in 1999 that included this:
Pediatricians should urge parents to avoid television viewing for children under the age of 2 years. Although certain television programs may be promoted to this age group, research on early brain development shows that babies and toddlers have a critical need for direct interactions with parents and other significant care givers (eg, child care providers) for healthy brain growth and the development of appropriate social, emotional, and cognitive skills. Therefore, exposing such young children to television programs should be discouraged.In 2011, the AAP released a more modern statement. As discussed in The New York Times:
The recommendation, announced at the group’s annual convention in Boston, is less stringent than its first such warning, in 1999, which called on parents of young children to all but ban television watching for children under 2 and to fill out a “media history” for doctor’s office visits. But it also makes clear that there is no such thing as an educational program for such young children, and that leaving the TV on as background noise, as many households do, distracts both children and adults.Interestingly, the less strict recommendations were made because many people thought the all-out ban was all but impossible to follow:
The recommendations are an attempt to be more realistic, given that, between TVs, computers, iPads and smartphones, households may have 10 or more screens.We have multiple devices in our house (though probably not 10), but we have an advantage. We don't watch TV, and though we really enjoy playing games and watching movies, we don't have much opportunity for it these days. Thus, for us, an all-out ban is feasible.
And that's what we're going for: an all-out ban on screen time. My only exception is that I don't mind if she sees me browsing or emailing, so long as there are no videos on the screen. Our choice is validated anytime she does see a video accidentally: she turns into a zombie and just stares at it. If a TV is on nearby, you can hardly stop her from turning her head around toward it. That makes me uncomfortable.
I'm not sure if we'll last all the way until 2, but we'll do our best. And when the time comes, I have to admit that I am very much looking forward to playing some fun kid-friendly Kinect games.
Thursday, July 12, 2012
Philip Guo's Ph.D. Memoirs have spread like wildfire, and for good reason. His well written short book offers a fascinating look into life as a grad student at Stanford while offering some really valuable advice for those of us still in the trenches.
Guo describes how he started his PhD years grinding on his supervisor's project with little benefit in terms of research outcomes that could contribute to his thesis. Internships helped him recover from burn-out, gave him some research inspiration, and provided valuable contacts.
In the latter years, he decided to define his own project. Though not his main interest, Guo's supervisor was supportive of the idea. Guo was also able to find other academics whose interests and obligations aligned with his project, helping ensure success. He graduated after six years and is now working for Google.
I really enjoyed reading this because it helps to know that even students of this calibre struggle. One of the key takeaways for me was to make sure I align myself with my professor's needs. For instance, he needs a student to be part of a particular story-related project for a research network he's part of, so I should try to make my own project fit into that framework. Another useful tip was to work with the insiders of a particular sub-field to make your chances of getting into top-tier conferences higher; the insiders know what reviewers want and can pitch the research appropriately.
I highly recommend you read this memoir if you are a grad student or thinking of becoming one. But if you're short on time, look at the twenty most memorable lessons in the epilogue. I'd love to hear which tips resonate most with you.
Monday, July 9, 2012
Code School recently put out a free lesson on Git with the tagline "Got 15 minutes and want to learn Git?" With the promise of it being so short I decided to give it a try. My take is that the implementation of the tutorial is really slick, but the actual content left a lot to be desired.
I used Git for one project in the past. I am much more experienced with SVN when it comes to source control for personal projects, and have used CVS in industry. I figured I could use this tutorial to better understand the way Git works as compared to what I'm used to, and to learn some of the commands, since I used Git via a Windows GUI.
What I Liked
I was really impressed with the tutorial implementation. Underneath the instructions up top, they had a little console you type your commands into. It's not fully functional by any means, but supports more than I expected. It's nice to be able to interactively try something while you can see the instructions so you don't have to switch your attention between multiple windows.
Under that, there is a little window showing the file structure you are working with for the tutorial. You can browse it, but you can't change it. It's nice to see what files you have access to visually.
The breadcrumbs up top are also a nice visual to show your progress through the tutorial.
What I Didn't Like
I thought the content of the tutorial left a lot to be desired. It was a little too basic, and didn't give much explanation of how source control works in general. In fact, there wasn't even much explanation of how Git specifically worked. It was mostly 'do this, do that.' This ended up not helping me take my Git knowledge further, and I felt like beginners would end up leaving with little real-world Git ability.
There was some more explanation and advanced information in the 'Advice' box at the bottom right of the page, but you have to scroll down to see it. When I even remembered it was there, it was annoying to get to, and the text was rather disconnected from the main content. It didn't end up being very useful because of this.
They give you a handy way to copy the main command you are working with into the console, which seems like a good idea at first. But honestly, if you aren't typing the one line commands in each of the tutorial steps, what are you actually going to learn? With the lack of meat in the tutorial, getting some muscle memory from typing the commands is the only real takeaway.
To top it all off, the main content had noticeable typos, which always distracts me.
In the end, I'm not a huge fan of this tutorial. I have to admit this tutorial wouldn't compel me to pay for access to the rest of Code School's courses. But it's a good start in trying to teach people about programming and related systems (like source control), so hopefully we'll see more iterations of this sort of thing in the future.
If you tried the tutorial, what did you think?
Wednesday, July 4, 2012
Dr James Paul Gee is one of gaming's best advocates by promoting the fact that good games are good for learning. But what exactly is a 'good' game? What makes a game good for learning? Gee explains all of this in his Games for Change Festival 2012 keynote talk.
The funny thing is that Gee figures people must have thought that, in all these years, he was promoting bad games as being good for learning... after all, it seems that most people are choosing bad games to study or use, and then wondering where the magic is!
Luckily, Gee shares in his talk what is takes to be a good game. Part of the equation is the idea of a 'Big G' game versus a 'Little G' game: a Little G game is just the game — the software you bought — while a Big G game is the game, an affinity group surrounding that game, and a long list of characteristics found in that game. An affinity group is a gathering space, often online, where people with a passion for a particular game come together. (Gee talked a lot about these in his book on women and gaming, which I reviewed last year.) It's the Big G games we have to look at.
The characteristics needed for a Big G game are listed below. You can see more explanation of these in the talk or somewhat in my notes (linked below). The list items are quoted directly from Gee's slides.
- Collective intelligence: Output from groups smarter than output from individuals
- Gamification: Motivation and direction of attention
- Smart Tools: Agents and knowledge that store knowledge and teach
- Crowd Sourcing: All contributions potentially count
- Convergence: Multiple media and tools well connected
- Data Mining: Copious data well represented
- Assessment as developmental trajectory towards mastery
- Standards: indigenous and models
- Distributed intelligence: Intelligence stored in a network of tools and people
- Emotional intelligence
- Social intelligence
- Embodied intelligence: Tacit understanding
- Situated Understanding: Words married to images and actions
- Critical thinking: Thinking strategically at a meta-level
- Design thinking: Thinking like a designer
- Systems thinking: Multiple variables and unintended consequences
- Model-based reasoning: science
- Literacy: Articulation of Tacit Understandings
- Problem Solving: Facts as tools
- Production/Fabrication: Modding mentality
- Cycle of expertise: Practice + Routine Mastery + Challenge to that Mastery
- Preparation for future learning
- Augment reality (surmise new possibilities)
- Adaptive Mentoring: Guided, well designed, customized experience
- Learning ecology: Learning in lots of different ways and spaces
- Remedial: repair past damage
- Interest -> Passion
- Art: Making Strange
- Cultural models: Challenge the taken-for-granted
- Identity: Being/Agency/Counting