Tips voor een One Man Gamedev-team wat te doen voordat u zelfs een computer aanraakt

Dus je hebt besloten dat je een videogame wilt maken als hobbyist. Je hebt een ontwikkelingsplatform gekozen, een aantal tutorials gelezen en je hebt een cool game-idee in gedachten. U bent klaar, tijd om te beginnen, laten we de computer raken, toch? Fout.


Kun je dit spel maken?

Ontwikkelingsstudio's voor videogames zijn bedrijven; geld bepaalt wat ze wel en niet kunnen doen. Maar u bent geen bedrijf en de dingen zijn niet zo eenvoudig voor u.

Een aanname die veel eenzame hobbyist-ontwikkelaars doen, is dat hun ontwikkeling op dezelfde manier werkt als die van een studio. Dat ze zichzelf geen salaris hoeven te betalen, en dat ze niet afhankelijk zijn van hun spel voor geld, dus ze kunnen zo lang duren als ze het willen afmaken; ze kunnen alles doen waar ze naar op zoek zijn.

Helaas is dit niet hoe het echt werkt. Als een eenmansploeg word je beperkt door je huidige vaardigheden en de vaardigheden die je tijdens de ontwikkeling kunt verwerven. Dit lijkt misschien voor de hand liggend, maar het is iets dat ambitieuze nieuwe ontwikkelaars vaak vergeten. Veel nieuwe hobbyisten, inclusief ikzelf, kregen de eerste keer dat ze een spel begonnen, tranen in hun ogen, denkend aan de geweldige ervaring die ze zouden creëren en volledig uit het oog verloren wat ze realistisch konden bereiken..

Een videogame maken is ingewikkeld werk, vooral alleen. Van ontwerp tot programmeren tot kunst, niet iedereen kan alles doen, en het is niet altijd gemakkelijk om te leren. Misschien ben je bereid om te leren hoe je je eigen rigid-body physics-engine kunt maken, maar om het voor elkaar te krijgen zonder je interesse in je project te verliezen, kan het moeilijk zijn - en wie weet is de wiskunde achter de natuurkunde het gewoon niet eens met je brein..


Zo veel als je wilt, is dit vervolg een spel dat je niet kunt maken.

Daag jezelf niet uit met je concept, vooral als dit je eerste spel is. Of het er nu naar uitziet of niet, er zullen altijd obstakels zijn die je niet had verwacht, zelfs in de meest eenvoudige ontwerpen, en je zult worden uitgedaagd en iets leren tijdens de ontwikkeling. Zelfs als u dat niet zoekt, gebeurt het vanzelf.

Een ander ding om in gedachten te houden: bereik. Het duurt altijd langer voordat games gemaakt zijn dan u denkt, dus pas uw ontwerpen dienovereenkomstig aan. Zoals de negentig-negentig regel zegt:

De eerste 90 procent van de code is goed voor de eerste 90 procent van de ontwikkelingstijd. De resterende 10 procent van de code is goed voor de overige 90 procent van de ontwikkelingstijd. Tom Cargill van Bell Labs

Deze regel is humoristisch, maar beschrijft de typische ontwikkelingscyclus van een spel. Je krijgt alles schijnbaar perfect op rolletjes en denkt dat je bijna klaar bent ... en realiseert je opeens dat je nog steeds een hoop werk hebt om je spel te polijsten. Dingen zoals UI, geluid en last-minute glitches vergen veel meer van je tijd dan je zou denken.

Hoe groter je spel, hoe meer van deze kleine dingen er zullen zijn om te repareren - dus houd altijd het bereik in het achterhoofd.


Cool idee, maar hoe zit het met jouw Spel?

Heb je een concept waarvan je zeker weet dat je het kunt uitvoeren? Geweldig - maar start nog niet. Je kunt niet coderen a concept; geen programmeertaal of game-ontwikkelingstool stelt ontwikkelaars in staat spellen te maken in vage, brede streken. Je moet de details kennen van wat je aan het maken bent.

Stel dat je een 2D-puzzelplatform maakt dat onder water plaatsvindt met een coole gewichtshouder. Dat klinkt geweldig, maar je kunt geen "cool weight mechanic" coderen, je moet opsplitsen hoe het werkt op een heel specifiek niveau.

  • Hoe wordt de speler zwaarder of lichter?
  • Hoe verandert dit de interacties tussen hem en de vijanden?
  • Wat zijn de vijanden?
  • Wat zijn hun bewegingspatronen?
  • Kunnen ze communiceren met het landschap?
  • Wat voor soort objecten zijn er in de niveaus?
  • Hoe ze omgaan met de speler en de vijanden?

U moet al deze aspecten overwegen voordat u begint met het maken van de inhoud. Natuurlijk zullen veel dingen veranderen in de loop van de ontwikkeling - je zult nieuwe ideeën bedenken en oude laten vervallen - maar het is van cruciaal belang om een ​​goed idee te hebben van wat je doet voordat je de computer raakt.

Ik ben niet de enige in deze mentaliteit. De hele kaart voor Shadow Complex is gemaakt op millimeterpapier voordat iemand zelfs maar een computer heeft aangeraakt. Nu is dit absoluut een ongewone ontwikkelingsstijl, en ik zeg niet dat iedereen het zou moeten repliceren, maar het team bij Chair Entertainment begreep absoluut de waarde van het begrijpen van je spel voordat het wordt gebouwd.


Een deel van de papieren kaart voor Shadow Complex.

Ik ben onvermurwbaar over dit punt omdat het een worsteling is die ik onlangs tegenkwam en ik zou mezelf graag willen gebruiken als een voorbeeld van wat niet te doen.

Ik was opgewonden om tijdens de zomervakantie een spel te ontwikkelen, toen ik gegarandeerd veel vrije tijd had. Ik bedacht een concept waarvan ik dacht dat het best cool was, kreeg goede feedback over een technische demo die ik had gebouwd en begon met coderen. Het probleem was, alles wat ik had was een concept. Ik had een primaire speler die ik dacht dat interessant was: je kon elke tegel in het level fotograferen om hem te laten stijgen of dalen, zodat je rond kon bewegen en vijanden kon neerknallen. Afgezien van dat alles wat ik had was een genre en algemene vibe van hoe ik wilde dat mijn spel voelde.

Dit was rampzalig en stom. Ik wilde zo graag gaan dat ik geen idee had wat ik probeerde te maken. Uiteindelijk heb ik lukraak functies gecodeerd, in de hoop dat mijn spel zou kristalliseren in iets cools. Wat ik kreeg was een erg rommelige codebase, een kunst die eruitzag als dat mijn spel plaatsvond in een jungle (en misschien deed het dat; ik tekende kunst voordat ik een stel-ga-figuur had) en geen enkele inspiratie.

Na dat alles verloor ik de interesse in het project volledig omdat het zo moeilijk was om te maken. Het ontwerp was niet bijzonder gecompliceerd en het was niets dat ik niet eerder had gedaan, maar ik vond de ontwikkeling nog steeds nauwgezet, zwaar en helemaal niet prikkelend..

Gebruik mij als voorbeeld - je kunt meer lezen over mijn verlaten project op mijn blog. Weet wat je wilt maken voordat je het gaat maken.


Maar is niet datgene waarvoor prototypering is?

Bijna elke gamedev post mortem bespreekt prototypes. "Gewoon prototypen en spelen, afspoelen en herhalen tot je iets hebt dat je leuk vindt."

Ik heb nog nooit een spel gemaakt als onderdeel van een groot team, maar ik heb ervaring met het werken in kleine teams en alleen, en ik kan je vertellen: prototyping is niet zo snel en gemakkelijk als je misschien denkt. Als je maar één persoon bent die aan een game werkt, kan het even duren om een ​​klein deel ervan te laten werken, en dit als methode gebruiken om primaire spelconcepten te achterhalen, is een nogal vervelende ervaring.

Maar prototyping en playtesting hebben hun plaats in de ontwikkelingscyclus van een eenmansploeg - je moet het gewoon op een andere manier aanpakken.


Prototypen zijn veel besproken tijdens interviews met de ontwikkelaars van deze game.

Wanneer je uitzoekt of een game-idee zo groot is als je denkt dat het is, is niets effectiever dan het daadwerkelijk gaan zitten en spelen. Dit verandert niet wanneer je alleen werkt, maar omdat prototyping zo lang kan duren, moet het een beetje worden aangepast. Ga niet blindelings in prototyping, denk er aan als een tijd waarin je één ding test en een heleboel coole nieuwe ideeën bedenkt. Denk liever aan prototyping als een ruimte waar u de ideeën die u al hebt kunt verfijnen, en de details van uw bestaande plan kunt uitwerken..

Je kunt geraakt worden door een golf van inspiratie zodra je begint met het draaien van dingen, maar reken er niet op. Wanneer je met prototyping begint, is het effectief om een ​​verticaal deel van je spel te maken, een kort, samengebracht, bespeelbaar gedeelte dat zo goed mogelijk weergeeft wat je wilt dat een deel van het uiteindelijke product is. U hoeft deze code later niet opnieuw te gebruiken, dus u kunt hem zo snel mogelijk laten draaien om een ​​goed beeld te krijgen van wat u echt aan het maken bent. Je zou hier zelfs een andere engine voor kunnen gebruiken dan je van plan bent te gebruiken voor het eigenlijke spel.

Dit helpt je een doel te bereiken en een goed idee van hoe je ontwerp gaat werken. Deze ervaring voegt context toe aan de rest van uw ontwikkeling en maakt het mogelijk om zeer efficiënt werk uit te voeren. Altijd het laatste product in je achterhoofd houden, helpt je echt om de hoeveelheid kunst en code die je later verwijdert te minimaliseren.

Uiteraard hangt dit allemaal af van uw ontwikkelplatform. Als je je spel aan het maken bent met een heleboel basiswerk voor je gedaan, zoals GameMaker of zelfs de LittleBigPlanet-leveleditor, dan kan prototyping snel zijn, ook al ben je maar één persoon. Bouw in dat geval zoveel prototypen als u maar wilt!


Kan ik nu beginnen?

Als je een ontwerp hebt dat haalbaar is, heb je de details over hoe dingen gaan werken, en je weet precies hoe je prototyping gaat aanpakken, dan ben je er helemaal klaar voor!

Bedankt voor het lezen. Ga je gang en maak dat spel - ik kijk er naar uit om het te zien.