Каковы типичные подводные камни при написании игр на управляемом языке, таком как C #? [закрыто]

С какими подводными камнями вы столкнулись при написании игр для ПК на управляемом языке, таком как C #, и как вы их решили?

Я не очень разбираюсь в Java, так что это с точки зрения разработчика .net.

Самым большим на сегодняшний день является мусор. Сборщик мусора .NET в Windows делает фантастическую работу, и вы можете обойтись без присмотра за детьми по большей части. На Xbox / Windows Phone 7 это другое дело. Если каждые несколько кадров появляются остановки, сбор мусора может вызывать проблемы. В данный момент он срабатывает после каждого выделения 1 МБ.

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

• Нарисуйте содержимое GC.GetTotalMemory()на экране. Это дает вам приблизительное количество выделенных байтов в вашей игре. Если он едва двигается, у тебя все хорошо. Если все идет быстро, у вас есть проблемы.
• Попробуйте выделить все ваши объекты кучи заранее. Если вы не распределяете все до начала игры, каждый раз, когда вы набираете миллион мегапикселей, вы останавливаетесь. Нет выделений, нет коллекций. Так просто, как, что.
• После загрузки звоните GC.Collect(). Если вы знаете, что большинство ваших больших выделений не в порядке, приятно сообщить об этом системе.
• НЕ ЗВОНИТЕ GC.Collect()каждый кадр. Может показаться, что это хорошая идея - держать мусор и так далее, но помните, что только сбор мусора - сбор мусора.
• Ищите, откуда ваш мусор. Есть некоторые общие причины , как конкатенации строк вместо использования StringBuilder(будьте осторожны, StringBuilderэто не волшебная палочка, и все еще могут привести к распределению! . Это означает , что простые операции , как добавление номера в конец строки может создавать удивительные количества мусора) или использование foreachциклов над коллекциями, использующими IEnumerableинтерфейс, также может создавать мусор без вашего ведома (например, foreach (EffectPass pass in effect.CurrentTechnique.Passes)это распространенный случай)
• Используйте такие инструменты, как профилировщик памяти CLR, чтобы выяснить, где выделяется память. Есть множество учебных пособий о том, как использовать этот инструмент.
• Когда вы знаете, где вы располагаете во время игры, посмотрите, можете ли вы использовать такие приемы, как объединение объектов, чтобы уменьшить это количество.
• Если ничего не помогает, ваши коллекции будут работать быстрее! GC на компактной платформе следует каждой ссылке в вашем коде, чтобы выяснить, какие объекты больше не используются. Рефакторинг вашего кода используйте меньше ссылок!
• Не забудьте использовать IDisposableв классах, которые содержат неуправляемые ресурсы. Вы можете использовать их для очистки памяти, которую GC не может освободить самостоятельно.

Другая вещь, о которой нужно думать, это производительность с плавающей запятой. Хотя .NET JITer выполняет значительную часть оптимизаций для конкретного процессора, он не может использовать SSE или любые другие наборы команд SIMD для ускорения математики с плавающей запятой. Это может вызвать довольно большую разницу в скорости между C ++ и C # для игр. Если вы используете моно, у них есть некоторые специальные математические библиотеки SIMD, которыми вы можете воспользоваться.

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

Для C # использование объектов-значений и выражение «using» могут снизить давление со стороны GC.

Я бы сказал, что самой большой проблемой, с которой я столкнулся при написании игр на C #, было отсутствие приличных библиотек. Больше всего я обнаружил либо прямые порты, но неполные, либо обертки над библиотекой C ++, которые влекут за собой значительное снижение производительности при маршалинге. (Я говорю конкретно о MOgre и Axiom для библиотеки OGRE и BulletSharp для библиотеки физики Bullet)

Управляемые языки (в отличие от Interpreted - ни Java, ни C # на самом деле больше не интерпретируются) могут быть такими же быстрыми, как и родные языки, если вы хорошо понимаете, что на самом деле делает их медленными (маршалинг, сборка мусора). Реальная проблема, я думаю, в том, что разработчики библиотек еще не осознали этого.

Как уже говорили, паузы при сборе GC являются самой большой проблемой. Использование пулов объектов является одним из типичных решений.

C # и Java не интерпретируются. Они скомпилированы в промежуточный байт-код, который после JIT становится таким же быстрым, как и нативный код (или достаточно близким, чтобы быть незначительным).

Самая большая ловушка, которую я обнаружил, заключается в освобождении ресурсов, которые напрямую влияют на пользовательский опыт. Эти языки не поддерживают автоматически детерминированную финализацию, как это делает C ++, что, если вы не ожидаете, может привести к таким вещам, как сетки, плавающие по сцене после того, как вы думали, что они были уничтожены. (C # выполняет детерминированную финализацию через IDisposable , я не уверен, что делает Java.)

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

Ни Java, ни C # не интерпретируются. Оба они скомпилированы в машинный код.

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

Одна большая ловушка, которую я вижу в создании игр с такими языками (или с использованием таких инструментов, как XNA, TorqueX engine и т. Д.), Заключается в том, что вам будет сложно найти команду хороших людей, обладающих опытом, необходимым для создания игры, эквивалентной тому, что было бы довольно легко найти людей для C ++ и OpenGL / DirectX.

Индустрия игровых разработок все еще очень сильно погружена в C ++, так как большинство инструментов и конвейеров, которые используются для выталкивания больших или просто отточенных маленьких игр, были написаны на C ++, и, насколько я знаю, ВСЕ официальные наборы разработчика вы можете get для XBox, PS3 и Wii выпускаются только с совместимостью для C ++ (в настоящее время набор инструментов XBox может быть более управляемым, кто-нибудь знает больше?)

Если вы хотите разрабатывать игры для консолей прямо сейчас, вы в значительной степени получаете XNA и C # на XBox и только в боковой части библиотеки игр под названием XBox Live Indie Games. Тех, кто выигрывает конкурсы и т. Д., Выбирают для переноса своей игры на настоящую XBox Live Arcade. Кроме этого плана по созданию игры для ПК.