DevOps C++ и "кухненските войни", или как започнах да пиша игри, докато ям

"Знам, че нищо не знам" Сократ

За кого: за IT хора, които плюят всички разработчици и искат да играят техните игри!

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

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

Здравей! Името ми е Андрей Гранкин, аз съм DevOps в Luxoft. Разработването на приложения не е моята работна специалност, но се опитвам да кодирам всяка седмица. Защото обичам игрите!

Индустрията на компютърните игри е огромна, дори повече слухове днес от филмовата индустрия. Игрите се пишат от началото на развитието на компютрите, като се използват, според съвременните стандарти, сложни и основни методи за разработка. С течение на времето започнаха да се появяват двигатели за игри с вече програмирани графики, физика и звук. Те ви позволяват да се съсредоточите върху развитието на самата игра и да не се притеснявате за нейната основа. Но заедно с тях, с двигателите, разработчиците "ослепяват" и деградират. Самото производство на игри се поставя на конвейер. И количеството на продукцията започва да надделява над нейното качество.

В същото време, когато играем игри на други хора, ние постоянно сме ограничени от локации, сюжет, герои, игрови механики, които са измислили други хора. Така разбрах, че...

… време е да създадете свои собствени светове, подчинени само на мен. Светове, в които Аз съм Отец, и Син, и Свети Дух!

И аз искрено вярвам, че като напишете свой собствен двигател за игри и игра върху него, ще можете да отворите очите си, да избършете прозорците и да изпомпате кабината си, ставайки по-опитен и цялостен програмист.

В тази статия ще се опитам да ви разкажа как започнах да пиша малки игри на C / C ++, какъв е процесът на разработка и къде намирам време за хоби в натоварена среда. Той е субективен и описва процеса на индивидуален старт. Материал за невежеството и вярата, за личната ми картина на света в момента. С други думи, "Администрацията не отговаря за вашите лични мозъци!".

Практика

"Знанието без практика е безполезно, практиката без знание е опасна." Конфуций

Моят бележник е моят живот!

Така че на практика мога да кажа, че всичко за мен започва от тетрадка. Там записвам не само ежедневните си задачи, но и чертая, програмирам, проектирам блок-схеми и решавам задачи, включително математически. Винаги използвайте бележник и пишете само с молив. Това е чисто, удобно и надеждно, IMHO.

Моят (вече попълнен) бележник. Ето как изглежда. Съдържа ежедневни задачи, идеи, чертежи, диаграми, решения, черно счетоводство, код и т.н.

На този етап успях да завърша три проекта (това е според моето разбиране за „окончателност“, защото всеки продукт може да се разработва относително безкрайно).

• Проект 0: това е Architect Demo 3D сцена, написана на C# с помощта на игровия двигател Unity. За macOS и Windows платформи.
• Игра 1: конзолна игра Simple Snake (известна на всички като "Snake") за Windows. написано на C.
• Игра 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. Този двигател не беше толкова взискателен към хардуера, колкото Нереалистичен двигател, а също така ми се стори по-лесен за инсталиране и използване. Други двигатели не съм разглеждал.

Целта в Unity за мен не беше да разработя някаква игра. Исках да създам 3D сцена с някакъв герой. Той, или по-скоро Тя (аз моделирах момичето, в което бях влюбен =) трябваше да се движи и да взаимодейства с външния свят. Беше важно само да разберем какво е Unity, какъв е процесът на развитие и колко усилия са необходими, за да се създаде нещо. Така се роди проектът Architect Demo (името е измислено почти от глупостите). Програмирането, моделирането, анимацията, текстурирането ми отнеха може би два месеца ежедневна работа.

Започнах с обучителни видеоклипове в YouTube за това как да създавам 3D модели в бъркачка. Blender е чудесен безплатен инструмент за 3D моделиране (и повече), който не изисква инсталация. И тук ме очакваше шок ... Оказва се, че моделирането, анимацията, текстурирането са огромни отделни теми, по които можете да пишете книги. Това важи особено за героите. За да моделирате пръсти, зъби, очи и други части на тялото, ще ви трябват познания по анатомия. Как са подредени мускулите на лицето? Как се движат хората? Трябваше да „вмъкна“ кости във всяка ръка, крак, пръст, кокалчета!

Моделирайте ключицата, допълнителни костни лостове, така че анимацията да изглежда естествена. След такива уроци разбирате каква огромна работа вършат създателите на анимационни филми, само за да създадат 30 секунди видео. Но 3D филмите продължават с часове! И тогава излизаме от кината и казваме нещо като: „Та, скапан анимационен филм / филм! Можеха да се справят по-добре…” Глупаци!

И още нещо за програмирането в този проект. Както се оказа, най-интересна за мен беше математическата част. Ако стартирате сцената (връзка към хранилището в описанието на проекта), ще забележите, че камерата се върти около героя на момичето в сфера. За да програмирам такова завъртане на камерата, трябваше първо да изчисля координатите на позицията на точката върху кръга (2D), а след това върху сферата (3D). Най-смешното е, че мразех математиката в училище и я знаех с минус. Отчасти вероятно, защото в училище просто не ви обясняват как, по дяволите, се прилага тази математика в живота. Но когато си обсебен от своята цел, мечта, тогава умът се избистря, разкрива! И започвате да възприемате сложните задачи като вълнуващо приключение. И тогава си мислите: „Е, защо *любимият* математик обикновено не можеше да каже къде могат да се опрат тези формули?“.

Изчисляване на формули за изчисляване на координатите на точка от окръжност и сфера (от моя бележник)

Игра 1

• платформа: Windows (тествано на Windows 7, 10)
• Език: Мисля, че е написано на чисто С
• Двигател на играта: Windows конзола
• Вдъхновение: javidx9
• Хранилище: GitHub

Проста игра със змия

3D сцената не е игра. Освен това моделирането и анимирането на 3D обекти (особено герои) е дълго и трудно. След като си поиграх с Unity, осъзнах, че трябва да продължа или по-скоро да започна от основите. Нещо просто и бързо, но в същото време глобално, за да разберете самата структура на игрите.

И какво имаме просто и бързо? Точно така, конзола и 2D. По-точно дори конзолата и символите. Отново започнах да търся вдъхновение в интернет (по принцип считам интернет за най-революционното и опасно изобретение на XNUMX век). Изрових видео на един програмист, който направи конзолен Tetris. И по подобие на играта си реши да посече "змията". От видеото научих за две фундаментални неща - цикъла на играта (с три основни функции / части) и изход към буфера.

Цикълът на играта може да изглежда така:

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

Директен изход към екрана на определен ред scoreLine (редът за показване на резултати):

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

На теория в тази игра няма нищо сложно, струва ми се добър пример за игра от начално ниво. Кодът е написан в един файл и е подреден в няколко функции. Няма класове, няма наследство. Вие сами можете да видите всичко в изходния код на играта, като отидете в хранилището на GitHub.

Игра 2 Crazy Tanks

• платформа: 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), координатите на началото на показване на изображението, неговата ширина / височина и изображението себе си под формата на растерно изображение (bitmap), представено от масив от байтове. Bitmap като масив от байтове!

Функцията 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_bitmapMemory 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 е тъмно сиво и т.н. По този начин можем да кажем, че имаме матрица на игралното поле, където всяко число е някакъв цвят.

И така, имаме цифрова матрица на цялото игрално поле от една страна и растерно изображение за показване на изображението от друга. Засега растерната карта е "празна" - все още няма информация за пикселите на желания цвят. Това означава, че последната стъпка ще бъде запълване на растерното изображение с информация за всеки пиксел въз основа на цифровата матрица на игралното поле. Илюстративен пример за такава трансформация е на снимката по-долу.

Пример за попълване на растерно изображение (Pixel matrix) с информация, базирана на числовата матрица (Digital matrix) на игралното поле (цветовите индекси не съвпадат с индексите в играта)

Ще представя и част от реален код от играта. На променливата 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() се формира нова картина (рамка). Вярно е, че обектите на играта може вече да имат различна позиция на игралното поле и съответно да са нарисувани на различно място. Ето как се случва анимацията (движението).

На теория (ако не сте забравили нещо), разбирането на цикъла на играта от първата игра („Snake“) и системата за показване на пиксели на екрана от втората игра („Tanks“) е всичко, което трябва да напишете. на вашите 2D игри за Windows. Беззвучен! 😉 Останалите части са просто полет на фантазия.

Разбира се, играта "Tanks" е проектирана много по-сложно от "Snake". Вече използвах езика C++, тоест описах различни игрови обекти с класове. Създадох моя собствена колекция - можете да видите кода в headers/Box.h. Между другото, колекцията най-вероятно има изтичане на памет. Използвани показалки. Работеше с памет. Трябва да кажа, че книгата ми помогна много. Начало на C++ чрез програмиране на игри. Това е страхотно начало за начинаещи в C++. Той е малък, интересен и добре организиран.

Разработването на тази игра отне около шест месеца. Пишех основно по време на обяд и закуски на работа. Той седеше в кухнята на офиса, тъпчеше храна и пишеше код. Или у дома за вечеря. Така че получих такива "кухненски войни". Както винаги, активно използвах тетрадка и всички концептуални неща се родиха в нея.

В края на практическата част ще извадя няколко сканирания от бележника си. Да покажа какво точно съм записвал, рисувал, броил, проектирал...

Дизайн на изображение на танк. И определението колко пиксела трябва да заема всеки резервоар на екрана

Изчисляване на алгоритъма и формулите за въртене на резервоара около оста му

Диаграма на моята колекция (най-вероятно тази с изтичането на паметта). Колекцията е създадена като свързан списък

И това са напразни опити да се вмъкне изкуствен интелект в играта

теория

„Дори едно пътуване от хиляда мили започва с първата стъпка“ (древна китайска мъдрост)

Да преминем от практика към теория! Как намирате време за вашето хоби?

1. Определете какво наистина искате (уви, това е най-трудното).
2. Поставете приоритети.
3. Пожертвайте всичко "излишно" в името на по-високите приоритети.
4. Движете се към целите си всеки ден.
5. Не очаквайте, че ще има два или три часа свободно време за хоби.

От една страна, трябва да определите какво искате и да подредите приоритетите си. От друга страна е възможно да се откажат от някои случаи/проекти в полза на тези приоритети. С други думи, ще трябва да пожертвате всичко "излишно". Чух някъде, че в живота трябва да има максимум три основни дейности. Тогава ще можете да се справите с тях по възможно най-добрия начин. И допълнителни проекти/посоки ще започнат да претоварват банално. Но всичко това вероятно е субективно и индивидуално.

Има определено златно правило: никога нямайте 0% ден! Научих за това в статия от независим разработчик. Ако работите по проект, правете нещо по въпроса всеки ден. И няма значение колко печелите. Напишете една дума или един ред код, изгледайте един обучителен видеоклип или забийте един пирон в дъската – просто направете нещо. Най-трудната част е да започнете. След като започнете, вероятно ще направите малко повече, отколкото сте искали. Така че постоянно ще се придвижвате към целта си и, повярвайте ми, много бързо. В крайна сметка основната спирачка за всички неща е отлагането.

И е важно да запомните, че не трябва да подценявате и пренебрегвате безплатните "стърготини" на времето в 5, 10, 15 минути, изчакайте едни големи "дръвници" с продължителност час-два. Стоиш ли на опашка? Помислете за нещо за вашия проект. Качваш ли се по ескалатора? Запишете нещо в тетрадка. Ядете ли в автобуса? Добре, прочетете някоя статия. Използвайте всяка възможност. Спрете да гледате котки и кучета в YouTube! Не си бъркайте в мозъка!

И последното. Ако, след като прочетете тази статия, ви хареса идеята за създаване на игри без използване на двигатели за игри, тогава запомнете името Кейси Муратори. Този човек има уебсайт. В раздела „гледайте -> ПРЕДИШНИ ЕПИЗОДИ“ ще намерите невероятни безплатни видео уроци за това как да създадете професионална игра от нулата. В пет урока от Intro to C за Windows може да научите повече, отколкото в пет години обучение в университета (някой писа за това в коментарите под видеото).

Кейси също обяснява, че като разработите свой собствен двигател за игри, вие ще имате по-добро разбиране за всички съществуващи двигатели. В света на рамките, където всеки се опитва да автоматизира, ще научите как да създавате, а не да използвате. Разберете самата природа на компютрите. Освен това ще станете много по-интелигентен и зрял програмист - професионалист.

Успех по избрания път! И нека направим света по-професионален.

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

Източник: www.habr.com