Αλληλεπίδραση με αντικείμενο όταν αυτό βρίσκεται σε Χ απόσταση...

[RubiksCube]

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

[m1cRo]

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

 

Και για να κόψεις την εξάρτηση αντικείμενο -> περιοχή στην render loop όταν ζωγραφίζεις περιοχή λες handle events το κάθε αντικείμενο έχει ένα queue από events μέσα του και το Location καλεί handle events και περνάει την λίστα με τα αντικείμενα ως παράμετρο. Δηλαδή ένα αντικείμενο έχει standard HandleEvents(List<IModel> neighbors); Οποτε το Item σου δεν εξαρτάται καν από το Location.

[Alchemist`]

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

 

1) Τα αντικείμενα έχουν δεδομένο x,y το οποίο μπορεί να ζητηθεί και να βρεθεί ανά πάσα στιγμή με απλή αναφορά στην αντίστοιχη μεταβλητή του αντικειμένου (π.χ. Obj_id.x)

2) Η απόσταση ενός αντικειμένου με ένα άλλο μπορεί να βρεθεί σε έναν κύκλο επεξεργασίας με μια απλή function "point_distance(obj_a.x,obj_a.y,obj_b.x,obj_b.y)"

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

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

[RubiksCube]

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

 

Προς θεού!!!! Εγώ έλεγα να έχεις ΈΝΑΝ μόνο πίνακα με όλα τα αντικείμενα. Όχι έναν για κάθε player object. Και όταν θέλεις να βρεις ποια άλλα αντικείμενα είναι κοντά του (μόνο τότε) θα υπολογίζεις την απόσταση. Δεν υπάρχει κανένας λόγος να αποθηκεύεις την απόσταση και να την ανανεώνεις, εφόσον μπορείς να την υπολογιζεις από τις συντεταγμένες.

 

Δηλαδή αν ενδιαφέρεσαι να βρεις τι ειναι κοντά στην θέση x,y θα έκανες loop σε όλο τον πίνακα και θα επέστρεφες μόνο τα αντικείμενα που είναι κοντά. πχ

 

>
List<InteractableObject> findNeighborObjects(int x, int y){
   List<InteractableObject> neighbors = new ArrayList<InteractableObject>();
   for(int i=0;i<allObjects.length;i++){
           if(απόσταση (x,y) από allObjects[i]<κατώφλι)
                 neighbors.add(allObjects[i]);
    }
   return neighbors;
}

 

όπου η μεταβλητή allObjects είναι member variable της κλάσσης (εγώ θα την έλεγα LocationController ή LocationProvider) μέσα στην οποία βάζεις αυτή τη μέθοδο.

 

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

[pinball_elf]

Μια άλλη λύση είναι να χωρίσεις τον χάρτη σε τομείς συναρτήσει των διαστάσεων του. Κατά την τοποθέτηση των αντικειμένων στον χάρτη να φτιάχνεις έναν πίνακα (lookup table), με indexes τους τομείς του χάρτη, ο οποίος θα περιέχει τα αντικείμενα που υπάρχουν ή όχι στον αντίστοιχο τομέα. Κατά την κίνηση του παίκτη θα υπολογίζεις μόνο σε ποιόν τομέα του χάρτη βρήσκεται, και θα χρησιμοποιείς τον lookup table για να παίρνεις το αντικείμενα που βρίσκονται σε αυτόν. Μόλις ένα αντικείμενο χρησιμοποιείται θα πρέπει να το αφαιρείς απο τον lookup table.

 

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

[MitsakosGR]

Μια άλλη λύση είναι να χωρίσεις τον χάρτη σε τομείς συναρτήσει των διαστάσεων του. Κατά την τοποθέτηση των αντικειμένων στον χάρτη να φτιάχνεις έναν πίνακα (lookup table), με indexes τους τομείς του χάρτη, ο οποίος θα περιέχει τα αντικείμενα που υπάρχουν ή όχι στον αντίστοιχο τομέα. Κατά την κίνηση του παίκτη θα υπολογίζεις μόνο σε ποιόν τομέα του χάρτη βρήσκεται, και θα χρησιμοποιείς τον lookup table για να παίρνεις το αντικείμενα που βρίσκονται σε αυτόν. Μόλις ένα αντικείμενο χρησιμοποιείται θα πρέπει να το αφαιρείς απο τον lookup table.

 

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

 

Στην περίπτωση που ο χαρακτήρας είναι κοντά στην τομή δύο lookup tables όμως υπάρχει περίπτωση να χάσει αντικείμενα.

Εκτός και αν οι περιοχές αυτές επικαλύπτουν οι μία την άλλη για λίγο (όση η μέγιστη απόσταση χρήσης αντικειμένων) ώστε να αποφευχθεί η περίπτωση του να βρίσκεσαι στο όριο των περιοχών και να μην βλέπεις κοντινό αντικείμενο στην δίπλα περιοχή. (Σε αυτή την περίπτωση όταν ο χαρακτήρας είναι σε περιοχή που καλύπτεται από δύο lookup tables πρέπει να κοιτάς και τους 2.

[pinball_elf]

Στην περίπτωση που ο χαρακτήρας είναι κοντά στην τομή δύο lookup tables όμως υπάρχει περίπτωση να χάσει αντικείμενα.

Εκτός και αν οι περιοχές αυτές επικαλύπτουν οι μία την άλλη για λίγο (όση η μέγιστη απόσταση χρήσης αντικειμένων) ώστε να αποφευχθεί η περίπτωση του να βρίσκεσαι στο όριο των περιοχών και να μην βλέπεις κοντινό αντικείμενο στην δίπλα περιοχή. (Σε αυτή την περίπτωση όταν ο χαρακτήρας είναι σε περιοχή που καλύπτεται από δύο lookup tables πρέπει να κοιτάς και τους 2.

 

Το παρατήρησα λίγο αργότερα μετά την πρώτη μου διατύπωση, και νομίζω πως το απάντησα ήδη:

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