Προτεινόμενη εναλλακτική αρχιτεκτονική / design pattern για videogame AI ?

[Alithinos]

Καλημέρα Insomnia.

Φτιάχνω ένα παιχνίδι εδώ και κάποιο καιρό, και εδώ και κάτι μέρες με απασχολεί το θέμα του AI διάφορων non-playable characters. Φυσικά όταν μιλάμε για ΑΙ σε video games, αυτό που εννοούμε είναι κάτι διαφορετικό απ το πραγματικό ΑΙ.

 

Το ΑΙ ενός παιχνιδιού είναι αρκετά καλό όταν για κάθε μια κατάσταση από n καταστάσεις αντιδρά με έναν αντίστοιχο προκαθορισμένο τρόπο, ο οποίος είναι 'λογικός'. Σκοπός είναι να φτιάξω ένα γενικό σύστημα 'ΑΙ' το οποίο θα χρησιμοποιείται από κάθε χαρακτήρα / τέρας, και θα είναι customizable προκειμένου με τη σωστή αρχικοποίηση μεταβλητών του component να μπορώ εύκολα να αλλάξω τους τρόπους που θα συμπεριφέρεται το κάθε πλάσμα ανάλογα το γεγονός.

 

πχ αν ο παίκτης επιτεθεί σε μια γάτα, η γάτα μάλλον θα το βάλει στα πόδια, αλλά αν επιτεθεί σε δράκο, ο δράκος μάλλον θα αντεπιτεθεί.

 

Ξεκίνησα λοιπόν να φτιάχνω το σύστημα αυτό χρησιμοποιόντας τη τεχνική του finite state machine.

Γίνεται έλεγχος για τη κατάσταση κάποιων μεταβλητών με άλλα λόγια, και με switch, if/else ανάλογα τη κατάσταση των μεταβλητών, μεταπηδά το ΑΙ από τη μια συμπεριφορά στην άλλη. Αυτό ήταν το πρώτο που σκέφτηκα μιας και φάνηκε απλό, αλλά στη συνέχεια καθώς έβρισκα νέους τρόπους συμπεριφοράς, και νέες περιστάσεις στις οποίες θέλω να αντιδρά, ανακάλυψα ότι υπάρχει ένα σημαντικό πρόβλημα: Ο αλγόριθμος προσθήκης κάθε νέας κατάστασης στην οποία θέλω να αντιδρά το ΑΙ ίσως να είναι 'καλός' για 4-5 καταστάσεις, αλλά η πολυπλοκότητα του αρχίζει και γρήγορα κάνει την ανάπτυξη του χαοτική, μιας και για κάθε νέο ερέθισμα στο οποίο θέλω να αντιδρά το ΑΙ, θα πρέπει να γράψω περισσότερο κώδικα απ' άπ ότι για το προηγούμενο, ώστε να μπορούν να γίνονται transitions απ' τη μια κατάσταση στην άλλη.

 

Όπως δείχνει το αριστερό γράφημα με τους κύκλους σε αυτή την εικόνα:

 

 

 

πρέπει όλες οι καταστάσεις (που αναπαριστούνται με κύκλους) να επικοινωνούν με όλες τις υπόλοιπες.

 

Και άμα έχεις πολλές καταστάσεις που θες να εφαρμώσεις, γρήγορα η ανάπτυξη του συστήματος γίνεται κουραστική, και χαοτική θα έλεγα. Στην αρχή είχα ξεκινήσει να φτιάχνω αυτό το σύστημα ως μια κλάση / code file, αλλά η πολυπλοκότητα και η ποσότητα κώδικα που χρειάζεται έφτασε σε σημείο που χρειάστηκε να το μοιράσω σε διαφορετικά files, και να φτιάξω υποκλάσεις με χαμηλότερου επιπέδου μεθόδους που καλούνται από άλλες υψηλότερου... Και από ένα σημείο και μετά το σύστημα γίνεται πολύ χαοτικό λόγο της πολυπλοκότητας, και ακόμα και αν δεν έχεις πρόβλημα να κάθεσαι να ξοδέψεις τις παραπάνω ώρες εργασίας για τη προσθήκη του κάθε node, έχεις πρόβλημα γιατί υπάρχουν τόσα πολλά nodes και υπό-καταστάσεις καταστάσεων που απλά... χάνεσαι.

 

Οι καταστάσεις ελέγχου που θέλω είναι πάρα πολλές

 

πχ ένα μικρό δείγμα: 

 

Είναι ο παίκτης εντός του πεδίου αντίληψης ?

Είμαι εχθρός ή φίλος του παίκτη ?

Έχω όπλο ?

Τι όπλο έχω ?

Που θα βρω όπλο ?

Ποια η εμβέλεια του όπλου ?

Μπορώ να κατευθυνθώ προς το παίκτη ώστε να βρεθώ στην εμβέλεια του όπλου ?

Μπορώ να κολυμπήσω στο νερό ?

Με τι ταχύτητα να μετακινηθώ ?

Αν ο παίκτης έχει το super duper όπλο να το βάλω στα πόδια, ή να συνεχίσω να πολεμώ ?

Αν ο παίκτης κάνει άμυνα τι να κάνω ?

Αν χάνω και είμαι στα τελευταία μου να παραδοθώ, να συνεχίσω να πολεμώ ή να το βάλω στα πόδια ?

Αν το βάλω στα πόδια που να πάω ?

Αν υπάρχει φωτιά, είναι το όπλο μου εύφλεκτο για να αρπάξει φωτιά και να κάνει επιπλέον fire damage ?

Μήπως θα καω και εγώ όμως ?

...

 

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

 

Πιθανότατα το ΑΙ που έχω ήδη φτιάξει, να είναι ήδη αρκετά 'έξυπνο' σε σύγκριση με αυτά κάποιων άλλων indie games, και ίσως και κάποιων παιχνιδιών μεγάλων εταιριών, αλλά επειδή δεν φτιάχνεται το παιχνίδι από μια μεγάλη εταιρία με γνωστό brand και μερικές δεκάδες εκατομμύρια για marketing, και υπάρχει μεγάλος ανταγωνισμός, χρειάζεται αυτό το κάτι 'παραπάνω' για να ξεχωρίσει και να μη θαφτεί ανάμεσα σε εκατοντάδες indie games που βγαίνουν "με το κιλό" κάθε μήνα. Για αυτό και προσπαθώ να κάνω κάποια συστήματα όπως πχ το ΑΙ να αλληλεπιδρούν περισσότερο απ' τα συνηθισμένα της αγοράς. Και εκτός αυτού απλά θέλω να φτιάξω κάτι καλύτερο, για να νιώσω ικανοποιημένος με τον εαυτό μου, για να είναι όπως θέλω πραγματικά να είναι, όπως το οραματίστικα.

 

Επειδή όμως το να συνεχίσω να κάνω το ΑΙ πιο έξυπνο με βάση αυτή τη μέθοδο των ISMs καταντάει πολύ κουραστικό, αναρωτιόμουν αν υπάρχει ένας τελείως διαφορετικός τρόπος για να κάνω το ίδιο πράγμα. Ένα design pattern ίσως το οποίο δεν έχω υπ' όψιν και θα μπορούσε να χρησιμοποιηθεί για αυτό το σκοπό, για το οποίο η προσθήκη νέων χαρακτηριστικών δεν έχει τόσο μεγάλη καμπύλη αύξησης πολυπλοκότητας.

 

Ευχαριστώ.

[solarpower]

Απλά μια ιδέα...Χρησιμοποίησε βάρη, δηλαδή δυαδικά νούμερα όπου  κάθε bit θα συμβολίζει μια κατάσταση. Έχει σημασία πως θα βάλεις τις καταστάσεις ανά bit, γιατί αν μια ομάδα "επίθεσης"  είναι πχ από το 5ο bit και μετά, τότε κάθε τελικό βάρος πάνω από 15 θα είναι επίθεση και αυτό βγαίνει από μια σύγκριση! Μπορείς δε να συγκρίνεις δυο "επιθετικά" bytes για να βγάλεις την προσδοκία επί ένα ποσοστό.

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

[Alithinos]

Βάρη.. Εννοείς να χρησιμοποιήσω neural networks ?

Μου πέρασε η ιδέα, αλλά σκέφτηκα πως ίσως να είναι overkill.

 

Δεν έχω φτιάξει κάτι με neural networks μέχρι στιγμής. Με τη πολυπλοκότητα πως τα πάει ?

Είναι σχετικά ευκολότερο να προσθέτω επιπλέον καταστάσεις ελέγχου σε σχέση με FSM ? 

[solarpower]

Να συνεχίσω τη πρότασή μου!

Ξεκινάς με βάρη, με την υπόθεση ότι αργότερα θα κάνεις κανονική AI. Το ουσιαστικό βήμα είναι η ανάδραση, το πώς θα συνδέσεις την ανάδραση, στην "συνάρτηση" που βγάζει τη στρατηγική "εξόδου". Γίνεται AI όταν με το αποτέλεσμα της στρατηγικής το πρόγραμμα βαθμολογεί την ποιότητα στρατηγικής. Ένας δυσδιάστατος πίνακας (η βάση γνώσης του παίκτη) έχει γραμμές που δηλώνουν στρατηγικές (ή μέρη αυτών), και στήλες με αποτελέσματα. Σαν περιεχόμενο έχει το βαθμό συσχέτισης αποτελεσμάτων και στρατηγικών. Σε δεύτερο πέρασμα αναβαθμολογεί με βάσει τα πραγματικά αποτελέσματα, και όπου είχε δοθεί το αποτέλεσμα "Στόχος" δίνει αρνηντικές τιμές. Κάθε "Πίστα" ή "Δωμάτιο" ή "Συμβάν" θα έχει μαζί και στόχους, τους οποίους θα διαβάζει ο αλγόριθμος βρίσκοντας τις κατάλληλες στατηγικές. Τώρα σκέψου ότι έχεις και άλλους παίκτες με δική τους βάση γνώσης, και σε δική τους ακολουθία συμβάντων. Σκέψου ακόμα ότι σε κάποια συμβάντα πέφτουν πολλά μαζί και πως κάποιοι παίκτες είναι πραγματικά άτομα και την επιλογή στρατηγικών την κάνουν χειροκίνητα, αλλά σκέψου ότι η βάση φτιάχνεται κανονικά, ώστε σε δεδομένη στιγμή που λείπει ο παίκτης (δεν είναι on line) να συνεχίζει να παίζει όπως έχει ήδη διαμορφώσει την δική του AI.

Από τα παραπάνω πρέπει να σκεφτείς τα σημεία εφαρμογής ΑΙ, σημείο που επιλέγονται οι στρατηγικές και σημείο που γίνεται η αποτίμηση του αποτελέσματος. Η πύκνωση ή αραίωση των σημείων αλλάζει τη δυσκολία του παιχνιδιού.

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

Έτσι για να γράψεις το πρόγραμμα πρέπει να ορίσεις τους στόχους των παικτών, τα γεγονότα ως διαφορετικές κατάστασεις που δύναται να έχουν, τις ενέργειες και κατ'επέκταση τις στρατηγικές.

Μπορεί στην αρχή να έχουμε απλά "text" κατάσταση, με την δράση να "διαφαίνεται" από τη θέαση λιστών, και μιας "λίστας νικητών". Δηλαδή την συμμετοχή του φυσικού παίκτη στις ενέργειες, πχ χρήση σπαθιού, τις αφηνουμε στο τέλος!

[Alithinos]

Χμ εννοείς κάτι σαν το GOAP ?

 

Να υπάρχει ας πούμε μια κλάση 'Action' με ένα pre-condition που χρειάζεται για να τρέξει, ένα result, ένα weight, και τον ιδιαίτερο κώδικα του action (πχ απόφυγε, κάνε επίθεση), και να υπάρχει ένας Manager που ελέγχει όλα τα actions και τα βάζει σε μια queue "Goal"  ανάλογα με τα pre-conditions και τα results τους, και εκτελεί τα actions απ το queue ένα προς ένα ?

 

υ.γ. προς το παρόν δε με απασχολούν τα διάφορα επίπεδα δυσκολίας του παιχνιδιού, αλλά μόνο το decision making, να βρω έναν πιο effective τρόπο να φτιάξω complex decision making, όπου το κάθε νέο decision που θέλω να προσθέσω δε θα απαιτεί xⁿ γραμμές κώδικα, αλλά απλά x. Ή τουλάχιστον x+1 ή x+2...

[Dr.Fuzzy]

Θα κάνεις hw υλοποίηση με ψηφιακή λογική; Διαφορετικά αν πρόκειται για sw υλοποίηση, το σχήμα που περιγράφει το FSM ως συνδυαστική λογική με στοιχεία μνήμης (Flip Flops) για τα states δεν σου χρειάζεται!

[solarpower]

Alithinos

Κάπως έτσι! Ξεκινάς με λίγα και προσθέτεις μετά.

[Alithinos]

Θα κάνεις hw υλοποίηση με ψηφιακή λογική; Διαφορετικά αν πρόκειται για sw υλοποίηση, το σχήμα που περιγράφει το FSM ως συνδυαστική λογική με στοιχεία μνήμης (Flip Flops) για τα states δεν σου χρειάζεται!

 

Sw.  Λοιπόν κρίνω κατάλληλο να εξηγήσω λίγο καλύτερα τι έχω κάνει έως τώρα. Μιας και απ' ότι διάβασα κάπου, όπως στα παιχνίδια πολλές φορές χρησιμοποιείται ο όρος ΑΙ για κάτι πιο απλό απ' τον γενικότερο ΑΙ, κάτι τέτοιο ίσως να συμβαίνει και για τα FSMs. 

 

 

Υπάρχει μια κλάση "Behavior Profile" η οποία:

 

#A Έχει έναν αριθμό enumerations με τη κάθε μεταβλητή enum να αντιστοιχεί σε ένα trigger που πυροδοτεί μια κατάσταση. Οι τιμές των enums καθορίζουν το τι θα κάνει (ποιο behavior θα εκτελέσει) αν οι συνθήκες της κατάστασης είναι true.

#Β Υπάρχουν μεταβλητές τύπου delegate, που αντιστοιχεί η κάθε μια σε  ένα behavior.

 

Στην εκτέλεση:

1. Κάνει polling σε κάθε frame ώστε να λάβει τιμές διάφορων μεταβλητών, ώστε να γνωρίζει την 'εξωτερική' κατάσταση, το state του κόσμου.

2. Ελέγχει τις μεταβλητές απ το state του κόσμου για το αν συμπίπτουν με τα conditions για να γίνει μια bool trigger true ή false.

3. Ακολουθεί έλεγχος για το κάθε bool αν true ή false, σε μερικές περιπτώσεις και συνδυαστικός περισσότερων, και αν true:

4. Γίνεται έλεγχος για το ποιο enum έχει επιλεχθεί σε ένα switch, και ανάλογα, εκτελείται η μέθοδος του delegate που αντιστοιχεί στο enum.

 

 

Τα προβλήματα που εντοπίζονται με αυτή τη πρακτική είναι τα εξής:

 

1) Οι έλεγχοι στα βήματα 2 και 3, και ιδιαίτερα στο 3, γίνονται χαοτικοί ύστερα από μια ποσότητα διαφορετικών states. Και αυτό επειδή η διαδρομή από τη μια bool στην άλλη δεν πρέπει να είναι πάντα μιας κατευθύνσεως. Για παράδειγμα, μπορεί να χρειάζεται μια συμπεριφορά Χ να πρέπει να εκτελεστεί υπό διαφορετικές συνθήκες (state). Φαντάσου τα if ως δέντρο. Στο δέντρο μπορείς να πας δεξιά ή αριστερά, αλλά πάντα προς τα κάτω. Δεν μπορείς να πας όμως πίσω στο προηγούμενο node, προς τα πάνω. Εκτός και αν τερματιστεί η διαδρομή και αρχίσει ξανά απ' το αρχικό node. Αλλά υπάρχουν καταστάσεις που δε θέλουμε κάτι τέτοιο.

 

2) Κάποια states διαθέτουν sub-states τα οποία με τη σειρά τους διαθέτουν μικρογραφίες του παραπάνω συστήματος που ανέφερα. Για παράδειγμα, στη Behavior Profile που περιέγραψα δεν υπάρχει καθόλου κώδικας για το πως να συμπεριφέρεται το ΑΙ όταν βρίσκεται συγκεκριμένα σε μάχη. Αλλά έφτιαξα άλλη κλάση, ειδικά για τη μάχη, της οποίας αντικείμενο δημιουργείται μέσα στη Behavior Profile, και όταν το ΑΙ βρεθεί σε Combat Mode καλείται μια μέθοδος του αντικειμένου, η οποία τρέχει όλα τα παραπάνω βήματα, ειδικά με conditions και states για τη μάχη. Φυσικά και οι 2 κλάσεις είναι άρρηκτα συνδεδεμένες και coupled, αλλά υπήρχε ήδη τόσος κώδικας με πολλά if/else/switch στη Behavior Profile που και μόνο να τα κοίταζες σε έπιανε δέος... Ίσως χρειάζεται περισσότερη ενθυλάκωση για να μη γίνεται τόσο χαοτικό με τόσες πληροφορίες in your face, αλλά θα είναι άρρηκτα συνδεδεμένα μεταξύ τους τα αντικείμενα αυτά, και αυτό γενικά δεν ενδεικνύεται. Άσε που και αυτό λύνει μόνο μέρος του προβλήματος, και δε λύνει το πρόβλημα 1).

[παπι]

Βασικα πρεπει να χωρίσεις το ai απο τον κώδικα. Και προφανως θα εχει πρόσβαση σε ενα πολυ υψηλό abstraction.

 

Γενικά απο design pattern, παιζει αυτο που λεμε game engine. Ουσιαστικα ειναι ενας interpreter που παιρνει script multimedia κλπ και τα κανει render.

 

Ενας απλος τροπος για να γραψεις ai. Φτιάξε ενα interface για το χ μοντέλο και στειλτω στον καθε παπι να σου γραψει ενα απλο ai για 5-6 καταστάσεις.

[k33theod]

Καλημέρα Insomnia.

Φτιάχνω ένα παιχνίδι εδώ και κάποιο καιρό, και εδώ και κάτι μέρες με απασχολεί το θέμα του AI διάφορων non-playable characters. Φυσικά όταν μιλάμε για ΑΙ σε video games, αυτό που εννοούμε είναι κάτι διαφορετικό απ το πραγματικό ΑΙ.

 

 

Οι καταστάσεις ελέγχου που θέλω είναι πάρα πολλές

 

πχ ένα μικρό δείγμα: 

 

Είναι ο παίκτης εντός του πεδίου αντίληψης ?

Είμαι εχθρός ή φίλος του παίκτη ?

Έχω όπλο ?

Τι όπλο έχω ?

Που θα βρω όπλο ?

Ποια η εμβέλεια του όπλου ?

Μπορώ να κατευθυνθώ προς το παίκτη ώστε να βρεθώ στην εμβέλεια του όπλου ?

Μπορώ να κολυμπήσω στο νερό ?

Με τι ταχύτητα να μετακινηθώ ?

Αν ο παίκτης έχει το super duper όπλο να το βάλω στα πόδια, ή να συνεχίσω να πολεμώ ?

Αν ο παίκτης κάνει άμυνα τι να κάνω ?

Αν χάνω και είμαι στα τελευταία μου να παραδοθώ, να συνεχίσω να πολεμώ ή να το βάλω στα πόδια ?

Αν το βάλω στα πόδια που να πάω ?

Αν υπάρχει φωτιά, είναι το όπλο μου εύφλεκτο για να αρπάξει φωτιά και να κάνει επιπλέον fire damage ?

Μήπως θα καω και εγώ όμως ?

...

 

Το "Αν το βάλω στα πόδια που να πάω ?"  φτάνει 

 

Δεν σε πιστεύουμε σταμάτα αμέσως αυτό που κάνεις 

 

https://www.designnews.com/governmentdefense/ai-and-robotics-companies-ask-un-ban-killer-robots/205674724557382

https://thenextweb.com/contributors/2017/09/17/weaponized-ai-ushers-terminator-era/#.tnw_WlOcQz23

https://www.teslarati.com/tesla-ceo-elon-musk-solidifies-stance-weaponizing-ai/

http://www.zdnet.com/article/uk-bans-fully-autonomous-weapons-after-elon-musk-letter/

[Alithinos]

Βασικα πρεπει να χωρίσεις το ai απο τον κώδικα. Και προφανως θα εχει πρόσβαση σε ενα πολυ υψηλό abstraction.

 

Γενικά απο design pattern, παιζει αυτο που λεμε game engine. Ουσιαστικα ειναι ενας interpreter που παιρνει script multimedia κλπ και τα κανει render.

 

Ενας απλος τροπος για να γραψεις ai. Φτιάξε ενα interface για το χ μοντέλο και στειλτω στον καθε παπι να σου γραψει ενα απλο ai για 5-6 καταστάσεις.

 

Ωραία λοιπόν, πήρα τις εξής αποφάσεις:

 

#1 Μιας και οι έλεγχοι είναι πάρα πολλοί, ξεκίνησα να φτιάχνω flowchart για να με βοηθήσει η οπτική αναπαράσταση. Αν και την ύπαρξη των flowcharts την ξέρω 2 χρόνια, σπάνια έχω κάτσει να φτιάξω σχεδιάγραμμα, γιατί συνήθως οι έλεγχοι τις περισσότερες φορές είναι ελάχιστοι και το flowchart για αυτούς είναι overkill. Τώρα όμως μάλλον είναι το κατάλληλο πρόβλημα για να φτιάξω οπτική αναπαράσταση.

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

#3 Θα προσπαθήσω αντί να έχω μια χειροκίνητη enum για κάθε συμπεριφορά / για κάθε γεγονός / για κάθε χαρακτήρα, να βρω κάποιους συχνά χρησιμοποιούμενους συνδυασμούς και να φτιάξω προφίλ με βάση αυτούς, ώστε να υπάρχει ένα enum με διαφορετικά προφίλ συμπεριφοράς που το κάθε προφιλ έχει προκαθορισμένες συμπεριφορές ανά γεγονός.

#4 Επειδή όπως προανέφερα οι έλεγχοι είναι πολύπλοκοι... Και σε ορισμένες περιπτώσεις θέλω αντί η ροή να πηγαίνει πάντα προς τα μια κατεύθυνση, να πηγαίνει και... αλλού, σκέφτομαι σοβαρά το να χρησιμοποιήσω το απαγαροευμένο όπλο: goto. Από τότε που μου λέγατε σε εκείνο το thread με τις απορίες για τη C# να μη τη χρησιμοποιώ, μου έγινε συνήθεια και δε την έχω χρησιμοποιήσει. Αλλά τώρα... ? 

Έστω ότι η ροή μοιάζει κάπως έτσι:

 

 

και θες από την Ε αντί να πας είτε στη J ή στη Κ να μπορείς να πας στη J ή την C χωρίς να χρειαστεί να ξανά-περάσεις απ την Α ?

 

Βέβαια υπάρχει και η άλλη επιλογή και να κάνεις copy απ τη C και κάτω, paste κάτω από την Ε, αλλά νομίζω ότι κάτι τέτοιο θα ήταν χειρότερο. Να έχεις duplicate code, ειδικά για κάτι τέτοιο.

 

Δεν σε πιστεύουμε σταμάτα αμέσως αυτό που κάνεις 

 

https://www.designnews.com/governmentdefense/ai-and-robotics-companies-ask-un-ban-killer-robots/205674724557382

https://thenextweb.com/contributors/2017/09/17/weaponized-ai-ushers-terminator-era/#.tnw_WlOcQz23

https://www.teslarati.com/tesla-ceo-elon-musk-solidifies-stance-weaponizing-ai/

http://www.zdnet.com/article/uk-bans-fully-autonomous-weapons-after-elon-musk-letter/

 

Χιχιχιχι 

Επεξ/σία 18 Σεπτεμβρίου 2017 από Alithinos

[ChRis6]

Δες τα behavior trees.

[tsofras]

Binary tree με preOrder traversal μήπως σου κάνει?

[Alithinos]

Δες τα behavior trees.

 

Ουφ! Όλη μέρα σήμερα αυτό κάνω. Τη σχεδίαση. Δεν έχω γράψει ούτε μια σειρά κώδικα. Σχεδιάζω μόνο.

 

Μέχρι στιγμής έχω κάνει αυτό:

 

 

Και νομίζω ότι έχω καλύψει ότι αφορά την αλληλεπίδραση ενός NPC με ένα άλλο ή το παίκτη.

Αν και θα ρήξω ένα double check / review ξανά αύριο, μήπως ξέχασα κάτι, γιατί απ' τη νύστα και τη κούραση ίσως αύριο να δω κάτι που δε το βλέπω τώρα.

 

Βέβαια ακόμα δεν έχει τελειώσει. Θα πρέπει να προσθέσω και τις ανάλογες αλληλεπιδράσεις ενός NPC με το περιβάλλον.

 

Υ.Γ. Ξέρω ότι τα σύμβολα σημειογραφίας ενδεχωμένως δημοσίως να έχουν άλλες έννοιες, αλλά αφού το κάνω μόνο για προσωπική χρήση, χρησιμοποιώ αυτά που μου αρέσουν περισσότερο!

Binary tree με preOrder traversal μήπως σου κάνει?

 

Σκέφτηκα να φτιάξω tree με nodes ή να βάλω απλά πολλές if/else μαζεμένες σε ένα σημείο.

Δεν έχω αποφασίσει ακόμα. 

[tsofras]

Βάλε μας και το αρχειάκι ρε μαν μου βγήκαν τα μάτια βραδιάτικα

 

Καλά κάνεις και το σχεδιάζεις, και πολύ το άργησες , ο χρόνος που έφαγες τώρα θα τον γλιτώσεις στο 10πλασιο. 

Επίσης να καταλάβουμε και εμείς καλύτερα που δεν είμαστε τόσο του θεωρητικού αλλά του πρακτικού

 

Υ.Γ.

Τώρα που έχουμε και διάγραμμα πές μας τι εννοούσες να πάς απο το Ε στο C