Οργάνωση του κώδικα //"χρονικός" έλεγχος

[Alchemist`]

Καλησπέρα παίδες... Ο τίτλος δεν είναι και πολύ κατανοητός, αλλά δεν ήξερα και τι να γράψω... Έχω 2 γενικές ερωτήσεις:

 

1) Μπορείτε να μου πείτε μερικούς τρόπου για να οργανώσω καλύτερα των κώδικα σε ένα αντικειμενοστραφές πρόγραμμα? Και τι εννοώ... Στο παιχνίδι που φτιάχνω (για το οποίο σας έχω πρήξει ) έχω εκατοντάδες αντικείμενα, και εκατοντάδες γραμμές κώδικα... Πολλά αντικείμενα χρησιμοποιούν ίδια κομμάτια κώδικα, οπότε έφτασα στο να χρησιμοποιώ script... Το θέμα είναι πως ακόμη και έτσι ο κώδικας (ως προς την ανάγνωση και κατανόηση) είναι ένα μπάχαλο, και θέλω να τον συμμαζέψω...

 

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

 

Εσείς ποιές μεθοδολογίες χρησιμοποιείται για την τακτοποίηση του κώδικά σας? Έχω αρχίσει σιγά-σιγά να περνάω σε script διάφορες λειτουργίες, πράγμα που είναι αρκετά χρονοβόρο... Είναι καλό αυτό? Η θα γίνει ακόμη μεγαλύτερο μπάχαλο ως προς την κατανόηση? Ελπίζω να κατανοείτε το ερώτημα μου...

 

2) Πολλές φορές έχω το εξής πρόβλημα:

-Αντικείμενο Α (σε τυχαίο σημείο του κώδικά του), δημιουργεί το αντικείμενο Β, στον κύκλο επεξεργασίας 1.

-Στον ίδιο κύκλο το Α δίνει κάποιες μεταβλητές στο Β (π.χ. την τιμή Β.direction = 0), οι οποίες είναι απαραίτητες για την "λειτουργία" του Β, και απαιτούνται για την εκτέλεση λειτουργιών κατα την δημιουργία του

-Μόλις τρέχω το πρόγραμμα, μου βγάζει σφάλμα πως η μεταβλητή direction του αντικειμένου Β δεν έχει οριστεί.

 

Αυτό που καταλαβαίνω ότι συμβαίνει είναι, πως στο κύκλο επεξεργασίας 1 του αντικειμένου Α το αντικείμενο Β απλώς δημιουργείται, και θα αρχίσει ουσιαστικά να υπάρχει, ώστε να μπορεί να λάβει τιμές, από τον κύκλο επεξεργασίας 2 του Α και έπειτα (τον αμέσως επόμενο δλδ), ο οποίος θα αποτελεί τον κύκλο επεξεργασίας 1 για το ίδιο το Β. Ισχύει κάτι τέτοιο? Πως μπορώ να ορίσω μεταβλητές σε ένα αντικειμένο κατά την δημιουργία του?

 

* Η συνάρτηση που δημιουργεί το αντικείμενο είναι η instance_create(x,y,obj_name), δεν μπορεί να δεχτεί παραμέτρους, ώστε να μεταφέρω τις τιμές που θέλω με τέτοιον τρόπο (όπως ας πούμε το χ και το y του αντικειμένου που δίνεται απευθείας από την συνάρτηση και αποτελούν arguments αυτής)...

 

Ελπίζω να μην σας κούρασα πολύ και να είμαι κατανοητός, ευχαριστώ προκαταβολικά!

[nspyrou]

Φιλαράκι έχεις μπλέξει άσχημα!!

 

Γιατί δεν κάνεις ένα Pause, να κάνεις μια καταγραφή των κλάσεων που έχεις φτιάξει, και να της τακτοποιήσεις ανά κάτι που σε βολεύει να θυμάσαι σχηματικά. Πχ, αν είναι για τα graphics, ρίχτα στα graphics, αν είναι για για το gameplay ρίχτα στο gameplay (λεμε τώρα πχ)! Ένα δεντράκι ιεραρχικό με τακτοποιημένα τα πραγματάκια στη θέση τους και να μη χτυπιέσαι και να ψάχνεσαι ...

 

Γνώμη μου!

 

Θα σου πάρει χρόνο βέβαια ... αλλά από το να χάσεις το μπούσουλα?!

 

Το 2 δεν το πολυ έπιασα ... να σου πω την αλήθεια ...

 

πχ: Σε κωδικα Delphi ...

 

Type TMyClass = class (TComponent)

 

public

LastName: String;

FirstName: String;

constructor Create( aOwner: TComponent; aFirstName: String; aLastName: String );

 

End;

 

Implementation

 

Constructor TMyClass.Create(aOwner: TComponent; aFirstName: String; aLastName: String )

begin

LastName := aLastName;

FirstName:= aFirstName;

end;

 

 

.... κατα την κλήση θα έχουμε:

 

Var

MyObject: TMyClass;

 

Begin

MyObject := TMyClass.Create( nil, 'Γιάννης', 'Μπαρμπούτσαλος' );

End.

 

Κατά την δημιουργία του αντικειμένου έχεις και τιμές αρχικοποίησης σε properties της κλάσης ...

 

Ελπίζω να σε κάλυψα ...

[Alchemist`]

Αυτό με το σχεδιάγραμμα δεν είναι κακή ιδέα...

Το θέμα πάντως με την GML που χρησιμοποιώ είναι πως έχει μια ιδιαιτερότητα... Κλάση = αντικείμενο. Δηλαδή, η κλάση ονομάζεται Object, ενώ το κάθε αντικείμενο ονομάζεται οντότητα (Instance) ενός Object. Με αποτέλεσμα πέρα από την διαφορά στην ονομασία, να υπάρχουν διαφορές και στην σύνταξη. Αυτό βέβαια είναι βολικό στην δημιουργία ενός παιχνιδιού, αφού οι 2 έννοιες αυτές ειναι πιο κοντά στην ουσιαστική και πρακτική χρησιμοποίησή τους στο παιχνίδι. Όταν υπάρχει μόνο ένα Instance ενός object στο παιχνίδι, τότε οι 2 έννοιες ταυτίζονται. Τέσπα...

 

Όσων αφορά το δεύτερο ερώτημα (ειληκρινά θα γράψω πολλά, αν βαριέσαι ΜΗΝ τα διαβάσεις). Ο κώδικάς μου είναι τόσο αντικειμενοστραφής, όσο και γεγονοστραφής (δεν θυμάμαι την ορολογία). Δηλαδή:

 

Υπάρχουν τα αντικείμενα (κλάσεις), οντότητες των οποίων (Instances) υπάρχουν μέσα στο δωμάτιο (room). Κάθε κομμάτι κώδικα, για να εκτελεστή από ένα Instance, πρέπει να γίνει και trigger από ένα γεγονός (event), όπως π.χ. το πάτημα ενός κουμπιού. Οπότε ένα Object, έχει μέσα του διάφορα blocks κώδικα, που θα εκτελεστούν σε κάθε σχετικό event. Ένα event είναι το "STEP", δηλαδή ο κύκλος επεξεργασίας, ένα step του επεξεργαστή.\

 

Και τώρα μετά την εισαγωγή, μπαίνουμε στο θέμα:

Έχουμε ένα το αντικείμενο NPC, το οποίο έχει την δυνατότητα να πυροβολεί. Και το αντικείμενο bullet, που είναι η σφαίρα.

Το αντικείμενο NPC σε κάποιο σημείο του κώδικα (δεν μας νοιάζει), που ανήκει στο event "STEP", δημιουργεί το αντικείμενο Β με τον εξής κώδικα:

 

own_bullet = instance_create(x,y,bullet_OBJ) //η μεταβλητή own_bullet κρατάει το μοναδικό ID, του instance που θα δημιουργηθεί από το αντικείμενο bullet

και μετά θέλω να δώσω στο σχετικό αντικείμενο κάποιες τιμές:

own_bullet.direction = direction + 180 + random(w_accuracy)*choose(-1,1)

own_bullet.power = weap_power

μπλά, μπλά μπλά...

 

Το αντικείμενο bullet τώρα στο event "create", (της δημιουργίας του) έχει κώδικα που εξαρτάται από αυτές τις τιμές που πήρε πριν, και οι εν λόγω μεταβλητές (direction, power κτλπ) χρησιμοποιούνται από τον κώδικα.

Μόλις πάω να το τρέξω μου πετάει σφάλμα, ότι η μεταβλητή π.χ. direction, είναι Unknown.

(Εδώ λοιπόν, υπάρχει ένα σχετικό ερώτημα, να ορίσω της μεταβλητές αυτές στο αντικείμενο bullet ξανά, ή εφόσων του τις δίνει το NPC δεν χρειάζεται? Εγώ δοκίμασα και τα 2 χωρίς αποτέλεσμα)

 

Αναλύοντας λοιπόν όσα είπα στο προηγούμενο μύνημα:

ΤΙ φαντάζομαι πως συμβαίνει:

Χρόνος 1: Το NPC δημιουργεί το bullet, και του μεταφέρει κάποιες τιμές

Χρόνος 2: Το bullet δημιουργείται τώρα αλλά δεν έχει πάρει τις τιμές, αφού δεν είχε δημιουργηθεί πριν

Χρόνος 3: Κώδικας στο bullet ζητάει τις μεταβλητές αυτές, οι οποίες όμως δεν έχουν λάβει τιμή

Δλδ από ότι καταλαβαίνει (γιατί δεν βρίσκω άλλη εξήγηση) όταν η Instance_create() ζητά την δημιουργία ενός αντικειμένο, αυτό "εμφανίζεται" στο αμέσως επόμενο step, και όχι σε αυτό που κλήθηκε.

 

Την ιδέα αυτή ισχυροπποιεί και ο πρόχειρος τρόπος λύσης που βρήκα, δηλαδή έβαλα timers στην δημιουργία των αντικειμένων, που ενεργοποιούν των κώδικα που δίνει τις τιμές, ένα step αργότερα. Μόνο έτσι δεν παίρνω σφάλματα, αλλά βαραίνει το παιχνίδι.

[RubiksCube]

Δεν μπόρεσα να τα διαβάσω όλα, αλλά από ότι φαίνεται έχεις μπλέξει με κώδικα που μοιάζει με μακαρονάδα. ;>

 

Γενικά μόνο μπορώ να σου πω ότι όταν φτιάχνεις ένα μεγάλο πρόγραμμα, πρέπει να ξοδέψεις ένα μεγάλο ποσοστό του χρόνου στο design. Γενικά αυτό που ρωτάς εμπίπτει στην κατηγορία του software engineering και των design patterns. Ψάγε το λίγο και θα καταλάβεις πόσο σημαντικό ρόλο παίζουν αυτά τα 2 πράγματα.

 

Επίσης μια καλή τεχνική προγραμματισμού είναι το modularization δηλαδή να έχεις όσο μπορείς ανεξάρτητες οντόντητες που διεκπαιρεώνουν μια δουλειά. Ανεξάρτητες σημαίνει ότι έχουν οσο το δυνατόν λιγότερα dependencies.

[Alchemist`]

Δεν μπόρεσα να τα διαβάσω όλα, αλλά από ότι φαίνεται έχεις μπλέξει με κώδικα που μοιάζει με μακαρονάδα. ;>

 

Γενικά μόνο μπορώ να σου πω ότι όταν φτιάχνεις ένα μεγάλο πρόγραμμα, πρέπει να ξοδέψεις ένα μεγάλο ποσοστό του χρόνου στο design. Γενικά αυτό που ρωτάς εμπίπτει στην κατηγορία του software engineering και των design patterns. Ψάγε το λίγο και θα καταλάβεις πόσο σημαντικό ρόλο παίζουν αυτά τα 2 πράγματα.

 

Επίσης μια καλή τεχνική προγραμματισμού είναι το modularization δηλαδή να έχεις όσο μπορείς ανεξάρτητες οντόντητες που διεκπαιρεώνουν μια δουλειά. Ανεξάρτητες σημαίνει ότι έχουν οσο το δυνατόν λιγότερα dependencies.

 

Μα όλο το παιχνίδι βασίζεται σε dependencies... Όλα ξεκινούν από το αντικείμενο global_ctrl το οποίο έχει μερικές βασικές μεταβλητές, απο εκεί έχουμε 4 αντικείμενα που βασίζονται σε αυτό (player, npc, ambient_items, bullets), και μετά υπάρχουν και άλλα αντικείμενα τα οποία βασίζονται σε αυτά τα 4. Οπότε με μικρές αλλαγές στο πρωταρχικό αντικείμενο, αλλάζει εύκολα το σκηνικό για όλα τα υπόλοιπα.

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

 

Υ.Γ. υπάρχει ένα θέμα οργάνωσης, αλλά όχι και μακαρονάδα

 

Y.Γ.2. Θα πάρω μολύβι και χαρτί όπως λέτε μου φαίνεται, και θα αρχίσω το ξέμπλεγμα.

[warchief]

>
[color="Green"]// η μεταβλητή own_bullet κρατάει το μοναδικό ID, του instance που θα δημιουργηθεί από το αντικείμενο bullet[/color]
own_bullet = instance_create(x,y,bullet_OBJ)

και μετά θέλω να δώσω στο σχετικό αντικείμενο κάποιες τιμές:

>
own_bullet.direction = direction + 180 + random(w_accuracy)*choose(-1,1)
own_bullet.power = weap_power
μπλά, μπλά μπλά...

Μόλις πάω να το τρέξω μου πετάει σφάλμα, ότι η μεταβλητή π.χ. direction, είναι Unknown.

(Εδώ λοιπόν, υπάρχει ένα σχετικό ερώτημα, να ορίσω της μεταβλητές αυτές στο αντικείμενο bullet ξανά, ή εφόσων του τις δίνει το NPC δεν χρειάζεται? Εγώ δοκίμασα και τα 2 χωρίς αποτέλεσμα)

 

Αυτό που καταλαβαίνω ειναι πως ο constructor του bullet_OBJ θέλει να έχει access σε attributes που η ανάθεση τους γίνεται αργότερα (πχ το direction).

 

Σε αυτη την περίπτωση είτε περνάς τις τιμές αυτές των attributes στον constructor (στην instance_create και απο εκει στον constructor) ειτε τροποποιείς τον constructor και του αφαιρείς την λειτουργικότητα εκεινη που χρειάζεται τα attributes. Ταυτόχρονα προσθέτεις νεα μέθοδο στο bullet_OBJ την οποία καλείς αφού έχεις κάνει assign τα attributes που χρειάζεται.

 

Ισως ένα πιο ευέλικτο σχήμα θα ήταν στον constructor του bullet_OBJ να αναθέτεις μια struct ή ένα class στο οποίο θα ομαδοποιείς configuration parameters. Ετσι κάθε φορά που θα θέλεις να προσθέσεις ένα νέο attribute στον constructor δεν θα χρειάζεται να του αλλάζεις το signature.

 

πχ

 

>

typedef struct cfg_params_s
{
   param1 = value,
   param2 = value,
   ...
} cfg_params;

Bullet_OBJ::Bullet_OBJ(const cfg_params & params)
{
   // Assign configuration parameters here
}

[RubiksCube]

Μα όλο το παιχνίδι βασίζεται σε dependencies...

 

Υ.Γ. υπάρχει ένα θέμα οργάνωσης, αλλά όχι και μακαρονάδα

 

Πλάκα έκανα με αυτόν τον όρο, άλλωστε τον χρησιμοποιώ και για δικό μου κώδικα πολλές φορές.

 

Όσο για τα dependencies, δεν είπα ότι δεν χρειάζονται καθόλου, απλά πολλές φορές υπάρχουν πολύ περισσότερα από όσα είναι απαραίτητα, και αυτό είναι θέμα design καθαρά.

 

Προφανώς έχεις αντικείμενα που πρέπει να επικοινωνούν μεταξύ τους με κάποιο τρόπο.

[nspyrou]

Θα συμφωνήσω με τα όσα σε προτρέπει ο φίλος RubiksCube πάνω στο θέμα του design και του modularization. Το design και το documentation δεν χρειάζεται μόνο για να μοιράσουμε την γνώση και τη λογική αλλά για να προφυλάξουμε και τον εαυτό μας απο το να τη ξεχάσει

 

Το πρόβλημα που αντιμετωπίζεις αυτή τη στιγμή, το έχω συναντήσει μόνο σε 1 περίπτωση, και απο τότε προσέχω πάρα πολύ τις δημιουργίες και καταστροφές των Instances των αντικειμένων μου:

 

Λόγω απροσεξίας, σε κάθε κύκλο του προγράμματος (loop) δημιουργούσα μια σειρά από αντικείμενα τα οποία γίνονταν Initialize με διάφορα δεδομένα. Μετά το δεύτερο ή τρίτο loop μου χτυπούσε μια ανάθεση τιμής σε ένα property, κάποιου τύπου κλάσης, μιας κλάσης καμιά 10αριά επίπεδα πιο πάνω (Abstract -> Inherited 1-> Inherited from Inherited κλπ ) οτι το property δεν έχει δημιουργηθεί ή δεν υπάρχει?! Ανακάλυψα μετά από τρελές ώρες οτι είχα ένα παραπανίσιο free σε κάποιο destructor (θα έλεγα οτι ήταν "φάρδος" που το βρήκα, γιατί εκεί που ήταν ... άστα).

 

Εκεί που θέλω να καταλήξω είναι οτι μπορεί να είναι απλώς και θέμα απροσεξίας. Προσπάθησε, με καθαρό μυαλό, να κάνεις ένα review του σφάλματος και ίσως τότε δεις κάτι που δεν βλέπεις τώρα ...

 

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

 

1. Θα είναι πιο ξεκάθαρα τα πράγματα στο μυαλό σου

2. Θα γνωρίζεις πού είναι τα πράγματα στο πρόγραμμά σου

3. Θα γλιτώσεις από το να ξαναματαφτιάχνεις κώδικα που πιθανώς τον έχεις κάπου χωμένο κάτω από εκατοντάδες άλλες γραμμές κώδικα ...

 

... και τα πλεονεκτήματα μπορούν να συνεχίζουν για ώρες!

[PCharon]

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

 

Τελικά είναι στον άνθρωπο πόσο οργανωμένος και αναγνώσιμος θα είναι ο κώδικας που γράφει. Ακόμα και με C (σκέτη) να γράφεις άμα θες τον κάνεις μια χαρά οργανωμένο και αναγνώσιμο.

 

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

 

Πάντως μια συμβουλή να δώσω (που μου την έδωσαν άλλοι πριν καιρό και διαπίστωσα την αξία της στην πράξη), μη θυσιάζετε άσκοπα τη διαισθητικότητα του κώδικα που γράφετε προκειμένου να γίνει πιο "optimized" ή απλά προκειμένου να δώσετε κάποιο προσωπικό στυλ ή να "σας αρέσει όπως το γράφετε με το δικό σας τρόπο". Πρέπει να υπάρχει μια ισορροπία σε αυτό και φυσικά δεν υπάρχει κανένας λόγος να κάνουμε insane optimization σε σημεία που καμία πρακτική επίδραση δε θα έχουν κατά την εκτέλεση.

Μου έχει τύχει να πιάσω λιγότερες από 50 γραμμές κώδικα που είχα φτιάξει 2 χρόνια πριν και να φάω πάνω από μισάωρο προκειμένου να καταλάβω πώς στα διάλα δούλευε ο αλγόριθμος που είχα μπροστά μου. Τέτοια τραγικά αποφύγετέ τα.

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

Τέλος αυτό που εφαρμόζω αρκετά τον τελευταίο καιρό είναι να σπάω τον κώδικα σε αρκετά αρχεία (με μέτρο βέβαια, βοηθάει πολύ πάντως).

[nspyrou]

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

 

Τελικά είναι στον άνθρωπο πόσο οργανωμένος και αναγνώσιμος θα είναι ο κώδικας που γράφει. Ακόμα και με C (σκέτη) να γράφεις άμα θες τον κάνεις μια χαρά οργανωμένο και αναγνώσιμο.

 

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

 

Πάντως μια συμβουλή να δώσω (που μου την έδωσαν άλλοι πριν καιρό και διαπίστωσα την αξία της στην πράξη), μη θυσιάζετε άσκοπα τη διαισθητικότητα του κώδικα που γράφετε προκειμένου να γίνει πιο "optimized" ή απλά προκειμένου να δώσετε κάποιο προσωπικό στυλ ή να "σας αρέσει όπως το γράφετε με το δικό σας τρόπο". Πρέπει να υπάρχει μια ισορροπία σε αυτό και φυσικά δεν υπάρχει κανένας λόγος να κάνουμε insane optimization σε σημεία που καμία πρακτική επίδραση δε θα έχουν κατά την εκτέλεση.

Μου έχει τύχει να πιάσω λιγότερες από 50 γραμμές κώδικα που είχα φτιάξει 2 χρόνια πριν και να φάω πάνω από μισάωρο προκειμένου να καταλάβω πώς στα διάλα δούλευε ο αλγόριθμος που είχα μπροστά μου. Τέτοια τραγικά αποφύγετέ τα.

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

Τέλος αυτό που εφαρμόζω αρκετά τον τελευταίο καιρό είναι να σπάω τον κώδικα σε αρκετά αρχεία (με μέτρο βέβαια, βοηθάει πολύ πάντως).

 

Μη το λες για τον οργανωμένο κώδικα!! Έεεεχωωω δείιιιι???!!!

Και απο ανθρώπους προ "υποτίθεται" οτι είναι και της ΑΣΟΕΕ (τρομάρα τους!). Όπως το είπες: Είναι στον άνθρωπο - στην εμπειρία, και θα πρόσθετα,, και στο προσωπικό στύλ! "Η πινελιά του καλλιτέχνη"

 

Πάντως έχεις δίκιο ...

[Alchemist`]

...

 

Δίκαιο έχεις ρε σύ, είναι θέμα ανθρώπου (είμαι γενικά ακατάστατοσ και ανοργάνωτος ), αλλά είναι και θέμα που επηρεάζεται και από το ίδιο το πρόγραμμα, τις αρχικές ιδέες κτλπ... Τι εννοώ...

Όταν ξεκίνησα να φτιάχνω ,μόνος μου σε αρχικά στάδια, το παιχνίδι, ήθελα να κάνω μια μηχανή για RPG στο στυλ Final Fantasy σε NES/SNES. Στην πορεία το "γύρισα" σε TDS. Πολλά πράγματα άλλαξαν, πολλές ιδέες έρχονται και ενσωματώνονται σε άκυρες στιγμές, ή αποτελλούν πράγματα που δεν είχαν προβλεφθεί πως θα υπάρχουν εξ αρχής... Για να γίνει αυτό που λές, πρέπει εκ των προτέρων να ξέρει κάποιος τι ακριβώς θα κάνει, πράγμα το οποίο, ιδιαίτερα σε μεγάλα Project, δεν είναι δεδομένο... Αποφάσεις που θα παρθούν αργότερα αλλάζουν όλο το σκηνικό σε μια στιγμή...

Παράδειγμα, εξ αρχής είχα αποφασίσει ότι το παιχνίδι δεν θα ήταν Mutliplayer. Τελικά άλλα άτομα με έπεισαν (και βοήθησαν πολυ στον τομέα). Φάγαμε λοιπόν 4 μέρες για να αλλάξουμε όλο τον κώδικα, γιατί απλά δεν είχα φανταστεί π.χ. ότι θα υπάρχουν πάνω από ένας παίκτες... Αλλιώς έπρεπε να σκέφτεται το Α.Ι., αλλιώς να επικοινωνεί ο παίκτης με κάποια global αντικείμενα και χίλια 2 άλλα.

 

Πάντως ξεκίνησα να κάνω σχεδιαγράμματα στο χαρτί... Θα πάρει καιρό, αλλά σίγουρα θα βοηθήσει. Ευχαριστώ για όλες τις απαντήσεις!

[RubiksCube]

...

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

 

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

 

Όποιος ενδιαφέρεται ας διαβάσει το The Mythical Man Month, από τα κλασσικά βιβλία για software engineering.

[asxoliastos]

Πρώτο μου post σε αυτό το forum.Καλώς σας βρήκα..

 

Το πρόβλημα ξεκινάει πάντα στην αρχή.Η σχεδίαση σου όπως καταλαβαίνεις είναι λάθος.

Το θέμα ειναι οτι στην αρχή θες να δεις αποτελέσματα και ή κάνεις violate το oop μοντέλο ή

δεν διαβλέπεις το τι θα έρθει αργότερα...

 

Προτείνω αρχικά rebuild from scratch αλλά πρώτα διάβασε αυτό για να είσαι σίγουρος στο τι πας να κανεις..

http://books.google.gr/books?id=uLU9k-mKvzoC&printsec=frontcover&dq=DESIGN+PATTERNS+FOR+DUMMIES&source=bl&ots=O6bGrjgcxp&sig=cXQNZLMbzkH4Bmexi5iyBgD5wY4&hl=el&ei=2U3JTOOQJsKUOpbD_cMB&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBUQ6AEwAA#v=onepage&q&f=false

 

Το official βιβλίο που εισάγει τα design patterns ειναι λίγο μεγάλο και δυσκολο στην ανάγνωση οπότε

προτείνω το παραπάνω μιας και διαβάζεται πιο γρήγορα και εύκολα και ειναι πλήρες...

O κώδικας που έχει ειναι σε java αλλά δεν έχει σημασία..Το point θα το καταλάβεις..

[MitsakosGR]

Πρώτο μου post σε αυτό το forum.Καλώς σας βρήκα..

 

Το πρόβλημα ξεκινάει πάντα στην αρχή.Η σχεδίαση σου όπως καταλαβαίνεις είναι λάθος.

Το θέμα ειναι οτι στην αρχή θες να δεις αποτελέσματα και ή κάνεις violate το oop μοντέλο ή

δεν διαβλέπεις το τι θα έρθει αργότερα...

 

Καταρχάς asxoliastos καλώς ήρθες!

Το κακό συνήθως δεν είναι η αρχή (καλά, εν μέρει είναι). Το ίδιο με τον Alchemist` κάνω και εγώ. Έχω μια γενική ιδέα του τι θέλω να φτιάξω και ξεκινάω. Ξέρω πως θα το υλοποιήσω κτλ αλλά στην πορεία έρχονται ιδέες για το πως να το κάνω καλύτερο ή να βάλω και κάτι διαφορετικό μέσα με αποτέλεσμα να χρειαστεί να αλλάξω πολλές φορές αυτά που έχω φτιάξει και να κάνω τον κώδικα εντελώς δυσανάγνωστο. Έχω διαγράψει πολλές φορές project επειδή έχω μπει σε αυτό το "τρυπάκι" και τα γράφω από το μηδέν...

Όπως είπε και ο RubiksCube είναι καταστροφή αυτό. Πιστεύω ότι όταν κάνεις μια αρχική σχεδίαση πρέπει να παραμείνεις σε αυτή. Απλά επειδή έρχονται πολλές ιδέες στην διάρκεια, τις καταγράφεις (μην τις ξεχάσεις κιόλας) και τις υλοποιείς αργότερα. Αυτό συνεπάγεται ότι πρέπει να έχεις εύκολα επεκτάσιμο κώδικα ή αρκετά επίπεδα λειτουργιών ώστε να μην επηρεάζει, τόσο πολύ, το ένα το άλλο.

 

Τώρα για το πώς θα οργανώσεις αυτά που έχεις φτιάξει θέλει ιδιαίτερη προσοχή και προσπάθεια. Πρόσεχε στην προσπάθειά σου αυτή μην χαλάσεις αυτά που έχεις ήδη φτιάξει.

Μία γενική ιδέα, δεν ξέρω κατά πόσο σε βολεύει, αλλά θα μπορούσες να χρησιμοποιήσεις Friend classes και functions για να έχουν πρόσβαση σε στοιχεία από αρκετές classes και να εξυπηρετούν κάποιες από τις δουλειές των script.

[m1cRo]

Καταρχάς asxoliastos καλώς ήρθες!

Το κακό συνήθως δεν είναι η αρχή (καλά, εν μέρει είναι). Το ίδιο με τον Alchemist` κάνω και εγώ. Έχω μια γενική ιδέα του τι θέλω να φτιάξω και ξεκινάω. Ξέρω πως θα το υλοποιήσω κτλ αλλά στην πορεία έρχονται ιδέες για το πως να το κάνω καλύτερο ή να βάλω και κάτι διαφορετικό μέσα με αποτέλεσμα να χρειαστεί να αλλάξω πολλές φορές αυτά που έχω φτιάξει και να κάνω τον κώδικα εντελώς δυσανάγνωστο. Έχω διαγράψει πολλές φορές project επειδή έχω μπει σε αυτό το "τρυπάκι" και τα γράφω από το μηδέν...

Όπως είπε και ο RubiksCube είναι καταστροφή αυτό. Πιστεύω ότι όταν κάνεις μια αρχική σχεδίαση πρέπει να παραμείνεις σε αυτή. Απλά επειδή έρχονται πολλές ιδέες στην διάρκεια, τις καταγράφεις (μην τις ξεχάσεις κιόλας) και τις υλοποιείς αργότερα. Αυτό συνεπάγεται ότι πρέπει να έχεις εύκολα επεκτάσιμο κώδικα ή αρκετά επίπεδα λειτουργιών ώστε να μην επηρεάζει, τόσο πολύ, το ένα το άλλο.

 

Τώρα για το πώς θα οργανώσεις αυτά που έχεις φτιάξει θέλει ιδιαίτερη προσοχή και προσπάθεια. Πρόσεχε στην προσπάθειά σου αυτή μην χαλάσεις αυτά που έχεις ήδη φτιάξει.

Μία γενική ιδέα, δεν ξέρω κατά πόσο σε βολεύει, αλλά θα μπορούσες να χρησιμοποιήσεις Friend classes και functions για να έχουν πρόσβαση σε στοιχεία από αρκετές classes και να εξυπηρετούν κάποιες από τις δουλειές των script.

 

Προφανώς και είναι λάθος η σχεδίαση και μάλλον η διάσπαση του όλου project σε classes και libraries, από εκεί και προβλήματα. Το βασικότερο στον αντικειμενοστραφή προγραμματισμό είναι να βγάλεις τις σωστές κλάσεις που περιγραφουν τον κόσμο σου, γιατί ο προγραμματισμός είναι η περιγραφή του κόσμου και όχι τις συμπεριφοράς του. Όταν για κάποιο λόγο σου εμφανίζονται κλάσεις που κάνουν κάτι αντί να είναι κάτι αυτό σημαίνει ότι πάει κάτι στραβά, είμαι σίγουρος ότι αυτή είναι η περίπτωση του post starter.