Πως δομούμε ένα Project?

[IHateLove]

Πως δομούμε ένα Project, δηλαδή

- τι ονόματα επιλέγουμε για τις κλάσεις

- τι θα πρέπει να κάνει κάθε κλάση(κάτω--)

- τι θα πρέπει να προσέξουμε στους τύπους των μεταβλητών

- τι θα πρέπει να αποφεύγεται (Tips)

 

Έστω ότι θέλουμε να μοντελοποιήσουμε το εξής:

Τον παίχτη ο οποίος εκτός από το Όνομα/Level (Τα βασικά) έχει και μερικά Abilities (Attack/Defense)

 

Τα Abilities θα υπάρχουν στην κλάση Player ή θα είναι ξεχωριστά, πως θα ενσωματωθούν/χρησιμοποιηθούν στη κλάση Player

 

κάποιο σχετικό link ή ότι γνωρίζει ο καθένας

[Re4cTiV3]

Τον παίχτη ο οποίος εκτός από το Όνομα/Level (Τα βασικά) έχει και μερικά Abilities (Attack/Defense)

 

Δεν ξέρω πολύ καλά αλλά κάλιστα μπορείς να βάλεις τα abilities στα basic χαρακτηριστηκά του Player. Αφού όντως είναι στα βασικά χαρακτηριστηκά!

 

Τα Abilities θα υπάρχουν στην κλάση Player ή θα είναι ξεχωριστά, πως θα ενσωματωθούν/χρησιμοποιηθούν στη κλάση Player

 

Αυτό ονομάζεται κληρονομικότητα κλάσεων στο προγραμματισμό.

[Timonkaipumpa]

Η δόμηση ενός project εξαρτάται από το τι project είναι, την κρισημότητά του (σε χρόνο) και το πλήθος των μελών της ομάδας.

 

Από ό,τι κατάλαβα, εσύ αναφέρεσαι σε κάποιο παιχνίδι, τύπου RPG συν ότι σου λείπουν κάποιες βασικές γνώσεις OOP.

 

Υπάρχουν πολλές τακτικές δόμησης και οργάνωσης, με κύριο στοιχείο διαφοράς την ταχύτητα ανάπτυξης και τον έλεγχο του project.

 

Δεν μπορώ να καταλάβω όμως κάτι παραπάνω για να σε βοηθήσω.

[defacer]

Αυτό που ρωτάς δεν λέγεται δόμηση του project αλλά αρχιτεκτονική του software. "Δόμηση του project" για μένα παραπέμπει σε πιο οργανωτικής φύσης ζητήματα (π.χ. ποιά θα είναι τα βήματα που ακολουθούνται για να κάνεις ένα full build) και όχι τόσο σε "προγραμματιστικά" θέματα.

 

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

1. Οι "σωστές" απαντήσεις περιλαμβάνουν τόσα πολλά if/then/else που για να τις αφομοιώσεις απαιτείται ένα μίνιμουμ επίπεδο, το οποίο εφόσον χρειάζεται να κάνεις την ερώτηση είναι φανερό ότι δεν κατέχεις ακόμα.
   
2. Επειδή μιλάμε για πράγματα στα οποία δεν υπάρχει μία σωστή απάντηση για όλες τις περιπτώσεις, οι σωστές κατευθύνσεις πάντα έχουν από πίσω και μία δικαιολόγηση. Το θέμα είναι ότι όταν σου πει κάποιος "αυτό το κάνεις έτσι γιατί DRY" ή ότι "αυτό είναι λάθος γιατί παραβιάζει την LSP", εσύ καλείσαι όχι μόνο να έχεις καταλάβει έμπρακτα για ποιό λόγο είναι καλό το DRY και η LSP αλλά επίσης και να κρίνεις αν αυτό που ακούς έχει βάση ή όχι (τα παραδείγματα που επέλεξα είναι από τα εύκολα επειδή πάντα έχουν βάση, υπάρχουν όμως πολλά πράγματα που έχουν νόημα μόνο κατα περίπτωση). Αυτό απαιτεί εμπειρία. Εμπειρία αποκτάς γράφοντας κώδικα και με κανέναν άλλο τρόπο.
   
3. Αν πας σε ένα χτίστη όντας άσχετος και σου κάνει 2 μέρες σεμινάριο για το χτίσιμο και μετά πας να χτίσεις κάτι μόνος σου το αποτέλεσμα θα είναι για να γελάσει και το παρδαλό κατσίκι (προφανώς). Το ίδιο ισχύει και με τον προγραμματισμό.
   

Γενικά λοιπόν το point μου είναι πως δεν υπάρχει περίπτωση να πάρεις χρήσιμη πρακτικά απάντηση στις ερωτήσεις όπως τις έχεις θέσει.

 

Αν σ' ενδιαφέρει το θέμα, σου προτείνω τα εξής:

1. Βρες κάποια blogs/sites που έχουν "καλό υλικό" και παρακολούθησέ τα. Όταν φτάνεις στο σημείο να πεις ότι "πλέον δεν υπάρχει κάτι χρήσιμο για μένα εδώ", αφήνεις ένα απ' αυτά και προσανατολίζεσαι σε πιο "δύσκολα".
   
2. Διάβασε βιβλία. Κάποια διαμάντια όπως το The Pragmatic Programmer, το Code Complete και το Design Patterns (aka "Gang of Four" και "GoF" book) θα σου ανοίξουν τα μάτια.
   
3. Γράψε κώδικα. Αν δεν το κάνεις αυτό δε θα πας πουθενά. Ο κώδικας που θα γράψεις σήμερα, σε ένα χρόνο θα (πρέπει να) σου φαίνεται λιγότερο όμορφος από μπαγιάτικα ξερατά. Αυτό είναι καλό.
   

Τέλος, και πιο άμεσα εφαρμόσιμο στην ερώτησή σου:

 

Γράψε τον κώδικα μόνος σου και μετά postαρέ τον μαζί με μια εκτενή (όσο πιστεύεις ότι χρειάζεται) ανάλυση του γιατί επέλεξες να το κάνεις έτσι. Μ' αυτό τον τρόπο όχι μόνο θα καταλάβεις μόνος σου συγκεκριμένα πού έχεις αδυναμίες (π.χ. δε μπορείς να δικαιολογήσεις μια απόφαση που πήρες) αλλά θα μπορούμε και μεις να κρίνουμε αυτά που γράφεις και να προτείνουμε εναλλακτικές. Δεν υπάρχει κάτι που θα σε βοηθήσει περισσότερο από το να παρακολουθείς πώς αναπτύσσεται το δικό σου thought process vs το thought process κάποιου έμπειρου πάνω σε ένα χειροπιαστό και ταυτόχρονα περιορισμένης έκτασης (απαραίτητο για να μπορεί να ακολουθήσει ο λιγότερο έμπειρος) παράδειγμα.

[imitheos]

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

1. Οι "σωστές" απαντήσεις περιλαμβάνουν τόσα πολλά if/then/else που για να τις αφομοιώσεις απαιτείται ένα μίνιμουμ επίπεδο, το οποίο εφόσον χρειάζεται να κάνεις την ερώτηση είναι φανερό ότι δεν κατέχεις ακόμα.
   
2. Επειδή μιλάμε για πράγματα στα οποία δεν υπάρχει μία σωστή απάντηση για όλες τις περιπτώσεις, οι σωστές κατευθύνσεις πάντα έχουν από πίσω και μία δικαιολόγηση. Το θέμα είναι ότι όταν σου πει κάποιος "αυτό το κάνεις έτσι γιατί DRY" ή ότι "αυτό είναι λάθος γιατί παραβιάζει την LSP", εσύ καλείσαι όχι μόνο να έχεις καταλάβει έμπρακτα για ποιό λόγο είναι καλό το DRY και η LSP αλλά επίσης και να κρίνεις αν αυτό που ακούς έχει βάση ή όχι (τα παραδείγματα που επέλεξα είναι από τα εύκολα επειδή πάντα έχουν βάση, υπάρχουν όμως πολλά πράγματα που έχουν νόημα μόνο κατα περίπτωση). Αυτό απαιτεί εμπειρία. Εμπειρία αποκτάς γράφοντας κώδικα και με κανέναν άλλο τρόπο.
   
3. Αν πας σε ένα χτίστη όντας άσχετος και σου κάνει 2 μέρες σεμινάριο για το χτίσιμο και μετά πας να χτίσεις κάτι μόνος σου το αποτέλεσμα θα είναι για να γελάσει και το παρδαλό κατσίκι (προφανώς). Το ίδιο ισχύει και με τον προγραμματισμό.
   

Γενικά λοιπόν το point μου είναι πως δεν υπάρχει περίπτωση να πάρεις χρήσιμη πρακτικά απάντηση στις ερωτήσεις όπως τις έχεις θέσει.

+1

 

1. Διάβασε βιβλία. Κάποια διαμάντια όπως το The Pragmatic Programmer, το Code Complete και το Design Patterns (aka "Gang of Four" και "GoF" book) θα σου ανοίξουν τα μάτια.
   

@defacer: Το C Interfaces and Implementations θα τον βοηθήσει λες για αρχή ή πάλιωσε πολύ πια ?

 

1. Γράψε κώδικα. Αν δεν το κάνεις αυτό δε θα πας πουθενά. Ο κώδικας που θα γράψεις σήμερα, σε ένα χρόνο θα (πρέπει να) σου φαίνεται λιγότερο όμορφος από μπαγιάτικα ξερατά. Αυτό είναι καλό.
   

 

Το πιο σημαντικό. Καλό το θεωρητικό διάβασμα αλλά δεν γράψεις κώδικα δεν γίνεται δουλειά. Εγκατέστησε και ένα git / mercurial και αποθήκευε κάθε βελτιωμένη έκδοση του κώδικα για να βλέπεις εύκολα τι αλλαγές έκανες και τι κώδικα έγραφες παλιά

 

Γράψε τον κώδικα μόνος σου και μετά postαρέ τον μαζί με μια εκτενή (όσο πιστεύεις ότι χρειάζεται) ανάλυση του γιατί επέλεξες να το κάνεις έτσι. Μ' αυτό τον τρόπο όχι μόνο θα καταλάβεις μόνος σου συγκεκριμένα πού έχεις αδυναμίες (π.χ. δε μπορείς να δικαιολογήσεις μια απόφαση που πήρες) αλλά θα μπορούμε και μεις να κρίνουμε αυτά που γράφεις και να προτείνουμε εναλλακτικές. Δεν υπάρχει κάτι που θα σε βοηθήσει περισσότερο από το να παρακολουθείς πώς αναπτύσσεται το δικό σου thought process vs το thought process κάποιου έμπειρου πάνω σε ένα χειροπιαστό και ταυτόχρονα περιορισμένης έκτασης (απαραίτητο για να μπορεί να ακολουθήσει ο λιγότερο έμπειρος) παράδειγμα.

 

+1

 

Πολλές φορές σου έρχεται κάτι στο μυαλό το οποίο δεν είναι και τόσο σωστό και όταν το ξαναβλέπεις μετά λες τι σκεφτόμουν τότε. Θα σε βοηθήσει να δικαιολογείς την κάθε απόφαση που παίρνεις και φυσικά θα εκμεταλλευτείς και τα σχόλια που θα λάβεις εδώ για αυτήν την δικαιολόγηση. Κάτι σαν το Rubber Duck Debugging δηλαδή αλλά με πολλούς Rubber Ducks οπότε καλύτερο

 

ΥΓ: δεν την γλυτώνω την καταγγελία για διπλό λογαριασμό με τον defacer

[IHateLove]

δεν ψάχνω το απόλυτο, σίγουρα δεν υπάρχει κάτι που είναι 100% σωστό απλά θέλω μια γενική εικόνα

 

Γενικά έχω να πω ότι βλέπω διάφορες υλοποιήσεις(Projects) στο Internet που η μια κλάση εξαρτάται από άλλες 10,

(παράδειγμα) η κλάση Player εξαρτάται από άλλες 4-5 κλάσεις οι οποίες κλάσεις αυτές θα μπορούσαν να μην είναι ξεχωριστές κλάσεις (Abilities)

 

Αυτό θέλω να πω, "οι κλάσεις πρέπει να ασχολούνται αυστηρά μόνο με 1 πράγμα"?

 

Είμαι αρκετά μπερδεμένος στο στήσιμο, πως να ξεχωρίσω τα δεδομένα δηλαδή και έλεγα μήπως υπάρχει κάποιο σχετικό Tutorial όπως πχ για τα ονόματα μεταβλητών (στο άλλο θρεαντ που είπες)

[imitheos]

Γενικά έχω να πω ότι βλέπω διάφορες υλοποιήσεις(Projects) στο Internet που η μια κλάση εξαρτάται από άλλες 10,

(παράδειγμα) η κλάση Player εξαρτάται από άλλες 4-5 κλάσεις οι οποίες κλάσεις αυτές θα μπορούσαν να μην είναι ξεχωριστές κλάσεις (Abilities)

 

Αυτό θέλω να πω, "οι κλάσεις πρέπει να ασχολούνται αυστηρά μόνο με 1 πράγμα"?

 

Είμαι αρκετά μπερδεμένος στο στήσιμο, πως να ξεχωρίσω τα δεδομένα δηλαδή και έλεγα μήπως υπάρχει κάποιο σχετικό Tutorial όπως πχ για τα ονόματα μεταβλητών (στο άλλο θρεαντ που είπες)

 

Ο κάθε προγραμματιστής έχει διαφορετικό στυλ γραψίματος για αυτό βλέπεις διαφορετικές υλοποιήσεις.

 

Πολλά μεγάλα projects που απαρτίζονται από πολλούς προγραμματιστές βγάζουν, για να μη γίνεται χαμός, ένα "style guide" όπως αυτά που παρέθεσα παρακάτω. Αυτοί οι οδηγοί αναφέρουν τι στοίχιση θα ακολουθείται για να μην βάζουν άλλοι space και άλλοι tab, πως θα ονομάζονται οι μεταβλητές που ανέφερες και εσύ, ποια στοιχεία της γλώσσας θα χρησιμοποιούνται και άλλα τέτοια.

 

Εδώ, εδώ, εδώ μπορείς να δεις κάποια στυλ από project σε python, c++, c αντίστοιχα.

 

Αυτοί οι οδηγοί όμως είναι ένας μπούσουλας για να βοηθήσουν τους έμπειρους προγραμματιστές του project. Ο προγραμματιστής μετά έχει την κρίση να χρησιμοποιήσει τον οδηγό εκεί που πρέπει. Για παράδειγμα μια τοπική μεταβλητή που δρα ως loop counter δεν χρειάζεται να λέγεται iloop_counter αλλά μπορεί απλά να λέγεται i και όλοι θα καταλάβουν τι κάνει. Το ίδιο όμως δεν ισχύει για μια global μεταβλητή που θα προσπελαστεί από 10 μεριές.

 

Αυτό που θέλω να πω είναι ότι εφόσον είσαι μπερδεμένος δεν αρκεί να σου παραθέσουμε 3-4 τέτοιους οδηγούς και είσαι οκ. Υπάρχουν βιβλία όπως αυτά που πρότεινε ο defacer που σου διδάσκουν ένα σωστό τρόπο σκέψης και πως να υλοποιείς διάφορους αλγορίθμους, patterns, κτλ. Συμπληρωματικά με τα βιβλία μπορείς να διαβάσεις και κάποιο καλογραμμένο project να δεις πως το "δόμησαν" αυτοί.

 

Ελπίζω να μη σε μπέρδεψα περισσότερο

 

Σημείωση: Περίμενε να ακούσεις και από άτομα με περισσότερες γνώσεις πάνω στο θέμα από εμένα. Κάποια παιδιά από το φόρουμ είναι διακοπές αυτή τη περίοδο.

[Timonkaipumpa]

δεν ψάχνω το απόλυτο, σίγουρα δεν υπάρχει κάτι που είναι 100% σωστό απλά θέλω μια γενική εικόνα

 

Γενικά έχω να πω ότι βλέπω διάφορες υλοποιήσεις(Projects) στο Internet που η μια κλάση εξαρτάται από άλλες 10,

(παράδειγμα) η κλάση Player εξαρτάται από άλλες 4-5 κλάσεις οι οποίες κλάσεις αυτές θα μπορούσαν να μην είναι ξεχωριστές κλάσεις (Abilities)

 

Αυτό θέλω να πω, "οι κλάσεις πρέπει να ασχολούνται αυστηρά μόνο με 1 πράγμα"?

 

Είμαι αρκετά μπερδεμένος στο στήσιμο, πως να ξεχωρίσω τα δεδομένα δηλαδή και έλεγα μήπως υπάρχει κάποιο σχετικό Tutorial όπως πχ για τα ονόματα μεταβλητών (στο άλλο θρεαντ που είπες)

 

 

Από αυτά που λες μέχρι να φτάσεις στο πως θα ονομάσεις τις μεταβλητές είναι αρκετός δρόμος.

 

Σχετικά με τις κλάσεις.... εάν θες να φτιάξεις κάτι δικό σου από την αρχή, θα πρέπει να κατανοήσεις και να προβλέψεις τι έχεις σε ένα υψηλό και αφαιρετικό επίπεδο. Αφού το κάνεις αυτό, μετά θα πρέπει να δεις την συσχέτιση των πραγμάτων που έχεις έτσι ώστε να οργανώσεις καλά τις σχέσεις τους. Αφού οργανωθούν αυτά, μετά θα ήταν καλό να ονομάσεις κύριες μεθόδους και ορίσματα και να δεις τι ανήκει σε τι. Αφού γίνει αυτό, ξανακάνεις ένα revision του τι έχεις φτιάξει και το αλλάζεις έτσι ώστε να γίνει όσο το δυνατόν καλύτερο. Μετά, μπορείς να ασχοληθείς με τις ονομασίες μεταβλητών και το γράψιμο...

 

Όμως, για να προβλέψεις τι θες, θα πρέπει να γνωρίζεις πώς θα υλοποιηθεί αυτό που θες και τι τεχνολογία υπάρχει ήδη. Δηλαδή, δεν είναι ανάγκη κανείς να γράφει υλοποίηση βασικών πραγμάτων εάν υπάρχει έτοιμη. Κανείς δεν βρίσκει τον τροχό για να φτιάξει ένα αμάξι. Παίρνει τον τροχό έτοιμο. Όπως παίρνει και το τιμόνι, το radio, την πόρτα κτλ. Για αυτό ένας απλός player έχει "σύνδεση" με όσες κλάσεις είπες (παράδειγμα είναι, δεν ξέρω ακριβώς που αναφέρεσαι αλλά ελπίζω να καταλαβαίνεις τι λέω).

 

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

 

Ο λόγος για να το κάνεις αυτό... είναι πολλοί. Λόγοι δηλαδή . Ο πιο κύριος, για εμένα, είναι η εύκολη επέμβαση και αντικατάσταση όπου χρειαστεί. Πράγμα που οδηγεί σε εύκολη συντήρηση, ανανέωση και μεταφερσιμότητα.

 

Το εάν θα ονομάσεις μία μεταβλητή myVariable ή my_variable ή md_myVariable ή mdMyVariable ή ή ή... είναι το λιγότερο αρκεί να είσαι συνεπής σε ό,τι διαλέξεις.

 

Υ.Γ. Σχετικά με τις κλάσεις...

Στην απλή περίπτωση της ανταλλαγής δεδομένων μεταξύ δύο οντοτήτων..

Μία κλάση κάνει την ανταλλαγή. Ένα πράγμα είναι η ανταλλαγή. Όμως, δεν θα πρέπει να ελέγχεται η ασφάλεια; Δεν θα πρέπει να υπάρχει ένα κοινό interface για την ανταλλαγή; Δεν θα πρέπει τα δεδομένα που ανταλλάσσονται να είναι consistent;

 

Ή, στην περίπτωση που έχεις κάποιες οντότητες που χρησιμοποιείς, έστω τα toons των παικτών, δεν θες αυτά να επικοινωνούν με τον έξω κόσμο; Όμως, μία δουλειά δεν είναι η διαχείριση του toon; Αλλά, για κάθε ένα θα γράφεις ξανά και ξανά και ξανά τις μεθόδους για την επικοινωνία ή θα υλοποιήσεις ένα interface που θα είναι κοινό για όλα;

 

Πώς μπορείς να ξέρεις τι interface θα πρέπει να έχεις εάν δεν τα οργανώσεις; Εάν δεν κάνεις σωστή αναγνώριση οντοτήτων, σωστή οργάνωση σχέσεων και σωστή οργάνωση επικοινωνίας των; Πώς μπορείς να ξέρεις την βέλτιστη οργάνωση εάν δεν γνωρίζεις μηχανισμούς υλοποίησης των πραγμάτων που θες από γλώσσες προγραμματισμού; Πώς μπορείς να βρεις τους μηχανισμούς αυτούς εάν δεν ξέρεις τι πράγματα θες;

[psychasthenix]

Αν θέλεις διάβασε αυτή τη σειρά των posts : http://therealkatie....og/tags/pygame/

 

Περιγράφει πως έστησε ένα rogue-like RPG. Δε σημαίνει ότι αυτό που κάνει είναι το βέλτιστο. Απλά θα σου δώσει να καταλάβεις λίγο τον τρόπο σκέψης και οτι παίζει πολύ το βλέποντας και κάνοντας (μέχρι να αποκτήσεις εμπειρία τουλάχιστον).

[IHateLove]

θανκς τους 2 από πάνω μου, κατατοπιστικές οι πληροφορίες

 

θα σταθώ λίγο εδώ

ΥΓ: Από πάνω, θα το δω το λινκ αλλά θα προτιμούσα κάτι σε C/C# (τέσπα)

 

>
class Player(object):
   """The player class. Contains level, HP, stats, and deals with combat."""
   def __init__(self):
       self.level = 1
       self.attack = 5
       self.defense = 5
       self.current_hp = 10
       self.strength = 1
       self.name = "Dudeguy McAwesomesauce"

   @property
   def max_hp(self):
       return 10 + (self.level-1)*5

   @property
   def get_defense(self):
       return 1

   def receive_damage(self, damage):
       self.current_hp -= damage

   def attempt_block(self, attack):
       pass

   def get_attack(self):
       return self.strength

 

 

Νομίζω ότι έχω δίκαιο που λέω από μέσα ότι τα Abilities (Attack/Defense) έχουν να κάνουν με τον παίχτη και θα πρέπει να είναι στην ίδια κλάση που είναι και τα άλλα (EXP/Level/Gold)

 

Ερώτηση 2:

εδώ https://www.assembla.com/code/ES/subversion/nodes/Trunk/src/main/java/com/l2jfree/gameserver/model/actor/instance/L2PcInstance.java βλέπουμε ότι κάνει load από τη βάση διάφορα πράγματα που έχουν να κάνουν με τον παίχτη (skills, stats)

 

το ερώτημα είναι, να γίνουν τα πάντα load στο "EnterWorld"; δηλαδή όταν μπαίνει ο παίχτης, ώστε να βρίσκονται στη μνήμη.

 

από την άλλη όμως σκέφτομαι ότι δεν πρέπει να υπάρχουν πράγματα που δεν χρησιμοποιούνται στη μνήμη, από την άλλη αν κάθε φορά που θες κάτι πας να το τραβήξεις από τη βάση, αυτό το πράγμα κοστίζει!;

 

PS: Η Python χρειάζεται κάποιο framework για να τρέξει, δηλαδή αν φτιάξω μια εφαρμογή και την βάλω σε ένα καθαρό PC θα τρέξει?

[Timonkaipumpa]

Κατά την γνώμη μου, τα abilities εφόσον χρησιμοποιούνται από όλους τους παίχτες αλλά θα πρέπει να έχουν και κάποια αρχική τιμή αναλόγως class και race, τότε θα πρέπει να είναι από μόνα τους μία κλάση.

 

Επίσης, εάν αναλόγως την κλάση, γίνεται διαφορετικό update στο level up στα abilities, τότε θα πρέπει να υπάρχει μία αυτόνομη οντότητα που θα είναι οι μέθοδοι διαχείρισης των abilities για κάθε κλάση.

[psychasthenix]

Είσαι σε windows/linux/mac? Μάλλον windows λόγω c#

 

Για την python στα windows πρέπει να την εγκαταστήσεις και να την προσθέσεις στο path (To Σεπτέμβρη θα βγει η python 3.3 και δε θα χρειάζεται πλέον η προσθήκη στο path). Το παραπάνω blog χρησιμοποιεί και μια extra βιβλιοθήκη, την pygame. Αυτήν θα πρέπει να την εγκαταστήσεις από μόνος σου σε όλα τα λειτουργικά.

 

Βασικά μην το μελετάς πάρα πολύ. Ξεκίνα να γράφεις. Καθώς δεν ξέρεις τι ακριβώς θέλεις να κάνεις, θα χρειαστεί να αλλάξεις το design στη συνέχεια 100%. Υπάρχουν πολλοί τρόποι να γράψεις ένα πρόγραμμα. Δεν υπάρχει ο "σωστός".

 

Αν σε ενδιαφέρει γενικά για Object Oriented δες και αυτό http://www.itmaybeahack.com/homepage/books/oodesign.html

[IHateLove]

Για την ώρα δεν έχω σκοπό να ασχοληθώ, απλά ρώτησα επειδή το ΧΝΑ έχει αρκετές ιδιαιτερότητες

θα πρέπει να έχεις το σωστό Framework και αρκετές φορές που κατεβάζω παιχνίδια μου χτυπάνε (έχω .NET Fw 4)

έλεγα να κάτσω να μάθω μερικά πράγματα σε XNA και μετά να το έκανα Convert το Project σε Python αλλά αφού και η python θέλει βιβλιοθήκες μάλλον δεν θα κάνω τον κόπο.

 

 

 

[lion2486]

Μια προσέγγιση...

rpgsim.zip

OOPproj_2010.pdf

[Star_Light]

@defacer εσυ καλα τα λες αλλα δεν σε εχω δει ποτε

να ποσταρεις δικο σου κωδικα και να τον συζητησεις....

 

γιατι ετσι ρε φιλε ?