Theresa Devine - Shared Desires, Conflicting Agendas and Lessons Learned

Shared Desires, Conflicting Agendas, and Lessons LearnedOn Collaborating to Create Educational Games

Theresa DevineAssistant ProfessorArizona State University

[email protected]://studio4gaminginnovation.com/http://theresadevine.com/http://zamtox.com/

July 22-24 20142014 Serious Play Conference

@Studio4Games #LessonsLearned

mailto:[email protected]

http://studio4gaminginnovation.com/

http://theresadevine.com/



http://zamtox.com/

http://zamtox.com/

Desires



My Backstory



I am an artist.I was trained as a painter and printmaker. MFA 1994



The enlightened one….



No audience participation = preaching



Political and Social Art



Barrier between artist and audience.



2 miles per hour



My Desire: What if?



1995: I will make games and engage the fine art audience through play



Note: Day Job 1998-2010(this is important later in the story)



Their Backstory



Their desire: beyond boredom



!!!!!!!!



Anti-Critical Thinking



*sigh*



Assembly Line Learning



First comes instruction, then practice, then work on comprehension skills



Break free



And everyone read it….



And decided games would SAVE education



Reinforcement



Seduced



Shared Desires

Wishing and wondering

• Can the interface disappear? • Can the artist/educator become one with the

audience/students? • Can our message become embedded in the

delivery so as to make the communication intuitive?



Rapture



And so we set out on our journey…



Conflicting Agendas



My Agenda

• To make fun, engaging, meaningful, well designed toys and games that are works of art.



Their Agenda

• To make a game that will engage an audience in their research.

• To enhance their teaching.

Conflicting Agenda #1: Pedagogical Confusion



Fields I Encountered: Cases #1 and #2



Case #1: Chemistry two pervasive pedagogical approaches

Lecture to present CONTENT Learn by doing: CONTEXT



Content vs. Context

Content• Students usually enjoy this

type of approach• Hard to motivate non

majors• Difficult for non majors to

see relevance

Context• Fosters a more positive

attitude to school science over conventional courses

• Helps students make links to their lived experiences

• Seems to engage non majors



Collaborator for this game…

• Unable to choose an approach• “Just use the book”• Result: a content driven pedagogical approach

wrapped in a story and gameplay• Goal: give the students the same feelings of

positivity and relevance that a context approach would



The Hope

• To motivate students to learn an admittedly difficult subject; and

• Improve retention



Fail: Motivation

+



Fail: Good Game Design

+



Why didn’t I push back?



+

What happened when I did push back?

What I said What they heard



Hmmmm...



Case #2: First Year Composition

Teaching skills• Identifying, categorizing,

studying, and replicating approaches to writing.

• Emphasis on “Form”

Covering content• Anchored in specific content

but approached from multiple disciplinary perspectives



Game Design Stumbling Blocks: FYC

Teaching skills• To reproduce the professor

feedback loop in a game would require duplication of the human ability to discern and critique the student's writing

• This type of artificial intelligence capability is beyond what is currently technically available.

Covering content• Adds layer of game design

as it requires that a disciplinary context be created on top of the writing lessons.

• Expected degree of flexibility of discipline is difficult to achieve.



Irony

• it has been found that neither methodology produces the systematic and wholesale improvements in writing skills desired



Since 1968



Stumbling Block:Eliminate FYC

Writing Lab as Game?

+



What FYC is to English Departments



Hmmmm...



Conflicting Agenda #2: Technology Wars



The BattlesTechnology Battle #1: Purchase “out of the box” solution

Technology Battle #2: Choose a digital environment based solely on novelty



Seduced at a Conference



Tech Battle #1: Purchase an “out of the box” solution



Age Old Software Question…Build or Buy?



“No Silver Bullet” – Fred Brooks



Level One Assessment Criteria

1. What does the software do?2. Does the software fill the need of the

project?3. Does the software do what it does well?4. Who are the competitors? 5. What are the differences and similarities of

the competitors’ products with the software being assessed?



Level Two Assessment Criteria:Total Cost of Ownership (TOC)

• initial license fees, • hardware, • developers, • time, • training, • maintenance, • and feature development



Level Three Assessment: What is the best value?

• The least expensive isn't necessarily the best value.

• The best value is determined by the long term plan of the software.

• Clear requirements that explain how the software is going to support the research are needed to determine the long term plan.



If

• There are clear requirements• And a long term plan



Then

this is the point at which the – build, – buy, – or build and buy

decision can be made



But…

• The assessment process was never allowed by my collaborators.

• It was seen as “extra work” and “a waste of time.”



Hmmmm...



Tech Battle #2: Choose a digital environment based solely on novelty



Why?

• Collaborator thought – It was cool and cutting edge.– The NSF would fund the project because of the

choice of technology.– The students would respond to this technology.– It was a readily available consumer product

(one that every student already owned).



Problems

• Inaccessible to people with limited mobility.• Financial burden to students. – my students struggle to buy their books.

• Caters to a kinesthetic learning style.





Hmmmm...



Conflicting Agenda #3: Bait and Switch



I thought I was wiser…Contract establishing rolesStakeholder Requirements DocumentGame Design DocumentAgreement to make Board Game to transfer

research informationAgreement to make Board Game as a

prototype Agreement to create Video Game



Dead EndContract establishing rolesStakeholder Requirements DocumentGame Design DocumentAgreement to make Board Game to transfer

research informationAgreement to make Board Game as a

prototype Agreement to create Video Game



Board Game to transfer research information

• Was used to alpha test collaborator’s research• Had some success and some interesting data

was collected



Bait and Switch

• Once the transfer of research was complete and the collaborator saw a “working” game

• And had some data collected• The project was ended by the collaborator

because he/she had what was needed for his/her own research

• Did not care if I had what I needed for my research



What happened when I pushed back?

What I said What they heard



Hmmmm...



Conflicting Agenda #4:Disappearing Act



#1: Unwillingness to share research data



Why?

• Your guess is as good as mine.• Fear?



#2: Orphan Textbook Syndrome



I took the class….



What these Disappearing Acts have in common.

• Lack of commitment from collaborator

(manifested in their failure to show up for meetings)

• Unspoken: “Do my research for me.”

• Unspoken: “My time has more value than yours.”



Hmmmm...



Lessons Learned



Know Your Limits andHave a Plan

Phase 1: Inception

• Pre-meeting research for game developer– Ask for teaching philosophy– Research pedagogy - look for opposing camps and assess degree

of emotional involvement in your collaborator and in your director.

• Meeting with collaborator:– Introduce process– Explain the difference between work for hire and collaborative

research– Collaborative research agreement– Collaborator homework: Stakeholder Questionnaire

• research data for game



Phase 2: Expectations

• Meeting with Collaborator: – Contract establishing roles– Technology Lead Agreement– Stakeholder Definition Document

• Collaborator homework– Stakeholder Requirements Document

• Meeting with Collaborator to discuss Stakeholder Requirements



Phase 3: Collaborative Elaboration

• Collaborator homework: First Board Game– The point is to transfer research and data needed

for the game– It is not a prototype

• No field testing or data collection allowed



Phase 4: Elaboration

• Developer homework– Initial Game Design Document• Set limitations on the project

– Project Plan Overview• Make it simple

• Meeting with Collaborator



Phase 5: Prototype

• IRB – Homework for Collaborator and Developer

• Developer Homework: – Board Game 2• Actual game design begins

• Field testing and Data collection allowed



Phase 6: Construction

• Developer Homework – Video Game • Promise only one game mechanic



More information

• http://studio4gaminginnovation.com/projects.aspx



http://studio4gaminginnovation.com/projects.aspx

http://studio4gaminginnovation.com/projects.aspx