"Ek weet dat ek niks weet nie" Sokrates
Vir wie: vir IT-mense wat op al die ontwikkelaars spoeg en hul speletjies wil speel!
Waaroor: hoe om speletjies in C/C++ te begin skryf as jy dit nodig het!
Hoekom moet jy dit lees: Toepassingsontwikkeling is nie my werkspesialiteit nie, maar ek probeer elke week kodeer. Want ek is mal oor speletjies!
hallo my naam is , Ek is 'n DevOps by Luxoft. Toepassingsontwikkeling is nie my werkspesialiteit nie, maar ek probeer elke week kodeer. Want ek is mal oor speletjies!
Die rekenaarspeletjiesbedryf is groot, volgens gerugte is dit vandag selfs groter as die rolprentbedryf. Speletjies is sedert die begin van rekenaars geskryf, met behulp van, volgens moderne standaarde, komplekse en basiese ontwikkelingsmetodes. Met verloop van tyd het spelenjins begin verskyn met reeds geprogrammeerde grafika, fisika en klank. Hulle laat jou toe om op die ontwikkeling van die speletjie self te fokus en jou nie te steur aan die grondslag daarvan nie. Maar saam met hulle, met die enjins, word die ontwikkelaars “blind” en degradeer. Die produksie van speletjies word op die vervoerband geplaas. En die hoeveelheid produksie begin die oorhand kry oor die kwaliteit daarvan.
Terselfdertyd, wanneer ons ander mense se speletjies speel, word ons voortdurend beperk deur liggings, plot, karakters, spelmeganika waarmee ander mense vorendag gekom het. So ek het besef dat...
… dit is tyd om jou eie wêrelde te skep, net aan my onderworpe. Wêrelde waar Ek die Vader en die Seun en die Heilige Gees is!
En ek glo opreg dat deur jou eie speletjie-enjin en 'n speletjie daarop te skryf, jy in staat sal wees om jou oë oop te maak, die vensters uit te vee en jou kajuit te pomp en 'n meer ervare en integrale programmeerder te word.
In hierdie artikel sal ek probeer om jou te vertel hoe ek begin het om klein speletjies in C / C ++ te skryf, wat die ontwikkelingsproses is en waar ek tyd kry vir 'n stokperdjie in 'n besige omgewing. Dit is subjektief en beskryf die proses van 'n individuele begin. Materiaal oor onkunde en geloof, oor my persoonlike prentjie van die wêreld op die oomblik. Met ander woorde, "Die administrasie is nie verantwoordelik vir jou persoonlike brein nie!".
Praktyk
"Kennis sonder oefening is nutteloos, oefening sonder kennis is gevaarlik." Confucius
My notaboek is my lewe!
So, in die praktyk, kan ek sê dat alles vir my begin met 'n notaboek. Ek skryf nie net my daaglikse take daar neer nie, maar teken, programmeer, ontwerp vloeidiagramme en los probleme op, insluitend wiskundiges. Gebruik altyd 'n notaboek en skryf slegs met 'n potlood. Dit is skoon, gemaklik en betroubaar, IMHO.
My (reeds gevul) notaboek. Dit is hoe dit lyk. Dit bevat alledaagse take, idees, tekeninge, diagramme, oplossings, swart boekhouding, kode, ensovoorts.
Op hierdie stadium het ek daarin geslaag om drie projekte te voltooi (dit is in my verstaan van “finaliteit”, want enige produk kan relatief eindeloos ontwikkel word).
- Projek 0: dit is 'n Argitek Demo 3D-toneel geskryf in C# met behulp van die Unity-speletjie-enjin. Vir macOS- en Windows-platforms.
- Speletjie 1: konsolespeletjie Simple Snake (aan almal bekend as "Snake") vir Windows. geskryf in C.
- Speletjie 2: konsolespeletjie Crazy Tanks (aan almal bekend as "Tanks"), reeds geskryf in C ++ (met behulp van klasse) en ook onder Windows.
Projek 0 Argitek Demo
- Platform: Windows (Windows 7, 10), Mac OS (OS X El Capitan v. 10.11.6)
- Taal: C#
- Spelenjin:
- Inspirasie:
- Bewaarplek:
3D Toneel Argitek Demo
Die eerste projek is nie in C/C++ geïmplementeer nie, maar in C# met behulp van die Unity-speletjie-enjin. Hierdie enjin was nie so veeleisend op hardeware soos , en het ook vir my makliker gelyk om te installeer en te gebruik. Ek het nie ander enjins oorweeg nie.
Die doel in Unity vir my was nie om een of ander speletjie te ontwikkel nie. Ek wou 'n 3D-toneel skep met 'n soort karakter. Hy, of eerder Sy (ek het die meisie op wie ek verlief was gemodelleer =) moes beweeg en met die buitewêreld omgaan. Dit was net belangrik om te verstaan wat Unity is, wat die ontwikkelingsproses is en hoeveel moeite dit verg om iets te skep. Dit is hoe die Architect Demo-projek gebore is (die naam is amper uit die snert uitgedink). Programmering, modellering, animasie, teksturering het my seker twee maande se daaglikse werk geneem.
Ek het begin met tutoriaalvideo's op YouTube oor hoe om 3D-modelle in te skep . Blender is 'n wonderlike gratis hulpmiddel vir 3D-modellering (en meer) wat nie installasie benodig nie. En hier het 'n skok op my gewag ... Dit blyk dat modellering, animasie, tekstuur groot afsonderlike onderwerpe is waaroor jy boeke kan skryf. Dit geld veral vir die karakters. Om vingers, tande, oë en ander dele van die liggaam te modelleer, sal jy kennis van anatomie nodig hê. Hoe is die spiere van die gesig gerangskik? Hoe beweeg mense? Ek moes bene in elke arm, been, vinger, kneukels "insit"!
Model die sleutelbeen, bykomende beenhefbome, sodat die animasie natuurlik lyk. Ná sulke lesse besef jy watter groot werk die skeppers van animasiefilms doen, net om 30 sekondes se video te skep. Maar 3D-flieks hou vir ure! En dan kom ons uit die teaters en sê iets soos: “Ta, 'n kak spotprent / fliek! Hulle kon beter gedoen het...” Fools!
En nog een ding oor programmering in hierdie projek. Soos dit geblyk het, was die mees interessante deel vir my die wiskundige een. As jy die toneel laat loop (skakel na die bewaarplek in die projekbeskrywing), sal jy agterkom dat die kamera om die meisiekarakter in 'n sfeer draai. Om so 'n kamerarotasie te programmeer, moes ek eers die koördinate van die posisiepunt op die sirkel (2D), en dan op die sfeer (3D) bereken. Die snaakse ding is dat ek wiskunde op skool gehaat het en dit met 'n minus geken het. Deels, waarskynlik, want op skool verduidelik hulle eenvoudig nie vir jou hoe de hel hierdie wiskunde in die lewe toegepas word nie. Maar wanneer jy behep is met jou doel, droom, dan word die verstand skoongemaak, geopenbaar! En jy begin komplekse take as 'n opwindende avontuur beskou. En dan dink jy: "Wel, hoekom kon *geliefde* wiskundige nie normaalweg sê waar hierdie formules geleen kan word nie?".
Berekening van formules vir die berekening van die koördinate van 'n punt op 'n sirkel en op 'n sfeer (uit my notaboek)
Speletjie 1
- Platform: Windows (getoets op Windows 7, 10)
- Taal: Ek dink dit is in suiwer C geskryf
- Spelenjin: Windows-konsole
- Inspirasie:
- Bewaarplek:
Eenvoudige slang spel
Die 3D-toneel is nie 'n speletjie nie. Daarbenewens is modellering en animasie van 3D-voorwerpe (veral karakters) lank en moeilik. Nadat ek met Unity rondgespeel het, het ek besef dat ek van die basiese af moet voortgaan, of eerder begin. Iets eenvoudig en vinnig, maar terselfdertyd wêreldwyd, om die struktuur van speletjies te verstaan.
En wat het ons eenvoudig en vinnig? Dit is reg, konsole en 2D. Meer presies, selfs die konsole en simbole. Weereens het ek inspirasie op die internet begin soek (oor die algemeen beskou ek die internet as die mees revolusionêre en gevaarlikste uitvinding van die XNUMXste eeu). Ek het 'n video opgegrawe van een programmeerder wat konsole Tetris gemaak het. En in die gelykenis van sy spel het hy besluit om die “slang” af te kap. Uit die video het ek oor twee fundamentele dinge geleer - die spellus (met drie basiese funksies / dele) en uitvoer na die buffer.
Die spellus kan so iets lyk:
int main()
{
Setup();
// a game loop
while (!quit)
{
Input();
Logic();
Draw();
Sleep(gameSpeed); // game timing
}
return 0;
}Die kode bied die hele hoof()-funksie gelyktydig aan. En die speletjie-siklus begin na die ooreenstemmende opmerking. Daar is drie basiese funksies in die lus: Input(), Logic(), Draw(). Eerstens, voer data in Invoer (hoofsaaklik beheer van toetsaanslagen), verwerk dan die ingevoerde data Logika, dan vertoon op die skerm - Teken. En so elke raam. Animasie word op hierdie manier geskep. Dit is soos spotprente. Gewoonlik neem die verwerking van die invoerdata die meeste tyd en bepaal, sover ek weet, die raamtempo van die speletjie. Maar hier is die Logic()-funksie baie vinnig. Daarom moet die raamtempo beheer word deur die Sleep() funksie met die gameSpeed parameter, wat hierdie koers bepaal.
spel siklus. Slangprogrammering in notaboek
As jy 'n simboliese konsole-speletjie ontwikkel, sal die vertoon van data op die skerm met die gewone stroomuitset 'cout' nie werk nie - dit is baie stadig. Daarom moet die uitset in die skermbuffer uitgevoer word. Soveel vinniger en die spel sal sonder foute werk. Om eerlik te wees, ek verstaan nie mooi wat 'n skermbuffer is en hoe dit werk nie. Maar ek sal 'n kode voorbeeld hier gee, en miskien sal iemand in die kommentaar die situasie kan verduidelik.
Kry die skermbuffer (as ek so mag sê):
// create screen buffer for drawings
HANDLE hConsole = CreateConsoleScreenBuffer(GENERIC_READ | GENERIC_WRITE, 0,
NULL, CONSOLE_TEXTMODE_BUFFER, NULL);
DWORD dwBytesWritten = 0;
SetConsoleActiveScreenBuffer(hConsole);Direkte uitset na die skerm van 'n sekere lyntellingLyn (die lyn vir die vertoon van tellings):
// draw the score
WriteConsoleOutputCharacter(hConsole, scoreLine, GAME_WIDTH, {2,3}, &dwBytesWritten);In teorie is daar niks ingewikkeld in hierdie speletjie nie, dit lyk vir my 'n goeie voorbeeld van 'n intreevlak-speletjie. Die kode is in een lêer geskryf en in verskeie funksies gerangskik. Geen klasse, geen erfenis. Jy kan self alles in die bronkode van die speletjie sien deur na die repository op GitHub te gaan.
Spel 2 Crazy Tanks
- Platform: Windows (getoets op Windows 7, 10)
- Taal: C + +
- Spelenjin: Windows-konsole
- Inspirasie: книга
- Bewaarplek:
Crazy Tanks-speletjie
Om karakters na die konsole te druk is waarskynlik die eenvoudigste ding wat jy in 'n speletjie kan verander. Maar dan verskyn een probleem: die karakters het verskillende hoogtes en breedtes (die hoogte is groter as die breedte). Alles sal dus buite verhouding lyk, en om af of op te beweeg, sal baie vinniger lyk as om links of regs te beweeg. Hierdie effek is baie opvallend in "Snake" (Game 1). "Tenks" (speletjie 2) het nie so 'n nadeel nie, aangesien die uitset daar georganiseer word deur die skermpixels met verskillende kleure te verf. Jy kan sê ek het 'n weergawe geskryf. Dit is waar, dit is reeds 'n bietjie meer ingewikkeld, hoewel baie interessanter.
Vir hierdie speletjie sal dit genoeg wees om my stelsel vir die vertoon van pixels op die skerm te beskryf. Ek dink dit is die hoofdeel van die spel. En alles anders wat jy self kan uitdink.
Dus, wat jy op die skerm sien, is net 'n stel bewegende gekleurde reghoeke.
Reghoek stel
Elke reghoek word voorgestel deur 'n matriks gevul met getalle. Terloops, ek kan een interessante nuanse uitlig - al die matrikse in die speletjie is as 'n eendimensionele skikking geprogrammeer. Nie tweedimensioneel nie, maar eendimensioneel! Eendimensionele skikkings is baie makliker en vinniger om mee te werk.
'n Voorbeeld van 'n wildtenkmatriks
Verteenwoordig die matriks van 'n wildtenk met 'n eendimensionele skikking
'n Meer illustratiewe voorbeeld van 'n matriksvoorstelling deur 'n eendimensionele skikking
Maar toegang tot die elemente van die skikking vind plaas in 'n dubbellus, asof dit nie 'n eendimensionele, maar 'n tweedimensionele skikking is. Dit word gedoen omdat ons steeds met matrikse werk.
Deur 'n eendimensionele skikking in 'n dubbellus. Y is die ry ID, X is die kolom ID
Neem asseblief kennis dat in plaas van die gewone matriksidentifiseerders i, j, ek die identifiseerders x en y gebruik. So, lyk dit vir my, meer aangenaam vir die oog en duideliker vir die brein. Boonop maak so 'n notasie dit moontlik om die matrikse wat gebruik word gerieflik op die koördinaat-asse van 'n tweedimensionele beeld te projekteer.
Nou oor pixels, kleur en vertoon. Die StretchDIBits-funksie (Header: windows.h; Library: gdi32.lib) word vir uitvoer gebruik. Onder andere word die volgende na hierdie funksie oorgedra: die toestel waarop die prent vertoon word (in my geval is dit die Windows-konsole), die koördinate van die begin van die vertoon van die prent, die breedte/hoogte daarvan en die prent self in die vorm van 'n bitmap (bitmap), verteenwoordig deur 'n verskeidenheid grepe. Bitmap as 'n verskeidenheid grepe!
Die StretchDIBits() funksie by die werk:
// screen output for game field
StretchDIBits(
deviceContext,
OFFSET_LEFT, OFFSET_TOP,
PMATRIX_WIDTH, PMATRIX_HEIGHT,
0, 0,
PMATRIX_WIDTH, PMATRIX_HEIGHT,
m_p_bitmapMemory, &bitmapInfo,
DIB_RGB_COLORS,
SRCCOPY
);Geheue word vooraf vir hierdie bitmap toegewys deur die VirtualAlloc()-funksie te gebruik. Dit wil sê, die vereiste aantal grepe word gereserveer om inligting oor alle pixels te stoor, wat dan op die skerm vertoon sal word.
Skep 'n m_p_bitmapMemory bitmap:
// create bitmap
int bitmapMemorySize = (PMATRIX_WIDTH * PMATRIX_HEIGHT) * BYTES_PER_PIXEL;
void* m_p_bitmapMemory = VirtualAlloc(0, bitmapMemorySize, MEM_COMMIT, PAGE_READWRITE);Rofweg gesproke bestaan 'n bitmap uit 'n stel pixels. Elke vier grepe in die skikking is 'n RGB-pixel. Een greep per rooi waarde, een greep per groen waarde (G), en een greep per blou kleur (B). Boonop is daar een greep per inkeping. Hierdie drie kleure - Rooi / Groen / Blou (RGB) - word in verskillende verhoudings met mekaar gemeng - en die resulterende pixelkleur word verkry.
Nou word elke reghoek, of spelvoorwerp, weereens deur 'n getallematriks voorgestel. Al hierdie spelvoorwerpe word in 'n versameling geplaas. En dan word hulle op die speelveld geplaas, wat een groot numeriese matriks vorm. Ek het elke nommer in die matriks na 'n spesifieke kleur gekarteer. Byvoorbeeld, die nommer 8 is blou, die nommer 9 is geel, die nommer 10 is donkergrys, ensovoorts. Ons kan dus sê dat ons 'n matriks van die speelveld het, waar elke nommer 'n soort kleur is.
So, ons het 'n numeriese matriks van die hele speelveld aan die een kant en 'n bitmap om die beeld te vertoon aan die ander kant. Tot dusver is die bitmap "leeg" - dit het nog nie inligting oor die pixels van die verlangde kleur nie. Dit beteken dat die laaste stap die bitmap sal vul met inligting oor elke pixel gebaseer op die numeriese matriks van die speelveld. 'n Illustratiewe voorbeeld van so 'n transformasie is in die prent hieronder.
'n Voorbeeld van die vul van 'n bitmap (Pixel matriks) met inligting gebaseer op die numeriese matriks (Digitale matriks) van die speelveld (kleurindekse stem nie ooreen met die indekse in die spel nie)
Ek sal ook 'n stukkie regte kode uit die speletjie aanbied. Die veranderlike kleurindeks by elke iterasie van die lus word 'n waarde (kleurindeks) van die numeriese matriks van die speelveld (mainDigitalMatrix) toegeken. Dan word die kleur self geskryf na die kleurveranderlike gebaseer op die indeks. Verder word die gevolglike kleur verdeel in die verhouding van rooi, groen en blou (RGB). En saam met die inspringing (pixelPadding) word hierdie inligting oor en oor na die pixel geskryf, wat 'n kleurbeeld in die bitmap vorm.
Die kode gebruik wysers en bitsgewyse bewerkings, wat moeilik kan wees om te verstaan. Ek raai jou dus aan om iewers apart te lees hoe sulke strukture werk.
Vul 'n bitkaart met inligting gebaseer op die numeriese matriks van die speelveld:
// set pixel map variables
int colorIndex;
COLORREF color;
int pitch;
uint8_t* p_row;
// arrange pixels for game field
pitch = PMATRIX_WIDTH * BYTES_PER_PIXEL; // row size in bytes
p_row = (uint8_t*)m_p_bitmapMemory; //cast to uint8 for valid pointer arithmetic
(to add by 1 byte (8 bits) at a time)
for (int y = 0; y < PMATRIX_HEIGHT; ++y)
{
uint32_t* p_pixel = (uint32_t*)p_row;
for (int x = 0; x < PMATRIX_WIDTH; ++x)
{
colorIndex = mainDigitalMatrix[y * PMATRIX_WIDTH + x];
color = Utils::GetColor(colorIndex);
uint8_t blue = GetBValue(color);
uint8_t green = GetGValue(color);
uint8_t red = GetRValue(color);
uint8_t pixelPadding = 0;
*p_pixel = ((pixelPadding << 24) | (red << 16) | (green << 8) | blue);
++p_pixel;
}
p_row += pitch;
}Volgens die metode hierbo beskryf word een prentjie (raam) in die Crazy Tanks-speletjie gevorm en op die skerm vertoon in die Draw()-funksie. Na die registrasie van toetsaanslagen in die Input()-funksie en hul daaropvolgende verwerking in die Logic()-funksie, word 'n nuwe prentjie (raam) gevorm. Spelvoorwerpe kan weliswaar reeds 'n ander posisie op die speelveld hê en word gevolglik op 'n ander plek geteken. Dit is hoe animasie (beweging) gebeur.
In teorie (as jy niks vergeet het nie), is al wat jy nodig het om die spellus van die eerste speletjie (“Snake”) en die stelsel vir die vertoon van pixels op die skerm van die tweede speletjie (“Tanks”) te verstaan. van jou 2D-speletjies vir Windows. Geluidloos! 😉 Die res van die dele is net 'n vlugvoetigheid.
Natuurlik is die speletjie "Tanks" baie ingewikkelder ontwerp as die "Slang". Ek het reeds die C++-taal gebruik, dit wil sê, ek het verskillende spelvoorwerpe met klasse beskryf. Ek het my eie versameling geskep - jy kan die kode in headers/Box.h sien. Terloops, die versameling het heel waarskynlik 'n geheuelek. Gebruikte wysers. Met geheue gewerk. Ek moet sê die boek het my baie gehelp. Begin C++ deur spelprogrammering. Dit is 'n goeie begin vir beginners in C++. Dit is klein, interessant en goed georganiseer.
Dit het ongeveer ses maande geneem om hierdie speletjie te ontwikkel. Ek het hoofsaaklik tydens middagete en versnaperinge by die werk geskryf. Hy het in die kantoorkombuis gesit, op kos getrap en kode geskryf. Of by die huis vir aandete. So ek het sulke "kombuisoorloë" gekry. Soos altyd het ek aktief 'n notaboek gebruik, en al die konseptuele dinge is daarin gebore.
Aan die einde van die praktiese deel sal ek 'n paar skanderings van my notaboek uithaal. Om te wys wat ek presies skryf, teken, tel, ontwerp...
Tenkbeeldontwerp. En die definisie van hoeveel pixels elke tenk op die skerm moet beset
Berekening van die algoritme en formules vir die rotasie van die tenk om sy as
Diagram van my versameling (die een met die geheuelek, heel waarskynlik). Die versameling word as 'n gekoppelde lys geskep
En dit is futiele pogings om kunsmatige intelligensie in die spel te skroef
teorie
"Selfs 'n reis van duisend myl begin met die eerste stap" (Antieke Chinese wysheid)
Kom ons beweeg van praktyk na teorie! Hoe kry jy tyd vir jou stokperdjie?
- Bepaal wat jy regtig wil hê (ja, dit is die moeilikste).
- Stel prioriteite.
- Offer alles "oorbodig" op ter wille van hoër prioriteite.
- Beweeg elke dag na jou doelwitte.
- Moenie verwag dat daar twee of drie uur vrye tyd vir 'n stokperdjie sal wees nie.
Aan die een kant moet jy bepaal wat jy wil hê en prioritiseer. Aan die ander kant is dit moontlik om sommige gevalle / projekte te laat vaar ten gunste van hierdie prioriteite. Met ander woorde, jy sal alles “oorbodig” moet opoffer. Ek het iewers gehoor dat daar in die lewe 'n maksimum van drie hoofaktiwiteite moet wees. Dan sal jy hulle op die beste moontlike manier kan hanteer. En bykomende projekte/aanwysings sal corny begin oorlaai. Maar dit is alles, waarskynlik, subjektief en individueel.
Daar is 'n sekere goue reël: moet nooit 'n 0%-dag hê nie! Ek het daarvan geleer in 'n artikel deur 'n indie-ontwikkelaar. As jy aan 'n projek werk, doen dan elke dag iets daaraan. En dit maak nie saak hoeveel jy verdien nie. Skryf een woord of een reël kode, kyk na een tutoriaalvideo, of slaan een spyker in die bord—doen net iets. Die moeilikste deel is om te begin. Sodra jy begin het, sal jy waarskynlik 'n bietjie meer doen as wat jy wou. So jy sal voortdurend na jou doelwit beweeg en, glo my, baie vinnig. Die hoofrem op alle dinge is immers uitstel.
En dit is belangrik om te onthou dat jy nie die gratis "saagsels" van tyd in 5, 10, 15 minute moet onderskat en ignoreer nie, wag vir 'n paar groot "logs" wat 'n uur of twee duur. Staan jy in die ry? Dink aan iets vir jou projek. Gaan jy die roltrap op? Skryf iets in 'n notaboek neer. Eet jy op die bus? Goed, lees 'n artikel. Gebruik elke geleentheid. Hou op om katte en honde op YouTube te kyk! Moenie met jou brein mors nie!
En die laaste. As u, nadat u hierdie artikel gelees het, gehou het van die idee om speletjies te skep sonder om speletjie-enjins te gebruik, onthou dan die naam Casey Muratori. Hierdie ou het . In die afdeling "kyk -> VORIGE EPISODES" sal jy wonderlike gratis video-tutoriale vind oor hoe om 'n professionele speletjie van nuuts af te skep. Jy leer dalk meer in vyf Intro tot C vir Windows-lesse as in vyf jaar se studie aan die universiteit (iemand het hieroor geskryf in die kommentaar onder die video).
Casey verduidelik ook dat deur jou eie speletjie-enjin te ontwikkel, jy 'n beter begrip van enige bestaande enjins sal hê. In die wêreld van raamwerke, waar almal probeer outomatiseer, sal jy leer hoe om te skep, nie te gebruik nie. Verstaan die aard van rekenaars. En jy sal ook 'n baie meer intelligente en volwasse programmeerder word - 'n pro.
Sterkte op jou gekose pad! En kom ons maak die wêreld meer professioneel.
Author: , DevOps
Bron: will.com