DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean

"Badakit ezer ez dakidala" Sokrates

Norentzat: Garatzaile guztiei axola ez zaien eta beren jokoak jokatu nahi dituzten informatikarientzat!

Zeri buruz: C/C++-n jokoak idazten hasteko moduari buruz, bat-batean behar baduzu!

Zergatik irakurri behar duzu hau: Aplikazioen garapena ez da nire espezializazio arloa, baina astero saiatzen naiz kodetzen. Jolasak maite ditudalako!

Kaixo nire izena da Andrey Grankin, DevOps naiz Luxoft-en. Aplikazioen garapena ez da nire espezialitatea, baina astero saiatzen naiz kodetzen. Jolasak maite ditudalako!

Ordenagailuen jokoen industria izugarria da, gaur egungo zinemaren industria baino are handiagoa dela. Jokoak ordenagailuen sorreratik idatzi dira, estandar modernoen arabera, garapen-metodo konplexu eta oinarrizkoak erabiliz. Denborarekin, jada programatutako grafikoak, fisika eta soinua zuten joko-motorrak agertzen hasi ziren. Jokoa bera garatzen zentratu eta bere oinarriaz kezkatu gabe. Baina haiekin batera, motorrekin, garatzaileak "itsutu" egiten dira eta degradatzen dira. Jokoen ekoizpena bera zinta garraiatzailean jartzen da. Eta produktuen kantitatea bere kalitatearen gainetik nagusitzen hasten da.

Aldi berean, besteen jokoetara jokatzean, etengabe mugatzen gaitu beste pertsonek asmatu zituzten kokapenak, argumentuak, pertsonaiak eta joko mekanikak. Beraz, konturatu nintzen...

... nire munduak sortzeko garaia heldu da, nire menpekoak soilik. Ni Aita, Semea eta Espiritu Santua naizen munduak!

Eta zinez uste dut zure joko-motorra idatziz eta bertan jolastuz, oinetakoak kendu, leihoak garbitu eta kabina berritu ahal izango dituzula, programatzaile esperientziadun eta osatuagoa bihurtuz.

Artikulu honetan saiatuko naiz kontatzen nola hasi nintzen C/C++-n joko txikiak idazten, nolakoa den garapen-prozesua eta non aurkitzen dudan zaletasun baterako denbora lanpetuta dagoen ingurune batean. Subjektiboa da eta banakako hasiera baten prozesua deskribatzen du. Ezjakintasunari eta fedeari buruzko materiala, unean uneko munduaren irudi pertsonalari buruzkoa. Beste era batera esanda, "Administrazioa ez da zure garun pertsonalaren erantzule!"

Praktika

"Praktikarik gabeko ezagutzak ez du ezertarako balio, ezagutzarik gabeko praktikak arriskutsua da" Konfuzio

Nire koadernoa nire bizitza da!


Beraz, praktikan, esan dezaket niretzat dena koaderno batetik hasten dela. Bertan eguneroko zereginak idazten ez ezik, marraztu, programatu, fluxu-diagramak diseinatzen eta problemak ebazten ditut, matematikoak barne. Erabili beti koadernoa eta idatzi arkatz batekin soilik. Garbia, erosoa eta fidagarria da, IMHO.

DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean
Nire (dagoeneko) koadernoa. Hauxe da bere itxura. Eguneroko zereginak, ideiak, marrazkiak, eskemak, irtenbideak, kontabilitate beltza, kodea eta abar biltzen ditu

Etapa honetan, hiru proiektu burutzea lortu nuen (hau "osotasuna" ulertzen dut, edozein produktu nahiko amaigabe garatu daitekeelako).

  • 0. proiektua: Hau C#-n idatzitako 3D Architect Demo eszena bat da, Unity joko motorra erabiliz. MacOS eta Windows plataformetarako.
  • 1. jokoa: Simple Snake kontsola-jokoa (denok "Snake" izenez ezagutzen dena) Windows-erako. C-n idatzia.
  • 2. jokoa: Crazy Tanks kontsola-jokoa (denek "Tanks" izenez ezagutzen dena), C++-n idatzia (klaseak erabiliz) eta baita Windows-erako ere.

Proiektua 0. Arkitekto Demo

  • Plataforma: Windows (Windows 7, 10), Mac OS (OS X El Capitan v. 10.11.6)
  • Hizkuntza: C#
  • Joko motorra: Batasun
  • Inspirazioa: Darrin Lile
  • Biltegia: GitHub

DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean
3D Eszena Arkitektoaren Demo

Lehenengo proiektua ez zen C/C++-n inplementatu, C#-n baizik Unity joko-motorra erabiliz. Motor hau ez zen hardwarerako bezain zorrotza Unreal Engine, eta instalatzeko eta erabiltzeko errazagoa ere bazirudien. Ez nituen beste motorrik kontuan hartu.

Nire helburua Unity-n ez zen joko bat garatzea. Pertsonaia batzuekin 3D eszena bat sortu nahi nuen. Berak, edo hobeto esanda, Berak (nik maiteminduta nengoen neskaren eredua egin nuen =) mugitu eta inguruko munduarekin elkarreragin behar izan zuen. Unity zer den, garapen prozesua zein den eta zerbait sortzeko zenbat ahalegin behar den ulertzea baino ez zen garrantzitsua. Horrela sortu zen Architect Demo proiektua (izena ia ezerezetik asmatu zen). Programazioak, modelizazioak, animazioak, testuratzeak bi hilabeteko eguneroko lana behar izan zidaten.

YouTube-n 3D ereduak sortzeko tutorial bideoekin hasi nintzen Blender. Blender 3D modelatzeko (eta gehiago) doako tresna bikaina da, instalaziorik behar ez duena. Eta hemen shock bat itxaroten ninduen... Agertzen da modelizazioa, animazioa, testurizazioa liburuak idazteko gai ikaragarriak direla. Hau bereziki egia da pertsonaien kasuan. Hatzak, hortzak, begiak eta beste gorputz atal batzuk modelatzeko, anatomiaren ezagutza beharko duzu. Nola egituratzen dira aurpegiko muskuluak? Nola mugitzen da jendea? Beso, hanka, hatz, atzamarren falange bakoitzean hezurrak “sartu” behar izan ditut!

Modelatu lepa-hezurrak eta palanka-hezur osagarriak animazioa naturala izan dadin. Horrelako ikasgaien ondoren, konturatzen zara animaziozko filmen sortzaileek 30 segundoko bideoa sortzeko zenbat lan egiten duten. Baina 3D filmek orduak irauten dute! Eta gero zinema-aretoetatik irten eta honelako zerbait esaten dugu: “Hau marrazki bizidun/pelikula kaskarra da! Hobeto egin zezaketen..." Ergelak!

Eta beste gauza bat proiektu honetan programazioari dagokionez. Horrexegatik, niretzat interesgarriena matematika izan zen. Eszena exekutatzen baduzu (proiektuaren deskribapenean biltegira esteka), kamerak neska pertsonaiaren inguruan biratzen duela ohartuko zara esfera batean. Kameraren biraketa hori programatzeko, lehenik zirkuluan (2D) posizio puntuaren koordenatuak kalkulatu behar izan ditut, eta gero esferan (3D). Dibertigarria da eskolan matematikak gorroto nituela eta C minus batekin ezagutzen nuela. Neurri batean, ziurrenik, eskolan ez dizutelako besterik azaltzen matematika hori nola demontre aplikatzen den bizitzan. Baina zure helburuarekin, zure ametsarekin obsesionatuta zaudenean, zure burua argitu eta irekitzen da! Eta zeregin zailak abentura zirraragarri gisa hautematen hasten zara. Eta orduan pentsatzen duzu: "Beno, zergatik ez dizu zure *gogoko* matematikariak normalean esan formula hauek non aplika daitezkeen?"

DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean
Zirkulu bateko eta esfera bateko puntu baten koordenatuak kalkulatzeko formulen kalkulua (nire koadernotik)

Jokoa 1. Suge sinplea

  • Plataforma: Windows (Windows 7, 10-n probatua)
  • Hizkuntza: Uste dut C hutsez idatzi nuela
  • Joko motorra: Windows kontsola
  • Inspirazioa: javidx9
  • Biltegia: GitHub

DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean
Suge joko sinplea

3D eszena bat ez da joko bat. Gainera, 3D objektuak (batez ere pertsonaiak) modelatzea eta animatzea denbora asko eta zaila da. Unity-rekin jolastu ostean, oinarrietatik jarraitu behar nuela konturatu nintzen, edo hobeto esanda, hasi behar nuela. Zerbait sinple eta azkarra, baina aldi berean globala, jokoen egitura bera ulertzeko.

Zer da erraza eta azkarra? Hori bai, kontsola eta 2D. Zehatzago esanda, baita kontsola eta ikurrak ere. Berriz ere Interneten inspirazio bila joan nintzen (oro har, uste dut Internet dela XXI. mendeko asmakizunik iraultzaileena eta arriskutsuena). Tetris kontsola egin zuen programatzaile baten bideo bat atera nuen. Eta bere jokoaren antzera “suge” bat egitea erabaki nuen. Bideotik oinarrizko bi gauzari buruz ikasi nuen: jokoaren begizta (oinarrizko hiru funtzio/zatirekin) eta bufferra irteera.

Jokoaren begiztak honelako itxura izan dezake:

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

Kodeak main() funtzio osoa aurkezten du aldi berean. Eta jokoaren zikloa dagokion iruzkinaren ondoren hasten da. Oinarrizko hiru funtzio daude begiztan: Input(), Logic(), Draw(). Lehenik eta behin, sarrerako datuak Sarrera (batez ere tekla sakatzearen kontrola), ondoren sartutako datuak Logika prozesatzea, eta pantailara ateratzea - ​​Marraztu. Eta horrela fotograma guztietan. Horrela sortzen da animazioa. Marrazki bizidunetan bezala da. Normalean, sartutako datuak prozesatzeko denbora gehien hartzen du eta, nik dakidala, jokoaren fotograma-abiadura zehazten du. Baina hemen Logic() funtzioa oso azkar exekutatzen da. Hori dela eta, fotograma-abiadura kontrolatu behar duzu Sleep() funtzioa erabiliz, abiadura hori zehazten duen gameSpeed ​​​​parametroarekin.

DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean
Jolas-zikloa. "Suge" bat koaderno batean programatzea

Pertsonaietan oinarritutako kontsola-joko bat garatzen ari bazara, ezingo dituzu pantailara datuak atera "cout" korrontearen irteera arrunta erabiliz - oso motela da. Beraz, irteera pantailako bufferera bidali behar da. Hau askoz azkarragoa da eta jokoa akatsik gabe abiaraziko da. Egia esateko, ez dut ondo ulertzen zer den pantaila-buffer bat eta nola funtzionatzen duen. Baina kode adibide bat emango dut hemen, eta agian norbaitek egoera argitu dezake iruzkinetan.

Pantaila-buffer bat lortzea (nolabait esateko):

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

Kate jakin baten bistaratzea zuzena puntuazio lerroa (puntuazioa bistaratzeko lerroa):

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

Teorian, ez dago ezer konplikaturik joko honetan; hasierako adibide ona dela uste dut. Kodea fitxategi batean idatzita dago eta hainbat funtziotan formateatzen da. Klaserik ez, herentziarik gabe. Zuk zeuk ikus dezakezu dena jokoaren iturburu-kodean GitHub-eko biltegira joanez.

Jokoa 2. Crazy Tanks

DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean
Game Crazy Tanks

Karaktereak kontsolan inprimatzea joko batean bihur dezakezun gauzarik errazena da. Baina orduan arazo bat agertzen da: sinboloek altuera eta zabalera desberdinak dituzte (altuera zabalera baino handiagoa da). Horrela, dena neurriz kanpo ikusiko da, eta behera edo gora mugitzea ezkerrera edo eskuinera mugitzea baino askoz azkarrago agertuko da. Efektu hau oso nabaria da Snake-n (1. jokoa). "Tankek" (2. jokoa) ez dute eragozpen hori, horko irteera pantailako pixelak kolore ezberdinekin margotuz antolatzen baita. Errendatzaile bat idatzi dudala esan liteke. Egia da, hau pixka bat konplexuagoa da, nahiz eta askoz interesgarriagoa.

Joko honetarako, nahikoa izango da pantailan pixelak bistaratzeko nire sistema deskribatzea. Hau jokoaren zati nagusitzat jotzen dut. Eta zuk zeuk asma dezakezu beste guztia.

Beraz, pantailan ikusten duzuna kolore anitzeko laukizuzen mugikor multzo bat besterik ez da.

DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean
Laukizuzen multzoa

Laukizuzen bakoitza zenbakiz betetako matrize baten bidez irudikatzen da. Bide batez, ñabardura interesgarri bat nabarmendu dezaket: jokoko matrize guztiak dimentsio bakarreko array gisa programatzen dira. Ez bi dimentsiokoak, baizik eta dimentsio bakarrekoak! Dimentsio bakarreko matrizeak askoz errazagoak eta azkarragoak dira lan egiteko.

DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean
Joko tankearen matrizearen adibidea

DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean
Jokoaren tankearen matrizearen irudikapena dimentsio bakarreko array gisa

DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean
Matrize bat dimentsio bakarreko array gisa irudikatzeko adibide bisualagoa

Baina arrayko elementuetarako sarbidea begizta bikoitzean gertatzen da, dimentsio bakarreko array bat ez balitz bezala, bi dimentsioko bat baizik. Hau oraindik matrizeekin lan egiten dugulako egiten da.

DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean
Dimentsio bakarreko array bat begizta bikoitzean zeharkatzea. Y - errenkaden identifikatzailea, X - zutabearen identifikatzailea

Kontuan izan: i, j ohiko matrize-identifikatzaileen ordez, x eta y identifikatzaileak erabiltzen ditut. Horrela, iruditzen zait, begietarako atseginagoa eta garunarentzat ulergarriagoa dela. Gainera, halako notazio batek bi dimentsioko irudi baten koordenatu-ardatzetan erabilitako matrizeak eroso proiektatzea ahalbidetzen du.

Orain pixelei, koloreari eta pantailaren irteerari buruz. StretchDIBits funtzioa erabiltzen da irteerarako (Goiburua: windows.h; Liburutegia: gdi32.lib). Funtzio honek, besteak beste, honako hauek jasotzen ditu: irudia bistaratzen den gailua (nire kasuan, Windows kontsola da), irudiaren pantailaren hasierako koordenatuak, bere zabalera/altuera eta irudia bera. bit-mapa baten forma, byte-matrize batek adierazten duena. Bitmap byte-matrize gisa!

StretchDIBits() funtzioa martxan:

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

Bitmap honetarako memoria aldez aurretik esleitzen da VirtualAlloc() funtzioa erabiliz. Hau da, pixel guztiei buruzko informazioa gordetzeko behar diren byte kopurua erreserbatzen da, ondoren pantailan bistaratuko dena.

m_p_bitmapMemory bitmap-a sortzea:

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

Gutxi gorabehera, bit-mapa pixel multzo batez osatuta dago. Arrayko lau bytetik behin RGB pixel bat da. Byte bat kolore gorri-balio bakoitzeko, byte bat kolore berde-balio bakoitzeko (G) eta byte bat kolore urdin-balio bakoitzeko (B). Gainera, koska bakoitzeko byte bat dago. Hiru kolore hauek - Gorria/Berdea/Urdina (RGB) - elkarren artean nahasten dira proportzio desberdinetan, ondoriozko pixel kolorea sortzeko.

Orain, berriro ere, laukizuzen edo joko-objektu bakoitza zenbakizko matrize baten bidez adierazten da. Joko-objektu horiek guztiak bilduma batean kokatzen dira. Eta gero jolas-eremuan jartzen dira, zenbakizko matrize handi bat osatuz. Matrizeko zenbaki bakoitza kolore zehatz batekin lotu dut. Adibidez, 8 zenbakia urdinari dagokio, 9 zenbakia horiari, 10 zenbakia gris iluna, etab. Horrela, esan dezakegu joko-eremuaren matrize bat dugula, non zenbaki bakoitza kolore bat den.

Beraz, alde batetik joko-eremu osoaren matrize numeriko bat eta bestetik irudia bistaratzeko bit-mapa dugu. Orain arte, bitmapa "hutsik" dago; oraindik ez du nahi den koloreko pixelei buruzko informaziorik. Horrek esan nahi du azken urratsa bit-mapa betetzea izango dela pixel bakoitzari buruzko informazioarekin, joko-eremuaren zenbakizko matrizean oinarrituta. Eraldaketa horren adibide garbia beheko irudian dago.

DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean
Bitmap bat (Pixel matrizea) betetzeko adibide bat joko eremuko matrize digitalean oinarritutako informazioarekin (kolore indizeak ez datoz bat jokoko indizeekin)

Jolaseko benetako kode zati bat ere aurkeztuko dut. Begiztaren iterazio bakoitzean colorIndex aldagaiari balio bat (kolore indizea) esleitzen zaio jolas eremuko zenbakizko matrizetik (mainDigitalMatrix). Kolore-aldagaia indizearen arabera kolorea bera ezartzen da. Lortutako kolorea gorria, berdea eta urdina (RGB) proportzioan banatzen da. Eta pixelPaddingarekin batera, informazio hori pixelean behin eta berriro idazten da, bitmapan kolorezko irudi bat osatuz.

Kodeak erakusleak eta bit bidezko eragiketak erabiltzen ditu, ulertzea zaila izan daitekeena. Beraz, halako egiturek nola funtzionatzen duten nonbait bereizita irakurtzea gomendatzen dizut.

Bitmapa betetzea joko-eremuaren zenbakizko matrizean oinarritutako informazioz:

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

Goian azaldutako metodoaren arabera, Crazy Tanks jokoan irudi bat (markoa) eratzen da eta pantailan bistaratzen da Draw() funtzioan. Sarrera() funtzioan tekla sakatuak erregistratu eta gero Logic() funtzioan prozesatu ondoren, irudi (markoa) berri bat sortzen da. Egia da, joko-objektuek dagoeneko beste posizio bat izan dezakete joko-eremuan eta, horren arabera, beste leku batean marraztuta egotea. Horrela gertatzen da animazioa (mugimendua).

Teorian (ez badut ezer ahaztu), lehenengo jokoaren begizta ("Snake") eta bigarren jokotik pantailan pixelak bistaratzeko sistema ("Tankak") ulertzea besterik ez da behar duzuna idazteko. Windows-en zure 2D jokoen artean. Soinurik gabe! 😉 Gainerako zatiak fantasiazko hegaldi bat besterik ez dira.

Noski, "Tanks" jokoa "Snake" baino askoz konplexuagoa da. Dagoeneko C++ lengoaia erabiltzen nuen, hau da, joko-objektu desberdinak klaseekin deskribatu nituen. Nire bilduma sortu nuen - kodea goiburuetan/Box.h-n ikus daiteke. Bide batez, bildumak ziurrenik memoria ihesa du. Erabiltzen diren erakusleak. Memoriarekin lan egin. Liburuak asko lagundu zidala esan behar dut C++-n hastea Jokoen Programazioaren bidez. Hasiera bikaina da C++-n hasiberrientzat. Txikia, interesgarria eta ondo antolatuta da.

Sei hilabete inguru behar izan zituen joko hau garatzeko. Batez ere bazkalondoan eta lanean mokaduetan idazten nuen. Bulegoko sukaldean eseri zen, janaria zapaldu eta kodea idatzi zuen. Edo etxean afarian. Beraz, halako "sukalde gerrak" lortu nituen. Beti bezala, aktiboki erabili nuen koaderno bat, eta bertan jaio ziren kontzeptuzko gauza guztiak.

Zati praktikoa osatzeko, nire koadernoaren eskaneatu batzuk egingo ditut. Zer idatzi, marraztu, zenbatu, diseinatu... zehatz-mehatz erakusteko.

DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean
Tankeen irudiak diseinatzea. Eta depositu bakoitzak pantailan zenbat pixel izan behar dituen zehaztea

DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean
Depositua bere ardatzaren inguruan biraketa egiteko algoritmoa eta formulak kalkulatzea

DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean
Nire bildumaren eskema (memoria ihesa dagoena, ziurrenik). Bilduma Lotutako Zerrenda motaren arabera sortzen da

DevOps C++ eta "sukalde gerrak" edo Nola hasi nintzen jolasak idazten jaten bitartean
Eta adimen artifiziala jokoari eransteko saiakera hutsalak dira

teoria

"Mila kilometroko bidaia ere lehen urratsarekin hasten da" (Antzinako Txinako jakinduria)

Pasa gaitezen praktikatik teoriara! Nola aurkitu denbora zure zaletasunerako?

  1. Zehaztu benetan zer nahi duzun (ai, hau da zailena).
  2. Ezarri lehentasunak.
  3. Sakrifikatu "gehiago" guztia lehentasun handiagoen mesedetan.
  4. Mugitu helburuetara egunero.
  5. Ez espero bizpahiru ordu libre zaletasun batean pasatzeko.

Alde batetik, zer nahi duzun zehaztu eta lehentasuna eman behar duzu. Bestalde, jarduera/proiektu batzuk alde batera uztea posible da lehentasun horien alde. Beste era batera esanda, "gehigarria" dena sakrifikatu beharko duzu. Nonbait entzun nuen bizitzan gehienez hiru jarduera nagusi egon behar zirela. Orduan, kalitate gorenean egin ahal izango dituzu. Eta proiektu/norabide gehigarriak gainkargatzen hasiko dira. Baina hau guztia ziurrenik subjektiboa eta indibiduala da.

Urrezko arau jakin bat dago: inoiz ez izan % 0ko egunik! Garatzaile indie baten artikulu batean jakin nuen. Proiektu batean lanean ari bazara, egin zerbait egunero. Eta ez du axola zenbat egiten duzun. Idatzi hitz bat edo kode-lerro bat, ikusi tutorial-bideo bat edo sartu iltze bat arbel batean - egin zerbait. Zailena hastea da. Behin hasita, ziurrenik nahi baino apur bat gehiago egingo duzu. Horrela etengabe zure helburura joango zara eta, sinetsi iezadazu, oso azkar. Azken finean, gauza guztien oztopo nagusia atzerapena da.

Garrantzitsua da gogoratzea 5, 10, 15 minutuko doako "zerrautsa" ez duzula gutxietsi behar, ordubete edo bi irauten duten "erregistro" handi batzuk itxaron. Ilaran jartzen al zara? Pentsatu zerbait zure proiekturako. Eskailera mekanikoa hartu? Idatzi zerbait koaderno batean. Autobusean zoaz? Bikaina, irakurri artikulu batzuk. Aprobetxatu aukera guztiak. Utzi katu eta txakurrak ikustea YouTube-n! Ez kutsatu zure garuna!

Eta azken gauza bat. Artikulu hau irakurri ondoren, joko-motorrak erabili gabe jokoak sortzea gustatu bazaizu, gogoratu Casey Muratori izena. Tipo honek badu web. “Erlojua -> AURREKO ATALAK” atalean joko profesional bat hutsetik sortzeko doako bideo-tutorial zoragarriak aurkituko dituzu. Windows-erako C-ren sarrerako bost ikasgaitan ziurrenik unibertsitateko bost urteko ikasketetan baino gehiago ikasiko duzu (norbaitek bideoaren azpiko iruzkinetan idatzi zuen honi buruz).

Caseyk ere azaltzen du zure joko-motor propioa garatuz, lehendik dauden motorrak hobeto ulertuko dituzula. Denak automatizatzen saiatzen diren esparruen munduan, erabiltzen ikasten baino gehiago sortzen ikasten duzu. Ordenagailuen izaera bera ulertzen duzu. Eta askoz ere programatzaile adimentsuagoa eta helduagoa bihurtuko zara, profesional bat.

Zorte on aukeratutako bidean! Eta egin dezagun mundua profesionalagoa.

Egilea: Grankin Andrey, DevOps



Iturria: www.habr.com