Когда вы должны запустить свой собственный игровой движок? [закрыто]

Я работаю разработчиком программного обеспечения уже 5 лет, и я хочу заняться разработкой игр для iOS. Я играл с iOS SDK около 2 лет, посещая встречи с какао-головами, и чувствую, что хорошо разбираюсь в target-c, какао и даже c и c ++.

У меня есть идея игры, и я знаю, что буду использовать Box2D, но мне интересно, стоит ли мне использовать cocos2D или нет. Основными причинами являются:

1. Возможно, я захочу сделать что-нибудь, что касается графики, чего нет в cocos2d.
2. Если я поверну свой собственный игровой движок, у меня будет больше контроля.

Конечно, главная причина использования уже существующего игрового движка - это время, которое он экономит, и это облегчает сложные вещи; но имеет ли это смысл для тех, у кого есть технические возможности?

Большинство других постов будут «сделать игру не движком», но я собираюсь предположить, что вы имеете в виду конкретную игру, которую хотите создать, и хотите знать, когда стоит начать с чужого кода база или начать с нуля.

Вы не должны бросать свои собственные технологии, если вы не знаете, что нужно делать свои собственные . Это может показаться легкомысленным, но это действительно единственный правильный ответ. Как и в большинстве решений, есть компромиссы. Только вы можете определить для вашей конкретной ситуации анализ затрат / выгод.

Вы должны иметь представление о следующих вещах (этот список вряд ли является всеобъемлющим).

• Какое промежуточное программное обеспечение уже существует, которое вы могли бы использовать («движок» или иное)
• Что это промежуточное программное обеспечение приносит на стол, функция мудрая.
• Насколько зрелым / проверенным является промежуточное ПО, особенно если вы заботитесь о мультиплатформенной поддержке
• Какие инструменты промежуточного программного обеспечения предоставляют или не предоставляют, чтобы помочь ускорить разработку (не сбрасывайте со счетов инструменты своими технологиями)
• Какие ограничения есть у промежуточного ПО (в качестве простого примера, Unity 3.x не создавал тени в реальном времени от динамических источников света на iOS)
• Какими специфическими особенностями должна обладать ваша конкретная игра .
• Каковы ваши крайние сроки и сколько времени вам придется потратить, чтобы добраться до точки, где промежуточное программное обеспечение доставит вас по сравнению с тем, сколько стоит промежуточное программное обеспечение.
• Насколько расширяемым является промежуточное программное обеспечение (например, вы можете обойти проблему теней на iOS в Unity с помощью теней BLOB-объектов. Или, возможно, теней проекции.)

(Обратите внимание, что я специально не поставил там «больше контроля». Это загруженная фраза, которая может варьироваться от «Мне не нравится код, который я не пишу» до «Мне нужно, чтобы я мог видеть, понимать и отрегулируйте все переменные в физическом движке для достижения этого конкретного эффекта. «Первый из них не совсем корректный, но второй - это).

Лично я считаю, что внедрение собственной технологии для малобюджетной игры вряд ли стоит усилий. Количество энергии, которую вы получаете дешевые двигатели в эти дни, смешно. Вы находитесь не в той точке, где вы выбираете многомиллионную лицензию на двигатель с тройным А или нет. Вы не сможете побить то, что, скажем, Unity предлагает вам за 3 тысячи долларов. Или Cocos2d за то, что это стоит (не бесплатно?).

Теперь, если ваша игра в основном сфокусирована на какой-то технологии, которую другие движки не могут предоставить или не могут предоставить с разумной частотой кадров, то, возможно, стоит изучить, что вы можете сделать. Это не значит, что вы полностью выбрасываете другое промежуточное ПО. То, что вам нужен собственный, скажем, рендерер, не означает, что вы не можете использовать какое-то другое промежуточное программное обеспечение для физики, звука, пользовательского интерфейса или чего-то еще.

Не катите свой собственный двигатель. Брось себе игру. Если вам приходится писать движок одновременно, то это хорошо для вас, если нет, то вы всегда можете реорганизовать любые детали, которые вы захотите использовать повторно, чтобы сделать его более похожим на движок.

Люди часто переоценивают, что нужно для написания «движка» части игры. Если вы делаете только то, что вам нужно, это не займет много времени. Сложная часть состоит в том, чтобы не зацикливаться на написании инфраструктуры и писать только то, что вам абсолютно необходимо для решения вашей проблемы.

Я бы использовал существующий двигатель, когда:

• У меня сжатые сроки
• У меня есть известный фиксированный набор функций, так что я могу выбрать двигатель для этого

Я думаю, что вы должны просто написать свою игру, и, возможно, позже у вас появится движок . Написание графического движка (и все это звучит так, как вы говорите) с нуля, без использования ничего, кроме OpenGL, скорее всего, только потратит ваше время. Это относительно хорошо решаемая проблема, поэтому в общем случае вы бы изменили форму API, не добавляя при этом значительных новых возможностей по сравнению с любым другим доступным сторонним решением.

Если Cocos2D или какой-либо другой графический слой соответствует вашим требованиям сейчас, используйте его. Если ваши требования меняются во время разработки, вы можете относительно легко поменять серверную часть рендеринга - если вы действительно уверены, что у вас есть опыт и средства для создания движка самостоятельно, у вас наверняка должно быть то, что нужно, чтобы структурировать свою игру таким образом, чтобы заменить ее. обратная сторона рендеринга является относительно тривиальной операцией.

Создайте свою игру, учитывайте ее специфические потребности, чтобы управлять набором функций кода, который вы пишете, и писать код с учетом возможности повторного использования и хорошей архитектуры Естественно, вы закончите с «движком» после того, как закончите несколько подобных проектов, и вы завершите эти проекты быстрее, потому что вы не позволяете себе увязнуть в крипах на уровне фреймворка.

Это очень просто Какова ваша основная цель: обучение или выход на рынок?

Избегайте использования библиотеки, если вашей основной целью является изучение опыта реализации концепций, решаемых библиотекой. Всякий раз, когда я разрабатываю игру (неполный рабочий день), моя цель - просто учиться. Мне все равно, сколько времени это займет, поэтому я делаю все это с нуля! Теперь вы решаете.

Вы должны запустить свой собственный игровой движок, когда вы знаете, что это необходимо .

Например, скажем, у вас нет денег, чтобы тратить на Unity. Или вместо этого лучше потратить его на новое оборудование. Либо есть проблемы с производительностью доступных вам бесплатных движков, либо вам нужно больше контролировать на низком уровне.

Если вы любите писать программное обеспечение ради написания программного обеспечения, то вам понравится писать игровой движок. Обычная ловушка начинающих программистов игры заключается в том, что они начинают писать движок как некий вечный проект. Я искренне верю, что так появились все игровые движки с открытым исходным кодом - программисты игр, которые на самом деле этого не делали.

Тогда в этом случае напишите свой собственный движок.