Περί ECS programming.

[Alithinos]

Το προγραμματιστικό υπόδειγμα ECS (Entity-Component-System) σκοπό έχει να αντικαταστήσει τη κληρονομικότητα και να μειώσει τη κατανάλωση πόρων συστήματος. Επίσης υπόσχεται πιο εύκολη επαναχρησιμοποίηση κώδικα.

Αντί να φτιάχνουμε αντικείμενα που έχουν δεδομένα + λογική, το υπόδειγμα λέει πως φτιάχνουμε Components (τα οποία έχουν μόνο δεδομένα), Entities (τα οποία είναι αντικείμενα που έχουν Components), και Systems όπου διαθέτουν όλο το κώδικα λογικής. Το σκεπτικό είναι πως έτσι έχεις τις μεθόδους σε  "κεντρικά" αντικείμενα (Systems) τα οποία δρουν στα διάφορα αντίτυπα των Components όπου χρειάζεται. Και έτσι το κάθε Component είναι ελαφρύτερο από ένα παραδοσιακό αντικείμενο OOP.

Έχω τον εξής προβληματισμό:

Αξίζουν οι βελτιώσεις στη κατανάλωση πόρων το να ξεσυνηθίσει κάποιος το παραδοσιακό τρόπο του OOP, και τους ενδεχόμενους κινδύνους που θα προκύψουν (?) αν ξεχωρίσουμε τα δεδομένα από τις μεθόδους ώστε να υπάρχουν αλλού ;

Επεξ/σία 4 Ιουνίου 2018 από Alithinos

[Fortistis]

Αδερφέ, με το συμπάθειο, αλλά τα έχεις μπλέξει.  

Θα σου πρότεινα να ξανά-διαβάσεις. 

Π.χ., λες για "component". Πώς δημιουργείς ένα τέτοιο; Είναι primitive data type ή υπάρχει μία κλάση με **δεδομένα και λογική** από την οποία δημιουργείς το αντικείμενο του component σου;

Ελπίζω να καταλαβαίνεις γιατί το

30 λεπτά πριν, Alithinos είπε

Αντί να φτιάχνουμε αντικείμενα που έχουν δεδομένα + λογική

δεν ισχύει, εφόσον **φτοάχνεις αντικείμενα που έχουν δεδομένα και λογική**. 

Επεξ/σία 4 Ιουνίου 2018 από Fortistis

[Kercyn]

Έβγαλε ένα βίντεο ο Brackeys χτες και μόνο από το χαζό παράδειγμα που χρησιμοποιεί εγώ πείστηκα.

 

[Alithinos]

@Fortistis

Component είναι ένα δοχείο δεδομένων. Μπορεί να είναι πχ ένα struct, ή και reference type ή και καταχώρηση σε βάση δεδομένων. Σημασία έχει ότι εντός του έχει μόνο δεδομένα. Σκέψου λίγο το MVC και πως ξεχωρίζει το μέρος που βρίσκονται τα δεδομένα από τη λογική που δρά στα δεδομένα. Το ECS δεν ασχολείται με το πως παρουσιάζουνται, άρα δε μιλάμε για MVC, αλλά διαχωρίζει τα δεδομένα απ' τη λογική που δρα σε αυτά όπως το MVC, και σου λέει ότι το κομμάτι αυτό που διαθέτει τη λογική υπάρχει 1 φορά σε όλη την εφαρμογή, και δρα σε όλα τα Components.

@Kercyn

Αυτό το βίντεο είδα και εγώ και με έβαλε σε σκέψεις. Ο Brackeys βέβαια ασχολείται συγκεκριμένα για να δώσει παράδειγμα για το πως να χρησιμοποιήσει κανείς ECS με την υλοποίηση του API της Unity. Αλλά οι αρχές του ECS καθ' αυτές, μπορούν να εφαρμοστούν και πέρα από τη συγκεκριμένη υλοποίηση. Με ενδιαφέρει αυτή τη στιγμή να μάθω γενικότερα για το υπόδειγμα παρά για τα τεχνικά της συγκεκριμένης υλοποίησης. Θα με ενδιέφερε να μάθω πχ θεωρητικά ή και πρακτικά από ανθρώπους που έχουν πείρα, τι να περιμένει κανείς με τέτοιες αλλαγές.

Επεξ/σία 4 Ιουνίου 2018 από Alithinos

[Fortistis]

Τα έχεις μπερδέψει. Πάμε ξανά. 

Από την στιγμή που δεν λες

	int a = 3;
	

αλλά

	a = MyComponent();
	

τότε έχεις αντικείμενο. Μπορεί να έχεις και struct, αλλά εάν έχεις και κλάση τότε μιλάμε για αντικείμενα. 

Τέλος, το ECS δεν είναι paradigm αλλά pattern και εσύ αναφέρεσαι σε συγκεκριμένο variant αυτού (από τον Martin εάν θυμάμαι καλά). 

Ξαναλέω, τα έχεις μπερδέψει. Αυτό δεν είναι κακό. Το ότι δεν θες να το δεχθείς, μπορεί να καταλήξει να είναι.  

Αυτό το "έχει μόνο δεδομένα".... !!!

Δηλαδή, εν έτη 2018 δεν χρησιμοποιείς containers; Δεν χρησιμοποιείς lenth checking; Είσαι με 

	for(myStructNode* p; ;){
	    p = p->nextStructAddres;
	    if (p == Null) break;
	}
	

;

Ή κάνεις memory allocation με malloc;

Επεξ/σία 4 Ιουνίου 2018 από Fortistis

[Alithinos]

1 ώρα πριν, Fortistis είπε

Τα έχεις μπερδέψει. Πάμε ξανά. 

Από την στιγμή που δεν λες

	int a = 3;
	

αλλά

	a = MyComponent();
	

τότε έχεις αντικείμενο. Μπορεί να έχεις και struct, αλλά εάν έχεις και κλάση τότε μιλάμε για αντικείμενα. 

Τέλος, το ECS δεν είναι paradigm αλλά pattern και εσύ αναφέρεσαι σε συγκεκριμένο variant αυτού (από τον Martin εάν θυμάμαι καλά). 

Ξαναλέω, τα έχεις μπερδέψει. Αυτό δεν είναι κακό. Το ότι δεν θες να το δεχθείς, μπορεί να καταλήξει να είναι.  

Αυτό το "έχει μόνο δεδομένα".... !!!

Δηλαδή, εν έτη 2018 δεν χρησιμοποιείς containers; Δεν χρησιμοποιείς lenth checking; Είσαι με 

	for(myStructNode* p; ;){
	    p = p->nextStructAddres;
	    if (p == Null) break;
	}
	

;

Ή κάνεις memory allocation με malloc;

Δε καταλαβαίνω γιατί μου λες πως "τα έχω μπερδέψει". Νομίζω πως αυτό που είπα στο πρώτο μήνυμα ήταν κάτι απλό: Διαχωρισμός δεδομένων από το κώδικα λογικής, και τοποθέτηση του κώδικα λογικής σε ένα κεντρικό σημείο. Ώστε αν θες πχ 100 πάπιες ταυτόχρονα να είναι πολλαπλασιασμένα επί 100 μόνο τα δεδομένα κάθε πάπιας, ενώ ο σχετικός κώδικας που δρα στα δεδομένα της πάπιας να υπάρχει σε 1 μόνο instance και όχι σε 100, ένα για τη κάθε πάπια. Στην ονομασία θα κολλήσουμε ; Σε μια λέξη ; Στο αν θα πούμε τη κάθε ξεχωριστή πάπια "αντικείμενο" ή "component" ;

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

Επεξ/σία 4 Ιουνίου 2018 από Alithinos

[defacer]

1 hour ago, Alithinos said:

Σκέψου λίγο το MVC και πως ξεχωρίζει το μέρος που βρίσκονται τα δεδομένα από τη λογική που δρά στα δεδομένα.

Το MVC κάνει τέτοιο πράγμα;

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

Tread carefully.

[Alithinos]

39 λεπτά πριν, defacer είπε

Το MVC κάνει τέτοιο πράγμα;

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

Tread carefully.

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

public class Car
{
 public float maxSpeed;
 public Color clr;
 public int seats;

 public void Accelerate()
 {
   ...
 }
 public void Decelearate()
 {
   ...
 }
}

Ενώ άμα ήθελες μετά να φτιάξεις πχ φορτηγά θα μπορούσες να γράψεις:

public Truck : Car
{
  public float loadedWeight;

  public bool IsFullyLoaded()
  {
    ...
  }
}

Μας λέει λοιπόν το ECS πως αντί να κάνεις το από πάνω, να φτιάξεις το βασικό Car να έχει μόνο δεδομένα, πχ: (Αυτό το ονομάζει Component)

public struct CarComponent
{
  public float maxSpeed;
  public Color clr;
  public int seats;
}

Έτσι άμα μετά θες να φτιάξεις φορτηγό, φτιάχνεις το Component του φορτηγού κάπως έτσι:

public struct TruckComponent
{
  public float loadedWeight;
}

Και ύστερα φτιάχνεις δοχεία components τα οποία τα ονομάζει Entities. Για παράδειγμα αυτό είναι ένα entity του Car:

public class CarEntity
{
  public Car car;
}

Ενώ αυτό Entity του Truck:

public class TruckEntity
{
  public Car car;
  public Truck truck;
}

Ώστε με αυτό το τρόπο αποφεύγεις τη κληρονομικότητα.

Και υποτίθεται πως επειδή το αντίτυπο κάθε αυτοκινήτου έχει μόνο δεδομένα και ο κώδικας λογικής για τα αυτοκίνητα θα υπάρχει μόνο σε 1 αντίτυπο (αυτό ονομάζει System) που θα χρησιμοποιείται συχνά απ' όλα τα αντίτυπα αυτοκινήτων, θα έχεις κάποιο ώφελος επειδή θα είναι cachαρισμένος ο κώδικας λογικής και δεν θα έχει κάθε αντίτυπο του car και αντίτυπο τοy κώδικα λογικής.

Επεξ/σία 4 Ιουνίου 2018 από Alithinos

[Fortistis]

57 λεπτά πριν, Alithinos είπε

Στην ονομασία θα κολλήσουμε ; Σε μια λέξη ; Στο αν θα πούμε τη κάθε ξεχωριστή πάπια "αντικείμενο" ή "component" ;

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

Σε μία λέξη, ναι. Ευτυχώς, η πληροφορική είναι επιστήμη και οι λέξεις έχουν σημασία. Το πώς ονομάζεις κάτι σημαίνει πολλά. Οπότε, ναι. Σε μία λέξη. Αλλιώς δεν μπορούμε να συννενοηθούμε.

Επίσης, δεν "ρώτησες συγκεκριμένα". Έθεσες δεδομένα, ανέπτυξες γνώμη και μετά ρώτησες.

15 λεπτά πριν, Alithinos είπε

Ώστε με αυτό το τρόπο αποφεύγεις τη κληρονομικότητα.

Και υποτίθεται πως επειδή το αντίτυπο κάθε αυτοκινήτου έχει μόνο δεδομένα και ο κώδικας λογικής θα υπάρχει μόνο σε 1 αντίτυπο (αυτό ονομάζει System) που θα χρησιμοποιείται συχνά απ' όλα τα αντίτυπα αυτοκινήτων, θα έχεις κάποιο ώφελος επειδή θα είναι cachαρισμένος ο κώδικας λογικής και δεν θα έχει κάθε αντίτυπο του car και αντίτυπο τοy κώδικα λογικής.

 

Ξανά πάλι. Τα έχεις κάνει κουλουβάχατα. Συνεχίζεις να μην το παραδέχεσαι. Κρίμα. Θα περίμενα από κάποιον με επιστημονκή εκπαίδευση να μπορεί να δεχθεί το λάθος του, να διαβάσει ξανά/κι άλλο, και να το διορθώσει.

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

Επεξ/σία 4 Ιουνίου 2018 από Fortistis

[Alithinos]

50 λεπτά πριν, Fortistis είπε

Σε μία λέξη, ναι. Ευτυχώς, η πληροφορική είναι επιστήμη και οι λέξεις έχουν σημασία. Το πώς ονομάζεις κάτι σημαίνει πολλά. Οπότε, ναι. Σε μία λέξη. Αλλιώς δεν μπορούμε να συννενοηθούμε.

Επίσης, δεν "ρώτησες συγκεκριμένα". Έθεσες δεδομένα, ανέπτυξες γνώμη και μετά ρώτησες.

Ξανά πάλι. Τα έχεις κάνει κουλουβάχατα. Συνεχίζεις να μην το παραδέχεσαι. Κρίμα. Θα περίμενα από κάποιον με επιστημονκή εκπαίδευση να μπορεί να δεχθεί το λάθος του, να διαβάσει ξανά/κι άλλο, και να το διορθώσει.

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

1) Καλό είναι όταν λέμε σε κάποιον ότι κάνει λάθος, να είμαστε έτοιμοι και να απαντήσουμε στα ερωτήματα "που;" και "γιατί;" που πιθανώς θα μας ρωτήσει.

2) Δεν ανέπτυξα καμία γνώμη. Είπα τι διάβασα να λέει κάποιος στο internet, και επειδή έχω αμφιβολίες και δε ξέρω, έφτιαξα το thread για να ρωτήσω, ακριβώς γιατί θέλω να μάθω. Άρα το να μου λες ότι δε θέλω να μάθω ενώ έφτιαξα το thread συγκεκριμένα επειδή θέλω να μάθω, είναι οξύμωρο.

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

4) Και δεν φροντίζεις καν να πεις "δεν ισχύει και δεν θα έχεις κανένα ώφελος στο performance για το Χ και το Ψ λόγο", για την ακρίβεια δεν απαντάς καν στο θέμα που ρώτησα αλλά στο αν πρέπει να χρησιμοποιούμε τη λέξη component ή αντικείμενο.

5) Το να ρωτάω αν υπάρχει πράγματι ώφελος σε performance και να μου λες <<κακώς λες τα αντικείμενα "components">> ενώ έτσι ονομάζονται συγκεκριμένα τα αντικείμενα στα οποία βάζουμε μόνο δεδομένα από όσους χρησιμοποιούν το ECS και αναφέρονται σε αυτό, δείχνει ότι:

α' δεν απαντάς επί του θέματος, στην ουσία, αλλά σχολιάζεις λεπτομέρειες που δεν αφορούν τα ερωτήματα που έθεσα, δηλαδή αγγίζει το off-topic.

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

6) Παράθεση από Wikipedia:

Αναφορά σε κείμενο

Entity–component–system (ECS) is an architectural pattern that is mostly used in game development. An ECS follows the Composition over inheritance principle that allows greater flexibility in defining entities where every object in a game's scene is an entity (e.g. enemies, bullets, vehicles, etc.). Every Entity consists of one or more components which add additional behavior or functionality. Therefore, the behavior of an entity can be changed at runtime by adding or removing components. This eliminates the ambiguity problems of deep and wide inheritance hierarchies that are difficult to understand, maintain and extend.

και

Αναφορά σε κείμενο

Composition over inheritance (or composite reuse principle) in object-oriented programming (OOP) is the principle that classes should achieve polymorphic behavior and code reuse by their composition (by containing instances of other classes that implement the desired functionality) rather than inheritance from a base or parent class.

Αν κάποιος τα χει κάνει κουλουβάχατα, είναι είτε αυτοί που έγραψαν τα άρθρα στη Wikipedia,και αλλού γενικότερα, είτε εσύ, όχι εγώ. Εγώ σε αυτό το thread επαναλαμβάνω τι διάβασα αλλού. Για αυτό αν θες να πεις πως κάποιος τα 'χει κάνει κουλουβάχατα, πες το προς άλλους.

Εκτός από το να

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

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

έχεις κάτι να προσφέρεις στη συζήτηση;

Επεξ/σία 4 Ιουνίου 2018 από Alithinos

[albNik]

Οκ κατάλαβα κάπως τα Car, Truck, CarComponent, TruckComponent. Μοιαζει λιγο με υβριδικό OOP/FP

Οι methods/functions που θα βρίσκονται;

[Lanike71]

Έριξα τυχαία μία ματιά https://www.gamedev.net/articles/programming/general-and-gameplay-programming/understanding-component-entity-systems-r3013/

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

[Kercyn]

25 λεπτά πριν, Lanike71 είπε

Έριξα τυχαία μία ματιά https://www.gamedev.net/articles/programming/general-and-gameplay-programming/understanding-component-entity-systems-r3013/

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

 

Σκέψου ότι έχεις 10 αυτοκίνητα που τρέχουν, και σε κάθε frame το κάθε αυτοκίνητο χρειάζεται να πάρει μια τιμή. Με τον "κανονικό" τρόπο κάθε αυτοκίνητο θα ζήταγε σε κάθε frame αυτή την τιμή. Με το ECS έχεις 10 entities αυτοκινήτων και 1 system που ζητάει την τιμή που χρειάζονται τα αυτοκίνητα μία φορά και μετά θα υλοποιεί τη συμπεριφορά των αυτοκινήτων.

Επεξ/σία 4 Ιουνίου 2018 από Kercyn

[Fortistis]

@Alithinos

Ό,τι πεις αδερφέ. Εκ των υστέρων καταλαβαίνω πως ήταν λάθος μου να πιστέψω ότι, βάσει του πρώτου σου post, μπορείς να καταλάβεις τι σου έγραψα. Μπορείς να συνεχίσεις αυτά τα ωραία που γράφεις. 

 

 

 

 

[defacer]

@Alithinos δε μπορώ να παρακολουθήσω αρκετά, αλλά όσον αφορά αυτό που μου έγραψες παραπάνω: κάνεις λάθος, δεν έχει κάθε car δικό του αντίγραφο του κώδικα κάθε μεθόδου. That's not at all how it works.

Όπως κι αν τα κάνεις, το αντίγραφο του κώδικα πάντα θα είναι ένα και μοναδικό εκτός από περιπτώσεις που ο κώδικας είναι σε κάποια library και την κάνεις statically link μέσα σε άλλες libraries, και μετά κάνεις statically link αυτές μέσα στο ίδιο εκτελέσιμο. Οπότε δεν ισχύει αυτό που λες ως θετικό.

Θα προσπαθήσω να επανέλθω αργότερα.