Η παρούσα εργασία αφορά τη δημιουργία ενός παιχνιδιού λαβυρίνθου με θέμα \textit{“Μια νύχτα στο μουσείο”}.
Στο συγκεκριμένο παιχνίδι καλούμαστε να δημιουργήσουμε ένα λαβύρινθο μέσα στον οποίο κινούνται με τυχαίο τρόπο δύο παίχτες, ο Θησέας και ο Μινώταυρος.
Στόχος του Μινώταυρου είναι να “πιάσει” τον Θησέα και στόχος του Θησέα είναι να βρει όλα τα εφόδια που είναι τυχαία κατανεμημένα στο ταμπλό, πριν ξημερώσει και πριν τον πιάσει ο Μινώταυρος.
Στο παιχνίδι αυτό υπάρχουν δύο βασικά προβλήματα τα οποία χρειάζεται να λύσουμε.
Το πρόβλημα της δημιουργίας του λαβύρινθου και το πρόβλημα της λειτουργίας των παιχτών και του υπόλοιπου παιχνιδιού.
Η παρούσα εργασία αφορά την δημιουργία ενός παιχνιδιού λαβυρίνθου “Μία νύχτα στο μουσείο”.
Στο συγκεκριμένο παιχνίδι καλούμαστε να υλοποιήσουμε ένα λαβύρινθο μέσα στον οποίο κινούνται δύο παίκτες, ο Μινώταυρος και ο Θησέας.
Στόχος του Μινώταυρου είναι να “πιάσει” τον Θησέα και στόχος του Θησέα είναι να βρει όλα τα εφόδια πού βρίσκονται κατανεμημένα στον ταμπλό, πριν ξημερώσει και πριν τον “πιάσει” ο Μινώταυρος.
\par Κατά την άποψή μας, σε αυτό το πρώτο μέρος της εργασίας, η δημιουργία του ταμπλό είναι το κυριότερο από τα δύο προβλήματα.
\par Υπενθυμίζουμε ότι στην πρώτη εργασία κληθήκαμε να λύσουμε δύο βασικά προβλήματα.
Το πρόβλημα της δημιουργίας του λαβυρίνθου και το πρόβλημα της λειτουργίας των παικτών.
Το ταμπλό αποτελείται από πλακίδια και τοίχους.
Τα πλακίδια είναι διατεταγμένα σε τετραγωνικό σχήμα και ανάμεσά τους τοποθετούνται οι τοίχοι.
Το πρόβλημα έγκειται στην επιλογή και τοποθέτηση τοίχων με τέτοιο τρόπο ώστε να πληρούνται οι προδιαγραφές του παιχνιδιού όπως πχ κάθε πλακίδιο να έχει το πολύ δύο τοίχους ή τα εξωτερικά πλακίδια να έχουν τοίχο από την έξω μεριά.
Μετά από μια πιο λεπτομερή ανάλυση του προβλήματος, διαπιστώσαμε πως οι δοθείσες προδιαγραφές δεν αποτρέπουν τη δημιουργία κλειστών δωματίων, κάτι που θεωρήσαμε άδικο, με αποτέλεσμα, όπως περιγράφουμε και αναλυτικά παρακάτω, \textbf{να προσθέσουμε έναν ακόμη περιορισμό}.
\textbf{Την αποτροπή κλειστών δωματίων στο ταμπλό}.
\par Το πρόβλημα της λειτουργίας του υπόλοιπου παιχνιδιού έχει να κάνει με τη δημιουργία των παιχτών καθώς και τις κινήσεις τους.
Οι προδιαγραφές αφορούν περιορισμούς στην κίνηση των παιχτών και τον τρόπο με τον οποίο λειτουργεί το παιχνίδι.
Για παράδειγμα οι παίχτες δεν μπορούν να περάσουν μέσα από τοίχους, ή οι παίχτες κινούνται κατά ένα πλακίδιο τη φορά κλτ.
Σε αντίθεση με το πρόβλημα του ταμπλό εδώ η λύση ήταν τετριμμένη.
\par Λαμβάνοντας υπόψιν τόσο τα δεδομένα που μας δόθηκαν, δηλαδή για την δομή του παιχνιδιού, όσο και τα δύο βασικά προβλήματα που χρειάστηκε να επεξεργαστούμε και να λύσουμε στο πρώτο μέρος, αποφασίσαμε να υλοποιήσουμε την δεύτερη εργασία με γνώμονα τις σχεδιαστικές επιλογές και τα \eng{concepts} που αναπτύξαμε και περιγράφονται αναλυτικά στην αναφορά του πρώτου μέρους.
Όσον αφορά επίσης τον τρόπο κίνησης των παικτών επιλέξαμε μόνο ο Θησέας να έχει την δυνατότητα να επιλέγει την κατεύθυνση της επόμενης κίνησης του, ενώ ο Μινώταυρος να κινείται με τυχαίο τρόπο.
\section{Παραδοτέα}
Τα επισυναπτόμενα παραδοτέα αποτελούνται από:
@@ -77,6 +76,8 @@
\section{Σχεδιαστικές επιλογές}
Πριν ασχοληθούμε όμως με τα ζητηθέντα αντικείμενα του προγράμματος, θα πρέπει να αναφερθούμε σε ορισμένες δομές που προστέθηκαν, αλλά και κάποιες σχεδιαστικές επιλογές που έγιναν για να απλοποιήσουν τον κώδικα.
Αρκετές από αυτές προέρχονται από την προηγούμενη εργασία.
Τις παραθέτουμε όμως και εδώ καθώς παίζουν σημαντικό ρόλο, τόσο στην λειτουργία του προγράμματος όσο και στην καλύτερη κατανόηση της τρέχουσας εργασίας.
\subsection{\eng{Accessor - mutator idiom}}
Στις προδιαγραφές της εργασίας αφήνεται να εννοηθεί πως ζητείται η χρήση του \eng{\textit{accessor - mutator idiom}}.
@@ -122,22 +123,32 @@
\par Ένας παρατηρητικός αναγνώστης θα διαπιστώσει πως οι συναρτήσεις για τα εφόδια είναι αναγκασμένες να πάρουν τον πίνακα αναφορών στα εφόδια ως όρισμα.
Αυτό είναι το τίμημα που πρέπει να πληρώσουμε προωθώντας τις μεθόδους αυτές στην \eng{Tile}.
\subsection{Αναβάθμιση της τάξης \eng{Board}}
Στην διάρκεια του σχεδιασμού θεωρήσαμε ωφέλιμη την εισαγωγή της μεταβλητής \eng{\textit{ArrayList<Integer[]> moves}} στην τάξη \eng{Board}.
Σε αυτή καταχωρούμε τις πληροφορίες της τελευταίας κίνησης του κάθε παίκτη, όπως το \eng{id} του πλακιδίου που βρίσκεται ο παίκτης, οι συντεταγμένες του και η συλλογή εφοδίου.
Στην προσθήκη αυτή οδηγηθήκαμε αφού παρατηρήσαμε πως για την τάξη \eng{HeuristicPlayer} είναι απαραίτητη η πρόσβαση στην θέση και στο \eng{id} του αντιπάλου.
Αυτή πραγματοποιείται μέσω της μεταβλητής \eng{moves} και της συνάρτησης \eng{\textit{getOpponentMoves()}}.
Έτσι ο κάθε \eng{HeuristicPlayer} μπορεί να διαπιστώσει αν στο οπτικό του πεδίο βρίσκεται κάποιος αντίπαλος και να κινηθεί κατάλληλα.
\subsection{Αναβάθμιση της τάξης \eng{Player}}
Για την επέμβαση σε αυτή την τάξη κινηθήκαμε με γνώμονα την αντιμετώπιση δύο προβλημάτων που μας παρουσιάστηκαν.
Αρχικά για την σωστή λειτουργία τη κλάσης \eng{HeuristicPlayer}, όπως αναφέραμε και παραπάνω, είναι αναγκαία η πρόσβαση στο \eng{id} του αντιπάλου.
Για τον λόγο αυτό επιλέξαμε να δημιουργείται ένα \eng{id} για κάθε παίκτη μέσω συνάρτησης της τάξης \eng{Board}, στο οποίο θα έχουμε πρόσβαση μέσω της μεταβλητής \eng{\textit{ArrayList<Integer[]> moves}}.
Τη λειτουργία αυτή αναλαμβάνει η συνάρτηση \eng{\textit{int generatePlayerId()}}.
\par
Επιπρόσθετα, θέλαμε να ενοποιήσουμε τις υλοποιήσεις των τάξεων \eng{Player} και \eng{HeuristicPlayer} και να τις κάνουμε συμβατές με την αρχή του \eng{Liskov} \footnote{\eng{\url{https://en.wikipedia.org/wiki/Liskov_substitution_principle}}}.
Για το λόγο αυτό οι συναρτήσεις \eng{\textit{move(), statistics()}} και \eng{\textit{final\_statistice()}} είναι πλέον υλοποιημένες και στα δύο αντικείμενα.
Αυτό μας ανάγκασε να μετακινήσουμε την μεταβλητή \eng{path} στο \eng{base object} δηλαδή στην \eng{Player}.
\section{\eng{Concepts}}
Η δημιουργία της \eng{Board} αποτέλεσε τον μεγαλύτερο όγκο του κώδικα της παρούσας εργασίας.
Για να κάνουμε τον κώδικα καθαρότερο αλλά και ευκολότερο στην κατανόηση επινοήσαμε κάποια \eng{\textbf{concepts}}.
Η ιδέα των \eng{concepts} προέρχεται από την \eng{C++} όπου τα \eng{concepts} είναι ένα είδους \eng{compile time predicate} και εφαρμόζεται στους τύπους δεδομένων.
Εμείς για την εργασία υλοποιήσαμε κάποια \eng{concepts} σε μορφή συναρτήσεων κατά την εκτέλεση του προγράμματος.
Αν και τα \eng{concepts} υλοποιήθηκαν για την εκπόνηση του πρώτου μέρους, τα παραθέτουμε συνοπτικά και σε αυτή την αναφορά, καθώς τα θεωρούμε ουσιαστικό κομμάτι τόσο για το πρώτο, όσο και για το δεύτερο μέρος της εργασίας.
Για την εργασία υλοποιήσαμε κάποια \eng{concepts} σε μορφή συναρτήσεων κατά την εκτέλεση του προγράμματος.
Τα \eng{concepts} αυτά αφορούν έννοιες σχετικές με την εφαρμογή και έχουν την μορφή \eng{predicate}.
Μας δίνεται έτσι η δυνατότητα να ελέγχουμε αν κάποια είσοδός ενός \eng{predicate-concept} πληροί τις προδιαγραφές του ή όχι.
Στο σχήμα \ref{fig:concepts} φαίνεται μια οπτικοποιημένη έκδοση τους.
Οπτική αναπαράσταση των \eng{concepts} που χρησιμοποιούμε σε ένα ταμπλό $7x7$.
Με πράσινο αναπαρίστανται όσα πληρούν κάποιο \eng{concept} και με κόκκινο όσα όχι.
Τα πλακίδια με το γκρι χρώμα, είναι τα πλακίδια φρουροί.
}
Πρόκειται για \eng{predicate} που μας επιτρέπει να ελέγξουμε αν μια διεύθυνση κάποιου πλακιδίου είναι \textit{”χτίσιμη διεύθυνση”}.
Αν δηλαδή μπορούμε να τοποθετήσουμε τοίχο στη διεύθυνση αυτή.
Για να είναι μια διεύθυνση χτίσιμη θα πρέπει:
@@ -226,7 +242,7 @@
\section{Υλοποίηση}
Για την μεταγλώττιση της εφαρμογής, απαιτείται \eng{java} έκδοση 8 ή και μεταγενέστερη καθώς έχουμε κάνει χρήση \eng{lambdas}.
Όσο αφορά την υλοποίηση, εκτός από τα ζητηθέντα αντικείμενα υλοποιήσαμε και τα παρακάτω.
Για υπενθύμιση, αναφέρουμε συνοπτικά τη λειτουργία ορισμένων αντικειμένων που προσθέσαμε κατά την πρώτη εργασία.
\begin{itemize}
\item \eng{\textbf{Const}}\\
Το αντικείμενο αυτό περιέχει σταθερές για όλη την εφαρμογή.
@@ -251,36 +267,21 @@
Οι αναπαραστάσεις αυτές όπως αναφερθήκαμε και παραπάνω είναι η καρτεσιανή που περιέχει δύο μεταβλητές για την γραμμή και τη στήλη και η μονοδιάστατη \eng{(id)}.
\item \eng{\textbf{Range}}\\
Το αντικείμενο χρησιμοποιείται για να δημιουργεί εύρη τιμών.
Για παράδειγμα ο κώδικας παρακάτω δημιουργεί ένα \eng{range} με όλες τις διευθύνσεις.
\setEnglish
\begin{verbatim}
Range dirs = new Range(DirRange.Begin, DirRange.End, DirRange.Step);
for (int dir = dirs.get() ; dir != Const.EOR ; dir = dirs.get()) {
// use dir
}
\end{verbatim}
\setGreek
\item \eng{\textbf{ShuffledRange}}\\
Το αντικείμενο αυτό χρησιμοποιείται για να δημιουργεί \textit{“τυχαίως ανακατεμένα”} εύρη τιμών.
Το αντικείμενο αυτό χρησιμοποιείται για να δημιουργεί \textit{“τυχαίως διατεταγμένα”} εύρη τιμών.
Η τάξη αυτή κληρονομεί την \eng{Range} και προσθέτει τη λειτουργία του τυχαίου ανακατέματος των τιμών.
Για παράδειγμα παρακάτω δημιουργούμε μια τυχαία σειρά από όλα τα πλακίδια του ταμπλό.
\setEnglish
\begin{verbatim}
ShuffledRange rand = new ShuffledRange(0, N*N);
for (int tileId =rand.get(); tileId!=Const.EOR ; tileId=rand.get()){
// use tileId
}
\end{verbatim}
\setGreek
\end{itemize}
Τόσο η \eng{Range} όσο και η \eng{ShuffledRange} έχουν μια μέθοδο \eng{\textit{get()}} η οποία επιστρέφει και αφαιρεί το πρώτο στοιχείο από το \eng{range}.
Όταν το \eng{range} είναι άδειο τότε επιστρέφει την τιμή φρουρό \eng{EOR - End of Range}.
\par Τα υπόλοιπα αντικείμενα είναι τα ζητηθέντα.
Σε αυτά δεν έχουμε αλλάξει τις προδιαγραφές με εξαίρεση τις μεθόδους \eng{\textit{createBoard()}} και \eng{\textit{createSupply()}} στις οποίες προσθέσαμε σαν ορίσματα τα πλακίδια του Θησέα και του Μινώταυρου.
Ο λόγος είναι γιατί για τα εφόδια, θέλουμε να γνωρίζουμε σε ποια πλακίδια είναι οι παίχτες, ώστε να μην τοποθετήσουμε εκεί κάποιο εφόδιο.
Για το ταμπλό δε, γιατί θέλουμε να ξέρουμε σε ποια πλακίδια θα τοποθετήσουμε τους παίχτες.
\subsection{Τάξη \eng{HeuristicPlayer}}
Η υλοποίηση της τάξης \eng{HeuristicPlayer} πραγματοποιήθηκε έτσι ώστε να ικανοποιούνται τα ζητήματα της εκφώνησης.
Η βασική λειτουργία της τάξης είναι η συνάρτηση \eng{\textit{double evaluate(int currentPos, int dice)}} η οποία ζητήθηκε και από την εκφώνηση.
Για τη δημιουργία της βασιστήκαμε στην ανάπτυξη κριτηρίων που θα βοηθήσουν τον παίκτη να “καταλήξει” στην βέλτιστη απόφαση με βάση το προκαθορισμένο οπτικό του πεδίο.
Τα κριτήρια αυτά είναι η απόσταση από κάποιο εφόδιο και η απόσταση από τον αντίπαλο.
Στην τελική αξιολόγηση της κίνησης τα κριτήρια συνδυάζονται με συντελεστές βάρους οι οποίοι αποτελούν σταθερές και θέτονται κατά τη μεταγλώττιση του προγράμματος.
\par
Ένα ακόμη χαρακτηριστικό της τάξης είναι η εκτενής χρήση της μεταβλητής \eng{path}.
Όπως αναφέραμε και παραπάνω η μεταβλητή αυτή είναι προσβάσιμη τόσο από την \eng{HeuristicPlayer}, όπως ζητήθηκε, όσο και από την \eng{Player}.
Και οι δύο τάξεις καταχωρούν πληροφορίες για την κίνησή του κάθε παίκτη, με την διαφορά πως η \eng{HeuristicPlayer} καταχωρεί περισσότερες.
\section{Εκτελέσιμο} \label{sec:excecutable}
Όπως αναφέραμε και στην παράγραφο με τα παραδοτέα, σε αυτά υπάρχει και το παραγόμενο εκτελέσιμο για την γραμμή εντολών.
@@ -333,19 +334,13 @@
}
\section{Παρατηρήσεις}
Σε αυτό το σημείο θα θέλαμε να παρατηρήσουμε και μια σχεδιαστική αβλεψία.
Το κομμάτι του κώδικα που δημιουργεί χρήστες καθώς και ορισμένες επιλογές που τους αφορούν, όπως η θέση τους στο ταμπλό, οι κινήσεις κ.α., δεν είναι υλοποιημένο με τον καλύτερο δυνατό τρόπο.
Θα θέλαμε να ήταν πιο γενικό και παραμετροποιήσιμο.
Ο λόγος που δεν είναι, έχει να κάνει αρκετά και με την υποψία μας, πως αυτό το υποσύστημα θα χρειαστεί να αλλάξει αρκετά στις επόμενες εργασίες.
Αν εκτιμήσαμε λανθασμένα, τότε είναι απλώς κρίμα.
\par Μια τεχνική που δεν χρησιμοποιήσαμε αλλά μας προβλημάτισε αν θα το κάναμε ή όχι ήταν τα \eng{generics}.
Η αρχική μας σκέψη, καθώς ήμαστε επηρεασμένοι ξεκάθαρα από την \eng{C++}, ήταν οι τάξεις \eng{Edge, Graph, Range} και \eng{ShuffledRange} να είναι \eng{generics}.
Το γεγονός όμως ότι τα αντικείμενα αυτά θα τα χρησιμοποιούσαμε μονάχα σε αυτή την εργασία, μας απέτρεψε.
Μια απλή υλοποίηση μόνο για \eng{int} ήταν αρκετή και κάτι διαφορετικό θα εισήγαγε περιττή πολυπλοκότητα.
\par Κλείνοντας θα θέλαμε να παρατηρήσουμε πως η παρούσα υλοποίηση θεωρούμε ότι ήταν μια προσπάθεια να ισορροπήσουμε μεταξύ των ζητηθέντων και μεταξύ πρακτικών που ίσως μας βοηθήσουν στη συνέχεια για συγγραφή ευκολότερου και καθαρότερου κώδικα.
Γενικά πιστεύουμε πως \textbf{αν ο χρήστης μιας βάσης κώδικα έχει τη δυνατότητα να χρησιμοποιήσει λανθασμένα τον κώδικα, κάποια στιγμή θα το κάνει.}
Θα θέλαμε εδώ να σταθούμε και σε κάποιες διορθώσεις που χρειάστηκε να πραγματοποιήσουμε στον κώδικα που καταθέσαμε για την πρώτη εργασία.
Για την ακρίβεια παρατηρήσαμε πως ο \eng{copy constructor} της \eng{Board} αποτύγχανε να αντιγράψει το διάνυσμα αναφορών των τοίχων.
Ακόμα ο αλγόριθμος που αναλάμβανε να τοποθετήσει τους εσωτερικούς τοίχους στο ταμπλό αποτύγχανε να εξαντλήσει όλες τις δυνατές θέσεις με τους πιθανούς τοίχους.
Λεπτομέρειες για τις διορθώσεις μπορεί κάποιος να δει και \href{https://git.hoo2.net/hoo2/Labyrinth/commit/c14d1d812f312eda499c445e2827a8fbafa34100}{εδώ}.
\par Κλείνοντας θα θέλαμε να παρατηρήσουμε πως η παρούσα υλοποίηση ήταν μια προσπάθεια να ισορροπήσουμε μεταξύ των ζητηθέντων και μεταξύ πρακτικών που διευκολύνουν στη συγγραφή ευκολότερου και καθαρότερου κώδικα.
Γενικά, όπως είναι ίσως ήδη γνωστό, πιστεύουμε πως \textbf{αν ο χρήστης μιας βάσης κώδικα έχει τη δυνατότητα να χρησιμοποιήσει λανθασμένα τον κώδικα, κάποια στιγμή θα το κάνει.}
Ακόμα και αν ο χρήστης είναι ο ίδιος ο αρχικός συντάκτης του κώδικα.
Για το λόγο αυτό προσπαθήσαμε να περιορίσουμε, όπου αυτό δεν ήταν αντίθετο με τα ζητούμενα, την δυνατότητα της λανθασμένης χρήσης εισάγοντας αρκετά επιπλέον αντικείμενα και δομές ως εργαλεία για την εφαρμογή.
Τέτοια για παράδειγμα είναι η τάξη \eng{Position} ή η αποφυγή των \eng{setters} κτλ.
