"Ma tean, et ma ei tea midagi." Sokrates
Kellele: IT-inimestele, kes sülitavad kõikide arendajate peale ja tahavad oma mänge mängida!
Millest: kuidas alustada mängude kirjutamist C/C++ keeles, kui seda vajad!
Miks peaksite seda lugema: Rakenduste arendus pole minu tööeriala, aga püüan iga nädal kodeerida. Sest ma armastan mänge!
Tere minu nimi on , olen Luxofti DevOps. Rakenduste arendus pole minu tööeriala, aga püüan iga nädal kodeerida. Sest ma armastan mänge!
Arvutimängude tööstus on tohutu, tänapäeval levitatakse isegi rohkem kuulujutte kui filmitööstus. Mänge on kirjutatud arvutite arendamise algusest peale, kasutades tänapäevaste standardite järgi keerulisi ja põhilisi arendusmeetodeid. Aja jooksul hakkasid ilmuma mängumootorid juba programmeeritud graafika, füüsika ja heliga. Need võimaldavad teil keskenduda mängu enda arendamisele ja mitte muretseda selle aluse pärast. Kuid koos nendega, koos mootoritega, "jäävad pimedaks" ja lagunevad ka arendajad. Mängude tootmine pannakse konveierile. Ja toodangu kvantiteet hakkab domineerima selle kvaliteedi üle.
Samas oleme teiste inimeste mänge mängides pidevalt piiratud asukohtade, süžee, tegelaste, mängumehaanikaga, mis teised inimesed välja mõtlesid. Nii sain aru, et...
… on aeg luua oma maailmad, alludes ainult mulle. Maailmad, kus mina olen Isa ja Poeg ja Püha Vaim!
Ja ma usun siiralt, et kirjutades oma mängumootori ja sellele mängu, saate avada oma silmad, pühkida aknad ja pumbata oma salongi, muutudes kogenumaks ja terviklikumaks programmeerijaks.
Selles artiklis püüan teile rääkida, kuidas alustasin väikeste mängude kirjutamist C / C ++-s, milline on arendusprotsess ja kust leian kiires keskkonnas aega hobide jaoks. See on subjektiivne ja kirjeldab individuaalse alguse protsessi. Materjal teadmatusest ja usust, minu isiklikust maailmapildist hetkel. Teisisõnu: "Administratsioon ei vastuta teie isiklike ajude eest!".
Tava
"Teadmised ilma praktikata on kasutud, praktika ilma teadmisteta on ohtlik." Konfutsius
Minu märkmik on minu elu!
Seega võin praktikas öelda, et minu jaoks algab kõik märkmikust. Panen sinna kirja mitte ainult oma igapäevased ülesanded, vaid ka joonistan, programmeerin, kujundan vooskeemi ja lahendan ülesandeid, sh matemaatilisi. Kasutage alati märkmikku ja kirjutage ainult pliiatsiga. See on puhas, mugav ja usaldusväärne, IMHO.
Minu (juba täidetud) märkmik. See näeb välja selline. See sisaldab igapäevaseid ülesandeid, ideid, jooniseid, diagramme, lahendusi, musta raamatupidamist, koodi jne.
Selles etapis jõudsin lõpule viia kolm projekti (see on minu mõistes “lõplikkus”, sest mis tahes toodet saab suhteliselt lõputult arendada).
- Projekt 0: see on Arhitekti Demo 3D stseen, mis on kirjutatud C# keeles Unity mängumootori abil. MacOS-i ja Windowsi platvormide jaoks.
- 1. mäng: konsoolimäng Simple Snake (kõigile tuntud kui "Snake") Windowsile. kirjutatud C-s.
- 2. mäng: konsoolimäng Crazy Tanks (kõigile tuntud kui "Tanks"), mis on kirjutatud juba C ++ keeles (kasutades klasse) ja ka Windowsi all.
Projekti 0 arhitekti demo
- Platvorm: Windows (Windows 7, 10), Mac OS (OS X El Capitan v. 10.11.6)
- Keel: C#
- Mängu mootor:
- Inspiratsioon:
- Hoidla:
3D-stseeni arhitekti demo
Esimene projekt realiseeriti mitte C/C++, vaid C# keeles, kasutades Unity mängumootorit. See mootor polnud riistvara suhtes nii nõudlik kui , ning mulle tundus ka lihtsam paigaldada ja kasutada. Teisi mootoreid ma ei arvestanud.
Minu jaoks ei olnud Unity eesmärk mingit mängu arendada. Tahtsin luua mingi tegelasega 3D-stseeni. Tema, õigemini Tema (ma modelleerisin tüdrukut, kellesse olin armunud =) pidi liikuma ja suhtlema välismaailmaga. Oluline oli vaid aru saada, mis on Unity, mis on arendusprotsess ja kui palju vaeva kulub millegi loomiseks. Nii sündis projekt Arhitekt Demo (nimi leiutati peaaegu jamadest). Programmeerimine, modelleerimine, animatsioon, tekstureerimine võtsid mul vist kaks kuud igapäevast tööd.
Alustasin YouTube'i õppevideotega 3D-mudelite loomise kohta . Blender on suurepärane tasuta tööriist 3D-modelleerimiseks (ja muuks), mis ei vaja installimist. Ja siin ootas mind šokk ... Selgub, et modelleerimine, animatsioon, tekstureerimine on tohutult eraldi teemad, millest saab raamatuid kirjutada. See kehtib eriti tegelaste kohta. Sõrmede, hammaste, silmade ja muude kehaosade modelleerimiseks vajate teadmisi anatoomiast. Kuidas on näo lihased paigutatud? Kuidas inimesed liiguvad? Pidin igasse kätte, jalga, sõrme, sõrmenukkidesse luud “sisestama”!
Modelleerige rangluu, täiendavad luuhoovad, et animatsioon näeks loomulik välja. Pärast selliseid õppetükke mõistate, kui suurt tööd teevad animafilmide loojad, et luua 30 sekundit videot. Kuid 3D-filmid kestavad tunde! Ja siis tuleme kinodest välja ja ütleme midagi sellist: “Ta, äge multikas/film! Nad oleksid võinud paremini teha…” Lollid!
Ja veel üks asi programmeerimise kohta selles projektis. Nagu selgus, oli minu jaoks kõige huvitavam matemaatika. Kui käivitate stseeni (link hoidlale projekti kirjelduses), märkate, et kaamera pöörleb sfääris ümber tüdruku tegelase. Sellise kaamera pööramise programmeerimiseks pidin kõigepealt arvutama asendipunkti koordinaadid ringil (2D) ja seejärel sfääril (3D). Naljakas on see, et ma vihkasin koolis matemaatikat ja teadsin seda miinusega. Osaliselt ilmselt sellepärast, et koolis lihtsalt ei seletata sulle, kuidas pagan seda matemaatikat elus rakendatakse. Aga kui oled kinnisideeks oma eesmärgist, unistad, siis on mõistus puhas, paljastatud! Ja hakkate keerukaid ülesandeid tajuma põneva seiklusena. Ja siis mõtlete: "Noh, miks ei võiks *armastatud* matemaatik tavaliselt öelda, kuhu neid valemeid saab kasutada?".
Valemite arvutamine punkti koordinaatide arvutamiseks ringil ja sfääril (minu märkmikust)
1. mäng
- Platvorm: Windows (testitud opsüsteemides Windows 7, 10)
- Keel: Ma arvan, et see oli kirjutatud puhtas C-s
- Mängu mootor: Windowsi konsool
- Inspiratsioon:
- Hoidla:
Lihtne Snake mäng
3D-stseen ei ole mäng. Lisaks on 3D-objektide (eriti tegelaste) modelleerimine ja animeerimine pikk ja keeruline. Pärast Unityga ringi mängimist sain aru, et pean jätkama või õigemini alustama põhitõdedest. Midagi lihtsat ja kiiret, kuid samal ajal globaalset, et mõista mängude ülesehitust.
Ja mis meil on lihtne ja kiire? Täpselt nii, konsool ja 2D. Täpsemalt isegi konsool ja sümbolid. Jälle hakkasin internetist inspiratsiooni otsima (üldiselt pean internetti XNUMX. sajandi kõige revolutsioonilisemaks ja ohtlikumaks leiutiseks). Kaevasin üles video ühest programmeerijast, kes tegi konsooli Tetrise. Ja oma mängu sarnaselt otsustas ta "mao" maha raiuda. Videost sain teada kahest põhimõttelisest asjast – mängutsüklist (kolme põhifunktsiooni/osaga) ja väljundist puhvrisse.
Mängutsükkel võib välja näha umbes selline:
int main()
{
Setup();
// a game loop
while (!quit)
{
Input();
Logic();
Draw();
Sleep(gameSpeed); // game timing
}
return 0;
}Kood esitab kogu funktsiooni main() korraga. Ja mängutsükkel algab vastava kommentaari järel. Silmuses on kolm põhifunktsiooni: Input(), Logic(), Draw(). Esiteks sisendandmed Sisend (peamiselt klahvivajutuste juhtimine), seejärel sisestatud andmete töötlemine Loogika, seejärel kuvamine ekraanil - Joonista. Ja nii iga kaader. Animatsioon luuakse sel viisil. See on nagu karikatuurid. Tavaliselt võtab sisendandmete töötlemine kõige rohkem aega ja minu teada määrab mängu kaadrisageduse. Kuid siin on funktsioon Logic() väga kiire. Seetõttu peab kaadrisagedust juhtima funktsioon Sleep() parameetriga gameSpeed , mis määrab selle kiiruse.
mängutsükkel. Madude programmeerimine märkmikus
Kui arendate sümboolset konsoolimängu, siis andmete kuvamine ekraanil tavalise vooväljundi 'cout' abil ei tööta - see on väga aeglane. Seetõttu tuleb väljund läbi viia ekraanipuhvris. Nii palju kiiremini ja mäng töötab ilma tõrgeteta. Kui aus olla, siis ma ei saa päris täpselt aru, mis on ekraanipuhver ja kuidas see töötab. Aga ma toon siin koodinäite ja ehk oskab keegi kommentaaridest olukorda selgitada.
Ekraanipuhvri hankimine (kui võib nii öelda):
// create screen buffer for drawings
HANDLE hConsole = CreateConsoleScreenBuffer(GENERIC_READ | GENERIC_WRITE, 0,
NULL, CONSOLE_TEXTMODE_BUFFER, NULL);
DWORD dwBytesWritten = 0;
SetConsoleActiveScreenBuffer(hConsole);Otseväljund teatud rea ekraanile scoreLine (skooride kuvamise rida):
// draw the score
WriteConsoleOutputCharacter(hConsole, scoreLine, GAME_WIDTH, {2,3}, &dwBytesWritten);Teoreetiliselt pole selles mängus midagi keerulist, mulle tundub see hea näide algtaseme mängust. Kood on kirjutatud ühte faili ja paigutatud mitmesse funktsiooni. Pole klasse, pole pärandit. Saate ise näha kõike mängu lähtekoodis, kui lähete GitHubi hoidlasse.
Mäng 2 Crazy Tanks
- Platvorm: Windows (testitud opsüsteemides Windows 7, 10)
- Keel: C + +
- Mängu mootor: Windowsi konsool
- Inspiratsioon: raamat
- Hoidla:
Mäng Crazy Tanks
Tähemärkide konsooli trükkimine on ilmselt kõige lihtsam asi, mida saate mänguks muuta. Siis aga ilmneb üks häda: tegelased on erineva kõrguse ja laiusega (kõrgus on laiusest suurem). Seega tundub kõik ebaproportsionaalne ja alla või üles liikumine tundub palju kiirem kui vasakule või paremale liikumine. See efekt on "Maos" (1. mäng) väga märgatav. "Tankidel" (mäng 2) sellist puudust pole, kuna sealne väljund korraldatakse ekraani pikslite värvimisega erinevate värvidega. Võib öelda, et kirjutasin renderdaja. Tõsi, see on juba veidi keerulisem, kuigi palju huvitavam.
Selle mängu jaoks piisab, kui kirjeldan minu süsteemi pikslite kuvamiseks ekraanil. Ma arvan, et see on mängu põhiosa. Ja kõike muud saate ise välja mõelda.
Niisiis, see, mida ekraanil näete, on vaid liikuvate värviliste ristkülikute komplekt.
Ristküliku komplekt
Iga ristkülik on kujutatud numbritega täidetud maatriksiga. Muide, võin välja tuua ühe huvitava nüansi – mängus on kõik maatriksid programmeeritud ühemõõtmelise massiivina. Mitte kahemõõtmeline, vaid ühemõõtmeline! Ühemõõtmeliste massiividega on palju lihtsam ja kiirem töötada.
Näide mängutanki maatriksist
Mängupaagi maatriksi kujutamine ühemõõtmelise massiiviga
Illustreerivam näide maatriksi esitusest ühemõõtmelise massiiviga
Kuid juurdepääs massiivi elementidele toimub topeltsilmuses, justkui poleks see ühemõõtmeline, vaid kahemõõtmeline massiiv. Seda tehakse seetõttu, et me töötame endiselt maatriksitega.
Ühemõõtmelise massiivi läbimine topeltsilmuses. Y on rea ID, X on veeru ID
Pange tähele, et tavapäraste maatriksidentifikaatorite i, j asemel kasutan identifikaatoreid x ja y. Nii et mulle tundub see silmale meeldivam ja ajule selgem. Lisaks võimaldab selline tähistus kasutada kasutatavaid maatrikseid mugavalt kahemõõtmelise kujutise koordinaattelgedele projitseerida.
Nüüd pikslite, värvide ja ekraani kohta. Väljundiks kasutatakse funktsiooni StretchDIBits (päis: windows.h; raamatukogu: gdi32.lib). Muuhulgas edastatakse sellele funktsioonile: seade, millel pilti kuvatakse (minu puhul on see Windowsi konsool), pildi kuvamise alguse koordinaadid, selle laius/kõrgus ja pilt ise bitmap (bitmap) kujul, mida esindab baitide massiiv. Bitmap baitide massiivina!
Funktsioon StretchDIBits() töötab:
// 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
);Selle bitmapi jaoks eraldatakse mälu eelnevalt funktsiooni VirtualAlloc() abil. See tähendab, et vajalik arv baite on reserveeritud teabe salvestamiseks kõigi pikslite kohta, mis seejärel kuvatakse ekraanil.
m_p_bitmapMemory bitmap loomine:
// create bitmap
int bitmapMemorySize = (PMATRIX_WIDTH * PMATRIX_HEIGHT) * BYTES_PER_PIXEL;
void* m_p_bitmapMemory = VirtualAlloc(0, bitmapMemorySize, MEM_COMMIT, PAGE_READWRITE);Jämedalt öeldes koosneb bitmap pikslite komplektist. Iga neli baiti massiivis on RGB piksel. Üks bait punase väärtuse kohta, üks bait rohelise väärtuse kohta (G) ja üks bait sinise värvi kohta (B). Lisaks on taande kohta üks bait. Need kolm värvi - Red / Green / Blue (RGB) - segatakse üksteisega erinevates proportsioonides - ja saadud pikslivärv saadakse.
Nüüd jällegi on iga ristkülik või mänguobjekt kujutatud arvumaatriksiga. Kõik need mänguobjektid on paigutatud kollektsiooni. Ja siis asetatakse need mänguväljale, moodustades ühe suure arvulise maatriksi. Vastandasin maatriksis iga numbri konkreetse värviga. Näiteks number 8 on sinine, number 9 on kollane, number 10 on tumehall jne. Seega võime öelda, et meil on mänguvälja maatriks, kus iga number on mingit värvi.
Seega on meil ühelt poolt kogu mänguvälja numbriline maatriks ja teiselt poolt pildi kuvamiseks mõeldud bitmap. Siiani on bitmap "tühi" - sellel pole veel teavet soovitud värvi pikslite kohta. See tähendab, et viimane samm on bitmapi täitmine teabega iga piksli kohta mänguvälja numbrilise maatriksi alusel. Illustreeriv näide sellisest teisendusest on alloleval pildil.
Näide bitmapi (pikslimaatriksi) täitmisest teabega, mis põhineb mänguvälja numbrilisel maatriksil (digitaalmaatriks) (värviindeksid ei ühti mängu indeksitega)
Esitan ka tüki päris koodi mängust. Muutujale colorIndex omistatakse tsükli iga iteratsiooni juures väärtus (värviindeks) mänguvälja arvmaatriksist (mainDigitalMatrix). Seejärel kirjutatakse indeksi põhjal värv ise värvimuutujasse. Lisaks jagatakse saadud värv punase, rohelise ja sinise suhteks (RGB). Ja koos taandega (pixelPadding) kirjutatakse see teave pikslisse ikka ja jälle, moodustades bitmapil värvilise pildi.
Kood kasutab viiteid ja bitipõhiseid toiminguid, millest võib olla raske aru saada. Seega soovitan sul kuskilt eraldi lugeda, kuidas sellised struktuurid töötavad.
Bitkaardi täitmine teabega mänguvälja numbrilise maatriksi põhjal:
// 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;
}Ülalkirjeldatud meetodi kohaselt moodustatakse mängus Crazy Tanks üks pilt (kaader), mis kuvatakse ekraanile funktsioonis Draw(). Pärast klahvivajutuste registreerimist funktsioonis Input() ja nende järgnevat töötlemist funktsioonis Logic() moodustub uus pilt (kaader). Tõsi, mänguobjektid võivad mänguväljal olla juba erinevas asendis ja vastavalt sellele on need joonistatud erinevasse kohta. Nii toimub animatsioon (liikumine).
Teoreetiliselt (kui te pole midagi unustanud) piisab, kui mõistate mängutsüklit esimesest mängust ("Snake") ja pikslite kuvamise süsteemi teisest mängust ("Tanks") teie Windowsi 2D-mängudest. Helitu! 😉 Ülejäänud osad on lihtsalt fantaasialend.
Muidugi on mäng "Tanks" kujundatud palju keerulisemaks kui "Snake". Kasutasin juba C++ keelt ehk kirjeldasin erinevaid mänguobjekte klassidega. Tegin oma kollektsiooni - koodi näete päistes/Box.h. Muide, kollektsioonis on suure tõenäosusega mäluleke. Kasutatud viiteid. Töötas mäluga. Pean ütlema, et raamat aitas mind palju. C++ alustamine mängude programmeerimise kaudu. See on suurepärane algus C++ algajatele. See on väike, huvitav ja hästi organiseeritud.
Selle mängu arendamiseks kulus umbes kuus kuud. Kirjutasin peamiselt lõuna ajal ja tööl näksides. Ta istus kontori köögis, trampis toitu ja kirjutas koodi. Või kodus õhtusöögiks. Nii et mul tekkisid sellised "köögisõjad". Nagu ikka, kasutasin aktiivselt märkmikku ja kõik kontseptuaalsed asjad sündisid selles.
Praktilise osa lõpus tõmban välja paar skaneeringut oma märkmikust. Et näidata, mida ma täpselt üles kirjutasin, joonistasin, lugesin, kujundasin…
Tanki pildikujundus. Ja määratlus, mitu pikslit iga paak peaks ekraanil hõivama
Paagi ümber oma telje pöörlemise algoritmi ja valemite arvutamine
Minu kollektsiooni skeem (tõenäoliselt mälulekkega). Kogu luuakse lingitud loendina
Ja need on asjatud katsed tehisintellekti mängu kruvida
Теория
"Isegi tuhandemiiline teekond algab esimesest sammust" (Vana Hiina tarkus)
Liigume praktikalt teooriale! Kuidas leiad aega oma hobi jaoks?
- Määrake, mida sa tegelikult tahad (paraku, see on kõige keerulisem).
- Määrake prioriteedid.
- Ohverdage kõik "üleliigne" kõrgemate prioriteetide nimel.
- Liikuge iga päev oma eesmärkide poole.
- Ärge oodake, et hobiks jääb kaks-kolm tundi vaba aega.
Ühest küljest peate kindlaks määrama, mida soovite, ja seadma prioriteediks. Teisest küljest on võimalik mõnest juhtumist/projektist nende prioriteetide kasuks loobuda. Teisisõnu peate ohverdama kõik "üleliigse". Kuskilt kuulsin, et elus peaks olema maksimaalselt kolm põhitegevust. Siis saad nendega parimal võimalikul viisil hakkama. Ja lisaprojektid/suunad hakkavad ülekoormama. Kuid see kõik on ilmselt subjektiivne ja individuaalne.
Kehtib teatav kuldreegel: kunagi ei tohi olla 0% päeva! Sain sellest teada indie-arendaja artiklist. Kui töötate projekti kallal, tehke selle nimel iga päev midagi. Ja pole vahet, kui palju te teenite. Kirjutage üks sõna või üks koodirida, vaadake ühte õppevideot või lööge üks nael tahvlisse – lihtsalt tehke midagi. Kõige raskem on alustada. Kui alustate, teete tõenäoliselt veidi rohkem, kui tahtsite. Nii et liigute pidevalt oma eesmärgi poole ja uskuge mind, väga kiiresti. Lõppude lõpuks on kõigi asjade peamine pidur edasilükkamine.
Ja on oluline meeles pidada, et te ei tohiks alahinnata ja ignoreerida vaba aja "saepuru" 5, 10, 15 minuti jooksul, oodata mõnda suurt "palki", mis kestab tund või paar. Kas sa seisad sabas? Mõelge oma projektile midagi. Kas sa lähed eskalaatoriga üles? Kirjutage midagi märkmikusse. Kas sa sööd bussis? Olgu, lugege mõnda artiklit. Kasutage iga võimalust. Lõpetage YouTube'is kasside ja koerte vaatamine! Ära aja oma ajuga jama!
Ja viimane. Kui pärast selle artikli lugemist meeldis teile idee luua mänge ilma mängumootoreid kasutamata, pidage meeles Casey Muratori nime. Sellel mehel on . Jaotises "vaata -> EELMISED EPISOODID" leiate hämmastavaid tasuta videoõpetusi, kuidas luua nullist professionaalset mängu. Windowsi C sissejuhatuse viie õppetunni jooksul võite õppida rohkem kui viie aasta jooksul ülikoolis õppides (keegi kirjutas sellest video all olevates kommentaarides).
Casey selgitab ka, et oma mängumootorit arendades mõistate paremini kõiki olemasolevaid mootoreid. Raamistikumaailmas, kus kõik üritavad automatiseerida, õpite looma, mitte kasutama. Arvutite olemuse mõistmine. Ja sinust saab ka palju intelligentsem ja küpsem programmeerija – proff.
Edu valitud teel! Ja muudame maailma professionaalsemaks.
Autor: , DevOps
Allikas: www.habr.com