View - Academy Publisher

More documents

Recommendations

Info

JOURNAL OF SOFTWARE, VOL. 2, NO. 6, DECEMBER 2007 87 On its waay through thhe simulated universe (accom plished by pphysical moveement of the ddevice hostingg the UbiQuest appplication), a sstarship can enncounter and iinter act with otheer starships (ddevices of otheer players) as well as with speccial entities, sso called star bases. Thesee star bases are staationary, non mmobile devicees within the MA- NET which aare equipped with higher pprocessing andd sto- rage power. TThis could bee e.g. a libraryy information com puter or a priivately ownedd desktop PC that features awireless card annd is taking part in the gammes network. CCom munication wwith other deevices or starr bases is accom plished ad hhoc. No centtral backbonee infrastructurre or access pointss are necessaryy. Accordingg to the games ad hoc enviironment, it distin guishes betwween three ddifferent leveels of interaaction [Fig.2]. Locaal interaction includes the mmicromanageement of the ships resources, faccilities and reesearch. Tradee, direct communnication (singgle hop) and ( (military) connflicts are situated on the tacticaal interaction level. Finallyy the strategic level encompassses longer terrm diplomacyy and espionage, aas well as ageent based commmunication with starships or bases not inn direct commmunication rrange (multi hop). Figure 2. Strategicc Interaction - Diplomacy Tactical Interaction - Trade - (Military) conflicts Local Innteraction - Micromanagement - Facility Managemennt - Research Interaction Levells Trade (on the tactical innteraction leveel) is performmed in two different ways. If a suitable tradee partner is wwithin communicatiion range (sinngle hop), a staar ships owneer can initiate a tradde request, ressulting in a poositive or neggative feedback from the trade ppartner. Takinng into accounnt the short time peeriod two mooving device mmay have conntact, another posssibility is auttomated tradee. Here the sship’s owner sets thresholds foor selling annd buying ceertain goods. If annother ship oor star base iin communiccation range dispersses matching offers, trade iis performed wwith out direct useer input. UbiQuest has been devveloped in JAAVA within thhe simulation envvironment JANNE, which is described in more detail in thee follow-on chhapter. The ffirst prototypee has been tested on HP-iPaq H5550 Pockket PCs, equiipped with a Holuux GM-270 CCompactFlash-GPS adapterr and integrated WWLAN capabillities. For JAVVA support on the mobile devicces we used thhe IBM Virtuaal Machine j9. The ad hooc communicaation within tthe game usees the routing frammework of the aforementionned simulationn en- © 2007 ACADEMY PUBLISHER viron nment JANE. . Multi-hop ccommunication n is based onn the DSR D [3] routiing protocol. AAnother impo ortant commu- nica ation service iis an upgradeed beaconing functionality, , prov viding not only information about the ships s locationn and presence, buut as well dispersing the current tradee offer rs etc. This iss accomplisheed by using th he PeriodiCastt beac coning protocol adapted to the trade off fer/request inform mation [4]. Coommunicationn in a cluster red MANET, , with hout routes to certain nodess, is implemen nted by usingg softw ware agents wwith certain ttasks. These try t to reach a spec cified device oor region, perrform their ta ask and returnn to a predefined hoome zone or llocation of the eir originator. . Typical tasks for aagents are dipplomacy and espionage. e Figuree 3. UbiQuest ddeployed on PDAs B. A Treasure Islland Setting foor ncoML The m-learningg framework ncoML was originally o design ned to support the training aand preparatio on of humani- taria an, catastrophhe aid and mmilitary missi ions that aree base ed on the tenets of Network Centric Op perations [5]. . Sinc ce it is a veryy flexible frammework, it ca an be used ass well l to depict sceenarios not dirrectly related to its originall inten nt. In the conntext of this year’s children n’s university, , whe ere kids have tthe opportunitty to get an ins sight into university life, it is planned as a veehicle to playf fully test theirr com mmunication annd cooperationn abilities. Fo or this, a Trea- sure e Island-like ggame scenarioo has been developed d andd impl lemented baseed on the ncoMML framewor rk. The system is ddesigned to be highly flexi ible and to allow many differeent mission tyypes within th he underlyingg fram mework. One typical scenarrio from its original o appli- catio on domain (e.g. in a UN oobserver mission) could bee the discovery d of ccommon graves or weapon deposits, e.g. . in a region that haas been or is bbeing harassed by civil un- rest or war. Witthin the Treaasure Island scenario, thee child dren’s objectiive is to find a hidden treasure, by wor- king g together andd by using inddividually ava ailableresour- ces, within a limitted timescale. Every E player is endowed wwith a GPS-eq quipped tablett PC providing p meddium-range coommunication n capabilities, , such h as WLAN. A digital mapp of the game area is storedd on the t device. Fuurthermore evvery player features certainn (sim mulated) abilities and posssesses prede efined assets. . Whi ile moving thhrough the ggame area ph hysically, thee
88 JOURNAL OF SOFTWARE, VOL. 2, NO. 6, DECEMBER 2007 player can innteract with thhe simulated wworld by usinng his or her abilitiies or by perrforming certaain actions, wwhich will result inn environmental or objectivve changes. AAssu ming the devvice will inform the playerr about a grouup of native populaace, which haave gathered iin the area shee just entered, by uusing her dipplomatic or laanguage skillss she can try to gaather information about the games objecttives. In the Treasuure Island sceenario, it is noot possible too suc- ceed in accomplishing thee mission alonne. The task oof the players is to learn that coooperation will lead to winnning the game fasster and with lless required rresources thann in a competing ennvironment. Figuure 4. Treasure Island Scenario ffor ncoML The basic design of thee learning frammework is divvided into two diffferent parts: The “framewwork” part andd the “scenario” paart. Both partss are completeely separated from each other, thhough withouut a scenario, tthe frameworkk will not provide any challengge to the plaayer, and witthout framework aany scenario iss purely theorretical. Scenarrio as well as mapp information is provided to the systemm via XML configguration files. They descrribe the simuulated “world” the pplayers can innteract with, ass well as the aavail able resourcees (abilities & assets). The frameework providdes the user interface andd the game map. FFurthermore iit calculates thhe success orr failure of decissions and upd dates the scennario accordingly. Most importtantly the frammework provvides the tools the users will neeed to communnicate and exccel in fulfillinng the mission as a team (chat, wwhiteboard, etcc.). The frameework allowss the analysiss of technicall and group dynammical effects in a mobile eenvironment, with players phyysically situatted in an auugmented reality. According too scenario or ssupervisor preeference, the ccolla borative leveel can be adjuusted from alllowing no usser to share and access any inforrmation, up too the possibiliity to display otherr player’s actiions, featuress and status onn the map without hiding any innformation. Onne important qques tion whose aanswer can be derived fromm the logged sstatis tic data is e.gg. the consequuence, an in- or decrease oof the collaborationn level will have on gaame success and efficiency. NCOml iss implementedd in JAVA as well and doees not require a ccentral commmunication innfrastructure, like © 2007 ACADEMY PUBLISHER WLA AN access pooints, but is bbased on mult ti-hop ad hocc com mmunication, pprovided by thhe simulation n environmentt JAN NE, which willl be describedd in more detail in a follow- on paragraph. p Central C part off the learningg framework is i a graphicall user r interface, whhich allows thee player to int teract with thee simu ulated world while physiccally passing g through thee gam me area. In thee first prototyype, the middleware JANEE allow wed to simulate the ad hooc network within w a LAN. . Here e physical moovement was simulated by y allowing too mov ve a virtual chharacter thoughh the game ar rea by using a remo ote-control-likke add-on too the user in nterface. Thee current version oof the framewwork runs on n Tablet-PCss usin ng the JANE pplatform modee. All A rules, objeccts, assets andd abilities with hin the systemm are provided by an external XML configuration file, , whic ch is uploaded to the playyer’s device on system andd gam me start. Gamee objectives annd detailed in nformation aree henc ceforth availaable to the pllayer. Objects include thee diffe erent team-meembers and thheir attributes and abilities, , as well w as simulaated real-worrld objects, th he player cann inter ract with. Actions A include using or intteracting with h objects, mo- difying them, pickking them up or dropping them, etc. In- terac cting with thee simulated rreal world usu ually requiress rand domized abilitty checks. All abilities are distributed d onn a pe ercentage scalee; where 0% mmeans no kno owledge/profi- cien ncy about the ttopic and 100% % ability mastery. Externall influ uences like (siimulated) weaather- or terrai in-conditions, , utiliz zation of diffeerent assets, eetc. can modify fy certain basee abili ity scores. E. .g. player “CCpt. Jacks” “observation” “ ” abili ity (50%) cann be modifiedd by a “spygl lass (observation x 1.5)” to 775%, since thhe spyglass modifies m any-- body y’s observatioon ability by tthe factor 1.5 5. Deciding too use the spyglass tto search for his lost shove el, but rollingg an 85%, 8 will result in not finnding it durin ng the currentt roun nd. Upon enteering a certainn part of the game g area, ex- istin ng terrain andd environmentt factors are automaticallyy affec cting defined abilities and aassets (like fog affects visi- bility y, trails or waater courses mmobility, etc.). Every E interaction between pplayers will co ommence in a certa ain amount off time (round) , – with either r a positive orr a ne egative result. Again, this tiime is random mized and mo- difie ed according tto the skill levvel of the user. During thiss time e, the player ccan not start a new intera action withoutt abor rting the runnning processs. The game e will finishh succ cessfully if thhe player willl fulfill certain predefinedd crite eria (objectivees). If these tasks are no ot performedd with hin a predefineed timeframe, , or if certain negative con- ditio ons occur, the player group will lose the game. g All A player inpuut, start and ennd-states, as well w as all in- term mediate resultss of any actioon or ability are a stored in a log file, f which is aautomaticallyy uploaded to the t supervisorr syste em after eithher failure or success of the t game forr furth her analysis. III. LOCATION IMMMERSION VS. REALITY AUG GMENTATION A. Location L Immeersion in UbiQQuest Using U the device’s availablle localization n services re- sults s in a close innterdigitation of reality an nd simulation, ,
Page 1: 86 JOURNAL OF SOFTWARE, VOL. 2, NO.
Page 5 and 6: 90 JOURNAL OF SOFTWARE, VOL. 2, NO.
Page 7: 92 JOURNAL OF SOFTWARE, VOL. 2, NO.

View - Academy Publisher

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?