Share
Zodra je besluit om games te maken, spring je in een oceaan van nieuwe problemen - problemen waarvan je niet eens wist dat ze bestonden! Maar je springt ook in een lonend en uitdagend medium, een waarmee je je ideeën op nieuwe en interessante manieren kunt verkennen.
Wat meer is, de problemen die een nieuwe ontwikkelaar tegenkomt, zijn dezelfde die iedereen is tegengekomen, dus veel tijd en verdriet kunnen worden bespaard door het advies van anderen in te winnen. In dit artikel zal ik vertellen over hoe ik die problemen heb gevolgd, beginnend bij mijn eerste idee en de voortgang naar mijn eerste succesvolle game.
Meestal begin je met het maken van games omdat je er een aantrekkelijk idee voor hebt. Mijn idee was een free-roaming FPS met willekeurige wereldgeneratie, willekeurige gebouwgeneratie, dynamische AI, de werken. Nadat ik het Game Design Document voor mijn idee (het enthousiasme!) Had geschreven, was het duidelijk dat ik niet het flauwste idee had van wat ik aan het doen was, dus besloot ik het te laten voor een tijd waarin ik meer ervaring had (zoals mijn tiende game, misschien) en doe iets veel eenvoudiger: een kleiduiven schietspel. Het was nog steeds gerelateerd aan mijn doel om een FPS te maken, maar niet zo verbazingwekkend complex.
Ik wist al hoe ik programmeerde in scripttalen op een hoog niveau zoals PHP en Autohotkey, dus ik was blij om een andere gamedev-taal op hoog niveau te leren, zoals Java, Python, Lua of C #. Met dit in gedachten begon ik naar motoren en kaders te kijken.
Ik ging naar reddit en nam de balans op van de populaire 3D-engines en probeerde er zelf een aantal uit om te zien of ze bij mijn workflow en manier van denken passen. Ik heb vijf 3D-engines en frameworks geprobeerd, doe hun tutorials voor beginners en koop zo nodig boeken. Uiteindelijk heb ik de Eenheid geadopteerd omdat het de enige was die voor mij persoonlijk echt logisch was. Later kocht ik de PlayMaker-plug-in voor Unity, met de intentie om hem te gebruiken voor zaken als eenvoudige AI. In plaats daarvan merkte ik dat ik het erg leuk vond om visuele codering met slepen en neerzetten te hebben, naast het direct programmeren. Dit beïnvloedde mijn latere beslissing om GameMaker Studio te gebruiken voor 2D-spellen omdat het een zeer vergelijkbare workflow heeft.
Dus mijn eerste spel was een kleiduivenschietsimulatie, gekozen omdat het eenvoudig te bereiken was, maar nog steeds rechtstreeks toepasbaar op mijn grote FPS-idee. Ik heb veel moeite gekeken om duivenmaten en -gewichten op te zoeken, snelheid en dichtheid van de schaal, duivalennis en vrijwel alles wat je maar kon bedenken, en 60 uur later bleef ik achter met een fysiek nauwkeurige simulatie van kleiduivenschieten..
Maar de game was helemaal niet leuk. Het slaan van de duiven was hard, man. Je wist nooit echt hoeveel je de duiven moest leiden omdat het spel de lanceringshoeken willekeurig maakte. Het jachtgeweer gooide honderden individuele pellets weg waarvan de richting en snelheid willekeurig waren om ze in een wolk uit te spreiden, en soms vlogen de duiven door een gat in de schotwolk en kwamen onverstoord tevoorschijn. Slaan op iets dat als stom geluk voelt.
Volledig realisme is niet altijd een goed spel.
Dus ging ik terug en maakte het hele ding meer "gamey". De grootste verandering was dat in plaats van 400 kleine korrels per shot, ik het vereenvoudigde tot acht enorme bollen die de schotwolk vertegenwoordigden, en een stevige massa produceerden die elke kleiduif zou vernietigen, in plaats van dat de duif door willekeurige openingen kon ontsnappen. in de wolk. Nadat deze verandering was doorgevoerd, werd het spel voorspelbaar en leuk - of op zijn minst net zo leuk als een eenvoudig kleiduivenschietspel. Je kunt het laatste spel op mijn website bekijken.
Spellen zijn rook en spiegels. Het is prima om vals te spelen om het beoogde resultaat te krijgen.
Kort na het beëindigen van mijn kleiduivelspel besloot ik om deel te nemen aan Ludum Dare. Ik had veel gehoord over hoe educatief het was om deel te nemen aan gameproblemen, en dit was een uitstekende test van mijn vaardigheden en werkethiek, en een kans om te zien of ik het leuk vond om games te maken.
De dag voor het evenement maakte ik een lijst van waar ik goed in was en waar ik slecht in was:
Een korte lijst, om zeker te zijn! Maar door het te schrijven, weet ik wat ik redelijkerwijs van mezelf kon verwachten:
Toen het thema ontstond, wist ik precies welke ideeën ik moest weggooien in de brainstormfase en welke ideeën ik moest nastreven. Ik besloot om een op kleuren gebaseerd puzzelspel te maken en dankzij de realistische doelen die ik mezelf stelde, kon ik vroeg genoeg eindigen om het spel grondig te verbeteren en mijn puzzelspel toevoeging eindigde in de top 5% van de inzendingen.
Het maken van een compleet spel in een jam-omgeving was een leerzame ervaring en hoewel het beangstigend kan zijn, raad ik het aan alle nieuwkomers aan. Ik heb drie belangrijke ideeën geleerd van maken toevoeging:
Er zijn een aantal andere tips die ik zou willen delen. Je zou absoluut moeten werken met een soort tijdmanagementschema. Ik hou van de Pomodoro-techniek en ben dol op het horen van het tikken van een mechanische timer. Draag ook een klein notitieboek en noteer al je spelideeën. Ideeën komen gemakkelijker naar je toe als je jezelf toestaat om zelfs de slechten te entertainen. En maak je geen zorgen over het vasthouden aan één stijl, één genre of één engine. Experimenteer, kijk wat voor u werkt, plaats uzelf in nieuwe situaties en werk echt uw creativiteit!
Tot slot wil ik alles wat ik geleerd heb samenvatten toen ik voor het eerst in vier woorden begon: het kan worden gedaan. Naast software zijn videogames een samensmelting van elke andere vorm van kunst. Je kunt niet verwachten dat je er 's nachts goed in bent, maar je kunt je aanpak verfijnen om tegemoet te komen aan je zwakheden en spelen op je sterke punten, en je kunt gebruiken wat je weet nu om interessante eigen werken te maken.
Accentsconagua