Share
Je kunt dit jaar een tiental spellen maken. Geluid onmogelijk? Het is niet. Probeer deze eenvoudige methode voor het ontwikkelen van games van iemand die het heeft gedaan en zie voor jezelf dat 12-in-12 een redelijk doel is.
Ik ga mijn persoonlijke spelontwikkelingsmethodologie met je delen. Ik beweer niet het enige systeem ter wereld te hebben bedacht om de eindstreep te halen - verre van dat. Dit is slechts een spreukenboek, een gereedschapskist gevuld met mijn eigen persoonlijke tips en technieken die ik gebruik om de demonen te bevechten die proberen te voorkomen dat ik een spel start. Deze demonen omvatten feature creep, alles-of-niets ontwerp en onbegrensd optimisme. Dit zijn trucs die ik heb ontwikkeld in de loop van het slagen waar ik in het verleden gefaald had.
Weet je, in 2012 bereikte ik het verheven doel om 12 games te maken in 12 maanden. Verrassend genoeg was het niet zo moeilijk: het kostte niet meer werk dan mijn vele mislukte projecten in voorgaande jaren.
Dus wat was het verschil? Een meer volwassen, meer gekruide, minder grote ogen en minder optimistische benadering. Begrijp me niet verkeerd: er is niets mis met optimisme. Sterker nog, ik moedig het aan! Zonder dat zou geen van ons gamedevs zijn. Zonder enig optimisme kom je nooit ergens. Ik moest gewoon mijn projecten benaderen met een iets bescheidener mindset.
Ik wil graag een paar van mijn tricks en tips met je delen. Ik vraag dat je ze allemaal in overweging neemt, maar voel je vrij om ze te accepteren of af te wijzen als je wilt. Geen enkele techniek kan voor iedereen werken, maar als je een enkele techniek of mindset weghaalt die je helpt om het doel van één game per maand van 12 games in één jaar te behalen, dan zal ik blij zijn.
Probeer deze tips te gebruiken in uw volgende gameproject. Misschien helpen ze je ook. Misschien kom je met je eigen best practices die anders of beter zijn. Dat is geweldig! Zoals met de meeste adviezen, is de sleutel om het bericht te overwegen, elk punt te accepteren of te verwerpen, zoals u persoonlijk goeddunkt, en het goed te keuren (of aan te passen) die praktijken die u aanspreken.
90% van de game-projecten zien nooit het licht van de dag. Mijn eigen persoonlijke ervaring bevestigt dit. Ik maak al meer dan twintig jaar games en van alle games die ik begon - gevuld met enthousiasme, een gedetailleerd plan en oneindige ideeën voor brainstorm - werd slechts een klein percentage ooit uitgebracht. Dit veroorzaakte jaren van hartzeer. Ik was een goede codeur, ik kon acceptabele illustraties produceren, ik had genoeg goede ideeën om vertrouwen te hebben in mijn plannen, en toch was die prachtige staat waarin de game voor het publiek klaarstond een ongrijpbaar doelwit..
Waarom? Omdat het implementeren van al deze spannende plannen altijd gepaard ging met uitdagingen die ik niet had voorspeld. Bovendien nam het enthousiasme dat ik voor elk project had, doorgaans af naarmate de finish naderde. Het gaan zou moeilijk worden, het geld zou opraken, de vervaldatum zou voorbij gaan en het plezier zou eindigen. Het enige wat er nog zou overblijven, was dat de laatste strekking die veel ontwikkelaars noemen, wordt gesjouwd de muur.
De muur is het punt in een softwareontwikkelingsproject waar het niet langer leuk is. Alle gemakkelijk te implementeren dingen zijn gecodeerd en wat overblijft is het drukke werk: het verhelpen van fouten, lastige stukjes code, repetitieve taken, onderdelen die afhankelijk zijn van dingen buiten je controle, die een ontbrekend niveau of geluidseffect, installatieproblemen, gebruiker testen, die gerapporteerde bug die je niet kunt reproduceren, en app store-inzendingen.
Het afwerken van een spel kan worden gezien als analoog aan het beklimmen van een berg. Met een beetje geluk kun je dat doen met niets anders dan sneakers en ambitie - maar dit resulteert meestal in catastrofale mislukkingen. In plaats van mijn bergen te bevrijden zonder een gedachte of een plan, begon ik touwen en ruimen te brengen, bestudeerde de rotsmuur van tevoren, nam nota van secties die lastig zouden zijn, en ging zelf op pad.
Stel je voor dat je een hele game moet afmaken zonder een enkele game te redden. Dit is het aantal game-ontwikkelaars dat software maakt: alles-of-niets, geen vangnet, je raakt het uit het park of crasht en verbrandt. Geen middenweg. Geen rekening houden met ongeplande onvoorziene gebeurtenissen. Dit is een zekere manier om onbedoeld naar mislukken te streven.
Nadat je dit een paar keer hebt gedaan, zul je het patroon beginnen te zien: optimistische plannen zonder spaarpunten langs de weg zijn buitengewoon riskant. Waarom niet het risico verlagen en onderweg meerdere exitpunten geven?
Laten we erin duiken. Ik ga een game gebruiken die ik in een weekend heb geschreven als voorbeeld om veel van deze punten te illustreren. Dit voorbeeld uit de echte wereld zou moeten helpen om dit werk te bewijzen.
Brainstormen is de beste. Ik ben dol op het noteren van uitgebreide lijsten met itemtypen, schatten, speurtochten, personagenamen, niveau-ideeën of bouwstenen. Het is leuk en het is een geweldige manier om aan een game te werken. Maar er is een verborgen valstrik: brainstormen zijn, van nature, ongeveer aantal stuks, geen kwaliteit. Ik hou ervan om dat te graperen een afkorting voor brainstorm is B.S..
Als je elk project met een enorme brainstorm begint, geweldig. Maar begin pas aan je spel te werken als je 99% van wat het op je oorspronkelijke lijst heeft gegooid hebt gegooid naar de "save it for version two point oh" wishlist.
Een geweldige manier om de gigantische, griezelige, overdreven optimistische toma te doorbreken die de brainstorm van een typische gamedev is, is om elk opsommingsteken te beoordelen op een paar schalen, zoals:
Sorteer uw lijst en verwerp de overgrote meerderheid van uw ideeën. Bewaar de meeste van hen (vooral de moeilijkste) voor later.
Vraag voor elk item in je topkeuze een laatste vraag: is dit een moet hebben of a goed om te hebben? Voor het eerste prototype richt u zich uitsluitend op de essentiële, niet-mogelijk-werk-zonder-functies.
Ten tweede, denk: hoe moeilijk zal elk item zijn om te implementeren? Vereist het veel code of inhoud? Schaam je er helemaal niet voor om lui te plannen: je moet gedisciplineerd genoeg zijn om veel van je grootste ideeën op een laag pitje te zetten, simpelweg omdat de implementatie ervan een groot aantal uren werk kost. Wees lui: kies de meest essentiële functies die dat zijn gemakkelijk maken.
Waarnaar wordt gestreefd wanneer je je gigantische brainstorm aanvalt, is het alleen aan de absolute essentie te onderwerpen. Verdeel uw idee naar de single kerngame monteur die je het leukst vindt die makkelijk te implementeren is. Doe één ding goed, niet een dozijn dingen die half gebakken zijn.
Dit wordt je MVP: jouw minimaal levensvatbaar product.
Zodra je de MVP voor jezelf hebt beschreven - wat betekent dat je het hele basisconcept van de game in één alinea kunt beschrijven, met maximaal één of twee functies - is het tijd om het te verfijnen.
Stel je voor dat je een uitvoerend directeur van een grote uitgever moet overtuigen van de levensvatbaarheid van je spel tijdens een toevallige ontmoeting in een lift. Je hebt tien seconden. Kun je je spel zo enthousiast, zo interessant, zo geamuseerd beschrijven dat je op dat korte moment een enorm vooruitbetalings- en publicatiecontract kon scoren??
Schrijf deze elevator pitch neer. Verander het. Maak het korter. Doe alsof, in plaats van het bovenstaande scenario, dit de tekstkopie van de achterkant van de doos van je spel zou zijn als deze op een winkelschap zou zitten. Stel je voor dat een gamer de doos oppakt en omdraait. Ze hebben honderden andere spellen om uit te kiezen, maar ze hebben besloten om je een dozijn seconden van hun tijd te geven om de jouwe te overwegen. Verkoopt deze pitch de game?
Als je het aan een vriend (of beter nog, een onbekende) voorlas, zijn ze dan geïntrigeerd? Opgewonden? Enthousiast? Als je ja kunt zeggen tegen deze vragen, weet je dat je iets goeds hebt gedaan.
Gewoon voor de lol, en om al mijn punten te illustreren, ga ik je mijn work-in-progress tonen voor een recente game die ik heb gemaakt. De elevator pitch aan het begin ging ongeveer als volgt:
Jij bent de slechterik. Twee geliefden willen wanhopig elkaar omhelzen. Jouw missie is om ze uit elkaar te houden door muren te bouwen die ze verder uit elkaar drijven zonder het ooit onmogelijk te maken. Een turn-based strategy puzzelspel gebaseerd op A-star pathfinding.
De volgende stap, voordat je begint met het coderen of het creëren van grote bibliotheken met inhoud die al dan niet in je uiteindelijke spel terechtkomen, is om maak een ruwe schets van het spel in actie. Je hebt geen artistieke vaardigheden nodig: deze kunnen zwart zijn en terwijl de miniatuurminiaturen van het crayon stick zijn. Waar je naar streeft, is een visuele weergave van het hele spel - van begin tot midden tot einde.
Teken een aantal panelen op een vel papier en begin met een ruwe benadering van hoe het titelscherm of hoofdmenu eruit zal zien. Teken in het volgende paneel wat er vervolgens gebeurt. Een intro? Niveau een? Ga door alsof je van het ene moment op het andere het spel zelf speelt. Hoe meer panelen je moet maken om je game volledig te visualiseren, hoe meer werk je aan jezelf zult toewijzen. Probeer daarom het hele ding op één pagina te passen. Minder dan een dozijn panelen is verstandig - maar de hemel is de limiet.
Ik laat je mijn work-in-progress shots zien van een puzzel / strategie / tactiekgame die ik onlangs Pathos heb geprogrammeerd. Om te beginnen, hier is de ruwe schets die ik gebruikte om de game-monteur snel te plannen:
Zoals je kunt zien, ben ik een grote fan van woordspelingen. Ik speelde met allerlei varianten van de game-titel die het a-star pathfinding-algoritme speelden, en ik gooide veel Dungeons and Dragons RPG-achtige beelden in, omdat dat me inspireert. Ik hou van fantasiewereldkaarten en dacht dat dit het ideale niveaukeuzescherm zou zijn.
De reden dat het maken van een snel storyboard belangrijk is, is dat het je een concretere beschrijving geeft van wat er feitelijk in het spel gebeurt. Moreso, het legt dingen visueel uit. Hoeveel knoppen kun je op één scherm passen? Hoe groot is de avatar? Welke richting is de beweging? Waar is de score of gezondheidsbalk? Deze miniaturen zijn een prachtige manier om de game vanuit het perspectief van een ontwerper te bekijken. Ze zullen u ook op verschillende manieren helpen bij het coderen. U weet bijvoorbeeld nu ongeveer hoeveel pictogrammen of knopafbeeldingen u moet tekenen, wat de niveaus van de kunst vereisen en zelfs hoe de game eruit zal zien - vanuit een basislayout-perspectief.
Als je strip er nu niet uitziet als een leuk spel, dan heb je jezelf weken of maanden van werk bespaard door alvast te weten dat er enkele wijzigingen moeten worden doorgevoerd. Als de strip voor altijd lijkt te duren, zie je de duidelijke waarschuwingstekens dat de werkdruk te groot is en moet je het aantal scènes of niveaus of gameplay-elementen verminderen.
Net als een elevator-pitch, is dit storyboard met één pagina-achtige strip in stripvorm een ideaal BS-filter. Laat het zien aan vrienden. Willen ze dit spel spelen? Denken ze dat het de moeite waard is om een realiteit te worden??
De volgende belangrijke handige tip voor deze uitdaging is om de eerste dag een speelbaar spel te maken. Geen titelscherm, slechts één niveau, en alleen de primaire gameplay-monteur.
Het zal niet geweldig zijn, het zal niet af zijn en het zal er zeker niet geweldig uitzien of zo leuk zijn. Dat gezegd hebbende, deze stap is je beste wapen. Daag jezelf uit om een codebase te maken die in de eerste paar uren wordt samengesteld en wordt uitgevoerd. Zorg ervoor dat je inputs kunt accepteren, rond kunt bewegen, iets kunt animeren en sommige geluiden kunt triggeren. Dit prototype, hoe waardevol een spel ook mag zijn, zal je beste vriend worden.
Hoe eerder u een werkend vroeg speelbaar prototype kunt hebben, hoe groter de kans dat u slaagt. Het wordt je eerste "opslagpunt" - een rustplateau op weg naar de top van de berg waarop je kunt terugvallen. Het vertegenwoordigt een visie op het werkspel. Vanaf hier kun je je game zo lang als je wilt oppoetsen met de wetenschap dat je iets in handen hebt dat "werkt".
Dit is hoe het eerste prototype eruit zag. Het was een eenvoudig voorbeeld van pathfinding in actie, met NO ART - alleen gekleurde rechthoeken.
Om deze fase te bereiken duurde veel programmeertijd. Ik schat dat de helft van de levensduur van het project is besteed aan het spel, zoals op de afbeelding hierboven. De no-art benadering is ideaal voor programmeren: het bespaart tijd, helpt je de beestjes te achterhalen en dwingt je om je te concentreren op het "voelen".
No-art prototypen hebben ook nog een ander groot voordeel: in vorige games maakte ik prachtige mockups in Photoshop en verzamelde ik honderden mooie uitziende sprites ter voorbereiding op het spel. Nadat de ontwikkeling was voltooid, moest de overgrote meerderheid van de kunst worden vervangen, verkleind of weggegooid. Ik heb duizenden uren verspild met het maken van artwork dat klaar is om te spelen voordat ik codeer; tegenwoordig weet ik dat de technische specificaties en de evoluerende gameplay-mechanica dat ook betekenen veel van wat je aan het begin maakt, haalt het niet in het voltooide spel.
Zodra de spelmonteur waarmee je werkt begint te werken, kun je dat begin met het toevoegen van polish aan uw minimaal haalbare product. In dit stadium moet je nog steeds geen hoofdmenu of titelscherm hebben, maar de bewegings- en spelregels moeten aanwezig zijn om de primaire monteur te dekken.
Je bent nu klaar om je vast te leggen op een bepaalde pixelgrootte voor je sprites, om te beslissen over lay-outs en kleurenschema's en hoeveel tegels je op het scherm wilt hebben, en om kunst van speelkwaliteit in je gamewereld te laten vallen. Dit is ook het moment om te experimenteren met de prestaties en om te gaan met alle technische beperkingen, zoals het onderhouden van een goede framerate en onder de gewenste bandbreedte of textuurgrootte te blijven.
Terug naar mijn voorbeeldproject, hier is het eerste werkende prototype, met slechts een paar placeholder-sprites. De afstand van de ene locatie naar de andere wordt nu gemeten en we zijn klaar voor enkele feitelijke niveaus:
Goed nieuws: dit is je volgende "save point"! Je hebt een spel dat "werkt" omdat het functioneert. U kunt op het scherm klikken en er gebeurt iets. Er is geen persoonlijkheid en slechts één niveau, maar het is op zijn minst iets dat je naar een vriend kunt sturen en ze kunt vragen om te spelen. Je hebt iets dat compileert.
Waar we hier naar streven is functionaliteit: iets, iets waar je aan zou kunnen werken en toch iets hebt om te laten zien (en te spelen!). Het kan vreselijk onplezierig of lelijk zijn als zonde, maar dat is niet in het minst belangrijk. Op zijn minst heb je een codeproject dat compileert zonder fouten en een deliverable produceert.
Pas als je dit "vroeg speelbaar" bereikt, ben je zeker dat je de finishlijn raakt, omdat je het vanaf nu zou kunnen verzenden.
Met de centrale gameplay-monteur in de hand, opent de wereld zich voor jou. De mogelijkheden zijn eindeloos en het leuke begint. Misschien kies je ervoor om een aantal niveaus toe te voegen, een dialoogvenster te schrijven of een aantal karakters te ontwikkelen om je spelwereld te bewonen. Misschien denk je dat een fraai deeltjessysteem, coole muziek of een hoge score lijst essentieel is voor jouw visie op wat de game zou moeten zijn. Super goed! Induiken!
Onthoud een ding: werk niet op een beetje van dit of dat alles tegelijk. Concentreer je op één taak en voltooi het tot de minimale basis-complete staat voordat je verder gaat.
Je zult je misschien vervelen als je ergens aan werkt en een pauze nodig hebt. Dat is prima - maar probeer gedisciplineerd genoeg te zijn om aan het minimale systeem te blijven werken totdat het bestaat in een staat waar je naar toe kunt lopen als dat nodig is.
Voordat u bijvoorbeeld combat- of health- of particle-effecten implementeert, kunt u zich concentreren op de personagebeweging en botsdetectie tot u zeker kunt zeggen dat het personage beweegt, tegen muren oploopt en reageert op bedieningselementen voor het toetsenbord, de muis of joystick.
Enkel en alleen dan moet je doorgaan met wapens, of geavanceerde bewegingen zoals springen, of detecteren of de speler specifiek lava aanraakt en schade moet krijgen.
Door zo rechtlijnig als je kunt te werken (binnen de rede), zul je merken dat je minder dingen tegelijkertijd jongleert. Je geest kan zich concentreren op één taak per keer in plaats van overweldigd te worden door vijftig verschillende fouten in vijftig verschillende klassen. Dit is essentieel om je motivatie, concentratie en enthousiasme te behouden. Niets maakt dat je meer wilt stoppen dan dat je zoveel problemen hebt om op te lossen dat je ontmoedigd raakt.
Net als bij een lekkende dam, is een enkel gat eenvoudig aan te sluiten. Als er in plaats daarvan vijftig verschillende gaten tegelijk verschijnen - als je van de ene uitdaging naar de andere springt zonder het programma waaraan je eerder werkte te voltooien - zul je al snel merken dat je in een enorme stapel met fouten zit die zo complex is en zoveel problemen verspreid over dat je dat vreselijke gevoel krijgt dat komt met het besef dat je alles moet insmeren om ze allemaal te maken.
In het leven van een gamedev creëer je een metaforisch save-punt telkens wanneer je een MVP of een speelbaar prototype of een vrijgegeven versie van een game voltooit.
Vergeet niet om deze speelbare versie van het spel ergens anders dan je werkmap op te slaan. Gebruik versiebeheer. Sluit het spel in en gooi het naar je back-upschijf. E-mail het naar een playtester. Wat u ook doet, zorg ervoor dat u, als u alles vanaf dit punt vernietigt, één versie kunt terugsturen en verzenden.
Probeer altijd om veel iteratief verbeterde en incrementeel verbeterde werkende, functionele, uitvoerbare bestanden te maken. Als je meer dan een dag hebt gewerkt zonder een degelijke back-upversie van je spel te hebben die, indien nodig, openbaar gemaakt zou kunnen worden, zou je nerveus moeten worden.
Natuurlijk zijn er af en toe lange stukken waar je uren achter elkaar beestjes kunt opsporen. Wanneer je een punt bereikt waarop het spel vaag functioneel lijkt en niet volledig kapot is, sla dan een back-up op. Daar - je hebt een ander opslagpunt gemaakt.
Om deze reden geldt de hierboven beschreven lineaire, iteratieve benadering ook voor uw inhoud of spelniveaus. Werk aan het oppoetsen van een goed niveau per keer. Op deze manier, als je te weinig tijd, geld, geduld of enthousiasme hebt voordat je alle 99 levels hebt voltooid die je in je ontwerpdocument zou plannen, zijn de drie of vier die je hebt voltooid goed genoeg dat je nog steeds trots op ze zou kunnen zijn.
Simpel gezegd, probeer altijd een versie van de game beschikbaar te hebben waar je vanaf kunt lopen en live kunt spelen. Dit is een vangnet. Per slot van rekening kan het leven morgen een onverwachte crisis voor je zijn. Ziekte, familiezaken, een tegemoetkomende bus - wat de oorzaak ook is, je zult altijd beter slapen met een veilige plek klaar.
Vergeet niet dat je er altijd op terug kunt komen en een sterk verbeterde en uitgebreide versie 2.0 kunt maken.
Iteratieve, lineaire, stap voor stap, one-thing-at-a-time ontwikkeling is het geheim van 12-in-12 succes.
Als je een paar spaarpunten hebt geslagen, zal je spel in topvorm zijn. Op een gegeven moment ga je beslissen dat het tijd is om het af te maken. Het is belangrijk om te beseffen dat je nooit de helft van de functies uit je originele brainstormdocument zult toevoegen. Waarschijnlijk zijn er veel meer van uw versie 1.0 naar uw versie 2.0-verlanglijstje gegaan.
Laten we terugkeren naar mijn voorbeeldprojectgame. Op dit punt was ik een weekend aan en uit aan het werken en was klaar om het te verzenden en weg te lopen. Ik had de naam veranderd, een paar mooie illustraties toegevoegd, een parser gecodeerd voor het gegevensformaat dat mijn niveau-editor gebruikte, en ik vond een aantal geluiden en muziek. Het was een spel. Het was speelbaar. Ik was er trots op. Ik noemde het "Pathos" en zo zag het eruit. Klik op de afbeelding hieronder om meer te lezen en het spel te spelen.
Alle gamedevs zijn enthousiaste, creatieve mensen. Helaas is het dit grenzeloze enthousiasme en creativiteit die ons in de problemen kunnen brengen. Als optimisten hebben we in onze verbeelding een grootse visie van wat zou kunnen zijn: die ultieme game die je net kent zou verkopen als warme broodjes.
Elk onderdeel van dit grootse droomproject klinkt als iets dat je gemakkelijk zou kunnen doen - en dit is waarschijnlijk waar! Als u echter elke taak optelt, is uw ruime vaardigheid eenvoudig niet wat u beperkt; het is jouw tijd dat is schaars.
Bedenk dat de meeste games die je op een console speelt, bijvoorbeeld honderd jaar lang fulltime voor honderd mensen hebben gewerkt. Als je een solo-indie bent die probeert te concurreren met dit soort teams, hoef je alleen maar een beetje wiskunde te bedenken om te beseffen dat de arbeidsuren van de mensuren meer dan één indie-ontwikkelaar zijn..
Je moet gewoon accepteren dat je lager moet richten om te eindigen tenzij je jaren aan een enkel spel wilt spenderen. Aangezien het gemiddelde goede Indie-spel een paar duizend dollar winst oplevert, kun je het je niet veroorloven om honderden of duizenden uren aan je spel te besteden, tenzij je de boerderij op een levenswerk of episch meesterwerk inzet. Je moet games ontwerpen die 20 tot 50 uur aan werk kosten.
In alle opzichten, droom groot - maar bouw iteratief. Bouw een minimaal levensvatbaar product en als afspeeltesters het geweldig vinden, voeg dan een beetje meer toe en noem die versie 2.0. Blijf zo doorgaan zo lang als je wilt!
Perfectie is per definitie onbereikbaar. Je zult je trots moeten inslikken en imperfectie accepteren. Om dit te verwaarlozen, moet je jezelf voor een eeuwigheid aan het project hechten. Vergeet niet dat je altijd een vervolg kunt maken. Het vrijgeven van je spel, ook al weet je dat je het voor altijd zou kunnen verbeteren, is een goede zaak. Niet alleen zal het een enorm gewicht van je schouders tillen en je iets geven waar je heel trots op kunt zijn, maar zodra het in de handen van je speler komt, kunnen ze nieuwe functies bedenken die je nog nooit overwogen had.
Wanneer je te weinig tijd, energie, geld of motivatie hebt, start dan wat je hebt. Als je hebt vastgehouden aan de systeemontwikkelingmethodologie van het opslagpunt, zou je in elk stadium van het project iets speelbaars moeten hebben, zelfs als er nog allerlei functies over zijn in je verlanglijstje of to-do-lijst. Dat is goed!
De "release early, release often" mantra wordt steeds weer herhaald door succesvolle gamedevs om een goede reden. Je hebt spelersfeedback nodig. Je hebt tests in de echte wereld nodig. Coderen in een zwarte doos, wegstoppen in een bunker tot het moment van definitieve vrijgave, is een vergissing. Ten eerste zie je je eigen spel door je beperkte perspectief. U hebt waarschijnlijk tijden gemerkt wanneer u uw eigen e-mails opnieuw leest, maar 's werelds meest voor de hand liggende typfouten worden doorgenomen. Dit komt omdat na een tijdje naar hetzelfde te kijken, je geest gevoelloos begint te worden voor het kritische oog. Een nieuwe reeks ogen ziet de dingen in een ander licht.
Je zou kunnen merken dat een bepaalde monteur, hoewel het op papier briljant lijkt, saai of frustrerend is zodra het is geïmplementeerd.
Bovendien zijn spellen die vroegtijdig worden uitgebracht en nog steeds worden ontwikkeld, degenen die de grootste blootstelling krijgen. U genereert meer "nieuwswaardige" informatie. Je bouwt buzz op. Je trekt volgers aan. Je laat mensen je spel testen en waardevolle kennis opdoen die van invloed is op je ontwerpen.
Spelers kunnen kritiek of kudos bieden die je verrassen. Functies waarvan je dacht dat ze belangrijk waren, kunnen met desinteresse worden bereikt, terwijl degenen waarvan je dacht dat ze onbelangrijk waren, misschien wel ieders favoriet zijn. Het is belangrijk om te zien hoe het publiek reageert op je spel en dienovereenkomstig te reageren. Dit bespaart u tijd en verdriet. Het geeft je richting voor toekomstige releases. Het belangrijkste is dat je nieuwe fans, volgers en een welverdiende schouderklop krijgt.
Bovendien is de kennis die iemand daar heeft gespeeld en leuk vond, goud waard.
Nu je dat extra beetje motivatie en een glimp van mijn persoonlijke gamedev-methodologie hebt gekregen, moedig ik je aan om van het internet af te komen en er gewoon in te duiken. Te lang plannen of onderzoeken kan een energie- en tijdafvoer zijn. Soms is het enige wat u echt hoeft te doen een nieuwe map maken, een leeg project maken en beginnen met coderen. Start je gamedev-motoren en schakel de naverbranders.
Als je deze basisfilosofie van gameontwikkeling volgt, heb ik er vertrouwen in dat je veel beloningen zult ontvangen. De meest basale is minder stress. Meer plezier van het proces, meer tastbare, speelbare builds en meer kansen om feedback van spelers te krijgen, zijn ook het voordeel van dit Save Point-systeem. Door projecten in kleine discrete secties te hakken, weet u zeker dat u deze maand elke maand een nieuwe game kunt posten.
Als je klaar bent voor dit soort uitdagingen, nodig ik je van harte uit om deel te nemen aan OneGameAMonth, een gamedev-uitdaging die is geaccepteerd door meer dan drieduizend indie-gamedevs, net als jij.
OneGameAMonth is gamedev met toevoeging van gamification: je verdient ervaringspunten, levelups en achievement-prijzen voor het maken van games. Je krijgt verbinding met een zeer betrokken en actieve gemeenschap van gelijken die ondersteunend, behulpzaam en gastvrij is. Honderden games van elk genre worden daar nu gepost. Doe met ons mee!
Veel succes met je toekomstige gamedev-projecten. Je kunt het.
Accentsconagua