RC: part A

This commit is contained in:
Christos Choutouridis 2020-10-28 18:18:17 +02:00
parent 5d8d06c793
commit 7dd8ede2f0
12 changed files with 97 additions and 35422 deletions

1
.gitignore vendored
View File

@ -1,6 +1,5 @@
bin/
doc/
out/
deliverable/
.classpath
.project

BIN
release/8997_PartA.zip Normal file

Binary file not shown.

2
report/.gitignore vendored
View File

@ -2,3 +2,5 @@
*.log
*.out
*.gz
*.svg
*.xcf

@ -1 +1 @@
Subproject commit 7a87aea1e30dfa311640d773207eb0e59da9cbdd
Subproject commit 3612ad227e11b056579910354c58c6973652f7ef

Binary file not shown.

Before

Width:  |  Height:  |  Size: 538 KiB

After

Width:  |  Height:  |  Size: 527 KiB

File diff suppressed because it is too large Load Diff

Before

Width:  |  Height:  |  Size: 2.5 MiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 263 KiB

After

Width:  |  Height:  |  Size: 267 KiB

File diff suppressed because it is too large Load Diff

Before

Width:  |  Height:  |  Size: 50 KiB

Binary file not shown.

View File

@ -21,6 +21,7 @@
\setFancyHeadLR{\ClassName}{\DocTitle}
%\setFancyHeadLERO{\ClassName}{\DocTitle}
%\BottomTitleSpace{8em}
% Document
% =================
@ -35,7 +36,7 @@
\section{Εισαγωγή}
Η παρούσα εργασία αφορά τη δημιουργία ενός παιχνιδιού λαβυρίνθου με θέμα \textit{“Μια νύχτα στο μουσείο”}.
Στο συγκεκριμένο παιχνίδι καλούμαστε να δημιουργήσουμε ένα λαβύρινθο μέσα στον οποίο κινούνται με τυχαίο τρόπο δύο παίχτες, ο Θησέας και ο Μινώταυρος.
Στόχος του Μινώταυρου είναι να “πιάσει” τον Θησέα και στόχος του Θησέα είναι να βρει όλα τα εφόδια που είναι τυχαία κατανεμημένα στο ταμπλό πριν ξημερώσει και πριν τον πιάσει ο Μινώταυρος.
Στόχος του Μινώταυρου είναι να “πιάσει” τον Θησέα και στόχος του Θησέα είναι να βρει όλα τα εφόδια που είναι τυχαία κατανεμημένα στο ταμπλό, πριν ξημερώσει και πριν τον πιάσει ο Μινώταυρος.
Στο παιχνίδι αυτό υπάρχουν δύο βασικά προβλήματα τα οποία χρειάζεται να λύσουμε.
Το πρόβλημα της δημιουργίας του λαβύρινθου και το πρόβλημα της λειτουργίας των παιχτών και του υπόλοιπου παιχνιδιού.
@ -51,13 +52,11 @@
Για παράδειγμα οι παίχτες δεν μπορούν να περάσουν μέσα από τοίχους, ή οι παίχτες κινούνται κατά ένα πλακίδιο τη φορά κλτ.
Σε αντίθεση με το πρόβλημα του ταμπλό εδώ η λύση ήταν τετριμμένη.
\section{Παραδοτέα}
Τα επισυναπτόμενα παραδοτέα αποτελούνται από:
\begin{itemize}
\item Τον \eng{\textbf{root}}κατάλογο στον οποίο υπάρχει και το \eng{project}του\eng{eclipse.}
\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.}
Το αρχείο ρυθμίσεων του \eng{doxygen}είναι στον \eng{root} με το όνομα \eng{Doxyfile.}
@ -73,7 +72,8 @@
\subsection{\eng{Accessor - mutator idiom}}
Στις προδιαγραφές της εργασίας αφήνεται να εννοηθεί πως ζητείται η χρήση του \eng{\textit{accessor - mutator idiom.}}
Θα πρέπει να παραδεχτούμε όμως, πως \textbf{θεωρούμε το συγκεκριμένο ιδίωμα ιδιαίτερα προβληματικό}.
Ο κύριος λόγος είναι πως παραβιάζει θεμελιακά τις αφαιρέσεις δίνοντας πρόσβαση στην εσωτερική δομή του αντικειμένου.
Ο κύριος λόγος είναι πως παραβιάζει θεμελιακά τις αφαιρέσεις προδίδοντας τον εσωτερικό σχεδιασμό του αντικειμένου.
Ακόμα δίνει πρόσβαση στην εσωτερική δομή του “πίσω από την πλάτη” του αντικειμένου.
Εν αντιθέτως με το ιδίωμα αυτό, \textbf{τα αντικείμενα που υλοποιούνται ως αφαιρέσεις μπορούν να προσφέρουν μεθόδους που εκτελούν κάποια λειτουργία, κρύβοντας τελείως τις εσωτερικές λεπτομέρειες της υλοποίησης}.
Αυτός είναι και ο δρόμος που διαλέξαμε για το σχεδιασμό του προγράμματος.
Η κάθε τάξη του προγράμματός μας προσφέρει δημόσια ένα αριθμό από μεθόδους που είναι απαραίτητες για την εκάστοτε απαιτούμενη λειτουργικότητα και κρύβει όσο καλύτερα γίνεται την εσωτερική υλοποίηση.
@ -84,7 +84,7 @@
Ένα καρτεσιανό που διευθυνσιοδοτεί ως προς δύο άξονες και περιέχει ένα ζευγάρι γραμμής και στήλης και ένα μονοδιάστατο που αποτελείται από τον γραμμικό συνδυασμό των προηγουμένων.
Το μονοδιάστατο αντικατοπτρίζει και την απεικόνιση στη μνήμη ενός πίνακα 2 διαστάσεων σε \eng{row major order.}
\par Γενικά θεωρούμε ότι κάτι τέτοιο δημιουργεί πλεονασμό δεδομένων και επομένως είναι κακή πρακτική.
\par Γενικά θεωρούμε πως κάτι τέτοιο δημιουργεί πλεονασμό δεδομένων και επομένως είναι κακή πρακτική.
Αυτό γιατί μεταξύ άλλων μειονεκτημάτων, που κυρίως αφορά τον πολυνηματικό προγραμματισμό, οδηγεί και σε προγραμματιστικά λάθη που πιθανώς θα αφήνουν τα δύο συστήματα ασυγχρόνιστα.
Για να λύσουμε αυτό το πρόβλημα \textbf{δημιουργήσαμε την τάξη \eng{Position,}}στην οποία εσωτερικά χρησιμοποιούμε μόνο το ένα από τα δύο συστήματα, για την ακρίβεια το μονοδιάστατο και ταυτόχρονα παρέχουμε μεθόδους για την πρόσβαση στη θέση και από τα δύο συστήματα.
Η τάξη μεταξύ άλλων προσφέρει και \textbf{στατικές μεθόδους για τις μετατροπές} προσφέροντας έτσι μια είδους εργαλειοθήκη για την εφαρμογή.
@ -93,9 +93,9 @@
\subsection{Αναβάθμιση της τάξης \eng{Tile}}
Κατά τον προγραμματισμό του παιχνιδιού παρατηρήσαμε πως τόσο η τάξη \eng{Tile}όσο και η \eng{Supply}έχουν πληροφορίες για τη θέση τους στο ταμπλό.
Αυτό σημαίνει πως τόσο τα πλακίδια όσο και τα εφόδια ανήκουν στο ταμπλό.
Ακόμα σημαίνει πως δημιουργούν επιπλέον πλεονασμό σε δεδομένα, καθώς απαιτούνται οι συντεταγμένες των εφοδίων μέσα στην\eng{Supply.}
Ακόμα σημαίνει πως δημιουργούν επιπλέον πλεονασμό σε δεδομένα, καθώς απαιτείται οι συντεταγμένες των εφοδίων να επαναληφθούν μέσα στην \eng{Supply.}
Κάτι τέτοιο γίνεται αντιληπτό και από τις προδιαγραφές της \eng{Board}η οποία είναι αυτή που περιέχει τους πίνακες αναφορών τόσο των πλακιδίων όσο και των εφοδίων.
\textbf{Μια ποιο διαισθητική προσέγγιση βέβαια θα ήθελε τα εφόδια να ανήκουν στα πλακίδια} και όχι στο ταμπλό.
\textbf{Μια πιο διαισθητική προσέγγιση βέβαια θα ήθελε τα εφόδια να ανήκουν στα πλακίδια} και όχι στο ταμπλό.
Με αυτό τον τρόπο η τάξη \eng{Supply}δεν θα είχε τις επαναλαμβανόμενες πληροφορίες θέσης, αλλά αντίθετα η τάξη \eng{Tile}θα είχε μια επιπρόσθετη πληροφορία για το αν υπάρχει εφόδιο ή όχι.
\par Όπως είναι φυσικό θελήσαμε να υλοποιήσουμε αυτή την προσέγγιση.
@ -124,7 +124,11 @@
Στο σχήμα \ref{fig:concepts} φαίνεται μια οπτικοποιημένη έκδοση τους.
\subsection{Πλακίδιο φρουρός - \textit{\eng{isSentinel()}}}
\WrapFigure{0.5}{r}{fig:concepts}{images/concepts.png}{Οπτική αναπαράσταση των\eng{concepts}που χρησιμοποιούμε σε ένα ταμπλό $7x7$}
\WrapFigure{0.45}{r}{fig:concepts}{images/concepts.png}{
Οπτική αναπαράσταση των \eng{concepts}που χρησιμοποιούμε σε ένα ταμπλό $7x7$.
Με πράσινο αναπαρίστανται όσα πληρούν κάποιο \eng{concept}και με κόκκινο όσα όχι.
Τα πλακίδια με το γκρι χρώμα, είναι τα πλακίδια φρουροί.
}
Πρόκειται για \eng{concept}που μας επιτρέπει να ελέγξουμε αν το πλακίδιο είναι \textit{”πλακίδιο φρουρός”}.
Αν δηλαδή βρίσκεται στα εξωτερικά άκρα του ταμπλό.
Η υλοποίηση αυτού του \eng{concept}γίνεται μέσω τεσσάρων συναρτήσεων που ελέγχουν χωριστά τις τέσσερεις διευθύνσεις του ταμπλό.
@ -158,7 +162,7 @@
\subsection{Χτίσιμο πλακίδιο - \textit{\eng{isWallable()}}}
Πρόκειται για \eng{predicate}που μας επιτρέπει να ελέγξουμε αν κάποιο πλακίδιο είναι \textit{”χτίσιμo πλακίδιο”}.
Αν δηλαδή μπορούμε σε κάποια πλευρά του πλακιδίου να τοποθετήσουμε τοίχο.
Αν δηλαδή υπάρχει κάποια πλευρά του πλακιδίου στην οποία μπορούμε να τοποθετήσουμε τοίχο.
Για να ισχύει αυτό θα πρέπει:
\begin{itemize}
\item Το πλακίδιο να μην έχει ήδη τον μέγιστο επιτρεπτό αριθμό τοίχων.
@ -174,19 +178,19 @@
Θέλαμε λοιπόν ένα τρόπο αναπαράστασης των τοίχων που να βολεύει για το συγκεκριμένο πρόβλημα.
Η λύση που χρησιμοποιήσαμε συνοψίζεται στα εξής:
\begin{itemize}
\item Οι διασταυρώσεις ανάμεσα στα πλακίδια ονομάζονται κόμβοι και η θέση τους αναπαρίστανται μονοδιάστατα σαν διεύθυνση σε\eng{row majer order.}
\item Οι γωνίες των πλακιδίων ονομάζονται κόμβοι και η θέση τους αναπαρίστανται μονοδιάστατα σαν διεύθυνση σε \eng{row major order.}
\item Ο κάθε κόμβος αποτελεί τον κόμβο-γωνία \eng{(vertex)}ενός γράφου.
\item Ο κάθε τοίχος αναπαρίσταται ως ακμή στον γράφο.
\end{itemize}
Για παράδειγμα ένας τοίχος αριστερά του πλακιδίου `3` αναπαρίσταται ως η ακμή `(4,8)`,
Στο σχήμα \ref{fig:graph} φαίνεται ένα παράδειγμα αναπαράστασης.
Για παράδειγμα στο σχήμα \ref{fig:graph}, που φαίνεται και ένα παράδειγμα αναπαράστασης, ο τοίχος αριστερά του πλακιδίου `3` αναπαρίσταται ως η ακμή `(4,8)`.
\InsertFigure{0.6}{fig:graph}{images/graph.png}{
\\(α) Διευθυνσιοδότηση πλακιδίων(τετραγωνάκια) και κόμβων(σφαίρες) ενός ταμπλό $3x3$.\\
(β) Ένας συνεκτικός γράφος που προκύπτει από το (α) ξεκινώντας από τον τοίχο (7, 11).
Ο τοίχος είναι αυτός για τον οποίο θέλουμε να διαπιστώσουμε αν δημιουργεί κλειστό δωμάτιο.
}
\par Για τον αλγόριθμο υλοποιήσαμε δύο αντικείμενα.
Το\eng{\textbf{Edge}}που δημιουργεί ζευγάρια κόμβων ώστε να μπορεί να αποθηκεύσει τον κάθε τοίχο(ακμή) και το\eng{\textbf{Graph}}που προσφέρει λειτουργίες δημιουργίας συνεκτικού γράφου λαμβάνοντας ως είσοδο τοίχους(ακμές).
\par Για τον αλγόριθμο υλοποιήσαμε δύο τάξεις.
Την \eng{\textbf{Edge}}που δημιουργεί ζευγάρια κόμβων ώστε να μπορεί να αποθηκεύσει τον κάθε τοίχο(ακμή) και την \eng{\textbf{Graph}}που προσφέρει λειτουργίες δημιουργίας συνεκτικού γράφου λαμβάνοντας ως είσοδο τοίχους(ακμές).
\par Η λειτουργία του είναι απλή.
Κάθε φορά που ελέγχουμε αν μία διεύθυνση πλακιδίου είναι \textit{χτίσιμη}, \textbf{δημιουργούμε το μεγαλύτερο δυνατό συνεκτικό γράφο που περιέχει τον εν λόγο τοίχο} και όλους τους ήδη τοποθετημένους τοίχους.
@ -210,7 +214,7 @@
\section{Υλοποίηση}
Για την μεταγλώττιση της εφαρμογής, απαιτείται \eng{java} έκδοση 8 ή και μεταγενέστερη καθώς έχουμε κάνει χρήση \eng{lambdas.}
Όσων αφορά την υλοποίηση, εκτός από τα ζητηθέντα αντικείμενα υλοποιήσαμε και τα παρακάτω.
Όσο αφορά την υλοποίηση, εκτός από τα ζητηθέντα αντικείμενα υλοποιήσαμε και τα παρακάτω.
\begin{itemize}
\item \eng{\textbf{Const}}\\
Το αντικείμενο αυτό περιέχει σταθερές για όλη την εφαρμογή.
@ -219,7 +223,7 @@
\item \eng{\textbf{Direction}}\\
Το αντικείμενο αυτό λειτουργεί σαν \eng{C++ enumerator}και παρέχει ονοματολογία στις διευθύνσεις που χρησιμοποιούμε στην εφαρμογή.
\item \eng{\textbf{DirRange}}\\
Ομοίως ένα βοηθητικό αντικείμενο αυτή τη φορά για την δημιουργία σε βρόχους επανάληψης.
Ομοίως ένα βοηθητικό αντικείμενο αυτή τη φορά για την αυτόματη δημιουργία διευθύνσεων σε βρόχους επανάληψης.
\item \eng{\textbf{Edge}}\\
Το αντικείμενο αυτό όπως είδαμε και στην ενότητα \ref{sec:isRoomCreator}, λειτουργεί ως αναπαράσταση των τοίχων με τη μορφή ακμών ενός γράφου.
Προσφέρει \eng{constructor} που δέχεται για ορίσματα συντεταγμένες από πλακίδια και διευθύνσεις.
@ -230,7 +234,7 @@
Οι βασικές λειτουργίες είναι η \eng{\textit{attach()}}η οποία δέχεται μια ακμή και αν κάποιος κόμβος της ακμής ανήκει ήδη στο γράφο τότε τοποθετεί και τον άλλο.
Και η \eng{\textit{count()}}η οποία δέχεται ένα κόμβο και μετράει πόσες φορές ο κόμβος αυτός περιέχεται στον γράφο.
\item \eng{\textbf{Position}}\\
Το αντικείμενο αυτό χρησιμοποιείται για να παρέχει ένα ενοποιημένο σύστημα συντεταγμένων για όλη την εφαρμογή.
Το αντικείμενο αυτό χρησιμοποιείται ως ένα κοινό σύστημα συντεταγμένων για την εφαρμογή.
\item \eng{\textbf{Range}}\\
Το αντικείμενο χρησιμοποιείται για να δημιουργεί εύρη τιμών.
Για παράδειγμα ο κώδικας παρακάτω δημιουργεί ένα \eng{range} με όλες τις διευθύνσεις.
@ -254,24 +258,24 @@
\end{verbatim} \selectlanguage{greek}
\end{itemize}
Τόσο η \eng{Range}όσο και η \eng{ShuffledRange}έχουν μια μέθοδο \eng{\textit{get()}}η οποία επιστρέφει και αφαιρεί το πρώτο στοιχείο από το \eng{range}.
Όταν δεν έχουν άλλα στοιχεία επιστρέφουν την τιμή φρουρό\eng{EOR - End of Range.}
Όταν το \eng{range}είναι άδειο τότε επιστρέφει την τιμή φρουρό \eng{EOR - End of Range.}
\par Τα υπόλοιπα αντικείμενα είναι τα ζητηθέντα.
Σε αυτά δεν έχουμε αλλάξει τις προδιαγραφές πέρα από τις \eng{\textit{createBoard()}}και \eng{\textit{createSupply()}}στις οποίες προσθέσαμε σαν ορίσματα τα πλακίδια του Θησέα και του Μινώταυρου.
Ο λόγος είναι γιατί για τα εφόδια θέλουμε να γνωρίζουμε σε ποια πλακίδια είναι οι παίχτες, ώστε να μην τοποθετήσουμε εκεί κάποιο εφόδιο.
Για το ταμπλό γιατί θέλουμε να ξέρουμε σε ποια πλακίδια θα τοποθετήσουμε τους παίχτες.
Σε αυτά δεν έχουμε αλλάξει τις προδιαγραφές με εξαίρεση τις μεθόδους \eng{\textit{createBoard()}}και \eng{\textit{createSupply()}}στις οποίες προσθέσαμε σαν ορίσματα τα πλακίδια του Θησέα και του Μινώταυρου.
Ο λόγος είναι γιατί για τα εφόδια, θέλουμε να γνωρίζουμε σε ποια πλακίδια είναι οι παίχτες, ώστε να μην τοποθετήσουμε εκεί κάποιο εφόδιο.
Δε για το ταμπλό, γιατί θέλουμε να ξέρουμε σε ποια πλακίδια θα τοποθετήσουμε τους παίχτες.
\section{Εκτελέσιμο}
Όπως αναφέραμε και στην παράγραφο με τα παραδοτέα, σε αυτά υπάρχει και το παραγόμενο εκτελέσιμο για την γραμμή εντολών.
Πρόκειται για ένα\eng{jar}αρχείο το οποίο μπορεί κάποιος να εκτελέσει σε ένα τερματικό μέσω της εντολής \eng{\texttt{java -jar labyrinth}}.
Πρόκειται για ένα \eng{jar}αρχείο το οποίο μπορεί κάποιος να εκτελέσει σε ένα τερματικό, μέσω της εντολής \eng{\texttt{java -jar labyrinth}}.
\InsertFigure{0.5}{fig:executable}{images/screenshot.png}{
Στιγμιότυπο από την εκτέλεση του προγράμματος σε \eng{interactive mode}και με αποφυγή κλειστών δωματίων.
Η εντολή που χρησιμοποιήθηκε είναι \eng{\texttt{java -jar labyrinth -i -{}-norooms}}
}
Στον κώδικά μας χρησιμοποιούμε\eng{asserion}ώστε να ελέγξουμε την είσοδο και τις επιλογές του χρήστη.
Στον κώδικά μας χρησιμοποιούμε \eng{asserions}ώστε να ελέγξουμε την είσοδο και τις επιλογές του χρήστη.
Επομένως αν κάποιος θέλει να πειραματιστεί με τις επιλογές καλό θα ήταν να τα ενεργοποιήσει στην \eng{VM}της \eng{java}με την παράμετρο \eng{\texttt{-ea}.}
Σε αυτή την περίπτωση θα μπορούσε να εκτελέσει \eng{\texttt{java -ea -jar labyrinth -i --norooms ...}}
Σε αυτή την περίπτωση θα μπορούσε να εκτελέσει \eng{\texttt{java -ea -jar labyrinth -i --norooms ...etc}}
\par Το παραγόμενο \eng{jar}παρέχει ένα αριθμό από επιλογές-ορίσματα τα οποία ελέγχουν την λειτουργία του παιχνιδιού.
Τις επιλογές αυτές μπορούμε να δούμε και από την γραμμή εντολών απλώς εκτελώντας την εντολή \eng{\texttt{java -jar labyrinth -h}}.
@ -313,21 +317,22 @@
\section{Παρατηρήσεις}
Σε αυτό το σημείο θα θέλαμε να παρατηρήσουμε και μια σχεδιαστική αβλεψία.
Το σύστημα του κώδικα που δημιουργεί χρήστες καθώς και ορισμένες επιλογές που τους αφορούν, όπως η θέση τους στο ταμπλό, οι κινήσεις κα, δεν είναι υλοποιημένο με τον καλύτερο δυνατό τρόπο.
Το κομμάτι του κώδικα που δημιουργεί χρήστες καθώς και ορισμένες επιλογές που τους αφορούν, όπως η θέση τους στο ταμπλό, οι κινήσεις κ.α., δεν είναι υλοποιημένο με τον καλύτερο δυνατό τρόπο.
Θα θέλαμε να ήταν πιο γενικό και παραμετροποιήσιμο.
Ο λόγος που δεν είναι, έχει να κάνει αρκετά και με την υποψία πως αυτό το υποσύστημα θα χρειαστεί να αλλάξει αρκετά στις επόμενες εργασίες.
Ο λόγος που δεν είναι, έχει να κάνει αρκετά και με την υποψία μας, πως αυτό το υποσύστημα θα χρειαστεί να αλλάξει αρκετά στις επόμενες εργασίες.
Αν εκτιμήσαμε λανθασμένα, τότε είναι απλώς κρίμα.
\par Μια τεχνική που δεν χρησιμοποιήσαμε αλλά μας προβλημάτισε αν θα το κάναμε ή όχι ήταν τα \eng{generics.}
Η αρχική μας σκέψη, καθώς ήμαστε επηρεασμένοι ξεκάθαρα από την \eng{C++,}ήταν οι τάξεις \eng{Edge, Graph, Range}και \eng{ShuffledRange}να είναι \eng{generics.}
Το γεγονός όμως ότι τα αντικείμενα αυτά θα τα χρησιμοποιούσαμε μονάχα σε αυτή την εργασία, μας απέτρεψε.
Μια απλή υλοποίηση μόνο για \eng{int}ήταν αρκετή και κάτι διαφορετικό θα εισήγαγε περιττή πολυπλοκότητα.
\par Κλείνοντας θα θέλαμε να παρατηρήσουμε πως η παρούσα υλοποίηση θεωρούμε ότι ήταν μια προσπάθεια να ισορροπήσουμε μεταξύ των ζητηθέντων και μεταξύ πρακτικών που ίσως μας βοηθήσουν στη συνέχεια για συγγραφή ευκολότερου και καθαρότερου κώδικα.
Γενικά πιστεύουμε πως \textbf{αν ο χρήστης μιας βάσης κώδικα έχει τη δυνατότητα να χρησιμοποιήσει λανθασμένα τον κώδικα, κάποια στιγμή θα το κάνει.}
Ακόμα και αν ο χρήστης είναι ο ίδιος ο αρχικός συντάκτης του κώδικα.
Για το λόγο αυτό προσπαθήσαμε να περιορίσουμε, όπου αυτό δεν ήταν αντίθετο με τα ζητούμενα, την δυνατότητα της λανθασμένης χρήσης εισάγοντας αρκετά επιπλέον αντικείμενα και δομές ως εργαλεία για την εφαρμογή.
Ευχόμαστε να μην θεωρηθούν υπερβολικά.
\par Τέλος και ενώ προσπαθήσαμε να είμαι συνοπτικοί, παρατηρούμε πως ο αριθμός των σελίδων τις αναφοράς είναι ίσως μεγάλος.
Μια πιο λεπτομερή επεξήγηση όλων των στοιχείων(μεθόδους και δεδομένα) των αντικειμένων θα καθιστούσε τα πράγματα ακόμα χειρότερα.
Φυσικά ο αναγνώστης μπορεί να ανατρέξει στα σχόλια του κώδικα ή ακόμα καλύτερα στην τεκμηρίωσή του που περιλαμβάνεται στο παραδοτέο σε μορφή\eng{html}, για οποιαδήποτε αποσαφήνιση.
Τέτοια για παράδειγμα είναι η τάξη \eng{Position}ή η αποφυγή των \eng{setters}κτλ.
Ελπίζουμε να μην θεωρηθούν υπερβολικά.
% References
% ============================

View File

@ -194,7 +194,7 @@ class Range {
int get () {
if (!numbers.isEmpty())
return numbers.remove(0);
return Const.noTileId;
return Const.EOR;
}
/** @name protected data types */

View File

@ -10,11 +10,29 @@
/**
* @mainpage A labyrinth board game
*
* @section intro_sec Introduction
* This is a console game, played by 2 players. The Theseus and Minotaur.
* The Minotaur goal is to capture Theseus. The Theseus's goal is to collect
* all the supplies of the board before Minotaur catches him and before the
* game ends.
*
* This is the introduction.
* In this first assignment we deal with the board's creation and a basic
* player-game logic. The game is build around a number of classes:
* - \ref Tile
* - Supply
* - Board
* - Player
* - Game
*
* etc...
* Which are the requested classes. We also provide some extra functionalities in:
* - Const
* - Session
* - Direction
* - DirRange
* - Edge
* - Graph
* - Position
* - Range
* - ShuffledRange
*/
package host.labyrinth;