Share
Ik vind dat elke game-ontwikkelaar alle tools moet gebruiken om hun workflow te verbeteren, in plaats van alles handmatig of helemaal opnieuw te doen. Maar wat bedoel ik met gereedschappen? Niveau-editors, debuggers, analyses ...? Al die en nog veel meer! In dit artikel zal ik de verschillende soorten tools die beschikbaar zijn voor game-ontwikkelaars onderverdelen en uitleggen waarom je ze elk zou willen gebruiken.
Wanneer u een spel aan het ontwikkelen bent, zal zeker de tijd komen dat u er inhoud aan gaat toevoegen. Dit kan in het begin een eenvoudige taak zijn: stel gewoon een aantal arrays en objecten in uw code in. Maar naarmate uw ontwikkeling vordert, kan ik u bijna garanderen dat uw inhoudscode er rommelig zal uitzien.
Stel je voor dat je tien levels hebt van een platformgame die is ingedeeld in code, met vijandelijke spawnposities, objecten, items, tegels en al het andere. Terwijl je het aan het spelen bent, merk je dat je de spawn-positie van een vijand moet veranderen. De inhoud van het niveau bevindt zich in dat grote bestand met alle informatie voor alle niveaus. Het klinkt zeker als een hoofdpijn om door alle code te gaan op zoek naar de exacte regel die moet worden gewijzigd. En dat is niet eens nadenken over veranderingen die andere veranderingen kunnen beïnvloeden - zoals de positie van een platform waarop een vijand staat.
Natuurlijk wilt u misschien ook uw niveau visualiseren en het on the fly kunnen veranderen. Dit is niet mogelijk door naar de code te kijken.
Schrijfhulpmiddelen om u te helpen bij het ontwikkelen van uw spel is een meer gecompliceerde maar meer lonende aanpak. U zou een tool kunnen schrijven die al die inhoudscode visueel naar het niveau zelf voor u zou vertalen, en terwijl u deze wijzigt, zou de tool de inhoudscode veranderen. Je kunt ook tools schrijven om meer content voor je game te maken, je te helpen je game te debuggen en zelfs inzetbaar te maken op meerdere platforms. Of je kunt een niveau hoger gaan en de tool vrijgeven aan je spelers en ze inhoud laten maken voor je spel!
Dit kan het succes van je game zelfs vergroten, zoals je misschien ziet als je rondkijkt naar recente games die dat al hebben gedaan.
Laten we eens kijken naar de verschillende hulpmiddelen die u kunt maken, hoe elke instantie u kan helpen bij het toevoegen en beheren van inhoud aan uw spel en de moeilijkheden bij het maken ervan.
Dit is de breedste sectie. Een creatie-tool is alles dat inhoud toevoegt aan je spel - items, personages, niveaus, muziek ... Deze tools zijn degene waar je het meeste tijd mee doorbrengt, omdat het afronden van je spel om hen heen draait: het creëren van de niveaus, items en vijanden; alles samenvoegen; polijsten elk beetje tot in de kleinste details. Elk van deze taken kan een creatie-instrument zijn.
Zelfs als de niveau-editor alleen door u of uw team wordt gebruikt, moet u de interface intuïtief en gebruiksvriendelijk maken.
Laten we aannemen dat je een level-based game hebt. Om een goed hulpmiddel te maken voor het bewerken van uw niveaus, is de eerste taak om ervoor te zorgen dat de tool het niveau visueel voor u vertegenwoordigt. Dat betekent dat het je precies moet laten zien hoe het niveau eruit zal zien voor je spelers. Hierna moet het u toestaan om de inhoud op de een of andere manier te bewerken, zodat u het niveau daadwerkelijk kunt creëren. Dit gebeurt via een interface. Lees dit nu zorgvuldig door, want dit is belangrijk: zelfs als de niveaueditor alleen door u of uw team wordt gebruikt, moet u de interface intuïtief en gebruiksvriendelijk maken. Waarom? Omdat niemand het leuk vindt om met iets te werken waarvoor je een combinatie van knoppen moet indrukken of op een aantal knoppen moet klikken om zoiets eenvoudigs als een object op het scherm toe te voegen. En dat geldt ook voor u en uw team.
Zelfs als u degene bent die het heeft gemaakt en alles weet over de editor, helpt het maken van een gebruiksvriendelijke interface iedereen inhoud aan het spel toevoegen. En als iemand toevallig de snelkoppeling vergeet van het markeren van een object als 'collidable', bijvoorbeeld, dan is het hebben van een intuïtieve interface een enorme hulp..
Hier is een concreet voorbeeld - een eenvoudige niveau-editor die ik heb gemaakt voor een kettingreactiespel van Windows Phone 7:
Zoals je misschien hebt gemerkt, bestaat de volledige leveleditor in de Adobe Flash Professional-software - ik heb geen afzonderlijke app gemaakt. Flash Pro was een perfecte omgeving: het kostte me geen moeite om iets te maken om grafische afbeeldingen op het scherm voor mij te bewerken, omdat ik naar een eenvoudige tool keek om me te helpen de levels voor het spel te maken. Het enige dat ik moest doen was een heel eenvoudige extensie maken (zoals je op de video kunt zien) om al die niveau-informatie ergens voor mij op te slaan (ik gebruikte een XML-bestand).
Al het andere werd voor mij behandeld door Flash Pro: ik kon de schermgrootte precies instellen op de schermgrootte van mijn spel, ik kon alle objecten op ware grootte op het scherm plaatsen en hulplijnen invoegen om me te helpen visualiseren waar de foto's zouden gaan na een object was geëxplodeerd. Het testproces was net zo eenvoudig als het "compileren" van het project in Flash, wat een venster zou openen met vragen waar het XML-bestand moest worden opgeslagen; toen ik mijn spel opnieuw compileerde, zou het de bijgewerkte XML lezen.
Stel je nu eens voor dat je een shoot-'em-up-game hebt. Heb je ooit eerder geprobeerd er een te maken? Het is vervelend (en gecompliceerd) om al die bewegingen van vijanden en schietpatronen via de code zelf in te stellen en het instellen van de timing is ook vervelend.
Hier is een shoot-'em-up level-editor die ik heb gemaakt als een ander experiment:
Dit is een voorbeeld van wat niet Te doen. Hoewel mijn editor over de basisfunctionaliteit beschikte om je vijandelijke bewegingspatronen te laten instellen zoals je zelf leuk vond en zelfs een aantal helperfuncties hebt opgenomen (in dat geval spiegelde ik de vijand die ik aan het bewerken was om een "spiegeleffect" te maken toen de vijanden in het spel verschenen), de interface was een complete mislukking.
Ik had niet de mogelijkheid om het hele niveau tegelijkertijd te visualiseren: het enige dat ik kon doen was golf voor golf visualiseren. Heb je je ooit voorgesteld hoe pijnlijk het zou zijn om iets op het niveau op die manier te veranderen? Als ik bijvoorbeeld de spawn-tijd tussen de vijanden van de huidige golf met 400 milliseconden zou willen uitstellen, zou ik alle volgende waves moeten doorlopen en toevoegen (400 ms * aantal vijanden veranderd) voor alle initiële spawn-tijden van de andere waves. Om deze basisreden, moest ik de tool opnieuw maken.
Creatiehulpmiddelen maken is een zeer moeilijke taak. Misschien zijn dit de moeilijkste van alle andere tools om te creëren, omdat je er dagelijks mee te maken krijgt om je spel te maken. Je moet ze zo snel en gemakkelijk mogelijk gebruiken en ze mogen de inhoud van je game niet echt in de weg zitten. Als u erachter komt dat u minuten of zelfs uren moet besteden aan het wijzigen van dingen in uw editor omdat u iets anders hebt gewijzigd dat moet worden gerepareerd, dan zou u misschien opnieuw willen nadenken over de vraag of de tool zijn doel dient.
Een uitstekende benadering is om in-game editors te maken. Met deze hulpmiddelen kunt u inhoud wijzigen terwijl de game wordt uitgevoerd en om te testen wat u tijdens runtime hebt gewijzigd.
Dergelijke tools duwen uw productiviteit tot het uiterste, omdat u onmiddellijk feedback krijgt over de wijzigingen die u hebt doorgevoerd. Met sommige editors kunt u zelfs de waarde van attributen wijzigen terwijl uw game wordt uitgevoerd, zodat u opdrachten in realtime kunt uitvoeren en de resultaten kunt bekijken. Je kunt ook "de tijd buigen" en de acties opnemen die je in de game hebt gedaan, dan attributen in je spel wijzigen (bijvoorbeeld de zwaartekracht) en zien hoe de beweging van de speler die dezelfde acties uitvoert eruit zou zien in die nieuwe omgeving.
Bekijk dit voorbeeld van een in-game kaarteditor voor een game in ontwikkeling, Concerned Joe:
Dit zijn waarschijnlijk de beste vrienden van een programmeur. Als er iets misgaat met een game, helpen hulpprogramma's voor foutopsporing u erachter te komen wat het was. Ze kunnen ook statistieken over uw spel weergeven, de procestijd van elke functie bekijken die in uw code wordt aangeroepen, geheugendumps aanbieden wanneer iets niet lukt, logboeken maken zolang de toepassing actief is en meer.
Bij het programmeren van een spel, zal een programmeur vaak veel van deze hulpmiddelen gebruiken - met name de eigen debugger van de ontwikkelomgeving, als die er is. Er kunnen echter veel andere hulpmiddelen worden geschreven om het spelontwikkelingsproces in dit gebied te ondersteunen.
Voor een zeer complexe game, wil je vaak de functieaanroepstapel kunnen herstellen wanneer iets vastloopt (zodat je precies weet welke coderegels de crash veroorzaakten) en genereer je logs zo vaak als je kunt. Natuurlijk moet u deze logboeken kunnen interpreteren. Misschien kan een hulpmiddel om u te helpen bij het analyseren van logboeken van pas komen ...
Bekijk bijvoorbeeld deze tool die is gemaakt door Adobe, genaamd SWF Investigator:
Deze tool, gemaakt om SWF-bestanden te analyseren, stelt de ontwikkelaar in staat om verschillende dingen van zijn spel te onderzoeken, inclusief code-analyse (het is in staat om de SWF te demonteren om te onderzoeken wat de toepassing precies doet), wat erg belangrijk is voor een game-ontwikkelaar - met name bij het optimaliseren van code.
Het is echter erg moeilijk om een foutopsporingsprogramma te schrijven. Niet omdat het een "perfecte" interface moet hebben, zoals creatiehulpmiddelen; vaak worden deze tools alleen gebruikt door programmeurs en het kernontwikkelingsteam, en de interface doet er niet toe dat veel. (Natuurlijk moet het nog steeds alles van belang voor je kunnen laten zien en je in staat stellen om er gemakkelijk mee te manipuleren.) Nee, het is moeilijk vanwege de enorme hoeveelheid technische details die er in moeten gaan.
Deze tools kunnen u echter helpen uw spel beter te laten renderen op de platforms van uw spelers, wat natuurlijk erg belangrijk is.
Implementatietools zijn nodig wanneer je een team hebt dat werkt aan verschillende aspecten van het spel (misschien een artiest en een programmeur) en wanneer je aan het ontwikkelen bent voor meerdere platforms. Bij de ontwikkeling voor meerdere platforms moet u rekening houden met de schermgrootte van elk apparaat (met name voor mobiele games) en de technische beperkingen van elk platform.
Stelt u zich eens voor dat u een game voor een smartphone met een resolutie van 1280x768 en een tablet met een resolutie van 1920x1200 moet ontwikkelen. U zult waarschijnlijk voor elk apparaat twee verschillende sets afbeeldingen willen gebruiken, omdat u geen afbeeldingen voor de smartphone wilt gebruiken en ze wilt opschalen voor de tablet - dat zou er lelijk uitzien. Bovendien heeft uw smartphone waarschijnlijk niet genoeg geheugen en verwerkingskracht om de grote afbeeldingen te verwerken die u voor uw tablet gebruikt. Daarom is een implementatietool nodig om u te helpen bij het beheren van de assets voor uw game.
Over het beheren van bedrijfsmiddelen gesproken, stel nu dat u in een team werkt, dat bestaat uit een artiest en een programmeur. De artiest zal zeker veel kunstitems maken, maar hoe gaat de programmeur omgaan met het verwijzen naar deze art-bestanden in het spel? De meest luie benadering zou zijn om gewoon de naam van het bestand te wijzigen of toe te voegen op elke plaats waar de code het gebruikt wanneer de artiest wijzigingen aanbrengt of kunstbestanden toevoegt. Voor grote projecten is dit echter niet mogelijk, omdat dit een goede ontwikkelingstijd zou wegnemen.
Een goede manier om hiermee om te gaan, is om een tool te maken voor het beheren van kunstitems voor het team: de artiest geeft eenvoudig op welk kunstbestand verwijst naar wat, en de tool converteert de bestandsnamen automatisch naar een vooraf gedefinieerde naam die is ingesteld door de tool zelf . Op die manier hoeft de programmeur zich geen zorgen te maken over het wijzigen van namen in de code wanneer de artiest iets verandert.
Deze tools zijn gemakkelijk over het hoofd te zien, maar je moet ze zeker gebruiken in je games. Hulpprogramma's voor na het vrijgeven helpen je bijhouden hoe je spel het doet in de markt en hoe spelers het ontvangen.
Dit is erg belangrijk voor virale web- en mobiele games, maar ook desktop-games kunnen veel baat hebben bij deze tools. Ze laten je zien waar de game beschikbaar is en hoeveel spelers je game hebben gespeeld. Ze kunnen nog verder gaan: tools zoals Playtomic, Mochi Analytics en GamesAnalytics kunnen bijhouden hoe vaak een bepaald niveau is gespeeld, hoe vaak op een knop is geklikt, hoeveel spelers je game hebben laten vallen (in de eerste minuut, eerste vijf minuten, seconden niveau, enzovoort) en meer. Je zou dan deze informatie kunnen gebruiken om te concluderen dat een bepaald niveau te moeilijk is (op basis van het aantal spelers dat het niet voltooit) en het vervolgens te repareren.
Er is meer: u kunt ook hulpmiddelen schrijven om de openbare ontvangst van uw spel op internet te volgen, met behulp van bots die informatie van Facebook-berichten of tweets verzamelen die de naam van uw spel bevatten, u laten zien op welke beoordelingssites uw spel is beoordeeld, enzovoort. Laten we ook Google Meldingen niet vergeten, een geweldige tool die u op de hoogte stelt wanneer een opgegeven term op het web verschijnt.
Hoewel dat echt nodig is gebruik hulpmiddelen om je spelontwikkelingsproces te ondersteunen, soms zul je merken dat dat niet nodig is creëren ze, omdat de game-ontwikkelingsgemeenschap al veel tools heeft gemaakt.
Er zijn veel uitstekende game-dev-tools online beschikbaar die u kunt gebruiken - het kost slechts een korte tijd om ze te vinden. Maar gebruik ze met de nodige voorzichtigheid: als u denkt dat een tool niet precies doet wat u nodig heeft, is het wellicht beter om uw eigen tool te schrijven dan tijd te verspillen aan het draaien van uw game. Dit is vaak het geval voor game- of genre-specifieke tools.
Het maken van een tool is een enorm onderwerp dat verschillende artikelen verdient, maar ik geef je hier een tip: je moet vaak de manier standaardiseren waarop je de inhoud van je game verwerkt. Dit betekent dat je een manier moet verzinnen om de informatie van je spel op te slaan, te kunnen laden en opslaan. De meeste mensen gebruiken XML of JSON voor het beschrijven van informatie, maar je wilt misschien je eigen binaire indeling maken als je een specifiekere manier nodig hebt om dingen te beschrijven.
Dat is het einde van mijn analyse van de verschillende hulpmiddelen die u kunt gebruiken om u te helpen bij het ontwikkelen van uw spel. Ik hoop dat je het artikel leuk vond en ervan hebt geleerd! Als u vragen heeft, aarzel dan niet om te vragen.
Opmerking van de uitgever: We gaan een lijst samenstellen van geweldige tools zoals Ogmo Editor, Tiled en SFXR. Laat het ons weten als u suggesties heeft!
Accentsconagua