ПОРАДА АМАТЕЮРА
// Від нуля до аматорського за роки навчання
Я б неодмінно тримався осторонь таких двигунів високого рівня, як Unity або Torque2D MIT. Вони чудово підходять для невеликих прототипів, але я б ніколи не сприймав їх серйозно для розробки власної відеоігри. Чому б я? Який сенс, якщо це був не що інше, як простий SideScroller чи аркад аркад?
Більшість ігрових двигунів, бібліотек або фреймворків виконують не що інше, як найпростіші завдання з цілим набором роздутого коду з функціями та функціями, які ви ніколи не будете використовувати.
Коли я був новим у розробці ігор років тому, я стартував на вершині. Двигуни дуже високого рівня. Не щось надто високо, як RPG MAKER, але, безумовно, високо там, як Unity та Torque. Потім я пішов нижче, до XNA та C #, тому що в ньому було стільки ресурсів та навчальних посібників. Моєму первинному проекту була потрібна продуктивність, або, можливо, я просто нав’язливо-компульсивний щодо того, щоб хотіти неймовірної продуктивності у своєму програмному забезпеченні, навіть якщо це не великий проект. XNA її просто не вирізала, і у мене було багато проблем з двигуном, який я прочитав, потрібен головний біль, щоб виправити. Який сенс використовувати щось "вищого рівня", наприклад, XNA / C #, коли ви робите ту саму роботу (виправляючи помилки та проблеми XNA), як і для прокатки власного двигуна в C ++?
Після деякого часу навчання я зрештою дізнався про те, як ігрові двигуни розроблені, і почав вивчати код самих двигунів. Читаючи, що має сказати більшість професіоналів, і скарги критиків ігрових двигунів змусили мене зрозуміти: "Навіщо навіть використовувати двигун?"
Випрацювання мого C ++ і дійсно втручання в деякі філософії, які використовуються цією мовою, мені дуже допомогли. Однак я витратив стільки часу на те, щоб дізнатися про стільки, що просто хотів почати робити гру.
Тож я закінчив щось із досить великою похвалою, був C ++ та дуже низьким рівнем: SDL. На жаль, це був головний біль. Це настільки низький рівень, я бачу, що немає жодної причини, чому навіть використовувати цю бібліотеку. Я вважаю за краще просто вивчити OpenGL і робити це з нуля. Чесно кажучи, саме той факт, що мені потрібно було реалізувати власний код, щоб зробити щось таке ж базове, як перевернути зображення (а інша реалізація не спрацювала через те, як я обробляю спрайти), що привело мене до сміття SDL назавжди. Чудово, якщо ви хочете візуалізувати програмне забезпечення, але IMO, я б краще спустив його, щоб знизитись на апаратному рівні (OpenGL) або вище (SFML).
Не бажаючи купувати ще одну книгу на Amazon та вивчати ще один API, я пішов вище. SFML просто чудовий, не кажучи вже про високо оцінену в усьому Інтернеті. Я прочитав майже нескінченну кількість позитивних відгуків, поруч із жодним негативом. Я не можу сказати те саме для SDL. Він обробляє всі крайні основи, а решту залишає за мною та іншими бібліотеками, які я вибрав. Я з цим застряг.
ІМО, ігровий движок просто дурний. Бібліотеки низького рівня - це набагато кращий вибір як для експертів, так і для початківців програмістів.
Також слід зазначити, що я дізнався більше про концепції програмування та посилив свої навички розробки програмного забезпечення, коли був змушений працювати з речами на нижчому рівні, ніж я коли-небудь вчився з ігровими двигунами високого рівня WYSIWYG.
Що щось на зразок Єдності дає тобі за XNA? Візуальне редагування та милиця. Зрештою, новачки дізнаються, що вам все одно доведеться кодувати всю гру так само, як і коли б у вас був C ++, а візуальні редактори неефективні для того, що ви могли б створити самостійно.
Що щось на зразок XNA дає вам над SFML або вашою власною реалізацією OpenGL та інших корисних бібліотек? ІМО, абсолютлей нічого хорошого. Гірша продуктивність, C # замість C ++, безліч навчальних посібників для новачків, але значно менше професіоналізму, а також деякі головні болі врятують, що IMO вкотре є лише сутичкою для того, що ви просто повинні вчитися на C ++. Мене спочатку залякували C ++ і полюбив C #, здебільшого через чути і чути думки дурнів, які мали ті самі неприємності, що і у мене з початком C ++: я просто хотів досить хорошого програміста. Я зрозумів, що потрібно вивчити більше основ і посилити свої слабкі сторони, щоб подолати неприємності, які виникли у мене з C ++, які C # "полегшили". Я коли-небудь пропускаю простоту деяких речей у C #? Навіть не! Я знаю, як це зробити в C ++ без клопоту.
Якщо бібліотеки низького рівня або навчання DirectX / OpenGL залякують вас, тоді просто зачекайте, поки ви почнете вникати в складність створення повноцінної відеоігри.
Мою філософію щодо ігрових двигунів можна підсумувати на двох прикладах, що пояснюють надмірність та непотрібність двигунів, за винятком окремих ситуацій.
У новачків, яких залякують бібліотеки низького рівня, буде захоплено, коли вони виявлять, що навіть при такому двигуні високого рівня, як Unity, (окрім візуалізації графіки, відтворення аудіо, завантаження вмісту; реальні основні речі), це буде майже ідентично створення гри з нуля. Складність полягає в розробці гри, не розумінні API або розробці класів для відображення на дисплеї.
Експерти, яких не залякує складність створення повноцінної гри у чомусь на зразок Unity, не користується Unity, оскільки час, протягом якого потрібно впевнено вивчити API та вимоги конкретного двигуна, ймовірно, більше болить голова і більше часу, ніж знадобиться для кодування кількох класів, необхідних для виконання основ.
Тому двигуни марні для новачків, тому що новачки не можуть нічого зробити з ними, оскільки їм не вистачає інженерних навичок. Крім того, двигуни марні для ветеранів, тому що вони вже мають інженерні навички робити це без двигуна, і, можливо, також зможуть розгорнути власний більш ефективний, специфічний «двигун», ніж переживати головний біль вивчення API API ігрового двигуна, функції та динаміки продуктивності. Не кажучи вже про величезний кошмар роботи з двигунами, до яких іноді не можна торкатися, оскільки вони не є відкритим кодом (або навіть якщо вони є, читання чужого коду часом може бути кошмаром).
Хек, навіть деякі "ігрові рамки" низького рівня "- це не що інше, як кілька класів для створення вікна, відображення на дисплеї та відтворення аудіо. Це те, що професіонал може зробити з нуля, використовуючи інші бібліотеки, такі як SDL / SFML або власну реалізацію OpenGL / DirectX / OpenAL, за частку часу, який потрібно для фактичного завершення повноцінної відеоігри.
TLDR;
Якщо ви хочете програмувати, навчіться бути програмістом .
Уникайте використання двигунів , але не будьте дурнем і ігноруйте неймовірно корисні бібліотеки.
Якщо ви хочете бути дизайнером ігор , спробуйте движок WYSIWYG та викачайте ці ігри!
Якщо ви хочете бути ігровим програмістом , уникайте таких двигунів, як милиця.
Для мене використання ігрових двигунів вищого рівня калічило мою здатність стати програмістом. Щойно я почав використовувати бібліотеки нижчого рівня або взагалі не користуватися будь-якою бібліотекою, я почав так багато вчитися, що швидко перейшов від новачків до когось, хто тепер може створювати відеоігри без будь-яких довідок, навчальних посібників чи книг поряд зі мною. Просто мій компілятор і багато техніки та практики.
Обсяг навчання, який я здобув у бібліотеках низького рівня за КОРОТКИЙ час, був набагато більшим, ніж кількість, яку я здобув за ДУЖЕ ДОЛГУ кількість часу з ДВИГАТЕЛЯМ вищого рівня **.