\newcommand{\DocTitle}{Λαβύρινθος: Ο Θησέας και ο Μινώταυρος 1}
\newcommand{\InstructorName}{Σιάχαλου Σταυρούλα}
\newcommand{\InstructorName}{Σταυρούλα Σιάχαλου}
\newcommand{\InstructorMail}{ssiachal@auth.gr}
\newcommand{\CurrentDate}{\today}
@@ -39,23 +39,24 @@
Στο παιχνίδι αυτό υπάρχουν δύο βασικά προβλήματα τα οποία χρειάζεται να λύσουμε.
Το πρόβλημα της δημιουργίας του λαβύρινθου και το πρόβλημα της λειτουργίας των παιχτών και του υπόλοιπου παιχνιδιού.
\par Κατά την άποψή μας η δημιουργία του ταμπλό είναι το κυριότερο από τα δύο προβλήματα.
\par Κατά την άποψή μας, σε αυτό το πρώτο μέρος της εργασίας, η δημιουργία του ταμπλό είναι το κυριότερο από τα δύο προβλήματα.
Το ταμπλό αποτελείται από πλακίδια και τοίχους.
Τα πλακίδια είναι διατεταγμένα σε τετραγωνικό σχήμα και ανάμεσά τους τοποθετούνται οι τοίχοι.
Το πρόβλημα έγκειται στην επιλογή και τοποθέτηση τοίχων με τέτοιο τρόπο ώστε να πληρούνται οι προδιαγραφές του παιχνιδιού όπως πχ κάθε πλακίδιο να μπορεί να έχει το πολύ δύο τοίχους ή τα εξωτερικά πλακίδια να έχουν τοίχο από την έξω μεριά.
Το πρόβλημα έγκειται στην επιλογή και τοποθέτηση τοίχων με τέτοιο τρόπο ώστε να πληρούνται οι προδιαγραφές του παιχνιδιού όπως πχ κάθε πλακίδιο να έχει το πολύ δύο τοίχους ή τα εξωτερικά πλακίδια να έχουν τοίχο από την έξω μεριά.
Μετά από μια πιο λεπτομερή ανάλυση του προβλήματος, διαπιστώσαμε πως οι δοθείσες προδιαγραφές δεν αποτρέπουν τη δημιουργία κλειστών δωματίων, κάτι που θεωρήσαμε άδικο, με αποτέλεσμα, όπως περιγράφουμε και αναλυτικά παρακάτω, \textbf{να προσθέσουμε έναν ακόμη περιορισμό}.
\textbf{Την αποτροπή κλειστών δωματίων στο ταμπλό}.
\par Το πρόβλημα της λειτουργίας του υπόλοιπου παιχνιδιού έχει να κάνει με τη δημιουργία των παιχτών καθώς και τις κινήσεις τους.
Οι προδιαγραφές αφορούν περιορισμούς στην κίνηση των παιχτών και τον τρόπο με τον οποίο λειτουργεί το παιχνίδι.
Για παράδειγμα οι παίχτες δεν μπορούν να περάσουν μέσα από τοίχους, ή οι παίχτες κινούνται κατά ένα πλακίδιο τη φορά κλτ.
Σε αντίθεση με τη λύση στο πρόβλημα του ταμπλό εδώ δεν απαιτήθηκαν ιδιαίτερες τεχνικές.
Σε αντίθεση με το πρόβλημα του ταμπλό εδώ η λύση ήταν τετριμμένη.
\section{Παραδοτέα}
Τα επισυναπτόμενα παραδοτέα αποτελούνται από:
\begin{itemize}
\item Τον \eng{\textbf{root}}κατάλογο στον οποίο υπάρχει και το \eng{project}του \eng{eclipse.}
\item Ένας υποκατάλογος \eng{\textbf{src/}}με τον κώδικα της\eng{java,}αποτελούμενο από ένα αριθμό αντικειμένων ενσωματωμένο στο πακέτο \eng{host.labyrinth.}
\item Ένας υποκατάλογος \eng{\textbf{src/}}με τον κώδικα της\eng{java,}αποτελούμενο από ένα αριθμό αντικειμένων ενσωματωμένο στο πακέτο \eng{host.labyrinth.}
Αναφορά σε αυτό τον κατάλογο υπάρχει στο \eng{eclipse project.}
\item Ένας υποκατάλογος \eng{\textbf{out/}} που περιέχει το παραγόμενο \eng{command line jar}του παιχνιδιού.
\item Ένας υποκατάλογος \eng{\textbf{doc/}}με την τεκμηρίωση του κώδικα όπως αυτή έχει παραχθεί από τα σχόλια, με το εργαλείο \eng{doxygen.}
@@ -72,10 +73,10 @@
\subsection{\eng{Accessor - mutator idiom}}
Στις προδιαγραφές της εργασίας αφήνεται να εννοηθεί πως ζητείται η χρήση του \eng{\textit{accessor - mutator idiom.}}
Θα πρέπει να παραδεχτούμε όμως, πως \textbf{θεωρούμε το συγκεκριμένο ιδίωμα ιδιαίτερα προβληματικό}.
Ο κύριος λόγος είναι πως παραβιάζει θεμελιακά τις αφαιρέσεις.
Εν αντιθέτως με το ιδίομα αυτό, \textbf{τα αντικείμενα που υλοποιούνται ως αφαιρέσεις μπορούν να προσφέρουν μεθόδους που εκτελούν κάποια λειτουργία, κρύβοντας τελείως τις εσωτερικές λεπτομέρειες τις υλοποίησης}.
Ο κύριος λόγος είναι πως παραβιάζει θεμελιακά τις αφαιρέσεις δίνοντας πρόσβαση στην εσωτερική δομή του αντικειμένου.
Εν αντιθέτως με το ιδίωμα αυτό, \textbf{τα αντικείμενα που υλοποιούνται ως αφαιρέσεις μπορούν να προσφέρουν μεθόδους που εκτελούν κάποια λειτουργία, κρύβοντας τελείως τις εσωτερικές λεπτομέρειες της υλοποίησης}.
Αυτός είναι και ο δρόμος που διαλέξαμε για το σχεδιασμό του προγράμματος.
Η κάθε τάξη προσφέρει δημόσια ένα αριθμό από μεθόδους που είναι απαραίτητες για την εκάστοτε απαιτούμενη λειτουργικότητα και κρύβει όσο καλύτερα γίνεται την εσωτερική υλοποίηση.
Η κάθε τάξη του προγράμματός μας προσφέρει δημόσια ένα αριθμό από μεθόδους που είναι απαραίτητες για την εκάστοτε απαιτούμενη λειτουργικότητα και κρύβει όσο καλύτερα γίνεται την εσωτερική υλοποίηση.
Ενώ λοιπόν υλοποιήσαμε το ζητηθέν \eng{get-set}ζευγάρι για την κάθε μεταβλητή των τάξεων, δεν το χρησιμοποιήσαμε πουθενά μέσα στο πρόγραμμα.
\subsection{Ενοποιημένο σύστημα συντεταγμένων}
@@ -95,7 +96,7 @@
Ακόμα σημαίνει πως δημιουργούν επιπλέον πλεονασμό σε δεδομένα, καθώς απαιτούνται οι συντεταγμένες των εφοδίων μέσα στην\eng{Supply.}
Κάτι τέτοιο γίνεται αντιληπτό και από τις προδιαγραφές της\eng{Board}η οποία είναι αυτή που περιέχει τους πίνακες αναφορών τόσο των πλακιδίων όσο και των εφοδίων.
\textbf{Μια ποιο διαισθητική προσέγγιση βέβαια θα ήθελε τα εφόδια να ανήκουν στα πλακίδια} και όχι στο ταμπλό.
Με αυτό τον τρόπο η τάξη\eng{Supply} δεν θα είχε πληροφορίες θέσης, αλλά αντίθετα η τάξη\eng{Tile}θα είχε επιπρόσθετη πληροφορία για το αν υπάρχει εφόδιο ή όχι.
Με αυτό τον τρόπο η τάξη\eng{Supply} δεν θα είχε τις επαναλαμβανόμενες πληροφορίες θέσης, αλλά αντίθετα η τάξη\eng{Tile}θα είχε μια επιπρόσθετη πληροφορία για το αν υπάρχει εφόδιο ή όχι.
\par Όπως είναι φυσικό θελήσαμε να υλοποιήσουμε αυτή την προσέγγιση.
Αν όμως μετακινούσαμε τις αναφορές των εφοδίων στην\eng{Tile}θα αλλοιώναμε τις προδιαγραφές της εκφώνησης.
@@ -112,6 +113,7 @@
\par Ένας παρατηρητικός αναγνώστης θα διαπιστώσει πως οι συναρτήσεις για τα εφόδια είναι αναγκασμένες να πάρουν τον πίνακα αναφορών στα εφόδια ως όρισμα.
Αυτό είναι το τίμημα που πρέπει να πληρώσουμε προωθώντας τις μεθόδους αυτές στην\eng{Tile.}
\section{\eng{Concepts}}
Η δημιουργία της\eng{Board}αποτέλεσε τον μεγαλύτερο όγκο του κώδικα της παρούσας εργασίας.
Για να κάνουμε τον κώδικα καθαρότερο αλλά και ευκολότερο στην κατανόηση επινοήσαμε κάποια\eng{\textbf{concepts}.}
\WrapFigure{0.5}{r}{fig:concepts}{images/concepts.png}{Οπτική αναπαράσταση των\eng{concepts}που χρησιμοποιούμε σε ένα ταμπλό $7x7$}
Πρόκειται για\eng{concept}που μας επιτρέπει να ελέγξουμε αν το πλακίδιο είναι \textbf{“πλακίδιο φρουρός”}.
Πρόκειται για\eng{concept}που μας επιτρέπει να ελέγξουμε αν το πλακίδιο είναι \textit{”πλακίδιο φρουρός”}.
Αν δηλαδή βρίσκεται στα εξωτερικά άκρα του ταμπλό.
Η υλοποίηση αυτού του\eng{concept}γίνεται μέσω τεσσάρων συναρτήσεων που ελέγχουν χωριστά τις τέσσερεις διευθύνσεις του ταμπλό.
\par Για την παράδειγμα η \eng{\textit{boolean isLeftSentinel (int tileId)}}μας δίνει την δυνατότητα να ελέγξουμε αν το πλακίδιο είναι “πλακίδιο φρουρού” αριστερά του ταμπλό.
Αυτό είναι χρήσιμο για λειτουργίες όπως για παράδειγμα αν θέλουμε να δούμε μήπως χρειάζεται να τοποθετηθεί τοίχος αριστερά του πλακιδίου.
\par Για την παράδειγμα η \eng{\textit{boolean isLeftSentinel (int tileId)}}μας δίνει την δυνατότητα να ελέγξουμε αν το πλακίδιο είναι \textit{πλακίδιο φρουρού} αριστερά του ταμπλό.
Αυτό είναι χρήσιμο για λειτουργίες όπως για παράδειγμα αν θέλουμε να δούμε μήπως χρειάζεται να τοποθετηθεί εξωτερικός τοίχος αριστερά του πλακιδίου.
Αντίστοιχα υπάρχουν και οι υπόλοιπες συναρτήσεις για τις υπόλοιπες διευθύνσεις.
Πρόκειται για\eng{predicate}που μας επιτρέπει να ελέγξουμε αν μια διεύθυνση κάποιου πλακιδίου είναι \textbf{”χτίσιμη”}.
Πρόκειται για\eng{predicate}που μας επιτρέπει να ελέγξουμε αν μια διεύθυνση κάποιου πλακιδίου είναι \textit{”χτίσιμη διεύθυνση”}.
Αν δηλαδή μπορούμε να τοποθετήσουμε τοίχο στη διεύθυνση αυτή.
Για να είναι μια διεύθυνση χτίσιμη θα πρέπει:
\begin{itemize}
\item Η διεύθυνση να είναι “διασχίσιμη”.
\item Το γειτονικό πλακίδιο σε αυτή τη διεύθυνση να μην περιέχει ήδη τον μέγιστο αριθμό πλακιδίων.
\item Η διεύθυνση να είναι \textit{διασχίσιμη}.
\item Το γειτονικό πλακίδιο σε αυτή τη διεύθυνση να μην περιέχει ήδη τον μέγιστο επιτρεπτό αριθμό τοίχων.
\item Ο τοίχος να μην δημιουργεί κάποιο κλειστό δωμάτιο.\\
Αυτή η τελευταία \textbf{η απαίτηση δεν υπάρχει στις προδιαγραφές} και την παίρνουμε υπόψιν μόνο αν ο χρήστης την έχει ζητήσει από την γραμμή εντολών.
Ο λόγος είναι γιατί ο υπολογισμός της κοστίζει και αυτό μπορεί να μην παίζει ρόλο για ταμπλό μεγέθους $15x15$, αλλά αν ζητηθεί κάποιο πολύ μεγαλύτερο τότε ο χρόνος είναι υπολογίσιμος.
Φυσικά στον κώδικα κάνουμε χρήση αυτού του \eng{concept}μόνο κατά τη δημιουργία του ταμπλό, με αποτέλεσμα να μην επιβαρύνεται καθόλου η λειτουργία του προγράμματος κατά τη διάρκεια του παιχνιδιού.
Αναφερόμαστε αναλυτικά σε αυτό τον αλγόριθμο στην ενότητα \ref{sec:isRoomCreator}
\end{itemize}
Αυτή η τελευταία \textbf{απαίτηση δεν υπάρχει στις προδιαγραφές} και την παίρνουμε υπόψιν μόνο αν ο χρήστης την έχει ζητήσει από την γραμμή εντολών.
Ο λόγος είναι γιατί ο υπολογισμός της κοστίζει και αυτό μπορεί να μην παίζει ρόλο για ταμπλό μεγέθους $15x15$, αλλά αν ζητηθεί κάποιο πολύ μεγαλύτερο τότε ο χρόνος είναι υπολογίσιμος.
Φυσικά στον κώδικα κάνουμε χρήση αυτού του \eng{concept}μόνο κατά τη δημιουργία του ταμπλό, με αποτέλεσμα να μην επιβαρύνεται καθόλου η λειτουργία του προγράμματος κατά τη διάρκεια του παιχνιδιού.
Αναφερόμαστε αναλυτικά σε αυτό τον αλγόριθμο στην ενότητα \ref{sec:isRoomCreator}
\item Ο κάθε κόμβος αποτελεί τον κόμβο-γωνία\eng{(vertex)}ενός γράφου.
\item Ο κάθε τοίχος αναπαρίσταται ως ακμή στον γράφο.
\end{itemize}
Για παράδειγμα ένας τοίχος αριστερά του πλακιδίου `0` αναπαρίσταται ως η ακμή `(0,4)`,
Για παράδειγμα ένας τοίχος αριστερά του πλακιδίου `3` αναπαρίσταται ως η ακμή `(4,8)`,
Στο σχήμα \ref{fig:graph} φαίνεται ένα παράδειγμα αναπαράστασης.
\InsertFigure{0.6}{fig:graph}{images/graph.png}{
\\(α) Διευθυνσιοδότηση πλακιδίων(τετραγωνάκια) και κόμβων(σφαίρες) ενός ταμπλό $3x3$.\\
@@ -187,10 +189,10 @@
Το\eng{\textbf{Edge}}που δημιουργεί ζευγάρια κόμβων ώστε να μπορεί να αποθηκεύσει τον κάθε τοίχο(ακμή) και το\eng{\textbf{Graph}}που προσφέρει λειτουργίες δημιουργίας συνεκτικού γράφου λαμβάνοντας ως είσοδο τοίχους(ακμές).
\par Η λειτουργία του είναι απλή.
Κάθε φορά που ελέγχουμε αν μία διεύθυνση πλακιδίου είναι χτίσιμη, \textbf{δημιουργούμε το μεγαλύτερο δυνατό συνεκτικό γράφο που περιέχει τον εν λόγο τοίχο} και όλους τους ήδη τοποθετημένους τοίχους.
Αν στον γράφο που προκύπτει υπάρχει κάποιος κόμβος περισσότερες από μία φορές, δηλαδή ο γράφος δεν είναι απλός, τότε αυτό σημαίνει πως στον εν λόγο κόμβο μπορούμε να πάμε ακολουθώντας κάποιο τοίχο από τουλάχιστον δύο κατευθύνσεις.
Κάθε φορά που ελέγχουμε αν μία διεύθυνση πλακιδίου είναι \textit{χτίσιμη}, \textbf{δημιουργούμε το μεγαλύτερο δυνατό συνεκτικό γράφο που περιέχει τον εν λόγο τοίχο} και όλους τους ήδη τοποθετημένους τοίχους.
Αν στον γράφο που προκύπτει υπάρχει κάποιος κόμβος περισσότερες από μία φορές, δηλαδή ο γράφος δεν είναι απλός, τότε αυτό σημαίνει πως στον εν λόγο κόμβο μπορούμε να πάμε ακολουθώντας τοίχους από τουλάχιστον δύο κατευθύνσεις.
Άρα το ταμπλό περιέχει κάποιο κλειστό δωμάτιο.
Αφού τον αλγόριθμο τον εκτελούμε για κάθε πιθανή χτίσιμη διεύθυνση, τότε ο τοίχος που προκαλεί το κλειστό δωμάτιο είναι αυτός που ελέγχουμε την εκάστοτε στιγμή.
Αφού τον αλγόριθμο τον εκτελούμε για κάθε πιθανή \textit{χτίσιμη διεύθυνση}, τότε ο τοίχος που προκαλεί το κλειστό δωμάτιο είναι αυτός που ελέγχουμε την εκάστοτε στιγμή.
\par Για την λειτουργία του αλγόριθμου χρειαζόμαστε όλους τους τοίχους που είναι ήδη τοποθετημένοι στο ταμπλό στη μορφή\eng{Edge.}
Γιαυτό προσθέσαμε στην τάξη \eng{Board} μια λίστα αναφορών\eng{(ArrayList)} και σε αυτήν αποθηκεύουμε κάθε τοίχο που δημιουργούμε.
@@ -205,13 +207,15 @@
Φυσικά θα μπορούσαμε να χρησιμοποιήσουμε υπομνηματισμό και να αποθηκεύουμε τους γράφους
Όμως λόγο του ότι η επιβάρυνση λαμβάνει χώρα μόνο μία φορά κατά την εκκίνηση, σε συνδυασμό με το μικρό μέγεθος του ταμπλό, αποφασίσαμε να μην προχωρήσουμε σε περαιτέρω βελτιστοποίηση.
\section{Υλοποίηση}
Για την δημιουργία της εφαρμογής, εκτός από τα ζητηθέντα αντικείμενα υλοποιήσαμε και τα παρακάτω.
Για την μεταγλώττιση της εφαρμογής, απαιτείται\eng{java} έκδοση 8 ή και μεταγενέστερη καθώς έχουμε κάνει χρήση\eng{lambdas.}
Όσων αφορά την υλοποίηση, εκτός από τα ζητηθέντα αντικείμενα υλοποιήσαμε και τα παρακάτω.
\begin{itemize}
\item \eng{\textbf{Const}}\\
Το αντικείμενο αυτό περιέχει σταθερές για όλη την εφαρμογή.
\item \eng{\textbf{Session}}\\
Το αντικείμενο αυτό περιέχει όλες τις τιμές της εφαρμογής που αποτελούν επιλογές, όπως πχ το μέγεθος του ταμπλό, τον αριθμό των εφοδίων κτλ.
Το αντικείμενο αυτό περιέχει όλες τις τιμές της εφαρμογής που αποτελούν ρυθμίσεις ή επιλογές, όπως πχ το μέγεθος του ταμπλό, τον αριθμό των εφοδίων κτλ.
\item \eng{\textbf{Direction}}\\
Το αντικείμενο αυτό λειτουργεί σαν \eng{C++ enumerator}και παρέχει ονοματολογία στις διευθύνσεις που χρησιμοποιούμε στην εφαρμογή.
\item \eng{\textbf{DirRange}}\\
@@ -229,13 +233,101 @@
Το αντικείμενο αυτό χρησιμοποιείται για να παρέχει ένα ενοποιημένο σύστημα συντεταγμένων για όλη την εφαρμογή.
\item \eng{\textbf{Range}}\\
Το αντικείμενο χρησιμοποιείται για να δημιουργεί εύρη τιμών.
Για παράδειγμα ο κώδικας παρακάτω δημιουργεί ένα \eng{range} με όλες τις διευθύνσεις.
\selectlanguage{english}
\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}
\selectlanguage{greek}
\item \eng{\textbf{ShuffledRange}}\\
Το αντικείμενο αυτό χρησιμοποιείται για να δημιουργεί “τυχαίως ανακατεμένα” εύρη τιμών.
Η τάξη αυτή κληρονομεί την \eng{Range}και προσθέτει τη λειτουργία του τυχαίου ανακατέματος των τιμών.
Για παράδειγμα παρακάτω δημιουργούμε μια τυχαία σειρά από όλα τα πλακίδια του ταμπλό.
\selectlanguage{english} \begin{verbatim}
ShuffledRange rand = new ShuffledRange(0, N*N);
for (int tileId =rand.get(); tileId!=Const.EOR ; tileId=rand.get()){
// use tileId
}
\end{verbatim} \selectlanguage{greek}
\end{itemize}
Τόσο η\eng{Range}όσο και η \eng{ShuffledRange}έχουν μια μέθοδο \eng{\textit{get()}}η οποία επιστρέφει και αφαιρεί το πρώτο στοιχείο από το \eng{range}.
Όταν δεν έχουν άλλα στοιχεία επιστρέφουν την τιμή φρουρό\eng{EOR - End of Range.}
\par Τα υπόλοιπα αντικείμενα είναι τα ζητηθέντα.
Σε αυτά δεν έχουμε αλλάξει τις προδιαγραφές πέρα από τις \eng{\textit{createBoard()}}και \eng{\textit{createSupply()}}στις οποίες προσθέσαμε σαν ορίσματα τα πλακίδια του Θησέα και του Μινώταυρου.
Ο λόγος είναι γιατί για τα εφόδια θέλουμε να γνωρίζουμε σε ποια πλακίδια είναι οι παίχτες, ώστε να μην τοποθετήσουμε εκεί κάποιο εφόδιο.
Για το ταμπλό γιατί θέλουμε να ξέρουμε σε ποια πλακίδια θα τοποθετήσουμε τους παίχτες.
\section{Εκτελέσιμο}
Όπως αναφέραμε και στην παράγραφο με τα παραδοτέα, σε αυτά υπάρχει και το παραγόμενο εκτελέσιμο για την γραμμή εντολών.
Πρόκειται για ένα\eng{jar}αρχείο το οποίο μπορεί κάποιος να εκτελέσει σε ένα τερματικό μέσω της εντολής \eng{\texttt{java -jar labyrinth}}.
Στιγμιότυπο από την εκτέλεση του προγράμματος σε\eng{interactive mode}και με αποφυγή κλειστών δωματίων.
Η εντολή που χρησιμοποιήθηκε είναι \eng{\texttt{java -jar labyrinth -i -{}-norooms}}
}
Στον κώδικά μας χρησιμοποιούμε\eng{asserion}ώστε να ελέγξουμε την είσοδο και τις επιλογές του χρήστη.
Επομένως αν κάποιος θέλει να πειραματιστεί με τις επιλογές καλό θα ήταν να τα ενεργοποιήσει στην \eng{VM}της\eng{java} με την παράμετρο\eng{\texttt{-ea}.}
Σε αυτή την περίπτωση θα μπορούσε να εκτελέσει \eng{\texttt{java -ea -jar labyrinth -i --norooms ...}}
\par Το παραγόμενο\eng{jar}παρέχει ένα αριθμό από επιλογές-ορίσματα τα οποία ελέγχουν την λειτουργία του παιχνιδιού.
Τις επιλογές αυτές μπορούμε να δούμε και από την γραμμή εντολών απλώς εκτελώντας την εντολή \eng{\texttt{java -jar labyrinth -h}}.
Στο σχήμα \ref{fig:executable_help} μπορούμε να δούμε ένα στιγμιότυπο με τις διαθέσιμες επιλογές-ορίσματα.
Αναλυτικά, εκτός από την\eng{\texttt{-h}} αυτές είναι:
Αυτό το όρισμα ενεργοποιεί το\eng{\textit{“interactive mode”.}}
Πρόκειται για λειτουργία κατά την οποία το παιχνίδι μετά από κάθε γύρο σταματά και περιμένει είσοδο από τον χρήστη για να προχωρήσει στον επόμενο.
Αν αυτή η λειτουργία δεν είναι ενεργοποιημένη, τότε το παιχνίδι εκτελείται μονομιάς και στην έξοδο εκτυπώνονται όλοι οι γύροι αμέσως μετά την είσοδο της εντολής.
\textit{Αυτή η επιλογή είναι απενεργοποιημένη ως προεπιλογή}.
\item \eng{\textbf{-{}-norooms}}\\
Αυτό το όρισμα ενεργοποιεί την λειτουργία της εύρεσης και αποτροπής των κλειστών δωματίων.
Αν δεν γίνει χρήση αυτή της επιλογής, τότε η λειτουργία αυτή είναι απενεργοποιημένη ως προεπιλογή\footnote{Συνίσταται ανεπιφύλακτα η χρήση αυτής της επιλογής}.
Αν ο χρήστης δεν χρησιμοποιήσει την επιλογή τότε ο προεπιλεγμένος αριθμός είναι 100.
\end{itemize}
\section{Παρατηρήσεις}
Σε αυτό το σημείο θα θέλαμε να παρατηρήσουμε και μια σχεδιαστική αβλεψία.
Το σύστημα του κώδικα που δημιουργεί χρήστες καθώς και ορισμένες επιλογές που τους αφορούν, όπως η θέση τους στο ταμπλό, οι κινήσεις κα, δεν είναι υλοποιημένο με τον καλύτερο δυνατό τρόπο.
Θα θέλαμε να ήταν πιο γενικό και παραμετροποιήσιμο.
Ο λόγος που δεν είναι, έχει να κάνει αρκετά και με την υποψία πως αυτό το υποσύστημα θα χρειαστεί να αλλάξει αρκετά στις επόμενες εργασίες.
Αν εκτιμήσαμε λανθασμένα, τότε είναι απλώς κρίμα.
\par Κλείνοντας θα θέλαμε να παρατηρήσουμε πως η παρούσα υλοποίηση θεωρούμε ότι ήταν μια προσπάθεια να ισορροπήσουμε μεταξύ των ζητηθέντων και μεταξύ πρακτικών που ίσως μας βοηθήσουν στη συνέχεια για συγγραφή ευκολότερου και καθαρότερου κώδικα.
Γενικά πιστεύουμε πως \textbf{αν ο χρήστης μιας βάσης κώδικα έχει τη δυνατότητα να χρησιμοποιήσει λανθασμένα τον κώδικα, κάποια στιγμή θα το κάνει.}
Ακόμα και αν ο χρήστης είναι ο ίδιος ο αρχικός συντάκτης του κώδικα.
Για το λόγο αυτό προσπαθήσαμε να περιορίσουμε, όπου αυτό δεν ήταν αντίθετο με τα ζητούμενα, την δυνατότητα της λανθασμένης χρήσης εισάγοντας αρκετά επιπλέον αντικείμενα και δομές ως εργαλεία για την εφαρμογή.
Ευχόμαστε να μην θεωρηθούν υπερβολικά.
\par Τέλος και ενώ προσπαθήσαμε να είμαι συνοπτικοί, παρατηρούμε πως ο αριθμός των σελίδων τις αναφοράς είναι ίσως μεγάλος.
Μια πιο λεπτομερή επεξήγηση όλων των στοιχείων(μεθόδους και δεδομένα) των αντικειμένων θα καθιστούσε τα πράγματα ακόμα χειρότερα.
Φυσικά ο αναγνώστης μπορεί να ανατρέξει στα σχόλια του κώδικα ή ακόμα καλύτερα στην τεκμηρίωσή του που περιλαμβάνεται στο παραδοτέο σε μορφή\eng{html}, για οποιαδήποτε αποσαφήνιση.
