Γενική συζήτηση περί Game Development

[defacer]

Διότι δεν υπάρχουν μισά pixels.

 

For the record, υπάρχουν: https://en.wikipedia.org/wiki/Subpixel_rendering

 

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

[M2000]

Τώρα σε πάω, γιατί τσίμπησες την ιδέα! Sub pixels σε κενά δεν υπάρχουν! Το άλλο είναι το Clear Type, και τα σχετικά.

[defacer]

Not bad θα έλεγα: http://ideone.com/FaZVKW

 

Υπόψιν η ιδέα είναι ότι κάνω justify κάθε γραμμή ξεχωριστά σα να μην υπήρχε άλλο input, άσχετα που στην πράξη υπάρχει.

 

Άμα δε βαρεθώ αργότερα ψήνομαι να δω πώς μοιάζει και σε πιο functional μορφή, τα procedural είναι κακάσχημα.

Τώρα σε πάω, γιατί τσίμπησες την ιδέα! Sub pixels σε κενά δεν υπάρχουν! Το άλλο είναι το Clear Type, και τα σχετικά.

 

Sub pixels σε κενά σαφώς υπάρχουν. Αν θέλω να κάνω justify το "Α B C" σε 6 χαρακτήρες απλά θα κάνω render το A στη θέση 0, το Β στην 2.5 κλπ. Το subpixel render του B στη φανταστική θέση 2.5 είναι αυτό που θα δημιουργήσει "κενά subpixel".

[M2000]

Δεν κάνεις Subpixels στην ουσία. Αυτά γίνονται από τη ρουτίνα που τυπώνει τους χαρακτήρες, σε σχέση με το Device Context άρα σε ένα επίπεδο που δεν έχουμε- πρόσβαση. Σημείωσε δε ότι δεν νοούνται sub pixels σε κείμενο σε γωνία.

Οπότε το "κενό" subpixel ή θα ήταν γεμάτο στο ολόκληρο δηλαδή ή θα έχει ένα χρώμα (κάποιο από τα R, G, Β). Εφόσον έστω και ένα είναι "αναμμένο" σημαίνει ότι το Pixel έχει χρησιμοποιηθεί. Το Subpixel απλά εφαρμόζεται σε ακμές, μόνο σε χαρακτήρες, και μόνο σε οριζόντια εμφάνιση, και μόνο στην οθόνη. (δεν υπάρχει και δεν είναι αναγκαίο να υπάρχει σε εκτυπωτή).

Θα δω το πρόγραμμά σου, αμέσως μετά!

Είδα την ρουτίνα σου! Παρατήρησα ότι το πρόγραμμά σου σε Php, Βασίζεται στο μήκος αθροίσματος δυο συνεχόμενων λέξεων, και ταξινόμηση όλων των ζευγαριών, για να βγει η σειρά για το επιπλέον διάστημα από τα υπολειπόμενα, και χρησιμοποιεί γραμματοσειρά σταθερού μήκους. Δεν παίζει ρόλο το μέγεθος δυο συνεχόμενων λέξεων για το μέγεθος του διαστήματος (είναι όμως ένας τρόπος στο δικό σου πρόγραμμα, διαμοιρασμού κενών και δουλεύει)

Φαντάσου τώρα που έκανες κάτι σε text για εκτυπωτή dot matrix της δεκαετίας του 80 (εκεί είχε σταθερού μήκους χαρακτήρες), να φτιάξεις το ανάλογο με αναλογική γραφή, και με υπoλογισμό του kerning. (Το kerning το χάνεις αν μετράς μήκος λέξεων, ενώ το έχεις όταν μετράς με την λέξη συμπληρωμένη στη σειρά της, και όταν χρειάζεται να σπάσεις μια λέξη...εκεί είναι τα δύσκολα)

 

kerning: π.χ. τα γράμματα αυτά έχουν κοινό χώρο: fj

[defacer]

Όπου χαρακτήρες στο πρόγραμμά μου, βάλε pixels. Δεν αλλάζει τίποτα στη λογική και δε σε απασχολεί τι γίνεται με το kerning εφόσον το αντίστοιχο της "μέτρα χαρακτήρες" strlen για σένα θα είναι η "μέτρα πόσο πιάνει το render" π.χ. MeasureString η οποία υπολογίζει εσωτερικά το kerning -- υποθέτω ότι αυτό είναι το επίπεδο που δουλεύουμε, αλλιώς δε μιλάμε για justify πλέον αλλά για σοβαρή τυπογραφία.

[M2000]

Στην αναλογική γραφή δεν μπορείς να δώσεις ένα π,χ, 1000pixels και να περιμένεις κάθε λέξη να σου δώσει τα πόσα pixels είναι, για τον απλούστατο λόγο ότι τότε πρέπει το διάστημα που έχεις να είναι 1 pixel. Δηλαδή εσύ έχεις θέσεις ανά χαρακτήρα (σταθερού μήκους), άρα και το διάστημα θα είναι στο ελάχιστο όσο ένας χαρακτήρας. Μόλις πας στα pixels, τότε το διάστημα πόσο είναι; Αν για παράδειγμα είχες δυο λέξεις που γέμιζαν ένα πλάτος 1000pixels, και άφηναν 2 pixels κενό τότε θα το άφηνες ή θα έκανες αναδίπλωση λέξης; Έτσι πρέπει να ορίσεις ένα μίνιμουμ πλάτος. Ποιo όμως αυτό του πλάτους του "i" ή του "w".

 

Δες εδώ http://php.net/manual/en/function.imagettfbbox.php για text metrics σε php.

 

Η συνάρτηση που έχω γράψει μετράει αριστερό περιθώριο, πλάτος, και τα κενά στην παράγραφο πριν την πρώτη λέξη, στη πρώτη γραμμή), αλλά κάνει και το εξής. Αντί να τυπώνει μπορεί να επιστρέφει το πόσες γραμμές βγαίνουν για δοσμένο μέγεθος γραμμάτων, στο συγκεκριμένο device context, και επίσης μπορεί να τυπώσει από την γραμμή που θέλουμε και για όσες γραμμές θέλουμε. Με αυτό το τρόπο μπορεί κανείς να βγάζει στήλες. Η συνάρτηση όταν τυπώνει δουλεύει λογαριάζοντας και την απόσταση γραμμής από γραμμή - το ενδιάμεσο περιθώριο), και επιπλέον αν είναι στην οθόνη (στην κονσόλα) και έχει πολλές γραμμές να βγάλει, κάνει ολίσθηση στην οθόνη και σταμάτημα στα 4/5 για πάτημα space ή κλικ με το ποντίκι (χωρίς να διακόπτει νήματα που τρέχουν στο περιθώριο).

[defacer]

Είπα νωρίτερα: όπου χαρακτήρας, βάλε pixel.

 

Λες, τώρα το διάστημα το έχεις στον ένα χαρακτήρα, μόλις πας στα pixel πόσο θα είναι; Ένα pixel. Δεν καταλαβαίνω γιατί δε συνεννοούμαστε. Αυτό δε σημαίνει ότι η απόσταση μεταξύ του τελευταίου γράμματος μιας λέξης και του πρώτου της επόμενης θα είναι ένα pixel, σημαίνει ότι ο καταμερισμός του κενού χώρου που περισσεύει γίνεται με ακρίβεια pixel.

 

Η ερώτηση "πόσα pixel είναι το μίνιμουμ πλάτος του κενού" δε βλέπω τι νόημα έχει. Είναι Ν pixel. Η τιμή του N προφανώς προκύπτει από τα metrics του font αλλά ποιά ακριβώς είναι δεν έχει σημασία. Στη δική μου περίπτωση βάζω Ν = 1 γιατί αυτό είναι σωστό με βάση τα χαρακτηριστικά της εξόδου (monospace font). Για proportional απλά διαλέγεις σα Ν το minimum που θεωρείς αποδεκτό με βάση το font και, για πολλοστή φορά, στον αλγόριθμο δεν αλλάζει τίποτα. Με τελείως τετριμμένες μετατροπές μπορώ να σου κάνω το πρόγραμμα αντί για 1+ κενό ανάμεσα στις λέξεις να έχει Ν+ όπου Ν όποιος αριθμός σου αρέσει που δίνεται ως παράμετρος.

 

Anyway επειδή είμαστε ήδη off topic και επειδή βλέπω το γνωστό pattern να δημιουργείται και πάλι (άρχισες πριν και έλεγες για kerning που είναι αδιάφορο σ' αυτό το επίπεδο abstraction, σου απάντησα, τώρα τα ξεχνάμε αυτά και λες πόσο είναι το ελάχιστο κενό λες και έχει σημασία στον αλγόριθμο, κλπ) προσωπικά το σταματάω εδώ.

[M2000]

Κοίτα για να καταλάβεις το θέμα. Αν αποφασίσεις ότι το ελάχιστο κενό είναι Ν pixels και έχεις μια λέξη ενός γράμματος, π.χ. το Ι το οποίο είναι μικρότερο από το N και είναι το τελευταίο της σειράς θα πάει στην επόμενη γραμμή; Αν το N μπορούσε να μικρύνει ένα pixel δεν θα έμπαινε το I;

Οκ. το σταματάμε εδώ!

[defacer]

Ρε συ τώρα σοβαρά μιλάς; Που τελειώνει αυτή η κολοκυθιά;

 

Αν το Ν ήταν 0 δε θα χωρούσαν περισσότερα γράμματα; Ναι. Μπορεί το Ν να γίνει 0; Όχι. Γιατί δε μπορεί το Ν να είναι 0; Γιατί (δε μ' ενδιαφέρει καθόλου ο λόγος).

 

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

 

Jesus.

[Alithinos]

Είπα να μάθω - ασχοληθώ και εγώ λίγο με το game development, τώρα που έχω μάθει κάπως καλύτερα κάποιες θεμελιώδεις αρχές της πληροφορικής.

 

Υπάρχουν πολλά tutorials, samples, κτλπ online, αλλά απ' τις πολλές πληροφορίες κάπου παθαίνεις υπερφόρτωση.

Έχω ένα δίλημμα και μια απορία:

 

Δίλημμα:

MonoGame (open source συνέχεια του XNA) ή Unity ?

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

Το μεν MonoGame όμως είναι framework με libraries για το , ενώ η Unity ολόκληρη μηχανή.

 

Το καθένα έχει τα υπέρ και τα κατά του όπως για παράδειγμα:

 

* Mε το MonoGame έχεις άμεσο έλεγχο στα πάντα, και μπορείς να ξέρεις ακριβώς πως δουλεύει το κάθε τι, αλλά πολλά πράγματα όπως εργαλεία τα οποία θα ήταν χρήσιμα πρέπει να τα φτιάξεις μόνος σου και να ανακαλύψεις ξανά το τροχό. Ότι μάθεις όμως θα σου είναι χρήσιμο και πέρα από το ίδιο το MonoGame. Επιπρόσθετα ότι φτιάξεις με το MonoGame είναι 100% royalty free.

 

* Με τη Unity υπάρχει αυτοματισμός σε πολλά πράγματα, αλλά δεν ξέρεις τι ακριβώς γίνεται 'πίσω απ τη κουρτίνα', και για να μπορείς να δουλέψεις πρέπει να κάτσεις να μάθεις που στο GUI έχουν κρύψει το κάθε τι, που σημαίνει πως άμα αλλάξεις εργαλείο, μεγάλη ποσότητα από ότι έμαθες πάει χαμένη. Επίσης η 'free license' είναι free μέχρι ένα ποσό, και άμα τα έσοδα σου είναι μεγαλύτερα, σε υποχρεώνει να πληρώνεις μηνιαία συνδρομή.

 

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

 

 

 

Υ.Γ. Δύο μέρες ξεκίνησα να μαθαίνω game dev, και ρίχνω ματιές και στο monogame και στη unity, για να δω πως κάνουν διάφορα πράγματα. Μέχρι στιγμής έχω μάθει μόνο πως να περνάω sprite και να θέτω τη σειρά εκτύπωσης τους απ' τη GPU, (επιπρόσθετα στη Unity πως να φτιάχνω 2d animation από Ν αριθμό sprites).

[Kercyn]

Καταρχάς θέματα royalties δε θα έπρεπε να σε απασχολούν εκτός αν βγάζεις $100k+/yr, το οποίο δε συμβαίνει.

 

Mε το MonoGame έχεις άμεσο έλεγχο στα πάντα, και μπορείς να ξέρεις ακριβώς πως δουλεύει το κάθε τι

 

Αυτό είναι σχετικό. Ναι, technically έχεις δίκιο, αλλά πρακτικά δεν έχει διαφορά. Αν δεν ξέρεις τι είναι το raycasting και πώς δουλεύει, το να κοιτάξεις τον κώδικα περισσότερο θα σε μπερδέψει παρά θα σε ξεμπερδέψει. Αν, από την άλλη, ξέρεις τι είναι το raycasting, τότε και πάλι δε θα είχε διαφορά, τουλάχιστον σε πρώτο επίπεδο τώρα που μαθαίνεις. Το να θες να κάνεις customιές στο engine/framework/whatever σημαίνει ότι α) ξέρεις πολύ καλά τι αλλαγές χρειάζεσαι, γιατί τις χρειάζεσαι, πώς θα τις υλοποιήσεις και τι επιπτώσεις θα έχουν ή β) θες να το χαλάσεις ως μέρος της μάθησης, να δεις τι θα γίνει κλπ.

 

 

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

 

Και στο Unity συμβαίνει αυτό. Ναι σου δίνει πάρα πολλά πράγματα έτοιμα, αλλά αν θες να φτιάξεις οτιδήποτε άλλο πέρα από trivial tutorial-level projects πρέπει να λερώσεις τα χέρια σου και πολλές φορές να βρεις ευφάνταστες λύσεις και workarounds για να κάνεις κάτι.

 

 

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

 

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

 

 

για να μπορείς να δουλέψεις πρέπει να κάτσεις να μάθεις που στο GUI έχουν κρύψει το κάθε τι, που σημαίνει πως άμα αλλάξεις εργαλείο, μεγάλη ποσότητα από ότι έμαθες πάει χαμένη

 

Αυτό δεν είναι ακριβώς σωστό. Εκτός του ότι αυτό ισχύει για τα πάντα (και MonoGame να χρησιμοποιήσεις πάλι πρέπει να μάθεις το API, το σχεδιασμό του κλπ), μπορείς πολλά απ' αυτά που μαθαίνεις να τα μεταφέρεις και σε άλλο engine/framework. Όταν πας σε κάτι καινούριο πάντα υπάρχει ένα learning curve το οποίο γίνεται ευκολότερο άμα έχεις ξανασχοληθεί με κάτι παρόμοιο. Οι μεθοδολογίες και ο τρόπος σκέψης δεν αλλάζει πολύ.

 

Έγραψες κάτι για πολλαπλά game loops και Update, αλλά μάλλον το έσβησες μετά, οπότε το αφήνω.

 

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

[stavrosyomafias]

Γεια σας, θα ήθελα κι εγώ να ασχοληθώ με Game Development,  και είμαι προετοιμασμένος να ξοδέψω αρκετό χρόνο σε αυτό.

Παρόλα αυτά είμαι πολύ μπερδεμένος με το πώς να ξεκινήσω. Για παράδειγμα να ξεκινήσω με μια game engine σαν την Unity και να εξασκηθώ σε αυτήν. Ή να ξεκινήσω να μαθαίνω OpenGL/WebGL/Canvas (γιατί δεν έχω την παραμικρή ιδέα από όλα αυτά τα APIs και γενικά από GameDev), και μετά να προσχωρήσω σε μια game engine? Και αν προτείνεται το δεύτερο ποιο από όλα τα APIs να διαλέξω (WebGL ή Canvas, δεν έβαλα το OpenGL, γιατί έχω μια ιδιαίτερη αδυναμία στην JavaScript)? Εδώ να αναφέρω ότι ξέρω τα βασικά από: C, Java, C#, Javascript. Λέγοντας τα βασικά, εννοώ λίγα πράγματα, σε ακαδημαϊκό επίπεδο, ελπίζω να καταλάβατε.

[Alithinos]

Καταρχάς θέματα royalties δε θα έπρεπε να σε απασχολούν εκτός αν βγάζεις $100k+/yr, το οποίο δε συμβαίνει.

 

 

Αυτό είναι σχετικό. Ναι, technically έχεις δίκιο, αλλά πρακτικά δεν έχει διαφορά. Αν δεν ξέρεις τι είναι το raycasting και πώς δουλεύει, το να κοιτάξεις τον κώδικα περισσότερο θα σε μπερδέψει παρά θα σε ξεμπερδέψει. Αν, από την άλλη, ξέρεις τι είναι το raycasting, τότε και πάλι δε θα είχε διαφορά, τουλάχιστον σε πρώτο επίπεδο τώρα που μαθαίνεις. Το να θες να κάνεις customιές στο engine/framework/whatever σημαίνει ότι α) ξέρεις πολύ καλά τι αλλαγές χρειάζεσαι, γιατί τις χρειάζεσαι, πώς θα τις υλοποιήσεις και τι επιπτώσεις θα έχουν ή β) θες να το χαλάσεις ως μέρος της μάθησης, να δεις τι θα γίνει κλπ.

 

 

 

Και στο Unity συμβαίνει αυτό. Ναι σου δίνει πάρα πολλά πράγματα έτοιμα, αλλά αν θες να φτιάξεις οτιδήποτε άλλο πέρα από trivial tutorial-level projects πρέπει να λερώσεις τα χέρια σου και πολλές φορές να βρεις ευφάνταστες λύσεις και workarounds για να κάνεις κάτι.

 

 

 

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

 

 

 

Αυτό δεν είναι ακριβώς σωστό. Εκτός του ότι αυτό ισχύει για τα πάντα (και MonoGame να χρησιμοποιήσεις πάλι πρέπει να μάθεις το API, το σχεδιασμό του κλπ), μπορείς πολλά απ' αυτά που μαθαίνεις να τα μεταφέρεις και σε άλλο engine/framework. Όταν πας σε κάτι καινούριο πάντα υπάρχει ένα learning curve το οποίο γίνεται ευκολότερο άμα έχεις ξανασχοληθεί με κάτι παρόμοιο. Οι μεθοδολογίες και ο τρόπος σκέψης δεν αλλάζει πολύ.

 

Έγραψες κάτι για πολλαπλά game loops και Update, αλλά μάλλον το έσβησες μετά, οπότε το αφήνω.

 

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

Κοίτα αυτό για τη μάθηση εννοώ το εξής:

Πχ στο monogame, μαθαίνεις διάφορες κλάσεις που έχει, και τι κάνουν οι μεθόδοι τους.

Είναι σχετικά εύκολο να βρεις τις κλάσεις και τις μεθόδους του, τα βγάζει όλα το intellisense, και μπορείς εύκολα και άμεσα να βρεις αυτό που θέλεις γράφοντας το όνομά του. Αρκετές κλάσεις και μέθοδοι είναι self-explanatory με τις ονομασίες τους, και αν χρειάζεσαι κάτι ρίχνεις μια ματιά στο documentation. 

Αλλά στη Unity δεν μπορείς με τον ίδιο εύκολο τρόπο να βρεις αυτό που θέλεις. Βέβαια, αφού φορτώσεις ένα script στο VS, θα βγάλει και για τα libraries της Unity intellisense, αλλά πχ άμα θέλω να ρυθμίσω τα controls, το workflow στο monogame είναι το γνωστό:

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

Στη unity δεν είναι τόσο απλό. Πρέπει καταρχάς να βρω το σχετικό παράθυρο και να κάνω εκεί κάποιες αλλαγές, και μετά να γράψω επιπλέον το κώδικα σε script.

Απλά έχω συνηθίσει το workflow της τυπικής ανάπτυξης εφαρμογής στο VS, και το να πρέπει να μάθω πως να κάνω τα ίδια πράγματα μέσω GUI & code, με το GUI να είναι συγκεκριμένο για τη Unity, μου φαίνεται πλεονασμός.

 

Από την άλλη όμως...

Αυτό ακριβώς έχει και τα αρνητικά του. Είναι οι αυτοματισμοί που ανέφερα νωρίτερα.

Πάρε για παράδειγμα τη τοποθέτηση των αντικειμένων στη σκηνή.

Στη Unity αυτό γίνεται πολύ πιο εύκολα και γρήγορα. Απλά σέρνω με το ποντίκι πράγματα στο Scene Window. Στο monogame τα πάντα πρέπει να τα τοποθετήσω προγραμματιστικά, εκτός αν φτιάξω δικό μου Scene Window για το monogame. Και όταν λέω προγραμματιστικά, εννοώ για κάθε sprite να καλέσω και μια μέθοδο που να στέλνει μήνυμα στη GPU να ζωγραφίσει το sprite, περνώντας ως arguments το όνομα του sprite, το Vector2 του οποίου τις συντεταγμένες πρέπει να υπολογίσω κάνοντας τις απαραίτητες μαθηματικές πράξεις... Εντάξει πρόσθεση και αφαίρεση είναι, αλλά φαντάσου να το κάνεις αυτό για κάθε tile.  Ειδικά αν θες να φτιάξεις ένα level μεγάλο.

Εκτός και αν κάνει κανείς το άλλο: Πάρει κανείς τα tile και τα τοποθετήσει όπως πρέπει σε ένα πρόγραμμα τύπου Paint.NET, Photoshop, και στο τέλος κάνει export το level ολόκληρο, το περάσει

στο VS ως ένα αντικείμενο sprite, και μετά κάτσει να γράψει vector τοποθεσίας, collision,κτλπ.

Αλλά και πάλι, αν το level είναι μεγάλο, θα είναι μεγάλο και το μέγεθος εικόνας, και η RAM θα τρώγεται σαν φρέσκα λαχταριστά donuts, άσε που το monogame έχει αυστηρό περιορισμό στο μέγεθος sprite που μπορείς να περάσεις.

 

Όσων αφορά το monoGame, είναι επί της ουσίας συνέχεια του παλιού XNA της Microsoft. Όταν ήταν να βγάλει το xbox360, έφτιαξε ένα framework με σκοπό να κάνει την ανάπτυξη παιχνιδιών πιο εύκολη από ότι ήταν μέχρι τότε, με το οποίο θα μπορούσε κανείς να φτιάξει παιχνίδια τόσο για Windows, όσο και για το 360. Αυτό τότε βοήθησε πολλούς indies να φτιάξουν κάτι και να το βάλουν στο xbox live marketplace. Αφού πλέον είχαν όμως βγει μηχανές όπως η Unity, και η Cryengine, και είχε εξελιχθεί περισσότερο και η Unreal, έπαψε να το ανανεώνει και να το υποστηρίζει. Πριν απ' αυτό όμως, κάποιοι είχαν φτιάξει compilers ώστε τα project γραμμένα με XNA, να μπορούν να εξάγονται και σε εκτελέσιμα για άλλες πλατφόρμες. Αφού η Microsoft σταμάτησε να το υποστηρίζει και το έκανε open source, η ομάδα που είχε φτιάξει τους compilers, πήρε πάνω της την ενημέρωση και συνέχεια του XNA, και αυτό πλέον ονομάζεται monoGame. 

 

 

Γεια σας, θα ήθελα κι εγώ να ασχοληθώ με Game Development,  και είμαι προετοιμασμένος να ξοδέψω αρκετό χρόνο σε αυτό.

Παρόλα αυτά είμαι πολύ μπερδεμένος με το πώς να ξεκινήσω. Για παράδειγμα να ξεκινήσω με μια game engine σαν την Unity και να εξασκηθώ σε αυτήν. Ή να ξεκινήσω να μαθαίνω OpenGL/WebGL/Canvas (γιατί δεν έχω την παραμικρή ιδέα από όλα αυτά τα APIs και γενικά από GameDev), και μετά να προσχωρήσω σε μια game engine? Και αν προτείνεται το δεύτερο ποιο από όλα τα APIs να διαλέξω (WebGL ή Canvas, δεν έβαλα το OpenGL, γιατί έχω μια ιδιαίτερη αδυναμία στην JavaScript)? Εδώ να αναφέρω ότι ξέρω τα βασικά από: C, Java, C#, Javascript. Λέγοντας τα βασικά, εννοώ λίγα πράγματα, σε ακαδημαϊκό επίπεδο, ελπίζω να καταλάβατε.

 

Αυτό που θα σου πρότεινα εγώ σαν έταιρος newbie, είναι να ξεκινήσεις διαβάζοντας αυτό το βιβλίο:

Game Coding Complete .

 

Αυτό το βιβλίο αναλύει γενικά σε υψηλό επίπεδο πως λειτουργούν τα video games, σε μαθαίνει τη 'θεωρία' να το πούμε έτσι, πράγματα που πρέπει να τα ξέρουμε.

Το διαβάζω τώρα και είμαι στο 2ο κεφάλαιο, και μπορώ να πω είναι απολαυστικό στο διάβασμα.

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

[Kercyn]

Γεια σας, θα ήθελα κι εγώ να ασχοληθώ με Game Development,  και είμαι προετοιμασμένος να ξοδέψω αρκετό χρόνο σε αυτό.

Παρόλα αυτά είμαι πολύ μπερδεμένος με το πώς να ξεκινήσω. Για παράδειγμα να ξεκινήσω με μια game engine σαν την Unity και να εξασκηθώ σε αυτήν. Ή να ξεκινήσω να μαθαίνω OpenGL/WebGL/Canvas (γιατί δεν έχω την παραμικρή ιδέα από όλα αυτά τα APIs και γενικά από GameDev), και μετά να προσχωρήσω σε μια game engine? Και αν προτείνεται το δεύτερο ποιο από όλα τα APIs να διαλέξω (WebGL ή Canvas, δεν έβαλα το OpenGL, γιατί έχω μια ιδιαίτερη αδυναμία στην JavaScript)? Εδώ να αναφέρω ότι ξέρω τα βασικά από: C, Java, C#, Javascript. Λέγοντας τα βασικά, εννοώ λίγα πράγματα, σε ακαδημαϊκό επίπεδο, ελπίζω να καταλάβατε.

 

Θα έλεγα όχι OpenGL αν δε γνωρίζεις καλά τη γλώσσα που θα χρησιμοποιήσεις (C, Java, w/e). Όντας low level, θα χρειαστεί να διαβάσεις αρκετά για το τι είναι αυτό που υλοποιεί και πολλές φορές το documentation θα είναι δυσνόητο και τα tutorials ελλιπή, απαρχαιωμένα ή straight up λάθος.

Για τη WebGL υπάρχουν έτοιμα frameworks αν δε θες να ξεκινήσεις από το μηδέν, αλλά και πάλι θα πρέπει να διαβάσεις πράγματα σχετικά με το τι γράφεις. Το ότι γράφεις javascript δεν έχει και πολύ νόημα, πάλι API calls θα κάνεις. Νόημα έχει στο υπόλοιπο πρόγραμμα που θα φτιάξεις.

Με Canvas δεν έχω ασχοληθεί οπότε δεν έχω να σου πω κάτι.

Με το Unity θα είναι πιο εύκολα τα πράγματα και θα μπορείς πιο γρήγορα να κάνεις κάτι ωραίο. Από κει και πέρα είναι το πόσο θ' ασχοληθείς και πόσο θες να εμβαθύνεις.

 

Θα σου έλεγα να δοκιμάσεις και Unity και WebGL (με ή χωρίς framework) και να δεις εσένα ποιο σου αρέσει πιο πολύ. Με WebGL θα μάθεις αναγκαστικά κάποια πράγματα και δε θα μπορείς να προχωρήσεις χωρίς αυτά, ενώ με το Unity θα μπορείς αν θες να μείνεις στο "θέλω να κάνω αυτό, άρα καλώ αυτό και δε με νοιάζει πώς δουλεύει" (τουλάχιστον σε πρώτο στάδιο).

 

 

 

 

Αυτό που λες για το documentation δεν το καταλαβαίνω. Το Unity έχει εξαιρετικό (τις περισσότερες φορές) documentation με επεξηγήσεις και παραδείγματα, και ενεργό community για ό,τι απορία έχεις.

 

Για τους χάρτες σου, δες το Tiled. Μπορείς να βάζεις τα δικά σου tilesets και να κάνεις export τους χάρτες σε XML. Υποστηρίζει και object groups όπου μπορείς να βάλεις ό,τι επιπλέον πληροφορία θέλεις.

 

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

[V.I.Smirnov]

To game programming αποτελείται απο πολλούς τομείς και κυρίως προγραμματισμό και χειρισμό γραφικών.
Για τον προγραμματιστή, μια έτοιμη μηχανή γραφικών, ήχου ή ΑΙ, είναι απλώς ένα "μαύρο κουτί".
Μπορείς να μάθεις τη λειτουργία της και να κάνεις άμεσα δουλειά.

 

Αλλά αν θες να αποκτήσεις πραγματικό υπόβαθρo πρέπει να μάθεις πώς είναι στημένη και πώς λειτουργεί μια

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

για το opengl ή το directΧ και να μελετήσεις αλγορίθμους γραφικών.
Αυτά που είναι προσανατολισμένα στο game programming συνήθως έχουν μια υποτυπώδη μηχανή γραφικών

όπου μπορείς να δεις τι γίνεται σε εισαγωγικό επίπεδο μαθαίνοντας ταυτόχρονα και το api.

Yπάρχουν πολλά βιβλία τέτοιου είδους, εξαιρετικά ακόμη και εντελώς αρχάριους. Οι (απαρχαιωμένες πλέον)

σειρές του Astle για το openGL είναι ένα παράδειγμα. Τα βιβλία τoυ Luna για το directX είναι επίσης εξαιρετικά.

 

Από εκεί και πέρα, πρέπει να αχοληθείς με κάποιο βιβλίο που περιγράφει λεπτομερώς τη δομή κάποιας μηχανής

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

πολλά θέματα γραφικών, collision detection και physics και τα υλοποιεί στην πράξη. Ο κώδικας που δίνει είναι ο

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

ιστοσελίδα του αλλά ετοιμάσου για πολλά μαθηματικά. Not for the faint heart !!!
Οι σειρές βιβλίων game programming gems, game engine gems και AI programming widsom είναι επίσης

"εκ των ων ουκ άνευ" καθώς περιέχουν διαλεγμένο εξαιρετικό υλικό από γκουρού - μπορείς να τα βλέπεις αφού

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

πραγματικά. Η τυφλή χρήση μηχανών όπως η Unity είναι απλώς πιθηκισμοί. Είναι γελοιότητα κάποιος να λέει

ότι ασχολείται με μηχανές γραφικών και να μην ξέρει την εξίσωση ευθείας στον χώρο...

-