Nee, dat zou beetje veel overhead zijn voor een simpele statische database waar alleen maar (door 1 iemand tegelijk) uit gelezen wordt
dus hoe vinden ze al die maps, textures, geluidseffecten, etc. terug? Is het een script waarin maps worden gelinkt waarin al die andere dingen worden gelinkt? En staat daar dan tot op de file-offset-in-de-resource-file in waar alles staat? Of is er een flexibelere manier van het vinden van de data?
Hier zijn natuurlijk verschillende implementaties voor denkbaar. Veel games gebruiken gewoon een soort filesystem-in-een-file. Alle resources (meestal in een "cooked" vorm zodat de binaire data zonder alteveel processing meteen at runtime gebruikt kan worden) worden gewoon bij filenaam genoemd door bijv. een configbestandje of een script, en opgezocht in de database.
Wijzelf gebruiken een uitgebreid resourcesysteem dat werkt met IDs ipv bestand- of resourcenamen. Alle levels en objecten staan in afzonderlijke files, maar die files zijn op zich weer allemaal databases met alle resources die nodig zijn voor dat level of object (denk aan mesh, textures, materials, animaties, scripts, etc.). Ze worden gebouwd met een buildtool (ik denk vergelijkbaar met
XNA Build) die met een top-down approach alle resources en dependencies daarvan gaat bouwen - als je het commando geeft een level te bouwen, dan introduceert dat level weer dependencies naar bepaalde textures en objecten die in dat level gebruikt worden die daardoor ook gebouwd worden, etc.. Natuurlijk wordt bijgehouden wat al gedaan is, zodat alleen veranderde elementen opnieuw gebouwd hoeven worden. Eveneens wordt er een database bijgehouden die unieke IDs bijhoudt van de resourcenamen, zodat we in-game alleen nog maar IDs hoeven te gebruiken ipv relatief ruimteverspillende strings.
In zo'n database staat niet alleen de binaire data van de resources, maar ook metadata die aangeeft op welke plaats in de binaire data pointers staan naar andere resources. In de runtime zijn er verschillende resource handlers, die bij het inladen van een resource dat aan hun type voldoet ingekickt worden en op die manier een class kunnen instantieren. De metadata wordt vervolgens gebruikt om de pointers in de resources te laten wijzen naar de class instances of simpelweg gewone binaire data van andere resources. Als we dus een stuk mesh inladen voor een object, dan is dat al meteen een instantie van de klasse RenderModel, en die heeft eveneens automatisch referencies naar de gebruikte textures (als instanties van de klasse Texture).
We hebben eveneens een asset manager GUI met editors danwel viewers voor de meeste resources, en waarmee je de dependencies kunt doorzoeken en de buildtool kan aanroepen. Sommige soorten resources zijn real-time-editable, dat wil zeggen dat we de game vanuit de GUI kunnen opstarten (op zowel PC als console), en door de resources aan te passen in een editor kunnen we meteen in real-time de veranderingen in de game zien. Denk aan het plaatsen/verplaatsen/verwijderen van objecten, het aanpassen van eigenschappen zoals de kleur en intensiteit van een licht, etc. Hierdoor kunnen verschillende elementen makkelijk getweakt worden, zonder opsteeds opnieuw de data te moeten bouwen en het game opnieuw te moeten runnen
- Testen. Het nabootsen van een productie-omgeving om losse (basis)componenten te testen lijkt me lastig in een console-wereld. Leveren bedrijven als Sony en Microsoft daar standaard omgevingen voor of zitten de game developers vrolijk minigames te maken de hele dag om hun voortgang te zien/verifieren?
Voor veel componenten van een game hebben unit tests niet zo heel erg veel nut. Je kan bijvoorbeeld moeilijk een test ontwerpen voor de physics engine om te zien of de reactie van een botsing wel loopt zoals die moet lopen. Of de tests worden dermate complex dat je de tests zelf ook moet gaan testen
Als je iets gemaakt hebt om te testen dan ga je eigenlijk gewoon de game spelen. Natuurlijk niet vanaf level 1 oid, want die bestaat wellicht nog niet eens, maar gewoon een simpel level dat snel laadt, evt gemodificeerd zodat je code ook daadwerkelijk aangeroepen wordt en je de boel goed kan controleren. Als dat niet makkelijk kan dan maak je gewoon wat debug-code zodat de specifieke case die je wilt testen ook daadwerkelijk optreedt.
Voor de echt uitvoerige gameplay tests zijn natuurlijk aparte mensen ingehuurd, die in principe gewoon continu de game doorspelen en fouten rapporteren (in het laatste stadium voor de release). Verder hebben de consoles (maar de PC tegenwoordig ook als je het "Games for Windows" logo wilt voeren) een aantal eisen waaraan je game moet voldoen (dat verschilt natuurlijk per console, maar denk aan: je moet corrupte savegames kunnen herkennen, een textuele opmerking op het scherm mag niet korter dan 2 sec weergegeven worden, de naam "Xbox" moet correct gespeld zijn (inclusief casing), etc.), en dit zijn tests die de consolemakers ook zelf testen nadat je je game bij hen hebt gesubmit. Als er tests falen dan moet het opnieuw (uiteraard krijg je een rapport met wat niet klopt). En aangezien elke submission weer geld kost kun je er maar beter voor zorgen dat het in een keer goed is
:strip_exif()/u/25820/raptorsafari.gif?f=community)
:strip_icc():strip_exif()/u/135733/crop600a06b926a1c.jpeg?f=community)
:strip_icc():strip_exif()/u/39264/notpingu.jpg?f=community)
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
/u/3273/crop62bb0d316df4f_cropped.png?f=community)
:strip_icc():strip_exif()/u/46177/FoX-icon.jpg?f=community){kind=icon}
/u/12668/hydra.png?f=community)
:strip_exif()/u/1165/thunk.gif?f=community)
:strip_exif()/u/73955/foxavatar-60.gif?f=community){kind=avatar}
:strip_icc():strip_exif()/u/7418/the_hat_icon.jpg?f=community){kind=icon}
/u/30789/crop6066c9ef8cc2a_cropped.png?f=community)
)