Які переваги забезпечує відкритий OpenGL над рамками / двигунами для невеликих розробників? [зачинено]

Я помітив тенденцію, коли інді-розробники відхиляються від рамок і двигунів і рухаються до використання чистого OpenGL або використовують його в поєднанні зі SDL / SFML2. Як інді-розробник, я не бачу, що може запропонувати OpenGL низького рівня для окремих двигунів або каркасів.

Більшість гідних двигунів і рамок надають потрібну вам функціональність і ніколи не заважають. Вони також можуть відкрити можливість безпосередньо працювати з OpenGL. Деякі навіть пропонують функціонал для складання крос-платформ!

Я розумію прагнення дізнатися, що відбувається під кришкою капота, але я не бачу жодних наслідків, які OpenGL може запропонувати інді-розробникам над двигунами чи рамками.

Не могли б ви пояснити міркування, що створюють ігри з нуля, використовуючи OpenGL?

Це багато в чому питання / відповідь на основі думки, тому насправді це не обов'язково ідеально для цієї платформи, але все одно:

Чому жодна рамка / двигун як інді? Ось два мої центи:

• Брак бюджету: це, мабуть, найбільший момент для більшості невеликих / інді-розробників. Багато рамок або двигунів не дозволять вам опублікувати свій товар, не купуючи дорожчої версії (якщо припустити, що у нас є дешева або безкоштовна версія) та / або сплатити гонорари, що завжди доведеться враховувати для невеликих проектів. Іноді вам навіть доводиться платити один раз за платформу.
• Складність: Більшість двигунів або рамок належать до однієї з двох категорій:
  • Вони або дуже обмежені для одного спеціального жанру ( RPG Maker є типовим прикладом).
  • Або ж ви просто занадто загальні з великою кількістю речей, які ви, швидше за все, не будете використовувати (як, наприклад, Єдність ).
• Власний код: Більшість двигунів не є відкритим кодом, і щоб отримати фактичне джерело, вам доведеться заплатити ще більше (якщо вони навіть є). Без фактичного перенесення вихідного коду на інші платформи може бути важким або навіть неможливим (знову ж таки, ідеальний приклад RPG Maker ).
• Клункість: Це моя особиста думка, але, принаймні, для мене це часто досить величезний занепад з урахуванням попередньо виготовлених двигунів та рамок, особливо коли ви будуєте лише невелику гру. Хто хоче пограти в невелику перерву, яка має розмір 200 КБ, але приносить з нею час виконання 50 Мб?
• Вибір мови: Деякі двигуни та рамки не надають бібліотекам для використання у власному коді. Натомість вони надають рамки або час виконання, які будуть використовувати власну мову сценаріїв або якусь задану мову (наприклад, Javascript або C #). Якщо ви пишете власний користувальницький механізм, ви можете користуватися будь-якою мовою, яку ви вибрали.
• Захист вашої роботи: Якщо ви використовуєте попередньо створений двигун або фреймворк, великі шанси на те, що інші можуть мати набагато простіший час змінити або декомпілювати ваш код або активи, чогось, можливо, захочете уникнути (навіть якщо це просто для того, щоб зберегти високий рейтинг чисто). Користувальницький код та обробка активів додають набагато більшу перешкоду, особливо коли вони складені в нативний код.
• Брендінг: це може бути незначним для багатьох, але деякі двигуни та рамки змушують вас показувати їх логотип або, можливо, навіть рекламу, по суті беручи на себе ваші свободи, щоб вибрати кого / що рекламувати. Звичайно, це часто залежить від фактичної ліцензії, плати за ліцензування тощо.
• Несумісність з ліцензіями: це те, що багато хто навіть не враховує при виборі двигуна, але залежно від того, що ви хочете зробити, це може бути головним фактором. Навіть якщо ви купуєте якийсь двигун, ви можете обмежувати розкриття будь-яких джерел чи пов'язаних матеріалів. Щось подібне може унеможливити модифікацію, навіть якщо ви хочете, щоб користувачі мали змогу. Візьмемо для прикладу джерело двигуна Valve ( Half-Life 2 , Team Fortress 2 тощо): вони дозволяють модникам використовувати свій двигун для власних проектів. Якщо б ці ігри базувалися на (наприклад) Unreal Engine, це було б неможливо через обмеження, передбачені умовами ліцензування.

Більшість гідних двигунів і рамок надають потрібну вам функціональність і ніколи не заважають.

Вони? Це швидше залежить від того, що саме ви робите, графічно кажучи.

Для багатьох видів ігор є стандартні відповіді на графічні запитання. Середня 2D гра, наприклад, може справлятися чудово за допомогою 2D-доблесті, наприклад, XNA / MonoGame. Це просто спрати, які можуть поставлятися партіями для місцевості, можна обертати тощо.

Але що робити, якщо ваша гра була середня 2D гра, ви читаєте про якусь прикольну техніку, наприклад використання карти висоти для створення саморобця, який має вигляд глибини відносно екрана. І ти хочеш це зробити.

Тепер ви використовуєте звичайне картографування і навіть можливо паралаксальне відображення. Все в тому ж контексті "справляння рендерінгу", але вимагає більше, ніж багато чистих двовимірних двигунів. Зокрема, для цього потрібні багатосмугові «спрайтові бликітки», що не те, що можна зробити у багатьох двовимірних двигунах.

Що ви робите, якщо ваш двигун не може адаптуватися до вас? Отже, це означає, що ви повинні зробити кілька проходів, один для кольорового та один для освітлення за допомогою звичайної карти. Але це не працює, тому що вам потрібно нормальне поле висоти карти, щоб використовувати паралаксальне відображення для пошуку кольорів. Отже ... тепер що? Вам потрібна альфа для прозорості, тому ви не можете вкрасти альфу. А двигун просто не підтримує багатотексти.

Отже, ви повинні вибрати одне з наступного:

1. Відмовитися від ідеї. Це означає, що ваша гра функціонально обмежена вашим двигуном.
2. Злому двигуна, щоб мати багатотекстовий. Припускаючи, що у вас є доступ до вихідного коду, ви тепер берете його на себе, щоб зазирнути на чужий код. Це також означає, що вам потрібно підтримувати його, а не порушувати його зі спотиканням.
3. Робіть все можливе, в межах обмежень двигуна. Таким чином, ви можете отримати паралакс на звичайних картах, але не на кольорах. Це може бути не саме те, що ви хотіли, але це краще, ніж нічого.

В якості прикладу візьміть війни "Геометрія". Більшість 2D-двигунів змогли б витягнути подібні відеозображення, оскільки більшість з них побудовані навколо малювання спрайтів, а не ліній. Це гра, яка потребує дуже спеціалізованого виду візуалізації.

Зрештою, вам потрібно взяти на себе відповідальність за елементи вашої гри, важливі для потреб вашої гри. Якщо візуальний вигляд вашої гри в першу чергу розробляється за допомогою художнього стилю зображень та моделей, які ви використовуєте, а не конкретних ефектів, то використання попередньо упакованого рішення чудово. Але якщо візуальний стиль вашої гри значно визначений спеціальним кодом візуалізації, шанси на те, що стандартний двигун може стати серйозним обмеженням, якщо ви вирішите робити речі, що знаходяться поза коробкою.

Крім того, є дуже практичне питання: не всі ігрові двигуни однаково портативні.

З недавнім підйомом мобільних платформ, ринок ігор поширився на численних ОС та пристроях інтерфейсу користувача. Не всі двигуни працюють на всіх пристроях. І якщо ваш двигун не працює на платформі, ви , звичайно , не збираєтеся взяти час , щоб зробити його роботу на одному. Зрештою, саме тому ви в першу чергу використовували двигун, правда?

Якщо вам важливо, що ваша гра працює на певній платформі, то вам знову потрібно взяти на себе відповідальність за неї. І "найпростіший" спосіб забезпечити успіх у цьому - це зробити самостійно. Щоб створити двигун, який може працювати на декількох платформах, можливо, використовуючи більш прості рамки, орієнтовані на платформу, де потрібно для обробки деяких деталей низького рівня. Таким чином, якщо він порушиться, це ваш код; ти найкраща людина, яка зможе це виправити.