Προς το περιεχόμενο

Τι τύπο δεδομένων θα επιλέγατε για ένα 2D παιχνίδι


Latency

Προτεινόμενες αναρτήσεις

ούτε εγώ ξέρω, δεν έχω κάποια σχέδια, προχωράω και ότι βγει

 

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

 

Η ερώτηση turn based vs real time ήταν σα να ρώτησα αν το όχημα που σχεδιάζεις θα πετάει η όχι. Δεν είναι δυνατόν να κάνεις γόνιμη συζήτηση αν η απάντηση είναι "δεν ξέρω".

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

  • Απαντ. 64
  • Δημ.
  • Τελ. απάντηση

Συχνή συμμετοχή στο θέμα

Δημοφιλείς Ημέρες

Συχνή συμμετοχή στο θέμα

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

 

http://codepaste.net/dgf1g3

 

>
Character c1 = new Character();
c1.IncreaseHP = 5;
// c1.IncreaseHP(5); looks beter

 

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

 

Η ερώτηση turn based vs real time ήταν σα να ρώτησα αν το όχημα που σχεδιάζεις θα πετάει η όχι. Δεν είναι δυνατόν να κάνεις γόνιμη συζήτηση αν η απάντηση είναι "δεν ξέρω".

 

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

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Αυτός ο κώδικας σου φαίνεται λιγότερο κατανοητός?

 

>
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace testprop
{
class Character
{
 int _health;
 public int Health
 {
	 get
	 {
		 return this._health;
	 }
	 set
	 {
		 if (value > 0) this._health = value;
	 }
 }
}
class Program
{
 static void Main(string[] args)
 {
	 Character c1 = new Character();
	 c1.Health = 5;
	 Console.WriteLine(c1.Health.ToString());
	 c1.Health += 3;
	 Console.WriteLine(c1.Health.ToString());
	 Console.ReadLine();
 }
}
}

 

Η γραμμή

>
c1.Health += 3;

δεν είναι ξεκάθαρο τι ακριβώς κάνει?

 

 

Ο defacer έχει δίκιο όσον αφορά την απάντηση στην ερώτηση real-time/turn-based. Το project πρέπει να έχει ξεκάθαρο στόχο για να έχει νόημα είτε αφορά επαγγελματική δουλειά είτε όχι. Πας να φτιάξεις πρόγραμμα με τη λογική "ότι βρέξει ας κατεβάσει".

 

 

 

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

 

http://codepaste.net/dgf1g3

 

>
Character c1 = new Character();
c1.IncreaseHP = 5;
// c1.IncreaseHP(5); looks beter

 

 

 

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

  • Like 1
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

από πάνω, έτσι όπως το έκανες φίλε μου θα πρέπει σε κάθε τι που χρησιμοποιείς το IncreaseHP, να υπολογίζεις με το μυαλό σου τι να προσέξεις

 

πχ, += 5, καλος, εύκολα γίνεται το λάθος σε = 5 φίλε... δεν μιλάμε για 2-3 κλάσεις

 

ΥΓ: μεταξύ μας τώρα, πιστεύεις ότι αυτό που έκανες είναι πιο εύχρηστο και κατανοητό? ξέρεις... ωραία τα geters/seters γλυτώνουν κώδικα αλλά καμια φορά η διαφορά δεν είναι τόσο μεγάλη που προτιμάται να φτιάχνεις συναρτήσεις...

 

ρίξε μια ματιά στο

http://svn.l2jserver...ver/gameserver/

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

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

 

>
Character c1 = new Character();
c1.IncreaseHP = 5;
// c1.IncreaseHP(5); looks beter

 

Εδώ μπορούμε να συμφωνήσουμε ότι διαφωνούμε. Φυσικά δεν πρόκειται να ονομάσεις το property IncreaseHP, αυτό είναι τελείως λάθος ακόμα και σύμφωνα με την απλοϊκή (αλλά ευρέως διαδεδομένη) προσέγγιση ότι "τα properties είναι ουσιαστικά ή επίθετα και τα methods ρήματα".

 

Επίσης διαφωνώ με το IncreaseHP ακόμα και σε method, θα ήταν καλύτερα είτε να κάνεις αυτό

 

c1.setHP(c1.getHP() + 5);

 

είτε αυτό

 

c1.addHP(5);

 

γιατί και στις δύο περιπτώσεις δεν θα φαίνεται τόσο άσχημο όσο το Increase αν αντί για 5 έχεις -5 (και βέβαια το να έχεις διαφορετικές IncreaseHP και DecreaseHP δεν λύνει κανένα πρόβλημα).

 

Επιπλέον παράδειγμα: η DateTime.Add χρησιμοποιείται να προσθέσει είτε αρνητικές είτε θετικές ποσότητες (όπως και η Subtract). Υπάρχει λόγος που δεν ονομάζονται Increase και Decrease, δεν έγινε στην τύχη.

 

Το c1.Health += 5 του Hawkpilot είναι μακράν το καλύτερο όλων (το πιστεύω και γω), τώρα το ότι αντί για += μπορείς να γράψεις σκέτο ίσον λέγεται bug, αν συμβεί είναι άμεσα αντιληπτό και πανεύκολα κατανοητό, το φτιάχνουμε και ησυχάζουμε και γενικά δεν είναι πρόβλημα. Με την ίδια λογική θα μπορούσες να πεις ότι κακώς υπάρχει ο τελεστής += in the first place, και ότι θα ήταν λιγότερο επιρρεπές σε bug να γράψεις x = x + 5 όπου δε μπορείς να κάνεις αυτό το λάθος.

 

Προφανώς εδώ μιλάμε για ένα tradeoff ανάμεσα στο πόσο πιθανό είναι να γίνει λάθος και τι χαρακτηριστικά θα έχει αν γίνει vs. το "πρήξιμο" που θα έχεις σε κάθε μία πρόσθεση μέχρι το τέλος του σύμπαντος αν η γλώσσα δεν υποστηρίζει το +=. Με πρακτικά κριτήρια απλά παίρνεις το += και λες ευχαριστώ.

 

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

 

Κάνεις λάθος. Στις απαντήσεις μου προσπαθώ να δώσω την οπτική γωνία του "σωστού/καλού". Και γω ο ίδιος στα προγράμματά μου δεν κάνω πάντα αυτά τα πράγματα, αλλά το κάνω κατ' επιλογή και έχοντας γνώση των εναλλακτικών. Αν όπως λες και συ ο σκοπός είναι να μάθεις τότε τι προτιμάς: να μάθεις μπακαλιές ή να έχεις μια ιδέα πώς είναι το καλό;

 

Αν έχεις στο μυαλό σου 10 σημεία που σηκώνουν βελτίωση, μπορείς να επικεντρωθείς σε 1-2 από αυτά και να μάθεις κάτι κάνοντας μπακαλιές στα υπόλοιπα για πρακτικούς λόγους. Αν όμως έχεις στο μυαλό σου μόνο μπακαλιές τότε απλά θα γίνεις μπακάλης.

 

Και κλείνοντας ξαναλέω: η άποψή σου ότι "properties δεν χρειάζονται" (που την έχεις εκφράσει πολύ έντονα αν και όχι με τις λέξεις που χρησιμοποίησα) ακούγεται "περίεργη". Μήπως απλά κουβαλάς πολλά μπαγκάζια από C ή C++ και πρέπει να τα αφήσεις πίσω για να προσεγγίσεις κάτι καινούριο με ανοιχτό μυαλό;

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

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

 

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

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

...

από τι βλέπετε σχεδών όλα θα μπορούσαν να αναπαρασταθούν με short(2byte) -32.000~ to 32.000~ ή unsigned 0...64.000~

 

απλά δεν έχω δει ποτέ μου να το χρησιμοποιούν short σε διάφορα παραδείγματα στο Internet, ακόμα και παιχνίδια που δίνουν Source

 

μήπως γίνεται λόγο συνήθειας-άγνοιας? έχουμε συνηθίσει τους int/float/double

...

 

Συχνά οι αποφάσεις για τα data-types μπορεί να σχετίζονται και με την αρχιτεκτονική στην οποία προορίζεται να τρέξει το λογισμικό, ειδικά αν μιλάμε για speed/resource critcal sofware.

 

Memory alignment(padding) και minimum addressable unit είναι 2 φράσεις που θα μπορούσες να γκουγκλάρεις, κι αργότερα να εμβαθύνεις αν σε ενδιαφέρει.

  • Like 1
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

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

 

Εμένα πάντως μου πήρε αρκετά χρόνια αφότου έμαθα να αποφασίζω απο πριν τι θέλω να φτιάξω για να σταματήσω να το παθαίνω αυτό. ;)

 

Δε θα ξεχάσω ποτέ ένα επαναχρησιμοποιήσιμο component που έγραφα σε Clipper (παλιά στο Τέξας) στο οποίο περνούσες όλες τις σχετικές πληροφορίες και αυτό αναλάμβανε να σου εμφανίσει ένα menu system (menu, submenu, hotkeys, checkmarks, disabled elements, mouse, κλπ κλπ). Χρειάστηκε να το ξαναγράψω τρείς φορές από την αρχή (μιλάμε για περίπου δυο μήνες ενασχόληση κάθε φορά).

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

γιατί και στις δύο περιπτώσεις δεν θα φαίνεται τόσο άσχημο όσο το Increase αν αντί για 5 έχεις -5 (και βέβαια το να έχεις διαφορετικές IncreaseHP και DecreaseHP δεν λύνει κανένα πρόβλημα).

 

σε αυτό το κομμάτι ας πούμε ότι συμφωνούμε απλά σε ότι φτιάχνω σκέφτομαι το ενδεχόμενο ο κώδικας να πέσει σε κάποιον εντελώς "Niewbie", Θα μπορούσε αυτός ο Niewbie να μην ξέρει να κάνει αυτό

 

>
c1.setHP(c1.getHP() + 5);

 

το μόνο που ξέρει είναι να περνάει αριθμό μέσα, και 2ον είναι αυτό που είπα πιο πάνω...

θα πρέπει κάθε φορά που το χρησιμοποιούμε να έχουμε στο μυαλό μας να βάλουμε στην παράμετρο και το Current HP, τρέχα γύρευε, μήπως να γινόταν αυτόματα αυτό?

 

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

 

μήπως φταίει ότι έχω συνηθίσει C? (με το OOP δεν έχω ιδιαίτερο θέμα, απλά σχεδόν πάντα ασχολούμε με συναρτήσεις για μικροπροβλήματα)

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

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

 

από πάνω, έτσι όπως το έκανες φίλε μου θα πρέπει σε κάθε τι που χρησιμοποιείς το IncreaseHP, να υπολογίζεις με το μυαλό σου τι να προσέξεις

 

πχ, += 5, καλος, εύκολα γίνεται το λάθος σε = 5 φίλε... δεν μιλάμε για 2-3 κλάσεις

 

ΥΓ: μεταξύ μας τώρα, πιστεύεις ότι αυτό που έκανες είναι πιο εύχρηστο και κατανοητό? ξέρεις... ωραία τα geters/seters γλυτώνουν κώδικα αλλά καμια φορά η διαφορά δεν είναι τόσο μεγάλη που προτιμάται να φτιάχνεις συναρτήσεις...

 

ρίξε μια ματιά στο

http://svn.l2jserver...ver/gameserver/

 

Συμφωνώ με τον defacer: έχω την αίσθηση ότι "κουβαλάς" κατάλοιπα άλλων γλωσσών κι εποχών. Αντιλαμβάνομαι ότι είναι αρκετά δύσκολο να αλλάξεις τρόπο σκέψης και υλοποίησης αν προγραμματίζεις χρόνια πχ σε c++. Νομίζω όμως ότι είναι "ατόπημα" να απορρίπτεις τις νέες τεχνολογίες - τεχνοτροπίες επειδή δε μπορείς να τις συνηθίσεις. Πολύ περισσότερο όταν αναφερόμαστε σε χαρακτηριστικά oop που μας διευκολύνουν τη ζωή και μας προστατεύουν από κακοτοπιές.

 

 

...

Και κλείνοντας ξαναλέω: η άποψή σου ότι "properties δεν χρειάζονται" (που την έχεις εκφράσει πολύ έντονα αν και όχι με τις λέξεις που χρησιμοποίησα) ακούγεται "περίεργη". Μήπως απλά κουβαλάς πολλά μπαγκάζια από C ή C++ και πρέπει να τα αφήσεις πίσω για να προσεγγίσεις κάτι καινούριο με ανοιχτό μυαλό;

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Εδώ μπορούμε να συμφωνήσουμε ότι διαφωνούμε. Φυσικά δεν πρόκειται να ονομάσεις το property IncreaseHP, αυτό είναι τελείως λάθος ακόμα και σύμφωνα με την απλοϊκή (αλλά ευρέως διαδεδομένη) προσέγγιση ότι "τα properties είναι ουσιαστικά ή επίθετα και τα methods ρήματα".

 

Επίσης διαφωνώ με το IncreaseHP ακόμα και σε method, θα ήταν καλύτερα είτε να κάνεις αυτό

 

c1.setHP(c1.getHP() + 5);

 

είτε αυτό

 

c1.addHP(5);

 

γιατί και στις δύο περιπτώσεις δεν θα φαίνεται τόσο άσχημο όσο το Increase αν αντί για 5 έχεις -5 (και βέβαια το να έχεις διαφορετικές IncreaseHP και DecreaseHP δεν λύνει κανένα πρόβλημα).

 

Επιπλέον παράδειγμα: η DateTime.Add χρησιμοποιείται να προσθέσει είτε αρνητικές είτε θετικές ποσότητες (όπως και η Subtract). Υπάρχει λόγος που δεν ονομάζονται Increase και Decrease, δεν έγινε στην τύχη.

 

Το c1.Health += 5 του Hawkpilot είναι μακράν το καλύτερο όλων (το πιστεύω και γω), τώρα το ότι αντί για += μπορείς να γράψεις σκέτο ίσον λέγεται bug, αν συμβεί είναι άμεσα αντιληπτό και πανεύκολα κατανοητό, το φτιάχνουμε και ησυχάζουμε και γενικά δεν είναι πρόβλημα. Με την ίδια λογική θα μπορούσες να πεις ότι κακώς υπάρχει ο τελεστής += in the first place, και ότι θα ήταν λιγότερο επιρρεπές σε bug να γράψεις x = x + 5 όπου δε μπορείς να κάνεις αυτό το λάθος.

 

Προφανώς εδώ μιλάμε για ένα tradeoff ανάμεσα στο πόσο πιθανό είναι να γίνει λάθος και τι χαρακτηριστικά θα έχει αν γίνει vs. το "πρήξιμο" που θα έχεις σε κάθε μία πρόσθεση μέχρι το τέλος του σύμπαντος αν η γλώσσα δεν υποστηρίζει το +=. Με πρακτικά κριτήρια απλά παίρνεις το += και λες ευχαριστώ.

 

 

 

Κάνεις λάθος. Στις απαντήσεις μου προσπαθώ να δώσω την οπτική γωνία του "σωστού/καλού". Και γω ο ίδιος στα προγράμματά μου δεν κάνω πάντα αυτά τα πράγματα, αλλά το κάνω κατ' επιλογή και έχοντας γνώση των εναλλακτικών. Αν όπως λες και συ ο σκοπός είναι να μάθεις τότε τι προτιμάς: να μάθεις μπακαλιές ή να έχεις μια ιδέα πώς είναι το καλό;

 

Αν έχεις στο μυαλό σου 10 σημεία που σηκώνουν βελτίωση, μπορείς να επικεντρωθείς σε 1-2 από αυτά και να μάθεις κάτι κάνοντας μπακαλιές στα υπόλοιπα για πρακτικούς λόγους. Αν όμως έχεις στο μυαλό σου μόνο μπακαλιές τότε απλά θα γίνεις μπακάλης.

 

Και κλείνοντας ξαναλέω: η άποψή σου ότι "properties δεν χρειάζονται" (που την έχεις εκφράσει πολύ έντονα αν και όχι με τις λέξεις που χρησιμοποίησα) ακούγεται "περίεργη". Μήπως απλά κουβαλάς πολλά μπαγκάζια από C ή C++ και πρέπει να τα αφήσεις πίσω για να προσεγγίσεις κάτι καινούριο με ανοιχτό μυαλό;

 

ειπα ότι όταν μιλάμε για σεταρίσματα υπό 2-3 προϋποθέσεις τότε με βολεύουν οι συναρτήσεις που είναι και πιο περιγραφικές

 

Memory alignment(padding) και minimum addressable unit είναι 2 φράσεις που θα μπορούσες να γκουγκλάρεις, κι αργότερα να εμβαθύνεις αν σε ενδιαφέρει.

 

γνωρίζω για το memory alignment, βασικά κάτσε να το τελειώσω και μετά θα το πάρω από την αρχή να εφαρμόσω αυτά που ξέρω, ένα καλό re-work γιατί τώρα δεν ξέρω τι θέλω,

 

πχ, 10 φορές έχω ξεκινήσει και τα έχω παρατήσει επειδή με έχει πιάσει πονοκέφαλος, δεν ξέρω τι Stats να βάλω, τι ονομασίες, κεφαλαία μικρά, _ μπροστά, (γενικά έχω τέτοια θέματα, θέλω να χτυπάνε ωραία στο μάτι)

 

ΥΓ: ουσιαστικά αυτό που κάνω με τα Increase/Decrease/SetHP είναι να παρέχω ένα Interface, δεν είναι τόσο τραγικό δηλαδή, ναι θα μπορούσε να υπάρχει μόνο η ADD και η δουλειά να γίνει στην είσοδο παραμέτρου.

 

ΥΓ: ουσιαστικά αυτό που κάνω με τα Increase/Decrease/SetHP είναι να παρέχω ένα Interface, δεν είναι τόσο τραγικό δηλαδή, ναι θα μπορούσε να υπάρχει μόνο η ADD και η δουλειά να γίνει στην είσοδο παραμέτρου.

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

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

το μόνο που ξέρει είναι να περνάει αριθμό μέσα, και 2ον είναι αυτό που είπα πιο πάνω...

θα πρέπει κάθε φορά που το χρησιμοποιούμε να έχουμε στο μυαλό μας να βάλουμε στην παράμετρο και το Current HP, τρέχα γύρευε, μήπως να γινόταν αυτόματα αυτό?

 

Αυτό γίνεται αυτόματα όταν γράψεις c.Health += 5 ;)

 

Επίσης, μη πέφτεις στην παγίδα "απευθύνομαι σε άσχετους". Είναι πολύ καλό και επιθυμητό ο κώδικας να μπορεί να είναι κατανοητός από άσχετους (δεν είναι απίστευτα προφανές ακόμα και σε τέρμα νιούφη το τι γίνεται με το Health property?) -- simple is good! Αυτό όμως δεν είναι το ίδιο με το να απευθύνεσαι σε άσχετους. Αν το τελευταίο ήταν καλό τότε όλοι μας θα πίναμε έτοιμο Bacardi Mojito.

 

 

 

Πολλοί από σας θα γνωρίζετε το jQuery, με το οποίο μπορεί ακόμα και ένας άσχετος να κάνει παπάδες εύκολα σε ένα web site.

 

Ορίστε το source για ένα plugin που έγραψα στη δουλειά. Κι αυτό jQuery είναι, αλλά δεν είναι για άσχετους. Είναι για να γίνει μια δουλειά σωστά. Σχολιάζω μόνο το ότι documentation + σχόλια είναι πολύ μεγαλύτερα από τον "πραγματικό" κώδικα.

 

 

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

 

Όσο πιο πολλά ξέρεις τόσο πιο πολύ συνειδητοποιείς ότι δεν ξέρεις τίποτα (it is known). Ίσως τώρα να βρίσκεσαι στη φάση που αρχίζεις να συνειδητοποιείς σιγά σιγά ότι δεν ξέρεις.

 

μήπως φταίει ότι έχω συνηθίσει C? (με το OOP δεν έχω ιδιαίτερο θέμα, απλά σχεδόν πάντα ασχολούμε με συναρτήσεις για μικροπροβλήματα)

 

Ναι και χαίρομαι που μπορείς να το καταλάβεις και μόνος σου.

 

Προσπάθησε να χωνέψεις και το παρακάτω, το οποίο το λέω για να σε προβληματίσω/τσιγκλίσω (σχετίζεται και με τα παραπάνω) και όχι βέβαια για να σε μειώσω: δεν έχεις ιδέα από OOP.

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Βάζουμε "πάντα" int γιατί δεν έχει κανένα νόημα να κάνεις οικονομία 2 bytes (θα είχε νόημα μόνο το 1980 στον ZX81 με το 1Kb ram). Δεν κερδίζεις απολύτως τίποτα και απλά αφήνεις ανοιχτό το ενδεχόμενο να έχεις πρόβλημα στο μέλλον.

 

Τοτε γιατι υπαρχουν οι τυποι δεδομενων byte & short? Και εδω που τα λεμε γιατι να δηλωνουμε τις μεταβλητες παντα int? Ας τις δηλωνουμε long αφου δεν έχει κανένα νόημα να κάνεις οικονομία (θα είχε νόημα μόνο το 1980 στον ZX81 με το 1Kb ram).

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

τώρα είναι καλύτερα?

 

http://codepaste.net/njo6jc Player Class

 

http://codepaste.net/324ta5 Update Function wich is calling it.

 

Όσο πιο πολλά ξέρεις τόσο πιο πολύ συνειδητοποιείς ότι δεν ξέρεις τίποτα (it is known). Ίσως τώρα να βρίσκεσαι στη φάση που αρχίζεις να συνειδητοποιείς σιγά σιγά ότι δεν ξέρεις.

ξέρω άλλους τρόπους , δεν σημαίνει ότι τα properties είναι η μοναδική λύση, μην επαναλαμβανόμαστε.... το κάναμε function vs seters/geters

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Δεν διυλίζουμε τον κώνωπα εδώ. Φυσικά και μπορείς να βάλεις byte & short αλλά να ξέρεις ότι οι περισσότεροι compilers της εποχής μας κάνουν 16/32/64 bit alignment στο data section για να είναι πιο γρήγορη η εκτέλεση του προγράμματος. Άρα, δεν έχει νόημα να γράφεις πρόγραμμα και να περιορίζεις τη μεταβλητή σου σε 8 bits όταν ο compiler θα δεσμεύσει πολλαπλάσιο χώρο στη μνήμη.

 

 

Τοτε γιατι υπαρχουν οι τυποι δεδομενων byte & short? Και εδω που τα λεμε γιατι να δηλωνουμε τις μεταβλητες παντα int? Ας τις δηλωνουμε long αφου δεν έχει κανένα νόημα να κάνεις οικονομία (θα είχε νόημα μόνο το 1980 στον ZX81 με το 1Kb ram).

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Δημιουργήστε ένα λογαριασμό ή συνδεθείτε για να σχολιάσετε

Πρέπει να είστε μέλος για να αφήσετε σχόλιο

Δημιουργία λογαριασμού

Εγγραφείτε με νέο λογαριασμό στην κοινότητα μας. Είναι πανεύκολο!

Δημιουργία νέου λογαριασμού

Σύνδεση

Έχετε ήδη λογαριασμό; Συνδεθείτε εδώ.

Συνδεθείτε τώρα

  • Δημιουργία νέου...