Loading in 2 Seconds...
Loading in 2 Seconds...
Castles A Strategy Game Exploring Mobile Collaborative Adaptive Software. Matthew Chalmers, Malcolm Hall, Marek Bell University of Glasgow, UK. Castles And Some Other Seamful Games. Matthew Chalmers, Malcolm Hall, Marek Bell University of Glasgow, UK. Background.
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
CastlesA Strategy Game Exploring Mobile Collaborative Adaptive Software • Matthew Chalmers, Malcolm Hall, Marek Bell • University of Glasgow, UK
CastlesAnd Some Other Seamful Games • Matthew Chalmers, Malcolm Hall, Marek Bell • University of Glasgow, UK
Background • Seamful games as a testbed for ubicomp research • ‘Seamfully’ revealing system structure and use • Combining histories from multiple people, programs & devices • Using wireless networks to share or disseminate information • Bandwidth and memory: constraints and possibilities • Wired and long-range ‘infrastructure’ wireless networks: slow/costly? • Short-range wireless networks, e.g. 802.11, UWB: fast and free? • Substantial memory in mobile devices (backed up by servers online?)
Treasure (a.k.a. Bill) • Two teams of players, Blue and Green • Each player has PDA+802.11+GPS • Designed for disconnection • Server drops coins on each PDA’s map • Coin locations often outside network • Only receive this info when in network • Get close, pickup coins, get back into network, upload, get points • Pickpocket: steals another player’s coins • Only works when in network area • Shield: protection from pickpockets • Real-time maps of sampled coverage • Based on history of movement
Bandwidth and Memory • 802.11: hot spots set in cold expanses • Cost and ownership are significant constraints too • Many 802.11 apps assume constant access to one network • …but perform poorly on mobile devices that are really mobile • Peer-to-peer mobile ad hoc networks • Rely less on central servers, active Internet connection, particular access points, having a specific static IP address… • Issues of transience and security • High short-range bandwidth, taking advantage of local storage • New possibilities for interaction and gaming
Monopoly • Wi-fi hotspots in the city are used as ‘properties’ • Players’ PDAs detect and identify wi-fi access points • First player to find a property can ‘buy’ it • Other players owe rent if they pass by • Rent paid in face-to-face meetings between players • Information spreads peer-to-peer, between players • Small ‘ad hoc’ networks between players’ PDAs • Epidemic algorithms for spreading state P2P • Rent due, players’ locations, new properties, bids to buy, offers to sell…
Yoshii Feeding (Illegal Version) • Some play is indoors/online • Home wi-fi used like a (glowing) hotspot for street players • Also maps, stats and similar web paraphernalia • Most play is out in the street with PDAs • Looking for wi-fi hotspots and other players • Can auto-connect to net through AP? • A Yoshi lives there (and a Yoshi likes fruit) • Bring Yoshi its desired fruit to get a game point • Can’t connect through the AP? • It’s presented as a plantation, to seed and pick fruit from • Players can connect to each other directly: MANETs • Swapping/stealing fruit, and info on plantations & Yoshis
Yoshii Feeding (Legal Version) • Some play is indoors/online • Web site shows game score tables • Most play is out in the street with PDAs • Looking for wi-fi hotspots and other players • Open AP? • A Yoshi lives there (and a Yoshi likes fruit) • Bring Yoshi its desired fruit to get a game point • Closed AP? • It’s presented as a plantation, to seed and pick fruit from • Players can connect to each other directly: MANETs • Swapping/stealing fruit, and info on plantations & Yoshis • Stripped-down version available atwww.yoshigame.com
Domino • Castles’ subsystem for handling assemblies of software components • P2P ad hoc recommendations of software modules • Dynamic sharing, dependency resolution and integration • Recommendation based on patterns of use, and on classes and dependencies • But users express utility or contextual relevance in and through their use • Designers specify module’s class and class dependencies • Social and technical means for security and privacy • Transfer done as part of face-to-face game play • Also: certification of modules? Sandbox? Showing logs of use?
The Current State of Affairs • Legal Yoshi user trial just finished • Stripped-down downloadable version just made available • Pilot runs of Castles recently done • Same base set of 54 components: buildings, adapters and units • And also two other buildings, two other adapters, one extra unit • Recommendations helped players who had poor setups • Full trials of Castles beginning in October • Interface and comms improvements, larger component set • Video and system logs sync’d for playback in Replayer tool • Issues of uniformity of system structure: the cost of winning battles? • Building Bluetooth version of Domino infrastructure • Links with U. Nottingham, UCL, U. Bristol and Blast Theory
Conclusion • Games as a testbed for ubicomp, ubicomp as a testbed for games • Exploiting fast comms and storage of mobile devices • Seamful exposure of system (infra)structure • Past use as a resource for adaptation of system structure and ongoing use • Castles: system adaptation as part of a multiplayer game • More coarse-grained and accessible than modding code • How will players handle dynamics, develop strategies and adapt game play?
email@example.com www.dcs.gla.ac.uk/~matthew www.equator.ac.uk