Jonathan Chaboissier

Tobias Isenberg

Frédéric Vernier

RealTimeChess: Lessons from a Participatory Design Process for a Collaborative Multi-Touch, Multi-User Game

Keywords: ACM Classification: H.5.m [User Interfaces]: Miscellaneous-Multi-Touch Interfaces. General terms: Design, Human Factors Multi-touch multi-user gaming, participatory design, simultaneous collaboration, territoriality, awareness

We report on a long-term participatory design process during which we designed and improved RealTimeChess, a collaborative but competitive game that is played using touch input by multiple people on a tabletop display. During the design process we integrated concurrent input from all players and pace control, allowing us to steer the interaction along a continuum between high-paced simultaneous and low-paced turn-based gameplay. In addition, we integrated tutorials for teaching interaction techniques, mechanisms to control territoriality, remote interaction, and alert feedback. Integrating these mechanism during the participatory design process allowed us to examine their effects in detail, revealing for instance effects of the competitive setting on the perception of awareness as well as territoriality. More generally, the resulting application provided us with a testbed to study interaction on shared tabletop surfaces and yielded insights important for other time-critical or attention-demanding applications.

INTRODUCTION

With the increasing availability of touch-sensitive display technology in small and large devices it becomes more and more important to create user interfaces that are well suited to this new user interaction paradigm. In this paper we focus on the development of a gaming application that makes use of simultaneous multi-user interaction on a multi-touch tabletop display. Such tabletop settings are not yet marketed to a mass audience, likely due to the hardware's cost, its availability, and the lack of a 'killer application.' However, collaborative gaming is becoming increasingly popular not only in remote settings but also using shared displays. It is thus imperative to explore in depth the potential of tabletop displays as novel environments to support gaming. In our work we focus on integrating many of the affordances of touch-sensitive tabletop displays (such as the horizontal layout, the large surface size, multi-touch sensing, touch precision, and multi-user interaction) into a practical application. During a long-term design and development process, we created a mature application whose capabilities and interactivities were thoroughly investigated. Our goal was to take advantage of the tabletop setting and to design a unique type of gaming experience that can be supported based on it. Specifically, we support multiple (identified) people who simultaneously play a tabletop game using a touch-based UI (Fig. 1). While it is known [START_REF] Isenberg | An Exploratory Study of Co-located Collaborative Visual Analytics around a Tabletop Display[END_REF][START_REF] Isenberg | An Exploratory Study of Visual Information Analysis[END_REF] that teams of people tend to frequently switch between parallel independent work and closely coupled collaboration stages (for information work), we aimed to stimulate (high-paced) collaboration phases with our gaming application that are a synthesis between the two extremes: while people are playing a joint game in a closely coupled way, they are still performing actions in parallel as they compete with each other. Sequential collaboration and parallel interaction, in our co-located interaction setting, thus are the extremes of an interaction spectrum between turn-based and simultaneous gameplay. With our tabletop game we examine this effect as well as the effects of territoriality, collaboration and communication, perception and awareness, and surfaces interaction and gameplay.

For this purpose we report on the long-term participatory design process that lead to our touch game RealTimeChess in which we closely involved potential users during all development stages. The game is based on the well-known traditional chess game with its board, its pieces, and their motion patterns to help people understand the game and to learn its mechanics quickly. Moreover, the game allows players to simultaneously manipulate the pieces on the board but also controls by different ways the frequency of their actions. It thus provides the richness of real-time interaction in a gaming context. We paid special attention to the mentioned interaction aspects and describe not only the different development stages and the decisions that drove them but also summarize what we learned from the process. In particular, we saw that the specific interaction techniques that were offered and the specific settings of the environment affected the interaction behavior of people and that, specifically, the competitive setting changed how issues of territoriality and awareness were treated by players.

RELATED WORK

Work related to our own can mainly be found in two areas: gaming on touch-sensitive tabletop displays and the simultaneous interaction of multiple people on touch displays. We discuss both domains in detail below.

Games on Digital Tabletops

The general setting of horizontal digital surfaces is well suited for games due to its similarity to traditional board games. Several tabletop game prototypes have been developed in the past including False Prophets [START_REF] Mandryk | False Prophets: Exploring Hybrid Board/Video Games[END_REF], STARS (Knight Mage, Monopoly) [START_REF] Magerkurth | STARS -A Ubiquitous Computing Platform for Computer Augmented Tabletop Games[END_REF], Tankwar [START_REF] Nilsen | Tankwar -Tabletop War Gaming in Augmented Reality[END_REF], Entertaible [START_REF] Hollemans | Entertaible: The Best of Two Gaming Worlds[END_REF], the TViews role playing game [START_REF] Mazalek | The TViews Table Role-Playing Game[END_REF], Marble Market [START_REF] Fukuchi | Marble Market: Bimanual Interactive Game with a Body Shape Sensor[END_REF], and Settlers of Catan [START_REF] Havir | The Settlers of Catan Trades Up for Objects[END_REF][START_REF] Havir | Vectorform Game Studio and The Settlers of Catan. In The Microsoft Surface Blog[END_REF]. Most of these examples are tabletop versions of classic games (board, role-playing, or video games), they show that digital tabletops are well suited for collaborative or competitive games, and people generally like them.

It has been argued [START_REF] Magerkurth | Towards the Next Generation of Tabletop Gaming Experiences[END_REF] that, while digital tabletop games are inspired by traditional board games, their additional video game influence may lead to a new class of hybrid games. However, existing digital tabletop games largely employ turnbased interaction as in traditional games where each player must wait before others have finished their turn. Digital tabletop gameplay based on simultaneous interaction which is facilitated by multi-touch surfaces and which is common in the PC and console worlds, so far, has only rarely been studied.

One example of simultaneous collaborative tabletop gaming in a touch-sensitive display context has been studied by Tse et al. [START_REF] Tse | Multimodal Multiplayer Tabletop Gaming[END_REF][START_REF] Tse | How Pairs Interact Over a Multimodal Digital Table[END_REF]. Specifically, they concentrated on multi-modal interaction of teams of people with two PC games (Warcraft III, The Sims) by means of bi-manual gestures and speech input. A specific benefit of multi-modal interaction was found to be an added level of awareness between collaborating multiple players. The focus of this work was on collaboration within a team with a common joint goal. A competitive setup was described by Fukuchi and Rekimoto [START_REF] Fukuchi | Marble Market: Bimanual Interactive Game with a Body Shape Sensor[END_REF] in their Marble Market game for up to four players, each of who use their arms to simultaneously control many independent game pieces. While the authors report some informal observations, these are not generalizable and the game is used mostly as a testbed for their SmartSkin hardware. With our game, Real-TimeChess, we expand on both approaches by providing findings within different player contexts (single players vs. several teams), competing goals (players play against each other), and investigations into pace and speed of execution.

Relating to this aspect of pace and speed, one of the main characteristics of RealTimeChess is to abandon the turns of chess and to let players move their pieces simultaneously. Stanley et al. similarly abandoned turns for their digital version of real-time chess [START_REF] Gutwin | Chess as a Twitch Game: RTChess is Real-Time Multiplayer Chess[END_REF][START_REF] Stanley | Integrating Cumulative Context into Computer Games[END_REF]. Their research investigated how accumulated contextual information could be used to modify game state and how using this information affected gamer's strategies, behavior, and game play overall. While this work is related in its real-time nature to ours, we instead focus on the effects of game features related to the tabletop setting and tabletop interaction with RealTimeChess.

Simultaneous Interaction of Groups on Touch Displays

One aspect particularly important for our setting is the simultaneous collaborative interaction that is facilitated by multitouch displays. This simultaneous collaboration can lead to conflict situations when two or more people try to access the same object, leading to confusion and interference [START_REF] Morris | Beyond "Social Protocols": Multi-User Coordination Policies for Co-Located Groupware[END_REF]. In most cases, such simultaneous interactions are seen as a problem that needs to be mitigated by the system [START_REF] Morris | Mediating Group Dynamics through Tabletop Interface Design[END_REF][START_REF] Morris | Beyond "Social Protocols": Multi-User Coordination Policies for Co-Located Groupware[END_REF][START_REF] Ryall | iDwidgets: Parameterizing Widgets by User Identity[END_REF]. For example, Ringel Morris et al. [START_REF] Morris | Beyond "Social Protocols": Multi-User Coordination Policies for Co-Located Groupware[END_REF] devised different strategies of conflict resolution: a user is designated to decide how to resolve problems; in case of conflict, all users must agree by a vote; or the system itself becomes the arbiter. Alternatively, a privilege system can be used that determines for each object which person can access it. More restrictive solutions force users to synchronize themselves by using cooperative interaction techniques [START_REF] Morris | Cooperative Gestures: Multi-User Gestural Interactions for Co-Located Groupware[END_REF]. Tse et al. [START_REF] Tse | Multimodal Split View Tabletop Interaction Over Existing Applications[END_REF] divide the whole environment into zones so that each user has his or her own view and the freedom to interact inside this zone. However, this solution may impact group coordination.

The effects of simultaneous interaction, however, can also be used as an advantage to support collaboration. For example, Isenberg et al. created [START_REF] Isenberg | Collaborative Brushing and Linking for Co-located Visual Analytics of Document Collections[END_REF] and studied [START_REF] Isenberg | An Exploratory Study of Co-located Collaborative Visual Analytics around a Tabletop Display[END_REF] a system for visual information analysis. In this system, the interaction of one user with an instance of an object (such as a search term or a document) affects all related representations of this objects used by another person. This aspect of their system lead to an increased level of awareness of a collaborative investigation process. This type of real-time awareness is of particular importance in collaborative real-time situations where 'information is not waiting for users,' for example in flight control systems on tabletops [6]. Here, time pressure on the dynamics of a group of tabletop users is of essential importance. Zhang et al. [START_REF] Zhang | Put That There NOW: Group Dynamics of Tabletop Interaction under Time Pressure[END_REF] studied such a setting using free-paced and critically-paced scenarios and their findings indicate that collaborations between users (discussions, resources sharing, cooperation, and knowledge transmission) decrease under time pressure. While this may be negative for a command-andcontrol setting, it may be an interesting aspect in a real-time gaming setting such as ours.

In summary, many aspects of simultaneous interaction are important for us to consider but may not necessarily be best realized the same way in games as they are in work settings. The most important aspects we considered are arising conflicts, collaboration between people and teams, and real-time strategies. In our approach we aim to integrate them as part of our context of gameplay, and examine how gameplay is affected in the tabletop context.

PARTICIPATORY DESIGN PROCESS

To be able to incorporate a wide range of user feedback into the interface design process we followed a multi-stage participatory design process. The whole design process took place over the course of approximately three years and lead to a well-tested and stable tabletop game. In total, 48 people participated intensively in the design process, while we also received additional feedback from several other people. Specifically, the development in Stages 1-3 was guided by informal feedback, after which in a first study 22 people participated (17 male, 5 female, ages 21 to 41, all members of our institute). Of these 6 were novice chess players, one was a frequent player. This first qualitative study had two parts: first, people played in groups of two (11 groups), in the second part 8 of the initial 22 people played in two groups of four. In both parts one experimenter explained the interface, gave instructions, and took notes while observing the players' actions who were asked to think-aloud. After each game, the players were interviewed as a group and asked about their opinion of the game, what problems they met, and general suggestions. This led to Stages 4 and 5 which were evaluated in separate studies whose details are reported below.

By applying a participatory design methodology with our large number of players we were able not only to iron out usability and stability issues but also, more importantly, could analyze the effect of many interaction issues and benefits that are commonly associated with collaborative direct-touch and multi-user interfaces. While many interaction techniques for tables and group work strategies have been discussed in the past, we had to re-test and make adjustments to many proposed solutions to be most effective in our tabletop game setting. In particular, our game provided an excellent opportunity to try how specific game design features could be adjusted, re-designed, and mashed-up to elicit certain behaviors, such as more or less collaboration, awareness, and interaction with the board and other players. We outline how these features evolved in the following section to provide a clear argument for our game choices, to discuss which tabletop interaction techniques we changed and newly designed, and how these influenced players' strategies and behaviors.

Stage 1: Chess with Simultaneous Two-Player Input

To realize our RealTimeChess game we started our design by implementing a traditional two-player chess board and pieces in a top-down 3D view [START_REF] Hancock | The Effects of Changing Projection Geometry on the Interpretation of 3D Orientation on Tabletops[END_REF] (Fig. 2) where pieces are controlled by identified touch input using a DiamondTouch [START_REF] Dietz | DiamondTouch: A Multi-User Touch Technology[END_REF] setting. Based on this straight-forward implementation our first goal was to explore aspects of concurrent gameplay. We specifically did not start with an existing single-user PC game (as done, e. g., by Tse et al. [START_REF] Tse | Multimodal Multiplayer Tabletop Gaming[END_REF]) to allow us a higher degree of flexibility for our simultaneous multi-player design. To explore this aspect, our initial step was to transform the traditional turn-based strategy game into a real-time application where interactions occur fundamentally simultaneously, to reduce waiting times and increase the pace. This choice had a fundamental influence on many aspects of the original game which we needed to change, modify, and re-design:

Interaction: As we abandoned turns, we allowed pieces to be moved by the players at any time. Initially, we had imple- mented 'tap-n-tap' as a way to move pieces in which players would tap on the piece to move and then tap on the target field, taking advantage of identification provided by the Dia-mondTouch device to associate taps to tap sequences of specific users. The change to simultaneous playing, however, resulted in an increase of game pace and we observed that players quickly tried to find the fastest way to move pieces. Consequently, players also tried to move pieces by means of 'drag-n-drop,' so we added this interaction as an alternative. After some play time, however, tap-n-tap was preferred by players over drag-n-drop because it turned out to be faster for most and created less friction with the surface. Beyond dragn-drop and tap-n-tap, we did not implement any additional 'two-hands/fingers' technique because people never tried or suggested to interact with two hands at the same time (unlike in other contexts [START_REF] North | Understanding Multi-Touch Manipulation for Surface Computing[END_REF]) and because the DiamondTouch touch sensing only provides a bounding box so that two parallel interactions are less reliable to detect.

Influencing Game Strategies: The intensely increased game pace caused by the removal of turns, in addition to removing wait times, also lead to less complex strategies being employed by players. Hence, we next introduced cool-down phases to encourage players to think more about strategy again. For this purpose we introduced wait times (in the order of a few seconds) after having made a move, either for the piece that was moved or generally for a player. In particular this second cool-down method turned out to be difficult to time well: a wait time that is too brief does not have much effect, while too long cool-down times essentially re-introduce turn-based gameplay. We found that wait times of approx. 2 seconds prevent fast players from overwhelming their opponent without creating an annoying delay. However, shorter cool-down times can make games faster, encouraging speed, reactivity to others' actions, and spontaneity.

In fact, we were surprised about how determined and motivated players could play without the cool-down system to moderate the game's pace. In such a setting people sometimes went beyond the technical limits of our DiamondTouch hardware, touching the surface so fast that the table sometimes did not sense the contact events. In that case, losers were very frustrated and blamed the system for making them lose while winners, of course, were just happy. However, the game pace was not always as fast as it could be. We observed groups of players to naturally adopt a turn-based gameplay, one person waiting for the other player to move their piece, even when they could interact at the same time.

Visual Design: The fast speed of interaction also led us to make several visual adjustments to the interface. For example, we noticed that when players selected a piece they often gazed very quickly at the intended target square. To support such fast gaze changes we added visual feedback about possible moves of a selected piece (Fig. 3, left). The quick gazes also resulted in less attention to potential changes in the display of active pieces. Such on-demand information display is possible in mouse-based interfaces using hover, but touch sensing does not afford similar capabilities. Thus, any information about a piece needs to be visible even before the piece is selected. This applies, e. g., to showing that a piece is currently 'frozen' which we realized by showing the remaining cool-down time (Fig. 3, middle). Moreover, we added a 'next move' feature that lets players record a following for a 'frozen' piece (Fig. 3, right). The move is then automatically executed when the associated cool-down is over, providing a means for players to quickly launch a massive attack. If a waiting piece's target field is no longer a valid destination after a cool-down, the movement is simply canceled.

Physical Interaction: One particularly interesting aspect of simultaneous interaction is that arm collisions occurred and players reacted to them. Some players thought that these collisions are funny and considered them to be an important part of the game, and thus tried to block others. Other players became aggressive and actively pushed their opponent's hands out of their way. A final group of players was afraid of contact or just bothered by the conflict and waited for a more 'peaceful' moment to operate their move. We decided to follow the first group's lead and accepted the arm collisions as a part of the simultaneous gameplay, partially using cool-down time-outs to avoid too aggressive behavior.

After this first development stage our main concern was that it was difficult to teach the game to new people: how to move the pieces, the meaning of the visual feedback, and specifically the cool-down system for people who are not gamers.

Stage 2: Integrating Tutorials

To address learning issues we created tabletop-specific tutorials for RealTimeChess to teach players step-by-step how to interact with the tabletop and the rules of the game. We divided the chess board into separate personal training spaces such that each player could train separately but also could observe others' interactions for learning by imitation. The tutorials are separated into a part about piece manipulation and one about piece selection to better be able to teach the specifics about tabletop interaction.

The first part of the tutorial focuses on piece manipulation and trains the three ways of piece movement, based on a piece selected by the system and a random target to reach:

• drag-n-drop where source & target are explicitly acquired, • tap-n-tap where only the target is explicitly acquired, and • tossing where the target is implicitly acquired-the piece moves as far as possible in the given direction.

Training all three options-for the several different types of chess pieces-allows new players to assess the respective speeds and accuracies (Fig. 4).

The second tutorial part trains piece selection and the two cool-down methods. This part is initially still conducted in the players' separate regions to give them the chance to optimize their speed while observing their behavior compared to others. Afterward, however, the constraint of private zones is dropped and players need to use the whole tabletop area for selection and motion toward randomly selected targets. This means that players learn to share the surface with fellow players, to deal with issues such as colliding arms, and to adjust their strategy accordingly. The tutorial ends with a simplified game to get players used to real game situations.

In addition to teaching the game to players for the participatory design process, we also showed the tutorials to lab visitors and used them to train participants for four user studies (on Stages 1 and 3-5). In all cases we observed that the mutual collaboration that was evident in the tutorials entirely disappeared in real games. This was disappointing for us, as we had hoped to create a collaborative experience and, thus, in the next design stage we incorporated more collaboration aspects into the game experience and also explored how gameplay would be affected by more than two players.

Stage 3: Up to Four Simultaneous Players

To support more mutual collaboration we extended the game to up to four players (Fig. 1) and specifically explored team play situations (such as 2 vs. 2 or 3 vs. 1; Fig. 5). For this purpose we extended the board to larger and non-square sizes to fill the entire display space, added more pieces, and used dedicated colors to distinguish the different players (using warm and cold colors to indicate team membership). Experimenting with a large pool of players in an iterative process when adjusting such aspects was crucial at this stage to keep the game playable and enjoyable.

One of the concepts suggested by our participants were 'wall locations on the board where no pieces can be placed (Fig. 5). The interesting effect of this concept is that it divides the board into regions that are perceived by players as personal and private territories, relating to these concepts in collaborative tabletop interaction [START_REF] Scott | Territoriality in Collaborative Tabletop Workspaces[END_REF]. While such walls may not be necessary in regular chess between two people where distance to the opponent implicitly encodes territoriality, in games with four people-one on each side of a rectangular board-specifically the corner regions are automatically perceived as shared areas, with the owner being unclear at the start of a game. Wall squares make the regions more explicit even though 'private' spaces are not safe from interactions of other players as some pieces have long reaches (e. g., the queen). However, we observed that private areas are almost always devoted to hiding and protecting the king, and players perceive it as an aggression when other players (even teammates) reach with their arms into this area.

The extension to three or four players and specifically their locations around the board affected the perceived degree of teamwork. When teammates were placed side-by-side on the board they expressed a stronger feeling of working as a team compared to when we placed them opposite to each other. Interestingly, we did not observe much communication between teammates (speech or gesture) in either setting even if players expressed a strong feeling of being part of a team. We also noticed that that the larger boards that were necessary to accommodate more players and the speed resulting from simultaneous gameplay lead to more 'messy' games, affected by issues of reach. We often observed that players who sent a piece away to a far side of the board would leave it there because the effort to re-select it would be too high. To address such situations we concentrated on remote interaction techniques in the following stage.

Stage 4: Remote Interaction Techniques

The issue of having to acquire distant targets ('reach'), in particular in collaborative contexts, has been identified as a problem on touch-sensitive surfaces in the past (e. g., [START_REF] Bezerianos | The Vacuum: Facilitating the Manipulation of Distant Objects[END_REF][START_REF] Nacenta | A Comparison of Techniques for Multi-Display Reaching[END_REF][START_REF] Nacenta | The Effects of Interaction Technique on Coordination in Tabletop Groupware[END_REF][START_REF] Parker | Trac-torBeam: Seamless Integration of Local and Remote Pointing for Tabletop Displays[END_REF][START_REF] Reetz | Superflick: A Natural and Efficient Technique for Long-Distance Object Placement on Digital Tables[END_REF]). In our context we have the additional challenge that several people interact on a relatively small space, under time pressure, and in a competitive situation. Particularly on the extended boards we observed increasing problems with selecting distant pieces that have to be moved or local pieces that have to be moved to distant locations to win the game.

For the latter action we employ the previously mentioned tossing (e. g., [START_REF] Geißler | Shuffle, Throw or Take It! Working Efficiently With an Interactive Wall[END_REF][START_REF] Scott | Storage Bins: Mobile Storage for Collaborative Tabletop Displays[END_REF]). Applying this interaction to a selected piece moves it to furthest possible destination along the given direction. The specific parameters (speed, amplitude, etc.) were specified based on player feedback, with the DiamondTouch hardware [START_REF] Dietz | DiamondTouch: A Multi-User Touch Technology[END_REF] enforcing a minimum touch duration (very fast touch events may otherwise not be detected).

To support remote selection we examined several interaction techniques: a laser beam inspired by Vacuum [START_REF] Bezerianos | The Vacuum: Facilitating the Manipulation of Distant Objects[END_REF] and based on finger orientation detection provided by an extra computer vision system, a similar laser beam that derived the orientation from the direction of finger movement, and a 'magic ruler.' The magic ruler could be accessed in the board's margins and selected pieces using drag and release in a row successively as the finger moved away from the margin. All three interaction techniques were ultimately disliked by participants due to inherent imprecision, discomfort (twisting fingers), and intuitiveness (real fingers do not shoot lasers). To better understand these techniques we conducted a controlled experiment comparing the mentioned three techniques with a standard radar view (radar views were specifically recommended for games by Nacenta et al. [START_REF] Nacenta | The Effects of Interaction Technique on Coordination in Tabletop Groupware[END_REF]) and found that the radar view outperformed the other techniques.

Hence we decided to adjust the radar view technique to best support RealTimeChess but made very specific choices on the design of and interaction with the radar view. Initially, we activated a radar view by keeping the finger pressed and immobile for some time (approx. 750 ms), anywhere on the table. This activation, however, proved to be physically uncomfortable and sometimes also interfered with other techniques such as drag-n-drop. Therefore, we turned the radar view into a semi-transparent pop-up widget that could be activated via an icon located on each edge of the board (Fig. 6) and can be moved along this edge. Participants helped us to adjust the radar view's level of transparency to allow players seeing both the radar view and the board. With respect to the visual design we deviated from the typical world-inminiature representation of the chess board. We specifically employed an abstracted radar view (Fig. 6, right) that only shows occupied squares in the players' colors to discourage players from exclusively playing on the radar view (which would be similar to separate displays) and to force them to also focus on the joint full game board. For the same reason we also only enabled selection on the radar view and disabled the use of drag-n-drop and tap-n-tap on it.

To validate this remote interaction we conducted a second evaluation with 16 participants (14 male, 2 female), 6 of which were new to the interface. To create a situation with frequent physical interference we created a non-competitive setup in which each player was asked to move their pieces to the opposite side of the table. Players were free to use direct (tap-n-tap/drag-and-drop) or remote interaction (radar view for selection, flicking to move pieces). In addition to the players being observed by one experimenter, we also logged all game events and players completed a post-study questionnaire. When observing the differences between direct (dragn-drop and tap-n-tap) and indirect (radar view) interaction, we noticed that novice players often seemed to prefer direct interaction, while expert players tended to favor 'effortless' remote interaction. When four novice players discovered RealTimeChess together at the same time, however, we observed that one or two people started using the remote technique while the others kept using direct interaction, possibly to decrease arm interference and, thus, discomfort for themselves and for their fellow players. From player feedback we gathered that some users preferred direct interaction, others indirect interaction, while a third group adjusted to others such as to avoid discomfort as described. The radar view was, thus, a valuable addition to the game that could adjust to player's preferred playing styles.

Stage 5: Alert Feedback

After introducing the mentioned techniques to reduce conflicts, to facilitate remote interaction, and to manage the pace, one final aspect that was criticized by players was the lack of visibility of important events: when four people interacted and played simultaneously, the virtual space was constantly being updated and people's arms over the surface distracted other players. And so it was very difficult-even for expert players on the relatively small DiamondTouch table (107 cm diagonal)-to remain fully aware in this co-located setting. A good RealTimeChess player needs to keep an eye on all other players' moves to be able to adapt his or her strategy and be aware of treats. However, the higher-paced the game becomes the more difficult it gets for players to stay alert. Since the game requires from players to focus on specific pieces to move to specific locations, players quickly become unaware of events that occur outside of their focus region (due to inattentional change blindness [START_REF] Rensink | To See or Not to See: The Need for Attention to Perceive Changes in Scenes[END_REF][START_REF] Simons | Gorillas in Our Midst: Sustained Inattentional Blindness for Dynamic Events[END_REF]). This lead to players losing the game without an understanding of what had happened, resulting in much frustration.

Guided by feedback provided in other real-time applications on vertical touch-sensitive displays [START_REF] Athènes | Your Attention Please: An Evaluation of Animated Visual Signals for ATC Alarms and Notifications[END_REF], we therefore examined ways to inform players of events happening outside of their focus regions. Specifically we examined a global 'alert feedback' to inform players about important events. For this purpose we added concentrically growing circles, in particular, around a king that was being threatened and around pieces that were being taken (Fig. 7, left). As the feedback around threatened kings was relatively rare players readily accepted it. The second feedback-around taken piecesoccurred more often. While this feedback was also considered to be useful, it was also named to be distracting, in particular in four-player games. We improved it by clipping the circle and directing it only toward the owner of the affected piece to reduce this effect (Fig. 7, right). To validate these signals we conducted a final study with 24 participants (21 male, 3 female; 19 new to the interface) playing in groups of 4. We logged the game events, video-recorded the games and later counted the oral collaboration acts, and all players completed a post-study questionnaire. A statistical analysis of the recorded data showed that the clipped visual feedback was preferred by players without decreasing their performance, and that the feedback significantly reduced oral communication, i. e. people did no longer have to compensate for missing feedback by means of oral communication.

Participatory Design: Summary

Our participatory design approach [START_REF] Beaudouin-Lafon | Designing Interaction, Not Interfaces[END_REF] was invaluable for developing our collaborative gaming environment. In games, user interactions and reactions are often unpredictable for developers and four-player games are also quite difficult to debug and test as a single developer. While the tabletop community has developed a number of specific interaction techniques, has learned a lot about issued of orientation, collaboration, and conflicts, we had to design and re-design a number of well-known techniques and had to think carefully how concepts such as territoriality, ownerships, cooperation, collaboration, and awareness would apply in our setting and affect players' behavior. In the end, we designed a well-liked game (according to the informal feedback we received from our participants) which is also a useful test-bed for general issues related to tabletop collaboration. Our long-term approach to design led to a variety of lessons-learned, specifically in context of our competitive gaming application. We discuss these lessons in the following section.

DISCUSSION AND LESSONS LEARNED

We organize our lessons learned into five main areas: insights on simultaneous vs. turn-based interaction, observations on the effects of territoriality, inferences on collaboration, notes on perception, and conclusions about touch-based gameplay.

Simultaneous vs. Turn-Based Interaction and Pace

In general, turn-based gameplay appears to become increasingly rare in modern video games. It seems that turn-based in- teraction is considered typically only when high-level strategies are important, and less often for group activities. In fact, most previous gaming experiences reported by our participants were single-user games in which they faced the computer in real-time scenarios. It is therefore not surprising that, in addition to us as designers setting out to create a collaborative and concurrent gaming experience, our pool of participants clearly expressed a preference for a simultaneous game both at the start of the project and throughout the process.

One important aspect of such a simultaneous tabletop game is that it is well known that shared surface interaction can lead to conflict situations [START_REF] Nacenta | The Effects of Interaction Technique on Coordination in Tabletop Groupware[END_REF], e. g., through colliding arms (Fig. 8). While such conflicts are typically considered to be something to be avoided, in our gaming situation the conflicts can be an essential aspect of a game's attractiveness. However, not everybody appreciates the resulting physical contact which, moreover, became more frequent and intensive as the game pace increased. We addressed this issue by introducing the previously described cool-down mechanisms that we designed to support the dialog between players without interrupting them much. However, beyond this we also noticed that by changing the specific cool-down timeout we could transition the game seamlessly from a completely simultaneous interaction to an almost turn-based experience.

We can adjust the settings of a specific game to a group of specific players by picking a certain point along this continuous scale to make the tabletop gaming experience enjoyable for all players. The specific point along the spectrum depends on the players' individual paces because a game that is too fast for a player will not be enjoyable for him or her, while a game that is too slow will be boring. Furthermore, the setting also affects the group pace because it facilitates or prohibits communication between the players of a game. One could, hence, think of the extremes of the simultaneous vs. turn-based interaction scale to enforce individualistic experiences (either very fast or essentially turn-based), while the middle rather encourages group-based interaction (more time to communicate without players having to wait for each other). Whether this observation extends to other mutually collaborative interaction scenarios on shared surfaces, however, is not clear due to the competitive nature of our game and the effect of this competitive character on the interaction pace.

Territoriality

In addition to the effects of pace, RealTimeChess also allowed us to study the effects of territoriality on shared tabletop displays in a competitive situation. Similar to Scott et al. [START_REF] Scott | Territoriality in Collaborative Tabletop Workspaces[END_REF], we also observed that players thought about specific regions of the chess board as personal/private territories or as group territories (but not storage territories due to the nature of the game). In contrast to Scott et al.'s [START_REF] Scott | Territoriality in Collaborative Tabletop Workspaces[END_REF] observations/guidelines, however, these regions were not explicitly established or externalized but instead players seemed to have an implicit concept of the territories based on proximity, likely due to the rigid chess board layout. The private space of one player, for example, was the area that other players could not easily extend their arms into without being immediately noticed. Private spaces of other players were also hard to reach and trying to access them potentially meant facing physical hand/arm collisions. The center of the table was a group space in our setting but was often perceived by the players as a conflict territory. This space was full of 'inconveniences': arms of fellow players hindering one's own interaction and many chess pieces blocking movements.

Due to the layout of the regions largely depending on proximity, the placement of players had an important effect on how players perceived the territoriality of the chess board. While in the traditional two-player game there seems to be a transition from the close side of the board (personal space) to the middle (group/conflict space) to the far side (opponent's personal space), RealTimeChess' three-or four-player setups enable corner regions between two players to be perceived as being the personal space by both, leading to conflicts. We addressed such concerns with wall squares which made personal spaces more explicit, relating to Scott et al.'s [START_REF] Scott | Territoriality in Collaborative Tabletop Workspaces[END_REF] design guidelines. With explicit private and group spaces players rarely physically intruded into other players' personal spaces. This typically only happened toward the end of a game when less pieces were left and the king was huntedthen the frontier between the spaces seemed to disappear. We did, however, observe 'hidden intrusions' of private territories. When player sent a piece into an opponent's private space without being immediately noticed, the player would then try to remain unseen. They would then use remote interaction to move the piece within the opponent's private space while checking the opponent's gaze to see if this was noticed.

In summary, competitive real-time gaming applications appear to facilitate a form of territoriality that is different from document-oriented, mutually collaborative settings. Proximity, player placement, arm presence over the table, and ingame elements define personal and conflict territories whose frontiers, however, can be broken by remote interaction.

Collaboration and Communication

The competitive nature of RealTimeChess (as opposed to working for a shared goal as in many previously studied tabletop applications) also had an important impact on the collaboration between players. For example, despite our cool-down phases we still found little strategic communication between players, even if these were members of the same team. Players mainly lamented about having lost an important piece or asked for help. Strategic communication within teams often only occurred when one team player had lost and, thus, the player's personal competition had ended. In this case they would start giving advice to their team-mate. This behavior only differed in periods between games or during tutorialsall these being cases of less or no competition. Nevertheless, despite the low level of (strategic) communication during games, players still expressed a feeling of awareness of each other as a team. This feeling of awareness was stronger if the team players were placed next to each other, and it was weaker when they were sitting opposite of each other.

One additional exception to the general pattern of little to communication during games was that more experienced players would sometimes give advice to novices. More generally, we noticed that as players became more experienced they would also start communicating with each other more often. This happened, for example, if we would repeat games such as a 1 vs. 3 setup with the same people 4-5 times such that players not only became familiar with the interaction but also with the specific game setup. In those situations we also noticed that there was a correlation between the amount of collaboration and the players' efficiency, similar to the observation by Isenberg et al. [START_REF] Isenberg | An Exploratory Study of Co-located Collaborative Visual Analytics around a Tabletop Display[END_REF] for a mutually collaborative visual analytics task. For instance, one player in the group of three would then give orders to his or her teammates and would gesture with the arms to support this communication-similar to the interactions described by Tse et al. [START_REF] Tse | Multimodal Multiplayer Tabletop Gaming[END_REF][START_REF] Tse | How Pairs Interact Over a Multimodal Digital Table[END_REF]-resulting in such teams generally being more successful. Such multi-modal forms of communication as reported by Tse et al., in particular in gaming situations such as ours, seem to be essential in surface interactions to be able to relate, e. g., spoken communication to surface locations.

Nevertheless, we think that more work is needed to investigate how to foster and steer collaboration even in competitive and high-paced applications such as ours. We investigated this to some degree by using tutorials and short games with discussion times in-between the games to allow players to develop strategies. In other situations like the previously mentioned calls for help, however, collaboration should also be initiated to avoid that these calls remain unanswered.

Perception and Awareness

The competitive but simultaneous game design enforced a concurrent but extremely focused style of interaction for each of the players. This situation lead to people becoming increasingly unaware of other players' actions as a result of people potentially being blind to events outside of their own (small) focus. This effect is generally termed 'change blindness,' [START_REF] Rensink | To See or Not to See: The Need for Attention to Perceive Changes in Scenes[END_REF][START_REF] Simons | Gorillas in Our Midst: Sustained Inattentional Blindness for Dynamic Events[END_REF] and it was interesting to see that it occurs in our information-dense environment, even though the Dia-mondTouch table is a smaller one (86 cm × 65 cm) among the large touch surfaces available today. We saw that the pace of the simultaneous interaction directly affected whether players would get isolated and miss events in regions outside their focus. The lesson learned from this observation is that certain interaction styles such as focused simultaneous work may be subject to a loss of sensitivity to other people's interactions, despite the fact that co-located tabletop settings are often considered to be environments that foster awareness.

To address such perception issues we examined global and personal event feedback to draw a player's attention to a certain event on the board. However, alert feedback can become distracting and must be carefully designed. Interface designers need to consider the trade-off between an efficient and noticeable feedback on one hand and a less distracting feedback that people can more easily ignore on the other hand. From our experience, awareness features which can be directed to a specific receiver reduce intrusion and are generally favored.

Surface Interaction and Gameplay/Game Design

Our RealTimeChess game is inspired by traditional chess but has undergone a large number of changes including being played in a video game setting on a touch-sensitive tabletop display, with simultaneous moves being possible, and with more than two players. Every one of these changes has affected the user interaction and had an influence on the game experience. At all stages, however, we aimed to keep the game enjoyable. Even physical embarrassments such as arm collisions that in other tabletop applications are tried to be avoided were, by most players, considered to be an interesting aspect of the gameplay. Remote interaction that normally solves reach issues on large surfaces, in RealTimeChess, similarly becomes an aspect of gameplay as it enables a 'secret invasion' of an opponent's personal territory. All these examples show that what is often considered to be an issue in tabletop interaction, in our case, became aspects of the game design that made playing more interesting and challenging.

Other surface interaction aspects that we considered in the design of RealTimeChess are the use of single-touch vs. multitouch input and the aspect of identity. While multi-touch input is certainly a necessity for being able to allow four players to simultaneously interact with the game, most interactions occur by single-finger input. Only to invoke a menu or to pause a game players need to use hand postures. Experiments to use multi-finger or multi-hand interaction were not appreciated by the players and were, thus, abandoned. Being able to identify each touch as provided by the Diamond-Touch hardware [START_REF] Dietz | DiamondTouch: A Multi-User Touch Technology[END_REF], however, is essential to be able to restrict a player's interactions to his or her own set of pieces. If such identification is not available some aspects of the interaction need to be changed. For example, we adapted the game to FTIR input [START_REF] Han | Low-Cost Multi-Touch Sensing Through Frustrated Total Internal Reflection[END_REF] and, consequently, had to abandon tap-n-tap interaction, thus leaving only drag-n-drop for players to move the pieces. Moreover, players could now also move opponents' pieces (either accidentally or intentionally to cheat). These changes, our players noted, made the game a less enjoyable one so we did not pursue this option further.

CONCLUSION AND FUTURE WORK

In conclusion, we reported about a long-term participatory design process of a collaborative but competitive tabletop game with simultaneous multi-user input. This environment has allowed us to integrate and study a wide variety of interaction effects on touch-sensitive surfaces such as sequential vs. parallel interaction, cooperative vs. competitive work, territoriality, collaboration and communication, and perception and awareness. This allowed us to examine how offering or not offering certain interaction techniques as well as tuning the setup of the game affected these effects to get a better understanding of how they influence people's behavior.

By having reported the whole participatory design process and discussing the lessons that we learned from it we hope to inform future tabletop and wall application development as well as to get a more fundamental understanding how the individual interaction effects relate to each other. We see the contributions of this paper, therefore, not in any individual interaction technique specifically for our RealTimeChess game but more generally in studying how the mentioned interaction effects have to be observed as well as can be used such that they benefit the application. Of course, some the lessons learned from our participatory design process can generalized more than others. Specifically, we showed that the use of a high-paced competitive setup as opposed to a mutually collaborative environment affects, for example, how territoriality is being observed (applicable in tabletop applications in general), collaboration (supporting results from other tabletop applications), and how awareness changes (applicable in tabletop applications in general). This may have implications for other time-critical or attention-demanding surfacebased applications such as command-and-control (e. g., air traffic control). In addition, we think that most of our results can be generalized to other (maybe traditionally turn-based) board games (casino games, educational games for children, etc.) when converted into simultaneous tabletop games (i. e., lessons on game pace, aspects of territoriality, player communication, and surface interaction vs. gameplay/game design). Moreover, the use of participatory design for our touch-based application was a good choice due to the complex nature of the interface and the (multiple) interacting people.

A limitation of this step-by-step participatory design process, however, is the difficulty of having access to a good pool of participants. We intentionally asked some of the participants from evaluations of previous stages to also participate in later stages to ensure that they could give feedback on the changes. At the same time, we also needed new participants to ensure that the game remained accessible to players who had not followed the design from the beginning. In our case we also needed people with sufficient time in their breaks to participate to our game sessions. Limitations in our specific realization may be seen that we have concentrated, despite the DiamondTouch hardware's broader capabilities, on single-touch interactions. This design choice, however, resulted from our intention to limit the interaction to simple techniques without complex gestures or postures to facilitate fast-paced interactions, a choice that our participants appreciated; other application domains with less high-paced but still simultaneous interaction may also use gestural interaction.

Of course, there is potential for further work on additional improvements and other specific issues of the RealTimeChess game, some of which were mentioned in the paper. More generally, however, we think that continuing the study of how different interaction techniques and game settings affect the overall player interaction would be the more interesting avenue of future work, one that we intend to continue.

Figure 1 :

 1 Figure 1: Four people playing RealTimeChess.

Figure 2 :

 2 Figure 2: The initial RealTimeChess implementation.

Figure 3 :

 3 Figure 3: Visual feedback: left-motion pattern; middle-post-move cool-down for a piece; right: move pre-programmed to be executed after a cool-down.

Figure 4 :

 4 Figure 4: Four player tutorial on moving the piece onto the target indicated by the square with a cross.

Figure 5 :

 5 Figure 5: Wall squares that subdivide the board into areas, 2 vs. 2 & 3 vs. 1 game setups (left & right, resp.).

Figure 6 :

 6 Figure 6: A radar view for remote piece selection.

Figure 7 :

 7 Figure 7: Circular and player-oriented alert feedback.

Figure 8 :

 8 Figure 8: An instance where the arms of all four players are interfering with each other.

© 2011 Association for Computing Machinery. ACM acknowledges that this contribution was authored or co-authored by an employee, contractor or affiliate of the national government of France. As such, the government of France retains a nonexclusive, royalty-free right to publish or reproduce this article, or to allow others to do so, for Government purposes only. Conference ITS'11, November 13-16, Kobe, Japan. Copyright 2011 ACM 978-1-4503-0871-7/11/11...$10.00.

ACKNOWLEDGMENTS

We thank Petra Isenberg for her comments on the paper as well as all our participants for their time and feedback.


Bing-Yu Chen

Jan Kautz

Tong-Yee Lee

Editors Ming C Lin

Maarten H Everts

Henk Bekker

Jos B T M Roerdink

Tobias Isenberg

Pacific Graphics (2011

Keywords: (according to ACM CCS): I, 3, 3 [Computer Graphics]: Picture/Image Generation-Line and Curve Generation; I, 3, m [Computer Graphics]: Miscellaneous-Illustrative Visualization

We present a flexible illustrative line style model for the visualization of streamline data. Our model partitions vieworiented line strips into parallel bands whose basic visual properties can be controlled independently. We thus extend previous line stylization techniques specifically for visualization purposes by allowing the parametrization of these bands based on the local line data attributes. We demonstrate the effectiveness of our model by applying it to 3D flow field datasets.

Introduction

The flow of fluids and gases plays an important role in a wide variety of real-world phenomena. Examples include the aerodynamics of cars, the heat distribution in offices, and the airflow around falling ink droplets. Consequently, flow has been extensively studied, typically through threedimensional simulations. These simulations yield large amounts of data containing information at multiple scales; for some applications the general structure of the flow is most relevant, for others the small local deviations are the subject of study. Visual representations of flow data help in understanding its behavior and over the years a large number of methods have been developed for this purpose. Initially, most flow visualization methods employed photorealistic rendering techniques, but later-on also methods that borrow principles from scientific illustration were developed.

Inspired by such illustrative visualization techniques [START_REF] Rautek | Illustrative Visualization: New Technology or Useless Tautology[END_REF], we present a flexible method for illustratively depicting streamlines generated from 3D vector fields. We achieve this flexibility by introducing a line style model whose parameters can be interactively manipulated, thus facilitating the interactive exploration of the parameter space of visual streamline representations. This allows the user to select and generate the representations that are most suitable for the data and communication goals at hand.

In order to achieve flexible parametrization of line styles we generalize a previous illustrative approach for line visualization [START_REF] Everts | Depth-Dependent Halos: Illustrative Rendering of Dense Line Data[END_REF], by subdividing the view-oriented line strips that represent the streamlines. These strips are split into bands that are arranged orthogonally to a line's direction, and whose shape, color, relative distance to the viewer, and width can be independently controlled. In addition, we allow these line parameters to individually depend on local data attributes such as temperature or velocity.

In summary, the contributions of this paper are a flexible line style model for use in scientific streamline visualizations and a fast yet flexible implementation of this model on the GPU. We demonstrate the power of our approach for a number of 3D flow datasets that exhibit complex flow patterns.

Related Work

In this section we discuss related work in the fields of flow visualization and illustrative visualization. streamlines, whereas for unsteady flow streak and pathlines are used. The challenge for the visualization of threedimensional streamlines is overcoming perceptual problems. Simply rendering large numbers of lines can quickly lead to clutter and occlusion, not to mention the fact that the general thinness of a line makes it hard to convey depth and spatial relationships.

Flow Visualization

Solutions to deal with these perceptual challenges include careful placement of streamlines through seeding strategies (see [MLP * 10] for an overview), illuminated streamlines [START_REF] Zöckler | Interactive Visualization of 3D-Vector Fields Using Illuminated Stream Lines[END_REF], and shaded tubes or ribbons [START_REF] Sikorski | Efficient Streamline, Streamribbon, and Streamtube Constructions on Unstructured Grids[END_REF]. Particularly relevant for this paper are the approaches that employ textured view-oriented triangle strips to mimic shaded tubes [START_REF] Schussman | Scalable Self-Orienting Surfaces: A Compact, Texture-Enhanced Representation for Interactive Visualization of 3D Vector Fields[END_REF][START_REF] Stoll | Visualization with Stylized Line Primitives[END_REF]. Such shaded primitives need to have a certain width for the depth perception to work and have only a limited number of visual variables to convey additional information: typically only width and color, although textures can also be used to convey information about the flow [START_REF] Stoll | Visualization with Stylized Line Primitives[END_REF]. In terms of flexibility in controlling the appearance of flow streamlines, the approach by Shen et al. [START_REF] Shen H.-W | Interactive Visualization of Three-Dimensional Vector Fields With Flexible Appearance Control[END_REF] that uses 3D flow textures is relevant.

Illustrative Visualization and Line Stylization

Illustrative visualization methods [START_REF] Rautek | Illustrative Visualization: New Technology or Useless Tautology[END_REF] use and apply the principles of (scientific) illustrators to achieve the clarity and effectiveness found in traditional illustrations. Naturally, many of these methods employ techniques from the field of non-photorealistic rendering (NPR). NPR methods particularly relevant to our work aim to replicate line drawings and, for this purpose, support different line styles. [START_REF] Dooley | Automatic Illustration of 3D Geometric Models: Lines[END_REF], for example, use dashing for illustrating geometric models, whereas the difference vectors of Schlechtweg et al. [START_REF] Schlechtweg | Surfaces to Lines: Rendering Rich Line Drawings[END_REF] permit a larger palette of styles. Other line style parametrization methods include stroke texturing [NM00,KMM * 02,KDMF03], multiresolution curves [START_REF] Finkelstein | Multiresolution Curves[END_REF], skeletal strokes [HLW93, HL94], and programmable line styles [START_REF] Isenberg | G-Strokes: A Concept for Simplifying Line Stylization[END_REF][START_REF] Grabli | Programmable Rendering of Line Drawing from 3D Scenes[END_REF]. These NPR styles are typically applied to contour and feature lines of 3D objects, aim to replicate marks made by traditional tools, and-if used in an illustration-may carry a meaning (such as parts being hidden). In our work, in contrast, we use line styles to specifically visualize data properties of streamlines in a flow.

Dooley and Cohen

One important concept from the field of illustrative visualization important for our work is the use of halos [ARS79, SGS05, TCM06, EBRI09] to make objects (including lines) easier to discern from the background, thus improving depth perception. In the context of flow visualization, other illustrative methods related to our work include stroke-and painting-inspired visualizations of 2D flow fields [KML99, LHS08], illustrative 3D volume rendering [START_REF] Svakhine | Illustration and Photography Inspired Visualization of Flows and Volumes[END_REF], stylized streamlines [START_REF] Li | Image-based streamline generation and rendering[END_REF], as well as animated, dashed streamlines [START_REF] Laramee R | Geometric Flow Visualization Techniques for CFD Simulation Data[END_REF] and dashtubes [START_REF] Fuhrmann | Real-time Techniques for 3D Flow Visualization[END_REF].

Line Styles for Visualization

As we have seen, line-based flow visualizations are problematic due to their limited number of visual variables as well as the occlusion that is introduced if more than a few line primitives are being used. We address these two major issues by introducing an extended line style model for visualization purposes.

Line Partitioning Into Line Bands

Such an extended illustrative line style model needs to increase the number of visual variables to allow the specification and parameterization of a variety of effects that can be flexibly used in visualization. For this purpose and inspired by halo-based line visualizations [START_REF] Everts | Depth-Dependent Halos: Illustrative Rendering of Dense Line Data[END_REF], we partition the line strips that are used to render the data lines into several bands (Fig. 1). By that separation we provide the granularity that is necessary to allow us to define visually distinguishable styles, each of the bands increasing the number of visual variables that can be controlled. These bands run parallel to the centerline and together define the visualization line style. Specifically, we represent each line from the 3D dataset by a view-oriented line strip as done in many previous linebased rendering systems. This strip is subdivided into two mirrored sets of bands, one on each side of the line (Fig. 1). The three visual properties that we control per band are color, width, and distance offset w.r.t. the viewer, each of which can be controlled independently. While the distance offset is not actually a visual property, it has an effect when used as a depth-dependent halo [START_REF] Tarini | Ambient Occlusion and Edge Cueing to Enhance Real Time Molecular Visualization[END_REF][START_REF] Everts | Depth-Dependent Halos: Illustrative Rendering of Dense Line Data[END_REF]. In that case the halo line band is folded back, away from the viewer. The effect is that the visible width of the halo depends on the difference in distance between two lines w.r.t. the viewer, improving the depth perception. Therefore, our extended line style model can be seen as a generalization of the depth-dependent line halo technique [START_REF] Everts | Depth-Dependent Halos: Illustrative Rendering of Dense Line Data[END_REF].

Local Attribute Mapping

This basic line model allows us to specify a wide range of visual effects, notably by its capability to convey information about the data in the visualization by mapping data attributes such as temperature, pressure, etc. to a line's visual properties. Specifically, we control each line style band's color and width based on the value of local scalar line attributes by means of mapping functions.

c The Eurographics Association 2011.

For the color attribute, this mapping is encoded in conventional color maps that assign input values ∈ [0, 1] to RGB colors. We provide a selection of pre-defined color maps from which the user can choose a color map most suitable for that particular attribute type and the desired visual style. Similar to controlling the color of a band a user may adjust the width of a band to convey more information in the visualization. For example, mapping local velocity to band width yields wide bands where the velocity is high and thin bands where the velocity is low. To control this mapping, both a minimum and a maximum value can be set for the band width.

Flexible Band Shapes

The control of the line width property of a band can also be used to create bands with repeating line shape patterns such as dashes, droplets, etc. Moreover, the local density (or frequency) of these repeating shape patterns can be used to provide additional means for conveying local flow properties; this is particularly useful for the velocity property. For this purpose we employ (1) a shape mapping function and (2) a dedicated line shape attribute.

A shape mapping function maps a line data attribute (∈ [0, 1]) to the width (∈ [0, 1]) of the band at that point of a line. As such, it defines the shape of a band. We combine this mapping function with a dedicated line shape attribute:

s x = x l mod 1, (1)
where l defines the size of the shape pattern on the line and x is a line attribute that is monotonically increasing along the line. The modulo operation ensures that the shape is repeated along the line.

The choice of x in Eq. 1 determines the local 'density' of the patterns. For example, choosing the distance along the data line to the seed point results in constant size patterns. However, choosing the integration time t makes the frequency of the patterns depend on the local velocity of the field: high velocity will result in a lower frequency of patterns (i. e., elongated patterns), providing additional means for visualizing the local velocity. Together, the line shape attribute and the shape mapping function provide a flexible way to achieve a wide range of line shapes. Fig. 2 shows a number of examples of mapping functions and illustrates how the mapping function influences the shape of a band and, thus, the line style.

The Extended Line Style Model for Visualization

Together, the line bands with their color and width control, the means to parametrize the band width with mapping functions, and the repeating shape patterns extend the number of visual variables available for visualization of line data. Most of these visual variables can be combined in one visualization and convey multiple aspects of the streamline data in one image.

Implementation

Several design decisions of the conceptual line model were driven by implementation considerations. More specifically, because we aim for the interactive exploration of line styles even when applied to large datasets, the line style model should be suitable for implementation in shaders on modern GPUs. Our implementation consists of two parts, each implemented in a different type of shader. The first is the generation of view-oriented triangle strips (geometry shader) and the second is the application of the line style to the strip (fragment shader).

The transformation of the input lines (stored in GPU memory) into view-oriented triangle strips is done each rendering pass in a geometry shader. The width of these triangle strips is (pre-)calculated by multiplying a global scaling factor with the maximum the of line style widths. The width of a line style is calculated through a summation of the maximum widths of its bands. With the line strips in place as the 'canvas' for the line style, the next step is to apply the style model.

The actual application of the line style is done in a fragment shader. The main goal of this fragment shader is to decide which band of which line style should be applied to the fragment. To determine this it uses the position on the strip, the shape mapping functions, and the values of the relevant line attributes. Then, based on the settings for that band, the color (either from a color map or from a color pattern) and the depth offset of the fragment can be determined. of templated shaders. The main reason for this is that the flexibility of our extended line style model yields a large number of options, which without templated shaders would result in a large number of expensive conditional statements in the shader. The templated shaders (implemented using the existing templating library Jinja2, see http://jinja.pocoo.org/docs/) allow us to flexibly include only the necessary shader code, based on the chosen style configurations. This approach has the additional benefit of making the shader used for rendering as small as possible.

Results

To illustrate the broad range of possible visual representations of lines that can be achieved with our line style model, we apply a number of different line styles to two sets of streamlines. The first set is generated from a snapshot of a numerical simulation of a heat driven cavity (Dataset 1), the other set is generated from a snapshot of a simulation of turbulent flow around a cube (Dataset 2). It is important to note that although the streamlines that we visualize here may give the impression of a steady flow, they are merely a visualization of the flow field at one particular time step.

We start with the application of a single simple black-andwhite line style to Dataset 1 (see Fig. 3). This line style has two bands. The center-most band is white and fairly wide, whereas the outer band is thin and black. In addition, this outer band acts as a depth-dependent halo, although in this case it can also be considered a depth-dependent contour. The first thing to notice in Fig. 3 is how, despite the fact that no color has been used, the spatial relationships of the lines are still clear. Also, the depth manipulation ensures that collinear streamlines (e. g., the laminar flow at the bottom) blend together, emphasizing such collinear structures and yielding a crisper visualization. The close-up of the same dataset in Fig. 4 illustrates this aspect further. The next step is to employ the visual parameters that our line style model introduces to convey additional information about the flow. Figures 5 shows the application of a color map to streamlines, using a blue-purple color map to display velocity in Dataset 2. Again, the halo allows us to omit shad- ing and still have good depth perception, making direct application of color maps possible without a potential shading that affects the perception of the colors.

Besides color maps, the other way our line style model can convey additional information is through the size and frequency of shape patterns. Fig. 6 illustrates how an arrow shape can be used to convey both direction and velocity in a black-and-white visualization. Shape and color maps can also be combined, as illustrated in Fig. 7, where light gray arrows are combined with a fairly wide halo to which a color map is applied. Again the size (length) of a pattern indicates the local velocity of the flow. Besides an indication of direction, the arrow shape also gives the visualization a certain feel of motion. A similar effect is achieved with the tadpole shape shown in Fig. 8 where also a color-mapped halo is used, but with a constant shape length.

Discussion

As illustrated by the results in the previous section, our parametrization of line styles allows for a wide variety of visual representations of lines, accompanied by visual variables to show additional information about the flow. In this section we discuss further aspects, observations, and limitations of our line style model.

In terms of performance, we find that on a fairly modern graphics card (NVIDIA GeForce GTX 285), we can interactively manipulate the line style parameters whilst displaying fairly large datasets, facilitating the interactive exploration of different visual representations of lines. For reference, the two datasets in Section 5 consist of 2500 streamlines (2.5M vertices) and 390 streamlines (250k vertices), respectively.

An additional observation is that in our visualizations where the length of a (shape) pattern depends on the local velocity, the patterns are longer in high velocity areas. Whether this effect is intuitive seems to depend on the people who are asked and the kind of shape being used, as some people correlate high (pattern) frequency with velocity. A related observation is that when the difference in velocity is large, the shape might become too small in low velocity areas, see for example the right side of Fig. 6. Other rendering artefacts are possible, for example when (shaped) line strips overlap in a certain way, resulting in oddly shaped patterns. Also, occasionally there are small artefacts when the view-vector is parallel to the line direction, though the effect is minimal and methods exist to remedy this artifact [START_REF] Stoll | Visualization with Stylized Line Primitives[END_REF].

Finally, we presented our visualization results to a fluid mechanics expert in an informal discussion. In his initial reaction he commented on the "prettyness" of the images and found the visualizations very suitable for illustration purposes (e. g., classroom usage) because they illustrate wellknown phenomena very well. Interestingly though, he liked the simple black-and-white visualizations (such as Fig. 3) best, mainly because of their simplicity and expressive power.

Conclusion

We have presented a flexible illustrative line style model for the visualization of streamline datasets. By partitioning line strips into parallel bands whose basic visual properties can be independently controlled, we create a parametrization that allows us to represent a broad range of visual styles for line data visualization. This approach is combined with line attribute mapping functions for color and width to facilitate flexible line shapes and means to convey additional information about the flow.

Future work includes combining our exploration of line styles with interactive streamline seeding strategies to further improve the exploration of flow datasets for visualization and illustration.

Acknowledgements

We thank Roel Verstappen and F. Xavier Trias Miquel for the datasets as well as their discussion and helpful feedback.

c The Eurographics Association 2011.

  Being one of the most fundamental subjects for visualization, a broad range of methods have been developed for the visualization of flow datasets. McLoughlin et al. [MLP * 10] survey both flow visualization in general and integration-based, geometric flow visualization in particular. A key component of integration-based flow visualization methods is the use of geometric objects to depict the properties and structure of the flow. These objects are generated by integrating over the underlying velocity field-starting from a set of seed points. Lines are the most widely used primitives for this purpose, and in the context of steady flow such trajectories are called c The Eurographics Association 2011.

Figure 1 :

 1 Figure 1: A view-oriented strip subdivided into a number of bands mirrored around the centerline.

Figure 2 :

 2 Figure 2: Shape mapping functions and corresponding line styles.

  One additional aspect of our implementation is the use c The Eurographics Association 2011.

Figure 3 :

 3 Figure 3: A simple black-and-white line style applied to streamlines from Dataset 1.

Figure 4 :

 4 Figure 4: Close-up of streamlines with a simple black-andwhite line style applied to them. Notice how the depthdependent halo (contour) emphasizes collinear streamlines.

Figure 5 :

 5 Figure 5: Streamlines depicting flow around a cube, colored with a blue-purple color map to show velocity, combined with white halos for depth perception.

Figure 6 :

 6 Figure 6: An arrow shape mapping function applied with a simple black-and-white style. The size of the arrow indicates velocity.

Figure 7 :

 7 Figure 7: Streamlines depicted through light gray arrow shapes combined with a halos colored with a color map to depict velocity.

Figure 8 :

 8 Figure 8: Streamlines depicted with tadpole-shaped, fixed size patterns, combined with a 'halo' colored using a colormap (velocity).

c The Eurographics Association 2011.