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

[Kercyn]

Από τις καλύτερες επιλογές είναι του Eberly

 

Αυτό εδώ λες;

https://www.crcpress.com/3D-Game-Engine-Design-A-Practical-Approach-to-Real-Time-Computer-Graphics/Eberly/p/book/9780122290633

[V.I.Smirnov]

Αυτό και το συνοδευτικό του για physics.

Είχα διαβάσει αρκετά από την προηγούμενη έκδοση.

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

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

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

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

το Α ως το Ω και να μάθουν ταυτόχρονα τη θεωρία των γραφικών.

Καλό είναι επίσης του Gregory αλλά για όποιον έχει κουράγιo του Eberly μαζί με τον κώδικα συνολικά  είναι πιο

"decent" σε λεπτομέρειες...

 

Γενικώς, τα βιβλία αυτά και κάποια όμοιά τους, με το συνοδευτικό τους υλικό, είναι για να μελετήσεις σε βάθος τι

γίνεται, όχι να μάθεις τυφλά ένα έτοιμο api.

Eξάλλου, λύσεις του στυλ "μάθετε game progamming σε μια εβδομάδα" δεν υπάρχουν. Αν δεν μελετήσεις μια

μηχανή σε low level (όχι χρήση "μαύρων κουτιών"), game programming δεν μαθαίνεται, ότι και να λένε κάποιοι...

 

-

[Kercyn]

Ωραία, γιατί έψαχνα κάποιο που να έχει περισσότερες λεπτομέρειες από αυτό του Gregory. Είναι πολύ καλό αλλά όπως είπες κι εσύ τις περισσότερες φορές είναι λακωνικό.

[V.I.Smirnov]

Του Eberly πρέπει να διαβαστεί ταυτόχρονα με τον κώδικα και το υλικό που υπάρχει στην ιστοσελίδα του.

Το βιβλίο μόνο του είναι απλώς ξερά μαθηματικά και ένα είδος manual για τους αλγόριθμους της μηχανής.

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

μεταξύ άλλων καλύπτει collision detection και physics.

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

Δεν είναι εύκολο ανάγνωσμα αλλά είναι από τα ελάχιστα που μπορείς να εμβαθύνεις πρακτικά στο στήσιμο

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

διαβάσεις πώς είναι οργανωμένα και πως δουλεύουν.

 

-

[stavrosyomafias]

 

 

 

 

 

Μάλιστα, σας ευχαριστώ πολύ.

[Alithinos]

 

Θα έλεγα όχι 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 και να φύγεις λίγο απ' αυτά που έχεις συνηθίσει. Ρίξε και μια ματιά εδώ. Είναι λίγο τρομακτικό στην αρχή αλλά μετά από λίγο που θα συνηθίσεις θα σου φαίνεται πολύ απλό.

 

Δεν είπα ότι έχει κακό documentation η Unity.

Όταν έγραψα "δεν μπορείς να βρεις το ίδιο εύκολα αυτό που θέλεις" δεν αναφερόμουν στο documentation στο site, αλλά μέσα στο ίδιο το πρόγραμμα. Ότι δηλαδή άλλο να πληκτρολογείς το όνομα αυτού που θες και αυτόματα να εμφανίζεται μπροστά σου, και άλλο να πρέπει να ψάξεις στο GUI να το βρεις.

 

Ενδιαφέρον το Tiled. Θα πρέπει να γράψω όμως μια κλάση για να κάνει import τα αρχεία και να είναι συμβατά με το MonoGame. Θα το δοκιμάσω. (y)

[Alithinos]

Τελικά κατέληξα σε Unity.

Αρχικά με είχε μπερδέψει λίγο το scripting, αλλά αφού διάβασα το σχετικό κεφάλαιο στο manual, τα πράγματα ξεκαθάρισαν.

Συγκεκριμένα με είχε μπερδέψει ο όρος "GameObject", καθώς μου έδινε την εντύπωση ότι είναι ένα αντικείμενο με το

συνηθισμένο τρόπο χρήσης της έννοιας, και περίμενα στη C# να έχω πρόσβαση στα GameObjects με το κλασικό τρόπο,

χρησιμοποιώντας τελείες, κάτι σε στυλ:

UnityGame1.GameObject1.AttachedScript1.x = 5;

και φυσικά κάτι τέτοιο δεν λειτουργούσε και έσπαγα το κεφάλι μου.

Τώρα πλέον όμως ξέρω να γράψω αυτό:

public GameObject gameObject1 = GameObject.Find("gameObject1");
var scriptFile = gameObject1.GetComponent<AttachedScript1>();
scriptFile.x = 5;

και να κάνω αυτό που θέλω.

 

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

 

Δε μπορώ να πω, μαθαίνεις αρκετά με το να ασχοληθείς με κάτι σαν το monoGame.

Για παράδειγμα κατάλαβα ακριβώς τι σημαίνει ο όρος Draw Calls που συχνά αναφέρεται στα video games,

ο οποίος μέχρι πριν ασχοληθώ με το monoGame ήταν πολύ abstract. Σε μηχανές όπως Unity, Unreal, κτλπ

είναι απλώς ένα metric για το performance..

Στο monoGame είναι κλήσεις στη μέθοδο Draw() (εξού και Draw - Calls) του API που ελέγχει τη GPU, τις

οποίες πρέπει να πληκτρολογήσεις ο ίδιος σε κάθε gameLoop.

Κάπου εκεί έκανα ξαφνική στροφή προς Unity μεριά, όταν έχοντας κατά νου ένα terrain που είχα φτιάξει

πειραματικά στο Unity Editor το οποίο είχε 10.000+ draw calls, συνειδητοποίησα πως στο monoGame θα 

έπρεπε για να φτιάξω το ίδιο terrain να γράψω και τις... 10.000 κλήσεις στη μέθοδο Draw() πληκτρολογώντας

τες ο ίδιος. Κάτι που θα μου έπαιρνε τουλάχιστον 10 φορές περισσότερο χρόνο. Παραείναι χαμηλό το επίπεδο του monoGame, τουλάχιστον για κάποιο αρχάριο στο game development.

 

 

Υ.Γ. Btw ξέρει κανείς κάποιο καλό tutorial για 2D Raycasting στη Unity ?

[Kercyn]

Δες batching για τα draw calls σου (τα οποία μου ακούγονται υπερβολικά πολλά). Τώρα για το raycasting, τι ακριβώς ψάχνεις; Τα docs εξηγούν με αηδιαστική λεπτομέρεια πώς να το χρησιμοποιήσεις.

 

Υ.Γ.: Ρίξε και μια ματιά εδώ.

[Alithinos]

Εντάξει προς το παρόν τα draw calls δεν αποτελούν πρόβλημα. Το terrain αυτό το έφτιαξα για πειραματισμό μιας και μπήκα σε creative mode, και άρχισα να φτιάχνω βουνά, μονοπάτια, να βάζω κάθε λογής δένδρα για δάση, κτλπ, με αποτέλεσμα η σκηνή να είναι πολύ φορτωμένη όταν η κάμερα κοιτά προς κάποιες πλευρές. Αλλά δε πειράζει, μιας και δεν το κρατάμε, ήταν απλά για εξοικείωση.

 

Ενδιαφέρον το doc. Είδα κάπου να λένε πως άμα θες πολύ συγκεκριμένα physics σε 2d games είναι καλύτερο να χρησιμοποιήσεις raycasts αντί για τα standard physics, και θέλησα να μάθω να τα χρησιμοποιώ για να δω τι και πως μπορώ να κάνω με αυτά.

[Alithinos]

Άκυρο.

 

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

 

Υ.Γ. Για την ιστορία ήθελα να φτιάξω mouse look που να συσχετίζει τη κίνηση του παίκτη με τη κατεύθυνση της κάμερας χωρίς ο παίκτης να πετάει όταν η κάμερα κοιτά στον ουρανό, και δεν έβρισκα το πως τόσες ώρες... Μετά θυμήθηκα τη Mathf.Clamp() και λύθηκε το πρόβλημα.

[BabyRage]

Μιας που μιλάτε για βιβλία για games engines: http://gameenginebook.com/  Βιβλίο που καλύπτει αρκέτα πράγματα σε βάθος και με κώδικα. Είναι αρκετά επιστημονικό όμως για τον Smirnov? 

[nikos5800]

για games ποια γλωσσα προγραμματισμου προτεινεται? απο οτι εψαξα κατι λιγο προτεινουν την c ως την καλυτερη

[Kercyn]

για games ποια γλωσσα προγραμματισμου προτεινεται? απο οτι εψαξα κατι λιγο προτεινουν την c ως την καλυτερη

 

C# αν θες ν' ασχοληθείς με Unity, C++ (κυρίως) για οτιδήποτε άλλο. Είμαι περίεργος να δω ποιος πρότεινε C...

[nikos5800]

σε ενα φορουμ της unity που διαβασα ειπαν οτι με την c# δεν θα πας και πολυ μακρια δεν θα μπορεις να κανεις π.χ καλυτερο optimization

[Kercyn]

σε ενα φορουμ της unity που διαβασα ειπαν οτι με την c# δεν θα πας και πολυ μακρια δεν θα μπορεις να κανεις π.χ καλυτερο optimization

 

Εεεε, το Unity χρησιμοποιεί C#, UnityScript και Boo, οπότε δεν καταλαβαίνω πού ακριβώς είναι αυτό το "πολύ μακριά" ούτε τι εννοεί καλύτερο optimization. Μάλλον κάτι άλλο έλεγε και τα μπέρδεψες.