Adventures in Research: Creating a video game textbook for an information literacy course

Dean Sullivan; Jessica Critten

The problem

In the summer of 2012, faculty librarians at the University of West Georgia were tasked to come up with a solution to the continuing problem of high withdrawal rates in online sections of our semester-long information literacy course, LIBR 1101: Academic Research and the Library. This course fulfills a general education requirement, and is often taken by students at all educational levels. LIBR 1101 instructors often found it difficult to engage online students with the course material due in no small part to the course’s fundamental interdisciplinarity. Also, it was a challenge to assess student mastery of certain concepts in an online environment, so instructors became frustrated that students were able to advance to new material (which was often scaffolded on material that preceded it) without demonstrating that they had learned what they were meant to.

Title screen from Adventures in Research, Artwork by Heidi Black.

We suspected that one of the reasons students did poorly in online sections of LIBR 1101 (or dropped the class altogether) was because online environments often lacked a substantial context that made the content of the course personally meaningful. We wanted to create something, then, that would engage students by contextualizing the process and importance of research. In other words, students would respond to the content because they could see its relevancy, and how it might look out in the real world. Because we were not working within a “traditional” discipline, we also knew we would have to create something that would capture student attention by being entertaining. This criteria brought into relief that the traditional library video tutorial would not be enough.

The solution

It was decided that a video game might be the best option. Through playing a game that would walk them through the whole research process, students had an example of what a successful research project might look like and insight into the thought that went into each iterative step. Our hope was that students would stick with the game because they wanted to see how the game (which was constructed as a narrative) would resolve itself. Students would also be entertained with unique and complex characters, road bumps, achievements, and the agency to make decisions in the game that affected how (and if) they could proceed.

Designing the game

We quickly found that creating a video game required a sound plan with a realistic timeline. It took us about nine months to create what would become our information literacy game, Adventures in Research. We settled on a “Choose-Your-Own Adventure”-style game, which is designed to allow the player to make choices that affect the storyline and progression of the game. We thought this format would provide a reasonable level of interactivity and integration with concepts from the course. We then had a few meetings during which we created a storyline, a cast of characters, and matched course content to key points in the story. We designed the game around six acts:

Act 1: Developing a topic

Act 2: Evaluation and types of information sources

Act 3: Searching for resources

Act 4: Plagiarism and academic honesty

Act 5: Using information

Act 6: Presenting information

With this structure in mind, we then developed a detailed breakdown of how the story would progress, and where the player might make decisions. We felt that, because the game is a required component of a course, it would perhaps be too frustrating if students could make choices that resulted in Game Overs. (How many times would you want to restart a game if you had to play it?) However, we did find a way to integrate “bad endings” into the gameplay in a way that wouldn’t be an insurmountable roadblock to players: after the “bad ending” screen, the game just picks up again from the last choice. Once we completed the scene breakdown within the acts, we knew what characters and background art we would need. With this decided, we could start the process of looking for an artist.

Adventures in Research classroom scene, Artwork by Heidi Black.

Finding an artist turned out to be the most difficult part of the game development process. We had a clear vision of how we wanted the game to look, and finding someone with a similar style who could work within our budget was surprisingly exhaustive. We met with representatives from our university’s finance division to learn about what was involved with hiring and paying a freelance artist. We then wrote an advertisement that we posted to art school job boards and Craigslist, and waited for the artist portfolios to arrive in our inboxes. Once the artist was on board, we instituted a process and a timeline to monitor how and when the artwork would be produced.

We provided photos of real university locations, written descriptions for locations, and detailed character descriptions to the artist to use as references. From this material, the artist provided sketches that we could provide feedback on. Once we approved sketches and color tests (the sketch with colors added), the artist provided final artwork. We made sure to approve early artwork so that we were able to adjust final artwork that did not meet our expectations or requirements. We also required all character artwork to be certain pixel dimensions and be on a transparent background, and backgrounds also had pixel dimension requirements. All artwork was submitted in PNG format. The entire process from hiring the artist to submitting the final artwork took about three months.

The technical requirements for our artwork were largely determined by the overall technical requirements of our software development kit (SDK). An SDK is a tool (or collection of tools) that are used to create the software programming for a game.

Students learning about library resources, Artwork by Heidi Black.

One of the two game developers had some programming experience, so he chose the SDK appropriate for the project. We ended up using Ren’Py, which is a readymade scripting engine (based on the Python programming language) for interactive, story-driven games. Not having to create our own game engine from scratch saved us at least six months of development time. Another good aspect of choosing Ren’Py was that it is free, so that meant not having to devote a portion of our very small budget to tools. A lot of the stock game components that Ren’Py provided needed adjusting, such as saving and loading games and user interface elements (such as the settings screen).

We implemented a password system to control access to other parts of the game to prevent students from getting too far ahead in the game.

Lastly, no game is complete without music and sound effects. Luckily our systems librarian is a musician and kindly agreed to compose the music.

Roughly a month before the game needed to be complete, we asked for volunteers (a mix of library staff, faculty, and students) to test the game. We got some great feedback from this, but one lesson we learned was that we did not get a lot of needed technical feedback from people without a technical Quality Assurance background. We would have benefited from testers who could try to break the game, so that bugs could be squashed before release.

Adventures in Research in action

The game was first used in an eight-week online class during the 2013 summer semester. This course was team-taught by two librarians, neither of whom were involved in the creation of the game (but who were involved with its beta testing.) This was done purposefully, to get some outside perspective on the game and its effectiveness and shortcomings as a teaching object. One of the game developers did help create the curriculum for the course, as she had a better recall of the content and structure of the game. She was also responsible for creating the supplemental assessments that tested the students’ understanding and application of the game content. The game was designed with the idea that as a “visual novel” or interactive textbook, it would introduce the concepts and then be followed up in class with supplemental instruction, assessment, and exercises to give the student an opportunity to analyze information literacy concepts in the context of their own student work.

Unfortunately, class enrollment was too low to measure its effectiveness. It was tremendously useful, however, as an opportunity to create materials that could be paired with the game and presented to potential instructors of LIBR 1101 as a “packaged” course.

The game was used again in fall 2013, in an online course taught by one of the same instructors of the summer course and also in a face-to-face setting taught by one of the game developers. Initially the biggest problem that presented itself was the difficulty in actually playing the game, as several students lacked experience in downloading files and running applications. Later in the semester, some students experienced problems with saved games, although many of these cases seemed to be variants of the age-old “I forgot to save my game” problem.

In a qualitative survey given to each class at the end of the semester, students almost universally reported that they preferred the video game to a traditional textbook. The online course in particular seemed to respond to it; the concepts covered in the game were not covered elsewhere in the course, but student work largely bore out an understanding of those concepts.

During the spring 2014 semester, the game was again used in both online and face-to-face environments of LIBR 1101. Using the lessons learned from the fall 2013 courses, LIBR 1101 instructors paid special attention to giving students extra time and support to work out technical issues early on in the semester. The online section did not start using the game in earnest until the third week, and one of the face-to-face sections dedicated a class period to downloading the game as a class, and solving any technical issues that arose. Dedicating class time to downloading the game did reduce the number of technical issues experienced by students throughout the semester.

Student feedback received at the end of the semester indicated that while students greatly preferred the game to a traditional textbook, they wanted to be able to easily access any of the game’s acts after completion. There was also a request for more player interactivity in some sections of the game.

Conclusions and future applications

The game was created with the intention that it could improve and evolve based on feedback and assessment. In fact, that it was a “living” teaching object was one of the ways in which the game developers privileged it over a static textbook beholden to publication cycles. In this spirit, it will continue to be re-evaluated each semester it is used based on student feedback received in the end-of-semester qualitative survey. Student suggestions about improved logistics of the game (more easily accessing each act, more save slots, etc.) were implemented for the fall 2014 iteration.

We are also exploring making the game openly available to be embedded in non-library classes based on requests from faculty across campus. This would primarily involve creating different versions that de-emphasize LIBR 1101 as a story element. There has also been a request for pieces of the game that highlight certain concepts (Boolean operators; How to formulate a research question), and we might also consider how to do this in the future, being mindful that this might compromise a central goal of the game, which is to engage students in a narrative.

We also plan to investigate situating this game into the cloud, instead of it being something that students have to download to their flash drives or hard drives. This would involve getting server space to host the game, and might also cause issues with individual log-ins and saves.

Overall, we are very happy with how this game turned out, especially given our limited time, staffing, and budget. We anticipate that the game will continue to be used in both online and face-to-face sections of LIBR 1101 for the foreseeable future, and we look forward to exploring its utility in other environments.

Copyright © 2014 Dean Sullivan and Jessica Critten

Article Views (Last 12 Months)

No data available

Contact ACRL for article usage statistics from 2010-April 2017.

Article Views (By Year/Month)

January: 22
February: 7
March: 5
April: 4
May: 10
June: 0
January: 7
February: 11
March: 13
April: 13
May: 11
June: 16
July: 8
August: 10
September: 4
October: 11
November: 9
December: 10
January: 8
February: 6
March: 14
April: 6
May: 8
June: 17
July: 27
August: 5
September: 10
October: 14
November: 16
December: 12
April: 0
May: 15
June: 3
July: 7
August: 14
September: 10
October: 22
November: 15
December: 28