Latency Δημοσ. 3 Οκτωβρίου 2012 Μέλος Δημοσ. 3 Οκτωβρίου 2012 NA! Πάλι κόλλησα! να φτιάξω συναρτήσεις Increase/Decrease/Set -> μεγαλύτερο πρόγραμμα να φτιάξω μια συνάρτηση για όλα αυτά και να κανονίσω στην παράμετρο? -> δύσχρηστο, και πρόβλημα με εύρεση ονόματος το AddHP δεν είναι κατάλληλη επιλογή όταν θέλουμε να κατεβάσουμε ζωή.... παω οφφ
Timonkaipumpa Δημοσ. 3 Οκτωβρίου 2012 Δημοσ. 3 Οκτωβρίου 2012 Επίσης, θα μπορούσα να προτείνω την υλοποίηση της επικοινωνίας των toons με τον κόσμο ως interface (κοινό για όλα τα toons), τα stats ως κλάση κοινή για όλα τα toons και τα toons ως inherited κλάσεις από την γενική κλάση CToons, η οποία θα υλοποιεί το interface για την επικοινωνία με τον έξω κόσμο και θα έχει ως aggregated class την κλάση CStats. (λέω τώρα εγώ... )
defacer Δημοσ. 3 Οκτωβρίου 2012 Δημοσ. 3 Οκτωβρίου 2012 (να φτιάξω συναρτήσεις Increase/Decrease/Set -> μεγαλύτερο πρόγραμμα) => λάθος τρόπος σκέψης Σοβαρά τώρα. Γράψε ένα πρόγραμμα με τις 3 αυτές συναρτήσεις και κάντο compile. Κράτα το εκτελέσιμο στην άκρη. Μετά σβήσε τις 2 και ξανακάντο compile. Σύγκρινε το εκτελέσιμο με το προηγούμενο και πες μας τι έγινε. Και αυτό χωρίς να εξετάσουμε καν αν μας πειράζει η τυχόν διαφορά μεγέθους. ------ Παλιότερα το μεγαλύτερο πρόβλημα στον προγραμματισμό ήταν να χωρέσουν αυτά που θέλουμε στους περιορισμένους πόρους του hardware της εποχής. Αυτές οι εποχές πέρασαν (εκτός κι αν γράφεις για embedded). Σήμερα το μεγαλύτερο πρόβλημα είναι η διαχείριση της πολυπλοκότητας του software. Και τότε και τώρα, "σωστός προγραμματισμός" είναι αυτός που ξεκινάει με σκοπό την αντιμετώπιση του μεγαλύτερου προβλήματος.
migf1 Δημοσ. 3 Οκτωβρίου 2012 Δημοσ. 3 Οκτωβρίου 2012 Η δική μου πρόταση είναι να διαλέξεις μια OOP γλώσσα που θέλεις να μάθεις και κατόπιν να ψάξεις να βρεις ένα καλό βιβλίο για αυτή την γλώσσα και να το διαβάσεις. Ιδανικά κάποιο που θα περιέχει και υλοποίηση εύστοχων και ενδιαφέροντων μικρών projects (δυστυχώς δεν ξέρω να σου υποδέιξω κάποιο εγώ, σίγουρα όμως θα βρεθεί κόσμος να σου υποδείξει). Έτσι όπως το έχεις ξεκινήσει, από ότι γράφεις, δεν δείχνει να σε βγάζει πουθενά. Το πιθανότερο είναι να τα παρατήσεις όντως περισσότερο μπερδεμένος από ότι όταν ξεκίνησες το project. Μέσα σε 2 ημέρες έχεις ρωτήσει στο φόρουμ για C++, για C# και για Java. Υποθέτω πως όλα αφορούσαν αυτό το μίνι RPG που θέλεις να κάνεις. Προσωπικά το θεωρώ απίθανο να φτάσεις σε επιθυμητό αποτέλεσμα με αυτή την προσέγγιση. Αν πάλι δεν σε ενδιαφέρει η εκμάθηση OOP μέσω μιας γλώσσας που το υποστηρίζει εγγενώς, δλδ απλώς θέλεις να φτιάξεις ένα μίνι-rpg απλώς για να δείς περίπου τι παίζει, θα σου πρότεινα να το κάνεις σε μια γλώσσα που ξέρεις ήδη, με την οποία αισθάνεσαι άνετα κι έχεις και resources. Νομιζω όμως πως το πιο χρήσιμο από όλα είναι να ασχοληθείς να μάθεις OOP μέσω μιας δημοφιλούς γλώσσας, την οποία θα προσεγγίσεις μεθοδικά και υπομονετικά.
Latency Δημοσ. 3 Οκτωβρίου 2012 Μέλος Δημοσ. 3 Οκτωβρίου 2012 τι λέτε? Σημείωση: θα είναι ξεχωριστή κλάση "PClass", για την ώρα το αφήνω έτσι ΥΓ: τα δεδομένα θα φορτώνονται απο XML > void GetMinMaxHPMP(PlayerClass pClass) { switch (pClass) { case PlayerClass.Healer: MIN_HP = 1; MAX_HP = 1; MIN_MP = 1; MAX_HP = 1; break; } } enum PlayerClass { Wizard, Rogue, Tank, Healer, Undefined };
Latency Δημοσ. 3 Οκτωβρίου 2012 Μέλος Δημοσ. 3 Οκτωβρίου 2012 λύθηκε το θέμα με τα Decrease/Increase/Set http://codepaste.net/93cusg http://codepaste.net/2nhse8 http://codepaste.net/im9c8e
moukoublen Δημοσ. 3 Οκτωβρίου 2012 Δημοσ. 3 Οκτωβρίου 2012 Ερώτηση. Αν είχες μια μόνο συνάρτηση Add και άφηνες την φύση να κάνεις τα υπόλοιπα, δεν θα ήταν λίγο πιο απλά τα πράγματα; Δηλαδή: > public void AddHP(float posotita) { this.HP += posotita // ... } //... ... ... c1.AddHP(4) // increace 4 c1.AddHP(-4) // decrease 4 Αν η απάντηση σε αυτό είναι ναι, τότε μπορούμε να κάνουμε ενα βήμα ακόμα. Γιατί να έχουμε μέθοδο για κάτι τέτοιο όταν μπορούμε να έχουμε μια Poperty που μας δίνει καλύτερη "εμφάνιση"; > private float hp; public float Hp { get { return this.hp; } set { this.hp = value; if(hp > MAXHP) hp = MAXHP; // ... what ever ... ... ... } } // ... ... ... c1.Hp += 3; // Increase c1.Hp -= 3; // Decrease c1.Hp = 245; // Set Δεν κάνω τίποτα παραπάνω απο το να σου επαναλάβω αυτά που σου είπαν πριν, πιο ήρεμα και απλά. Γενικότερα σκέψου το εξής. Είναι μη-χρήσιμο να έχεις 2 συναρτήσεις ή εναν μηχανισμό διακλάδωσης που σε κάθε περίπτωση να κάνει το ίδιο πράγμα. Γιατι εκ των πραγμάτων είτε προσθέσεις είτε αφαιρέσεις έχεις κανει ακριβώς την ίδια πράξη (ξέχωρα που υπάρχει bug, δηλαδή τι θα γίνει αν δώσεις ο άλλος P1.UpdateHP(-5.0f, SetMode.INCREASE); ) Σημείωση. H property είναι ένα συντακτικό "κόλπο" της C#. Αν δεν αισθάνεσαι οικειότητα με αυτή και θέλεις να ασχοληθείς με C#, διάβασέ τη. Και γενικότερα. Διαβασε καλά όσα σου γράψανε εδω, και μείνε λίγο σε αυτό που σου είπε ο migf1, βρες ένα καλό/α βιβλίο/α στη γλώσσα - πλατφόρμα που θα επιλέξεις. Και εγώ θα προσθέσω, αν θες να ασχοληθείς σοβαρά με OOP βρες βιβλία γενικότερα για OOP analysis - desing κ.τ.λ.
Latency Δημοσ. 3 Οκτωβρίου 2012 Μέλος Δημοσ. 3 Οκτωβρίου 2012 θα το σκεφτώ, απλά έχω συνηθίσει με συναρτήσεις... έτσι και αλλιώς τον ίδιο κώδικα έχω "σε γραμμές" "ας πούμε" http://codepaste.net/93cusg κάτι έλεγα πάνω για BackgroundWorker, το δοκίμασα και δουλεύει http://tinypic.com/player.php?v=33z37ky&s=6 Γιατι εκ των πραγμάτων είτε προσθέσεις είτε αφαιρέσεις έχεις κανει ακριβώς την ίδια πράξη (ξέχωρα που υπάρχει bug, δηλαδή τι θα γίνει αν δώσεις ο άλλος P1.UpdateHP(-5.0f, SetMode.INCREASE); ) > // Update Player Health public void SetHP(float value, StatUpdateMode _Mode) { if (!isDEAD) { switch (_Mode) { case StatUpdateMode.Increase: HP += value; break; case StatUpdateMode.Decrease: HP -= value; break; case StatUpdateMode.Set: HP = value; break; } if (HP > Limits.MAX_HP) HP = Limits.MAX_HP; else if (HP < Limits.MIN_HP) { HP = 0.5f; isDEAD = true; } } else { //TODO: Print is dead message } } εδώ είμαστε... > if (HP > Limits.MAX_HP) HP = Limits.MAX_HP; else if (HP < Limits.MIN_HP) { HP = 0.5f; isDEAD = true; } για το Bug που λες , κάνει και άλλο πράγμα, κάνει το ανάποδο, δηλαδή μπορεί να του δηλώσεις Increase και να βάλεις -1 και να λειτουργεί ανάποδα εδώ είναι η λύση > if (!isDEAD) { value = Math.Abs(value); switch (_Mode) { //..... } //..... } xmmmm, μου αρέσει πιο πολύ απλά στις δηλώσεις πάνω δεν θέλω να βάλω μικρά γράμματα "hp", ή _HP.... έχω τέτοια κολλήματα, θα το σκεφτώ... > // Update Player Health public float _HP { get { return HP; } set { HP = value; if (HP > Limits.MAX_HP) HP = Limits.MAX_HP; else if (HP < Limits.MIN_HP) { HP = 0.5f; isDEAD = true; } } } ΥΓ: έτσι θα το κάνω αλλά δώστε καμιά ιδέα για τα ορίσματα, μάλλον θα βάλω όλα τα ορίσματα _Name και τα seters/geters Name (χωρίς _ δηλαδή)
moukoublen Δημοσ. 3 Οκτωβρίου 2012 Δημοσ. 3 Οκτωβρίου 2012 καταρχήν αν είναι να έχεις κάποιο πεδίο με _ τότε καλύτερα να είναι το private. Αλλά γενικότερα διάβασε ποιες είναι οι συμβάσεις γενικά στην C# και κινήσου με αυτές. Τα "κολλήματα" (και είναι κατι που πιστεύω και για εμένα) άστα για οταν θα έχεις 10+ χρόνια σοβαρής εμπειρίας στην ανάπτυξη λογισμικού. Τότε θα μπορείς να έχεις "κολλήματα". Τώρα απλά ακολούθα όσο πιο πιστά μπορείς τις συμβάσεις της κάθε κοινότητας και πλατφόρμας. 2
Timonkaipumpa Δημοσ. 3 Οκτωβρίου 2012 Δημοσ. 3 Οκτωβρίου 2012 Latency... με το συμπάθειο.. Κατηγόρησες πιο πριν τον defacer για τον τρόπο του όταν, τελικά, εσύ επιδεικνύεις ένα attitudde κάπως ... μυστήριο. Δεν είναι δυνατό να μην ξέρεις από OOP και να κάνεις τα πρώτα σου βήματα (και τα πρώτα εν γένει βήματα στον προγραμματισμό, όπως είπες) και να μιλάς για κολλήματα. Δεν θα σε βγάλει σε good practices και σίγουρα θα αυξήσει τον χρόνο που θα χρειαστείς για να μάθεις (όπως και το impact των λαθών σου). Και στην τελική.... και εάν κατάλαβα σωστά, εάν όχι συμπάθα με, εδώ μπήκες να γράψεις για βοήθεια. Αλλά μόνο αυτή δεν βλέπω να δέχεσαι. Φιλικά.
defacer Δημοσ. 3 Οκτωβρίου 2012 Δημοσ. 3 Οκτωβρίου 2012 Υπάρχουν αρκετά πράγματα που μπορείς να βελτιώσεις ακόμα και σε τόσο "απλό" κώδικα. #1: Η λύση με τη δεύτερη παράμετρο mode είναι κακή εκτός κι αν υπάρχει περίπτωση να μην είναι γνωστή η τιμή της statically. Τι εννοώ: αν υπάρχει περίπτωση το mode να έρχεται από μεταβλητή της οποίας δεν ξέρεις το περιεχόμενο (π.χ. γιατί προέκυψε από κάποιο υπολογισμό ή από κάποιο input του χρήστη) τότε μπορείς να το εξετάσεις σα λύση -- παρόλο που στη C# δε θα ήταν από τις πρώτες επιλογές μου κάτι τέτοιο. Αν δέν υπάρχει περίπτωση να είναι μεταβλητή και απλά θα το γράφεις πάντα hardcoded τότε απλά τα πράγματα περιπλέκονται χωρίς λόγο και καταλήγεις να γράφεις "φλύαρο" αντί για "καθαρό" κώδικα. #2: H λύση με το Add() είναι άπειρα καλύτερη από αυτό που κάνεις τώρα με το Abs. Εδώ δεν έχω να πω και πολλά. Σου έδωσα (τυχαίο) link παραπάνω για την DateTime.Add. Καλό είναι να καταλάβεις ότι ακόμα κι αν δε μπορείς να αντιληφθείς γιατί ακριβώς είναι καλό να αφήσεις τη δυνατότητα αρνητικών τιμών, κάνε όπως κάνουν αυτοί που ξέρουν και αφήνουν και την Add και την Subtract να έχουν είτε θετικές είτε αρνητικές τιμές. Θα καταλάβεις αργότερα. Επίσης η λύση του να βάλεις Abs() βγάζει και πάλι κάρτα το παρελθόν σου: δεν γίνονται έτσι τα πράγματα σε μοντέρνες OO γλώσσες όπως η C#. Πες ότι τη method την κάναμε σωστά και δεν έχει νόημα να παίρνει αρνητικές τιμές. Παρόλα αυτά ο χρήστης (δηλαδή ο προγραμματιστής που την καλεί, δηλαδή εσύ στην προκειμένη) τυχαίνει να την καλέσει με αρνητικές τιμές. Αυτό φανερά σημαίνει πως είτε δεν έχει καταλάβει ότι χρησιμοποιεί το εργαλείο λάθος, είτε το ξέρει αλλά το πρόγραμμά του έχει bug. Και στις δύο περιπτώσεις, κάτι πάει πολύ στραβά. Όταν κάτι πάει πολύ στραβά δε θέλεις να το "διορθώσεις" όπως όπως και να συνεχίσεις! Αυτό που θέλεις είναι να γίνει άμεσα αντιληπτό το ότι κάτι πήγε στραβά. And what do you know, υπάρχει "ειδικό" exception γι' αυτή την περίπτωση. Τυχαίο; Δε νομίζω. #3: Το "print is dead message" είναι ανάθεμα. Αν θέλεις να ρίξεις πυροτεχνήματα σ' αυτή την περίπτωση λανθασμένης χρήσης, κατά πλήρη αναλογία με τα παραπάνω εδώ είσαι. Σε καμία μα καμία περίπτωση μην κάνεις το λάθος να τυπώσεις τίποτα στην οθόνη ή κάτι παρόμοιο. Δεν είναι αυτό δουλειά του κώδικα που κανονίζει τα HP! #4: Ο BackgroundWorker είναι... πώς να το πω... τελείως λάθος προσέγγιση. Δεν είναι δυνατόν να τρως ένα thread κάθε φορά που θέλεις να βάλεις κάποιο buff. Δε φτάνουν για όλους. Είναι απίστευτα κακό από άποψη performance σε σχέση με σωστότερες εναλλακτικές (βέβαια στην προκειμένη δε θα το καταλάβεις φυσικά). Δεν μπορεί ο κώδικας εκει μέσα να συνεννοηθεί με τυχόν άλλα buffs που μπορεί να υπάρχουν in effect. Εκτός από πολύ απλές περιπτώσεις σαν αυτό που έκανες απλά δε θα μπορείς να το δουλέψεις έτσι. Και βέβαια όταν μαζευτούν 3-4 μαζί, ακόμα κι αν στα χαρτιά ο κάθε ένας μπορεί να δουλέψει ανεξάρτητα από τον άλλο στην πράξη θα μπερδευτούν μεταξύ τους. (φαντάζομαι αν συνεχίσω μπορώ να βρω διάφορα ακόμα προβλήματα) We saved the best for last: επειδή το timing των BackgroundWorkers είναι ανεξάρτητο από αυτό του update loop σου, η συμπεριφορά του προγράμματος δεν είναι πλέον ντετερμινιστική. Αν δεν καταλαβαίνεις τι σημαίνει αυτό, ψάξτο. Ελπίζω όλα αυτά που έχουν ειπωθεί σ' αυτό το thread να τα σκεφτείς και να τα λάβεις σοβαρά υπόψη. Και μια τελευταία συμβουλή: έχεις ένα χαρακτηριστικό που καλό είναι να διορθώσεις. Δηλαδή: βλέπεις πως κόσμος που ξέρει (π.χ. τα links που έδωσα στο MSDN) κάνουν τα πράγματα με κάποιον τρόπο. Υπάρχει λόγος που το κάνουν αυτό. Αν θέλεις να τραβήξεις το δικό σου δρόμο, you had better be able to explain why. Το "έτσι το προτιμώ" θα σε χαντακώσει. Και με την ευκαιρία, μήπως είδες το link που έδωσα παραπάνω περι coding conventions στο MSDN? Κατηγόρησες πιο πριν τον defacer για τον τρόπο του όταν, τελικά, εσύ επιδεικνύεις ένα attitudde κάπως ... μυστήριο. Τελικά κατάλαβα τι συνέβη εκεί... τον χάλασε το σχόλιο "Απλή λογική: ή όλοι αυτοί έχουν μεγαλύτερη άγνοια από σένα (που είσαι τελείως νέος) ή κάτι άλλο συμβαίνει" γιατί μπορείς να το εκλάβεις ως "έχεις άγνοια" (κάποιου βαθμού τουλάχιστον). Βεβαίως πέραν του ότι από την δική μου πλευρά αυτό ήταν statement of fact (και άρα μπορεί να ενοχλήσει όσο και το να πω πως βρωμάς, δηλαδή καθόλου: αν βρωμάς τότε βρωμάς, deal with it), η πλάκα είναι ότι το χρησιμοποίησα ακριβώς επειδή το είχε χρησιμοποιήσει πρώτος ο Latency προς τρίτους. Φαντάζομαι αν άλλοι άνθρωποι μπορούν να έχουν άγνοια τότε μπορώ να έχω και γω, και γι' αυτό το λόγο πραγματικά στην αρχή δεν κατάλαβα τι είπα που ακούστηκε άσχημα. Ego is a bad mistress όπως λέγανε και στο σχολείο τη μέρα που έλειπε ο Δελαπόρτας.
Latency Δημοσ. 3 Οκτωβρίου 2012 Μέλος Δημοσ. 3 Οκτωβρίου 2012 χμμμ http://codepaste.net/ayy9rp @Timo, απλά συνηθίζω έναν άλλον τρόπο, βασικά στο συγκεκριμένο είναι καλύτερα να έχεις seter/geter γιατί γλυτώνεις 1-2 εντολές όπως το > value = Math.Abs(value); πριν το Switch (κοίτα πάνω), για την αποφυγή του Bug, επιπλέον εντολές = επιπλέον χρόνος για αυτό, μην νομίζεις δηλαδή... οπα υπάρχει bug εδώ > // Alive status public bool isDead { get { return _isDead; } set { _HP = 0.5f; _isDead = value; } } FIXED! > // Alive status public bool isDead { get { return _isDead; } set { if (value == true) _HP = 0.5f; _isDead = value; } } #3: Το "print is dead message" είναι ανάθεμα. Αν θέλεις να ρίξεις πυροτεχνήματα σ' αυτή την περίπτωση λανθασμένης χρήσης, κατά πλήρη αναλογία με τα παραπάνωεδώ είσαι. Σε καμία μα καμία περίπτωση μην κάνεις το λάθος να τυπώσεις τίποτα στην οθόνη ή κάτι παρόμοιο. Δεν είναι αυτό δουλειά του κώδικα που κανονίζει τα HP! έστω ότι ο παίχτης είναι κάτω πεθαμένος, δεν έχει πατήσει ToVillag ακόμα, και ανοίξει Inventory Και πατήσει Healing Potion, δεν πρέπει να πάρει ένα μήνυμα σε κάποιο Chat Window? - ναι οκ, όταν είναι DEAD δεν θα μπορεί να χρησιμοποιήσει Potions > UsePotion(.....) { if (!isDead) { // use pot } } αν όμως είσαι σε Party και κάνει Mass-Heal ο Healer? για το #4, αφού θα καταστρέφεται το Thread μετά την ολοκλήρωση της δουλειάς του. ναι οκ δεν λέω ότι είναι σωστή μέθοδος, για πες μου εσύ, ποια είναι η σωστή μέθοδος όταν θέλουμε να κάνουμε κάποια πράγματα παράλληλα? αφού το BW ουσιαστικά δημιουργεί κάποιο θρεαντ, τότε και το System.Threading.Thread το βγάζουμε εκτός, τι έμεινε? (ένα if(elpasedsec < 1000) στο Update?)
Timonkaipumpa Δημοσ. 3 Οκτωβρίου 2012 Δημοσ. 3 Οκτωβρίου 2012 latency... Επειδή είναι πολλά αυτά που θα πρέπει να λύσεις, καλύτερα να ποστάρεις ένα static class diagramm (με appropriate naming κτλ) παρά κώδικα. Νομίζω ότι η πρόταση που σου έκανα για το interface ίσως σου λύσει τα χέρια γιατί: α) Θα επιλύσεις αυτά τα ζητήματα μόνο μία φορά β) θα γράψεις τον κώδικα για αυτά τα ζητήματα μόνο μία φορά γ) θα ελέγχεται μόνο από ένα σημείο η συμπεριφορά των toons Έτσι, και επειδή οι κανόνες θα είναι οι ίδιοι και για τους παίκτες και για τα τερατάκια, θα μπορέσεις να έχεις μία συμπαγή αντιμετώπιση του θέματος σε ένα μόνο σημείο και για όλους. Για να το κάνεις αυτό όμως, θες σχεδίαση. @defacer Από την μεριά μου, ούτε την δικαιολογία που, ίσως και εάν κατάλαβα καλά, δίνεις μπορώ να καταλάβω. Εάν κάτι είναι "έτσι", είναι "έτσι". Ούτως ή άλλως, εάν κάποιος δεν ξέρει να ξεβιδώσει το καζανάκι του και μπει σε ένα forum να ρωτήσει πώς ξεβιδώνει και εκεί του πουν "δεν ξέρεις να το ξεβιδώνεις" δεν κάνουν κάτι παραπάνω από το να λένε όπως έχουν τα πράματα. Χώρια ότι από λογικούς συνειρμούς μπορεί κανείς να καταλήξει σε συμπεράσματα που θα τον βοηθήσουν 100%, όπως αυτό που παρέθεσες.
defacer Δημοσ. 3 Οκτωβρίου 2012 Δημοσ. 3 Οκτωβρίου 2012 > // Alive status public bool isDead { get { return _isDead; } set { _HP = 0.5f; _isDead = value; } } FIXED! Όχι ακριβώς fixed, εκτός κι αν αποκλείεται κάποιος να βρίσκεται κάποιος σε αρνητικά HP και να ζει ακόμα, που δεν είναι καθόλου απίθανο (π.χ. knocked out and dying ή έχει buff το οποίο μέχρι να κάνει expire απλά δεν πεθαίνεις, berserker style). Κάτι που μου ακούγεται σαν μια ΟΚ αρχική προσέγγιση: > interface IActor { int CurrentHitPoints { get; set; } } interface IActorStatus { bool IsDead; { get; } } interface IActorStatusBehavior { bool IsDead { get; } } class PlayerStatusBehavior : IActorStatusBehavior { private IActor actor; public PlayerStatusBehavior(IActor actor) { this.actor = actor; } public bool IsDead { get { return this.actor.CurrentHitPoints <= 0; } } } class Player : IActor, IActorStatus { private IActorStatusBehavior statusBehavior = new PlayerStatusBehavior(this); public bool IsDead { get { return this.statusBehavior.IsDead; } } public int CurrentHitPoints { get; set; } } Πολύ πράγμα για ένα <= 0 έτσι; Αλλά χρειάζεται. Και δεν ξύσαμε ακόμα ούτε τη μπογιά από πάνω. έστω ότι ο παίχτης είναι κάτω πεθαμένος, δεν έχει πατήσει ToVillag ακόμα, και ανοίξει Inventory Και πατήσει Healing Potion, δεν πρέπει να πάρει ένα μήνυμα σε κάποιο Chat Window? Είμαι σίγουρος πως μπορείς και μόνος σου να καταλάβεις ότι δε χρειάζεται να μας το περιγράψεις αυτό το σενάριο για να το φανταστούμε. Άρα, αφού το έχουμε φανταστεί και παρόλα αυτά σου λέω τσουκ, τι συμπέρασμα βγαίνει: ότι ναι, πρέπει να υπάρχει κάποιο feedback, αλλά δεν είναι αυτό το μέρος από όπου θα το δίνεις. Προφανές; > UsePotion(.....) { if (!isDead) { // use pot } } Ή, σε κάποιο εναλλακτικό σύμπαν: > if (!isDead && !isParalyzed && !isPetrified && !isPlant && !isInMagicDeadZone) { // use pot } Δεν είναι φανερό πού πάει αυτό; αφού θα καταστρέφεται το Thread μετά την ολοκλήρωση της δουλειάς του. ναι οκ δεν λέω ότι είναι σωστή μέθοδος, για πες μου εσύ, ποια είναι η σωστή μέθοδος όταν θέλουμε να κάνουμε κάποια πράγματα παράλληλα? αφού το BW ουσιαστικά δημιουργεί κάποιο θρεαντ, τότε και το System.Threading.Thread το βγάζουμε εκτός, τι έμεινε? (ένα if(elpasedsec < 1000) στο Update?) Το κάνεις στο update loop. Αλλά όχι με αυτό τον τρόπο, γιατί εκτός από προφανής είναι και λάθος (όπως και πολλα προφανή πράγματα στον προγραμματισμό). Και τέλος: πέτα τις enum από το παράθυρο τώρα γιατί έτσι πας να γράψεις C σε καινούριο IDE.
Προτεινόμενες αναρτήσεις
Δημιουργήστε ένα λογαριασμό ή συνδεθείτε για να σχολιάσετε
Πρέπει να είστε μέλος για να αφήσετε σχόλιο
Δημιουργία λογαριασμού
Εγγραφείτε με νέο λογαριασμό στην κοινότητα μας. Είναι πανεύκολο!
Δημιουργία νέου λογαριασμούΣύνδεση
Έχετε ήδη λογαριασμό; Συνδεθείτε εδώ.
Συνδεθείτε τώρα