DevOps C++ kaj "kuirejaj militoj", aŭ Kiel mi komencis verki ludojn manĝante

"Mi scias, ke mi scias nenion" Sokrato

Por kiu: por IT-uloj, kiuj kraĉas sur ĉiujn programistojn kaj volas ludi siajn ludojn!

Pri kio: kiel komenci skribi ludojn en C/C++ se vi bezonas ĝin!

Kial vi devus legi ĉi tion: App-evoluo ne estas mia laborfako, sed mi provas kodigi ĉiun semajnon. Ĉar mi amas ludojn!

Saluton mia nomo estas Andrey Grankin, mi estas DevOps ĉe Luxoft. Aplika evoluo ne estas mia laborfako, sed mi provas kodigi ĉiun semajnon. Ĉar mi amas ludojn!

La industrio de komputilaj ludoj estas grandega, eĉ pli disvastigita hodiaŭ ol la filmindustrio. Ludoj estis verkitaj ekde la komenco de la evoluo de komputiloj, uzante, laŭ modernaj normoj, kompleksajn kaj bazajn evolumetodojn. Kun la tempo, ludmaŝinoj komencis aperi kun jam programitaj grafikoj, fiziko kaj sono. Ili permesas vin koncentriĝi pri la evoluo de la ludo mem kaj ne ĝeni pri ĝia fundamento. Sed kune kun ili, kun la motoroj, la programistoj "blindas" kaj degradas. La produktado mem de ludoj estas metita sur la transportilon. Kaj la kvanto de produktado komencas superi sian kvaliton.

Samtempe, kiam ni ludas aliulajn ludojn, ni estas konstante limigitaj de lokoj, intrigo, roluloj, ludmekanikoj, kiujn aliaj homoj elpensis. Do mi rimarkis, ke...

… estas tempo krei viajn proprajn mondojn, submetitajn nur al mi. Mondoj kie mi estas la Patro, kaj la Filo, kaj la Sankta Spirito!

Kaj mi sincere kredas, ke skribante vian propran ludmaŝinon kaj ludon sur ĝi, vi povos malfermi viajn okulojn, viŝi la fenestrojn kaj pumpi vian kajuton, fariĝante pli sperta kaj integra programisto.

En ĉi tiu artikolo mi provos rakonti al vi kiel mi komencis verki malgrandajn ludojn en C/C++, kio estas la evoluprocezo kaj kie mi trovas tempon por ŝatokupo en okupata medio. Ĝi estas subjektiva kaj priskribas la procezon de individua komenco. Materialo pri nescio kaj kredo, pri mia persona bildo de la mondo nuntempe. Alivorte, "La administracio ne respondecas pri viaj personaj cerboj!".

Praktiko

"Scio sen praktiko estas senutila, praktiko sen scio estas danĝera." Konfuceo

Mia kajero estas mia vivo!

Do, praktike, mi povas diri, ke ĉio por mi komenciĝas per kajero. Mi skribas ne nur miajn ĉiutagajn taskojn tie, sed ankaŭ desegnas, programas, desegnas fludiagramojn kaj solvas problemojn, inkluzive de matematikaj. Ĉiam uzu notblokon kaj skribu nur per krajono. Ĝi estas pura, komforta kaj fidinda, IMHO.

Mia (jam plenigita) kajero. Jen kiel ĝi aspektas. Ĝi enhavas ĉiutagajn taskojn, ideojn, desegnaĵojn, diagramojn, solvojn, nigran librotenadon, kodon ktp.

En ĉi tiu etapo, mi sukcesis plenumi tri projektojn (ĉi tio estas laŭ mia kompreno pri "finaĵo", ĉar ajna produkto povas esti evoluigita relative senfine).

• Projekto 0: ĉi tio estas Architect Demo 3D sceno skribita en C# uzante la Unity ludmaŝinon. Por platformoj macOS kaj Vindozo.
• Matĉo 1: konzoludo Simple Snake (konata de ĉiuj kiel "Serpento") por Vindozo. skribita en C.
• Matĉo 2: konzoludo Crazy Tanks (konata de ĉiuj kiel "Tankoj"), jam skribita en C++ (uzante klasojn) kaj ankaŭ sub Vindozo.

Projekto 0 Arkitekto Demo

• Platformo: Vindozo (Vindozo 7, 10), Mac OS (OS X El Capitan v. 10.11.6)
• Язык: C#
• Ludmotoro: unueco
• Inspiro: Darrin Lile
• Deponejo: GitHub

3D Scenarkitekto Demo

La unua projekto estis efektivigita ne en C/C++, sed en C# uzante la Unity ludmaŝinon. Ĉi tiu motoro ne estis tiel postulema pri aparataro kiel nereala Motoro, kaj ankaŭ ŝajnis al mi pli facile instalebla kaj uzebla. Mi ne konsideris aliajn motorojn.

La celo en Unity por mi estis ne evoluigi ian ludon. Mi volis krei 3D scenon kun ia karaktero. Li, aŭ pli ĝuste Ŝi (mi modeligis la knabinon, kiun mi enamiĝis =) devis moviĝi kaj interagi kun la ekstera mondo. Estis nur grave kompreni kio estas Unueco, kio estas la evoluprocezo, kaj kiom da penado necesas por krei ion. Tiel naskiĝis la Arkitekto Demo-projekto (la nomo estis elpensita preskaŭ el la babo). Programado, modelado, animacio, teksturado prenis min verŝajne du monatojn da ĉiutaga laboro.

Mi komencis kun lernilaj videoj en Jutubo pri kiel krei 3D-modelojn en Miksilo. Blender estas bonega senpaga ilo por 3D-modelado (kaj pli), kiu ne postulas instaladon. Kaj jen ŝoko atendis min... Montriĝas, ke modelado, animacio, teksturo estas grandegaj apartaj temoj, pri kiuj oni povas verki librojn. Ĉi tio estas precipe vera por la karakteroj. Por modeligi fingrojn, dentojn, okulojn kaj aliajn partojn de la korpo, vi bezonos scion pri anatomio. Kiel estas aranĝitaj la muskoloj de la vizaĝo? Kiel homoj moviĝas? Mi devis "enmeti" ostojn en ĉiun brakon, kruron, fingron, fingroartikojn!

Modelu la klaviklon, pliajn ostajn levilojn, por ke la animacio aspektu natura. Post tiaj lecionoj, vi rimarkas, kian grandegan laboron faras la kreintoj de viglaj filmoj, nur por krei 30 sekundojn da video. Sed 3D filmoj daŭras horojn! Kaj tiam ni eliras el la teatroj kaj diras ion kiel: “Ta, aĉa bildstrio/filmo! Ili povus fari pli bone...” Malsaĝuloj!

Kaj ankoraŭ unu afero pri programado en ĉi tiu projekto. Kiel evidentiĝis, la plej interesa parto por mi estis la matematika. Se vi prizorgas la scenon (ligilo al la deponejo en la projekta priskribo), vi rimarkos, ke la fotilo turniĝas ĉirkaŭ la knabina karaktero en sfero. Por programi tian kameraan rotacion, mi devis unue kalkuli la koordinatojn de la poziciopunkto sur la cirklo (2D), kaj poste sur la sfero (3D). La amuza afero estas, ke mi malamis matematikon en la lernejo kaj sciis ĝin kun minuso. Parte, verŝajne, ĉar en la lernejo oni simple ne klarigas al vi, kiel diable oni aplikas ĉi tiun matematikon en la vivo. Sed kiam vi estas obsedita de via celo, sonĝo, tiam la menso estas purigita, malkaŝita! Kaj vi komencas percepti kompleksajn taskojn kiel ekscitan aventuron. Kaj tiam vi pensas: "Nu, kial *kara* matematikisto normale ne povus diri kie ĉi tiuj formuloj povas esti klinitaj?".

Kalkulo de formuloj por kalkuli la koordinatojn de punkto sur cirklo kaj sur sfero (el mia kajero)

Ludo 1

• Platformo: Vindozo (provita sur Vindozo 7, 10)
• Язык: Mi pensas, ke ĝi estis skribita en pura C
• Ludmotoro: Vindoza konzolo
• Inspiro: javidx9
• Deponejo: GitHub

Simpla Serpenta ludo

La 3D sceno ne estas ludo. Krome, modeligi kaj vigligi 3D objektojn (precipe karakterojn) estas longa kaj malfacila. Post ludado kun Unity, mi konstatis, ke mi devas daŭrigi, aŭ prefere komenci, de la bazaĵoj. Io simpla kaj rapida, sed samtempe tutmonda, por kompreni la strukturon mem de ludoj.

Kaj kion ni havas simplan kaj rapidan? Ĝuste, konzolo kaj 2D. Pli precize, eĉ la konzolo kaj simboloj. Denove mi komencis serĉi inspiron en la Interreto (ĝenerale mi konsideras Interreton la plej revolucia kaj danĝera inventaĵo de la XNUMX-a jarcento). Mi elfosis videon de unu programisto kiu faris konzolon Tetris. Kaj en la simileco de sia ludo, li decidis tranĉi la "serpenton". De la video, mi lernis pri du fundamentaj aferoj - la ludbuklo (kun tri bazaj funkcioj / partoj) kaj eligo al la bufro.

La ludbuklo povus aspekti kiel ĉi tio:

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

La kodo prezentas la tutan funkcion main() samtempe. Kaj la ludciklo komenciĝas post la responda komento. Estas tri bazaj funkcioj en la buklo: Input(), Logic(), Draw(). Unue, enigo datumoj Enigo (ĉefe kontrolo de klavopremoj), tiam prilaborado la enmetitaj datumoj Logiko, tiam montrado sur la ekrano - Desegno. Kaj tiel ĉiu kadro. Animacio estas kreita tiamaniere. Estas kiel bildstrioj. Kutime prilabori la enigajn datumojn prenas la plej multe da tempo kaj, laŭ mia scio, determinas la framfrekvencon de la ludo. Sed ĉi tie la funkcio Logic() estas tre rapida. Tial, la framfrekvenco devas esti kontrolita per la funkcio Sleep() kun la parametro gameSpeed ​​​​, kiu determinas ĉi tiun indicon.

ludciklo. Serpenta programado en notbloko

Se vi disvolvas simbolan konzolludon, tiam montri datumojn sur la ekrano uzante la kutiman fluan eligon 'cout' ne funkcios - ĝi estas tre malrapida. Tial, la eligo devas esti efektivigita en la ekranbufro. Tiel pli rapide kaj la ludo funkcios sen problemoj. Verdire, mi ne tute komprenas kio estas ekranbufro kaj kiel ĝi funkcias. Sed mi donos kodan ekzemplon ĉi tie, kaj eble iu en la komentoj povos klarigi la situacion.

Akiro de la ekranbufro (se mi rajtas diri tion):

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

Rekta eligo al la ekrano de certa linio scoreLine (la linio por montri poentarojn):

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

En teorio, estas nenio komplika en ĉi tiu ludo, ŝajnas al mi bona ekzemplo de enirnivela ludo. La kodo estas skribita en unu dosiero kaj aranĝita en pluraj funkcioj. Neniuj klasoj, neniu heredo. Vi mem povas vidi ĉion en la fontkodo de la ludo irante al la deponejo sur GitHub.

Ludo 2 Frenezaj Tankoj

• Platformo: Vindozo (provita sur Vindozo 7, 10)
• Язык: C ++
• Ludmotoro: Vindoza konzolo
• Inspiro: libro Komencante C++ Per Luda Programado
• Deponejo: GitHub

Ludo de Frenezaj Tankoj

Presi signojn al la konzolo estas verŝajne la plej simpla afero, kiun vi povas transformi en ludon. Sed tiam aperas unu problemo: la karakteroj havas malsamajn altojn kaj larĝojn (la alteco estas pli granda ol la larĝo). Tiel, ĉio aspektos neproporcia, kaj moviĝi malsupren aŭ supren ŝajnos multe pli rapide ol moviĝi maldekstren aŭ dekstren. Ĉi tiu efiko estas tre rimarkebla en "Serpento" (Ludo 1). "Tankoj" (Ludo 2) ne havas tian malavantaĝon, ĉar la eligo tie estas organizita pentrante la ekranpikselojn kun malsamaj koloroj. Vi povus diri, ke mi skribis bildilon. Vere, ĉi tio jam estas iom pli komplika, kvankam multe pli interesa.

Por ĉi tiu ludo, sufiĉos priskribi mian sistemon por montri pikselojn sur la ekrano. Mi pensas, ke ĉi tio estas la ĉefa parto de la ludo. Kaj ĉion alian vi povas elpensi mem.

Do, kion vi vidas sur la ekrano, estas nur aro de moviĝantaj koloraj rektanguloj.

Rektangulo aro

Ĉiu rektangulo estas reprezentita per matrico plenigita kun nombroj. Cetere, mi povas reliefigi unu interesan nuancon - ĉiuj matricoj en la ludo estas programitaj kiel unudimensia tabelo. Ne dudimensia, sed unudimensia! Unudimensiaj tabeloj estas multe pli facile kaj pli rapide labori kun.

Ekzemplo de ludtanka matrico

Reprezentante la Matricon de Ludtanko kun Unu-Dimensia Aro

Pli ilustra ekzemplo de matrica reprezentado per unudimensia tabelo

Sed aliro al la elementoj de la tabelo okazas en duobla buklo, kvazaŭ ĝi estus ne unudimensia, sed dudimensia tabelo. Ĉi tio estas farita ĉar ni ankoraŭ laboras kun matricoj.

Trairante unudimensian tabelon en duobla buklo. Y estas la vica ID, X estas la kolumna ID

Bonvolu noti, ke anstataŭ la kutimaj matricaj identigiloj i, j, mi uzas la identigilojn x kaj y. Do, ŝajnas al mi, pli plaĉa al la okulo kaj pli klara al la cerbo. Krome, tia notacio ebligas oportune projekcii la uzatajn matricojn sur la koordinataksoj de dudimensia bildo.

Nun pri pikseloj, koloro kaj ekrano. La StretchDIBits funkcio (Header: windows.h; Biblioteko: gdi32.lib) estas uzata por eligo. Interalie, la sekvaj estas transdonitaj al ĉi tiu funkcio: la aparato sur kiu la bildo estas montrata (en mia kazo, ĉi tio estas la Vindoza konzolo), la koordinatoj de la komenco de montrado de la bildo, ĝia larĝo / alteco, kaj la bildo. sin en la formo de bitmapo (bitmapo), reprezentita per tabelo de bajtoj. Bitmapo kiel tabelo de bajtoj!

La StretchDIBits() funkcio ĉe laboro:

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

Memoro estas asignita anticipe por ĉi tiu bitmapo uzante la funkcion VirtualAlloc(). Tio estas, la bezonata nombro da bajtoj estas rezervita por stoki informojn pri ĉiuj pikseloj, kiuj tiam estos montrataj sur la ekrano.

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

Malglate parolante, bitmapo konsistas el aro de pikseloj. Ĉiuj kvar bajtoj en la tabelo estas RGB-pikselo. Unu bajto per ruĝa valoro, unu bajto per verda valoro (G), kaj unu bajto per blua koloro (B). Krome, estas unu bajto per streko. Ĉi tiuj tri koloroj - Ruĝa / Verda / Blua (RGB) - estas miksitaj unu kun la alia en malsamaj proporcioj - kaj la rezulta piksela koloro estas akirita.

Nun, denove, ĉiu rektangulo, aŭ ludobjekto, estas reprezentita per nombromatrico. Ĉiuj ĉi tiuj ludobjektoj estas metitaj en kolekton. Kaj tiam ili estas metitaj sur la ludkampon, formante unu grandan nombran matricon. Mi mapis ĉiun nombron en la matrico al specifa koloro. Ekzemple, la numero 8 estas blua, la numero 9 estas flava, la numero 10 estas malhelgriza, ktp. Tiel, ni povas diri ke ni havas matricon de la ludkampo, kie ĉiu nombro estas ia koloro.

Do, ni havas nombran matricon de la tuta ludkampo unuflanke kaj bitmapon por montri la bildon aliflanke. Ĝis nun, la bitmapo estas "malplena" - ĝi ankoraŭ ne havas informojn pri la pikseloj de la dezirata koloro. Ĉi tio signifas, ke la lasta paŝo estos plenigi la bitmapon kun informoj pri ĉiu pikselo bazita sur la nombra matrico de la ludkampo. Ilustra ekzemplo de tia transformo estas en la suba bildo.

Ekzemplo de plenigado de bitmapo (Pixel-matrico) kun informoj bazitaj sur la nombra matrico (Cifereca matrico) de la ludkampo (kolorindeksoj ne kongruas kun la indeksoj en la ludo)

Mi ankaŭ prezentos pecon de reala kodo de la ludo. La varia colorIndex ĉe ĉiu ripeto de la buklo ricevas valoron (kolorindekso) de la nombra matrico de la ludkampo (mainDigitalMatrix). Tiam la koloro mem estas skribita al la kolorvariablo bazita sur la indekso. Plue, la rezulta koloro estas dividita en la rilatumon de ruĝa, verda kaj blua (RGB). Kaj kune kun la indentaĵo (pixelPadding), ĉi tiu informo estas skribita al la pikselo denove kaj denove, formante kolorbildon en la bitmapo.

La kodo uzas montrilojn kaj bibitajn operaciojn, kiuj povas esti malfacile kompreneblaj. Do mi konsilas vin legi aparte ie, kiel funkcias tiaj strukturoj.

Plenigi bitmapon kun informoj bazitaj sur la nombra matrico de la ludkampo:

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

Laŭ la metodo priskribita supre, unu bildo (kadro) estas formita en la ludo Crazy Tanks kaj montrata sur la ekrano en la Draw() funkcio. Post registrado de klavopremoj en la funkcio Input() kaj ilia posta prilaborado en la funkcio Logic() , nova bildo (kadro) formiĝas. Vere, ludobjektoj eble jam havas malsaman pozicion sur la ludkampo kaj, sekve, estas desegnitaj en malsama loko. Tiel okazas animacio (movado).

En teorio (se vi nenion forgesis), kompreni la ludbuklon de la unua ludo ("Serpento") kaj la sistemon por montri pikselojn sur la ekrano de la dua ludo ("Tankoj") estas ĉio, kion vi bezonas por skribi ajnan. de viaj 2D-ludoj por Vindozo. Sensona! 😉 La ceteraj partoj estas nur fantazio.

Kompreneble, la ludo "Tankoj" estas desegnita multe pli komplika ol la "Serpento". Mi jam uzis la lingvon C++, tio estas, mi priskribis malsamajn ludobjektojn kun klasoj. Mi kreis mian propran kolekton - vi povas vidi la kodon en headers/Box.h. Cetere, la kolekto plej verŝajne havas memorfluon. Uzitaj montriloj. Laboris kun memoro. Mi devas diri, ke la libro multe helpis min. Komencante C++ Per Luda Programado. Ĉi tio estas bonega komenco por komencantoj en C++. Ĝi estas malgranda, interesa kaj bone organizita.

Daŭris ĉirkaŭ ses monatojn por disvolvi ĉi tiun ludon. Mi skribis ĉefe dum tagmanĝo kaj manĝetoj ĉe la laboro. Li sidis en la oficeja kuirejo, tretis manĝaĵon kaj skribis kodon. Aŭ hejme por vespermanĝi. Do mi ricevis tiajn "kuirejojn". Kiel ĉiam, mi aktive uzis kajeron, kaj ĉiuj konceptaĵoj naskiĝis en ĝi.

Fine de la praktika parto mi eltiros kelkajn skanaĵojn de mia kajero. Montri kion precize mi skribis, desegnis, nombris, desegnas...

Tanka bildo-dezajno. Kaj la difino de kiom da pikseloj ĉiu tanko devus okupi sur la ekrano

Kalkulo de la algoritmo kaj formuloj por la rotacio de la tanko ĉirkaŭ ĝia akso

Diagramo de mia kolekto (tiu kun la memorfluo, plej verŝajne). La kolekto estas kreita kiel Ligita Listo

Kaj ĉi tiuj estas vanaj provoj ŝraŭbi artefaritan inteligentecon en la ludon

Teorio

"Eĉ vojaĝo de mil mejloj komenciĝas per la unua paŝo" (Antikva ĉina saĝo)

Ni transiru de praktiko al teorio! Kiel vi trovas tempon por via ŝatokupo?

1. Determini kion vi vere volas (ve, ĉi tio estas la plej malfacila).
2. Fiksu prioritatojn.
3. Oferu ĉion "superfluan" pro pli altaj prioritatoj.
4. Movu al viaj celoj ĉiutage.
5. Ne atendu, ke estos du aŭ tri horoj da libera tempo por ŝatokupo.

Unuflanke, vi devas determini kion vi volas kaj prioritati. Aliflanke, eblas forlasi iujn kazojn/projektojn favore al ĉi tiuj prioritatoj. Alivorte, vi devos oferi ĉion "superfluan". Mi aŭdis ie, ke en la vivo estu maksimume tri ĉefaj agadoj. Tiam vi povos trakti ilin en la plej bona ebla maniero. Kaj aldonaj projektoj/direktoj komencos troŝarĝi kurzajn. Sed ĉi tio estas ĉio, verŝajne, subjektiva kaj individua.

Estas certa ora regulo: neniam havu 0% tagon! Mi eksciis pri ĝi en artikolo de sendependa programisto. Se vi laboras pri projekto, tiam faru ion pri ĝi ĉiutage. Kaj ne gravas kiom vi gajnas. Skribu unu vorton aŭ unu linion de kodo, spektu unu lernilon-videon aŭ martelu unu najlon en la tabulon—nur faru ion. La plej malfacila parto estas komenci. Post kiam vi komencos, vi verŝajne faros iom pli ol vi volis. Do vi konstante iros al via celo kaj, kredu min, tre rapide. Post ĉio, la ĉefa bremso por ĉiuj aferoj estas prokrastado.

Kaj gravas memori, ke vi ne devas subtaksi kaj ignori la senpagan "segpolvon" de tempo en 5, 10, 15 minutoj, atendu kelkajn grandajn "ŝtipojn" daŭrantajn unu aŭ du horojn. Ĉu vi staras en la vico? Pensu pri io por via projekto. Ĉu vi supreniras la rulŝtuparon? Skribu ion en kajeron. Ĉu vi manĝas en la buso? Bone, legu iun artikolon. Uzu ĉiun ŝancon. Ĉesu rigardi katojn kaj hundojn ĉe Jutubo! Ne fuŝu kun via cerbo!

Kaj la lasta. Se, leginte ĉi tiun artikolon, vi ŝatis la ideon krei ludojn sen uzi ludmotorojn, tiam memoru la nomon Casey Muratori. Ĉi tiu ulo havas retejo. En la sekcio "rigardo -> ANTAŬAJ EPISODOJ" vi trovos mirindajn senpagajn videolernilojn pri kiel krei profesian ludon de nulo. Vi povas lerni pli en kvin lecionoj de Enkonduko al C por Vindozo ol en kvinjara studado en la universitato (iu skribis pri tio en la komentoj sub la video).

Casey ankaŭ klarigas, ke disvolvante vian propran ludmaŝinon, vi havos pli bonan komprenon pri iuj ekzistantaj motoroj. En la mondo de kadroj, kie ĉiuj provas aŭtomatigi, vi lernos kiel krei, ne uzi. Komprenu la naturon mem de komputiloj. Kaj vi ankaŭ fariĝos multe pli inteligenta kaj matura programisto - profesiulo.

Bonŝancon sur via elektita vojo! Kaj ni faru la mondon pli profesia.

Aŭtoro: Grankin Andrey, DevOps

fonto: www.habr.com