IT10: Koppelen met het spel 33

Naast het opslaan en inladen van een gemaakt level is het natuurlijk van belang dat de levels ook daadwerkelijk speelbaar zijn in het spel. Hiervoor moet een vertaalslag gemaakt worden van objecten uit de editor naar objecten uit het spel. Deze vertaalslag is nodig doordat de editor veel objecten gebruikt die onder andere gebruik maken van een aantal Java klassen. De objecten in het spel zelf doen dat niet. Echter maken deze gebruik van veel klassen afkomstig uit de Physics Engine. Het is zinloos om deze hele engine te importeren in de Editor, dat zou namelijk veel overhead cre¨eren.

(a) Het model van het externe formaat. (b) Het klassediagram van het externe formaat.

Figuur 20: Het model en klassediagram van het externe formaat.

22.1. Model/ontwerp

Voor het maken van een vertaalslag heb ik een formaat bedacht dat zowel in het spel als in de editor gebruikt wordt. Dit formaat bevat een aantal onderdelen die in beide (spel en editor) belangrijk zijn. Het model hiervoor is te zien in figuur 20a. Het klassediagram is te zien in figuur 20b.

De hoofdklasse, ExternalFormat bevat een aantal sub-klassen waarin de benodigde informatie opgesla-gen staat:

• ShapeFormat: Hierin staat opgeslagen wat voor soort vorm het is en wat de positie van de punten van deze vorm is. Een object kan in de toekomst uit meerdere vormen bestaan, dus is het een array van vormen.

• FillFormat: Hierin staat simpelweg hoe het object weergegeven wordt. Dit is tot nog toe de kleur van het object.

• GraphicsFormat: Hierin staat informatie die relevant is voor de Graphics Engine. Tot nu toe staat hierin alleen de texture opgeslagen.

• Collections: Een String array waarin staat tot welke collecties een object behoort, zoals beschreven was in sectie 16.1.

• PhyPropFormat: De informatie dat voor de Physics Engine relevant is, wordt in deze klasse opgeslagen. Dit is de informatie zoals beschreven in sectie 16.1.

• CameraPath: Tot slot is er nog een camera pad opgeslagen, als een lijst van Edges. Dit is het pad waar de camera overheen loopt. Dit wordt tezamen met een ’basislevel’ gegenereerd. Tot slot bestaat er een FormatConverter klasse. Deze klasse zorgt voor het opslaan en ophalen van informatie in het externe formaat.

22.2. Implementatie

De implementatie van de FormatConverter klasse verschilt aan de Editor- en Spel-kant. De implemen-tatie aan de Editor-zijde is geheel gericht aan het opslaan van informatie. Het gaat de objecten in de modellen af om de informatie om te zetten naar het externe formaat. Dit externe formaat wordt vervolgens in een lijst bewaard. Deze lijst wordt tot slot naar een bestand geschreven, dat later door het spel ingelezen kan worden.

De implementatie aan het spel-zijde is echter geheel gericht aan het ophalen van deze informatie. De lijst met externe formaten wordt uit een bestand gelezen. Vervolgens wordt elk formaat uit de lijst langsgegaan om daaruit de benodigde informatie te halen. Er wordt eerst gekeken wat voor soort vorm het is en wat de bijbehorende fysische eigenschappen zijn en tot wat voor collectie het object behoort. Dit wordt opgeslagen in een object van de Physics Engine. Daarna wordt de grafische informatie verkregen en opgeslagen in een object van de Graphics Engine. De twee reeds gemaakte objecten worden tot slot gebruikt om een GameObject te maken dat toegevoegd wordt aan de Game Engine. Het object uit de Level Editor is nu succesvol geimporteerd in het spel.

22.2.1. Problemen

Het koppelen van de Editor en het spel was niet zo makkelijk. Allereerst moest er een vertaalslag gemaakt worden tussen de beide soorten objecten. Dit koste wat tijd, maar was uiteindelijk te realiseren door te vergelijken welke relevante informatie aan beide kanten beschikbaar was en waar deze informatie vandaan gehaald of opgeslagen kon worden. De Editor was immers ontwikkeld om de gebruiker in staat te stellen deze informatie zelf op te slaan.

Naast het bedenken en ontwerpen van die vertaalslag moest de lijst met externe formaten nog van de Editor naar het spel komen. Hiervoor was in eerste instantie een eigen methode bedacht, die de objecten ´e´en voor ´e´en naar een tekstbestand schreef. Eerst werden alle sub-klassen van het level editor object naar het bestand geschreven, daarna het object zelf. Hierdoor kon, door een zelfgeschreven parser, eerst de sub-klassen van het object ingelezen worden en vervolgens het object zelf gemaakt worden aan de hand van deze sub-klassen. Dit was erg ineffici¨ent en tijdrovend. Ik besloot om het te proberen met Java Serializable.

Het gebruik van Serializable verliep niet geheel zoals verwacht. Aan de Editor kant werden ob-jecten wel naar het bestand geschreven, maar aan het spel kant ging het inlezen niet goed. Met Serializable moeten de formaten identiek zijn aan elkaar, dus ook de packagenamen van het formaat en de sub-klassen. Een voorbeeld: De Editor gebruikt een klasse Vec2 voor het gebruik van punten met een x- en y-co¨ordinaat, die de punten van de vorm van het object representeren. De packagenaam van deze klasse aan de Editor zijde is com.bernoulligames.leveleditor.util. Aan de zijde van het spel wordt deze klasse ook gebruikt voor dezelfde punten. Echter is de packagenaam hier: mage.util.math. Doordat deze packagenamen verschillen, ziet Serializable ze als compleet verschillende objecten. Dit leverde foutmeldingen op. Naast de packagenaam moet ook de inhoud exact hetzelfde zijn. Na het oplossen van deze problemen werkte het echter nog niet, om onbekende reden.

Ik besloot om het opslaan en inlezen met behulp van XStream te doen, aangezien dit gemakkelijk werkte bij het opslaan en inladen van levels in de Editor (zie sectie 21). Hiervoor moest echter de library van XStream ge¨ımporteerd worden in het spel. Aan de Editor kant was dit al gebeurd, dus dat was geen probleem. Doordat het spel in Android geschreven is, werkt het importeren van externe libraries anders dan in normale Java projecten. Na wat zoeken vond ik uitleg hoe het importeren in Android

moest. Echter, na het importeren kreeg ik toch steeds een foutmelding dat XStream niet gevonden kon worden. Deze foutmelding kreeg ik maar niet opgelost. Uiteindelijk ben ik weer teruggegaan naar Java Serializable.

Na het opnieuw implementeren van Serializable ging het ineens goed, zonder een foutmelding. Waar-schijnlijk had ik tijdens de vorige implementatie een foutje gemaakt, dat ik dit keer niet maakte. Mogelijk werkt dan ook het opslaan en inladen van levels. Echter bestaat de koppeling van de Editor en het spel alleen nog uit objecten uit de Level Editor. De Event Editor is nog niet gekoppeld, dus alle referenties in dat onderdeel hoeven (nog) niet te bestaan in het spel. Hierdoor is het simpeler om de koppeling te maken. Om deze reden kan het zo zijn dat het opslaan/inladen van levels nog steeds niet met Serializable werkt.

De koppeling tussen de Editor en het spel zou verder uitgebreid worden, zodat de gemaakte Events in de Event Editor ook ge¨ımporteerd werden in het spel, maar doordat de ontwikkeling van het spel is stilgezet is dit niet mogelijk (hierover is meer te lezen in sectie 23).

22.3. Voorbeeld

Om te laten zien dat de koppeling tussen de Editor en het spel bestaat, laat ik screenshots zien van een level dat gemaakt is in de Editor en ge¨ımporteerd is in het spel. De screenshot van de Editor is te zien in figuur 21a. Hier is te zien dat het android-logo gemaakt is. Dit object is als een convexe vorm gecre¨eerd, maar doordat dit object uiteindelijk niet convex was is het opgedeeld in driehoeken. Hetzelfde geldt voor het woord ’YAY’. Een screenshot van het level in het spel is te zien in figuur 21b. Hierin is het android-logo alsmede het woord ’YAY’ weer te zien, maar nu is het ´e´en geheel. Het gele object dat in deze screenshot te zien is, is een representatie van de speler. Dit wordt uiteindelijk veranderd in een echt speler-object, inclusief grafische elementen.

(a) Een screenshot van een level in de Editor. (b) Een screenshot van een level in het spel.