DevOps C++ és "konyha háborúk", avagy Hogyan kezdtem el evés közben játékokat írni

"Tudom, hogy nem tudok semmit." Szókratész

Kinek: informatikusoknak, akik nem törődnek az összes fejlesztővel, és játszani akarnak a játékaikkal!

Miről: arról, hogyan kezdj el játékokat írni C/C++ nyelven, ha hirtelen szükséged van rá!

Miért érdemes ezt olvasni: Az alkalmazásfejlesztés nem az én szakterületem, de igyekszem minden héten kódolni. Mert szeretem a játékokat!

Helló az én nevem Andrey Grankin, DevOps vagyok a Luxoftnál. Az alkalmazásfejlesztés nem a szakterületem, de igyekszem minden héten kódolni. Mert szeretem a játékokat!

A számítógépes játékipar hatalmas, a pletykák szerint még a mai filmiparnál is nagyobb. A játékokat a számítógépek hajnala óta írják, modern mércével mérve összetett és alapvető fejlesztési módszerekkel. Idővel megjelentek a már programozott grafikával, fizikával és hanggal rendelkező játékmotorok. Lehetővé teszik, hogy magának a játéknak a fejlesztésére összpontosítson, és ne aggódjon az alapja miatt. De velük együtt, a motorokkal együtt a fejlesztők „megvakulnak” és leépülnek. Maga a játékok gyártása is futószalagra kerül. És a termékek mennyisége kezd érvényesülni a minőségével szemben.

Ugyanakkor, amikor mások játékait játszunk, folyamatosan korlátoznak bennünket a helyszínek, a cselekmény, a karakterek és a játék mechanikája, amit mások találtak ki. Szóval rájöttem, hogy...

... eljött az idő, hogy megteremtsem a saját világomat, csak nekem van alárendelve. Világok, ahol én vagyok az Atya, a Fiú és a Szentlélek!

És őszintén hiszem, hogy ha megírod a saját játékmotorodat és azon játszol, akkor le tudod venni a cipődet, letörölni az ablakokat és frissíteni a kabinodat, így tapasztaltabb és teljesebb programozó leszel.

Ebben a cikkben megpróbálom elmondani, hogyan kezdtem el kis játékokat írni C/C++ nyelven, milyen a fejlesztési folyamat, és hol találok időt egy hobbira egy mozgalmas környezetben. Szubjektív, és az egyéni indulás folyamatát írja le. Anyag a tudatlanságról és a hitről, a pillanatnyi világról alkotott személyes képemről. Más szóval: "Az adminisztráció nem felelős az Ön személyes agyáért!"

Gyakorlat

"A tudás gyakorlás nélkül haszontalan, a gyakorlat tudás nélkül veszélyes." Konfucius

A füzetem az életem!

Tehát a gyakorlatban azt mondhatom, hogy számomra minden a jegyzettömbbel kezdődik. Nemcsak a napi feladataimat írom oda, hanem rajzolok, programozok, folyamatábrákot tervezek és feladatokat oldok meg, beleértve a matematikaiakat is. Mindig használjon jegyzettömböt, és csak ceruzával írjon. Tiszta, kényelmes és megbízható, IMHO.

A (már megtelt) füzetem. Így néz ki. Tartalmaz mindennapi feladatokat, ötleteket, rajzokat, diagramokat, megoldásokat, fekete könyvelést, kódot és így tovább

Ebben a szakaszban három projektet sikerült teljesítenem (ez a „teljesség” értelmezése szerint értendő, mert bármely termék viszonylag végtelenül fejleszthető).

• 0. projekt: Ez egy 3D Architect Demo jelenet, amely C# nyelven íródott a Unity játékmotor segítségével. MacOS és Windows platformokhoz.
• 1. játék: Simple Snake (mindenki „Snake” néven ismert) konzoljáték Windows-ra. C-ben írva.
• 2. játék: Crazy Tanks konzoljáték (mindenki „Tanksként” ismert), C++ nyelven (osztályok használatával) és Windowsra is íródott.

Projekt 0. Építész bemutató

• Felület: Windows (Windows 7, 10), Mac OS (OS X El Capitan v. 10.11.6)
• Nyelv: C#
• Játék motor: Egység
• Ihlet: Darrin Lile
• Adattár: GitHub

3D Scene Architect bemutató

Az első projektet nem C/C++, hanem C# nyelven valósították meg a Unity játékmotor segítségével. Ez a motor nem volt olyan igényes a hardverre, mint Unreal Engine, és egyszerűbbnek tűnt a telepítés és a használat is. Más motorokat nem vettem figyelembe.

A Unityben nem a játék fejlesztése volt a célom. 3D-s jelenetet akartam létrehozni valamilyen karakterrel. Neki, vagy inkább Neki (a lányt mintáztam, akibe szerelmes voltam =) mozognia kellett, és kapcsolatba kellett lépnie a körülötte lévő világgal. Csak az volt a fontos, hogy megértsük, mi az a Unity, mi a fejlesztési folyamat, és mennyi erőfeszítést igényel valami létrehozása. Így született meg az Architect Demo projekt (a nevet szinte a semmiből találták ki). A programozás, modellezés, animáció, textúrázás valószínűleg két hónapig tartott a napi munkámból.

A YouTube-on lévő oktatóvideókkal kezdtem a 3D modellek létrehozásáról keverőgép. A Blender egy kiváló ingyenes eszköz a 3D modellezéshez (és még sok máshoz), amely nem igényel telepítést. És itt egy döbbenet várt rám... Kiderült, hogy a modellezés, az animáció, a textúra óriási külön témák, amelyekről lehet könyveket írni. Ez különösen igaz a karakterekre. Az ujjak, fogak, szemek és más testrészek modellezéséhez anatómiai ismeretekre lesz szüksége. Hogyan épülnek fel az arcizmok? Hogyan mozognak az emberek? Csontokat kellett „beszúrnom” minden karba, lábba, ujjakba, ujjak falángjaiba!

Modellezze a kulcscsontokat és a további karcsontokat, hogy az animáció természetesnek tűnjön. Az ilyen leckék után rájössz, mennyi munkát végeznek az animációs filmek készítői csupán azért, hogy 30 másodperces videót készítsenek. De a 3D-s filmek órákig bírják! Aztán kilépünk a mozikból, és valami ilyesmit mondunk: „Ez egy szar rajzfilm/film! Lehetett volna jobban is..." Bolondok!

És még egy dolog a programozással kapcsolatban ebben a projektben. Mint kiderült, számomra a matematikai rész volt a legérdekesebb. Ha lefuttatod a jelenetet (link a repositoryra a projekt leírásában), észre fogod venni, hogy a kamera egy gömbben forog a lány karakter körül. A kamera ilyen elforgatásának programozásához először ki kellett számítanom a pozíciópont koordinátáit a körön (2D), majd a gömbön (3D). Az a vicces, hogy az iskolában utáltam a matematikát, és C-mínuszossal tudtam. Részben valószínűleg azért, mert az iskolában egyszerűen nem magyarázzák el, hogyan a pokolban alkalmazzák ezt a matematikát az életben. De ha megszállott vagy a céloddal, az álmoddal, az elméd kitisztul és megnyílik! És elkezded izgalmas kalandként érzékelni a nehéz feladatokat. És akkor azt gondolja: "Nos, miért nem tudta megmondani a *kedvenc* matematikusa, hogy hol lehet ezeket a képleteket normálisan alkalmazni?"

Képletek kiszámítása egy körön és egy gömbön lévő pont koordinátáinak kiszámításához (a jegyzetfüzetemből)

1. játék: Simple Snake

• Felület: Windows (Windows 7, 10 rendszeren tesztelve)
• Nyelv: Azt hiszem, tiszta C-ben írtam
• Játék motor: Windows konzol
• Ihlet: javidx9
• Adattár: GitHub

Egyszerű Snake játék

A 3D-s jelenet nem játék. Ezenkívül a 3D objektumok (különösen a karakterek) modellezése és animálása időigényes és nehéz feladat. A Unityvel való játék után jött a felismerés, hogy folytatnom kell, vagy inkább az alapoktól kell kezdenem. Valami egyszerű és gyors, de ugyanakkor globális, hogy megértsük a játékok szerkezetét.

Mi az egyszerű és gyors? Így van, konzol és 2D. Pontosabban még a konzolt és a szimbólumokat is. Ismét az interneten kerestem ihletet (általában úgy gondolom, hogy az Internet a XNUMX. század legforradalmibb és legveszélyesebb találmánya). Előástam egy videót egy programozóról, aki Tetris konzolt készített. És az ő játékához hasonlóan úgy döntöttem, hogy készítek egy „kígyót”. A videóból két alapvető dolgot tudtam meg - a játékhurokról (három alapvető funkcióval/résszel) és a pufferre történő kimenetről.

A játékhurok valahogy így nézhet ki:

int main()
   {
      Setup();
      // a game loop
      while (!quit)
      {
          Input();
          Logic();
          Draw();
          Sleep(gameSpeed);  // game timing
      }
      return 0;
   }

A kód egyszerre mutatja be a teljes main() függvényt. A játékciklus pedig a megfelelő megjegyzés után kezdődik. A ciklusban három alapvető funkció található: Input(), Logic(), Draw(). Először bemeneti adatok Input (főleg billentyűleütések vezérlése), majd a bevitt adatok feldolgozása Logic, majd kimenet a képernyőre - Draw. És így minden képkockán. Így jön létre az animáció. Olyan, mint a rajzfilmekben. Jellemzően a bevitt adatok feldolgozása veszi igénybe a legtöbb időt, és tudtommal ez határozza meg a játék képkocka sebességét. De itt a Logic() függvény nagyon gyorsan lefut. Ezért a képsebességet a Sleep() funkcióval kell szabályoznia a gameSpeed ​​​​paraméterrel, amely meghatározza ezt a sebességet.

Játék ciklus. „Kígyó” programozása a jegyzettömbben

Ha karakter alapú konzoljátékot fejleszt, akkor nem fog tudni adatokat kiadni a képernyőre a szokásos „cout” stream kimenettel – ez nagyon lassú. Ezért a kimenetet a képernyőpufferbe kell küldeni. Ez sokkal gyorsabb, és a játék zökkenőmentesen fog futni. Őszintén szólva nem egészen értem, mi az a képernyőpuffer, és hogyan működik. De adok itt egy példakódot, és talán valaki tisztázza a helyzetet a megjegyzésekben.

Képernyőpuffer beszerzése (úgymond):

// create screen buffer for drawings
   HANDLE hConsole = CreateConsoleScreenBuffer(GENERIC_READ | GENERIC_WRITE, 0,
 							   NULL, CONSOLE_TEXTMODE_BUFFER, NULL);
   DWORD dwBytesWritten = 0;
   SetConsoleActiveScreenBuffer(hConsole);

Egy bizonyos karakterlánc scoreLine (pontszámmegjelenítési sor) közvetlen megjelenítése:

// draw the score
   WriteConsoleOutputCharacter(hConsole, scoreLine, GAME_WIDTH, {2,3}, &dwBytesWritten);

Elméletileg nincs semmi bonyolult ebben a játékban, szerintem ez egy jó belépő szintű példa. A kód egy fájlba van írva, és több függvényben van formázva. Nincs osztály, nincs örökség. A játék forráskódjában mindent megtekinthet, ha felkeresi a GitHubon található tárolót.

Játék 2. Őrült tankok

• Felület: Windows (Windows 7, 10 rendszeren tesztelve)
• Nyelv: C + +
• Játék motor: Windows konzol
• Ihlet: könyv C++ kezdete játékprogramozáson keresztül
• Adattár: GitHub

Játék Crazy Tanks

A karakterek kinyomtatása a konzolra valószínűleg a legegyszerűbb dolog, amit játékká alakíthatsz. Ekkor azonban megjelenik egy probléma: a szimbólumok különböző magasságúak és szélességűek (a magasság nagyobb, mint a szélesség). Így minden aránytalannak tűnik, és a lefelé vagy felfelé mozgás sokkal gyorsabbnak tűnik, mint a balra vagy jobbra való mozgás. Ez a hatás nagyon észrevehető a Snake-ben (1. játék). A „tankoknak” (2. játék) nincs meg ez a hátránya, mivel ott a kimenet a képernyő pixeleinek különböző színűre festésével szerveződik. Mondhatni renderelőt írtam. Igaz, ez egy kicsit bonyolultabb, bár sokkal érdekesebb.

Ennél a játéknál elég lesz leírni a pixelek képernyőn való megjelenítésére szolgáló rendszeremet. Ezt tartom a játék fő részének. És minden mást magad is kitalálhatsz.

Tehát amit a képernyőn lát, az csak mozgó, többszínű téglalapok halmaza.

Téglalapok halmaza

Minden téglalapot számokkal töltött mátrix ábrázol. Egyébként kiemelhetek egy érdekes árnyalatot - a játékban minden mátrix egydimenziós tömbként van programozva. Nem kétdimenziós, hanem egydimenziós! Az egydimenziós tömbök sokkal könnyebben és gyorsabban használhatók.

Példa egy játék tankmátrixra

A játék tankmátrixának egydimenziós tömbként való ábrázolása

Vizuálisabb példa a mátrix egydimenziós tömbként való megjelenítésére

De a tömb elemeihez való hozzáférés kettős hurokban történik, mintha nem egydimenziós, hanem kétdimenziós tömbről lenne szó. Ez azért történik, mert még mindig mátrixokkal dolgozunk.

Egydimenziós tömb bejárása kettős hurokban. Y - sorazonosító, X - oszlopazonosító

Figyelem: a szokásos i, j mátrix azonosítók helyett az x és y azonosítókat használom. Nekem úgy tűnik, hogy így kellemesebb a szemnek, és érthetőbb az agy számára. Ezenkívül egy ilyen jelölés lehetővé teszi a használt mátrixok kényelmes kivetítését egy kétdimenziós kép koordinátatengelyeire.

Most a pixelekről, a színekről és a képernyőkimenetről. A kimenethez a StretchDIBits függvény szolgál (fejléc: windows.h; Library: gdi32.lib). Ez a funkció többek között a következőket kapja: az eszköz, amelyen a kép megjelenik (esetemben ez a Windows konzol), a képmegjelenítés kezdő koordinátái, szélessége/magassága és maga a kép a bittérkép formájában, amelyet egy bájttömb képvisel. Bitmap bájttömbként!

StretchDIBits() függvény működés közben:

// 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
               );

Ehhez a bittérképhez a memória előre le van foglalva a VirtualAlloc() függvény segítségével. Vagyis a szükséges számú bájt le van foglalva az összes képpont információinak tárolására, amelyek ezután megjelennek a képernyőn.

Az m_p_bitmapMemory bittérkép létrehozása:

// create bitmap
   int bitmapMemorySize = (PMATRIX_WIDTH * PMATRIX_HEIGHT) * BYTES_PER_PIXEL;
   void* m_p_bitmapMemory = VirtualAlloc(0, bitmapMemorySize, MEM_COMMIT, PAGE_READWRITE);

Nagyjából elmondható, hogy a bittérkép pixelkészletből áll. A tömbben minden négy bájt egy RGB pixel. Piros színértékenként egy bájt, zöld színértékenként egy bájt (G) és kék színértékenként egy bájt (B). Plusz egy bájt maradt a behúzáshoz. Ez a három szín – Piros/Zöld/Kék (RGB) – különböző arányban keveredik egymással, hogy létrejöjjön a kapott pixelszín.

Most ismét minden téglalapot vagy játékobjektumot egy numerikus mátrix képvisel. Mindezek a játéktárgyak egy gyűjteményben vannak elhelyezve. Ezután a játéktérre kerülnek, és egyetlen nagy numerikus mátrixot alkotnak. A mátrix minden számához egy adott színt társítottam. Például a 8-as szám a kéknek, a 9-es a sárgának, a 10-es a sötétszürkének és így tovább. Így azt mondhatjuk, hogy van egy játékmező mátrixunk, ahol minden szám egy szín.

Tehát van egy numerikus mátrixunk az egyik oldalon a teljes játéktérről, a másik oldalon pedig egy bittérkép a kép megjelenítéséhez. Eddig a bitkép „üres” - még nem tartalmaz információt a kívánt szín képpontjairól. Ez azt jelenti, hogy az utolsó lépés a bittérkép feltöltése az egyes pixelekre vonatkozó információkkal a játékmező numerikus mátrixa alapján. Az alábbi képen egy ilyen átalakítás egyértelmű példája látható.

Példa egy bittérkép (Pixel mátrix) kitöltésére a játéktér digitális mátrixán alapuló információkkal (a színindexek nem egyeznek a játékban szereplő indexekkel)

Bemutatok egy darab valódi kódot is a játékból. A colorIndex változóhoz a hurok minden iterációjában hozzárendelnek egy értéket (színindexet) a játékmező numerikus mátrixából (mainDigitalMatrix). A színváltozó ezután magára a színre lesz beállítva az index alapján. A kapott színt ezután felosztják a vörös, zöld és kék arányra (RGB). És a pixelPadding-el együtt ezek az információk újra és újra beleíródnak a pixelbe, színes képet alkotva a bittérképen.

A kód mutatókat és bitenkénti műveleteket használ, amelyeket nehéz lehet megérteni. Ezért azt tanácsolom, hogy valahol külön olvassa el az ilyen szerkezetek működését.

A bittérkép kitöltése információval a játékmező numerikus mátrixa alapján:

// 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;
   }

A fent leírt módszer szerint a Crazy Tanks játékban egy kép (keret) készül és megjelenik a képernyőn a Draw() függvényben. Miután a billentyűleütéseket az Input() függvényben regisztráltuk, majd a Logic() függvényben feldolgoztuk, új kép (keret) jön létre. Igaz, a játéktárgyak már más pozícióban lehetnek a játéktéren, és ennek megfelelően más helyre kerülnek. Így történik az animáció (mozgás).

Elméletileg (ha nem felejtettem el semmit) az első játékból ("Snake") és a pixelek képernyőn való megjelenítésére szolgáló rendszer megértése a második játékból ("Tanks") elegendő ahhoz, hogy bármit írhasson. 2D-s játékai közül Windows alatt. Hangtalan! 😉 A többi rész csak egy röpke képzelet.

Természetesen a „Tanks” játék sokkal összetettebb, mint a „Snake”. Már használtam a C++ nyelvet, vagyis osztályokkal írtam le a különböző játékobjektumokat. Saját gyűjteményt készítettem - a kód megtekinthető a fejlécekben/Box.h. A gyűjteményben egyébként nagy valószínűséggel memóriaszivárgás van. Használt mutatók. Memóriával dolgozott. Azt kell mondanom, hogy a könyv sokat segített C++ kezdete játékprogramozáson keresztül. Ez egy nagyszerű kezdet a C++ kezdők számára. Kicsi, érdekes és jól szervezett.

Körülbelül hat hónapig tartott a játék fejlesztése. Főleg ebéd és munkahelyi uzsonna közben írtam. Az iroda konyhájában ült, ételt taposott, és kódot írt. Vagy otthon vacsoránál. Szóval ezekkel a „konyhaháborúkkal” kötöttem ki. Mint mindig, most is aktívan használtam egy notebookot, és minden fogalmi dolog benne született meg.

A gyakorlati rész befejezéséhez beolvasok néhányat a füzetemből. Hogy megmutassam, hogy pontosan mit írtam le, rajzoltam, számoltam, terveztem...

Tartályok képeinek tervezése. És annak meghatározása, hogy az egyes tartályoknak hány pixelt kell elfoglalniuk a képernyőn

A tartály tengelye körüli forgásának algoritmusának és képleteinek kiszámítása

Gyűjteményem sémája (amelyben valószínűleg memóriaszivárgás van). A gyűjtemény a Linked List típusnak megfelelően jön létre

És ezek hiábavaló kísérletek mesterséges intelligenciát csatolni a játékhoz

elmélet

„Még egy ezer mérföldes utazás is az első lépéssel kezdődik” (Ősi kínai bölcsesség)

Térjünk át a gyakorlatról az elméletre! Hogyan találjon időt a hobbira?

1. Határozza meg, mit akar valójában (sajnos, ez a legnehezebb rész).
2. Állítsa be a prioritásokat.
3. Feláldozzon mindent, ami „extra” a magasabb prioritások érdekében.
4. Minden nap haladj a célok felé.
5. Ne várja el, hogy két-három óra szabadidőt hobbira fordítson.

Egyrészt meg kell határoznia, hogy mit szeretne, és fontossági sorrendet kell felállítania. Másrészt lehetőség van egyes tevékenységek/projektek elhagyására e prioritások javára. Más szóval, mindent fel kell áldoznia, ami „extra”. Valahol hallottam, hogy az életben maximum három fő tevékenységnek kell lennie. Akkor képes lesz arra, hogy a legmagasabb minőségben végezze el őket. És a további projektek/irányok egyszerűen kezdenek túlterhelni. De mindez valószínűleg szubjektív és egyéni.

Van egy bizonyos aranyszabály: soha ne legyen 0%-os napod! Egy indie fejlesztő cikkéből értesültem róla. Ha egy projekten dolgozik, minden nap tegyen valamit. És nem számít, mennyit teszel. Írjon egy szót vagy egy sor kódot, nézzen meg egy oktatóvideót, vagy kalapáljon egy szöget egy táblába – csak csináljon valamit. A legnehezebb elkezdeni. Ha elkezdi, valószínűleg egy kicsit többet fog tenni, mint amennyit akart. Így folyamatosan és hidd el, nagyon gyorsan haladsz a célod felé. Hiszen mindennek a fő akadálya a halogatás.

És fontos észben tartani, hogy nem szabad alábecsülni és figyelmen kívül hagyni az 5, 10, 15 perces idő szabad „fűrészporát”, várjon néhány nagy „hasábra”, amely egy-két óráig tart. sorban állsz? Gondolj valamire a projektedhez. Mozgólépcsővel? Írj le valamit egy jegyzettömbbe. A buszon utazol? Remek, olvass el egy cikket. Használj ki minden lehetőséget. Hagyd abba a macskák és kutyák nézését a YouTube-on! Ne szennyezd be az agyadat!

És még egy utolsó dolog. Ha a cikk elolvasása után megtetszett az ötlet, hogy játékmotorok használata nélkül készítsen játékokat, akkor emlékezzen Casey Muratori nevére. Ennek a srácnak van weboldal. A „megtekintés -> ELŐZŐ EPISZÓDOK” részben csodálatos ingyenes oktatóvideókat találsz egy professzionális játék létrehozásához a semmiből. Az Intro to C for Windows öt leckéjében valószínűleg többet fog megtudni, mint öt év egyetemi tanulás alatt (valaki írt erről a videó alatti megjegyzésekben).

Casey azt is elmagyarázza, hogy saját játékmotorjának fejlesztésével jobban megértheti a meglévő motorokat. A keretrendszerek világában, ahol mindenki automatizálni próbál, megtanulsz létrehozni, nem pedig használni. Ön tisztában van a számítógépek természetével. És sokkal intelligensebb és érettebb programozó leszel - profi.

Sok sikert a választott úton! És tegyük professzionálisabbá a világot.

Szerző: Grankin Andrey, DevOps

Forrás: will.com