Здрастуйте. Не так давно у мене з'явився вільний час, який раптово збігся з часом, коли мені захотілося зробити щось своє, рідне.
А що свого може захотіти зробити рядовий програміст? Звичайно ж гру!
Під катом моя невелика історія, яку навряд чи можна назвати повчальною або надзвичайно захоплюючою, але, тим не менш...
Почалося все приблизно тиждень тому. У мене був в принципі чималий досвід програмування в цілому і не було практично ніякого досвіду в ігроделі. Десь рік-два тому я ставив собі Unity3D, щоб подивитися що це за звір, так що з засобів розробки було обрано єдине мені знайоме. Ще можна було б звичайно на канвасі все малювати, але, я вирішив, що, мабуть, не варто. Від цього початкового знайомства у мене залишилися якісь спогади про gameobjects, components і те, що можна зробити ортографічну камеру, щоб робити 2D гру в Unity3D. Як виявилося, в поточних версіях юніті (починаючи з 4.3) з'явилася підтримка 2D «з коробки», чому я невимовно зрадів. Тепер процес створення ігрового об'єкта зводиться до перетягування спрайту на сцену. Спрайт навіть скейлиться під різні екрани, правда я не знаю, по ширині він це робить, висоті або взагалі по площі (а може бути sqrt (площа)?).
Тут дуже страшний і негарний початковий начерк ігрового екрану.
Так, це замислювалося як платформер у стилі доісторичної Impossible Game.
Намальовано ЦЕ було в пориві натхнення, коли я раптом вирішив, що мені все під силу. Показав його парі чоловік, зняв рожеві окуляри і почав думати. Оскільки бюджет на розробку був виділений ніякий, то на роль художника/дизайнера була визначена моя 12-річна сестра.
Тут перерисуваний їй приклад. Мені здається стало краще. А то що графіка дитяча, так адже ігри роблять для дітей, так?
Отже, почався процес розробки.
Велика помилка
Першу помилку я зробив практично відразу ж, коли задумався про конструктор рівнів. Після деяких роздумів до мене дійшло, що сама по собі юніті являє собою чудовий конструктор. І ось після додавання на сцену всіх потрібних об'єктів в потрібних місцях, після того, як рівень був грабельний і відтестований, я запустив це на своєму неслабі nexus 5 і побачив fps близько 5-10. Виявилося, що не було дуже хорошою ідеєю додати на сцену відразу всі approx 400 об'єктів-перешкод. Так були написані 2 скрипти, один з яких зчитував всі об'єкти, їх положення і кут повороту зі сцени і записував все в текстовий файл, а другий надалі зчитував цей файл і створював об'єкти на льоту, коли підходив їх час. Зараз одночасно може існувати 50 об'єктів і нексус відчув себе цілком здорово, чого не можна було сказати про jiayu g2.
Велика помилка два
Тут потрібно зауважити, з чого ж почалася розробка. Почав я з самого на мій погляд простого - з динамічного фону. Тобто. у нас є 2 спрайти, які йдуть один за одним, і коли той який зліва ховається з виду, він переставляється вправо і нескінченний конвеєр з двох спрайтів продовжує рух. І саме це стало причиною подальшої грубої помилки - я рухав не гравця щодо фону, а навпаки. Відповідно коли стали з'являтися нові об'єкти, вони теж рухалися разом з фоном, а гравець продовжував покоїтися по осі Х. А тут потрібно сказати спасибі ось цьому списку з 46 помилок, що найбільш часто зустрічаються. Виявляється, що не можна рухати collider (компонент, що відстежує зіткнення) без rigidbody (компонент, який схильний до всіх законів фізики; ну або не зовсім всім). Тобто. у своїх порадах цей список доходить навіть до того, що якщо подібні об'єкти створюються з коду, то потрібно їх спочатку створити, потім перемістити куди потрібно і тільки після цього навішувати на них collider. А у мене всі перешкоди в грі якраз і являють собою colliders без rigidbody. І враховуючи те, що фон рухається відносно гравця... Загалом, довелося переробляти. Тепер рухаються тільки гравець і камера і на jiayu g2 гра теж працює досить плавно.
Не така велика помилка
Були й менш масштабні промахи. Наприклад, враховуючи ось таке розташування коллайдерів:
З яких нижній відстежував дотик ногами землі і все добре, а верхній призводив до швидкої і болісної смерті, було неприпустимо, щоб гравець проскакував крізь перешкоду і торкався її верхнім колайдером. При цьому в налаштуваннях є відповідний чекбокс, який встановлює continuous detection, тобто, здавалося б, якраз те що нам потрібно. Але це працює тільки з фізикою, якби гравець стрибав і падав за фізичними законами, а тут цього допускати не можна, тому що в такому випадку рано чи пізно з'являться зміщення при стрибках і гравець буде падати тоді, коли він робить все правильно.
У підсумку зараз при падінні запускаються 2 промені, ось таких ось:
Якщо один промінь стикається з землею, а другий з шипом, то зараховується дотик до землі. А фініш, наприклад, пріоритетніший за землю. Так і обчислюються дотики.
Звук
За музику велике спасибі добрим людям з fma, які поширюють її по creative commons.
Підсумки
Фух. Вільний час добігає кінця, у мене є деякий завершений проект (зазвичай всі починання зупиняються десь посередині). Про юніті, враховуючи початковий багаж знань, я тепер знаю практично в нескінченну кількість разів більше, але цього все ще дуже мало. Мене все ще не покидає відчуття, що все це можна було зробити куди простіше і красивіше.
І ось тут, загалом-то, сама гра - тинць.
Мало не забув! В Android'e починаючи з версії 4.4 став доступний запис відео з екрану через adb. Так що я зміг за хвилин 10 в мувімейкері зістряпати якесь відео.
P.S. Всім, хто дочитав до цього місця, величезне спасибі!
Вам може здатися, що це маленька поробка на кілька годин, але я витратив на неї тиждень свого часу, причому навряд чи це був такий стандартний робочий тиждень, швидше це нагадувало останній день перед дедлайном. Щодня. Хоча ні, найбільше це схоже на хакатон довжиною на тиждень, по. Загалом, поїхав я на природу, відновлюватися. Всім ще раз спасибі за увагу, я виговорився.
