A soft approach to computer science: designing & developing computer games for and with senior citizens.(Report)

ABSTRACT

This article introduces a soft approach to programming and especially game development, based on the inclusion of the end user in the development process and on the rigorous use of a scaled-down version of the Unified Process.

Students were assigned to develop a computer game for and with senior citizens. The project started by observing senior citizens in their natural habitat, researching what passions occur in their daily lives. Consequently, students and seniors co-designed the selected ideas into game concepts. One game concept was chosen to be developed: Petanque, a multiplayer jeux-de-boule game.

A player-centered, iterative, and incremental approach was applied during the actual development of the game. During a five-week course, the students worked full-time in a team taking on different project roles. We encouraged the use of existing software engines and frameworks to ensure that, within a limited amount of time, a playable demo could emerge. The demo was finally evaluated by a senior audience.

The project resulted in an inspiring computer game, directly grafted onto the passions and desires of the seniors. Students gained insight into and empathy with their player audience and became aware of the diverse soft skills that are necessary for the creation of successful software applications.

Categories and Subject Descriptors

H.5.2 User Interfaces--User-Centered Design

K.6.3 Software Management, Software Development, Software Process

General Terms: Design, Human Factors, Management

Keywords: Seniors, Elderly, Game Development, Game Design, Co-design, Participatory Design, Human-Centered, Player-Centered Design, Software Engineering, Unified Process.

INTRODUCTION

The Master in e-Media

The Master in e-Media is a graduate program for students who have a bachelor's degree in Computer Science or an equivalent degree. The program specializes in the development of rich media applications and has a special focus on higher level programming skills, software engineering, computer graphics, digital media, and human-computer interaction. Recently, we saw a rising interest with our students in game development; therefore, the program started to incorporate games as a specific topic. In particular, a course on User Experience was broadened to incorporate player-centered design, and more fundamentally, we oriented the subject of our Multidisciplinary Project to game development1. This Multidisciplinary Project is a five-week, full-time course in an attempt to mimic a real-world job situation. Students work together in a team, taking on different roles to manage the development process. In this project, we follow a scaled-down version of the Unified Process (UP) [2, 5, 9] to software development, together with a player-centered approach. The UP defines an iterative and incremental software engineering framework that can be extended and customized for specific projects. This hands-on, real-life experience prepares our students for the intricacies of large-scale programming in a versatile, creative, and fast-paced (game) industry.

The I-Methodology

Students in Computer Science and thus game development courses prefer to tap into their creativity and come up with their own ideas [15], referred to as the I-methodology [12]. This self-centered design process often results in boys designing for boys [6], or to put it in other words, gamers designing for gamers. Combining the I-methodology with the fact that Engineering and Computer Science programs (and consequently the game development industry) are mainly populated by young white males [7], the difficulties are obvious when trying to develop games aimed at a wider audience. As a result, a widespread critique is that the game industry has difficulties in addressing nontraditional player groups [14]. The industry, however, is aware of the lack of diversity and the need for a more player-centered approach to gain maturity [18]. Similarly, with our e-Media program, we want to address the need for software development and management skills, and the need for a more human-centered, more inclusive approach to user interaction.

Elderly and the digital divide

A call for projects to close the digital divide for elderly in society, launched by the Belgian King Baudouin Foundation [8] in October 2005, drew our attention to a senior gaming audience. The symposium of the foundation indicated that there was a clear necessity to develop software applications with a senior audience in mind. The digital divide is threatening the independence of senior citizens. Computer, Internet, mobile phones, e-mail, Internet banking, interactive television, etc.--modern life is increasingly digital. Seniors did not grow up in a digital society and have a hard time adapting to and coping with these new circumstances. However, the foundation also mentioned an opportunity; seniors want to and can manage in a digital society, as long as applications are designed with respect for their user characteristics. Two key points to lower the digital threshold are a greater focus on user friendliness and a better match between applications and the needs and interests of seniors. For the e-Media program, choosing this audience clearly necessitated a player-centered approach to game development while aiming at the noble goal of closing the digital divide.

PLAYER-CENTERED GAME DEVELOPMENT FOR AND WITH SENIORS

We deemed a player-centered approach necessary to innovate game play for a senior audience. Therefore, we conceived a project in which students developed games for and with senior citizens. The project activities encompassed five different phases, distributed over a semester course on User Experience (during the first semester), and a condensed five-week, full-time course on game development (during the second semester), called Multidisciplinary Project. In phase one, we started with ethnographic inquiries of senior citizens. Consequently, in the second phase, seniors and researchers brainstormed for ideas and converted selected ideas into game concepts via a participatory design process. During the third phase, the game concepts were presented to a broader audience of seniors and one game concept was selected. This game concept was developed in the fourth phase. During this phase, we used a UP approach to develop a playable demo in only five weeks. In the fifth and final phase, the game was played and evaluated by the seniors. Phases one, two, and three were part of the User Experience course in which 10 students participated. Phases four and five took place in the Multidisciplinary Project in which six students participated.2 We now discuss the five different phases and clarify this soft approach to computer science with some illustrations.

Phase One: Ethnographic Inquiries

We started by conducting ethnographic inquiries. Ethnographic inquiries originated in anthropology as a means of studying people in the wild. In the community of Human Computer Interaction, it quickly caught on as a type of qualitative user research that is particularly suited when designing for user groups that are little understood [4]. Ethnographic enquiries are part of those research techniques that are typically employed at the fuzzy front end of the design process. Through a method of observation and open-ended interviewing, audiences are studied in their natural environment. When user requirements are still vague and when the social context of an application needs further investigation, ethnographic research techniques have proven helpful [13]. When designing games, this type of user information can be especially helpful. Game design is a second order design [16, p.171], meaning that as a designer one can only design the rules of the game and never the direct player experience. Therefore, to understand what can transport a player into this second order reality or magic circle demands a deep understanding of the player audience and those aspects of game design that provide meaningful play [16]. Ethnographic inquiries are particularly suited for understanding what provides meaning and how to transport the player into this suspension of disbelief.

In our case, during the time span of one week, 10 seniors were observed and interviewed by our students in their homes (one student observed one senior). Ten senior citizens (seven male and three female) participated in the research project. The age varied from 68 to 80 years. All seniors were living in Flanders (Belgium). We should stress that we did not look for the "average senior," but rather aimed to include active and healthy persons who wanted to think creatively and contribute to the design process. Seniors were asked to record all enjoyable activities or passions. It was stressed that a passion is something that makes time fly, but can really be anything. We asked seniors to write these passions on sticky notes, and stick these notes in a passion logbook or on objects in the environment. In addition, we asked to take photographs of any artifacts, surroundings, or people related to these passions. If possible, "show and tells" of the passions were requested.

During three consequent visits, the students directly analyzed different factors that were important for a better understanding of these passions or enjoyable activities. What is the nature of the passion? What exactly makes it enjoyable? How is that passion situated in time and space? Are other people involved? Is there technology that facilitates the passion? Finally, students asked the senior to create a top five of the most important passions for him or her. To finalize the part of the research, the student wrote a biography of the senior that captured his or her daily life, needs, wishes, and dreams, and detailed the nature of the passions. In total, this resulted in a list of 10 biographies and 50 passions in elderly life that provided actionable inspiration, and more important, ensured that students gained insight into and empathy with the lives of senior citizens [1] (Figure 4.1).

Phase Two: Participatory Design

After the ethnographic inquiries were finished, we started with participatory design (PD) sessions. PD emerged as a design practice in Scandinavian countries in the 1970s in the development of work-oriented software applications [21]. The end user is included as an equal design partner in the design team with direct influence on design decisions [19]. From abstract players, our seniors became stakeholders in the design process, contributing directly as design partners. For this project, the aim of PD was a reinforcement of the ethnographic enquiries; our aim was to include users and social contexts into the design process to ensure that meaningful play would come out of the design sessions. However, the ethnographic enquiries were not directly aimed at games or playful behavior but more broadly focused on passions. With the PD sessions, we narrowed our focus and converged on games or electronic entertainment. We constructed design teams consisting of one student and one senior citizen (the same pairs were teamed up for the ethnographic observations). The PD sessions consisted of a brainstorm and a co-design session. A social scientist and an interaction designer were present to moderate and facilitate the design processes.

[FIGURE 4.1 OMITTED]

Seniors and students first brainstormed in small groups for possible ideas. Not surprisingly, many of the passions that were listed in the top five during the ethnographic inquiries also ended up as ideas on the wall during this brainstorm session. After the idea generation phase, the ideas were clustered and the senior-student teams evaluated them on their attractiveness. In the end, each team chose one idea upon which to elaborate.

Consequently, this idea was then co-designed into a game concept by the student and the senior. We asked for a document with the title of the game genre and short overview, a description of the visual arts and style, a listing of the core objectives and challenges, the story or narrative if present, the gameplay theme, the game structure and levels, character features of protagonists and antagonists, an overview of player mechanics and reward/scoring mechanisms, and a description of the environment. Design teams were also encouraged to create paper prototypes and visualize their vision. However, the results of the participatory design workshops did not leverage this kind of detailed document; instead, what came out of it were more high-level concepts. In most cases, the theme was chosen and the type of gameplay was elaborated a little further. To ask for player mechanics, however, or reward or scoring mechanisms was clearly too difficult. Perhaps this was due to time constraints (two-hour session per workshop) or to the limited game design experience of the participants. Also for the students, this was the first encounter with a game design document. For each of the 10 teams, the result of this participatory design process was a rough concept document, and if possible a paper prototype. Although high level and unpolished, we found most games to be surprisingly rich and diverse in themes and play style (Figure 4.2).

[FIGURE 4.2 OMITTED]

Phase Three: Presentation and Selection of the Game Concepts

From the ethnographic observations, we knew that seniors spend a lot of time on activities such as playing cards, solving puzzles, watching television, etc. However, when listing a top five of the passions, these activities fell short and did not show up, nor did they make it into the brainstormed ideas and game concepts. We expected more straightforward games concepts that were a translation of current puzzle or card games played by seniors. Instead, game concepts were layered with different themes and gameplay styles, and could interest a non-senior audience as well. The games ranged from interactive cookbooks with humoristic agents, virtual cultural travels, sport simulations, to role-playing games, and family quizzes.

However, most important, most games were about being connected as social beings; 6 out of 10 games were explicitly multiplayer games. It was often stressed that one should play together and that playing should not be an isolated activity. Furthermore, seniors required that games should have a purpose or value, meaning there should be some educational or cultural benefit (5 out of 10 games were about educating the player). Finally, we found that seniors stressed that one should contribute to society; even when designing games, it was often asked how this could help create a better society.

From this stage, we derived a passion model [1] that focused on important aspects of elderly life and aimed at providing a framework for meaningful play for our seniors. We understood that this generation emphasized social connectedness, personal growth, and that there should be a contribution to society. We organized passions and game concepts accordingly. Taking into account the passion model and the 10 high-level game concepts, the interaction designer turned this raw material into eight attractive game concepts, presented on posters. (3) (Two game concepts were too much alike and converted into one; one game concept was simply too vague.)

During a bimonthly meeting of the senior city council, the game concepts were presented on posters and seniors were asked to vote on their favorite game. There was no clear indication or consensus about one winning concept. Upon practical considerations of the staff, we chose the Petanque game to be developed further. Petanque is an outdoor sports game, typically played by a senior audience in Flanders and France. The main goal of the game is to throw balls as close to the jack (a smaller ball) as possible.

Phase Four: Development of Petanque

The actual development of the Petanque game started during a five-week, full-time course in which a team of six students contributed to the development. In a multidisciplinary, team-oriented way, students developed the actual game. A strong focus was on an iterative and incremental software engineering approach to carry the project to a successful end. Identical to classical software development, many game development post mortems sound the same:

"The game was late. It had too many bugs. Functionality was not what was originally intended. Getting the game out the door took too many development hours and the development team was under too much pressure. Even when the game was launched, management was not pleased" [11].

A common development methodology in game development is the lack of one, often referred to as a code-and-fix environment [11]. Therefore, applying methodologies of modern software development could only improve the process of game development.

From a software engineering perspective, this problem can be solved by switching from a waterfall-based approach to an iterative and incremental approach as described in the (Rational) Unified Process [5, 3, 9, 10]. Within the UP, each iteration selects some use cases and projects risks. This selection is taken through the entire process of requirements analysis, design, implementation, testing, and deployment. At the end, this results in a new project increment. High-priority use cases and project risks are tackled at the beginning of the project. Only after a few initial iterations, the focus is put on the development of an executable baseline architecture that should validate the architecture of the system and will act as the foundation of the remaining development (Figure 4.3).

[FIGURE 4.3 OMITTED]

The UP approach was selected for several reasons for our project. UP has proven that it can handle projects with a well-defined end-deliverable, but with an uncertain project evolution due to changing requirements and unknown risks. We want to stress that although the three previous phases led to an inspiring game concept, clear requirements were still uncertain or even unknown. The game concepts were inspiring high-level posters that provided a start, but were not even close to a clear design document for a game that could be developed by our team.

Second, UP seems to be tailored to projects with an unknown or unclear solution at project startup. Our students had no substantial experience with the application domain. The dynamic structure of UP offers a customizable process framework, which can be easily applied to small project teams [2]. We wanted to develop a game in which both programming and (3D) content creation matter. The development process had to be flexible enough to deal with both aspects equally well. The inexperience of the student team called for a disciplined approach; however, the limited time we could spend on this project invited a less-formal approach. A scaled-down version of UP allowed the combination of both.

Besides the limited experience and the limited time, the size of the development team also posed constraints on the type of game that could be realized. However, the multidisciplinary project had enough complexity to define clear roles for each student, depending on his or her background and interest. We distinguished between a project leader, a software architect, a lead programmer, a character artist, an environment artist, and a 2D interface artist. Students' responsibilities, however, were not limited to these predefined roles; if necessary, each student was expected to work on different aspects. Following the UP approach, the project went through the phases of Inception, Elaboration, and Construction.

Inception

During Inception, team roles and corresponding responsibilities were assigned, along with some project and process management agreements such as project planning and time tracking, risk management, quality assurance, etc. It needs to be stressed that the teachers only advised the students on this, but in the end, the students were free to do as they pleased. Eventually, they would have to face the consequences of their decisions, especially those of their project plan. Students also made decisions on the development tools and the environment used to create the game. Because of the short development time, students were encouraged to use tools and environments that would support ultra rapid development. As an environment, the team chose to investigate the Virtools framework [20]. This framework is suited for a Rapid Prototype Development due to the availability of a large collection of components, which can easily be used in a visual editor environment. If more specific behavior is needed, both scripting level solutions and developing new components in C++ are possible. For content creation, the team chose to use a combination of e-frontier Poser, Autodesk[R] Max[R], Adobe[R] Photoshop[R] and standard sound editors like the Windows Sound Recorder.

After the decisions on tools and frameworks were made, the original Petanque idea was revised. Although the game concept was already defined during the second phase, students were encouraged to do some more exploration with seniors and make adaptations to the game concept if needed. Getting a deeper understanding of Petanque was certainly necessary; not all international students were aware of the characteristics of this typical activity for Belgian people. Again, the involvement of seniors was sought after. After some real-life games and discussions with the president of the local senior Petanque club, students got an understanding of the rules of the game and especially the joy of playing the game. They learned the importance of the different types of throwing the ball and the strategic consideration of composing a Petanque team with different players and throwing skills. In addition, the team found out about the social context of the game, the outdoor experience, and the pleasure of drinking a glass of Pastis (a licorice flavored drink) while playing.

The team created a new game concept document in which they listed the key elements of their game and a first draft of the structure and style of the game. Students gave the following description of the concepts: "Petanque is a simulation--sports game, with 2 players, and intuitive, consistent controls [...]. We focus not on the competitive, but on "feel good" and social interaction between players [...]. There is a Practice Mode and Play Mode.[...] There are always visual and auditory explanations of functionalities. There is a possibility to compose a team of unique characters with individual skills. There is a consistent style in 2D interface and 3D content [...]. We use immersive 3D characters the player could relate to. We need matching music and sound effects [...]."

Elaboration

Next in line was the Elaboration phase. The overall target of this phase is to come up with an executable base-line architecture. To manage this Elaboration phase, several iterations were defined, each with its own deliverables.

In a first iteration, students worked out their ideas in a more detailed concept document. In this and the previous phase, the focus was on programming skills and on the diversity of skills that are necessary in game design and development. Use cases and scenarios that made up the base-line architecture were selected. The implementation of these scenarios would result in the major end-deliverable of the Elaboration phase. (4)

Although the students were familiar with the tools they had chosen, they certainly were not experts. Previous projects were quite small in complexity, so the team's experience with the tools was rather limited. A good plan was needed for knowing how to tackle this project and how to manage the project risks. Therefore, the team scheduled a second iteration of technical scouting with the tools, keeping the ultimate goal and their individual sub-goals in mind. The Virtools framework in particular was something they needed to learn more about in order to create a piece of software with the necessary complexity.

As soon as the students knew how use cases could be implemented with the chosen tools, the base-line architecture was designed and a basic framework was implemented, aiming to have a working demonstrator at all times. The previous individual scouting projects were revised and merged into the skeleton of the game. In a third iteration, the result of the merging was polished and preparations were made for an intermediate review, in the presence of Swen Vincke, CEO of Larian Game Studios and a professional game developer. Swen Vincke stressed that content creation often takes up more resources than the actual development and that there was a strong need for style guides when outsourcing this work. When analyzing the students' game, the lack of style guides was showing in inconsistencies within the visual style and certain gameplay components. The need for keeping an eye on the overall style of the game and formal documentation is necessary when different people are working in parallel on different parts of the project. The team also learned the value of getting user feedback as early as possible in the development stage. In particular, the game mechanics of throwing the balls, which is part of the basic gameplay, proved cumbersome and could severely damage the overall gaming experience. UP is not only use case but also risk driven; hence, the development team needed to implement a satisfying way of throwing the balls before elaborating other parts of the gameplay (Figure 4.4).

Construction

Filling in the initial framework with more content and game rules happened in iterations, which continued in the Construction phase, alongside testing. Initially, two iterations were planned. Each iteration would add more features, and the deliverable at the second and final iteration should be the finished game. Unfortunately, the team had to revise their plan during the course of events. The construction phase turned out to consume most of the time and more than was originally planned by the students. Because the team had no substantial technical experience, most implementation parts were underestimated, and in the end, the realization was delayed.

[FIGURE 4.4 OMITTED]

Testing and debugging took more time than first thought, and often, repairing one bug resulted in other problems arising elsewhere. An accumulation of these small delays resulted in the project going over its schedule. Fortunately, the students did implement a safety net by setting their personal deadline largely in advance of their ultimate presentation deadline. This safety net allowed them to add a third iteration to the construction phase, where originally two were planned. The cost of this approach was that some motivated students had to put in more than the 200 hours (or five weeks full time) than were originally scheduled. Part of the management process required students to keep track of the time they spent on the project. We found that for some of the students, a better estimation of the actual workload was about 280 hours. This unplanned heroic programming resulted in a project slip of 20% in total. Students realized that this was a consequence of poor project planning, and exactly the kind of situation that has to be avoided in software development. In the end, because of the safety net, the prioritization of components, and the good will of some of the students, the team managed to present a fully working prototype.

Phase Five: Evaluating the Game, the Process, and the Tools Evaluating the Game

In a final stage, the Petanque game was demonstrated and evaluated. Unfortunately, our 10 seniors turned out to have busy schedules; only one senior managed to free his agenda. He gave an overall positive evaluation, but still made some useful remarks and pointed out flaws in the user interface: "The mapping of actions to controller buttons showed a lack in consistency. How to control the camera view on the boules was unclear. A more diverse team of Petanque players was wished for, not all 3D characters should be seniors" (Gerald, senior). However, the critical game mechanics, the selection of players, and the throwing of the balls were implemented well and enjoyed by the senior player. In the overall context of the project, the team emphasized that they would have liked to have tested and evaluated the game more thoroughly and with a larger senior audience. They also would have liked to add an extra iteration, but in the scope of this course multidisciplinary project there simply was no extra time (Figure 4.5).

[FIGURE 4.5 OMITTED]

Evaluating the Tools

Students also evaluated the choice of Virtools framework. Choosing this development tool seemed logical in the beginning because the team was on such a tight schedule. The team decided to use as many predefined building blocks of Virtools as possible. Often, decisions in the process had to be made in one day, so there was simply no time to thoroughly investigate other options like writing building blocks themselves. However, how can one design a UP class diagram when one does not write the software himself? The students had to be creative.

By going through the Virtools API, they discovered ways to give structure to their application, divide the work, and communicate about the architecture in a meaningful way. In the beginning of the development phase, work could be done in parallel, using Virtools scenes. Near the final phases of construction, however, the students experienced that the scenes became more dependent on each other and work gradually became sequential.

When looking back on their first 3D game project, the team still felt the Virtools framework was a good choice. Virtools presents itself as a having "the ability to create striking, game-quality interactivity quickly and efficiently" [20]. To gain this advantage: "Virtools authoring software is built on the Virtools Behavioral Engine and offers an innovative graphical user interface [...] and behavior building blocks (BBs) to create complex interactivity [...]" [20].

However, because of this unique approach with predefined scripts and building blocks, Virtools requires a steep learning curve, even though most students had experience in programming.

In addition, the expertise in working with Virtools is not easily transferable to other pure programming engines. However, in favor of Virtools, students did stress that once accustomed with the Virtools approach, realizing interactive content is indeed rapid and powerful.

As for 3D content creation, 3ds Max seemed the best choice at first, since the team members all had a basic modeling course in the first semester. However, as they started to design character models, it appeared that this basic experience did not suffice for the detail and the amount of models they wanted within the limited timeframe. So eventually, a combination of Max and Poser was used, where Poser would deliver almost out of the box models that were adjusted in 3ds Max.

Evaluating the Process

From the beginning, the team felt that the clearly defined roles and tasks for everyone were an advantage that allowed for parallel working--students could even work at home. However, to keep things consistent, to help each other out, and to make sure everyone was working toward the same goals, a large amount of communication was needed. Eventually, all the students worked in the same room, each still covering his or her own role inside the project.

Reviewing the work of every team member and formally documenting every step in the development process felt initially somewhat as overhead. However, after the first iteration, templates existed for all documents and they learned that reviewing improved the overall quality of everybody's work. The iterative software development approach forced them to first develop a core system demonstrating all critical features that made up the heart of the game. Each iteration resulted in a new executable system that improved the previous one in quality and in number of features. They realized very quickly that this process was a safe approach to bring a project with so many uncertainties to a good end. They also experienced that defining the activities per iteration is a dynamic and nontrivial activity in itself since the option list seemed to become longer and longer: new requirements, always more and more "nice-to-have," bug fixes, etc. Near the end of the project, they worked with a task list sorted on criteria as task priority and task workload to make the best decisions in defining the next iteration activities. Clearly, it didn't make sense to work on low-priority tasks with a high workload when almost no time was left over.

The team also experienced the results of a poor project plan. Since this was the first large software development project for the students, some typical pitfalls of project planning became true. Obviously, the integration of software components, testing and debugging were clearly underestimated. However, they also learned that, besides programming, content creation is a very time-consuming technical task in developing a game. From the beginning of the project, the students were asked to keep track of all time spent on every project activity. The data collected in these time sheets should help the students to better plan individual activities in future projects in general, not only game projects.

After further processing these time sheets, the students also clearly saw that coding was only a small part of the project. Only 38% of the time was spent on the actual implementation; the rest went to communication, planning, and other activities. These soft activities took up almost two-thirds of the time spent on actual game development.

CONCLUSION

The choice of developing computer games for seniors was a valuable exercise to teach students about the intricacies of programming on a large scale in a multidisciplinary environment and about the importance of a player-centered process. The ethnographic observations and co-design sessions provided a valuable inspiration for game ideas and led to creative and nonstereotypical game concepts that ensured meaningful play. Students gained insight into and empathy with their player audience.

The Unified Process approach to game development helped students to organize and prioritize their time and work, which is critical to the complex process of game development. The Virtools framework along with other rapid prototyping tools helped students deliver a working prototype within a limited amount of time. Students became aware of the diverse and versatile aspects that are part in the creation of computer games.

However, the most important skill they learned was to work together, to manage, and to communicate so that in the end all the pieces would fit the puzzle. The results of this approach resulted in an inspiring computer game, directly grafted onto the passions and desires of the senior. Students also gained insight into the soft skills that are necessary for the creation of computer games. Software development is more than only coding.

ACKNOWLEDGMENTS

We would like to thank all the students of e-Media, 2005-2006, who contributed to this project, and Veerle Van Rompaey, who helped to design the user research methodology. Furthermore, we are very grateful to the senior city council of Louvain, and especially Jerome Verhoelst. We would like to thank Swen Vincke for his useful remarks about this project. Finally, we thank the King Baudouin Foundation for their support.

REFERENCES

[1] Abeele, V. Vanden, and Van Rompaey V., Introducing human-centered research to game design: designing game concepts for and with senior citizens, ACM CHI '06 extended abstracts, 2006, 1469-1474, ACM Press, http://delivery.acm.org/.

[2] Augustine L., Lowe C., Madhur J., and Pollice G., (2004), Software Development for Small Teams: a RUP-centric Approach, Addison-Wesley, 2004.

[3] Bethke, E., Structuring Key Design Elements, 2003, www.gamasutra.com/features/ 20030411/bethke_pfv.htm.

[4] Blumberg, J., Burrell, M., and Guest, G., An Ethnographic Approach to Design. The Human-Computer Interaction Handbook, Lawrence Elbaum Associates. NJ, 2003.

[5] Flood, K., Game Unified Process, 2003, www.gamedev.net/reference/articles/article1940.asp.

[6] Gansmo, H., Nordli, H., and Sorensen K., The Gender Game: A Study of Norwegian Game Designers, SIGIS, 2003.

[7] International Game Developers Association, Game Developers Demographics, An Exploration of Workplace Diversity, 2005, www.igda.org/diversity/.

[8] Koning Boudewijnstichting, Neen aan de digitale kloof. (No to the digital Divide) Symposium on Elderly in the Digital Society, 2005, www.kbs-frb.be.

[9] Kroll P., and Kruchten P., The Rational Unified Process Made Easy, Addison Wesley, 2003.

[10] Larman, C., Applying UML and Patterns--An Introduction to Object-Oriented Analysis and Design and Iterative Development, Pearson Education, 2003.

[11] Llopis, N., "Teams and Processes" in Introduction to Game Development (Edited by Steve Rabin). Charles River Media, USA, 2005.

[12] Oudshoorn, N. E. J., and Pinch, T. J. (eds), How Users Matter: The Co-construction of Users and Technology, MIT Press, Cambridge, 2003.

[13] Plowman, T., Ethnography and Critical Design Practice. Design Research, MIT Press, Cambridge, 2003.

[14] Ray, S. G., Gender Inclusive Game Design: Expanding the Market. Charles River Media, USA, 2004.

[15] Rouse, R., Game Design: Theory and Practice, 2nd edition, Wordware, Texas, 2005.

[16] Salen, K., and Zimmerman, E., Rules of Play, Game Design Fundamentals. MIT Press, Cambridge, 2003.

[17] Sannella, M. J., Constraint Satisfaction and Debugging for Interactive User Interfaces. Ph.D. Thesis, University of Washington, Seattle, WA, 1994.

[18] Sykes J., and Patterson A., Considering the User in Video Game Design, Workshop on Player-centered Design, 2004, ACMCHI 2006.

[19] Van Rompaey, V., Van Der Meerssche, B., Godon, M., Vanden Abeele, M., and Charliers, K., Connecting the family home: Co-designing new technologies for Community Communication. ECCR/ECA conference, Amsterdam, 2005.

[20] Virtools.com, Create Cutting-Edge 3D Interactive Content & Deliver Life-Like User Experiences, 2007, www.virtools.com/solutions/products/ pdfs/suite_4/ds_softwaresuite_eng.pdf].

[21] Winograd, T., and Kuhn, S., Participatory Design, Bringing Design to Software, Addison Wesley, 1996.

(1) In previous years, there was a stronger focus on distributed Web applications and augmented reality applications.

(2) Not all students participating in the User Experience course chose to follow the Multidisciplinary Project, which explains the different number of students.

(3) For a detailed overview of the passions, ideas, and game concepts, visit http://sbox.groept.be.

(4) For a detailed view of the architecture, models and schemas, please visit sbox.groept.be.

Vero Vanden Abeele, Jelle Husson, Luc Vandeurzen, Stef Desmet

e-Medialab, Group T--Leuven Engineering School, Vesaliusstraat 13, B-3000 Belgium vero@groept.be, jelle.husson@groept.be, luc.vandeurzen@groept.be, stef.desmet@groept.be