Διπλωματική Εργασία του φοιτητή του Τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών της Πολυτεχνικής Σχολής του Πανεπιστημίου Πατρών

Transcript

1 ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΑΤΡΩΝ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΤΕΧΝΟΛΟΓΙΑΣ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ: ΥΠΟΛΟΓΙΣΤΩΝ ΚΑΙ ΗΛΕΚΤΡΟΝΙΚΗΣ ΕΡΓΑΣΤΗΡΙΟ ΔΙΑΔΡΑΣΤΙΚΩΝ ΣΥΣΤΗΜΑΤΩΝ Διπλωματική Εργασία του φοιτητή του Τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών της Πολυτεχνικής Σχολής του Πανεπιστημίου Πατρών Ντούρμα Αναστάσιου-Ιωάννη του Ιωάννη Αριθμός Μητρώου: 8143 Θέμα «Σχεδίαση και ανάπτυξη επεκτάσιμου εξυπηρετητή παιχνιδιών» Επιβλέπων Καθηγητής κ.νικόλαος Αβούρης Αριθμός Διπλωματικής Εργασίας: ΠΑΤΡΑ, ΙΟΥΛΙΟΣ 2017

2 ΠΙΣΤΟΠΟΙΗΣΗ Πιστοποιείται ότι η Διπλωματική Εργασία με θέμα «Σχεδίαση και ανάπτυξη επεκτάσιμου εξυπηρετητή παιχνιδιών» Του φοιτητή του Τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών Ντούρμα Αναστάσιου-Ιωάννη του Ιωάννη Αριθμός Μητρώου: 8143 Παρουσιάστηκε δημόσια και εξετάστηκε στο Τμήμα Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών στις 20/07/2017 Ο Επιβλέπων Ο Διευθυντής του Τομέα Καθηγητής Κ.Νικόλαος Αβούρης Καθηγητής κ.ευθύμιος Χούσος 2

3 Αριθμός Διπλωματικής Εργασίας: Θέμα: «Σχεδίαση και ανάπτυξη επεκτάσιμου εξυπηρετητή παιχνιδιών» Φοιτητής: Ντούρμας Αναστάσιος-Ιωάννης του Ιωάννη Επιβλέπων: κ.νικόλαος Αβούρης Περίληψη Η συγκεκριμένη διπλωματική εργασία αφορά τον σχεδιασμό και ανάπτυξη ενός επεκτάσιμου εξυπηρετητή παιχνιδιών (game server) ο οποίος υποστηρίζει χωρο-ευαίσθητα φορητά παιχνίδια (location-based mobile games). Σε πρώτο στάδιο για να πραγματοποιηθεί η σχεδίαση ενός τέτοιου εξυπηρετητή γίνεται μια διαδικασία μοντελοποίησης. Στην μοντελοποίηση αυτήν λαμβάνονται υπόψη δύο παιχνίδια, το MuseumScrabble και το Taggling. Τα παιχνίδια αυτά παίζονται σε φυσικό χώρο μουσείων μέσω φορητών συσκευών και σε αυτά υπάρχει αλληλεπίδραση των φορητών συσκευών με τα εκθέματα που υπάρχουν στον μουσειακό χώρο. Αρχικά αναλύονται τα χαρακτηριστικά των παιχνιδιών αυτών και στη συνέχεια ορίζεται ένα αφαιρετικό μοντέλο το οποίο μπορεί να τα περιγράψει. Το δεύτερο στάδιο είναι η εφαρμογή αυτού του μοντέλου σε κώδικα για την ανάπτυξη ενός τέτοιου εξυπηρετητή ο οποίος θα έχει την ιδιότητα της επεκτασιμότητας. Με τον όρο επεκτασιμότητα εννοείται ότι ο εξυπηρετητής θα μπορεί να υποστηρίξει στο μέλλον νέα παιχνίδια που έχουν αυτήν τη συμπεριφορά ακόμα και αν οι κανόνες τους είναι διαφορετικοί. Το κρίσιμο τεστ που έγινε στον εξυπηρετητή που αναπτύχθηκε ήταν να γίνει η υποστήριξη ενός νέου παιχνιδιού, του UoP GO. Στο παιχνίδι αυτό έγινε η εφαρμογή της 3

4 μοντελοποίησης και μπόρεσε αποτελεσματικά να υποστηριχτεί από τον εξυπηρετητή. Για την αξιολόγηση του επεκτάσιμου εξυπηρετητή που αναπτύχθηκε στα πλαίσια αυτής της διπλωματικής εργασίας, πραγματοποιήθηκαν κάποια τεστ στα οποία προσομοιώνονταν συνεδρίες των παραπάνω παιχνιδιών με συνεχώς αυξανόμενο αριθμό εικονικών χρηστών. Τα αποτελέσματα ήταν θετικά καθώς ο αριθμός των αιτημάτων που εξυπηρετούνταν σε πραγματικό χρόνο ήταν μεγάλος και μπορούσε χωρίς προβλήματα να εξυπηρετήσει το παιχνίδι της συνεδρίας μέχρι το τέλος του. Λέξεις κλειδιά: ετικέτα, αντικείμενο του φυσικού κόσμου, αντιστοίχιση, αποσύνδεση, αλληλεπίδραση, αναγνώριση αντικειμένου 4

5 Executive summary «Design and development of an extendable game server for location-based multiplayer mobile games» The thesis concerns the design and development of an extendable game server the purpose of which is to support location-based multiplayer mobile games. The work is structured in three main phases: Design, implementation and evaluation. The first stage of the design phase is to create a model which can describe the class of games that the server will support. Two games are used to create this model, MuseumScrabble and Taggling. These games take place at museums or city centres or archeaological parks etc., and the players that participate in them use their mobile devices to interact with the objects in those places. By analyzing the common characteristics of these games, a conseptual framework for describing location-based games is created. Afterwards, in the second phase, this model is used to develop the game server. A major presequite of the game server is to be extendable and be able to support every new game that can be described by this model that was created during the design phase. In the third phase the server s extendability is evaluated, by using a new game, unknown during the game server s design phase, and implement a plug-in module for the game server. The new game UoP GO is a location-based multiplayer mobile game. The game is modeled according to the conceptual framework that was outline in the design phase, and a plug-in module is implemented to support UoP GO game with the game server. For the evaluation of the performance of the game server, a number of stress tests were conducted. During the stress tests, a simulation of game sessions was performed by creating a large number of virtual players who create a similarly large number of requests to the game server with increasing rate. 5

6 Ευχαριστίες Θα ήθελα να ευχαριστήσω θερμά τον καθηγητή κ.νικόλαο Αβούρη, για την ευκαιρία που μου έδωσε να ασχοληθώ με το συγκεκριμένο θέμα. Η αμέριστη βοήθεια αλλά και η στήριξή του, μαζί με τις πολύτιμες συμβουλές του αποτελούν καθοριστικούς παράγοντες που συνέβαλλαν στην ολοκλήρωση της διπλωματικής εργασίας. Ένα μεγάλο ευχαριστώ στον διδάκτορα κ.χρήστο Σιντόρη για την υποστήριξη, τις οδηγίες και τις συμβουλές που μου παρείχε σε όλη τη διάρκεια της διπλωματικής εργασίας. Ακόμη ευχαριστώ έναν προς έναν τους διδακτορικούς φοιτητές Γεώργιο Ράπτη και Χριστίνα Κατσίνη που υπήρξαν πολύτιμοι σύμβουλοι και υποστηρικτές σε κρίσιμες στιγμές. Θα ήθελα να ευχαριστήσω την οικογένειά μου για τη βοήθεια και τη στήριξη που μου παρείχαν σε όλη τη διάρκεια των σπουδών μου και οικονομικά και ψυχολογικά. Ευχαριστώ όλους τους κοντινούς μου φίλους για την έμπρακτη και ψυχολογική βοήθεια που μου προσέφεραν καθ όλη τη διάρκεια της εκπόνησης της διπλωματικής μου εργασίας, καθώς και για την αντικειμενική τους αξιολόγηση στην εφαρμογή. Τέλος, θα ήθελα να ευχαριστήσω τα υπόλοιπα μέλη της Ερευνητικής Ομάδας Αλληλεπίδρασης Ανθρώπου Υπολογιστή για τις ώρες που περάσαμε μαζί κι όλους τους υπόλοιπους συμμετέχοντες στην διαδικασία της αξιολόγησης για τις εποικοδομητικές τους παρατηρήσεις. 6

7 ΠΕΡΙΕΧΟΜΕΝΑ Ευχαριστίες... 6 Πίνακας Εικόνων Εισαγωγή Στόχος της διπλωματικής εργασίας Διάρθρωση της διπλωματικής εργασίας Θεωρητικό και τεχνολογικό υπόβαθρο Χωρο-ευαίσθητα παιχνίδια Αρχιτεκτονική εξυπηρετητή Επισκόπιση επιστημονικού πεδίου Τεχνολογία Pomelo Τεχνολογία google cloud platform Τεχνολογίες που χρησιμοποιήθηκαν Τεχνολογία ανάπτυξης κώδικα του εξυπηρετητή Τεχνολογία ανάπτυξης βάσης δεδομένων εξυπηρετητή Δομή ανάπτυξης του εξυπηρετητή Λογισμικό ασφάλειας του εξυπηρετητή Μοντελοποίηση Βασικό Λεξικό Περιγραφή παιχνιδιών MuseumScrabble Taggling Ορισμός βασικών οντοτήτων Ορισμός δυνατών καταστάσεων παίκτη Είδη σχέσεων αντικειμένων φυσικού κόσμου- ετικετών Ορισμός βασικών χώρων αποθήκευσης ετικετών Ορισμός του πεδίου ορατότητας Εφαρμογή της μοντελοποίησης MuseumScrabble Taggling Υλοποίηση για υποστήριξη νέων παιχνιδιών

8 4 Υλοποίηση Δημιουργία περιβάλλοντος εξυπηρετητή Διαχείριση χρηστών Διαχείριση συνεδριών Σχεδιασμός και ανάπτυξη της βάσης δεδομένων του εξυπηρετητή Σχήμα βάσης δεδομένων Βασικές οντότητες της βάσης δεδομένων Συσχετίσεις του σχήματος της βάσης δεδομένων Επικοινωνία εξυπηρετητή με συσκευές Προκαθορισμένες λειτουργίες εξυπηρετητή Αρχικοποίηση και τέλος του παιχνιδιού Προκαθορισμένες διαδρομές εξυπηρετητή Υποστήριξη του MuseumScrabble Υποστήριξη του Taggling Αξιολόγηση Πρώτη αξιολόγηση Αξιολόγηση επεκτασιμότητας Σύντομη περιγραφή του UoP GO Εφαρμογή της μοντελοποίηση στο UoP GO Υλοποίηση του UoP GO Δεύτερη αξιολόγηση - Δοκιμές φορτίου κίνησης Εργαλείο δεύτερης αξιολόγησης artillery.io Εφαρμογή artillery.io στον επεκτάσιμο εξυπηρετητή Πρώτη δοκιμή-συνεδρία MuseumScrabble Δεύτερη δοκιμή-συνεδρία Taggling Τρίτη δοκιμή-συνεδρία UoP GO Σύνοψη αποτελεσμάτων δεύτερης αξιολόγησης Συμπεράσματα αξιολογήσεων Συμπεράσματα και μελλοντικιές κατευθύνσεις Ανασκόπηση πορείας Συμπεράσματα Μελλοντικές κατευθύνσεις

9 6.4 Επίλογος Αναφορές Παράρτημα Α: Οδηγίες εγκατάστασης εξυπηρετητή Παράρτημα Β: Οδηγίες εισαγωγής νέου παιχνιδιού Παράρτημα Γ: Οδηγίες σύνδεσης παιχνιδιού με εξυπηρετητή Ευρετήριο

10 Πίνακας Εικόνων Εικόνα 1: Γενική εικόνα για την 3-tier αρχιτεκτονική Εικόνα 2: Αρχιτεκτονική επεκτάσιμου εξυπηρετητή της συγκεριμένης διπλωματική εργασίας Εικόνα 3: Αρχιτεκτονική του google cloud platform Εικόνα 4: Εγγραφή και είσοδος χρήστη μέσω Passportjs Εικόνα 5: Είσοδος και επιλογή συνεδρίας στο παιχνίδι Εικόνα 6: Κατηγορίες των ετικετών μέσω της διεπαφής Εικόνα 7: Αντιστοίχιση/αποσύνδεση ετικετών μέσω διεπαφής Εικόνα 8: Χάρτης των τοποθεσιών των εκθεμάτων μέσω της διεπαφής Εικόνα 9: QRcodes των εκθεμάτων Εικόνα 10: Οδηγίες προς τους παίκτες Εικόνα 11: Κατάσταση εκθεμάτων μέσω της διεπαφής Εικόνα 12: Σκανάρισμα QRcode ενός εκθέματος Εικόνα 13: Ετικέτες στην τσάντα του χρήστη Εικόνα 14: Ετικέτες αντιστοιχισμένες σε κάποιο έκθεμα Εικόνα 15: Αντικείμενο του φυσικού κόσμου Εικόνα 16: Ετικέτα Εικόνα 17: Σχέσεις Εικόνα 18: Σχέσεις 1-Ν Εικόνα 19: Σχέσεις Ν Εικόνα 20: Παίκτης με το δικό του Σακούλι Εικόνα 21: Καλάθι ενός αντικειμένου του φυσικού κόσμου Εικόνα 22: Κουβάς ως κοινόχρηστος χώρος για απόκτηση ετικετών Εικόνα 23: Αναγνώριση αντικειμένου μέσω φορητής συσκευής Εικόνα 24: MuseumScrabbleΑλληλεπιδραστικό Εικόνα 25: MuseumScrabbleΑτομικό Εικόνα 26: Taggling Αλληλεπιδραστικό Εικόνα 27: Taggling Ατομικό Εικόνα 28: Περιβάλλον που δημιουργεί το Expressjs Εικόνα 29: Διάγραμμα καταστάσεων χρήστη Εικόνα 30: Διάγραμμα καταστάσεων μιας συνεδρίας Εικόνα 31: Σχήμα βάσης δεδομένων εξυπηρετητή Εικόνα 32: Εγγραφή χρήστη στο UoPGO Εικόνα 33: Διεπαφή χρήστη στο UoPGO Εικόνα 34: Εμπειρία χρήστη κατά την διάρκεια της συνεδρίας Εικόνα 35: Παράδειγμα κώδικα σε artillery.io Εικόνα 36: Κώδικας για την 1η δοκιμή στη συνεδρία MuseumScrabble

11 Εικόνα 37: Κώδικας τμήματος 'scenarios' της 1ης δοκιμής Εικόνα 38: Αποτελέσματα 1ης δοκιμής Εικόνα 39: Κώδικας 'config' 2ης δοκιμής Εικόνα 40: Κώδικας 'scenarios' της 2ης δοκιμής Εικόνα 41: Αποτέσματα 2ης δοκιμής Εικόνα 42: Κώδικας 'config' της 3ης δοκιμής Εικόνα 43: Κώδικας 'scenarios' 3ης δοκιμής Εικόνα 44: Αποτελέσματα 3ης δοκιμής Εικόνα 45: Διακύμανση χρόνου απόκρισης σε αιτήματα Εικόνα 46: Διακύμανση χρόνου απόκρισης σε σενάρια κάθε παιχνιδιού Εικόνα 47: Αριθμός αιτημάτων ανά δευτερόλεπτο σε κάθε δοκιμή Εικόνα 48: Αρχική της ιστοσελίδας του Nodejs Εικόνα 49: Γραμμή εντολών για εκκίνηση εξυπηρετητή

12 1 Εισαγωγή 1.1 Στόχος της διπλωματικής εργασίας Ο στόχος της συγκεκριμένης διπλωματικής εργασίας είναι η σχεδίαση και ανάπτυξη ενός επεκτάσιμου εξυπηρετητή παιχνιδιών. Ο εξυπηρετητής αυτός θα μπορεί να υποστηρίζει εκπαιδευτικά χώρο-ευαίσθητα παιχνίδια τα οποία παίζονται μέσω φορητών συσκευών σε μουσεία και γενικότερα σε κάποιον φυσικό χώρο. Το γεγονός ότι ο εξυπηρετητής πρέπει να είναι επεκτάσιμος, σημαίνει ότι πρέπει να μπορεί να υποστηρίξει όλα τα παιχνίδια τα οποία ανήκουν σε αυτό το είδος παιχνιδιών που υπάρχουν ήδη, καθώς και νέα που θα δημιουργηθούν στο μέλλον. Επομένως για να δημιουργηθεί αυτός ο επεκτάσιμος εξυπηρετητής πρέπει πρώτα να γίνει μια σωστή και ολοκληρωμένη σχεδίαση στην οποία θα πρέπει να ληφθούν υπόψιν όλες οι βασικές παράμετροι των παιχνιδιών. Στη συνέχεια έχοντας μια καλή σχεδίαση μπορεί να γίνει η υλοποίησή του σε κώδικα και να αρχίσει η υποστήριξη νέων παιχνιδιών. 1.2 Διάρθρωση της διπλωματικής εργασίας Η δομή που ακολουθείται στην συγκεκριμένη διπλωματική εργασία παρουσιάζεται παρακάτω πραγματοποιώντας μία περιγραφή του περιεχομένου κάθε κεφαλαίου που ακολουθεί. Στο κεφάλαιο 2 θα γίνει αναφορά στο θεωρητικό και επιστημονικό υπόβαθρο που είναι απαραίτητο για την ανάπτυξη του επεκτάσιμου εξυπηρετητή. Αρχικά γίνεται αναφορά στην θεωρία των χωρο-ευαίσθητων παιχνιδιών ώστε να γίνει κατανοητή η βασική θεωρία τους. Έπειτα θα γίνει λεπτομερής επεξήγηση της αρχιτεκτονικής που θα έχει ο επεκτάσιμος εξυπηρετητής, εξηγώντας την από όλες τις πλευρές της. Στη συνέχεια γίνεται μία επισκόπιση του επιστημονικού πεδίου, όσον αφορά τις τεχνολογίες που υπάρχουν για την ανάπτυξη εξυπηρετητών παιχνιδιών με αναφορά στα 12

13 πλεονεκτήματά τους και στους λόγους που δεν χρησιμοποιήθηκαν. Τέλος γίνεται λεπτομερή αναφορά στις τεχνολογίες που χρησιμοποιήθηκαν για την ανάπτυξη του επεκτάσιμου εξυπηρετητή της συγκεκριμένης διπλωματικής εργασίας, που αφορούν την τεχνολογία ανάπτυξης κώδικα, την τεχνολογία ανάπτυξης της βάσης δεδομένων του και το λογισμικό για την ασφάλειά του. Στο κεφάλαιο 3 υπάρχει το κομμάτι της σχεδίασης του επεκτάσιμου εξυπηρετητή. Σε αυτό θα γίνει αρχικά η επεξήγηση των παιχνιδιών MuseumScrabble και Taggling, με βάση τα οποία στη συνέχεια θα γίνει η μοντελοποίηση των χωρο-ευαίσθητων παιχνιδιών. Η μοντελοποίηση αυτή περιλαμβάνει τον ορισμό ενός βασικού λεξικού της, τον ορισμό βασικών οντοτήτων και σχέσεων μεταξύ τους, καθώς και βασικών εργαλείων που βοηθούν στην μοντελοποίηση καθενός παιχνιδιού ξεχωριστά. Αφού λοιπόν γίνει η μοντελοποίηση αυτή στο τέλος του κεφαλαίο, εφαρμόζεται στα δύο αυτά παιχνίδια για την απόδειξη της ορθότητάς της. Στο κεφάλαιο 4 παρουσιάζεται το κομμάτι της ανάπτυξης του επεκτάσιμου εξυπηρετητή σε κώδικα βάση της μοντελοποίησης του κεφαλαίου 3. Αρχικά γίνεται ο ορισμός του περιβάλλοντός του, ορίζεται η πολιτική διαχείρισης χρηστών και συνεδριών που διαθέτει και εξηγείται αναλυτικά η βάση δεδομένων του. Έπειτα γίνεται επεξήγηση των επεκτάσιμων κομματιών κώδικα που διαθέτει, εξηγώντας όλες τις προκαθορισμένες λειτουργίες και διαδρομές (routes) που χρησιμοποιεί αλλά και το πώς μπορεί να υιοθετήσει νέες. Στο τέλος του κεφαλαίου γίνεται η χρήση του λογισμικού αυτού που αναπτύχθηκε, για την υποστήριξη του MuseumScrabble και του Taggling για την επιβεβαίωση ότι όντως λειτουργεί αποτελεσματικά και μπορεί να υποστηρίξει παιχνίδια αυτού του είδους. Στο κεφάλαιο 5 υπάρχει το κομμάτι της αξιολόγησης του επεκτάσιμου εξυπηρετητή. Σε αυτό θα γίνει η αξιολόγηση δύο βασικών χαρακτηριστικών του. Το πρώτο αφορά το κομμάτι της επεκτασιμότητάς του και αξιολογείται με την είσοδο ενός νέου παιχνιδιού σε αυτόν, του UoP GO και εξετάζεται αν μπορεί βάση της μοντελοποίησης του κεφαλαίου 3 να υποστηριχτεί από τον 13

14 επεκτάσιμο εξυπηρετητή. Το δεύτερο χαρακτηριστικό που αξιολογείται είναι το φορτίο κίνησης που μπορεί να υποστηρίξει ο επεκτάσιμος εξυπηρετητής. Σε αυτό το κομμάτι πραγματοποιούνται δοκιμές φόρτου (stress tests) στον εξυπηρετητή και με βάση τα αποτελέσματά τους εξάγονται βασικές παράμετροί του που αφορούν τους χρόνους απόκρισής του. Τέλος στο κεφάλαιο 6 γίνεται μια ανασκόπηση της όλης πορείας που έγινε στην συγκεκριμένη διπλωματική εργασία και γίνεται αναφορά σε μελλοντικιές κατευθύνσεις που μπορεί να έχει ο επεκτάσιμος εξυπηρετητής. Ο εξυπηρετητής έχει κάποια σημεία τα οποία μπορούν στο μέλλον να αποτελέσουν αντικείμενο μελέτης, ανάπτυξης και βελτίωσης. Σε αυτό το κεφάλαιο αναφέρονται τα σημεία αυτά και προτείνονται κάποιοι τρόποι με τους οποίους μπορεί να γίνει η εξέλιξή του στο μέλλον. 14

15 15

16 2 Θεωρητικό και τεχνολογικό υπόβαθρο Στο κεφάλαιο αυτό θα γίνει ορισμός των χωρο-ευαίσθητων παιχνιδιών, θα γίνει επισκόπιση του επιστημονικού πεδίου τεχνολογιών ανάπτυξης εξυπηρετητών παιχνιδιών, θα γίνει αναφορά στις τεχνολογίες που χρησιμοποιήθηκαν στην συγκεκριμένη διπλωματική εργασία, καθώς και στην αρχιτεκτονική του εξυπηρετητή. 2.1 Χωρο-ευαίσθητα παιχνίδια Τα χαρακτηριστικά του χώρου στον οποίο παίζεται ένα παχνίδι αποτελούν κομμάτι της δυναμικής του. Τα χωρο-ευαίσθητα παιχνίδια ενσωματώνουν τον περίγυρο ο οποίος γίνεται μέρος του πλαισίου ανάλυσης (Magerkurth, Cheok, Mandryk, & Nilsen, 2005). Τα χαρακτηριστικά του περιγύρου, όπως οι διαστάσεις του φυσικού χώρου, οι θέσεις των αντικειμένων και οι θέσεις των παικτών οδηγούν στην δημιουργία συσχετίσεων μεταξύ παικτών και αντικειμένων. Σε ένα χωρο-ευαίσθητο παιχνίδι οι παίκτες κινούνται στον φυσικό χώρο και αλληλεπιδρούν με τα αντικείμενα που βρίσκονται σε αυτόν. Ο τρόπος με τον οποίον πραγματοποιείται η αλληλεπίδραση αυτή είναι μέσω της φορητής τους συσκευής. Στην ουσία η φορητή συσκευή αποτελεί την σύνδεση του πραγματικού χώρου με τον ψηφιακό. Με αυτήν μπορούν και αποκτούν πρόσβαση στην ψηφιακή πληροφορία που βρίσκεται στον φυσικό χώρο (Σιντόρης, 2014). Η πληροφορία έχει σχέση με τη θέση και την κατάσταση του παίκτη, καθώς και με τη θέση του αντικειμένου του φυσικού κόσμου. Τα χωρο-ευαίσθητα παιχνίδια παίρνουν μέρος σε χώρους ανοικτούς, στον οποίο μπορούν να βρίσκονται και θεατές, έτσι ώστε να προωθείται και η επικοινωνία με τον περίγυρο. Σαν ορολογία το γεγονός αυτό θα μπορούσε να 16

17 χαρακτηριστεί ως χωρική επέκταση και τα παιχνίδια που το υιοθετούν χωρίζονται σε τρεις κατηγορίες. 1. location-free: στα παιχνίδια της κατηγορίας αυτής η εξέλιξη του παιχνιδιού απαιτεί κάθε παίκτης να κινείται στον φυσικό χώρο διανύοντας αποστάσεις μικρές ή μεγάλες. Οι πράξεις του όμως πάνω στο παιχνίδι δεν έχουν κάποιον περιορισμό ως προς την τοποθεσία του. Οποιαδήποτε ενέργεια που πραγματοποιεί δεν είναι απαραίτητο να είναι στην τοποθεσία που παίζεται η συνεδρία του παιχνιδιού, αλλά οπουδήποτε χρησιμοποιήσει την εφαρμογή μέσω της φορητής του συσκευής. 2. site-adaptive: το περιεχόμενο των παιχνιδιών αυτών έχει άμεση σχέση με τον χώρο στον οποίο παίζονται αλλά και με την ιστορία του. Τα παιχνίδια αυτά μπορούν να αλλάξουν την τοποθεσία στην οποία παίζονται αν το νέο μέρος παρουσιάζει συσχέτιση και παρόμοια δομή με τις ρυθμίσεις τους. Στην ουσία τα παιχνίδια αυτά έχουν την ιδιότητα να μπορούν να προσαρμοστούν σε κάποιον νέο χώρο. 3. site-specific: τα παιχνίδια αυτά χρησιμοποιούν τις ιστορικές, αρχιτεκτονικές και αισθητικές λεπτομέρειες του χώρου στον οποίο έχουν σχεδιαστεί για να παίζονται. Τα παιχνίδια αυτά είναι ρητά συνδεδεμένα με τον χώρο στον οποίο παίζονται και η μεταφορά τους σε κάποιον νέο χώρο είναι δύσκολη ως προς τη προσαρμογή. (Montola, Stenros, & Waern, 2009) 2.2 Αρχιτεκτονική εξυπηρετητή Πριν γίνει οτιδήποτε, πρέπει να πραγματοποιηθεί η ανάλυση της αρχιτεκτονικής του εξυπηρετητή που θα αναπτυχθεί. Θα γίνει επεξήγηση του μοντέλου αρχιτεκτονικής που ακολουθεί ως προς τη δομή του και ως προς τις υπηρεσίες που εξυπηρετεί. Η αρχιτεκτονική που θα έχει ο επεκτάσιμος εξυπηρετητής είναι τύπου REST (REpresentatonStateTransfer) (Guinard, Trifa, & Wilde, 2010). Η 17

18 συγκεκριμένη δομή χρησιμοποιείται όταν η επικοινωνία μεταξύ πελάτη και εξυπηρετητή (client-server) είναι stateless μεταξύ των αιτημάτων. Με τον όρο stateless εννοείται ότι ο εξυπηρετητής δεν κρατάει κάποια κατάσταση για τον χρήστη ώστε να τον θυμάται (Pautasso, 2009). Αυτό σημαίνει ότι κάθε αίτημα που στέλνεται πρέπει να έχει όλη την απαραίτητη πληροφορία που χρειάζεται καθώς δεν γίνεται εγκαθίδρυση συνεδρίας μεταξύ τους. Ο πελάτης (client) δεν είναι σε συνεχή σύνδεση με τον εξυπηρετητή που σημαίνει ότι όποτε θέλει μπορεί ασύγχρονα να στέλνει αιτήματα και ασύγχρονα ο εξυπηρετητής να απαντάει. Για να μπορεί ο εξυπηρετητής να αναγνωρίζει τους χρήστες χρησιμοποιεί την βάση δεδομένων του και με βάση κάποια ταυτότητα μπορεί και κάνει πιστοποίηση για τον αποστολέα. Τα αιτήματα στέλνονται με μεθόδους HTTP, δηλαδή GET, POST, PUT και DELETE πάνω από το πρωτοκόλλο HTTP. Ο εξυπηρετητής σε μια REST αρχιτεκτονική δέχεται αιτήματα σε διαδρομές (URI) μέσω των οποίων εκτελεί λειτουργίες τις οποίες είναι προγραμματισμένος να κάνει. Το μεγάλο πλεονέκτημα της συγκεκριμένης αρχιτεκτονικής είναι ότι επειδή στη μεριά του εξυπηρετητή δεν κρατείται κάποια κατάσταση για τον χρήστη, μπορεί να υποστηριχτεί μεγαλύτερος αριθμός χρηστών. ( A multi-tier architecture for building RESTful Web services, 2009) Οι λόγοι για τους οποίους χρησιμοποιήθηκε η συγκεκριμένη αρχιτεκτονική έχουν σχέση με το είδος των παιχνιδιών που θέλει να υποστηρίζει ο εξυπηρετητής. Όπως αναλύθηκε στο υποκεφάλαιο 2.1 τα παιχνίδια τα οποία θέλει να υποστηρίζει απαιτούν την κίνηση των παικτών στον χώρο. Επομένως ένας παίκτης θα διανύει αποστάσεις, μικρές ή μεγάλες, μέχρι να στείλει κάποιο αίτημα στον εξυπηρετητή. Αν ο εξυπηρετητής κρατούσε κάποια σύνδεση με αυτόν τον χρήστη απλώς θα φορτωνόταν με δεδομένα χωρίς να υπάρχει συνεχής επικοινωνία. Επίσης μέχρι να φτάσει ο παίκτης στο σημείο του ενδιαφέροντός του μπορεί να έχει κλειστή την εφαρμογή, για παράδειγμα για εξοικονόμιση μπαταρίας της φορητής του συσκευής, ή μπορεί να έχει αποσυνδεθεί από το δίκτυο. Για να αποφεύγονται λοιπόν όλες οι διαδικασίες με τις οποίες επαναφέρεται η σύνδεση μεταξύ εξυπηρετητή-πελάτη, η ιδιότητα 18

19 της ασύγχρονης επικοινωνίας είναι η λύση. Για αυτό τον λόγο η αρχιτεκτονική REST είναι ικανοποιητική για την ανάπτυξη του εξυπηρετητή. Όσον αφορά την αρχιτεκτονική μεταξύ πελάτη-εξυπηρετητή χρησιμοποιείται η 3-tier client-server architecture. Η αρχιτεκτονική αυτή έχει τρία βασικά μέρη. Το πρώτο είναι ο υπολογιστής του πελάτη (Presentation tier), που στη συγκεκριμένη διπλωματική εργασία είναι η φορητή συσκευή του παίκτη, το δεύτερο είναι ο εξυπηρετητής της εφαρμογής (Logic tier) και το τρίτο η βάση δεδομένων (Data tier) (Kambalyal, 2010). Η εφαρμογή που τρέχει στην συσκευή του χρήστη ότι δεδομένο χρειάζεται ανάλογα με τις ανάγκες της το αντλεί από τη βάση δεδομένων. Ο εξυπηρετητής είναι ένας και αναλαμβάνει την αποστολή των δεδομένων μέσω των απαντήσεων των αιτημάτων που του έρχονται. Μία πολύ γενική εικόνα μιας τέτοιας αρχιτεκτονικής φαίνεται παρακάτω στην Εικόνα 1. Εικόνα 1: Γενική εικόνα για την 3-tier αρχιτεκτονική Η αρχιτεκτονική 3-tier client-server architecture είναι αυτή που επιλέχθηκε για τον επεκτάσιμο εξυπηρετητή της συγκεκριμένης διπλωματικής εργασίας. Όπως αναλύεται στο υποκεφάλαιο 2.4, η βασική τεχνολογία με την οποία αναπτύχθηκε ο εξυπηρετητής είναι το Nodejs, στο οποίο η διαχείριση των δεδομένων και των πακέτων γίνεται μέσω του npm. Η βάση δεδομένων είναι αναπτυγμένη με την τεχνολογία mongodb. Οι εφαρμογές στην φορητή συσκευή του χρήστη μπορεί να είναι οποιαδήποτε τεχνολογία, όπως για 19

20 παράδειγμα Perl, Ruby, Java, Python και άλλες που χρησιμοποιούνται για ανάπτυξη διαδικτυακών εφαρμογών. Τα αιτήματα και οι απαντήσεις είναι σε μορφή JSON. Επομένως η αρχιτεκτονική του συστήματος του επεκτάσιμου εξυπηρετητή φαίνεται παρακάτω στην Εικόνα 2. Εικόνα 2: Αρχιτεκτονική επεκτάσιμου εξυπηρετητή της συγκεριμένης διπλωματική εργασίας 2.3 Επισκόπιση επιστημονικού πεδίου Πριν ξεκινήσει η υλοποίηση του εξυπηρετητή παιχνιδιών της συγκεκριμένης διπλωματικής εργασίας έγινε μία έρευνα για το τι τεχνολογίες υπάρχουν στον επιστημονικό χώρο που σχετίζονται με το θέμα αυτό. Υπάρχουν πάρα πολλά frameworks τα οποία μπορούν να υποστηρίξουν την δημιουργία εξυπηρετητών για παιχνίδια πραγματικού χρόνου. Σε αυτό το σημείο θα γίνει αναφορά σε δύο τεχνολογίες οι οποίες βοηθούν στην κατασκευή εξυπηρετητών για παιχνίδια πάνω σε αυτό το κομμάτι, το pomelo και το google cloud platform Τεχνολογία Pomelo Η πρώτη αξιοσημείωτη τεχνολογία η οποία αποτελεί εργαλείο για ανάπτυξη εξυπηρετητών παιχνιδιών είναι το Pomelo. Το Pomelo είναι ένα γρήγορο, κλιμακούμενο και διανεμημένο framework για δημιουργία εξυπηρετητών για παιχνίδια (Cardin, 2016). Παρέχει αρκετά εργαλεία για ανάπτυξη εφαρμογών πραγματικού χρόνου. Η αρχιτεκτονική που χρησιμοποιεί είναι πολυδιαδικαστική (multi-process) και κατ επέκταση είναι κλιμακούμενη. Παρέχει 20

21 ένα μεγάλο API το οποίο είναι γραμμένο σε Nodejs το οποίο μπορεί να χρησιμοποιηθεί για την δημιουργία νέων modules τα οποία επεκτείνουν την λειτουργικότητά του. Δίνει δηλαδή την δυνατότητα σε προγραμματιστές να αξιοποιήσουν τα εργαλεία που παρέχει για να καλύψουν τις ανάγκες των παιχνιδιών τους. Το pomelo είναι ένα project ανοιχτού κώδικα στο οποίο μπορεί να έχει πρόσβαση ο καθένας και να εκμεταλλευτεί την επεκτασιμότητά του. Το pomelo σαν framework έχει αρκετές δυνατότητες και αρκετά πλεονεκτήματα ως προς την χρήση του. Αρχικά, όπως αναφέρθηκε προηγουμένως η κλιμακούμενη αρχιτεκτονική του είναι ένα μεγάλο πλεονέκτημα καθώς δίνει τη δυνατότητα στον προγραμματιστή να κατασκευάσει την δομή και αρχιτεκτονική της εφαρμογής του χρησιμοποιώντας λιγότερο κώδικα και σε μικρότερο χρόνο. Το API που παρέχει είναι μεγάλο και παρέχει πάρα πολλές δυνατότητες ως προς τη λειτουργικότητά του και δίνει την δυνατότητα για επέκταση των δυνατοτήτων ενός εξυπηρετητή παιχνιδιών ως προς τη διαχείριση αιτημάτων και άλλων παραμέτρων του. Το βασικό στοιχείο στο οποίο εστιάζει είναι στην απόδοση (performance) καθώς η τεχνολογία έχει κατασκευαστεί με τη λογική υποστήριξης μεγάλου αριθμού χρηστών. Είναι αναμφισβήτητο ότι οι δυνατότητες που παρέχει το pomelo είναι μεγάλες αλλά δεν επιλέχτηκε για την ανάπτυξη του εξυπηρετητή παιχνιδιών στα πλαίσια της συγκεκριμενης διπλωματικής. Το πρόβλημα ήταν ότι το API που παρέχει για κάποιον νέο προγραμματιστή που δεν έχει κάποια εμπειρία πάνω σε αυτό είναι αρκετά μεγάλο και περίπλοκο. Για την χρήση του χρειάζεται γνώσεις πάνω σε Nodejs και η υποστήριξη που παρέχει σε κάθε μέθοδο είναι σχετικά ελλειπής και την καθιστά δύσκολη την εξοικείωση ενός νέου προγραμματιστή με αυτό. 21

22 2.3.2 Τεχνολογία google cloud platform Το google cloud platform αποτελεί μία πλατφόρμα η οποία παρέχει μία αρχιτεκτονική για σχεδίαση εξυπηρετητών για παιχνίδια (Bunch κ.ά., 2010). Η αρχιτεκτονική αυτή χρησιμοποιεί το Google App Engine και το Google Compute Engine για υψηλή κλιμάκωση και απόδοση σε εφαρμογές πραγματικού χρόνου. Το πρώτο παρέχει λειτουργίες που αφορούν την διαχείριση συνεδριών και χρηστών και το δεύτερο αποτελεί την μηχανή που προγραμματίζεται για την υποστήριξη κάποιου παιχνίδι. Η πλατφόρμα αυτή παρέχει μία έτοιμη συλλογή εργαλείων για ρύθμιση και προγραμματισμό πολλών παραμέτρων σε έναν εξυπηρετητή παιχνιδιών. Τα βασικά χαρακτηριστικά του google cloud platform είναι πολλά και δίνουν αρκετά πλεονεκτήματα στην ανάπτυξη ενός εξυπηρετητή παιχνιδιών πραγματικού χρόνου. Αρχικά παρέχει πολύ μεγάλη κλιμάκωση ως προς τον αριθμό των χρηστών που μπορεί να υποστηρίξει που φτάνει μέχρι χιλιάδες. Η πλατφόρμα είναι κατασκευασμένη για εφαρμογές μεγάλης κλίμακας που έχουν μεγάλο αριθμό χρηστών. Παρέχει ένα μεγάλο σύνολο εργαλείων για γραφικά για τη δημιουργία αξιόπιστου front-end του εξυπηρετητή. Επίσης παρέχει και δική της βάση δεδομένων για τον προγραμματιστή την οποία μπορεί να επεξεργαστεί ανάλογα με τις ανάγκες του. Μέσω του App engine παρέχει λειτουργίες για διαχείριση προφίλ των χρηστών, για διαχείριση συνεδριών, για κοινωνική δικτύωση και άλλες πολλές που διευκολύνουν κάποιον προγραμματιστή. Μέσω του Compute Engine δίνει την δυνατότητα για δημιουργία του εξυπηρετητή που υποστηρίζει ένα νέο παιχνίδι παρέχοντας δυνατότητες διαχείρισης αιτημάτων και υποστήριξης μεγάλου φορτίου χρηστών. Όσον αφορά την αρχιτεκτονική του google cloud platform φαίνεται παρακάτω στην Εικόνα 3. 22

23 Εικόνα 3: Αρχιτεκτονική του google cloud platform Στην αρχιτεκτονική του google cloud platform φαίνονται αναλυτικά όλες οι δυνατότες που παρέχονται. Φαίνεται όλη η πορεία της επικοινωνίας των φορητών συσκευών με το κομμάτι των εξυπηρετητών, όπως η διαχείριση των αιτημάτων, η δημιουργία συνεδριών, η βάση δεδομένων και άλλες λεπτομέρειες που δίνουν ένα οργανωμένο περιβάλλον ανάπτυξης εξυπηρετητή. Είναι αναμφισβήτητο ότι οι δυνατότητες που παρέχει το google cloud platform είναι πολλές και το περιβάλλον ανάπτυξης που παρέχει είναι ευρύ. Η συγκεκριμένη πλατφόρμα ανάπτυξης δεν επιλέχτηκε όμως για την ανάπτυξη του εξυπηρετητή παιχνιδιών στα πλαίσια της συγκεκριμενης διπλωματικής. Το θέμα ήταν ότι όλες οι δυνατότητες ανάπτυξης πάνω σε ένα τέτοιο περιβάλλον είναι αυτοματοποιημένες. Ο προγραμματιστής έχει όλα τα εργαλεία στη διάθεση του και με βάση τους κανόνες τις πλατφόρμας τα προσαρμόζει στις ανάγκες του και δεν έχει την ίδια οικειότητα με το περιβάλλον ανάπτυξης όπως θα είχε με ένα που έχει χτίσει ο ίδιος. 2.4 Τεχνολογίες που χρησιμοποιήθηκαν Σε σημείο αυτό θα γίνει αναλυτική αναφορά στις τεχνολογίες που χρησιμοποιήθηκαν για την ανάπτυξη του επεκτάσιμου εξυπηρετητή της συγκεκριμένης διπλωματικής εργασίας. 23

24 2.4.1 Τεχνολογία ανάπτυξης κώδικα του εξυπηρετητή Είναι γνωστό ότι υπάρχουν πολλές διαφορετικές τεχνολογίες την εποχή αυτή με τις οποίες μπορεί κάποιος να αναπτύξει το λογισμικό ενός εξυπηρετητή για διαδικτυακές εφαρμογές, όπως για παράδειγμα η java και η php. Για τη ανάπτυξη του λογισμικού του συγκεκριμένου επεκτάσιμου εξυπηρετητή η βασική τεχνολογία που χρησιμοποιήθηκε είναι το Nodejs (Tilkov & Vinoski, 2010). Το Nodejs αποτελεί μία τεχνολογία που ακολουθεί τους κανόνες σύνταξης της javascript και χρησιμοποιείται για την ανάπτυξη του λογισμικού ενός εξυπηρετητή, όπως στην συγκεκριμένη περίπτωση για την εξυπηρέτηση εφαρμογών πραγματικού χρόνου για φορητές συσκευές. Αυτό που πετυχαίνει η συγκεκριμένη τεχνολογία είναι ότι ξεφεύγει από το πολυνηματικό μοντέλο σε τέτοιου είδους εφαρμογές και λειτουργεί ασύγχρονα ως ένα προγραμματιστικό μοντέλο που επηρεάζεται από γεγονότα (Tilkov & Vinoski, 2010). Το Nodejs παρέχει σημαντικό αριθμό πλεονεκτημάτων τα οποία είναι πολύ σημαντικά για την σχεδίαση ενός επεκτάσιμου εξυπηρετητή που χρειάζεται αξιόπιστο back-end. Τα πλεονεκτήματα είναι παρουσιάζονται παρακάτω (Chaniotis, Kyriakou, & Tselikas, 2015). Παρέχει πολύ υψηλό συγχρονισμό μεταξύ εξυπηρετητή και πελάτη (client). Παρέχει δυνατότητα μεταφοράς μεγάλου όγκου δεδομένων μέσω του npm, το οποίο καθιστά την τεχνολογία αυτή κατάλληλη για διαδικτυακές εφαρμογές που έχουν ανάγκη την μεγάλη ροή δεδομένων. Χρησιμοποιεί javascript που είναι εύκολη στην εκμάθηση. Το γεγονός ότι λειτουργεί ασύγχρονα κάνει την διαχείριση των αιτημάτων πιο εύκολη και ευέλικτη. 24

25 Το Nodejs καθώς και άλλες γνωστές τεχνολογίες ανάπτυξης λογισμικού για έναν εξυπηρετητή (Python-Web και php) ήρθαν αντιμέτωπα σε πολλά τεστ που διεξάχθηκαν με κριτήριο την απόδοσή τους στην ανταπόκριση σε αιτήματα εισόδου και εξόδου. Το αποτέλεσμα ήταν ότι το Nodejs παρουσίασε πολύ καλύτερη απόδοση σε σύγκριση με τις άλλες τεχνολογίες, καθώς ο αριθμός αιτημάτων που εξυπηρετούσε σε συγκεκριμένο χρόνο ήταν πολύ μεγαλύτερος σε σχέση με τις υπόλοιπες τεχνολογίες (Lei, Ma, & Tan, 2014). Αυτό συμβαίνει καθώς διαθέτει μεγάλες ταχύτητες εξυπηρέτησης λειτουργιών Ι/Ο ακόμα και αν η κίνηση από το δίκτυο είναι μεγάλη. Το Nodejs έχει και κάποια αξιοσημείωτα ελλαττώματα τα οποία παρουσιάζονται παρακάτω (Chaniotis κ.ά., 2015): Είναι δύσκολη και περίπλοκη η διαχείριση μιας σχεσιακής βάσης δεδομένων. Είναι δύσκολη η δημιουργία ενός διαδραστικού front-end, καθώς είναι δύσκολη η δυναμική διαχείριση του περιεχομένου των HTML αρχείων από την μεριά του εξυπηρετητή. Επομένως αυτό που γίνεται κατανοητό είναι ότι το Nodejs παρέχει πολύ αποδοτικό back-end σε κάποιον εξυπηρετητή και όχι τόσο αποδοτικό front-end (Chaniotis κ.ά., 2015). Στην περίπτωση του επεκτάσιμου εξυπηρετητή της συγκεκριμένης διπλωματικής εργασίας όπου χρειάζεται το back-end σε μεγαλύτερο βαθμό, το Nodejs είναι κατάλληλο και είναι αυτό που θα χρησιμοποιηθεί Τεχνολογία ανάπτυξης βάσης δεδομένων εξυπηρετητή Όσον αφορά την τεχνολογία που χρησιμοποιήθηκε για την ανάπτυξη της βάσης δεδομένων του εξυπηρετητή, είναι η mongodb. Παρακάτω παρατίθενται βασικά χαρακτηριστικά της συγκεκριμένης τεχνολογίας καθώς τα πλεονεκτήματά της και οι λόγοι επιλογής της. 25

26 Αρχικά θα γίνει η παρουσίαση κάποιων βασικών χαρακτηριστικών της mongodb ως τεχνολογία ανάπτυξης βάσεων δεδομένων. Ένα βασικό χαρακτηριστικό είναι ότι ανήκει στις μη σχεσιακές τεχνολογίες καθώς είναι προσανατολισμένη σε έγγραφα (document-oriented) τεχνολογία. Για τη δημιουργία και διαχείριση των σχημάτων της η βασική μορφοποίηση (format) των δεδομένων είναι η JSON. Η ευρετηρίαση που παρέχει είναι πολύ δυνατή καθώς μέσα σε έγγραφα μπορούν να υπάρχουν και δευτερεύοντα εμφωλευμένα έγγραφα, μειώνοντας έτσι τον αριθμό των πινάκων του σχήματος της βάσης. Η λογική με την οποία αποθηκεύει δεδομένα βασίζεται σε αντίγραφα (replicats), δηλαδή τα δεδομένα υπάρχουν σε πολλά αντίγραφα όπου ένα είναι το βασικό και τα άλλα λειτουργούν ως back-up. Με αυτήν την δυνατότητα, αν αποτύχει κάποιο γράψιμο ή διάβασμα από την βάση υπάρχουν back-up αρχεία ώστε να μην χαθεί η πληροφορία (Banker, 2011). Η mongodb επίσης παρέχει εξισορρόπηση του φορτίου (load-balancing), καθώς μία τέτοιου είδους βάση δεδομένων μπορεί να τρέχει σε πολλούς εξυπηρετητές ταυτόχρονα και έτσι μπορεί να μειώνεται το φορτίο του καθενός όσον αφορά τα αιτήματα προς εξυπηρέτηση. Έτσι οδηγεί σε καλύτερο χρόνο απόκρισης και μεγαλύτερη απόδοση του εξυπηρετητή. Η μέθοδος αυτή αναφέρεται στην βιβλιογραφία ως sharding. Ένα άλλο βασικό χαρακτηριστικό είναι ότι χρησιμοποιεί το προγραμματιστικό μοντέλο MapReduce. Σύμφωνα με το μοντέλο αυτό, η δημιουργία, προώθηση και επεξεργασία δεδομένων από την βάση γίνεται παράλληλα σαν ένα είδος pipeline εκτελώντας πολύπλοκα queries (Berlińska & Drozdowski, 2011). Έτσι είναι δυνατή η εξοικονόμηση χρόνου απόκρισης της βάσης όταν φτάνει μεγάλος αριθμός αιτημάτων στον εξυπηρετητή. Η mongodb λόγω της ευελιξίας της ως τεχνολογία παρέχει πολλά πλεονεκτήματα. Το πρώτο και βασικό είναι ότι ο τρόπος με τον οποίο δημιουργείται μία τέτοια βάση απαιτεί μικρότερο και λιγότερο πολύπλοκο σχήμα σε σχέση με τις σχεσιακές βάσεις δεδομένων (Wang, Chen, & Wang, 2013). Για την επιλογή στοιχείων από τους πίνακες της βάσης σε επίπεδο εντολών οι συνενώσεις (joins) είναι πιο απλές (Han, E, Le, & Du, 2011), 26

27 απαλλάσσοντας τον προγραμματιστή από πολύπλοκο και χρονοβόρο κώδικα. Παρέχει ευέλικτο μοντέλο δεδομένων ως μη-σχεσιακή τεχνολογία, καθώς μέσα στα έγγραφα μπορεί να υπάρχει συνδυασμός πολλών τύπων δεδομένων αλλά και πινάκων (arrays) δεδομένων. Παρέχει πολύ υψηλή απόδοση σε γενικές γραμμές λαμβάνοντας υπόψη και τον πολύ μικρή καθυστέρηση που έχει μετρηθεί στην απόκρισή της. Ένα πολύ βασικό πλεονέκτημά της είναι η παροχή δυναμικού σχήματος (Banker, 2011). Μία βάση δεδομένων που έχει δυναμικό σχήμα δίνει την δυνατότητα στον προγραμματιστή να μπορέσει στο μέλλον να αλλάξει την δομή της βάσης οποιαδήποτε στιγμή θελήσει. Έτσι αν προκύψουν νέα προβλήματα ή ανάγκες στο μέλλον ο χρήστης μπορεί, χωρίς να ξαναπιάσει την βάση δεδομένων από την αρχή, να επέμβει και να τροποποιήσει κατάλληλα το σχήμα της. Από όλες τις παραπάνω δυνατότητες που διαθέτει η mongodb, ο καθένας καταλαβαίνει ότι η τεχνολογία αυτή είναι κατάλληλη για την ανάπτυξη ενός επεκτάσιμου εξυπηρετητή για εφαρμογές πραγματικού χρόνου. Έτσι, η συγκεκριμένη τεχνολογία επιλέχτηκε για την υλοποίησή της βάσης δεδομένων του Δομή ανάπτυξης του εξυπηρετητή Πάνω στην τεχνολογία του Nodejs έχουν κατασκευαστεί πολλές δομές (frameworks) τις οποίες μπορεί κάποιος προγραμματιστής να χρησιμοποιήσει για σχεδιασμό νέων εφαρμογών. Για την υλοποίηση του συγκεκριμένου επεκτάσιμου εξυπηρετητή χρησιμοποιήθηκε το Expressjs. Το Expressjs αποτελεί μία δομή (framework) η οποία κατασκευάστηκε πάνω στο Νodejs. Το συγκεκριμένο framework χρησιμοποιείται για την ανάπτυξη διαδικτυακών εξυπηρετητών πιο γρήγορα και με δομημένο τρόπο. Αποτελεί μία επέκταση του Nodejs και διευκολύνει σε μεγάλο βαθμό την διαχείριση αιτημάτων προς τον εξυπηρετητή με πιο λίγες γραμμές κώδικα (Dayley, 2014). 27

28 Παρακάτω παρουσιάζονται τα κύρια χαρακτηριστικά του Expressjs μέσα από τα οποία καταλαβαίνει κάποιος τις δυνατότητες που έχει το συγκεκριμένο framework για την ανάπτυξη ενός εξυπηρετητή. Το Expressjs λοιπόν παρέχει: Εύκολη διαχείριση διαδρομών (route management): μέσω του Expressjs ένας προγραμματιστής μπορεί εύκολα να διαχειριστεί την δημιουργία και αξιοποίηση κάποιου URL του εξυπηρετητή και να το συνδέσει με κάποια λειτουργία Διαχείριση λαθών (error handling): το Expressjs παρέχει δικό του λογισμικό για την διαχείριση λαθών που μπορεί να συμβούν στον εξυπηρετητή απαλλάσσοντας τον προγραμματιστή από αυτό το βάρος Εύκολη ενσωμάτωση: ένας εξυπηρετητής γραμμένος πάνω σε Expressjs μπορεί εύκολα να ενσωματωθεί σε άλλα υπάρχοντα συστήματα παρέχοντας νέες λειτουργίες σε αυτά Διαχείριση συνεδριών (session management): το Expressjs παρέχει εύκολη και αποτελεσματική δημιουργία και διαχείριση συνεδριών από χρήστες (Dayley, 2014) Λογισμικό ασφάλειας του εξυπηρετητή Πέρα από το κομμάτι της τεχνολογίας ανάπτυξης του επεκτάσιμου εξυπηρετητή, για το κομμάτι της ασφάλειας δεδομένων του χρησιμοποιήθηκε το Passportjs. Το Passportjs αποτελεί ένα λογισμικό (middleware) που χρησιμοποιείται αποκλειστικά από το Nodejs για θέματα ασφάλειας, πιστοποίησης χρηστών (authentication) και ασφάλεια των συνεδριών. Είναι ένα αρκετά ευέλικτο λογισμικό και προσαρμόζεται πάνω στο Expressjs εύκολα (Pereira, 2016). Το Passportjs δημιουργήθηκε με σκοπό να παρέχει υπηρεσίες ασφαλείας σε εφαρμογές που αναπτύσσονται με Nodejs. Η πιστοποίηση βασίζεται σε tokens, από τον οποίο προκύπτει και ο χαρακτηρισμός του ως token-based middleware (Pereira, 2016). Το χαρακτηριστικό που το κάνει τόσο ευέλικτο σαν λογισμικό είναι ότι δίνει την δυνατότητα στους χρήστες να δημιουργήσουν την δική τους 28

29 στρατηγική για την ασφάλειά τους, μέσω βασικών μηχανισμών που τους παρέχει. Οι στρατηγικές αυτές είναι modules του Nodejsτις οποίες τροποποιεί χειροκίνητα (manually) ο προγραμματιστής, για να υλοποιήσει κάποιον μηχανισμό ασφαλείας. Από την στιγμή που δημιουργηθεί μια στρατηγική μπορεί να χρησιμοποιηθεί για λειτουργίες πιστοποίησης χρηστών. Η λογική της πιστοποίησης των χρηστών είναι αρκετά απλή και φαίνεται πιο παραστατικά στην εικόνα παρακάτω. Αρχικά θεωρούμε ότι ένας χρήστης θέλει να εγγραφεί στο σύστημα, τότε στέλνει το αίτημα με τα στοιχεία του και την πραγματοποιεί. Τον κωδικό του, το Passportjs τον κρυπτογραφεί ανάλογα με το κλειδί που παρέχεται από την στρατηγική και τον αποθηκεύει στην βάση. Έπειτα αν θελήσει να κάνει σύνδεση με το σύστημα (login), πρέπει να στείλει το όνομα του και τον κωδικό του. Το Passportjs με δικές του μεθόδους κάνει την ταύτιση των στοιχείων του χρήστη και αν είναι επιτυχής τότε παράγει ένα token. Το token αυτό το επιστρέφει στον χρήστη και είναι μοναδικό για αυτόν. Από εκεί και πέρα κάθε αίτημα από αυτόν προς τον εξυπηρετητή πρέπει στην κεφαλίδα του να έχει και το token αυτό για να πιστοποιείται ο χρήστης ότι είναι επιτρεπτό το αίτημά του (Pereira, 2016). 29

30 Εικόνα 4: Εγγραφή και είσοδος χρήστη μέσω Passportjs 30

31 31

32 3 Μοντελοποίηση Κάθε εξυπηρετητής δημιουργείται και υπάρχει για να υποστηρίζει μία ή περισσότερες εφαρμογές είτε αυτές είναι πραγματικού χρόνου είτε όχι. Στη συγκεκριμένη περίπτωση οι εφαρμογές αυτές είναι παιχνίδια πραγματικού χρόνου, χώρο-ευαίσθητα και παίζονται στον φυσικό χώρο. Για να δημιουργηθεί ένας επεκτάσιμος εξυπηρετητής πρέπει τα παιχνίδια τα οποία θα εξυπηρετεί να έχουν κάποια κοινή συμπεριφορά μεταξύ τους. Γι αυτό τον λόγο θα πρέπει να γίνει μια μοντελοποίηση της συμπεριφοράς αυτής, ώστε να μπορούν τα παιχνίδια να περιγραφθούν με βάση αυτή. Έτσι θα είναι εφικτή η ανάπτυξη του εξυπηρετητή στη συνέχεια. Για να μπορέσουν να περιγραφούν αποτελεσματικά τα παιχνίδια αυτά θα πρέπει να είναι αφαιρετική και να έχει κάποιους άξονες οι οποίοι θα είναι κοινοί για όλα τα παιχνίδια αυτού του είδους. Πριν όμως παρουσιαστούν αναλυτικά οι εφαρμογές αυτές θα πρέπει να οριστεί ένα αυστηρό λεξικό για αυτές ώστε να μπορούν να γίνουν πιο εύκολα αντιληπτές ως προς τη λογική τους. 3.1 Βασικό Λεξικό Αντικείμενο του φυσικού κόσμου: είναι ένα αντικείμενο το οποίο υπάρχει στον φυσικό χώρο και ο χρήστης μπορεί μέσω της φορητής του συσκευής να αλληλεπιδράσει με αυτό με τον τρόπο που του ορίζει η εφαρμογή Ετικέτα: είναι ένα αντικείμενο της εφαρμογής, δηλαδή που δεν το βλέπει ο χρήστης στον φυσικό χώρο, και χρησιμοποιείται για να αντιστοιχιστεί με κάποιο αντικείμενο του φυσικού κόσμου. Μπορεί να είναι κάποιος χαρακτηρισμός, κάποιο ιστορικό γεγονός ή οτιδήποτε άλλο που μπορεί να χαρακτηρίζει κάποιο αντικείμενο του φυσικού κόσμου Αναγνωρίζω: είναι η πράξη με την οποία ένας παίκτης αποκτά τη δυνατότητα να αλληλεπιδράσει με κάποιο αντικείμενο του φυσικού κόσμου 32

33 Αλληλεπιδρώ: οποιαδήποτε πράξη επιτρέπει η εφαρμογή στον παίκτη να πραγματοποιήσει με κάποιο αντικείμενο. Ορίζονται δύο είδη αλληλεπίδρασης μεταξύ ετικετών και αντικειμένων του φυσικού κόσμου. Αυτή της αντιστοίχισης και αυτή της αποσύνδεσης που παρουσιάζονται παρακάτω. o Αντιστοιχίζω: αποτελεί την πράξη αντιστοίχισης που κάνει κάποιος παίκτης μίας ετικέτας με ένα αντικείμενο του φυσικού κόσμου μέσω της εφαρμογής o Αποσυνδέω: αποτελεί την πράξη αποσύνδεσης κάποιας ετικέτας από ένα αντικείμενο του φυσικού κόσμου που την πραγματοποιεί ο παίκτης μέσω της εφαρμογής Κλειδωμένη: χαρακτηρισμός μίας ετικέτας όταν έχει αντιστοιχιστεί σε κάποιο αντικείμενο του φυσικού κόσμου Ελεύθερη: χαρακτηρισμός μίας ετικέτας όταν δεν έχει αντιστοιχιστεί σε κάποιο αντικείμενο του φυσικού κόσμου 3.2 Περιγραφή παιχνιδιών Τα παιχνίδια που θα υποστηρίζει ο επεκτάσιμος εξυπηρετητής ανήκουν στην κατηγορία των χωρο-ευαίσθητων παιχνιδιών, όπως αναλύθηκαν στο υποκεφάλαιο 2.1. Παρακάτω παρουσιάζεται η περιγραφή δύο χωροευαίσθητων παιχνιδιών, του MuseumScrabble και του Taggling, οι κανόνες τους και άλλες χρήσιμες πληροφορίες για τις συγκεκριμένες εφαρμογές MuseumScrabble Το MuseumScrabble (Sintoris κ.ά., 2012) είναι ένα χώρο-ευαίσθητο παιχνίδι το οποίο παίζεται σε κάποιον μουσειακό χώρο. Για να μπορέσει το παιχνίδι να πραγματοποιήσει μια συνεδρία σε έναν μουσειακό χώρο υπάρχουν κάποιες απαιτήσεις όσον αφορά το στήσιμο του παιχνιδιού. Σε κάθε έκθεμα του χώρου πρέπει να έχουν τοποθετηθεί κωδικοί (QRcodes) για να μπορεί να αλληλεπιδρά με αυτά ο χρήστης μέσω της εφαρμογής (Εικόνα 9). 33

34 Πριν ξεκινήσει μια συνεδρία του παιχνιδιού οι παίκτες πρέπει να κάνουν login στην εφαρμογή και στην συνέχεια να επιλέξουν τη συνεδρία στην οποία θέλουν παίξουν. Αυτό γίνεται μέσω της διεπαφής της εφαρμογής όπως φαίνεται στην Εικόνα 5. Επίσης όπως φαίνεται σε αυτήν ο παίκτης μπορεί να δημιουργήσει και δική του συνεδρία. Εικόνα 5: Είσοδος και επιλογή συνεδρίας στο παιχνίδι Όταν μαζευτούν οι παίκτες που θα συμμετέχουν και όλα είναι έτοιμα τότε ξεκινά η συνεδρία. Το παιχνίδι ξεκινά και οι παίκτες περιφέρονται στον χώρο με τις φορητές τους συσκευές. Στόχος τους είναι να μαζέψουν πόντους κάνοντας αντιστοιχίσεις μεταξύ αντικειμένων του φυσικού κόσμου, που στην συγκεκριμένη περίπτωση είναι τα εκθέματα του μουσείου, και ετικετών της εφαρμογής. Οι ετικέτες του παιχνιδιού είναι χωρισμένες σε εννιά κατηγορίες και για να έχει πρόσβαση ο παίκτης σε κάποια ετικέτα πρέπει να μπει στην κατάλληλη κατηγορία όπως φαίνεται στην Εικόνα 6. 34

35 Εικόνα 6: Κατηγορίες των ετικετών μέσω της διεπαφής Στις ετικέτες αυτές αποκτούν πρόσβαση οι παίκτες μόνο μέσω της εφαρμογής, δηλαδή δεν τις βρίσκουν κάπου καθώς παίζουν αλλά τις έχουν διαθέσιμες από την αρχή της συνεδρίας στην φορητή τους συσκευή. Το μόνο πράγμα που πρέπει να αποκτήσουν πρόσβαση είναι τα αντικείμενα του φυσικού κόσμου, δηλαδή να τα αναγνωρίσουν. Για να μπορέσουν να το πετύχουν αυτό, όταν πλησιάσουν ένα έκθεμα σκανάρουν τον κωδικό που έχει πάνω του. Από την στιγμή που καταφέρουν και αναγνωρίσουν ένα αντικείμενο του φυσικού κόσμου τότε μπορούν να κάνουν κάποια αντιστοίχιση το συγκεκριμένο με κάποια ετικέτα της εφαρμογής. Ανάλογα με τον αν είναι σωστή η αντιστοίχιση ή όχι κερδίζουν ή χάνουν πόντους αντίστοιχα. Η διεπαφή που βλέπει ο παίκτης κατά τη διάρκεια που κάνει κάποια αντιστοίχιση ή αποσύνδεση ετικέτας φαίνεται παρακάτω στην Εικόνα 7. 35

36 Εικόνα 7: Αντιστοίχιση/αποσύνδεση ετικετών μέσω διεπαφής Από την στιγμή που έχει κάνει αντιστοίχιση ένας παίκτης με μία ετικέτα, η ετικέτα θεωρείται κλειδωμένη. Οι κανόνες του παιχνιδιού δεν επιτρέπουν σε κανέναν άλλον παίκτη να χρησιμοποιήσει μία κλειδωμένη ετικέτα, μέχρι να την αποσυνδέσει ο παίκτης που την έκανε αντιστοίχιση. Η αποσύνδεση γίνεται όταν ένας παίκτης πιστεύει ότι έκανε λάθος και αν έχει κάνει τότε χάνει πόντους. Από τη στιγμή αυτή η ετικέτα είναι ελεύθερη, δηλαδή είναι διαθέσιμο ξανά σε όλους τους παίκτες. Για την καλύτερη αίσθηση του χώρου οι παίκτες μπορούν να δουν την τοποθεσία των εκθεμάτων μέσω ενός χάρτη που τους παρέχεται στην εφαρμογή. Μέσω αυτού μπορούν να δουν που βρίσκονται τα εκθέματα που δεν έχουν σκανάρει ακόμα ώστε να μην επιστρέφουν στα ίδια σπαταλώντας χρόνο 36

37 παιχνιδιού. Παρακάτω στην Εικόνα 8 φαίνεται ο χάρτης αυτός μέσω της διεπαφής. Εικόνα 8: Χάρτης των τοποθεσιών των εκθεμάτων μέσω της διεπαφής Νικητής της συγκεκριμένης συνεδρίας του MuseumScrabble είναι αυτός που θα έχει στο τέλος μαζέψει τους περισσότερους πόντους. Η συνεδρία μπορεί να τελειώσει με πολλούς τρόπους. Μπορεί να τελειώσει μετά από ένα χρονικό όριο, όταν όλες οι ετικέτες αντιστοιχιστούν σωστά και με άλλους τρόπους που καθορίζονται από την διεπαφή της εφαρμογής Taggling Το Taggling (Manoli, Sintoris, Yiannoutsou, & Avouris, 2015) είναι ένα χώροευαίσθητο παιχνίδι το οποίο παίζεται σε μουσειακό χώρο. Για να μπορέσει το παιχνίδι να πραγματοποιήσει μια συνεδρία σε έναν μουσειακό χώρο υπάρχουν 37

38 κάποιες απαιτήσεις όσον αφορά το στήσιμο του παιχνιδιού. Σε κάθε έκθεμα του χώρου πρέπει να έχουν τοποθετηθεί κωδικοί (QRcodes) για να μπορεί να αλληλεπιδρά με αυτά ο χρήστης μέσω της εφαρμογής. Εικόνα 9: QRcodes των εκθεμάτων Για να γίνει πιο εύκολα αντιληπτή η διεπαφή του παιχνιδιού προς τους νέους χρήστης που παίζουν για πρώτη φορά παρέχονται κατάλληλες οδηγίες μέσω της εφαρμογής, όπως φαίνεται στην Εικόνα

39 Εικόνα 10: Οδηγίες προς τους παίκτες μέσω της εφαρμογής Εικόνα 11: Κατάσταση εκθεμάτων μέσω της διεπαφής Όταν μαζευτούν οι παίκτες που θα συμμετέχουν και όλα είναι έτοιμα τότε ξεκινά η συνεδρία. Το παιχνίδι ξεκινά και οι παίκτες περιφέρονται στον χώρο με τις φορητές τους συσκευές. Στόχος είναι οι παίκτες να μαζέψουν όσο πιο πολλούς πόντους μπορούν κάνοντας αντιστοιχίσεις ετικετών με εκθέματα που έχουν αναγνωρίσει. Στο Taggling οι παίκτες δεν έχουν στη διάθεσή τους όλες τις ετικέτες του παιχνιδιού, αλλά έναν συγκεκριμένο αριθμό ετικετών που μπορούν να έχουν πάνω τους και να κάνουν αντιστοιχίσεις. Στα αντικείμενα του φυσικού χώρου, δηλαδή στα εκθέματα, μπορούν να πραγματοποιηθούν αντιστοιχίσεις με περισσότερες από μία ετικέτες. Για να γίνει πιο εύκολα αντιληπτό, είναι σαν σε κάθε έκθεμα να αντιστοιχεί ένα καλάθι με συγκεκριμένη χωρητικότητα που οι παίκτες αφήνουν και παίρνουν ετικέτες σε αυτό. Κατά την διάρκεια του παιχνιδιού ο κάθε παίκτης μπορεί να έχει 39

40 επίγνωση για τις ετικέτες που είναι αντιστοιχισμένες πάνω στα εκθέματα, όπως φαίνεται παρακάτω στην Εικόνα 11. Κατά τη διάρκεια της συνεδρίας, οι παίκτες περιφέρονται στον χώρο και αναγνωρίζουν τα αντικείμενα του φυσικού κόσμου σκανάροντας τον κωδικό τους με την κάμερα του κινητού τους. Στην Εικόνα 12 φαίνεται η διεπιφάνεια της εφαρμογής κατά την διάρκεια ενός σκαναρίσματος. Εικόνα 12: Σκανάρισμα QRcode ενός εκθέματος Εικόνα 13: Ετικέτες στην τσάντα του χρήστη Έπειτα μπορούν να αντιστοιχίσουν το αντικείμενο με κάποια ή κάποιες ετικέτες που έχουν πάνω τους. Επίσης μπορούν να κάνουν και αποσύνδεση 40

41 κάποιας ετικέτας από το αντικείμενο αυτό και να την έχουν διαθέσιμη για αργότερα. Κάθε παίκτης κρατάει πάνω του συγκεκριμένες ετικέτες που μπορεί να χρησιμοποιήσει. Παρακάτω στην Εικόνα 13 φαίνεται μέσω της διεπαφής της εφαρμογής η τσάντα με τις ετικέτες που κρατάει κάποιος παίκτης. Ο περιορισμός όσον αφορά το αν γίνεται να κάνει αποσύνδεση μιας ετικέτας, έχει να κάνει με τον αν η ετικέτα είναι στο σωστό έκθεμα που αντιστοιχεί. Αν είναι στο σωστό τότε κανένας παίκτης δεν μπορεί να την αποσυνδέσει. Ανάλογα με τον αν η αντιστοίχιση ή αποσύνδεση από κάποιον παίκτη είναι σωστή ή όχι κερδίζει ή χάνει πόντους αντίστοιχα. Παρακάτω στην Εικόνα 14 φαίνεται η εικόνα της διεπαφής που βλέπει ο χρήστης όταν βλέπει τις ετικέτες που έχει πάνω του κάποιο έκθεμα. Εικόνα 14: Ετικέτες αντιστοιχισμένες σε κάποιο έκθεμα 41

42 Νικητής της συγκεκριμένης συνεδρίας του Taggling είναι αυτός που θα έχει στο τέλος μαζέψει τους περισσότερους πόντους. Η συνεδρία μπορεί να τελειώσει με πολλούς τρόπους. Μπορεί να τελειώσει μετά από ένα χρονικό όριο, όταν όλες οι ετικέτες αντιστοιχιστούν σωστά και με άλλους τρόπους που καθορίζονται από την διεπαφή της εφαρμογής. 3.3 Ορισμός βασικών οντοτήτων Για να είναι εφικτή η μοντελοποίηση αυτή θα πρέπει να υπάρχουν κάποιες βασικές οντότητες που θα είναι κοινές για τα παιχνίδια. Για το λόγο αυτό, αρχικά πρέπει να οριστούν οι βασικές οντότητες σε ένα παιχνίδι. Η πρώτη βασική οντότητα ορίζεται το αντικείμενο του φυσικού κόσμου, δηλαδή ένα έκθεμα στον φυσικό χώρο κάποιου μουσείου ή οποιαδήποτε άλλο αντικείμενο που παίζει ρόλο σε κάποιον φυσικό χώρο για το αντίστοιχο παιχνίδι. Στην Εικόνα 15 παρακάτω φαίνεται πιο παραστατικά ο συμβολισμός του. Η δεύτερη οντότητα είναι η ετικέτα, δηλαδή το εικονικό αντικείμενο το οποίο θα αντιστοιχίζεται σε κάποιο ή κάποια αντικείμενα του πραγματικού κόσμου. Στην Εικόνα 16 παρακάτω φαίνεται πιο παραστατικά ο συμβολισμός της. Εικόνα 15: Αντικείμενο του φυσικού κόσμου Εικόνα 16: Ετικέτα 42

43 3.4 Ορισμός δυνατών καταστάσεων παίκτη Σε ένα χωρο-ευαίσθητο παιχνίδι αυτού του είδους πρέπει να είναι ορισμένες οι καταστάσεις που μπορεί να βρεθεί κάποιος παίκτης. Οι καταστάσεις αυτές έχουν άμεση σύνδεση με τις πράξεις που αναφέρονται βασικό λεξικό που περιγράφθηκε στο υποκεφάλαιο 3.1. Αυτό συμβαίνει καθώς έτσι μπορούν να προσδιοριστούν οι στιγμές στις οποίες θα υπάρχει επικοινωνία μεταξύ παίκτη και εξυπηρετητή. Κίνηση: Η πρώτη βασική κατάσταση στην οποία μπορεί να βρίσκεται ένας παίκτης κατά τη διάρκεια μιας συνεδρίας είναι όταν κινείται στον φυσικό χώρο. Κατά την διάρκεια της κίνησής του δεν αλληλεπιδρά με αντικείμενα του φυσικού κόσμου, αλλά το μόνο που αλλάζει είναι οι συντεταγμένες του στον χάρτη, οπότε με βάση αυτές μπορεί να υπάρξει επικοινωνία με τον εξυπηρετητή. Για παράδειγμα μπορεί σε ένα χωρο-ευαίσθητο παιχνίδι οι συντεταγμένες του παίκτη να ελέγχονται από τον εξυπηρετητή και αν βρεθεί σε κάποιες συγκεκριμένες να ενεργοποιείται κάποιο γεγονός, όπως να του στέλνει μήνυμα ότι βρίσκεται κοντά σε κάποιο αντικείμενο. Αναγνώριση αντικειμένου: Η δεύτερη κατάσταση που μπορεί να βρεθεί ένας παίκτης είναι όταν αναγνωρίζει ένα αντικείμενο του φυσικού κόσμου. Στην κατάσταση αυτή ο παίκτης έχει επικοινωνία με τον εξυπηρετητή καθώς στέλνει και λαμβάνει από αυτόν δεδομένα για κάποιο αντικείμενο. Αντιστοίχιση: Η τρίτη κατάσταση που μπορεί να βρεθεί είναι όταν πραγματοποιεί κάποια αντιστοίχιση μιας ετικέτας με κάποιο αντικείμενο του φυσικού κόσμου. Στην διάρκεια αυτής της πράξης υπάρχει αποστολή και λήψη δεδομένων μεταξύ παίκτη και εξυπηρετητή. Αποσύνδεση: Η τέταρτη κατάσταση είναι κατά την διάρκεια που ένας παίκτης κάνει αποσύνδεση κάποιας ετικέτας από κάποιο αντικείμενο. 3.5 Είδη σχέσεων αντικειμένων φυσικού κόσμου- ετικετών Σε επόμενο βήμα μοντελοποιούνται κάποιες κατηγορίες σύμφωνα με τις οποίες μπορούν να ομαδοποιηθούν τα παιχνίδια αυτού του είδους. Με τον τρόπο 43

44 αυτόν θα μπορεί να προσδιοριστεί με μεγαλύτερη ακρίβεια η συμπεριφορά που αναφέρθηκε προηγουμένως, ώστε να μπορεί να υποστηριχτεί από τον εξυπηρετητή. Όσον αφορά τα παιχνίδια αυτού του είδους μπορούν να χαρακτηριστούν ως παιχνίδια αντιστοίχισης μεταξύ αντικειμένων του πραγματικού κόσμου και ετικετών. Υπάρχουν όμως περισσότερα από ένα είδη αντιστοιχίσεων. Το πρώτο είδος αντιστοίχισης είναι το 1-1, δηλαδή κάθε μοναδική ετικέτα αντιστοιχεί σε ένα και μόνο αντικείμενο του πραγματικού κόσμου, όπως στο MuseumScrabble όπου κάθε ετικέτα αντιστοιχεί σε ένα μοναδικό έκθεμα. Εικόνα 17: Σχέσεις 1-1 Ένα δεύτερο είδος είναι το 1-Ν, δηλαδή σε κάθε μοναδικό αντικείμενο του φυσικού κόσμου αντιστοιχούν πολλές ετικέτες ο αριθμός των οποίων καθορίζεται από την εφαρμογή, όπως για παράδειγμα στο Taggling όπου σε κάθε έκθεμα αντιστοιχίζεται αριθμός ετικετών. 44

45 Εικόνα 18: Σχέσεις 1-Ν Τέλος το είδος αντιστοιχίσεων Ν-1 που σημαίνει ότι μία ετικέτα μπορεί να αντιστοιχιστεί σε περισσότερα από ένα αντικείμενα του φυσικού κόσμου. Για το συγκεκριμένο είδος αντιστοιχίσεων θα μπορούσε να είναι ένα παιχνίδι που αποτελεί παραλλαγή των προηγουμένων δύο. Εικόνα 19: Σχέσεις Ν Ορισμός βασικών χώρων αποθήκευσης ετικετών Οι δύο βασικές οντότητες, των παιχνιδιών αυτών, που έχουν μοντελοποιηθεί είναι τα αντικείμενα του φυσικού κόσμου και οι ετικέτες. Όσον αφορά τα 45

46 αντικείμενα, βρίσκονται στον φυσικό χώρο και κατά την διάρκεια της συνεδρίας έχουν συγκεκριμένη θέση και οι παίκτες δεν έχουν δυνατότητα μετακίνησής τους. Αυτό όμως που οι παίκτες συνεχώς επηρεάζουν με τις αποφάσεις τους είναι οι θέσεις των ετικετών. Με την παραδοχή αυτή πρέπει να οριστούν οι βασικοί (ιδεατοί/virtual) χώροι στους οποίους μπορούν να βρίσκονται οι ετικέτες σε οποιαδήποτε στιγμή στη συνεδρία. Εισάγονται λοιπόν οι έννοιες του σακουλιού, του καλαθιού και του κουβά. Μια ετικέτα μπορεί να βρίσκεται μόνο σε έναν από τους τρεις αυτούς χώρους και οι παίχτες με τις ενέργειές τους μετακινούν ετικέτες μεταξύ των χώρων αυτών. Το σακούλι ορίζεται ως ο ιδεατός χώρος των ετικετών που ανήκει σε κάθε παίκτη ξεχωριστά. Κάθε παίκτης έχει το δικό του ιδιωτικό σακούλι και σε αυτό μπορεί να κουβαλάει συγκεκριμένο αριθμό ετικετών. Όταν πραγματοποιεί κάποια αντιστοίχιση θα αφαιρείται η αντίστοιχη ετικέτα από το σακούλι του και όταν αποσυνδέει κάποια ετικέτα θα εισέρχεται σε αυτό. Το σακούλι ορίζεται για παιχνίδια όπου οι παίκτες δεν θα χουν πρόσβαση σε όλες τις ετικέτες αλλά σε έναν περιορισμένο αριθμό από αυτές. Το σακούλι έχει συγκεκριμένη χωρητικότητα, δηλαδή χωράει περιορισμένο αριθμό ετικετών. Εικόνα 20: Παίκτης με το δικό του Σακούλι Το καλάθι ορίζεται ως ο ιδεατός χώρος αποθήκευσης ετικετών σε ένα αντικείμενο του φυσικού κόσμου. Για να γίνει καλύτερα αντιληπτό, θα 46

47 μπορούσε να θεωρηθεί ως ένα καλάθι το οποίο υπάρχει σε κάθε αντικείμενο του φυσικού κόσμου στο οποίο οι παίκτες αφήνουν και παίρνουν ετικέτες. Ο χώρος αυτός βοηθάει πολύ σε περιπτώσεις παιχνιδιών όπου σε ένα αντικείμενο αντιστοιχίζονται περισσότερες από μία ετικέτες, όπως για παράδειγμα στο taggling. Το καλάθι αυτό έχει συγκεκριμένη χωρητικότητα, δηλαδή χωράει περιορισμένο αριθμό ετικετών. Εικόνα 21: Καλάθι ενός αντικειμένου του φυσικού κόσμου Ο κουβάς ορίζεται ως ένας ιδεατός δημόσιος χώρος ετικετών που είναι προσβιβάσιμος από όλους τους παίχτες. Χρησιμεύει για παιχνίδια όπου οι ετικέτες βρίσκονται σε κάποιον κοινό χώρο για όλους τους παίκτες. Όταν αποκτήσουν πρόσβαση σε αυτόν, μπορούν να πάρουν οποιαδήποτε ετικέτα και να την αντιστοιχίσουν σε κάποιο αντικείμενο. Ένα παράδειγμα είναι στο MuseumScrabble, όπου κάποιος παίκτης παίρνει κάποια ετικέτα από τον δημόσιο χώρο και την αντιστοιχεί σε κάποιο αντικείμενο του φυσικού κόσμου και δεν μπορεί να χρησιμοποιηθεί από κάποιον άλλον παίκτη μέχρι να αποσυνδεθεί. Ο κουβάς στο MuseumScrabble περιέχει όλες τις ετικέτες που υπάρχουν σε μια συνεδρία. Επομένως όταν κάποιος παίκτης θέλει να πραγματοποιήσει κάποια αντιστοίχιση θα πρέπει να πάρει με κάποιον τρόποτην ετικέτα από τον κουβά να την αποθέσει στο καλάθι κάποιου αντικειμένου. Θα μπορούσε βέβαια να χρησιμοποιηθούν περισσότεροι από έναν κουβά, δηλαδή περισσότεροι δημόσιοι χώροι και ο καθένας θα έχει μέρος των συνολικών ετικετών. Όσον αφορά την πρόσβαση στον κουβά, οι 47

48 παίκτες μπορούν να έχουν από οποιαδήποτε θέση είναι ή σε συγκεκριμένες θέσεις που έχουν οριστεί από το παιχνίδι. Εικόνα 22: Κουβάς ως κοινόχρηστος χώρος για απόκτηση ετικετών 3.7 Ορισμός του πεδίου ορατότητας Αφού έγινε ανάλυση όσον αφορά τις ετικέτες, δηλαδή τον τρόπο που γίνεται η διαχείρισή τους, τώρα θα πραγματοποιηθεί ανάλυση όσον αφορά τον τρόπο που θα γίνεται η διαχείριση των αντικειμένων του φυσικού κόσμου. Για να επιτευχθεί αυτό θα οριστεί ένα νέο εργαλείο, αυτό του πεδίου ορατότητας. Μιλώντας για πεδίο ορατότητας από και εδώ και πέρα θα εννοούνται τα αντικείμενα του φυσικού κόσμου τα οποία θα έχει αναγνωρίσει κάποιος παίκτης. Με αυτά επομένως θα έχει την δυνατότητα να κάνει κάποια αντιστοίχιση ή αποσύνδεση ετικετών. Για το πόσο χρόνο θα είναι στο πεδίο ορατότητάς του τα αντικείμενα που έχει αναγνωρίσει έχουμε τις παρακάτω περιπτώσεις: Από τη στιγμή που ένας παίκτης αναγνωρίσει κάποιο αντικείμενο του φυσικού κόσμου με κάποιον τρόπο, για παράδειγμα το σκανάρει με το κινητό του, θα υπάρχει για πάντα στο πεδίο ορατότητάς του και θα μπορεί να έχει πρόσβαση στο καλάθι του αντικειμένου, όποια και να είναι η τοποθεσία του παίκτη. Για παράδειγμα θα μπορούσε με αυτήν την 48

49 υλοποίηση κάποιος να περάσει από όλα τα αντικείμενα, να τα αναγνωρίσει και μετά να πραγματοποιήσει αντιστοιχίσεις και αποσυνδέσεις με τις ετικέτες. Από τη στιγμή που ο παίκτης αναγνωρίσει κάποιο αντικείμενο του φυσικού κόσμου υπάρχουν περιορισμοί για το πόσο θα παραμένει στο πεδίο ορατότητάς του. Οι περιορισμοί μπορεί να είναι χωρικοί ή χρονικοί ή άλλου είδους. Παράδειγμα χωρικού περιορισμού είναι η απόσταση που θα πρέπει να έχει ο παίχτης από το αντικείμενο για να μπορεί να κάνει κάποια αντιστοίχιση ή αποσύνδεση. Παράδειγμα χρονικού περιορισμού, είναι το χρονικό διάστημα από τη στιγμή που αναγνωρίσει ένα αντικείμενο μέσα στο οποίο θα έχει το δικαίωμα για αντιστοίχηση ή αποσύνδεση. Χρονικοί ή χωρικοί περιορισμοί μπορούν να συνδυαστούν. Εικόνα 23: Αναγνώριση αντικειμένου μέσω φορητής συσκευής 49

50 3.8 Εφαρμογή της μοντελοποίησης Αφού ορίστηκαν τα εργαλεία βάσει τα οποία μπορούν να υλοποιηθούν παιχνίδια αυτού του είδους που περιγράφθηκαν παραπάνω, θα γίνει αναλυτική επεξήγηση του τρόπου που εφαρμόζονται στα παιχνίδια MuseumScrabble και Taggling. Πριν αρχίσει η ανάλυση, ορίζονται 2 διαφορετικοί τρόποι που μπορεί να παιχτεί κάποιο από αυτά τα παιχνίδια. Ο πρώτος είναι ο αλληλεπιδραστικός (interactive), όπου οι παίκτες στην ίδια συνεδρία μοιράζονται όλες τις ετικέτες, οι οποίες είναι κοινές ανάμεσα σε όλους και κάθε αντιστοίχιση/αποσύνδεση που γίνεται επηρεάζει τις διαθέσιμες ετικέτες των υπολοίπων. Ο δεύτερος είναι ο ατομικός (solo), δηλαδή οι παίκτες που βρίσκονται σε κοινή συνεδρία δε μοιράζονται μεταξύ τους τις ετικέτες του παιχνιδιού, ο καθένας κάνει ατομικό σκορ και κάθε αντιστοίχιση/αποσύνδεση δεν επηρεάζει τις ετικέτες των υπολοίπων MuseumScrabble Το MuseumScrabble που όσον αφορά την περιγραφή του είναι γνωστό από πριν, αποτελεί ένα παιχνίδι αντιστοιχίσεων ετικετών και αντικειμένων του φυσικού κόσμου και οι σχέσεις μεταξύ τους αποτελούν 1-1. Σε κάθε αντικείμενο του φυσικού κόσμου αντιστοιχεί μοναδικά μία ετικέτα. Το παιχνίδι αυτό αν παιχτεί ως αλληλεπιδραστικό, τότε οι ετικέτες που θα αντιστοιχίζονται από κάθε παίκτη θα επηρεάζουν άμεσα τις διαθέσιμες των υπολοίπων. Αυτή η συμπεριφορά μοντελοποιείται αποτελεσματικά με τη χρήση του κουβά (του δημόσιου χώρου ετικετών). Για να γίνει καλύτερα αντιληπτό, όταν ένας παίκτης πραγματοποιεί κάποια αντιστοίχιση, είναι σαν να αφαιρεί την ετικέτα από τον κουβά και έτσι από εκείνη τη στιγμή κανένας άλλος δε μπορεί να την χρησιμοποιήσει. Όταν επιστρέψει η ετικέτα πίσω στον δημόσιο χώρο (π.χ. αν ο παίχτης που έκανε την αντιστοίχηση το μετανιώσει και αποσυνδέσει την ετικέτα), τότε θα μπορούν ξανά οι υπόλοιποι να 50

51 χρησιμοποιήσουν την ετικέτα. Ο κουβάς έχει χωρητικότητα ίση με τον αριθμό όλων των ετικετών της συνεδρίας. Όσον αφορά το σακούλι (τον χώρο των ετικετών που είναι ιδιωτικός σε κάθε παίχτη) δεν εφαρμόζεται, οπότε θεωρούμε ότι έχει χωρητικότητα μηδέν. Τέλος όσον αφορά το καλάθι η χωρητικότητά του θα είναι 1, καθώς μόνο μια ετικέτα μπορεί να αντιστοιχιστεί με ένα αντικείμενο του φυσικού κόσμου. Παρακάτω στην Εικόνα 24 φαίνεται πιο παραστατικά η εφαρμογή της μοντελοποίησης με τα εργαλεία που αναλύθηκαν στην υποενότητα 3.6. Εικόνα 24: MuseumScrabble Αλληλεπιδραστικό Αν παιχτεί το MuseumScrabble ως ατομικό (solo), τότε κάθε παίκτης που κάνει αντιστοιχίσεις/αποσυνδέσεις δεν επηρεάζει τις διαθέσιμες ετικέτες των υπόλοιπων παικτών. Γι αυτό η χρήση του κουβά δεν είναι αποτελεσματική και η χωρητικότητά του σε αυτό το είδος παιχνιδιού θα είναι μηδέν. Στην περίπτωση αυτή η υλοποίηση μέσω του σακουλιού είναι αποτελεσματική. Το σακούλι στο ατομικό παιχνίδι MuseumScrabble είναι για κάθε παίκτη μοναδικό, θα έχει μέγεθος ίσο με τον αριθμό όλων των ετικετών της συνεδρίας και κάθε αντιστοίχιση θα περιορίζει μόνο τον ίδιο από το να την ξαναχρησιμοποιήσει χωρίς να επηρεάζει καθόλου τους υπόλοιπους παίκτες. Επομένως έχοντας ο καθένας τις δικές του ετικέτες, θα κάνει δικό του ατομικό 51

52 σκορ και στο τέλος νικητής θα είναι αυτός με τους περισσότερους πόντους. Τέλος όσον αφορά το καλάθι η χωρητικότητά του θα είναι 1, καθώς μόνο μια ετικέτα μπορεί να αντιστοιχιστεί με ένα αντικείμενο του φυσικού κόσμου. Εικόνα 25: MuseumScrabbleΑτομικό Taggling Στο Taggling που όσον αφορά την περιγραφή του είναι γνωστή από πριν, αποτελεί ένα παιχνίδι αντιστοιχίσεων ετικετών και αντικειμένων του φυσικού κόσμου και οι σχέσεις μεταξύ τους αποτελούν 1-Ν. Σε κάθε αντικείμενο του φυσικού κόσμου, δηλαδή, αντιστοιχεί συγκεκριμένος αριθμός ετικετών. Αν το παιχνίδι αυτό παιχτεί ως αλληλεπιδραστικό τότεοι παίκτες θα μοιράζονται όλες τις ετικέτες σε μία κοινή συνεδρία. Σε αυτήν την περίπτωσητο σακούλι του κάθε παίκτη θα έχει χωρητικότητα μεγαλύτερη του μηδενός. Αυτό συμβαίνει καθώς στο Taggling ένας αριθμός των ετικετών θα βρίσκεται πάνω σε κάποιον παίκτη και ένας άλλος πάνω στα εκθέματα. Οπότε υπάρχει άμεση αλληλεπίδραση μεταξύ των παικτών, καθώς μοιράζονται τις ετικέτες, και το που θα κάνει αντιστοίχιση κάποιος μία ετικέτα επηρεάζει το που θα το βρει κάποιος άλλος. Γι αυτό τον λόγο o κουβάς (ο δημόσιος χώρος ετικετών) έχει χωρητικότητα μηδέν. Η χωρητικότητα του σακουλιού θα είναι κ όπου το κ θα καθορίζεται από τους κανόνες του παιχνιδιού. Επειδή σε ένα αντικείμενο του φυσικού κόσμου αντιστοιχούν πολλές ετικέτες, η 52

53 χωρητικότητα του καλαθιού θα είναι λ, το οποίο θα καθορίζεται από τους κανόνες του παιχνιδιού. Για να γίνει πιο εύκολα αντιληπτό ακολουθεί ένα πιο παραστατικό παράδειγμα. Έστω ότι υπάρχουν 20 ετικέτες συνολικά και 2 παίκτες στη συνεδρία. Αν κάθε παίκτης μπορεί να κρατάει στο σακούλι του 4 ετικέτες τότε τα υπόλοιπα 12 θα αντιστοιχιστούν σε κάποια αντικείμενα του φυσικού κόσμου, δηλαδή στα σακούλια των αντικειμένων. Για να μπορέσει ο παίκτης Α να αποκτήσει κάποιο από τις ετικέτες του παίκτη Β θα πρέπει ο Β να το αντιστοιχίσει σε κάποιο αντικείμενο λανθασμένα, ώστε να πάει και να το αποσυνδέσει για να το βάλει στο σακούλι του. Βλέπουμε λοιπόν ότι υπάρχει πλήρη αλληλεπίδραση όσον αφορά τις ετικέτες που χρησιμοποιούνται σε μια τέτοιου είδους συνεδρία. Εικόνα 26: Taggling Αλληλεπιδραστικό Στην περίπτωση τώρα που στη συνεδρία παιχτεί ατομικό (solo) Taggling, η αλληλεπίδραση μεταξύ των παικτών σταματά να υπάρχει. Αυτό συμβαίνει καθώς κάθε παίκτης παίζει με όλες τις ετικέτες σαν να είναι μόνος του στη συνεδρία. Οπότε σε αυτήν την περίπτωση και πάλι η χωρητικότητα του κουβά είναι μηδέν, του σακουλιού κάθε παίκτη κ και του καλαθιού κάθε αντικειμένου λ. Σύμφωνα με το προηγούμενο παράδειγμα με τις 20 ετικέτες, ο παίκτης θα κρατάει 4 και οι υπόλοιπες 16 θα ναι στο καλάθι των αντικειμένων του φυσικού κόσμου και θα παίζει μόνος του με αυτές πραγματοποιώντας 53

54 αντιστοιχίσεις και αποσυνδέσεις. Είτε αυτές είναι σωστές ή λάθος θα κερδίζει ή θα χάνει πόντους. Στο τέλος από όλους τους παίκτες θα νικά αυτός με το μεγαλύτερο σκορ. Εικόνα 27: Taggling Ατομικό 3.9 Υλοποίηση για υποστήριξη νέων παιχνιδιών Αφού έγινε ανάλυση του τρόπου που επιδρά η μοντελοποίηση στα παιχνίδια MuseumScrabble και Taggling, το ερώτημα που τίθεται είναι πως ο επεκτάσιμος εξυπηρετητής θα υποστηρίξει και παιχνίδια καινούρια που δεν έχουν υλοποιηθεί ακόμα; Όταν δημιουργήσει κάποιος ένα νέο παιχνίδι αυτού του είδους δεν θα χρειάζεται να κατασκευάσει και αντίστοιχο εξυπηρετητή για την υποστήριξή του. Το μόνο που χρειάζεται να κάνει είναι να κατασκευάσει ένα κατάλληλο module (όπως ορίζεται στο Nodejs) για το παιχνίδι του και απλά περνώντας το στον εξυπηρετητή μπορεί πλέον να υποστηριχτεί το νέο του παιχνίδι. Τι είναι όμως το module και τι μορφή πρέπει να έχει το περιεχόμενό του; Το module στο Nodejs είναι ένα αρχείο με συναρτήσεις γραμμένο σε javascript. Με βάση τον κώδικα των συναρτήσεων αυτών θα εφαρμόζονται οι κανόνες του νέου παιχνιδιού μέσω του επεκτάσιμου εξυπηρετητή. Για να 54

55 μπορέσει, όμως, αυτός ο τρόπος να είναι αποτελεσματικός θα πρέπει να οριστεί μια συγκεκριμένη δομή που θα έχει το module. Για τον ορισμό λοιπόν της δομής αυτής θα ληφθούν υπόψη οι δυνατές καταστάσεις που μπορεί να βρίσκεται κάποιος παίκτης κατά την διάρκεια μιας συνεδρίας, όπως ορίστηκε αναλυτικά στην παράγραφο 3.4. Με βάση της δυνατές αυτές καταστάσεις θα οριστούν οι βασικές συναρτήσεις του module, το περιεχόμενο των οποίων θα επεξεργάζεται ο προγραμματιστής του νέου παιχνιδιού. Οι συναρτήσεις που θα πρέπει να περιέχει το module παρουσιάζονται παρακάτω. oninit: το περιεχόμενο της συνάρτησης αυτής θα πραγματοποιεί την αρχικοποίηση μιας νέας συνεδρίας onscan: το περιεχόμενο της συνάρτησης αυτής θα περιέχει τον κώδικα που θα εκτελείται όταν κάποιος παίκτης αναγνωρίζει ένα αντικείμενο του φυσικού κόσμου με την συσκευή του onlock: το περιεχόμενο της συνάρτησης αυτής θα περιέχει τον κώδικα που θα εκτελείται όταν ένας παίκτης κάνει κάποια αντιστοίχιση μιας ετικέτας με κάποιο αντικείμενο του φυσικού κόσμου onunlock: το περιεχόμενο της συνάρτησης αυτής θα περιέχει τον κώδικα που θα εκτελείται όταν ένας παίκτης κάνει κάποια αποσύνδεση μιας ετικέτας από κάποιο αντικείμενο του φυσικού κόσμου onmove: το περιεχόμενο της συνάρτησης αυτής θα περιέχει τον κώδικα που θα εκτελείται όταν ένας παίκτης κινείται στον φυσικό χώρο onend: το περιεχόμενο της συνάρτησης αυτής θα περιέχει τον κώδικα που θα εκτελείται όταν τελειώσει μια συνεδρία του αντίστοιχου παιχνιδιού Όλες οι συναρτήσεις αυτές είναι γενικευμένες και με βάση αυτές μπορούν να εφαρμόζονται οι κανόνες των νέων παιχνιδιών. Επομένως, ένας προγραμματιστής αφού κατασκευάσει το νέο παιχνίδι, διαμορφώνοντας το module αυτό μπορεί να εκμεταλλευτεί αποτελεσματικά τις υπηρεσίες του επεκτάσιμου εξυπηρετητή. 55

56 4 Υλοποίηση Στο κεφάλαιο 3 έγινε λεπτομερής ανάλυση της μοντελοποίησης των παιχνιδιών. Ορίστηκε το βασικό λεξιλόγιο και τα βασικά εργαλεία με τα οποία θα υποστηριχτεί η μοντελοποίηση αυτή. Στο συγκεκριμένο κεφάλαιο θα παρουσιαστεί η υλοποίησή της αναλυτικά με τις τεχνολογίες που αναφέρθηκαν στο κεφάλαιο 2. Στην υλοποίηση του εξυπηρετητή πρέπει να τονιστεί ότι όλα τα μηνύματα από και προς τον εξυπηρετητή πρέπει να έχουν δομή JSON. 4.1 Δημιουργία περιβάλλοντος εξυπηρετητή Όπως αναφέρθηκε στο κεφάλαιο 2 ο κώδικας του εξυπηρετητή αναπτύχθηκε πάνω σε Nodejs. Για την δομή του περιβάλλοντος του επεκτάσιμου εξυπηρετητή χρησιμοποιήθηκε η επέκταση του Nodejs, το Expressjs. Ο βασικός σκοπός του Expressjs είναι να διευκολύνει τον χρήστη στο πρώτο στάδιο δημιουργίας ενός εξυπηρετητή. Στην ουσία τον απαλλάσσει από όλον εκείνον τον κώδικα που πρέπει να γράψει ώστε να δημιουργήσει έναν εξυπηρετητή από το μηδέν. Αυτό που κάνει είναι να δημιουργεί σε κάποια τοποθεσία (directory) του υπολογιστή έναν κενό εξυπηρετητή ο οποίος δεν κάνει κάτι, απλά δημιουργεί ένα οργανωμένο περιβάλλον για ανάπτυξη. Το περιβάλλον του επεκτάσιμου εξυπηρετητή έχει την μορφή που φαίνεται στην Εικόνα

57 Εικόνα 28: Περιβάλλον που δημιουργεί το Expressjs Όπως φαίνεται το Expressjs δημιουργεί οργανωμένα ένα περιβάλλον εξυπηρετητή απαλλάσσοντας τον χρήστη από θέματα κατασκευής και οργάνωσης φακέλων και αρχείων από το μηδέν. Έτσι μπορεί να εστιάσει κατευθείαν στην βασική λειτουργικότητα του εξυπηρετητή και να πραγματοποιήσει την ανάπτυξή του. Από εκεί και πέρα ο χρήστης μπορεί να προσθέσει δικά του αρχεία που είναι αναγκαία γι αυτόν. Στην Εικόνα 28, στο περιβάλλον του επεκτάσιμου εξυπηρετητή υπάρχουν φάκελοι και αρχεία που συμβάλουν στην λειτουργικότητά του. Η επεξήγηση των κυριότερων είναι η εξής: app.js: είναι ο πυρήνας του εξυπηρετητή. Είναι το αρχείο που συνδέει τα πάντα μεταξύ τους, για παράδειγμα τις συνεδρίες (sessions), τις διαδρομές (routes) του εξυπηρετητή και οτιδήποτε άλλο, και πραγματοποιεί τη σύνδεση με τη βάση δεδομένων. routes: στον φάκελο αυτόν υπάρχουν οι προκαθορισμένες διαδρομές (routes) του εξυπηρετητή οι οποίες αφορούν τη διαχείριση χρηστών, των συνεδριών και βασικών πράξεων του παιχνιδιού που θα επεξηγηθούν αναλυτικά στη συνέχεια. 57

58 custom_routes: αυτός ο φάκελος δίνει την πρώτη επεκτάσιμη λειτουργικότητα στον εξυπηρετητή. Σε αυτόν τον φάκελο ο εξυπηρετητής περιμένει να τοποθετούνται δυναμικά νέες διαδρομές (routes), οι οποίες μπορεί να είναι απαραίτητες για ένα νέο παιχνίδι, το οποίο μπορεί να μην υποστηρίζεται πλήρως από τις προκαθορισμένες που έχει ο εξυπηρετητής. models: ο φάκελος αυτός περιέχει όλα τα μοντέλα της βάσης δεδομένων, δηλαδή την δομή των πινάκων μέσω του mongoose. Τα μοντέλα αποτελούν modules του Nodejs τα οποία μπορούν να χρησιμοποιηθούν από άλλα αρχεία για αναφορά στην βάση δεδομένων. public: στο φάκελο αυτόν υπάρχουν τα scripts με τα δεδομένα της βάσης δεδομένων. Αποτελεί και αυτό επεκτάσιμο κομμάτι του εξυπηρετητή καθώςσε αυτόν τον φάκελο εισάγονται τα JSON αρχεία δεδομένων ενός νέου παιχνιδιού. rulesets: ο φάκελος αυτός αποτελεί ένα ακόμα επεκτάσιμο κομμάτι του εξυπηρετητή και πολύ βασικό καθώς σε αυτό υπάρχουν οι κανόνες των παιχνιδιών. Κανόνας είναι ο κώδικας, ή αλλιώς το module, που είναι σχεδιασμένος να εκτελεστεί ανάλογα με την πράξη ενός παίκτη. Όταν κάποιος θέλει να περάσει στον εξυπηρετητή τους κανόνες του νέου του παιχνιδιού ή και παραλλαγές κάποιου ήδη υπάρχοντος, απλά βάζει το αρχείο με αυτούς στον φάκελο rulesets. 4.2 Διαχείριση χρηστών Ο επεκτάσιμος εξυπηρετητής διαθέτει μία προκαθορισμένη στρατηγική όσον αφορά το κομμάτι διαχείρισης των χρηστών του. Αυτό όμως δε περιορίζει ένα νέο παιχνίδι το οποίο μπορεί να έχει απαιτήσεις για περισσότερες λειτουργίες όσον αφορά την διαχείριση των χρηστών, καθώς μπορεί να τις εισάγει χρησιμοποιώντας τα επεκτάσιμες λειτουργίες του εξυπηρετητή. Οι προκαθορισμένες λειτουργίες όσον αφορά την διαχείριση των χρηστών του συστήματος από τον εξυπηρετητή παρουσιάζονται στη συνέχεια καθώς και το διάγραμμα καταστάσεων που τις απεικονίζει πιο παραστατικά. 58

59 Το διάγραμμα καταστάσεων όσον αφορά την διαχείριση ενός χρήστη παρουσιάζεται στην Εικόνα 29. Εικόνα 29: Διάγραμμα καταστάσεων χρήστη Όσον αφορά το κομμάτι εγγραφής ενός χρήστη στο σύστημα η λογική είναι αρκετά απλή. Όπως φαίνεται και στο αντίστοιχο διάγραμμα καταστάσεων, ο χρήστης για να κάνει εγγραφή πρέπει να στείλει το επιθυμητό username που θέλει να έχει, τον κωδικό πρόσβασής του και ένα . Ο μόνος περιορισμός του συστήματος είναι να μην υπάρχουν δύο ή περισσότεροι χρήστες με ίδιο username. Επομένως αποτυγχάνεται η εγγραφή όταν παραβιάζεται ο περιορισμός αυτός ή όταν κάποιο πεδίο είναι κενό ή όταν το δεν έχει την προβλεπόμενη δομή. Από την στιγμή που κάποιος χρήστης πραγματοποιήσει επιτυχώς εγγραφή στο σύστημα, γίνονται κάποιες λειτουργίες στον εξυπηρετητή. Ο εξυπηρετητής παράγει ένα κλειδί 48-bit το οποίο ονομάζεται login_token, το οποίο το αντιστοιχεί στον συγκεκριμένο χρήστη. Ο χρήστης μέχρι να κάνει login στο σύστημα δεν γνωρίζει το κλειδί. Όταν θέλει να κάνει login στέλνει αίτημα στον εξυπηρετητή με παραμέτρους username και password. Αν όλα είναι σωστά 59

60 τότε ο εξυπηρετητής του επιστρέφει το κλειδί και πλέον ο χρήστης το ξέρει. Από κει και πέρα ότι αίτημα πραγματοποιεί ο χρήστης μέσω της εφαρμογής, πρέπει να συμπεριλάβει στο περιεχόμενό του και το κλειδί αυτό. Τέλος, αν επιθυμεί να πραγματοποιήσει έξοδο (logout) από το σύστημα στέλνει απλά ένα αίτημα στον εξυπηρετητή με παραμέτρους username, password και login_token και αφού κάνει τους απαραίτητους ελέγχους ο εξυπηρετητής παράγει ένα νέο κλειδί 48-bit που αντιστοιχεί στον χρήστη. Το παλιό παύει να ισχύει και για να γίνει γνωστό το καινούριο πρέπει να κάνει πάλι είσοδο (login) στο σύστημα. Τέλος δίνονται οι προκαθορισμένες διαδρομές του εξυπηρετητή και οι είσοδοι-έξοδοι τους για τις παραπάνω λειτουργίες διαχείρισης χρηστών. Όλα τα δεδομένα εισόδου πρέπει να έχουν την δομή JSON. Η απάντηση του εξυπηρετητή είναι και αυτή σε μορφή JSON και έχει ένα πεδίο το status και σε αυτό υπάρχει η απόκρισή του.τα αιτήματα σε όλες τις διαδρομές αποστέλονται με μέθοδο POST. serverdomain :3000/users/register Χρήση για εγγραφή στο σύστημα. Είσοδοι: o username o password o Έξοδοι στο πεδίο status : o 2 σφάλμα: το πεδίο username που στάλθηκε είναι κενό o 3 σφάλμα: το πεδίο password που στάλθηκε είναι κενό o 4 σφάλμα: το πεδίο που στάλθηκε είναι κενό o 9 σφάλμα: το username που στάλθηκε υπάρχει ήδη στο σύστημα o 1 επιτυχής εγγραφή gcm_api_key: το API key του εξυπηρετητή στο google cloud messaging gcm_sender_id: το id του εξυπηρετητή στο gcm 60

61 Οι παράμετροι του gcm στέλνονται στην περίπτωση επιτυχούς εγγραφής του χρήστη για να πάρει registration_key από την google η συσκευή του χρήστη. serverdomain :3000/users/login Χρήση για είσοδο στο σύστημα. Είσοδοι: o username o password o registration_token: το κλειδί που πήρε η συσκευή από το gcm Έξοδοι στο πεδίο status : o 2 σφάλμα: το πεδίο username που στάλθηκε είναι κενό o 3 σφάλμα: το πεδίο password που στάλθηκε είναι κενό o 13 σφάλμα: το πεδίο registration_token που στάλθηκε είναι κενό o 6 επιτυχής είσοδος (login) στο σύστημα login_token: το 48-bit κλειδί που αντιστοιχεί στον χρήστη o 10 σφάλμα: σωστό username, λάθος password o 5 σφάλμα: το username δεν βρέθηκε στην βάση δεδομένων serverdomain :3000/users/logout Χρήση για έξοδο από το σύστημα. Είσοδοι: o username o password o login_token Έξοδοι στο πεδίο status : o 2 σφάλμα: το πεδίο username που στάλθηκε είναι κενό o 3 σφάλμα: το πεδίο password που στάλθηκε είναι κενό o 7 σφάλμα: το πεδίο login_token που στάλθηκε είναι κενό o 8 επιτυχής έξοδος (logout) από το σύστημα o 10 σφάλμα: σωστό username, λάθος password o 11 σφάλμα: λάθος login_token, δεν αντιστοιχεί στον χρήστη o 10 σφάλμα: σωστό username, λάθος password 61

62 o 5 σφάλμα: το username δεν βρέθηκε στην βάση δεδομένων 4.3 Διαχείριση συνεδριών Ένα πολύ σημαντικό κομμάτι στην ανάπτυξη του εξυπηρετητή είναι ο τρόπος με τον οποίο διαχειρίζεται τις συνεδρίες του. Στην Εικόνα 30 παρουσιάζεται το διάγραμμα καταστάσεων μιας συνεδρίας από την δημιουργία μέχρι και το τέλος της. Εικόνα 30: Διάγραμμα καταστάσεων μιας συνεδρίας Όταν λοιπόν ένας διαχειριστής θέλει να δημιουργήσει μια συνεδρία τότε αφού στείλει το κατάλληλο μήνυμα στον εξυπηρετητή, γεννάται μια νέα συνεδρία. Το όνομα της συνεδρίας πρέπει να είναι μοναδικό στο σύστημα. Η πρώτη κατάσταση που μπαίνει η συνεδρία όταν δημιουργηθεί είναι η κατάσταση 0. Σε αυτήν την κατάσταση ο εξυπηρετητής περιμένει για κάποια χρονική διάρκεια να εισέλθουν παίκτες στην συνεδρία. Το παιχνίδι δεν έχει αρχίσει ακόμα και πράξεις στον χώρο δεν γίνονται. Όταν τελειώσει λοιπόν ο χρόνος για την συμμετοχή παικτών, η συνεδρία περνάει στην κατάσταση 1. Σε 62

63 αυτήν το παιχνίδι ξεκινάει και όλοι οι παίκτες οι οποίοι μπήκαν στη συνεδρία στην κατάσταση 0, αρχίζουν να μετακινούνται και να κάνουν πράξεις στον χώρο. Η κατάσταση 1 διαρκεί κάποιο χρονικό διάστημα και όταν αυτό περάσει το παιχνίδι τελειώνει και η συνεδρία περνάει στην κατάσταση 2 που είναι και η τελική. Σε αυτήν την κατάσταση όποιος εισέλθει στη συνεδρία απλά θα μπορεί να δει όλο το ιστορικό των πράξεων που έγιναν στην κατάσταση 1 καθώς και τους πόντους του κάθε παίκτη. Σε αυτήν το παιχνίδι έχει ολοκληρωθεί και οι παίκτες μπορούν να αποχωρήσουν από την συνεδρία. Για θέματα ασφαλείας κάθε συνεδρίας, όταν δημιουργείται μια συνεδρία παράγεται από τον εξυπηρετητή ταυτόχρονα ένα 48-bit κλειδί το οποίο είναι μοναδικό για κάθε μία. Όταν κάποιος χρήστης εισέλθει σε αυτήν επιτυχώς τότε του επιστρέφεται το κλειδί αυτό. Έτσι στη συνέχεια οποιαδήποτε πράξη θέλει να κάνει στη συνεδρία, πρέπει σε κάθε του αίτημα να περιλαμβάνει και το κλειδί αυτό για επιβεβαίωση ότι όντως ανήκει σε αυτήν. Αφού λοιπόν εξηγήθηκαν όλες οι προκαθορισμένες δυνατές καταστάσεις μιας συνεδρίας τώρα δίνονται οι προκαθορισμένες διαδρομές του εξυπηρετητή μέσω των οποίων γίνεται η διαχείριση των συνεδριών. Τα αιτήματα σε όλες τις διαδρομές αποστέλονται με μέθοδο POST. Οι προκαθορισμένες διαδρομές είναι οι εξής: serverdomain :3000/sessions/create_new Χρήση για δημιουργία μιας νέας συνεδρίας. Έξοδοι: o session_id: η μοναδική ταυτότητα της συνεδρίας o session_password: κωδικός για πρόσβαση στην συνεδρία ο οποίος είναι προαιρετικός o max_players: μέγιστος αριθμός παικτών που μπορούν να υπάρχουν σε αυτήν την συνεδρία o admin_username: το username του διαχειριστή ο οποίος θέλει να δημιουργήσει τη συγκεκριμένη συνεδρία 63

64 o allow_join_during_game: η τιμή του πεδίου αυτού καθορίζει αν μπορούν να εισέλθουν παίκτες εφόσον η κατάσταση στην οποία βρίσκεται η συνεδρία είναι η 1, δηλαδή όταν το παιχνίδι έχει ήδη αρχίσει. Οι δυνατές τιμές του πεδίο είναι 0 για απαγόρευση εισόδου και 1 για τη δυνατότητα εισόδου. o allow_teams: η τιμή του πεδίου αυτού καθορίζει αν μπορούν να υπάρχουν ομάδες παικτών στην συγκεκριμένη συνεδρία. Οι δυνατές τιμές είναι 0 για όχι και 1 για ναι. o game_id: είναι η ταυτότητα του παιχνιδιού το οποίο θα παιχτεί στην συγκεκριμένη συνεδρία o assemble_duration: είναι η διάρκεια που θα κρατήσει η κατάσταση 0 της συνεδρίας, δηλαδή ο χρόνος που έχουν οι παίκτες για να εισέλθουν στην συνεδρία. o game_duration: είναι η διάρκεια που θα κρατήσει η κατάσταση 1 της συνεδρίας, δηλαδή ο χρόνος που διαρκεί το παιχνίδι o content_id: είναι η ταυτότητα του περιεχομένου ετικετών και αντικειμένων με το οποίο θα παιχτεί το παιχνίδι στην συνεδρία Έξοδοι στο πεδίο status : o 4 σφάλμα: το πεδίο session_id που στάλθηκε είναι κενό o 3 σφάλμα: το πεδίο password που στάλθηκε είναι κενό o 5 σφάλμα: το πεδίο max_players που στάλθηκε είναι κενό o 6 σφάλμα: το πεδίο admin_username που στάλθηκε είναι κενό o 27 σφάλμα: το πεδίο allow_join_during_game που στάλθηκε είναι κενό o 28 σφάλμα: το πεδίο allow_teams που στάλθηκε είναι κενό o 29 σφάλμα: το πεδίο game_id που στάλθηκε είναι κενό o 30 σφάλμα: το πεδίο assemble_duration που στάλθηκε είναι κενό o 31 σφάλμα: το πεδίο game_duration που στάλθηκε είναι κενό o 32 σφάλμα: το πεδίο content_id που στάλθηκε είναι κενό o 33 σφάλμα: το πεδίο max_players δεν είναι ακέραιος 64

65 o 34 σφάλμα: το πεδίο allow_join_during_game δεν είναι ακέραιος o 35 σφάλμα: το πεδίο allow_teams δεν είναι ακέραιος o 36 σφάλμα: το πεδίο assemble_duration δεν είναι ακέραιος o 37 σφάλμα: το πεδίο game_duration δεν είναι ακέραιος o 38 σφάλμα: το πεδίο max_players δεν είναι θετικός αριθμός o 39 σφάλμα: το πεδίο allow_join_during_game πρέπει να είναι 0 ή 1 o 40 σφάλμα: το πεδίο allow_teams πρέπει να είναι 0 ή 1 o 41 σφάλμα: το πεδίο assemble_duration πρέπει να είναι θετικός αριθμός o 42 σφάλμα: το πεδίο game_duration πρέπει να είναι θετικός αριθμός o 23 σφάλμα: το όνομα του session υπάρχει στο σύστημα o 25 σφάλμα: το content_id δεν υπάρχει στην βάση δεδομένων o 26 σφάλμα: το game_id δεν υπάρχει στην βάση δεδομένων o 1 επιτυχής δημιουργία συνεδρίας o 9 σφάλμα: το admin_username δεν υπάρχει στην βάση δεδομένων serverdomain :3000/ sessions/join Χρήση για είσοδο ενός χρήστη του συστήματος σε κάποια συνεδρία. Είσοδοι: o session_id: η ταυτότητα της συνεδρίας στην οποία θέλει να εισέλθει o session_password: ο κωδικός της συνεδρίας ώστε να αποκτήσει πρόσβαση σε αυτήν o username: όνομα του χρήστη ο οποίος θέλει να εισέλθει στη συνεδρία o login_token: το κλειδί του χρήστη το οποίο αναφέρθηκε στο υποκεφάλαιο 4.2 Έξοδοι στο πεδίο status : 65

66 o 4 σφάλμα: το πεδίο session_id που στάλθηκε είναι κενό o 3 σφάλμα: το πεδίο password που στάλθηκε είναι κενό o 2 σφάλμα: το πεδίο username που στάλθηκε είναι κενό o 7 σφάλμα: το πεδίο login_token που στάλθηκε είναι κενό o 8 σφάλμα: το username δεν υπάρχει στην βάση δεδομένων o 10 σφάλμα: λάθος login_token, δεν αντιστοιχεί στον χρήστη o 11 σφάλμα: η συνεδρία που στάλθηκε δεν βρέθηκε στο σύστημα o 20 σφάλμα: δεν μπορεί να γίνει είσοδος στη συνεδρία. Το μήνυμα αυτό χρησιμοποιείται όταν η συνεδρία βρίσκεται στην κατάσταση 1 και το allow_join_during_game έχει την τιμή 0. o 12 επιτυχής είσοδο του παίκτη στη συνεδρία o 24 ο παίκτης υπάρχει ήδη στη συνεδρία o 13 σφάλμα: η συνεδρία είναι πλήρης δεν χωράνε άλλοι παίκτες o 14 σφάλμα: λάθος κωδικός συνεδρίας serverdomain :3000/ sessions/quit Χρήση για έξοδο ενός χρήστη από μία συνεδρία. Είσοδος: o session_id: η ταυτότητα της συνεδρίας από την οποία θέλει να εξέλθει o username: όνομα του χρήστη ο οποίος θέλει να εξέλθει από την συνεδρία o login_token: το κλειδί του χρήστη το οποίο αναφέρθηκε στο υποκεφάλαιο 4.2 o session_token: το κλειδί της συνεδρίας το οποίο χρησιμοποιείται για επιβεβαίωση ότι όντως ανήκει στην συνεδρία. Έξοδοι στο πεδίο status : o 4 σφάλμα: το πεδίο session_id που στάλθηκε είναι κενό o 43 σφάλμα: το πεδίο session_token που στάλθηκε είναι κενό o 2 σφάλμα: το πεδίο username που στάλθηκε είναι κενό o 7 σφάλμα: το πεδίο login_token που στάλθηκε είναι κενό 66

67 o 8 σφάλμα: το username δεν υπάρχει στην βάση δεδομένων o 10 σφάλμα: λάθος login_token, δεν αντιστοιχεί στον χρήστη o 11 σφάλμα: η συνεδρία που στάλθηκε δεν βρέθηκε στο σύστημα o 21 σφάλμα: λάθος session_token, δεν αντιστοιχεί στην συνεδρία o 16 σφάλμα: ο παίκτης δεν ανήκει στην συνεδρία o 15 επιτυχής αποχώρηση από την συνεδρία serverdomain :3000/ sessions/delete Χρήση για διαγραφή μιας συνεδρίας από το σύστημα. Είσοδοι: o session_id: η μοναδική ταυτότητα της συνεδρίας που θέλει να διαγράψει ο διαχειριστής o admin_username: το username του διαχειριστή ο οποίος θέλει να διαγράψει τη συγκεκριμένη συνεδρία Έξοδοι στο πεδίο status : o 4 σφάλμα: το πεδίο session_id που στάλθηκε είναι κενό o 6 σφάλμα: το πεδίο admin_username που στάλθηκε είναι κενό o 9 σφάλμα: το admin_username δεν υπάρχει στην βάση δεδομένων o 11 σφάλμα: η συνεδρία που στάλθηκε δεν βρέθηκε στο σύστημα o 17 επιτυχής διαγραφή συνεδρίας o 18 σφάλμα ο το username δεν έχει δικαιώματα διαχειριστή 4.4 Σχεδιασμός και ανάπτυξη της βάσης δεδομένων του εξυπηρετητή Όπως αναφέρθηκε στο κεφάλαιο 2 η τεχνολογία που χρησιμοποιήθηκε για την ανάπτυξη της βάσης δεδομένων είναι η Mongodb. H Mongodb ανήκει στις μησχεσιακές τεχνολογίες για ανάπτυξη βάσεων δεδομένων. Για να μπορέσει λοιπόν να δημιουργηθεί σχεσιακό σχήμα της βάση δεδομένων χρησιμοποιήθηκε η τεχνολογία Mongoose. Η Mongoose χρησιμοποιείται πάνω στην Mongodb με στόχο τη δημιουργία σχέσεων μεταξύ των πινάκων της 67

68 βάσης δεδομένων. Αυτό οδηγεί σε πιο εύκολη επεξεργασία και απεικόνιση των σχέσεων μεταξύ των δεδομένων (Mardan, 2014). Παρακάτω παρουσιάζεται αναλυτικά η πορεία που έγινε μέχρι τον τελικό σχεδιασμό της βάσης δεδομένων του εξυπηρετητή Σχήμα βάσης δεδομένων Αρχικά λοιπόν για τον σχεδιασμό της βάσης δεδομένων, πραγματοποιήθηκε η δημιουργία του σχήματος της βάσης. Παρακάτω στην Εικόνα 31 φαίνεται το σχήμα αυτό και στην συνέχεια γίνεται η αναλυτική επεξήγηση των πεδίων του. Εικόνα 31: Σχήμα βάσης δεδομένων εξυπηρετητή Βασικές οντότητες της βάσης δεδομένων Το σχήμα της βάσης δεδομένων είναι αρκετά μεγάλο και περίπλοκο. Σε αυτό υπάρχουν βασικές οντότητες οι οποίες αναλύονται παρακάτω: 68

69 player: Σε αυτόν τον πίνακα αποθηκεύονται όλα τα απαραίτητα στοιχεία που πρέπει να κρατάει ο εξυπηρετητής για έναν παίκτη. Τα στοιχεία αυτά είναι: o username: το όνομα του παίκτη στο σύστημα το οποίο είναι μοναδικό και αποτελεί πρωτεύων κλειδί o password: ο κωδικός που έχει ο παίκτης τον οποίο τον δηλώνει όταν κάνει εγγραφή στο σύστημα και τον χρησιμοποιεί για είσοδο σε αυτό o η διεύθυνση του ηλεκτρονικό ταχυδρομείο του παίκτη που το δίνει όταν κάνει εγγραφή στο σύστημα o login_token: είναι ένα κλειδί 48-bit, μοναδικό για κάθε παίκτη το οποίο παράγεται από τον εξυπηρετητή και χρησιμοποιείται από τον παίκτη για πιστοποίηση πριν από κάθε πράξη o registration_token: είναι το κλειδί που αποκτά ο χρήστης από το google cloud messaging όταν κάνει εγγραφή σε αυτό και το χρειάζεται ο εξυπηρετητής για να μπορεί να επικοινωνεί με αυτόν o color: χρησιμοποιείται ως το χρώμα που αντιστοιχεί στον παίκτη στην διεπαφή του παιχνιδιού session: Σε αυτόν τον πίνακα κρατούνται όλα τα δεδομένα για κάθε συνεδρία που δημιουργείται στο σύστημα. Τα δεδομένα είναι τα εξής: o session_id: είναι η ταυτότητα της συνεδρίας, αποτελεί πρωτεύων κλειδί και είναι μοναδική στο σύστημα. o session_password: είναι ο κωδικός που επιτρέπει την είσοδο κάποιου παίκτη στην συνεδρία. Το να έχει κωδικό κάποια συνεδρία είναι προαιρετικό. o max_players: είναι ο μέγιστος αριθμός παικτών που μπορούν να συμμετέχουν στην αντίστοιχη συνεδρία. o allow_join_during_game: η τιμή αυτού του πεδίου καθορίζει αν μπορούν να εισέλθουν νέοι παίκτες στην συνεδρία αφού το παιχνίδι 69

70 έχει ξεκινήσει. Μηδέν για απαγόρευση και 1 για είσοδο στη συνεδρία. o allow_teams: η τιμή αυτού του πεδίου καθορίζει αν επιτρέπονται οι ομάδες στην συγκεκριμένη συνεδρία. 1 για να υπάρχουν και μηδέν για απαγόρευση ομάδων στην συνεδρία. o state: το συγκεκριμένο πεδίο περιγράφει την κατάσταση στην οποία βρίσκεται η συνεδρία. Όπως αναφέρθηκε στο κεφάλαιο 4.3 οι δυνατές τιμές του πεδίου αυτού είναι 0 αν η συνεδρία είναι στην κατάσταση 0, 1 αν βρίσκεται στην κατάσταση 1 και 2 αν είναι στην κατάσταση 2. o session_token: το πεδίο αυτό αποτελεί ένα κλειδί το οποίο είναι μοναδικό για την αντίστοιχη συνεδρία και χρησιμοποιείται από τους παίκτες που συμμετέχουν σε αυτήν για πιστοποίηση ότι ανήκουν σε αυτή. o game_id: είναι ξένο κλειδί στον πίνακα game και είναι η ταυτότητα του παιχνιδιού το οποίο παίζεται στην συνεδρία αυτή. o assemble_duration: είναι η διάρκεια που κρατά η κατάσταση 0 της συνεδρίας όπου σε αυτήν μαζεύονται οι παίκτες και εισέρχονται στην συνεδρία. o game_duration: είναι η διάρκεια που κρατά η κατάσταση 1 της συνεδρίας όπου το παιχνίδι έχει ξεκινήσει και οι παίκτες που συμμετέχουν στη συνεδρία παίζουν. Μόλις περάσει η διάρκεια αυτή, η συνεδρία εισέρχεται στην κατάσταση 2, όπου το παιχνίδι έχει τελειώσει. o admin_username: το πεδίο αυτό αποτελεί ξένο κλειδί στον πίνακα admin και είναι ο διαχειριστής ο οποίος έχει δημιουργήσει την συνεδρία o content_id: αποτελεί ξένο κλειδί στον πίνακα content και αποτελεί το περιεχόμενο αντικειμένων και κλειδιών με βάση το οποίο θα παιχτεί το παιχνίδι. admin: 70

71 Σε αυτόν τον πίνακα αποθηκεύονται όλα τα απαραίτητα στοιχεία που πρέπει να κρατάει ο εξυπηρετητής για τους διαχειριστές των συνεδριών στο σύστημα. Τα στοιχεία αυτά είναι: o username: το όνομα του διαχειριστή στο σύστημα το οποίο είναι μοναδικό και αποτελεί πρωτεύων κλειδί του πίνακα o password: ο κωδικός που έχει ο διαχειριστής για να πραγματοποιεί είσοδο στο σύστημα o role: η τιμή αυτού του πεδίου ανάλογα με την τιμή της καθορίζει τον ρόλο που έχει ο διαχειριστής στο σύστημα. Οι δυνατές τιμές είναι 1 για τους διαχειριστές συγκεκριμένων συνεδριών, δηλαδή των συνεδριών που έχουν φτιαχτεί από αυτούς και η τιμή 2 για τους διαχειριστές όλων των συνεδριών αλλά και των παικτών του συστήματος. Οι δεύτεροι έχουν δηλαδή την δυνατότητα να επεξεργαστούν όλα τα δεδομένα του συστήματος. tag: Σε αυτόν τον πίνακα αποθηκεύονται όλα τα απαραίτητα στοιχεία που πρέπει να κρατάει ο εξυπηρετητής για τις ετικέτες που υπάρχουν αποθηκευμένες στη βάση δεδομένων. Τα στοιχεία αυτά είναι: o tag_id: είναι η ταυτότητα της ετικέτας και είναι μοναδική μόνο ως προς το content στο οποίο ανήκει. Αυτό συμβαίνει καθώς μπορεί 2 ή περισσότερα περιεχόμενα ετικετών να έχουν ίδιες ταυτότητες στις ετικέτες που περιλαμβάνουν και έτσι αποφεύγεται οποιοδήποτε σφάλμα όσον αφορά τις ταυτότητες των ετικετών. o valid_objects: το πεδίο αυτό αποτελεί ένα πίνακα που περιλαμβάνει όλες τις ταυτότητες των αντικειμένων στις οποίες είναι σωστή η αντιστοίχιση της συγκριμένης ετικέτας. Κάθε τιμή του πίνακα αποτελεί ξένο κλειδί στο πεδίο object_id του πίνακα object. 71

72 o tag_values: το πεδίο αυτό αποτελεί ένα πίνακα ο οποίος περιλαμβάνει τους πόντους που κερδίζονται όταν γίνει σωστά η αντιστοίχιση της ετικέτας με κάποιο από τα σωστά αντικείμενα που έχει το πεδίο valid_objects. o tag_hint: το πεδίο αυτό περιλαμβάνει κάποιο κείμενο το οποίο χρησιμοποιείται ως περιγραφή της ετικέτας ή ως βοήθεια για το που μπορεί κάποιος να την αντιστοιχίσει. Αυτό εξαρτάται από τον κατασκευαστή του αντίστοιχου περιεχομένου. o content_id: η τιμή του συγκεκριμένου πεδίου είναι το όνομα του περιεχομένου στο οποίο ανήκει η συγκεκριμένη ετικέτα. Αποτελεί ξένο κλειδί στον πίνακα content. object: Σε αυτόν τον πίνακα αποθηκεύονται όλα τα απαραίτητα στοιχεία που πρέπει να κρατάει ο εξυπηρετητής για τα αντικείμενα του φυσικού κόσμου τα οποία είναι αποθηκευμένα στο σύστημα. Τα στοιχεία αυτά είναι: o object_id: είναι η ταυτότητα του συγκεκριμένου αντικειμένου του φυσικού κόσμου και είναι μοναδική μόνο ως προς το content στο οποίο ανήκει. Αυτό συμβαίνει καθώς μπορεί 2 ή περισσότερα περιεχόμενα αντικειμένων να έχουν ίδιες ταυτότητες στα αντικείμενα που περιλαμβάνουν και έτσι αποφεύγεται οποιοδήποτε σφάλμα όσον αφορά τις ταυτότητες των ετικετών. o title: το πεδίο αυτό είναι ο τίτλος του συγκεκριμένου αντικειμένου o description: το πεδίο αυτό αποτελεί την περιγραφή του συγκεκριμένου αντικειμένου o object_hint: το πεδίο αυτό περιλαμβάνει κάποιο κείμενο το οποίο χρησιμοποιείται ως βοήθεια για τον παίκτη για το ποια ετικέτα μπορεί να αντιστοιχιστεί σε αυτό. 72

73 o collectdata: πεδίο αυτό περιλαμβάνει τα δεδομένα τα οποία περιλαμβάνει το QRcode του αντικειμένου και με βάση αυτά καταλαβαίνει ο εξυπηρετητής ποιο αντικείμενο αναγνώρισε ο παίκτης. o coords: είναι οι γεωγραφικές συντεταγμένες στις οποίες βρίσκεται το συγκεκριμένο αντικείμενο. o image: είναι η εικόνα που αντιστοιχεί στο συγκεκριμένο αντικείμενο και χρησιμοποιείται από την διεπαφή του χρήστη για να παρουσιάσει πιο παραστατικά το αντικείμενο σε αυτόν. o content_id: η τιμή του συγκεκριμένου πεδίου είναι το όνομα του περιεχομένου στο οποίο ανήκει το συγκεκριμένο αντικείμενο. Αποτελεί ξένο κλειδί στον πίνακα content. game: Σε αυτόν τον πίνακα αποθηκεύονται όλα τα απαραίτητα στοιχεία που πρέπει να κρατάει ο εξυπηρετητής τα παιχνίδια τα οποία είναι αποθηκευμένα στο σύστημα. Τα στοιχεία αυτά είναι: o game_id: είναι η ταυτότητα του παιχνιδιού η οποία είναι μοναδική και αποτελεί πρωτεύων κλειδί του πίνακα. o game_name: είναι το όνομα του παιχνιδιού. Δεν είναι μοναδικό καθώς ο εξυπηρετητής μπορεί να έχει δύο παιχνίδια αποθηκευμένα με το ίδιο όνομα αλλά με διαφορετική τιμή στο πεδίο ruleset. o ruleset: το πεδίο αυτό περιλαμβάνει το όνομα του ruleset με βάση το οποίο παίζεται το συγκεκριμένο παιχνίδι. Αποτελεί το όνομα που έχει το αρχείο το οποίο περιλαμβάνει τα modules τα οποία θα εκτελέσει ο εξυπηρετητής κατά την διάρκεια της συνεδρίας ώστε να το εφαρμόσει. bucket: Σε αυτόν τον πίνακα αποθηκεύονται όλα τα απαραίτητα στοιχεία που πρέπει να κρατάει ο εξυπηρετητής για κάθε κουβά που υπάρχει στο σύστημα. Τα στοιχεία αυτά είναι: 73

74 o bucket_id: είναι η ταυτότητα του αντίστοιχου κουβά και αποτελεί πρωτεύων κλειδί στον πίνακα αυτόν. o session_id: σε αυτό το πεδίο αποθηκεύεται η ταυτότητα της συνεδρίας στην οποία υπάρχει ο κουβάς αυτός και αποτελεί ξένο κλειδί στο πεδίο session_id του πίνακα session. o tags: το πεδίο αυτό είναι ένας πίνακας στον οποίο αποθηκεύονται όλες οι ταυτότητας των ετικετών οι οποίες βρίσκονται στον κουβά. Κάθε τιμή που αποθηκεύεται στον πίνακα αποτελεί ξένο κλειδί στο πεδίο tag_id του πίνακα tag. content: Σε αυτόν τον πίνακα αποθηκεύονται τα ονόματα των περιεχομένων, δηλαδή οι συλλογές από ετικέτες και αντικείμενα στο σύστημα. Τα στοιχεία αυτά είναι: o content_id: σε αυτό το πεδίο αποθηκεύεται η ταυτότητα του περιεχομένου στο οποίο ανήκουν αντικείμενα και ετικέτες που υπάρχουν στην βάση δεδομένων. topic: Σε αυτόν τον πίνακα αποθηκεύονται οι κατηγορίες στις οποίες ομαδοποιούνται οι ετικέτες ενός περιεχομένου. Τα στοιχεία αυτά είναι: o topic_id: είναι η ταυτότητα της κατηγορίας. o title: είναι ο τίτλος της κατηγορίας. o description: η περιγραφή της συγκεκριμένης κατηγορίας. o image: η εικόνα που χρησιμοποιείται από την διεπαφή του χρήστη για απεικόνιση της συγκεκριμένης κατηγορίας Συσχετίσεις του σχήματος της βάσης δεδομένων Αφού έχει γίνει αναφορά σε όλες τις βασικές οντότητες της βάσης δεδομένων του εξυπηρετητή, τώρα θα γίνει επεξήγηση όλων των συσχετίσεων που υπάρχουν μεταξύ αυτών. Οι συσχετίσεις παρουσιάζονται παρακάτω: 74

75 player_session: Ο πίνακας αυτός συσχετίζει ονόματα χρηστών και ταυτότητες συνεδριών, οπότε έτσι βλέπει κάποιος σε ποια συνεδρία ανήκει κάποιος παίκτης. Τα στοιχεία του πίνακα είναι: o session_id: σε αυτό το πεδίο αποθηκεύεται η ταυτότητα της συνεδρίας στην οποία ανήκει ο παίκτης. Αποτελεί ξένο κλειδί στον πίνακα session στο πεδίο session_id. o username: το όνομα του παίκτη που ανήκει στη παραπάνω συνεδρία. Αποτελεί ξένο κλειδί στον πίνακα player στο πεδίο username. rankings: Ο πίνακας αυτός συσχετίζει ονόματα χρηστών με ταυτότητες συνεδριών και συνολικούς πόντους, οπότε έτσι βλέπει κάποιος πόσους πόντους έχει κάποιος παίκτης σε κάποια συνεδρία. Τα στοιχεία του πίνακα είναι: o session_id: σε αυτό το πεδίο αποθηκεύεται η ταυτότητα της συνεδρίας στην οποία ανήκει ο παίκτης. Αποτελεί ξένο κλειδί στον πίνακα session στο πεδίο session_id. o username: το όνομα του παίκτη που ανήκει στη παραπάνω συνεδρία. Αποτελεί ξένο κλειδί στον πίνακα player στο πεδίο username. o total_points: οι συνολικοί πόντοι ο έχει ο παίκτης σε αυτήν την συνεδρία. history: Ο πίνακας αυτός κρατά πληροφορίες για το ιστορικό κάθε συνεδρίας, δηλαδή ποια πράξη έγινε, από ποιον παίκτη, μεταξύ ποιων αντικειμένων και ετικετών και η χρονική στιγμή που πραγματοποιήθηκε. Τα στοιχεία του πίνακα είναι: o session_id: σε αυτό το πεδίο αποθηκεύεται η ταυτότητα της συνεδρίας. Αποτελεί ξένο κλειδί στον πίνακα session στο πεδίο session_id. 75

76 o username: το όνομα του παίκτη που ανήκει στη παραπάνω συνεδρία και έκανε την πράξη. Αποτελεί ξένο κλειδί στον πίνακα player στο πεδίο username. o action: το πεδίο αυτό παίρνει ως τιμή έναν ακέραιο και ανάλογα με το είδος της πράξης οι δυνατοί ακέραιοι είναι 0 για αναγνώριση ενός αντικειμένου, 1 για αντιστοίχιση μιας ετικέτας με ένα αντικείμενο και 2 για αποσύνδεση μιας ετικέτας με ένα αντικείμενο. Βέβαια ανάλογα με το ruleset, αν υπάρχουν και νέες πράξεις πέρα από αυτές και πρέπει να αποθηκευτούν στο ιστορικό εξαρτάται από τον προγραμματιστή για τις τιμές που θα χρησιμοποιήσει. o object_id: αποτελεί την ταυτότητα του αντικειμένου στο οποίο γίνεται η πράξη. o tag_id: αποτελεί την ταυτότητα της ετικέτας η οποία χρησιμοποιείται στην πράξη. Στην περίπτωση αναγνώρισης αντικειμένου η τιμή της αφήνεται NULL. o datetime: πεδίο αυτό παίρνει ως τιμή την ημερομηνία και ώρα την οποία έγινε η αντίστοιχη πράξη που πραγματοποίησε ο παίκτης. o active: το συγκεκριμένο πεδίο παίρνει ως τιμές 0 και 1, και ορίζει αν μια πράξη είναι ακόμα ενεργή ή όχι. Το 0 σημαίνει ότι έχει πάψει να είναι ενεργή και το 1 ότι ισχύει ακόμα. inventory: Ο πίνακας αυτός συσχετίζει χρήστες που ανήκουν σε κάποια συνεδρία με το σακούλι που κουβαλάνε σε αυτήν. Τα στοιχεία του πίνακα είναι: o session_id: σε αυτό το πεδίο αποθηκεύεται η ταυτότητα της συνεδρίας στην οποία ανήκει ο παίκτης. Αποτελεί ξένο κλειδί στον πίνακα session στο πεδίο session_id. o username: το όνομα του παίκτη που ανήκει στη παραπάνω συνεδρία. Αποτελεί ξένο κλειδί στον πίνακα player στο πεδίο username. 76

77 o tags: το πεδίο αυτό αποτελεί έναν πίνακα ο οποίος έχει σαν περιεχόμενο τις ετικέτες που έχει στο σακούλι του ο παίκτης στην συγκεκριμένη συνεδρία. vision: Ο πίνακας αυτός συσχετίζει χρήστες που ανήκουν σε κάποια συνεδρία με το πεδίο ορατότητας που έχει σε αυτήν. Τα στοιχεία του πίνακα είναι: o session_id: σε αυτό το πεδίο αποθηκεύεται η ταυτότητα της συνεδρίας στην οποία ανήκει ο παίκτης. Αποτελεί ξένο κλειδί στον πίνακα session στο πεδίο session_id. o username: το όνομα του παίκτη που ανήκει στη παραπάνω συνεδρία. Αποτελεί ξένο κλειδί στον πίνακα player στο πεδίο username. o objects: το πεδίο αυτό αποτελεί έναν πίνακα ο οποίος έχει σαν περιεχόμενο τα αντικείμενα που έχει στο πεδίο ορατότητάς του ο παίκτης στην συγκεκριμένη συνεδρία. basket_object: Ο πίνακας αυτός στην ουσία συμβολίζει το καλάθι ενός αντικειμένου στο οποίο αφήνουν οι παίκτες ετικέτες. Συσχετίζει την ταυτότητα ενός αντικειμένου που ανήκει σε μια συνεδρία με την ταυτότητα της ετικέτας που έχει αφήσει κάποιος παίκτης σε αυτήν. Τα στοιχεία του πίνακα είναι: o session_id: σε αυτό το πεδίο αποθηκεύεται η ταυτότητα της συνεδρίας στην οποία ανήκει το αντικείμενο. Αποτελεί ξένο κλειδί στον πίνακα session στο πεδίο session_id. o object_id: η ταυτότητα του αντικειμένου το οποίο ανήκει στην παραπάνω συνεδρία. Αποτελεί ξένο κλειδί στον πίνακα object στο πεδίο object_id. o tag: η ταυτότητα της ετικέτας η οποία έχει αντιστοιχιστεί στο συγκεκριμένο αντικείμενο. o username: το όνομα του παίκτη που έχει αντιστοιχίσει την παραπάνω ετικέτα στο συγκεκριμένο αντικείμενο. topic_tag: 77

78 Ο πίνακας αυτός συσχετίζει τις ταυτότητες των ετικετών με την κατηγορία στην οποία ανήκουν. Τα στοιχεία του πίνακα είναι: o tag_id: σε αυτό το πεδίο αποθηκεύεται η ταυτότητα της ετικέτας. Αποτελεί ξένο κλειδί στον πίνακα tag στο πεδίο tag_id. o topic_id: η ταυτότητα της κατηγορίας στην οποία ανήκει η παραπάνω ετικέτα. Αποτελεί ξένο κλειδί στον πίνακα topic στο πεδίο topic_id. 4.5 Επικοινωνία εξυπηρετητή με συσκευές Σε αυτό το σημείο θα γίνει αναφορά για τον τρόπο που επικοινωνεί ο εξυπηρετητής με τις φορητές συσκευές. Η επικοινωνία μεταξύ τους πραγματοποιείται μέσω του google cloud messaging. Ο εξυπηρετητής όταν κάποιος παίκτης κάνει εγγραφή στο σύστημα, όπως αναλύθηκε στο υποκεφάλαιο 4.2, του επιστρέφει το APIkey και το senderid του. Με το APIkey η συσκευή του παίκτη θα κάνει εγγραφή στο gcm και θα αποκτήσει deviceid. Με το senderid θα επιτρέπει στον εξυπηρετητή να στέλνει μηνύματα στη συσκευή. Ο εξυπηρετητής για να μπορεί να επικοινωνεί με τις συσκευές πρέπει να γνωρίζει τα device ids τους. Όταν μια συσκευή κάνει είσοδο (login) στο σύστημα τότε στέλνει το device id της σε αυτόν, όπως αναλύθηκε στο υποκεφάλαιο 4.2, και από κει και πέρα μπορεί να υπάρξει επικοινωνία μεταξύ τους. Όταν ένας προγραμματιστής ενός module θέλει να στείλει μέσω gcm μηνύματα σε συσκευές της συνεδρίας πρέπει να ξέρει τις συναρτήσεις που διαθέτει ο εξυπηρετητής για να το πετύχει. Ο συγκεκριμένος εξυπηρετητής διαθέτει δύο συναρτήσεις που στέλνουν μέσω gcm μηνύματα σε φορητές συσκευές και παρουσιάζονται παρακάτω. 1. gcm_broadcast: Η συνάρτηση αυτή στέλνει μήνυμα σε όλες της συσκευές μιας συνεδρίας. Τα ορίσματά της είναι δύο. Το πρώτο είναι η ταυτότητα του session στο οποίο υπάρχουν οι συσκευές που θέλει να στείλει το 78

79 μήνυμα. Το δεύτερο είναι ένα string το οποίο είναι το μήνυμα που θέλει να μεταδόσει σε αυτές. 2. gcm_send: Η συνάρτηση αυτή στέλνει ένα μήνυμα σε μία συγκεκριμένη συσκευή. Τα ορίσματά της είναι δύο. Το πρώτο είναι το device id της συσκευής στην οποία θέλει να στείλει το μήνυμα. Το δεύτερο string και είναι το μήνυμα το οποίο θέλει να μεταδόσει σε αυτήν. Μια σημαντική πληροφορία που πρέπει να γνωρίζει ο προγραμματιστής είναι το πως θα συμπεριλάβει τις συναρτήσεις αυτές στο module του για να μπορεί να τις καλέσει. Για να τις συμπεριλάβει θα πρέπει στο module του να έχει την εντολή var gcm_func = require('../routes/gcm_functions');. Από εκεί και πέρα με dot notation μπορεί να της καλέσει και να στέλνει μηνύματα, για παράδειγμα gcm_func.gcm_send(device_id, message ). 4.6 Προκαθορισμένες λειτουργίες εξυπηρετητή Μέχρι στιγμής έχει γίνει αναλυτική επεξήγηση στον τρόπο που ο εξυπηρετητής διαχειρίζεται τους χρήστες, στον τρόπο που διαχειρίζεται τις συνεδρίες και στη δομή της βάσης δεδομένων του. Τώρα θα γίνει αναφορά στις βασικές προκαθορισμένες λειτουργίες που έχει ο εξυπηρετητής προκειμένου να υποστηρίξει βασικές πράξεις σε παιχνίδια. Όπως αναφέρθηκε στο κεφάλαιο 3.9 για να μπορέσει ένα νέο παιχνίδι να το υποστηρίζει ο εξυπηρετητής θα πρέπει το module με τους κανόνες του να έχει μια συγκεκριμένη δομή. Η δομή αυτή περιλαμβάνει συναρτήσεις που συνδέονται με πράξεις του χρήστη. Οι συναρτήσεις αυτές είναι προκαθορισμένες (default) και εκτελούνται μέσω κάποιων προκαθορισμένωνδιαδρομών (routes) του που περιγράφονται στη συνέχεια Αρχικοποίηση και τέλος του παιχνιδιού Ο εξυπηρετητής είναι επεκτάσιμος που σημαίνει ότι όταν ένας προγραμματιστής θέλει να τον χρησιμοποιήσει για την υποστήριξη ενός νέου 79

80 παιχνιδιού, μπορεί περνώντας απλώς ένα νέο module να δώσει στον εξυπηρετητή τους κανόνες του παιχνιδιού του. Το module αυτό μπορεί να έχει όσες νέες συναρτήσεις θέλει μαζί και με τις προκαθορισμένες. Ο μόνος περιορισμός είναι ότι πρέπει να έχει αναγκαστικά 2 συγκεκριμένες από τις προκαθορισμένες συναρτήσεις, την oninit() και την onend(). Αυτές αφορούν την αρχή και το τέλος του παιχνιδιού και περιγράφονται αναλυτικά παρακάτω. Η πρώτη συνάρτηση που πρέπει να έχει το module είναι η oninit(), η οποία εκτελείται όταν μια συνεδρία μεταβαίνει από την κατάσταση 0 στην κατάσταση 1. Όταν τελειώσει ο χρόνος στον οποίο οι παίκτες μαζεύονται σε μια συνεδρία (κατάσταση 0) και η συνεδρία περνά στην διεκπεραίωση του παιχνιδιού (κατάσταση 1), ο εξυπηρετητής ψάχνει και εκτελεί την συνάρτηση oninit() από το module του παιχνιδιού. Η συνάρτηση αυτή είναι απαραίτητη και πρέπει πάντα να υπάρχει στο module που έχει τους κανόνες του παιχνιδιού. O εξυπηρετητής θεωρεί ότι η συνάρτηση αυτή θα αρχικοποιήσει όλες τις παραμέτρους του παιχνιδιού ώστε να μπορέσει να ξεκινήσει επιτυχώς η κατάσταση 1, για παράδειγμα ανάθεση ετικετών στα σακούλια των παικτών ή γέμισμα του κουβά με ετικέτες. Η δεύτερη συνάρτηση που πρέπει να έχει το module είναι η συνάρτηση onend(), η οποία εκτελείται όταν η συνεδρία μεταβαίνει από την κατάσταση 1 στην 2. Όταν γίνει η μετάβαση από την κατάσταση 1 της συνεδρίας στην κατάσταση 2 ο εξυπηρετητής ψάχνει και εκτελεί την συνάρτηση onend () από το module του παιχνιδιού. O εξυπηρετητής θεωρεί ότι η συνάρτηση αυτή θα κάνει τις απαραίτητες ενέργειες που αφορούν την ολοκλήρωση του παιχνιδιού, για παράδειγμα να υπολογίζει σύμφωνα με τους κανόνες του παιχνιδιού τον νικητή ή την τελική κατάταξη στην συγκεκριμένη συνεδρία Προκαθορισμένες διαδρομές εξυπηρετητή Ο εξυπηρετητής έχει κάποιες προκαθορισμένες διαδρομές οι οποίες θέτουν σε λειτουργία τις συναρτήσεις του module. Αν το παιχνίδι χρειάζεται περισσότερες διαδρομές για την εφαρμογή των κανόνων του δεν υπάρχει 80

81 πρόβλημα καθώς ο εξυπηρετητής μπορεί να υποστηρίξει και νέες διαδρομές. Το πώς το κάνει αυτό εξηγείται αναλυτικά σε επόμενο κεφάλαιο. Οι προκαθορισμένες διαδρομές του εξυπηρετητή είναι οι παρακάτω και όλες δέχονται αιτήματα POST : serverdomain :3000/Game/Sessions/scan Η συγκεκριμένη διαδρομή έχει ως στόχο να καλέσει την συνάρτηση onscan() από το module με τους κανόνες του παιχνιδιού. Η διαδρομή αυτή δέχεται παραμέτρους με βάση τους οποίους γίνεται η αναγνώριση ενός αντικειμένου. Τα δύο είδη δεδομένων για κάποιο αντικείμενο που περιμένει είναι collectdata και coords, όπως φαίνεται παρακάτω. Αν ο προγραμματιστής θέλει άλλου είδους δεδομένα, τότε θα χρησιμοποιήσει κάποια δικιά του διαδρομή για την αναγνώριση αντικειμένου. Οι είσοδοι της διαδρομής είναι οι εξής: o session_id: η ταυτότητα της συνεδρίας στην οποία γίνεται η αναγνώριση του αντικειμένου o username: το όνομα του παίκτη που θέλει να κάνει την πράξη της αναγνώρισης o collectdata: τα δεδομένα που στέλνει η εφαρμογή του χρήστη από τα οποία θα αναγνωριστεί το αντικείμενο (προαιρετικό) o coords: οι συντεταγμένες του παίκτη (προαιρετικό) o login_token: το κλειδί του χρήστη για επιβεβαίωση χρήστη o session_token: το κλειδί της συνεδρίας για επιβεβαίωση ότι ο χρήστης ανήκει στη συνεδρία και μπορεί κάνει την πράξη Έξοδοι στο πεδίο status : o 2 σφάλμα: το πεδίο session_id που στάλθηκε είναι κενό o 3 σφάλμα: το πεδίο username που στάλθηκε είναι κενό o 4 σφάλμα: το πεδίο login_token που στάλθηκε είναι κενό o 5 σφάλμα: το πεδίο session_token που στάλθηκε είναι κενό o 6 σφάλμα: το πεδίο collectdata που στάλθηκε είναι κενό o 7 σφάλμα: το πεδίο coords που στάλθηκε είναι κενό 81

82 o 8 σφάλμα: το session που στάλθηκε δεν υπάρχει στο σύστημα o 13 σφάλμα : το session δεν είναι στην κατάσταση 1, η πράξη δε μπορεί να γίνει o 9 σφάλμα : ο χρήστης δεν ανήκει στο session o 10 σφάλμα : ο χρήστης δεν υπάρχει στο σύστημα o 11 σφάλμα : το session_token δεν ανήκει σε αυτή τη συνεδρία o 12 σφάλμα : το login_token δεν ανήκει σε αυτόν τον χρήστη o 1 επιτυχής εκτέλεση της onscan() serverdomain :3000/Game/Sessions/lock Η συγκεκριμένη διαδρομή έχει ως στόχο να καλέσει την συνάρτηση onlock() από το module με τους κανόνες του παιχνιδιού. Η διαδρομή αυτή δέχεται παραμέτρους με βάση τους οποίους γίνεται η αντιστοίχιση μιας ετικέτας με ένα αντικείμενο του φυσικού κόσμου. Οι είσοδοι της διαδρομής είναι οι εξής: o session_id: η ταυτότητα της συνεδρίας στην οποία γίνεται η αντιστοίχιση ετικέτας αντικειμένου o username: το όνομα του παίκτη που θέλει να κάνει την πράξη της αντιστοίχισης o object_id: η ταυτότητα του αντικειμένου του φυσικού κόσμου στο οποίο θα αντιστοιχιστεί κάποια ετικέτα o tag_id: η ταυτότητα της ετικέτας την οποία θέλει να αντιστοιχίσει ο χρήστης o login_token: το κλειδί του χρήστη για επιβεβαίωση χρήστη o session_token: το κλειδί της συνεδρίας για επιβεβαίωση ότι ο χρήστης ανήκει στη συνεδρία και μπορεί κάνει την πράξη Έξοδοι στο πεδίο status : o 2 σφάλμα: το πεδίο session_id που στάλθηκε είναι κενό o 3 σφάλμα: το πεδίο username που στάλθηκε είναι κενό o 4 σφάλμα: το πεδίο login_token που στάλθηκε είναι κενό o 5 σφάλμα: το πεδίο session_token που στάλθηκε είναι κενό o 14 σφάλμα: το πεδίο tag_id που στάλθηκε είναι κενό 82

83 o 15 σφάλμα: το πεδίο object_id που στάλθηκε είναι κενό o 8 σφάλμα: το session που στάλθηκε δεν υπάρχει στο σύστημα o 13 σφάλμα: το session δεν είναι στην κατάσταση 1, η πράξη δε μπορεί να γίνει o 9 σφάλμα: ο χρήστης δεν ανήκει στο session o 10 σφάλμα: ο χρήστης δεν υπάρχει στο σύστημα o 11 σφάλμα: το session_token δεν ανήκει σε αυτή τη συνεδρία o 12 σφάλμα: το login_token δεν ανήκει σε αυτόν τον χρήστη o 1 επιτυχής εκτέλεση της onlock() serverdomain :3000/Game/Sessions/unlock Η συγκεκριμένη διαδρομή έχει ως στόχο να καλέσει την συνάρτηση onunlock() από το module με τους κανόνες του παιχνιδιού. Η διαδρομή αυτή δέχεται παραμέτρους με βάση τους οποίους γίνεται η αποσύνδεση μιας ετικέτας από ένα αντικείμενο του φυσικού κόσμου. Οι είσοδοι της διαδρομής είναι οι εξής: o session_id: η ταυτότητα της συνεδρίας στην οποία γίνεται η αντιστοίχιση ετικέτας αντικειμένου o username: το όνομα του παίκτη που θέλει να κάνει την πράξη της αντιστοίχισης o object_id: η ταυτότητα του αντικειμένου του φυσικού κόσμου από το οποίο θα αποσυνδεθεί κάποια ετικέτα o tag_id: η ταυτότητα της ετικέτας την οποία θέλει να αποσυνδέσει από κάποιο αντικείμενο ο χρήστης o login_token: το κλειδί του χρήστη για επιβεβαίωση χρήστη o session_token: το κλειδί της συνεδρίας για επιβεβαίωση ότι ο χρήστης ανήκει στη συνεδρία και μπορεί κάνει την πράξη Έξοδοι στο πεδίο status : o 2 σφάλμα: το πεδίο session_id που στάλθηκε είναι κενό o 3 σφάλμα: το πεδίο username που στάλθηκε είναι κενό o 4 σφάλμα: το πεδίο login_token που στάλθηκε είναι κενό o 5 σφάλμα: το πεδίο session_token που στάλθηκε είναι κενό 83

84 o 14 σφάλμα: το πεδίο tag_id που στάλθηκε είναι κενό o 15 σφάλμα: το πεδίο object_id που στάλθηκε είναι κενό o 8 σφάλμα: το session που στάλθηκε δεν υπάρχει στο σύστημα o 13 σφάλμα: το session δεν είναι στην κατάσταση 1, η πράξη δε μπορεί να γίνει o 9 σφάλμα: ο χρήστης δεν ανήκει στο session o 10 σφάλμα: ο χρήστης δεν υπάρχει στο σύστημα o 11 σφάλμα: το session_token δεν ανήκει σε αυτή τη συνεδρία o 12 σφάλμα: το login_token δεν ανήκει σε αυτόν τον χρήστη o 1 επιτυχής εκτέλεση της onunlock() serverdomain :3000/Game/Sessions/move Η συγκεκριμένη διαδρομή έχει ως στόχο να καλέσει την συνάρτηση onmove() από το module με τους κανόνες του παιχνιδιού. Η διαδρομή αυτή δέχεται παραμέτρους με βάση τις συντεταγμένες ενός παίκτη. Τα δεδομένα για κάποιον παίκτη που περιμένει είναι τα coοrds τα οποία είναι οι συντεταγμένες που βρίσκεται ο παίκτης, όπως φαίνεται παρακάτω. Οι είσοδοι της διαδρομής είναι οι εξής: o session_id: η ταυτότητα της συνεδρίας στην οποία γίνεται η αναγνώριση του αντικειμένου o username: το όνομα του παίκτη που θέλει να κάνει την πράξη της αναγνώρισης o coords: οι συντεταγμένες του παίκτη o login_token: το κλειδί του χρήστη για επιβεβαίωση χρήστη o session_token: το κλειδί της συνεδρίας για επιβεβαίωση ότι ο χρήστης ανήκει στη συνεδρία και μπορεί κάνει την πράξη Έξοδοι στο πεδίο status : o 2 σφάλμα: το πεδίο session_id που στάλθηκε είναι κενό o 3 σφάλμα: το πεδίο username που στάλθηκε είναι κενό o 4 σφάλμα: το πεδίο login_token που στάλθηκε είναι κενό o 5 σφάλμα: το πεδίο session_token που στάλθηκε είναι κενό 84

85 o 7 σφάλμα: το πεδίο coords που στάλθηκε είναι κενό o 8 σφάλμα: το session που στάλθηκε δεν υπάρχει στο σύστημα o 13 σφάλμα: το session δεν είναι στην κατάσταση 1, η πράξη δε μπορεί να γίνει o 9 σφάλμα: ο χρήστης δεν ανήκει στο session o 10 σφάλμα: ο χρήστης δεν υπάρχει στο σύστημα o 11 σφάλμα: το session_token δεν ανήκει σε αυτή τη συνεδρία o 12 σφάλμα: το login_token δεν ανήκει σε αυτόν τον χρήστη o 1 επιτυχής εκτέλεση της onmove() 4.7 Υποστήριξη του MuseumScrabble Αφού λοιπόν εξηγήθηκαν όλες οι βασικές λειτουργίες του εξυπηρετητή, το επόμενο βήμα είναι να μπορεί να υποστηρίξει το πρώτο παιχνίδι με βάση την μοντελοποίηση που περιγράφθηκε στο κεφάλαιο 3. Το παιχνίδι αυτό είναι το αλληλεπιδραστικό MuseumScrabble, οι κανόνες του οποίου είναι γνωστοί από το υποκεφάλαιο Για την αποτελεσματική υποστήριξη του αλληλεπιδραστικού MuseumScrabble, όσον αφορά τις διαδρομές που χρειάζεται το παιχνίδι, οι προκαθορισμένες του εξυπηρετητή είναι αρκετές. Αρχικά λοιπόν δημιουργήθηκε ένα module το οποίο υλοποιεί τους κανόνες του αλληλεπιδραστικού MuseumScrabble εφαρμόζοντας την μοντελοποίηση που αναλύθηκε στο υποκεφάλαιο Το module αυτό ονομάζεται ms_ruleset.js και αφού δημιουργήθηκε, τοποθετήθηκε στον φάκελο rulesets, ο οποίος αποτελεί επεκτάσιμο κομμάτι του εξυπηρετητή, όπως αναλύθηκε στο υποκεφάλαιο 4.1. Όσον αφορά το περιεχόμενο του module, χρειάστηκαν να δημιουργηθούν συναρτήσεις που συνδέονται με τις πράξεις κάποιου παίκτη σστο παιχνίδι. Οι δύο βασικές συναρτήσεις που πρέπει να περιέχει, όπως αναφέρθηκε στο υποκεφάλαιο 4.6.1, είναι η oninit() και η onend(). Στην oninit() ο κώδικάς που περιέχεται κάνει την αρχικοποίηση του κουβά που περιέχει όλες τις ετικέτες 85

86 της συνεδρίας, των πεδίων ορατότητας κάθε παίκτη και των καλαθιών των αντικειμένων. Στην onend() ο κώδικάς που περιέχεται υπολογίζει τον νικητή της συνεδρίας, που σύμφωνα με τους κανόνες του MuseumScrabble είναι αυτός που έχει μαζέψει τους περισσότερους πόντους. Αφού αναλύθηκαν οι δύο συναρτήσεις που δεν μπορούν να λείπουν από το module τώρα θα γίνει αναφορά στις συναρτήσεις που σχετίζονται με τις πράξεις των παικτών. Σύμφωνα με την εφαρμογή της μοντελοποίησης στο αλληλεπιδραστικό MuseumScrabble που αναλύθηκε στο υποκεφάλαιο 3.8.1, οι βασικές πράξεις είναι η αναγνώριση ενός αντικειμένου, η αντιστοίχιση μιας ετικέτας από τον κουβά με κάποιο αντικείμενο στον φυσικό χώρο και η αποσύνδεση μιας ετικέτας από κάποιο αντικείμενο. Αυτές οι τρεις πράξεις εξυπηρετούνταν μέσω των συναρτήσεων onscan(), onlock() και onunlock(). Η αναγνώριση του αντικειμένου γίνεται σκανάροντας το QRcode πάνω σε κάποιο αντικείμενο. Όταν γίνεται αυτή η πράξη, στέλνεται αίτημα POST στη διαδρομή serverdomain :3000/Game/Sessions/scan και εκτελείται η συνάρτηση onscan(). Η συνάρτηση αυτή εισάγει το αντικείμενο που αναγνωρίστηκε στο πεδίο ορατότητας του παίκτη. Τέλος μέσω των onlock() και onunlock() γίνεται η μεταφορά των ετικετών από τον κουβά σε κάποιο καλάθι ενός αντικειμένου όταν κάποιος παίκτης κάνει κάποια αντιστοίχιση και το ανάποδο αντίστοιχα. Οι διαδρομές για το onlock() είναι η serverdomain :3000/Game/Sessions/lock και για το onunlock() η serverdomain :3000/Game/Sessions/unlock. Έτσι με αυτές τις 5 συναρτήσεις, εφαρμόζοντας τη μοντελοποίηση που έγινε στο κεφάλαιο 3, η υποστήριξη του αλληλεπιδραστικού MuseumScrabble πραγματοποιείται επιτυχώς. 4.8 Υποστήριξη του Taggling Η δεύτερη εφαρμογή που υλοποιήθηκε ήταν με τη σειρά της η δημιουργία κατάλληλου module για την υποστήριξη του αλληλεπιδραστικού Taggling. Το Taggling, όπως είναι γνωστό από την περιγραφή του στο υποκεφάλαιο 3.2.2, 86

87 ανήκει στην ίδια κατηγορία παιχνιδιών με το MuseumScrabble αλλά οι κανόνες του είναι διαφορετικοί. Παρακάτω περιγράφεται αναλυτικά ο τρόπος που πραγματοποιήθηκε η υποστήριξή του από τον επεκτάσιμο εξυπηρετητή. Σε πρώτο στάδιο το Taggling έχει δικά του δεδομένα καθώς δεν χρησιμοποιεί τις ετικέτες και τα αντικείμενα του MuseumScrabble. Ο πρώτος στόχος λοιπόν είναι να βρεθεί ένας τρόπος να περαστούν τα δεδομένα του χρησιμοποιώντας της δυνατότητες του επεκτάσιμου εξυπηρετητή. Για να γίνει αυτό δημιουργήθηκε ένα αρχείο javascript το οποίο περιέχει μια νέα διαδρομή (route) για τον server και τοποθετείται στο φάκελο custom_routes, ο οποίος είναι ένα επεκτάσιμο κομμάτι του εξυπηρετητή όπως αναλύθηκε στο υποκεφάλαιο 4.1. Μέσω της νέας αυτής διαδρομής εισάγονται τα δεδομένα του Taggling. Η διαδρομή είναι server_domain /taggling/create_database και καλείται με μέθοδο GET. Επίσης τα δεδομένα του Taggling για τις ετικέτες και τα αντικείμενα είναι πλέον διαθέσιμα στον εξυπηρετητή μέσω ενός JSON αρχείου που τοποθετείται στο φάκελο public. Θα μπορούσε βέβαια να αντλεί τα δεδομένα και από εξωτερικό χώρο εκτός του χώρου του εξυπηρετητή, αλλά χρησιμοποιήθηκε η συγκεκριμένη υλοποίηση. Αφού πλέον ο εξυπηρετητής έχει τα δεδομένα του νέου παιχνιδιού, το μόνο που μένει είναι το module με τους κανόνες του Taggling. Για τους κανόνες του Taggling δημιουργήθηκε το αρχείο taggling_v1_ruleset.js το οποίο τοποθετείται στον φάκελο rulesets. Στο module αυτό δημιουργήθηκαν οι συναρτήσει oninit() και onend() που πρέπει πάντα να περιέχονται. Η πρώτη, όταν ξεκινήσει το παιχνίδι, αρχικοποιεί το σακούλι κάθε παίκτη και το καλάθι κάθε αντικειμένου. Η δεύτερη υπολογίζει τον νικητή όταν λήξει το παιχνίδι και σύμφωνα με τους κανόνες του Taggling (υποκεφάλαιο 3.2.2) νικητής είναι αυτός με τους περισσότερους πόντους. Αφού αναλύθηκαν οι συναρτήσεις που αφορούν την αρχικοποίηση και το τέλος του παιχνιδιού, τώρα θα γίνει αναφορά στις συναρτήσεις που αφορούν τις πράξεις των παικτών. Σύμφωνα με την εφαρμογή της μοντελοποίησης στο αλληλεπιδραστικό Taggling που αναλύθηκε στο υποκεφάλαιο 3.8.2, οι βασικές 87

88 πράξεις είναι η αναγνώριση ενός αντικειμένου, η αντιστοίχιση μιας ετικέτας από το σακούλι ενός παίκτη στο καλάθι ενός αντικειμένου και η αποσύνδεση μιας ετικέτας από το καλάθι ενός αντικειμένου. Αυτές οι τρεις πράξεις εξυπηρετούνται μέσω των συναρτήσεων onscan(), onlock() και onunlock(). Η αναγνώριση του αντικειμένου γίνεται σκανάροντας το QRcode πάνω σε κάποιο αντικείμενο, όπως και στο MuseumScrabble. Τα δεδομένα της αναγνώρισης τα διαχειρίζεται η onscan() και προσθέτει στο πεδίο ορατότητας του παίκτη το νέο αντικείμενο που αναγνώρισε. Τέλος μέσω των onlock() και onunlock() γίνεται η μεταφορά των ετικετών από το σακούλι του παίκτη που έκανε την αντιστοίχιση στο καλάθι του αντικειμένου και το ανάποδο αντίστοιχα. Οι διαδρομές που ενεργοποιούν τις συναρτήσεις αυτές είναι αυτές που χρησιμοποιήθηκαν στο υποκεφάλαιο 4.6. Έτσι εξυπηρετούνται αποτελεσματικά όλες οι πράξεις του παιχνιδιού και το παιχνίδι μπορεί πλέον να εξυπηρετηθεί. 88

89 89

90 5 Αξιολόγηση Στο κεφάλαιο 4 έγινε αποτελεσματικά η ανάπτυξη του επεκτάσιμου εξυπηρετητή εφαρμόζοντας την μοντελοποίηση που αναλύθηκε στο κεφάλαιο 3. Ο εξυπηρετητής πλέον μπορεί να υποστηρίξει δύο παιχνίδια, τα οποία είναι το αλληλεπιδραστικό MuseumScrabble και το αλληλεπιδραστικό Taggling. Το τελευταίο που μένει να γίνει με τον επεκτάσιμο εξυπηρετητή είναι η αξιολόγησή του. Η αξιολόγηση του επεκτάσιμου εξυπηρετητή θα πραγματοποιηθεί αξιολογώντας δύο βασικά χαρακτηριστικά του. Το πρώτο έχει να κάνει με το κομμάτι της επεκτασιμότητάς του. Θα γίνει δηλαδή αξιολόγηση για το αν μπορεί να εξυπηρετηθεί, με βάση την μοντελοποίηση του κεφαλαίου 3, ένα νέο παιχνίδι. Με τον τρόπο αυτόν θα γίνει η αξιολόγηση της επεκτασιμότητας του εξυπηρετητή. Το νέο παιχνίδι είναι το UoP GO, ανήκει στην κατηγορία των παιχνιδιών που περιγράφθηκαν στο υποκεφάλαιο 2.1 και η περιγραφή του παρουσιάζεται στη συνέχεια. Η αξιολόγηση που θα γίνει είναι αν μπορεί να δημιουργηθεί ένα κατάλληλο module, το οποίο θα περιέχει τους κανόνες του UoP GO και με βάση αυτό να μπορεί στη συνέχεια να υποστηρίζει το παιχνίδι ο εξυπηρετητής. Το δεύτερο χαρακτηριστικό που θα αξιολογηθεί αφορά το φορτίο που μπορεί να υποστηρίξει ως εξυπηρετητής. Για να γίνει αυτό, ο εξυπηρετητής θα υποβληθεί σε δοκιμές φόρτου (stress tests) με τη χρήση ενός εργαλείου, του artillery.io. Το συγκεκριμένο εργαλείο, όπως περιγράφεται πιο αναλυτικά στη συνέχεια, δημιουργεί φορτίο κίνησης που το ρυθμίζει ο προγραμματιστής και με βάση αυτό εξάγει αποτελέσματα που έχουν σχέση με την απόκριση του εξυπηρετητή σε μεγάλο αριθμό αιτημάτων που δέχεται. 5.1 Πρώτη αξιολόγηση Αξιολόγηση επεκτασιμότητας Πλέον έχει γίνει ολοκληρωμένα η υλοποίηση της μοντελοποίησης που περιγράφθηκε στο κεφάλαιο 3 για να υποστηριχτούν τα παιχνίδια MuseumScrabble και Taggling από τον εξυπηρετητή. Το κρίσιμο ερώτημα 90

91 είναι αν μπορεί ο επεκτάσιμος αυτός εξυπηρετητής να υποστηρίξει ένα νέο παιχνίδι αυτής της κατηγορίας παιχνιδιών. Το νέο παιχνίδι είναι το UoP GO Σύντομη περιγραφή του UoP GO Το UoPGO είναι ένα παιχνίδι που ανήκει στην κατηγορία παιχνιδιών που αναλύθηκε στο υποκεφάλαιο 3.2. Είναι ένα παιχνίδι που παίζεται σε φυσικό χώρο και συγκεκριμένα στον χώρο του Πανεπιστημίου Πατρών. Η εφαρμογή είναι σχετικά απλή ως προς τη λειτουργία της. Αρχικά όταν ο χρήστης ανοίγει την εφαρμογή μέσω της φορητής του συσκευής του εμφανίζεται μια φόρμα συμπλήρωσης μέσω της οποίας πραγματοποιεί εγγραφή στο σύστημα, όπως φαίνεται παρακάτω στην Εικόνα 32. Εικόνα 32: Εγγραφή χρήστη στο UoP GO Αφού λοιπόν ο χρήστης κάνει εγγραφή στο σύστημα μπαίνει κατευθείαν στο παιχνίδι όπου βλέπει στην οθόνη της φορητής του συσκευής μέσω της εφαρμογής την τοποθεσία του στο χάρτη. Αυτό που δεν μπορεί να δει στον χάρτη είναι οι τοποθεσίες των αντικειμένων που στη περίπτωση του UoP GO είναι ιστορικά μέρη του Πανεπιστημίου Πατρών. Η εικόνα που έχει ο χρήστης όταν μπαίνει στο παιχνίδι φαίνεται στην Εικόνα

92 Εικόνα 33: Διεπαφή χρήστη στο UoP GO Στόχος του χρήστη στο παιχνίδι είναι να κινείται στο χώρο του Πανεπιστημίου Πατρών και να ψάξει να βρει τα αντικείμενα στον χώρο. Όταν βρεθεί σε κάποια επιτρεπτή απόσταση από κάποιο αντικείμενο, που ορίζεται από την εφαρμογή, του εμφανίζεται κάποια ερώτηση που σχετίζεται με αυτό. Η ερώτηση είναι τύπου πολλαπλής επιλογής. Κάθε αντικείμενο έχει κάποιον αριθμό ερωτήσεων που σχετίζονται με αυτό και όταν κάποιος χρήστης το πλησιάσει του εμφανίζεται με τυχαίο τρόπο μία από αυτές. Ανάλογα με το αν ο χρήστης απαντάει σωστά ή λάθος κερδίζει ή χάνει εμπειρία και νικητής είναι αυτός που θα τερματίσει τη συνεδρία έχοντας μαζέψει την περισσότερη. Η εμπειρία που έχει κάποιος χρήστης φαίνεται παρακάτω στην Εικόνα

93 Εικόνα 34: Εμπειρία χρήστη κατά την διάρκεια της συνεδρίας Εφαρμογή της μοντελοποίηση στο UoP GO Για να μπορέσει να υποστηριχτεί το UoP GO από τον επεκτάσιμο εξυπηρετητή θα πρέπει να εφαρμοστεί αρχικά η μοντελοποίηση που έγινε στο κεφάλαιο 3. Εφαρμόζοντας τη μοντελοποίηση αρχικά πρέπει να ορίσουμε τις βασικές οντότητες. Τα αντικείμενα του φυσικού κόσμου είναι τα ιστορικά μνημεία του Πανεπιστημίου Πατρών. Όσον αφορά τις ετικέτες ορίζονται οι ερωτήσεις του αντικειμένου και γίνεται η θεώρηση ότι είναι αντιστοιχισμένες στα αντικείμενα στα οποία ανήκουν. Έτσι όταν ένας χρήστης πλησιάσει ένα αντικείμενο θα του εμφανίζεται μία από τις ετικέτες-ερωτήσεις που υπάρχουν στο καλάθι του αντικειμένου. Από τους βασικούς χώρους αποθήκευσης ετικετών που περιγράφθηκαν στο υποκεφάλαιο 3.6 θα χρησιμοποιηθούν το σακούλι και το καλάθι. Το σακούλι χρησιμοποιείται για να γνωρίζει ο εξυπηρετητής ποιες ερωτήσεις-ετικέτες έχει κάποιο αντικείμενο και το σακούλι για να ξέρει σε ποιες ερωτήσεις έχει απαντήσει κάποιος παίκτης, είτε σωστά είτε λάθος, ώστε να μην του ξαναεμφανιστούν στο μέλλον. Ο κουβάς δεν χρειάζεται 93

94 στην μοντελοποίηση αυτή καθώς δεν υπάρχει κάποιος δημόσιος χώρος για τις ετικέτες. Όσον αφορά το πεδίο ορατότητας κάποιου παίκτη δεν είναι απαραίτητο να υπάρχει γιατί η αλληλεπίδραση με το αντικείμενο τελειώνει με το που απαντήσει σε κάποια ερώτηση ο παίκτης. Με βάση την παραπάνω μοντελοποίηση μπορεί να εξυπηρετηθεί το UoP GO. Τώρα το μόνο που μένει είναι η υλοποίησή της σε κώδικα με ένα νέο module ώστε να δοθούν στον επεκτάσιμο εξυπηρετητή οι κανόνες του παιχνιδιού Υλοποίηση του UoP GO Σε επόμενο βήμα, για την επιτυχής υποστήριξη του UoPGO από τον εξυπηρετητή πρέπει να δοθούν οι κανόνες του σε αυτόν. Σε πρώτη φάση πρέπει να αποκτήσει ο εξυπηρετητής τα δεδομένα του νέου παιχνιδιού και σε επόμενο στάδιο το module με τους κανόνες του. Για το κομμάτι της βάσης δεδομένων, για να μπορέσει ο εξυπηρετητής να αποκτήσει τα δεδομένα του UoP GO δημιουργήθηκε μια νέα διαδρομή στον εξυπηρετητή. Η νέα αυτή διαδρομή, όπως και στις περιπτώσεις του MuseumScrabble και του Taggling που αναλύθηκαν στα υποκεφάλαια 4.7 και 4.8, τοποθετείται στο φάκελο custom_routes στην τοποθεσία (directory) του εξυπηρετητή στον υπολογιστή. Πλέον στέλνοντας ένα αίτημα GET σε αυτήν τη διαδρομή (route) περνάνε τα νέα δεδομένα του UoP GO στον εξυπηρετητή. Η διαδρομή είναι η server_domain /up_go/create_database. Σε επόμενο στάδιο πρέπει να γίνει ανάλυση για το module που θα έχει τους κανόνες του παιχνιδιού. Οι κανόνες του UoP GO, οι οποίοι αναλύθηκαν στο υποκεφάλαιο 5.1.1, είναι λίγοι οπότε είναι αναμενόμενο ότι οι προκαθορισμένες συναρτήσεις του εξυπηρετητή (υποκεφάλαιο 4.6.2) αρκούν για την υποστήριξή του. Αρχικά οι δύο συναρτήσεις που πρέπει να υπάρχουν σε κάθε module, η oninit() και η onend() θα υπάρχουν και σε αυτό. Η oninit() όταν ξεκινάει η συνεδρία θα αρχικοποιεί το σακούλι κάθε παίκτη και την αρχική εμπειρία των παικτών. Η onend() θα αναλάβει τον υπολογισμό του 94

95 νικητή της συνεδρίας, που είναι ο παίκτης που έχει μαζέψει την περισσότερη εμπειρία. Από τις υπόλοιπες η onscan() χρησιμοποιείται για να ελέγχει τις συντεταγμένες της τοποθεσίας κάποιου παίκτη και όταν βρεθεί σε κάποιο αντικείμενο κοντά θα το ανιχνεύει και θα του επιστρέφει κάποια ερώτηση. Η δεύτερη και τελευταία συνάρτηση του module που χρειάζεται για να ολοκληρωθεί η υποστήριξη του παιχνιδιού είναι η onlock() η οποία θα παίρνει την απάντηση του παίκτη, θα ελέγχει αν είναι σωστή ή λάθος και θα την καταχωρεί στο σακούλι του παίκτη ώστε να μην του ξαναερωτηθεί στη συνεδρία. Επίσης θα κάνει και τον υπολογισμό της εμπειρίας του παίκτη. Οι διαδρομές που χρησιμοποιούνται για αυτές τις συναρτήσεις έχουν αναλυθεί στο υποκεφάλαιο Το UoP GO μπορεί πλέον να υποστηριχτεί από τον εξυπηρετητή αποτελεσματικά. Το γεγονός ότι ανήκει στην κατηγορία των παιχνιδιών με βάση τα οποία σχεδιάστηκε ο εξυπηρετητής έκαναν την μοντελοποίησή του πιο εύκολη. Πλέον ανήκει στα παιχνίδια του εξυπηρετητή και οι συνεδρίες του UoP GO μπορούν από εδώ και πέρα να υποστηριχτούν. Τα αποτελέσματα της πρώτης αξιολόγησης επιβεβαιώνουν ότι ο εξυπηρετητής είναι επεκτάσιμος και ότι μπορεί να υποστηρίξει νέα παιχνίδια στα οποία μπορεί να εφαρμοστεί η μοντελοποίηση του κεφαλαίου Δεύτερη αξιολόγηση - Δοκιμές φορτίου κίνησης Στην δεύτερη αξιολόγηση που θα γίνει στον επεκτάσιμο εξυπηρετητή θα αξιολογηθεί το μέγιστο φορτίο κίνησης που μπορεί να υποστηρίξει. Θα γίνει δηλαδή προσομοίωση αποστολής αιτημάτων στον εξυπηρετητή με αυξανόμενο ρυθμό μέχρι το σημείο που δεν θα μπορεί να αποκριθεί σε νέα αιτήματα. Η προσομοίωση αυτή θα γίνει με τη χρήση του εργαλείου artillery.io Εργαλείο δεύτερης αξιολόγησης artillery.io Το artillery.io είναι ένα εργαλείο παραγωγής φορτίου κίνησης γραμμένο σε Nodejs. Δίνει τη δυνατότητα σε κάποιον προγραμματιστή να μπορέσει να πραγματοποιήσει δοκιμές πάνω σε έναν εξυπηρετητή του με στόχο να 95

96 εμφανίστουν οι αδυναμίες του. Οι αδυναμίες αυτές έχουν να κάνουν με τον χρόνο απόκρισής του και με τον αριθμό αιτημάτων που μπορεί να εξυπηρετήσει όταν δέχεται μεγάλο αριθμό αιτημάτων. Ο προγραμματιστής μπορεί να δημιουργεί εικονικούς χρήστες και να τους βάζει να πραγματοποιούν αποστολή αιτημάτων σε διαδρομές του εξυπηρετητή με διάφορους ρυθμούς. Έχει τη δυνατότητα να δημιουργεί φάσεις στην δοκιμή του οι οποίες υλοποιούνται με τη σειρά και η καθεμιά δίνει όλο και περισσότερο φορτίο στον εξυπηρετητή πραγματοποιώντας έτσι δοκιμές φόρτου (stress tests) σε αυτόν. Για παράδειγμα μία δοκιμή γραμμένη σε artillery.io θα μπορούσε να έχει 3 φάσεις όπου η πρώτη θα είχε 5 εικονικούς χρήστες, η δεύτερη 20 και η τρίτη 100 και η καθεμιά θα δίνει κίνηση σε διαδρομές του εξυπηρετητή. Έτσι με έναν τέτοιο τρόπο μπορεί κάποιος να εξετάσει τα άκρα της εφαρμογής του, δηλαδή μετά από ποιον αριθμό αιτημάτων αρχίζει να μην απαντάει σε νέα αιτήματα, ποιος είναι ο μέσος χρόνος για να απαντήσει σε ένα αίτημα, έτσι ώστε να βγάλει κάποια στατιστικά συμπεράσματα για αυτόν. Το script το οποίο περιγράφει τη δοκιμή η οποία θα γίνει πάνω στην εφαρμογή έχει συγκεκριμένη δομή. Αποτελείται από δύο πεδία τα οποία προσδιορίζουν τον τρόπο που θα λειτουργήσει η δοκιμή. Το πρώτο είναι το κομμάτι config στο οποίο προσδιορίζεται ο στόχος (URI) στον οποίο θα στέλνονται τα αιτήματα, οι εικονικοί χρήστες, ο ρυθμός με τον οποίο θα στέλνουν αιτήματα και γενικότερα παράμετροι που θέλει να εισάγει κάποιος προγραμματιστής. Το δεύτερο κομμάτι είναι το scenarios στο οποίο προσδιορίζεται το τι ενέργειες θα κάνουν οι εικονικοί χρήστες που έχουν οριστεί στο κομμάτι config. Παρακάτω παρουσιάζεται ένα απλό παράδειγμα μιας δοκιμής γραμμένο σε artillery.io για την κατανόηση του τρόπου γραφής του. Το παράδειγμα βρίσκεται στο link της ιστοσελίδας του documentation του artillery.io. 96

97 Εικόνα 35: Παράδειγμα κώδικα σε artillery.io Πιο αναλυτικά στο παραπάνω παράδειγμα αρχικά στο κομμάτι config προσδιορίζεται ο στόχος στον οποίο θα γίνει η δοκιμή που είναι το Στη δοκιμή υπάρχει μία φάση η οποία διαρκεί ένα λεπτό στην οποία συμμετέχουν είκοσι εικονικούς χρήστες. Στα αιτήματά τους, στην επικεφαλίδα τους συγκεκριμένα έχει οριστεί και μια προκαθορισμένη τιμή για το πεδίο x-my-service-auth. Στη συνέχεια στο κομμάτι scenarios θα εκτελείται ένα σενάριο στο οποίο οι εικονικοί χρήστες θα στέλνουν αιτήματα στη διαδρομή με μέθοδο GET Εφαρμογή artillery.io στον επεκτάσιμο εξυπηρετητή Αφού έγινε η επεξήγηση του artillery.io με το οποίο θα γίνει η αξιολόγηση του φορτίου που υποστηρίζει ο επεκτάσιμος εξυπηρετητής, τώρα θα γίνει αναλυτική περιγραφή των δοκιμών που θα γίνουν. Για την αξιολόγηση του φορτίου κίνησης του εξυπηρετητή θα γίνουν τρεις δοκιμές σε καθένα από τα παιχνίδια που υποστηρίζονται από αυτόν. Στο πρώτο θα γίνει η προσομοίωση μιας συνεδρίας του MuseumScrabble. Θα δημιουργηθούν στη συνεδρία εικονικοί χρήστες και θα υλοποιούν σενάρια με τα δεδομένα του παιχνιδιού, δηλαδή αναγνωρίσεις αντικειμένων, αντιστοιχίσεις ετικετών-αντικειμένων και αποσυνδέσεις αντίστοιχα. Με παρόμοιο τρόπο θα γίνει το ίδιο και για το Taggling και το UoP GO. 97

98 Σε κάθε δοκιμή θα υπάρχουν τρεις φάσεις και σε καθε μία θα υπάρχει αυξανόμενη κίνηση ώστε να φτάσει ο εξυπηρετητής στα άκρα του, όπως περιγράφθηκαν προηγουμένως στο υποκεφάλαιο Ο λόγος που επιλέγονται αυτές οι 3 δοκιμές, μία για κάθε παιχνίδι, είναι για να δοκιμαστούν όλα τα παιχνίδια που υποστηρίζει ο εξυπηρετητής και να εξεταστεί η απόκρισή του στο καθένα. Παρακάτω σε κάθε δοκιμή υλοποιούνται τρεις φάσεις όπου κάθε μία έχει διαφορετικό αριθμό χρηστών ως αφετηρία. Επιλέχτηκαν συγκεκριμένα τρεις φάσεις, όπου η τρίτη έχει 100 εικονικούς χρήστες ως αφετηρία, γιατί μετά από συνεχόμενες δοκιμές οι πρώτες αρνήσεις (rejects) αιτημάτων παρουσιάστηκαν όταν η αφετηρία ήταν 100 χρήστες. Για πιο μικρό αριθμό αφετηρίας ο εξυπηρετητής απαντούσε αποτελεσματικά σε όλα τα αιτήματα. Επομένως επιλέγεται ως τελευταίο σενάριο το όριο αυτό Πρώτη δοκιμή-συνεδρία MuseumScrabble Στην πρώτη δοκιμή θα δημιουργηθεί μία συνεδρία στην οποία θα παίζεται το παιχνίδι αλληλεπιδραστικό MuseumScrabble και θα γίνει μια προσομοίωση του παιχνιδιού με αυξανόμενη κίνηση από αιτήματα στον επεκτάσιμο εξυπηρετητή. Ο κώδικας (script) ο οποίος θα υλοποιήσει τη συγκεκριμένη δοκιμή παρουσιάζεται παρακάτω. Το κομμάτι του config είναι το εξής: 98

99 Εικόνα 36: Κώδικας για την 1η δοκιμή στη συνεδρία MuseumScrabble Στο τεστ θα υπάρχουν τρεις φάσεις όπως φαίνεται στην Εικόνα 36. Η πρώτη φάση θα διαρκεί ένα λεπτό και θα ξεκινά με 10 εικονικούς χρήστες. Η δεύτερη φάση θα ξεκινά με 30 εικονικούς χρήστες για 1 λεπτό και τέλος η Τρίτη με 100 για δύο λεπτά. Όσο κάθε φάση τρέχει, ο αριθμός των χρηστών θα αυξάνεται εκθετικά. Στο κομμάτι payload ορίζονται τα αρχεία.csv από τα οποία θα αντλούν οι εικονικοί χρήστες τα δεδομένα τα οποία έχουν νόημα για το συγκεκριμένο παιχνίδι για να διαμορφώνουν τα αιτήματά τους. Στη συνέχεια παρουσιάζονται τα σενάρια τα οποία θα εκτελούν οι εικονικοί χρήστες, δηλαδή το κομμάτι κώδικα scenarios. 99

100 Εικόνα 37: Κώδικας τμήματος 'scenarios' της 1ης δοκιμής Στο κομμάτι scenarios ορίζονται οι διαδρομές στις οποίες θα στέλνουν τα αιτήματα οι εικονικοί χρήστες. Οι διαδρομές αυτές είναι γνωστές από το υποκεφάλαιο 4.7. Τα αιτήματα στέλνονται με μέθοδο POST, έχουν δομή JSON και το περιεχόμενό τους αντλείται από τα.csv αρχεία τα οποία ορίστηκαν προηγουμένως. Το επόμενο βήμα, αφού έχει οριστεί η δομή της δοκιμής που θα πραγματοποιηθεί, είναι η εφαρμογή της στον εξυπηρετητή. Αφού έτρεξε η παραπάνω δοκιμή και ολοκληρώθηκε, παρουσιάζονται τα αποτελέσματά του που φαίνονται παρακάτω στην Εικόνα

101 Εικόνα 38: Αποτελέσματα 1ης δοκιμής Παρακάτω δίνονται οργανωμένα τα αποτελέσματα της πρώτης δοκιμής από τη συνεδρία MuseumScrabble. Γενικά αποτελέσματα αναφοράς Αριθμός σεναρίων που ξεκίνησαν Αριθμός σεναρίων που 6083 ολοκληρώθηκαν επιτυχώς Ποσοστό επιτυχών σεναρίων 48,16% Αριθμός αιτημάτων που στάλθηκαν Αριθμός αιτημάτων που απαντήθηκαν επιτυχώς Αριθμός εξυπηρετημένων αιτημάτων (ανα δευτερόλεπτο) Τώρα παρουσιάζονται οι χρόνοι όσον αφορά τα αιτήματα στα οποία απάντησε ο εξυπηρετητής. 101

102 Αποτελέσματα χρόνων αιτημάτων πρώτης δοκιμής Ελάχιστος χρόνος απάντησης ενός 4.3 ms αιτήματος Μέγιστος χρόνος απάντησης ενός ms αιτήματος Μέσος χρόνος απάντησης αιτημάτων ms Χρόνος που απαντήθηκε το 95% των ms αιτημάτων Χρόνος που απαντήθηκε το 99% των ms αιτημάτων Τώρα παρουσιάζονται οι χρόνοι όσον αφορά τα σενάρια στα οποία απάντησε ο εξυπηρετητής. Αποτελέσματα χρόνων σεναρίων πρώτης δοκιμής Ελάχιστος χρόνος απάντησης ενός 40.3 ms σεναρίου Μέγιστος χρόνος απάντησης ενός ms σεναρίου Μέσος χρόνος απάντησης σεναρίου ms Χρόνος που απαντήθηκε το 95% των ms αιτημάτων Χρόνος που απαντήθηκε το 99% των ms αιτημάτων Αυτά είναι τα στατιστικά αποτελέσματα από το πρώτο τεστ που υλοποιήθηκε στον εξυπηρετητή. 102

103 5.2.4 Δεύτερη δοκιμή-συνεδρία Taggling Στη δεύτερη δοκιμή θα δημιουργηθεί μία συνεδρία στην οποία θα παίζεται το παιχνίδι αλληλεπιδραστικό Taggling και θα γίνει μια προσομοίωση του παιχνιδιού με αυξανόμενη κίνηση από αιτήματα στον επεκτάσιμο εξυπηρετητή. Ο κώδικας (script) ο οποίος θα υλοποιήσει τη συγκεκριμένη δοκιμή παρουσιάζεται παρακάτω. Το κομμάτι του config είναι το εξής: Εικόνα 39: Κώδικας 'config' 2ης δοκιμής Στο τεστ θα υπάρχουν τρεις φάσεις όπως φαίνεται στην Εικόνα 39. Η πρώτη φάση θα διαρκεί ένα λεπτό και θα ξεκινά με 10 εικονικούς χρήστες. Η δεύτερη φάση θα ξεκινά με 30 εικονικούς χρήστες για 1 λεπτό και τέλος η Τρίτη με 100 για δύο λεπτά. Όσο κάθε φάση τρέχει, ο αριθμός των χρηστών θα αυξάνεται εκθετικά. Στο κομμάτι payload ορίζονται τα αρχεία.csv από τα οποία θα αντλούν οι εικονικοί χρήστες τα δεδομένα τα οποία έχουν νόημα για το συγκεκριμένο παιχνίδι για να διαμορφώνουν τα αιτήματά τους. Στη συνέχεια παρουσιάζονται τα σενάρια τα οποία θα εκτελούν οι εικονικοί χρήστες, δηλαδή το κομμάτι κώδικα scenarios. 103

104 Εικόνα 40: Κώδικας 'scenarios' της 2ης δοκιμής Στο κομμάτι scenarios ορίζονται οι διαδρομές στις οποίες θα στέλνουν τα αιτήματα οι εικονικοί χρήστες. Οι διαδρομές αυτές είναι γνωστές από το υποκεφάλαιο 4.7. Τα αιτήματα στέλνονται με μέθοδο POST, έχουν δομή JSON και το περιεχόμενό τους αντλείται από τα.csv αρχεία τα οποία ορίστηκαν προηγουμένως. Το επόμενο βήμα, αφού έχει οριστεί η δομή της δοκιμής που θα πραγματοποιηθεί, είναι η εφαρμογή της στον εξυπηρετητή. Αφού έτρεξε η παραπάνω δοκιμή και ολοκληρώθηκε, παρουσιάζονται τα αποτελέσματά του που φαίνονται παρακάτω στην Εικόνα

105 Εικόνα 41: Αποτέσματα 2ης δοκιμής Παρακάτω δίνονται οργανωμένα τα αποτελέσματα της δεύτερης δοκιμής από τη συνεδρία Taggling. Γενικά αποτελέσματα αναφοράς Αριθμός σεναρίων που ξεκίνησαν Αριθμός σεναρίων που 5559 ολοκληρώθηκαν επιτυχώς Ποσοστό επιτυχών σεναρίων 44,01% Αριθμός αιτημάτων που στάλθηκαν Αριθμός αιτημάτων που απαντήθηκαν επιτυχώς Αριθμός εξυπηρετημένων αιτημάτων (ανα δευτερόλεπτο) Τώρα παρουσιάζονται οι χρόνοι όσον αφορά τα αιτήματα στα οποία απάντησε ο εξυπηρετητής. 105

106 Αποτελέσματα χρόνων αιτημάτων πρώτης δοκιμής Ελάχιστος χρόνος απάντησης ενός 4.3 ms αιτήματος Μέγιστος χρόνος απάντησης ενός ms αιτήματος Μέσος χρόνος απάντησης αιτημάτων ms Χρόνος που απαντήθηκε το 95% των ms αιτημάτων Χρόνος που απαντήθηκε το 99% των ms αιτημάτων Τώρα παρουσιάζονται οι χρόνοι όσον αφορά τα σενάρια στα οποία απάντησε ο εξυπηρετητής. Αποτελέσματα χρόνων σεναρίων πρώτης δοκιμής Ελάχιστος χρόνος απάντησης ενός 39.7 ms σεναρίου Μέγιστος χρόνος απάντησης ενός ms σεναρίου Μέσος χρόνος απάντησης σεναρίου ms Χρόνος που απαντήθηκε το 95% των ms αιτημάτων Χρόνος που απαντήθηκε το 99% των ms αιτημάτων Αυτά είναι τα στατιστικά αποτελέσματα από το δεύτερο τεστ που υλοποιήθηκε στον εξυπηρετητή. 106

107 5.2.5 Τρίτη δοκιμή-συνεδρία UoP GO Στην τρίτη και τελευταία δοκιμή θα δημιουργηθεί μία συνεδρία στην οποία θα παίζεται το παιχνίδι UoP GO και θα γίνει μια προσομοίωση του παιχνιδιού με αυξανόμενη κίνηση από αιτήματα στον επεκτάσιμο εξυπηρετητή. Ο κώδικας (script) ο οποίος θα υλοποιήσει τη συγκεκριμένη δοκιμή παρουσιάζεται παρακάτω. Το κομμάτι του config είναι το εξής: Εικόνα 42: Κώδικας 'config' της 3ης δοκιμής Στο τεστ θα υπάρχουν τρεις φάσεις όπως φαίνεται στην Εικόνα 42. Η πρώτη φάση θα διαρκεί ένα λεπτό και θα ξεκινά με 10 εικονικούς χρήστες. Η δεύτερη φάση θα ξεκινά με 30 εικονικούς χρήστες για 1 λεπτό και τέλος η Τρίτη με 100 για δύο λεπτά. Όσο κάθε φάση τρέχει, ο αριθμός των χρηστών θα αυξάνεται εκθετικά. Στο κομμάτι payload ορίζονται τα αρχεία.csv από τα οποία θα 107

108 αντλούν οι εικονικοί χρήστες τα δεδομένα τα οποία έχουν νόημα για το συγκεκριμένο παιχνίδι για να διαμορφώνουν τα αιτήματά τους. Στη συνέχεια παρουσιάζονται τα σενάρια τα οποία θα εκτελούν οι εικονικοί χρήστες, δηλαδή το κομμάτι κώδικα scenarios. Εικόνα 43: Κώδικας 'scenarios' 3ης δοκιμής Στο κομμάτι scenarios ορίζονται οι διαδρομές στις οποίες θα στέλνουν τα αιτήματα οι εικονικοί χρήστες. Οι διαδρομές αυτές είναι γνωστές από το υποκεφάλαιο 4.7. Τα αιτήματα στέλνονται με μέθοδο POST, έχουν δομή JSON και το περιεχόμενό τους αντλείται από τα.csv αρχεία τα οποία ορίστηκαν προηγουμένως. Το επόμενο βήμα, αφού έχει οριστεί η δομή της δοκιμής που θα πραγματοποιηθεί, είναι η εφαρμογή της στον εξυπηρετητή. Αφού έτρεξε η παραπάνω δοκιμή και ολοκληρώθηκε, παρουσιάζονται τα αποτελέσματά του που φαίνονται παρακάτω στην Εικόνα

109 Εικόνα 44: Αποτελέσματα 3ης δοκιμής Παρακάτω δίνονται οργανωμένα τα αποτελέσματα της τρίτης δοκιμής από τη συνεδρία Taggling. Γενικά αποτελέσματα αναφοράς Αριθμός σεναρίων που ξεκίνησαν Αριθμός σεναρίων που 3098 ολοκληρώθηκαν επιτυχώς Ποσοστό επιτυχών σεναρίων 24.52% Αριθμός αιτημάτων που στάλθηκαν Αριθμός αιτημάτων που απαντήθηκαν επιτυχώς Αριθμός εξυπηρετημένων αιτημάτων (ανα δευτερόλεπτο) Τώρα παρουσιάζονται οι χρόνοι όσον αφορά τα αιτήματα στα οποία απάντησε ο εξυπηρετητής. 109

110 Αποτελέσματα χρόνων αιτημάτων πρώτης δοκιμής Ελάχιστος χρόνος απάντησης ενός 4.4 ms αιτήματος Μέγιστος χρόνος απάντησης ενός ms αιτήματος Μέσος χρόνος απάντησης αιτημάτων ms Χρόνος που απαντήθηκε το 95% των ms αιτημάτων Χρόνος που απαντήθηκε το 99% των ms αιτημάτων Τώρα παρουσιάζονται οι χρόνοι όσον αφορά τα σενάρια στα οποία απάντησε ο εξυπηρετητής. Αποτελέσματα χρόνων σεναρίων πρώτης δοκιμής Ελάχιστος χρόνος απάντησης ενός 26.5 ms σεναρίου Μέγιστος χρόνος απάντησης ενός ms σεναρίου Μέσος χρόνος απάντησης σεναρίου ms Χρόνος που απαντήθηκε το 95% των ms αιτημάτων Χρόνος που απαντήθηκε το 99% των ms αιτημάτων Αυτά είναι τα στατιστικά αποτελέσματα από το τρίτο τεστ που υλοποιήθηκε στον εξυπηρετητή. 110

111 5.2.6 Σύνοψη αποτελεσμάτων δεύτερης αξιολόγησης Από τις δοκιμές που περιγράφθηκαν στα υποκεφάλαια 5.2.3, 5.2.4, ο εξυπηρετητής υποβλήθηκε σε τρεις δοκιμές φόρτου (stress tests) και έγινε η εξαγωγή των χρόνων απόκρισης σε εισερχόμενα αιτήματα αλλά και σε σενάρια πράξεων καθενός παιχνιδιού ξεχωριστά. Με βάση τα δεδομένα αυτά έγινε η δημιουργία διαγραμμάτων στα οποία φαίνεται η διακύμανση των χρόνων απάντησης των αιτημάτων και των σεναρίων από τον εξυπηρετητή. Τα διαγράμματα έγιναν με χρήση της Matlab. Αρχικά παρουσιάζονται τα διαγράμματα που αφορούν τον χρόνο απόκρισης του εξυπηρετητή σε εισερχόμενα αιτήματα. Εικόνα 45: Διακύμανση χρόνου απόκρισης σε αιτήματα Στην Εικόνα 45 υπάρχουν τρία διαγράμματα στα οποία φαίνεται η διακύμανση του χρόνου απόκρισης σε αιτήματα από τον εξυπηρετητή. Στο πρώτο φαίνεται ο ελάχιστος χρόνος που χρειάστηκε να εξυπηρετηθεί ένα αίτημα και κατά μέσο όρο χρειάζεται 4,4ms. Στο δεύτερο σχήμα πάνω δεξιά φαίνεται η διακύμανση του μέγιστο χρόνου που χρειάστηκε για να απαντηθεί ένα αίτημα σε κάθε δοκιμή κατά μέσο όρο είναι ms. Στο τρίτο διάγραμμα φαίνεται ο μέσος χρόνος απάντησης σε ένα αίτημα σε κάθε δοκιμή. Από τις τρεις δοκιμές ο μέσος όρος απάντησης σε ένα αίτημα είναι ms. 111

112 Στη συνέχεια παρουσιάζονται τα διαγράμματα που αφορούν τους χρόνους εξυπηρέτησης των σεναρίων σε κάθε δοκιμή. Εικόνα 46: Διακύμανση χρόνου απόκρισης σε σενάρια κάθε παιχνιδιού Στην Εικόνα 46 υπάρχουν τρία διαγράμματα στα οποία φαίνεται η διακύμανση του χρόνου απόκρισης σε σενάρια κάθε παιχνιδιού από τον εξυπηρετητή. Στο πρώτο φαίνεται ο ελάχιστος χρόνος που χρειάστηκε να εξυπηρετηθεί ένα σενάριο και κατά μέσο όρο χρειάζεται 35.5ms. Στο δεύτερο σχήμα πάνω δεξιά φαίνεται η διακύμανση του μέγιστο χρόνου που χρειάστηκε για να εξυπηρετηθεί ένα σενάριο σε κάθε δοκιμή κατά μέσο όρο είναι ms. Στο τρίτο διάγραμμα φαίνεται ο μέσος χρόνος εξυπηρέτησης για ένα σενάριο σε κάθε δοκιμή. Από τις τρεις δοκιμές ο μέσος όρος εξυπηρέτησης σε ένα σενάριο είναι ms. Τέλος δίνεται το διάγραμμα στο οποίο φαίνεται ο αριθμός αιτημάτων ανά δευτερόλεπτο που εξυπηρετείται σε κάθε δοκιμή. 112

113 Εικόνα 47: Αριθμός αιτημάτων ανά δευτερόλεπτο σε κάθε δοκιμή Στην Εικόνα 47 φαίνεται η διακύμανση του αριθμού αιτημάτων ανά δευτερόλεπτο που εξυπηρετείται και κατά μέσο όρο υπολογίζεται ότι ο εξυπηρετητής εξυπηρετεί αιτήματα/δευτερόλεπτο. Αφού έγινε η ανάλυση όλων των αποτελεσμάτων της δεύτερης αξιολόγησης παρακάτω παρουσιάζονται αναλυτικά τα χαρακτηριστικά του εξυπηρετητή Χρόνοι απόκρισης του επεκτάσιμου εξυπηρετητή Ελάχιστος χρόνος εξυπηρέτησης 4.4 αιτήματος (ms) Μέγιστος χρόνος εξυπηρέτησης αιτήματος (ms) Μέσος χρόνος εξυπηρέτησης αιτήματος (ms) Ελάχιστος χρόνος εξυπηρέτησης 35.5 σεναρίου παιχνιδιού (ms) Μέγιστος χρόνος εξυπηρέτησης σεναρίου παιχνιδιού (ms) 113

114 Μέσος χρόνος εξυπηρέτησης σεναρίου παιχνιδιού (ms) Αριθμός εξυπηρέτησης αιτημάτων (ανά δευτερόλεπτο) , Συμπεράσματα αξιολογήσεων Από τις δύο αξιολογήσεις που έγιναν στον επεκτάσιμο εξυπηρετητή μπορεί να γίνει η εξαγωγή συμπερασμάτων ως προς τα χαρακτηριστικά του. Αρχικά με βάση την πρώτη αξιολόγηση που έγινε και αναλύθηκε στο υποκεφάλαιο 5.1, ο επεκτάσιμος εξυπηρετητής αξιολογήθηκε επιτυχώς ως προς την επεκτασιμότητά του. Έγινε η μοντελοποίηση του UoP GO και δημιουργήθηκε το κατάλληλο module με βάση το οποίο υποστηρίζεται επιτυχώς από τον εξυπηρετητή. Οποιοδήποτε παιχνίδι στο οποίο μπορεί να εφαρμοστεί η μοντελοποίηση που περιγράφθηκε στο κεφάλαιο 3 μπορεί να υλοποιηθεί με ένα module που περιλαμβάνει τους κανόνες του και στη συνέχεια να υποστηριχτεί από τον εξυπηρετητή. Επομένως τα όρια της επεκτασιμότητάς του ορίζονται μέσα στα πλαίσια της μοντελοποίησης που έγινε. Όσον αφορά την δεύτερη αξιολόγηση όπου ο εξυπηρετητής υποβλήθηκε σε δοκιμές φόρτου (stress tests) μπόρεσαν να εξαχθούν αποτελέσματα σχετικά με την απόκρισή του. Όπως μπορεί ο καθένας να δει μέσα από τις τρεις δοκιμές που έγιναν στο υποκεφάλαιο 5.2 έγινε η εξαγωγή των μέσων χρόνων απόκρισης του εξυπηρετητή και σε πραγματικές συνθήκες παιχνιδιού είναι αρκετά ικανοποιητικοί. Για να μπορέσει σε πραγματικές συνθήκες ο επεκτάσιμος εξυπηρετητής να αρχίσει να αρνείται (reject) αιτήματα θα πρέπει τα δεδομένα του παιχνιδιού να είναι πολλά, όσον αφορά τις ετικέτες και τα αντικείμενα, και ο αριθμός των χρηστών που κάνει πράξεις να στέλνουν πάνω από 50 μέσα σε ένα δευτερόλεπτο. Επομένως σαν γενικό συμπέρασμα η απόκριση του εξυπηρετητή που μετρήθηκε είναι σε ικανοποιητικά πλαίσια. 114

115 115

116 6 Συμπεράσματα και μελλοντικιές κατευθύνσεις Στο συγκεκριμένο κεφάλαιο θα γίνει ανασκόπηση της συνολικής πορείας της συγκεκριμένης διπλωματικής εργασίας και παρουσίαση των συμπερασμάτων που προέκυψαν από αυτήν. Θα γίνει αναφορά στην κατάσταση που βρίσκεται ο επεκτάσιμος εξυπηρετητής που αναπτύχθηκε και θα γίνει αναφορά στις μελλοντικιές δυνατότητες που υπάρχουν για την επέκταση και βελτίωσή του. 6.1 Ανασκόπηση πορείας Ο στόχος της συγκεκριμένης διπλωματικής εργασίας ήταν να σχεδιαστεί και να αναπτυχθεί ένας επεκτάσιμος εξυπηρετητής ο οποίος θα υποστηρίζει χωροευαίσθητα παιχνίδια που ανήκουν σε μια συγκεκριμένη κατηγορία. Αρχικά λοιπόν αφού αναλύθηκε η κατηγορία αυτή των παιχνιδιών στο υποκεφάλαιο 2.1, έγινε χρήση δύο παιχνιδιών για τη μοντελοποίησή τους. Τα παιχνίδια αυτά είναι το MuseumScrabble και το Taggling τα οποία αναλύθηκαν στα υποκεφάλαια και Ο λόγος που ήταν σημαντική η μοντελοποίηση, ήταν για να δημιουργηθεί μια αφαιρετική συμπεριφορά με βάση την οποία να μπορεί να περιγραφθεί ένα παιχνίδι. Αφού έγινε μεγάλη ανάλυση της μοντελοποίησης στο κεφάλαιο 3 το αμέσως επόμενο βήμα ήταν να μπορέσει να την υιοθετήσει ο εξυπηρετητής. Έτσι θα μπορέσει να αποκτήσει την ιδιότητα της επεκτασιμότητας, ώστε στη συνέχεια οποιοδήποτε νέο παιχνίδι υπακούει στους κανόνες της μοντελοποίησης, να μπορεί αποτελεσματικά να υποστηριχτεί από αυτόν. Στο κεφάλαιο 4 πραγματοποιείται η υιοθέτηση της μοντελοποίησης σε κώδικα από τον εξυπηρετητή. Από εκεί και πέρα όταν θέλει κάποιος προγραμματιστής θέλει να τον χρησιμοποιήσει για την υποστήριξη ενός παιχνιδιού, το μόνο που έχει να κάνει είναι να κατασκευάσει ένα module σε Nodejs που θα περιέχει 116

117 τους κανόνες του και να το εισάγει σε αυτόν. Έτσι πραγματοποιήθηκε η υποστήριξη του MuseumScrabble και του Taggling. Τέλος έγινε η αξιολόγησή του για δύο χαρακτηριστικά στο κεφάλαιο 5. Το πρώτο που αξιολογήθηκε ήταν η επεκτασιμότητα του εξυπηρετητή με την εισαγωγή ενός νέου παιχνιδιού, του UoP GO, η οποία στέφθηκε με επιτυχία. Η δεύτερη και τελευταία αξιολόγηση έγινε πάνω στο φορτίο κίνησης που μπορεί να αντέξει ο εξυπηρετητής μέσω δοκιμών φόρτου (stress tests). Από αυτήν έγινε εξαγωγή των χαρακτηριστικών χρόνων απόκρισης του επεκτάσιμου εξυπηρετητή. 6.2 Συμπεράσματα Αφού έγινε η ανασκόπηση όλης της πορείας τώρα θα γίνει η παρουσίαση των συμπερασμάτων από αυτήν. Αυτό που έχει επιτευχθεί είναι ένα λογισμικό εξυπηρετητή το οποίο είναι εξ ολοκλήρου back-end. Διαθέτει δική του πολιτική για διαχείριση χρηστών και συνεδριών που περιγράφεται στα υποκεφάλαια 4.2 και 4.3 αντίστοιχα. Διαθέτει κάποια βασικά εργαλεία που προέκυψαν από την μοντελοποίηση του κεφαλαίου 3. Τα εργαλεία αυτά, τα οποία αναφέρονται στο κεφάλαιο 4.6, είναι διαθέσιμα σε κάποιον προγραμματιστή για να μπορέσει να κατασκευάσει το module με τους κανόνες του νέου του παιχνιδιού. Οι στόχοι που τέθηκαν στην αρχή τις συγκεκριμένης διπλωματικής εργασίας επιτεύχθηκαν. Έγινε ολοκληρωμένα η σχεδίαση του εξυπηρετητή η οποία είναι το πιο σημαντικό κομμάτι πριν την υλοποίησή του σε κώδικα. Στη συνέχεια μέσω της υλοποίησής του παράχθηκε ένα λογισμικό το οποίο είναι επεκτάσιμο και μπορεί στο μέλλον να χρησιμοποιηθεί για εξυπηρέτηση νέων παιχνιδιών. 6.3 Μελλοντικές κατευθύνσεις Όπως αναφέρθηκε στο υποκεφάλαιο 6.1 ο επεκτάσιμος εξυπηρετητής είναι εξ ολοκλήρου ένα back-end λογισμικό. Σε αυτό το κομμάτι θα γίνει αναφορά του πως μπορεί αυτό το λογισμικό να επεκταθεί και να εξελιχθεί στο μέλλον. 117

118 Αρχικά το πρώτο θέμα που θα αναλυθεί είναι η ύπαρξη μιας γενικής διεπαφής που θα λειτουργεί ως front-end για τον εξυπηρετητή. Αυτήν τη στιγμή δεν διαθέτει κάποιο front-end για την επεξεργασία του περιεχομένου του από κάποιον διαχειριστή. Ένα μελλοντικό πόρισμα, λοιπόν, που μπορεί να υπάρξει είναι να δημιουργηθεί ένα front-end το οποίο θα το χειρίζονται οι διαχειριστές των συνεδριών. Θα έχουν την δυνατότητα να επεξεργάζονται τις συνεδρίες, για παράδειγμα να δημιουργούν νέες, να τις τροποποιούν και να τις διαγράφουν όποτε χρειαστεί. Ο εξυπηρετητής αυτή τη στιγμή υλοποιεί τις λειτουργίες αυτές αλλά όχι μέσω διεπαφής. Επίσης να μπορούν μέσω της διεπαφής να έχουν εικόνα της κατάστασης που επικρατεί σε μια συνεδρία. Για παράδειγμα να έχουν τη δυνατότητα να βλέπουν ποιος προπορεύεται, που βρίσκεται κάθε παίκτης και άλλα στοιχεία τα οποία τους παρέχουν μια εικόνα της. Ένα παράδειγμα είναι η περίπτωση που κάποιος παίκτης απομακρυνθεί πολύ από το χώρο που παίζεται το παιχνίδι ώστε να μπορεί κάποιος επιβλέπων να το δει. Το δεύτερο θέμα για μελλοντική εξέλιξη έχει να κάνει με τη δημιουργία του module των κανόνων ενός νέου παιχνιδιού. Αυτήν τη στιγμή για να δημιουργήσει ένας προγραμματιστής ένα νέο module που να έχει τους κανόνες του παιχνιδιού του, πρέπει να έχει καλές γνώσεις και εμπειρία πάνω στο Nodejs. Αυτό είναι ένα θέμα που μπορεί να ληφθεί υπόψιν για μελλοντική εξέλιξη του εξυπηρετητή. Θα μπορούσε να δημιουργηθεί μια διεπαφή μέσω της οποίας ο χρήστης θα δημιουργεί και να τροποποιεί ένα νέο module με τους κανόνες ενός παιχνιδιού. Η λογική της διεπαφής θα είναι να απαλλάσει τον χρήστη από γνώσεις του Nodejs και να μπορεί να δημιουργεί τους κανόνες του παιχνιδιού με έναν πιο εύκολο τρόπο. Θα μπορούσε να είναι μια διεπαφή μέσω της οποίας θα τροποποιεί το περιεχόμενο των προκαθορισμένων συναρτήσεων που περιγράφθηκαν στο υποκεφάλαιο 4.6, αλλά και να εισάγει νέες μέσω μιας δυναμικής φόρμας. Από τις παραπάνω προτάσεις που αναλύθηκαν όσον αφορά το μέλλον του επεκτάσιμου εξυπηρετητή πρέπει να γίνει μια απλοποίηση του τρόπου που 118

119 δημιουργούνται τα επεκτάσιμα κομμάτια τα οποία χρησιμοποιεί για υποστήριξη νέων παιχνιδιων βάση της μοντελοποίησης. Έτσι θα είναι πιο προσιτός σε προγραμματιστές με λιγότερη εμπειρία πάνω σε θέματα mongodb αλλά και του Nodejs. 6.4 Επίλογος Μέσα από την εκπόνηση της συγκεκριμένης διπλωματικής εργασίας είναι φανερό ότι οι στόχοι που τέθηκαν έχουν πλέον επιτευχθεί. Το γεγονός ότι η μεγαλύτερη βαρύτητα δόθηκε στον σχεδιασμό του επεκτάσιμου εξυπηρετητή έκανε πιο αξιόπιστη και εύκολη την υλοποίησή του. Η αξιολόγηση έδειξε ότι σε πραγματικές συνθήκες ο εξυπηρετητής μπορεί να υποστηρίξει σε ικανοποιητικό χρόνο συνεδρίες πολλών παιχνιδιών αλλά και να επεκταθεί για την υποστήριξη νέων. Ο επεκτάσιμος εξυπηρετητής της εργασίας αυτής αποτελεί στην ουσία έναν νέο πυρήνα υποστήριξης χωρο-ευαίσθητων παιχνιδιών. Είναι ένα λογισμικό το οποίο μπορεί κάποιος να το εξελίξει στο μέλλον και να απλοποιήσει τον τρόπο που με τον οποίο επεκτείνεται για την υποστήριξη νέων παιχνιδιών, αλλά και τον τρόπο διαχείρισης του περιεχομένου του. 119

120 7 Αναφορές Σιντόρης, Χ. (2014, Μάρτιος 6). Εργαλεία σχεδίασης χωρο-ευαίσθητων παιχνιδιών για άτυπη μάθηση (Thesis). Ανακτήθηκε από A multi-tier architecture for building RESTful Web services. (2009, Ιούνιος 9). Ανακτήθηκε 10 Ιούλιος 2017, από Banker, K. (2011). MongoDB in Action. Greenwich, CT, USA: Manning Publications Co. Berlińska, J., & Drozdowski, M. (2011). Scheduling divisible MapReduce computations. Journal of Parallel and Distributed Computing, 71(3), Bunch, C., Chohan, N., Krintz, C., Chohan, J., Kupferman, J., Lakhina, P., Nomura, Y. (2010). An Evaluation of Distributed Datastores Using the AppScale Cloud Platform. Στο 2010 IEEE 3rd International Conference on Cloud Computing (σσ ). Cardin, C. (2016). Design of a horizontally scalable backend application for online games. Ανακτήθηκε από Chaniotis, I. K., Kyriakou, K.-I. D., & Tselikas, N. D. (2015). Is Node.js a viable option for building modern web applications? A performance evaluation study. Computing, 97(10), Dayley, B. (2014). Node.js, MongoDB, and AngularJS Web Development. Addison-Wesley Professional. Guinard, D., Trifa, V., & Wilde, E. (2010). A resource oriented architecture for the Web of Things. Στο 2010 Internet of Things (IOT) (σσ 1 8). Han, J., E, H., Le, G., & Du, J. (2011). Survey on NoSQL database. Στο th International Conference on Pervasive Computing and Applications (σσ ). Kambalyal, C. (2010). 3-tier architecture. Retrieved On, 2. Ανακτήθηκε από Lei, K., Ma, Y., & Tan, Z. (2014). Performance Comparison and Evaluation of Web Development Technologies in PHP, Python, and Node.js. Στο 2014 IEEE 17th 120

121 International Conference on Computational Science and Engineering (σσ ). Magerkurth, C., Cheok, A. D., Mandryk, R. L., & Nilsen, T. (2005). Pervasive Games: Bringing Computer Entertainment Back to the Real World. Comput. Entertain., 3(3), Manoli, V., Sintoris, C., Yiannoutsou, N., & Avouris, N. (2015). Taggling Game: Learning about contemporary art through game play. Στο Proceedings EDULEARN 2015, 7th Int. Conference on Education and New Learning Technologies, IATED (σσ ). IATED. Ανακτήθηκε από ggling_game_learning_about_contemporary_art_through_game_play/links/568cc6 6e08ae153299b6867f/Taggling-Game-Learning-about-contemporary-art-throughgame-play.pdf Mardan, A. (2014). Boosting Your Node.js Data with the Mongoose ORM Library. Στο Practical Node.js (σσ ). Apress. 2_7 Montola, M., Stenros, J., & Waern, A. (2009). Pervasive Games: Theory and Design. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc. NoSQL Databases Pros And Cons. (χ.χ.). Ανακτήθηκε 27 Μάιος 2017, από Pautasso, C. (2009). RESTful Web service composition with BPEL for REST. Data & Knowledge Engineering, 68(9), Pereira, C. R. (2016). Authenticating Users. Στο Building APIs with Node.js (σσ 49 59). Apress. Sintoris, C., Stoica, A., Papadimitriou, I., Yiannoutsou, N., Komis, V., & Avouris, N. (2012). MuseumScrabble: Design of a Mobile Game for Children s Interaction with a Digitally Augmented Cultural Space. Global.com/Resolvedoi/resolve.aspx?doi= / ch007, Tilkov, S., & Vinoski, S. (2010). Node.js: Using JavaScript to Build High-Performance Network Programs. IEEE Internet Computing, 14(6), Wang, X., Chen, H., & Wang, Z. (2013). Research on Improvement of Dynamic Load Balancing in MongoDB. Στο 2013 IEEE 11th International Conference on Dependable, 121

122 Autonomic and Secure Computing (σσ )

123 123

124 Παράρτημα Α: Οδηγίες εγκατάστασης εξυπηρετητή Όταν ένας προγραμματιστής χρειαστεί την υποστήριξη του συγκεκριμένου επεκτάσιμου εξυπηρετητή για μια εφαρμογή του, θα πρέπει να γνωρίζει πώς να τον εγκαταστήσει επιτυχώς. Στο συγκεκριμένο παράρτημα θα δοθούν αναλυτικά όλα τα βήματα που πρέπει να γίνουν ώστε να στηθεί ο εξυπηρετητής και να μπορεί να λειτουργήσει σωστά. Αρχικά λοιπόν πρέπει να εγκατασταθεί το περιβάλλον του Nodejs που είναι η βασική δομή του λογισμικού του εξυπηρετητή. Μετά την εγκατάσταση του Nodejs πρέπει να εγκατασταθεί και το node package manager (npm), το οποίο αποτελεί και αυτό κομμάτι του πυρήνα του εξυπηρετητή. Τα συγκεκριμένα λογισμικά είναι διαθέσιμα από το όπου εκεί κάποιος μπορεί να βρει οδηγίες για το πώς ανάλογα με το λειτουργικό του σύστημα μπορεί να τα εγκαταστήσει στον υπολογιστή του. Εικόνα 48: Αρχική της ιστοσελίδας του Nodejs Το επόμενο λογισμικό που πρέπει να εγκατασταθεί είναι αυτό της βάσης δεδομένων. Ο χρήστης πρέπει να εγκαταστήσει την mongodb στο μηχάνημά του από το όπου θα βρει την κατάλληλη έκδοσή της βάσει και του λειτουργικού του συστήματος και τις οδηγίες εγκατάστασής της. Αφού εγκατασταθεί η mongodb, το μόνο πράγμα που πρέπει να κάνει είναι να δημιουργήσει έναν χώρο στον οποίο θα αποθηκευτούν τα δεδομένα της βάσης 124

125 του. Αυτή η λεπτομέρεια βρίσκεται και αυτή στις οδηγίες εγκατάστασης της mongodb. Αφού γίνουν τα παραπάνω επιτυχώς μπορεί να γίνει η εκκίνηση του εξυπηρετητή ακολουθώντας τα παρακάτω βήματα. 1. Εκκίνηση της mongodb ανοίγοντας το αρχείο mongod.exe που βρίσκεται στον φάκελο bin στο directory που είναι αποθηκευμένη η mongodb. 2. Στη συνέχεια πρέπει μέσω γραμμής εντολών να εκκινήσει τον εξυπηρετητή ως npm εφαρμογή. Αυτό γίνεται αν πάει κάποιος μέσω γραμμής εντολών στο directory του εξυπηρετητή και γράψει την εντολή npmstart. Με τον τρόπο αυτόν ξεκινά ο εξυπηρετητής και το μύνημα που βλέπει ο χρήστης στη γραμμή εντολών είναι το εξής. Εικόνα 49: Γραμμή εντολών για εκκίνηση εξυπηρετητή 125