DevOps C++ и „кујнски војни“, или Како почнав да пишувам игри додека јадам

„Знам дека ништо не знам“ Сократ

За кого: за ИТ луѓе кои плукаат по сите програмери и сакаат да ги играат нивните игри!

За што: како да започнете да пишувате игри во C/C++ ако ви треба!

Зошто треба да го прочитате ова: Развојот на апликации не е моја работна специјалност, но се обидувам да кодирам секоја недела. Затоа што сакам игри!

Здраво Моето име е Андреј Гранкин, јас сум DevOps во Luxoft. Развојот на апликации не е моја работна специјалност, но се обидувам да кодирам секоја недела. Затоа што сакам игри!

Индустријата за компјутерски игри е огромна, дури и повеќе се шпекулира денес од филмската индустрија. Игрите се напишани уште од почетокот на развојот на компјутерите, користејќи, според современи стандарди, сложени и основни методи на развој. Со текот на времето, моторите за игри почнаа да се појавуваат со веќе програмирани графики, физика и звук. Тие ви дозволуваат да се фокусирате на развојот на самата игра и да не се мачите за нејзината основа. Но, заедно со нив, со моторите, програмерите „слепуваат“ и деградираат. Самото производство на игри се става на транспортерот. И квантитетот на производството почнува да преовладува над неговиот квалитет.

Во исто време, кога играме туѓи игри, постојано сме ограничени со локации, заплет, ликови, механика на игри до кои дошле другите луѓе. Така сфатив дека ...

… време е да создадете свои светови, подложени само на мене. Светови каде што јас сум Отецот и Синот и Светиот Дух!

И јас искрено верувам дека со пишување на свој мотор за игри и игра на него, ќе можете да ги отворите очите, да ги избришете прозорците и да ја пумпате вашата кабина, станувајќи поискусен и интегрален програмер.

Во оваа статија ќе се обидам да ви кажам како почнав да пишувам мали игри во C / C ++, каков е процесот на развој и каде наоѓам време за хоби во зафатена средина. Тој е субјективен и го опишува процесот на индивидуален почеток. Материјал за незнаењето и верата, за мојата лична слика за светот во моментов. Со други зборови, „Администрацијата не е одговорна за вашите лични мозоци!“.

Пракса

„Знаењето без пракса е бескорисно, вежбањето без знаење е опасно“ Конфучие

Мојата тетратка е мојот живот!

Така, во пракса, можам да кажам дека се за мене започнува со тетратка. Таму ги запишувам не само моите дневни задачи, туку и цртам, програмирам, дизајнирам дијаграми на текови и решавам проблеми, вклучително и математички. Секогаш користете бележник и пишувајте само со молив. Чист е, удобен и сигурен, IMHO.

Мојата (веќе пополнета) тетратка. Вака изгледа. Содржи секојдневни задачи, идеи, цртежи, дијаграми, решенија, црно книговодство, код и сл.

Во оваа фаза, успеав да завршам три проекти (ова е во моето разбирање за „комплетност“, бидејќи секој производ може да се развива релативно бесконечно).

• Проект 0: ова е Architect Demo 3D сцена напишана во C# со помош на моторот за игри Unity. За macOS и Windows платформи.
• Игра 1: Конзолна игра Simple Snake (на сите позната како „Snake“) за Windows. напишано во В.
• Игра 2: Конзолна игра Crazy Tanks (на сите позната како „Tanks“), веќе напишана во C ++ (со користење на класи) и исто така под Windows.

Проект 0 Архитект Демо

• Платформа: Windows (Windows 7, 10), Mac OS (OS X El Capitan v. 10.11.6)
• Јазик: C#
• Мотор за игри: Единство
• Инспирација: Дарин Лиле
• Репозиториум: GitHub

Демо за 3D Scene Architect

Првиот проект беше имплементиран не во C/C++, туку во C# користејќи го моторот за игри Unity. Овој мотор не беше толку баран за хардвер како Unreal Engine, а исто така ми се чинеше полесно за инсталирање и користење. Не ги земав предвид другите мотори.

Целта во Unity за мене не беше да развивам некаква игра. Сакав да создадам 3Д сцена со некаков карактер. Тој, поточно Таа (ја моделирав девојката во која бев вљубена =) мораше да се движи и да комуницира со надворешниот свет. Важно беше само да се разбере што е Unity, каков е процесот на развој и колку напор е потребен за да се создаде нешто. Така се роди проектот Architect Demo (името е измислено речиси од срање). Програмирање, моделирање, анимација, текстурирање ми требаа веројатно два месеци секојдневна работа.

Почнав со туториал видеа на YouTube за тоа како да креирате 3D модели во Блендер. Blender е одлична бесплатна алатка за 3D моделирање (и повеќе) што не бара инсталација. И тука ме чекаше шок ... Излегува дека моделирањето, анимацијата, текстурирањето се огромни посебни теми на кои можете да пишувате книги. Ова особено важи за ликовите. За да ги моделирате прстите, забите, очите и другите делови од телото, ќе ви треба познавање на анатомијата. Како се распоредени мускулите на лицето? Како се движат луѓето? Морав да „вметнам“ коски во секоја рака, нога, прст, зглобови!

Симулирајте клучни коски, дополнителни коскени лостови, за анимацијата да изгледа природно. По ваквите лекции, сфаќате каква огромна работа прават креаторите на анимирани филмови, само за да создадат видео од 30 секунди. Но, 3D филмовите траат со часови! И тогаш излегуваме од кината и кажуваме нешто како: „Та, посран цртан/филм! Можеа и подобро…“ Глупаци!

И уште нешто за програмирањето во овој проект. Како што се испостави, најинтересниот дел за мене беше математичкиот. Ако ја извршите сцената (врска до складиштето во описот на проектот), ќе забележите дека камерата ротира околу ликот на девојката во сфера. За да програмирам таква ротација на камерата, морав прво да ги пресметам координатите на положната точка на кругот (2D), а потоа и на сферата (3D). Смешното е што мразев математика на училиште и ја знаев со минус. Делумно, веројатно, затоа што на училиште едноставно не ви објаснуваат како по ѓаволите се применува оваа математика во животот. Но, кога сте опседнати со вашата цел, сонувајте, тогаш умот се расчистува, се открива! И комплексните задачи почнувате да ги сфаќате како возбудлива авантура. И тогаш мислите: „Па, зошто *саканиот* математичар нормално не можеше да каже каде може да се потпираат овие формули?“.

Пресметка на формули за пресметување на координатите на точка на круг и на топка (од мојата тетратка)

Игра 1

• Платформа: Windows (тестиран на Windows 7, 10)
• Јазик: Мислам дека е напишано со чисто Ц
• Мотор за игри: Windows конзола
• Инспирација: javidx9
• Репозиториум: GitHub

Едноставна игра со змии

3Д сцената не е игра. Покрај тоа, моделирањето и анимирањето на 3D објекти (особено ликови) е долго и тешко. Откако си поиграв со Unity, сфатив дека морам да продолжам, или подобро кажано, да почнам од основите. Нешто едноставно и брзо, но во исто време и глобално, за да се разбере самата структура на игрите.

А што имаме едноставно и брзо? Така е, конзола и 2D. Поточно, дури и конзолата и симболите. Повторно, почнав да барам инспирација на Интернет (во глобала, интернетот го сметам за најреволуционерниот и најопасниот изум на XNUMX век). Ископав видео од еден програмер кој направи конзола Тетрис. И по подобие на својата игра реши да ја исече „змијата“. Од видеото научив за две основни работи - циклусот на играта (со три основни функции / делови) и излезот во баферот.

Јамката на играта може да изгледа вака:

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

Кодот ја прикажува целата функција main() одеднаш. И циклусот на играта започнува по соодветниот коментар. Постојат три основни функции во циклусот: Input(), Logic(), Draw(). Прво, внесување податоци Внесување (главно контрола на притискање на копчињата), потоа обработка на внесените податоци Логика, па прикажување на екранот - Цртање. И така секоја рамка. На овој начин се создава анимација. Тоа е како цртани филмови. Обично обработката на влезните податоци одзема најмногу време и, колку што знам, ја одредува стапката на слики на играта. Но, тука функцијата Logic() е многу брза. Затоа, стапката на слики мора да се контролира со функцијата Sleep() со параметарот gameSpeed, кој ја одредува оваа стапка.

циклус на игра. Програмирање на змии во бележник

Ако развивате симболична игра со конзола, тогаш прикажувањето податоци на екранот со користење на вообичаениот излез на пренос „cout“ нема да работи - тоа е многу бавно. Затоа, излезот мора да се изврши во баферот на екранот. Толку побрзо и играта ќе работи без грешки. Да бидам искрен, не разбирам баш што е тампон на екранот и како функционира. Но, овде ќе дадам пример за код, а можеби некој во коментарите ќе може да ја разјасни ситуацијата.

Добивање на баферот на екранот (ако можам да кажам така):

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

Директен излез на екранот на одредена линија резултати (линија за прикажување резултати):

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

Теоретски, нема ништо комплицирано во оваа игра, ми се чини добар пример за игра на влезно ниво. Кодот е запишан во една датотека и распореден во неколку функции. Нема часови, нема наследство. Вие самите можете да видите сè во изворниот код на играта со одење во складиштето на GitHub.

Игра 2 луди тенкови

• Платформа: Windows (тестиран на Windows 7, 10)
• Јазик: C + +
• Мотор за игри: Windows конзола
• Инспирација: книга Почеток на C++ преку програмирање на игри
• Репозиториум: GitHub

Игра Луди тенкови

Печатењето знаци на конзолата е веројатно наједноставното нешто што можете да го претворите во игра. Но, тогаш се појавува една неволја: ликовите имаат различни висини и ширини (висината е поголема од ширината). Така, сè ќе изгледа непропорционално, а движењето надолу или нагоре ќе изгледа многу побрзо отколку движењето лево или десно. Овој ефект е многу забележлив во „Змија“ (Игра 1). „Тенкови“ (игра 2) немаат таков недостаток, бидејќи излезот таму се организира со боење на пикселите на екранот со различни бои. Може да се каже дека напишав рендерер. Точно, ова е веќе малку покомплицирано, иако многу поинтересно.

За оваа игра, ќе биде доволно да го опишам мојот систем за прикажување пиксели на екранот. Мислам дека ова е главниот дел од играта. И се друго можете сами да смислите.

Значи, она што го гледате на екранот е само збир од подвижни обоени правоаголници.

Комплет правоаголник

Секој правоаголник е претставен со матрица исполнета со броеви. Патем, можам да истакнам една интересна нијанса - сите матрици во играта се програмирани како еднодимензионална низа. Не дводимензионално, туку еднодимензионално! Еднодимензионалните низи се многу полесни и побрзи за работа.

Пример за матрица на резервоар за игра

Претставување на матрицата на резервоар за игра со еднодимензионална низа

Поилустративен пример на матрична претстава со еднодимензионална низа

Но, пристапот до елементите на низата се случува во двојна јамка, како да не е еднодимензионална, туку дводимензионална низа. Ова е направено затоа што сè уште работиме со матрици.

Преминување на еднодимензионална низа во двојна јамка. Y е ID на редот, X е ID на колоната

Ве молиме имајте предвид дека наместо вообичаените идентификатори на матрицата i, j, ги користам идентификаторите x и y. Така, ми се чини, попријатно за око и појасно за мозокот. Покрај тоа, таквата нотација овозможува погодно проектирање на матриците што се користат на координатните оски на дводимензионална слика.

Сега за пиксели, боја и дисплеј. Функцијата StretchDIBits (Header: windows.h; Library: gdi32.lib) се користи за излез. Меѓу другото, на оваа функција се пренесува следново: уредот на кој се прикажува сликата (во мојот случај, ова е конзолата на Windows), координатите на почетокот на прикажувањето на сликата, нејзината ширина / висина и сликата самиот во форма на битмапа (битмапа), претставена со низа од бајти. Битмапа како низа од бајти!

Функцијата StretchDIBits() на работа:

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

Меморијата се доделува однапред за оваа битмапа користејќи ја функцијата VirtualAlloc(). Односно, потребниот број бајти е резервиран за складирање на информации за сите пиксели, кои потоа ќе се прикажат на екранот.

Создавање m_p_bitmapМемориска битмапа:

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

Грубо кажано, битмапата се состои од збир на пиксели. Секои четири бајти во низата е RGB пиксел. Еден бајт по црвена вредност, еден бајт по зелена вредност (G) и еден бајт по сина боја (B). Плус, има еден бајт по алинеја. Овие три бои - Црвена / Зелена / Сина (RGB) - се мешаат една со друга во различни пропорции - и се добива добиената боја на пикселот.

Сега, повторно, секој правоаголник, или објект на играта, е претставен со матрица на броеви. Сите овие предмети на играта се сместени во колекција. И тогаш тие се ставаат на полето за играње, формирајќи една голема нумеричка матрица. Го мапирав секој број во матрицата со одредена боја. На пример, бројот 8 е сина, бројот 9 е жолт, бројот 10 е темно сива итн. Така, можеме да кажеме дека имаме матрица на полето за играње, каде што секој број е некаква боја.

Значи, имаме нумеричка матрица на целото поле за играње од една страна и битмапа за прикажување на сликата од друга страна. Досега, битмапата е „празна“ - сè уште нема информации за пикселите од саканата боја. Ова значи дека последниот чекор ќе биде пополнување на битмапата со информации за секој пиксел врз основа на нумеричката матрица на полето за играње. Илустративен пример за таква трансформација е на сликата подолу.

Пример за пополнување битмапа (матрица на пиксели) со информации засновани на нумеричката матрица (Дигитална матрица) на полето за играње (индексите на боите не се совпаѓаат со индексите во играта)

Ќе презентирам и дел од вистински код од играта. На променливата colorIndex при секое повторување на циклусот и се доделува вредност (индекс на боја) од нумеричката матрица на полето за играње (mainDigitalMatrix). Тогаш самата боја се запишува на променливата боја врз основа на индексот. Понатаму, добиената боја е поделена на сооднос на црвена, зелена и сина (RGB). И заедно со вовлекувањето (pixelPadding), оваа информација се запишува на пикселот одново и одново, формирајќи слика во боја во битмапата.

Кодот користи покажувачи и битови операции, кои може да бидат тешки за разбирање. Затоа ве советувам да прочитате некаде одделно како функционираат таквите структури.

Пополнување на битмапа со информации засновани на нумеричката матрица на полето за играње:

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

Според методот опишан погоре, една слика (рамка) се формира во играта Crazy Tanks и се прикажува на екранот во функцијата Draw(). По регистрирање на тастатурата во функцијата Input() и нивна последователна обработка во функцијата Logic(), се формира нова слика (рамка). Точно, предметите на играта можеби веќе имаат поинаква позиција на полето за играње и, соодветно, се нацртани на друго место. Така се случува анимацијата (движењето).

Во теорија (ако не сте заборавиле ништо), разбирањето на циклусот на играта од првата игра („Змија“) и системот за прикажување пиксели на екранот од втората игра („Тенкови“) е сè што ви треба за да напишете од вашите 2D игри за Windows. Беззвучно! 😉 Останатите делови се само фантазија.

Се разбира, играта „Тенкови“ е дизајнирана многу покомплицирано од „Змијата“. Веќе го користев јазикот C++, односно опишав различни предмети на играта со класи. Создадов сопствена колекција - можете да го видите кодот во headers/Box.h. Патем, колекцијата најверојатно има протекување на меморијата. Користени покажувачи. Работеше со меморија. Морам да кажам дека книгата многу ми помогна. Почеток на C++ преку програмирање на игри. Ова е одличен почеток за почетници во C++. Мал е, интересен и добро организиран.

Беа потребни околу шест месеци за да се развие оваа игра. Пишував главно за време на ручек и закуски на работа. Седеше во канцелариската кујна, газеше по храната и напиша код. Или дома за вечера. Така добив такви „кујнски војни“. Како и секогаш, активно користев тетратка и во неа се родија сите концептуални работи.

На крајот од практичниот дел, ќе извадам неколку скенови од мојот тетратка. За да покажам што точно запишувам, цртав, броев, дизајнирав…

Дизајн на слика на резервоарот. И дефиницијата за тоа колку пиксели треба да зафаќа секој резервоар на екранот

Пресметка на алгоритам и формули за ротација на резервоарот околу неговата оска

Дијаграм на мојата колекција (онаа со истекување на меморијата, најверојатно). Колекцијата е креирана како Поврзана листа

И ова се залудни обиди да се зафрли вештачката интелигенција во играта

Теорија

„Дури и патување од илјада милји започнува со првиот чекор“ (древна кинеска мудрост)

Да преминеме од пракса во теорија! Како наоѓате време за вашето хоби?

1. Определете што навистина сакате (за жал, ова е најтешко).
2. Поставете приоритети.
3. Жртвувајте ги сите „излишни“ заради повисоките приоритети.
4. Движете се кон вашите цели секој ден.
5. Не очекувајте дека ќе има два или три часа слободно време за некое хоби.

Од една страна, треба да одредите што сакате и да дадете приоритет. Од друга страна, можно е да се напуштат некои случаи/проекти во корист на овие приоритети. Со други зборови, ќе мора да жртвувате се што е „излишно“. Слушнав некаде дека во животот треба да има најмногу три главни активности. Тогаш ќе можете да се справите со нив на најдобар можен начин. И дополнителни проекти/насоки ќе почнат да преоптоваруваат корни. Но, сето ова е, веројатно, субјективно и индивидуално.

Постои одредено златно правило: никогаш немајте 0% ден! Научив за тоа во една статија од инди програмер. Ако работите на некој проект, тогаш правете нешто околу него секој ден. И не е важно колку ќе заработите. Напишете еден збор или една линија код, гледајте едно видео за упатство или зачукајте една шајка во таблата - само направете нешто. Најтешкиот дел е да започнете. Откако ќе започнете, веројатно ќе направите малку повеќе отколку што сте сакале. Така постојано ќе се движите кон својата цел и, верувајте, многу брзо. На крајот на краиштата, главната кочница за сите работи е одолговлекувањето.

И важно е да запомните дека не треба да ја потценувате и игнорирате бесплатната „струготина“ на времето за 5, 10, 15 минути, да чекате некои големи „трупци“ кои траат час или два. Дали стоите во ред? Размислете за нешто за вашиот проект. Се качуваш по ескалаторот? Запишете нешто во тетратка. Дали јадете во автобус? Добро, прочитајте некоја статија. Искористете ја секоја можност. Престанете да гледате мачки и кучиња на YouTube! Не се плеткајте со мозокот!

И последното. Ако, откако ја прочитавте оваа статија, ви се допадна идејата за создавање игри без користење на мотори за игри, тогаш запомнете го името Кејси Муратори. Овој човек има веб-страница. Во делот „гледајте -> ПРЕТХОДНИ ЕПИЗОДИ“ ќе најдете неверојатни бесплатни видео упатства за тоа како да креирате професионална игра од нула. Можеби ќе научите повеќе во пет лекции за Вовед во C за Windows отколку во пет години студирање на универзитетот (некој напиша за ова во коментарите под видеото).

Кејси исто така објаснува дека со развивање на сопствен мотор за игри, подобро ќе ги разберете сите постоечки мотори. Во светот на рамки, каде што сите се обидуваат да автоматизираат, ќе научите како да креирате, а не да користите. Разберете ја самата природа на компјутерите. И, исто така, ќе станете многу поинтелигентен и позрел програмер - професионалец.

Среќно на избраниот пат! И да го направиме светот попрофесионален.

автор: Гранкин Андреј, DevOps

Извор: www.habr.com