Share
Als onderdeel van de viering van ons eenjarig jubileum, dachten we dat we een kijkje zouden nemen naar de soorten artikelen die we de komende 12 maanden willen laten maken. Intern hebben we gedebatteerd over de verdiensten van het ene soort artikel over het andere, wie zijn onze lezers en wie we het meest moeten targeten, en wat is het precies over Gamedevtuts + waar we zoveel van houden.
Voor het publiceren van toekomstbestendige artikelen waarmee beginners-tot-middelgrote game-ontwikkelaars hun vak kunnen verbeteren. Elke eerdere zelfstudie die u kunt lezen op Gamedevtuts + zou iets moeten zijn dat we graag vandaag publiceren.
Dit zijn de attitudes die we hebben gebruikt om Gamedevtuts + uit te voeren sinds we het hebben gelanceerd (hoewel we ze in de tussentijd voortdurend hebben aangepast).
De cruciale rol - niet noodzakelijkerwijs het belangrijkste, maar cruciaal - in game-ontwikkeling is implementatie. Fantastische kunst en geluid zonder interactiviteit is geen spel, maar een game kan worden gemaakt zonder kunst of geluid.
Dus we definiëren "gamedev", voor onze doeleinden, als (a) het bedenken van regels, thema's, mechanica, esthetiek, enz. En (b) het implementeren ervan, het toevoegen van interactiviteit.
Het gaat er niet om om daadwerkelijk de kunst en het geluid te creëren, dus we zullen geen tutorials doen over het tekenen van personages in Illustrator of het maken van muziek in Logic Pro - onze zuster Tuts + -sites dekken dat al, hoe dan ook.
Tegelijkertijd is het niet nodig diep in te gaan op programmeren of op het gebruik van specifieke talen; dat is niet onze focus.
Het kan zakelijke (PR, marketing, juridische zaken, etc.) omvatten en mensen vinden die kunst en geluid kunnen creëren.
Dit is een geweldig artikel dat een inleidend overzicht geeft van vrijwel alles: hoe een Indie Game-ontwikkelaar te zijn, door Mode 7 Games.
Dit helpt vooral om onze te definiëren publiek, - we zijn bijvoorbeeld niet gericht op degenen die sprites maken in Illustrator of muziek in Logic Pro.
Tuts + en Envato richten zich over het algemeen op freelancers, aannemers, werknemers in kleine bedrijven en dergelijke; we doen hetzelfde bij Gamedevtuts +. Onze berichten zijn gericht op freelance game-ontwikkelaars, indies, contractanten en kleine studio's. We schrijven niet specifiek voor ontwikkelaars van AAA-console-spellen, hoewel ze natuurlijk ook van onze inhoud kunnen genieten en ze zijn van harte welkom om voor ons te schrijven!
We hebben ons publiek opgedeeld in drie brede groepen, gebaseerd op hun ervaring:
beginners heb nog nooit een spel gemaakt. We kunnen echter niets anders over hen aannemen - bijvoorbeeld, sommige kunnen briljante programmeurs zijn die al tien jaar in software werken, terwijl anderen misschien helemaal geen programmeerervaring hebben.
Intermediates een volledige game eerder hebben gemaakt of misschien op meerdere hebben gewerkt. Het is veilig om te veronderstellen dat ze een basiscompetentie hebben in een of meer programmeerhulpmiddelen of talen. Dit kan geavanceerde Game Maker-scripting zijn, Unity zijn, XNA zijn ... alles dat verder gaat dan slepen en neerzetten - en dus geen behoefte hebben aan hun handen vast bij het bespreken van code. Ze weten waar ze informatie kunnen vinden over hun gereedschap naar keuze: de documenten, forums, Stack Overflow, naslagwerken, enzovoort.
gevorderd lezers hebben een reeks spellen gemaakt of eraan gewerkt, althans waarvan sommige succesvol waren en hebben daarom veel ervaring. Wanneer een ontwikkelaar van een beginner of tussengame vraagt: "Hoe maak ik een MMORPG?" het antwoord is: "Dat doe je niet." - maar dat is niet het geval voor gevorderde lezers.
Onlangs hebben we gemerkt dat er een duidelijk verschil is tussen Beginner en Gemiddeld, en dit kan groot genoeg zijn om sommige gamedevs door de kloven te laten glippen - zij die hiaten in hun vaardigheden hebben en de grootste demografie van gamedevs vertegenwoordigen, maar niet ze beschouwen zichzelf als beginners. Omdat we niet de neiging hebben om veel geavanceerde zelfstudies te publiceren, is het misschien tijd om deze groepen opnieuw te definiëren: tussentijdse zelfstudies worden opnieuw geclassificeerd als geavanceerd, waardoor we ruimte hebben voor nieuwe tussentijdse zelfstudies in die lacune.
We hebben een controversiële benadering van de site gevolgd: onze artikelen zijn platform-agnostisch. Soms leidden dit ertoe dat lezers zich afvroegen waarom we hun gereedschap, motor of taal van keuze hebben verwaarloosd.
Persoonlijk heb ik ook af en toe gedrongen naar meer ouderwetse (snel verouderde) platform- of taalspecifieke artikelen, maar ik ben het er volmondig mee eens dat ze een slechte keuze zijn als ze denken aan voordelen op de lange termijn.
Het is handig om een gedachte-experiment te doen: als we Gamedevtuts + tien jaar geleden hadden gelanceerd, zonder een platform-agnostische aanpak, in welke situatie zouden we nu zitten??
… enzovoorts. We zouden ook veel artikelen over onderwerpen als bedrijf en esthetiek hebben die in datum zouden blijven, maar we zouden merken dat veel van onze platformspecifieke tutorials ofwel minder relevant zouden zijn voor lezers, of zelfs zouden zijn om verouderde praktijken te onderwijzen.
Het gevaar bestaat dat we te nauw worden geassocieerd met een paar specifieke platforms, waardoor onze lezers mogelijk vervreemden als we proberen uit te zetten.
Als allemaal onze zelfstudies waren platformspecifiek, we riskeerden de lezers onnodig uit de weg te ruimen. Er is geen reden waarom een Java-ontwikkelaar een A * -tracking-zelfstudie geschreven in AS3 niet kan begrijpen, tenzij deze te AS3-specifiek is.
Platform-specifieke tutorials kunnen vaak erg "verf-door-nummers" zijn, als de schrijver en redacteur niet voorzichtig zijn; dit kan het publiek van de site naar de minder ervaren (of minder toegewijde) kantelen.
We kunnen grofweg onze implementatietutorials opsplitsen in deze brede categorieën:
Dit is een enorme investering: voor een echt indrukwekkende demo hebben ze goed artwork, goed geluid en stevige code nodig. En als de handleiding eenmaal geschreven is, kan het een enorme pijn zijn om hem bij te werken - stel je voor dat je probeert om een op blit gebaseerde AS3-tutorial bij te werken om Stage3D te gebruiken.
En toch ... dit zijn waarschijnlijk wat lezers verwachten van een gamedev-tutorial en hebben grote voordelen voor leren (er zijn zoveel subtiliteiten bij het samenstellen van een heel spel dat verloren gaat als je alleen maar de afzonderlijke componenten leert).
We hebben dit gedaan met onze beginnershandleiding "From Scratch" - die allemaal point-and-click, code-vrije gamedev-platforms gebruiken - maar nooit met een intermediate gamedev-platform dat codering vereist, zoals Unity of HTML5.
Dat gaat veranderen. We gaan beginnen met publiceren platformonafhankelijke tutorials, beginnend met Michael Hoffman's op Geometry Wars gebaseerde game. We publiceren een XNA-specifieke versie van de zelfstudie en vervolgens een Flash-specifieke versie en vervolgens een DirectX-specifieke versie, enzovoort. Elke module zal modulair zijn ontworpen, zodat ze kunnen worden bijgewerkt naarmate de onderliggende platforms in de toekomst veranderen.
We zullen deze platform-agnostisch houden - maar ze kunnen nog steeds in een specifieke taal geschreven worden, met demo's en broncode die gecompileerd zijn voor een specifiek platform, zolang ze platform-agnostisch genoeg zijn dat devs die bekend zijn met andere platforms kunnen begrijpen hen. Bijvoorbeeld: een tutorial over A * pathfinding zou u niet moeten vertellen "Open FlashDevelop en klik Bestand> Nieuw om een nieuw project te maken ".
We willen echter beginnen met het publiceren van zelfstudies waarin wordt uitgelegd hoe een aantal van deze concepten moet worden geïmplementeerd met een bepaald platform. Misschien maken we bijvoorbeeld een bericht op basis van Jamie Fristrom's uitstekende tutorial met swinging physics, waarin precies wordt uitgelegd hoe het moet worden gecodeerd in Unity of UDK of een ander geschikt platform..
Soms zijn de ongelooflijk krachtige tools en software die we gebruiken om spellen te maken een beetje ingewikkeld. Wie zou het geraden hebben?
We willen gamedevs helpen door tutorials te bieden waarin wordt uitgelegd hoe bepaalde pijnpunten in deze hulpmiddelen kunnen worden opgelost, of hoe dialogen kunnen worden gebruikt die misschien nog niet zo gebruiksvriendelijk zijn als ze zouden kunnen zijn. Het is echter zo dat deze aspecten vrij snel verholpen worden, wat betekent dat de bijbehorende tutorials verouderd raken en we geen gedateerde informatie op deze site willen.
We gaan met dit soort tutorials experimenteren, maar alleen voor problemen die echte pijnpunten zijn en die nog niet elders zijn uitgelegd. We zullen moeten uitzoeken hoe we de inhoud gescheiden kunnen houden van al het andere als deze verouderd is!
De toekomst ziet er rooskleurig uit voor Gamedevtuts +. Hoewel ik verwacht dat we onze prioriteiten constant zullen aanpassen aan die van onze lezers, evenals de constante innovatie in de industrie, hoop ik dat onze missie op de lange termijn ons zal helpen om relevant en onmiddellijk bruikbaar te blijven voor jouw huidige en toekomstige toekomstige game-projecten.
Door ons te richten op de hogere behoeften van gamedevs, de concepten die gelden voor verschillende genres en platforms, en de opkomende trends in de ontwikkeling van gamesoftware, het bedrijfsleven en de productie, zijn we van plan om tutorials en artikelen te maken die de tand des tijds doorstaan.
Er zullen tijden zijn dat we de technologie van de dag moeten aanpakken - om te kijken naar de nieuwste trends en tools van dit jaar. In het algemeen hopen we echter content te kunnen leveren die in de toekomst of in de toekomst toekomstbestendig is.
Immers, een diepgaande analyse van de levelontwerp-pacing of bewegingsfysica achter Super Mario Bros. is nog steeds van toepassing en is nu meteen van groot nut voor veel gamedevs. Omgekeerd zou een tutorial over geheugenbeheer in assembleertaal op de 6502 CPU die wordt gebruikt om de NES-versie van het spel aan te drijven vandaag alleen van belang zijn voor historische doeleinden.
Samenvattend: zelfstudieprogramma's en artikelen over het ontwerp, de implementatie en het spelen van games.
Wat vind je van dit beleid? Hoe voel je je over onze huidige richting? Ik zou graag uw mening horen over de kwestie. Er zijn tenslotte geen goede of foute antwoorden. Ik hecht veel waarde aan uw mening, ook als we het daar niet mee eens zijn. Voel u alsjeblieft van harte welkom om een reactie achter te laten.
Accentsconagua