Заменяется ли C ++ на C # в индустриальных играх?

В индустриальных играх я имею в виду Quake, CoD и т. Д.

В некотором смысле, C ++ действительно заменяется - не только C #, но и множеством других языков. Но если вы спросите, будет ли он заменен полностью - тогда ответ определенно нет .

Это потому, что C ++ традиционно используется в двух направлениях. Во-первых, создать игровой движок : низкоуровневые компоненты, которые загружают ресурсы, подталкивают полигоны к экрану и сокращают числа в симуляциях физики. Во-вторых, для кодирования игровой логики : актуальные правила, которые делают игровой процесс.

Эта вторая емкость не требует сильных сторон C ++ (таких как полный контроль над деталями низкого уровня), но страдает от своих слабостей (таких как подверженное ошибкам управление памятью вручную). И в этом втором качестве C ++ заменяется различными языками сценариев. Многие разработчики используют Lua; некоторые используют Python. Но если доступна платформа CLI, в форме .NET или Mono, она является отличным кандидатом для хостинга сценариев. Эти платформы довольно быстрые, надежные, предлагают широко известный язык (C #) и обширную библиотеку базовых классов. Давайте не будем забывать инструменты: MS Visual Studio и SharpDevelop / MonoDevelop могут быть не самыми лучшими IDE в мире, но они довольно хороши.

Тем не менее, игровой движок не будет написан на C # (или Lua, или Python в этом отношении). Зачем? Потому что они просто недостаточно быстрые.

Вопреки многим распространенным убеждениям, самый большой удар по производительности сегодня связан с задержкой памяти . Это означает, что доступ к памяти - серьезное дело. А управляемые языки не позволяют пользователю контролировать доступ к памяти - именно поэтому они «управляются» в первую очередь. Итак, ни один управляемый язык не позволит написать действительно быстрый игровой движок. На самом деле, все большие движки "C #", о которых я могу думать - XNA, MOGRE, Unity - основаны на собственном коде C ++; но позвольте написать игровую логику на C #.

Подводя итог : C # будет использоваться вместо C ++ или других языков. Но он никогда не заменит C ++, по крайней мере, до тех пор, пока кто-нибудь не изобрел память с мгновенным доступом без задержки.

Выбор языка сильно зависит от платформы. В настоящее время кажется маловероятным, чтобы что-либо, кроме платформы Microsoft, фактически требовало .NET в качестве реализации.

Принято считать, что небольшая платформа должна быть близко к металлу, чтобы обеспечить ее производительность, но, с другой стороны, управляемые платформы более безопасны . Это, вероятно, причина, по которой Windows Phone 7 заставляет вас использовать .NET.

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

Прямо сейчас вы можете использовать Mono в качестве серверной части для сценариев (аналогично тому, что делает Unity), но я бы предположил, что большинство производителей движков либо захотят накатить свои собственные, либо использовать что-то более компактное, например Lua или Python, чем C #.

В любом случае, это все о правильном инструменте для правильной работы. В любом случае вы действительно должны изучать оба языка, поскольку C # облегчает выполнение определенных задач (разработка инструментов, разработка серверов и т. Д.), И в некоторых случаях вы не можете использовать ничего, кроме C ++.

Это маловероятно. Преимущество C ++ заключается в низком уровне, так что разработчики могут настроить тончайшие детали для достижения максимальной производительности.

С C # и .NET у вас есть сборка мусора, которая очень полезна, но при работе с платформами с ограниченной памятью и ресурсами (портативные консоли и в некоторой степени домашние консоли) вам нужно иметь как можно больше контроля над памятью, чтобы наилучшим образом использовать ресурсов. Разрешение управляемым языкам выделять и освобождать память для вас, скорее всего, вызовет у вас много проблем.

Скорость также является проблемой (хотя, вероятно, не так). Со временем я уверен, что управляемые языки могли бы работать так же, как компиляторы C ++.

В целом, по моему опыту, разработчики игр, как правило, склонны к контролю, когда дело доходит до памяти, процессорного времени и ресурсов (чтобы выжать как можно больше производительности), поэтому C / C ++ - это в основном используемые языки.

AFAIK .NET GC по-прежнему страдает от остановки алгоритма мирового стиля. Хотя это может быть подходящим для широкого спектра приложений - это неприемлемо для приложений реального времени, таких как игры.

На самом деле, очень сложно эффективно использовать управляемые языки для программ реального времени, пока у нас не появятся какие-то прорывы в GC.

Нет. В зависимости от .NET может потребоваться массовая перезапись для платформ без доступной платформы, таких как PS3, и недостатки производительности могут быть вполне приемлемы для ПК или для игр с живой аркадой, но более крупным играм потребуется каждый клочок производительность от своих приставок для запуска достаточно быстрая. Более того, в C ++ существуют огромные базы кода, которые никто не мог позволить себе обновить, даже если бы захотел. C ++ находится в игровой индустрии и будет оставаться там долгое время.

В периоды, когда вычислительная мощность компьютеров ограничена, все должно быть запрограммировано на C или C ++ просто потому, что языки со сборкой мусора отнимают контроль над памятью у программиста, и, следовательно, производительность может падать.

В настоящее время компьютеры работают быстрее, но, как говорит Кнут и, говоря кратко, оптимизация может быть зла:

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

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

Пример с 2 случаями

• Отправьте 500 кг мебели с помощью грузовика.
• Отправьте 30 тонн материала на лодке.

оба находятся на расстоянии 500 км.

В обоих случаях имеет значение ускорить процесс погрузки / разгрузки, чтобы сократить все время транспортировки, зная, что вы НЕ МОЖЕТЕ заставить лодку или грузовик двигаться быстрее?

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

Я не знаю, понимаете ли вы эту метафору, но в некотором смысле она может заставить вас представить математическую проблему, которая важнее, чем понимание ответа.

Языки сценариев позволяют делать игры быстрее, если у вас уже есть движок, запрограммированный на C / C ++: движок 3D решает проблемы низкого уровня, теперь вы должны сделать игру со своими скриптами.

Но помните: вы никогда не сможете заменить низкоуровневый скомпилированный язык, НИКОГДА. Статически типизированные, скомпилированные языки являются основой производительности, и вы НЕ МОЖЕТЕ исключать их, будь то ядро, 3D-движок или драйвер графической карты.

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

За исключением случаев, когда вы планируете портировать ir на DS. Но я на этом остановлюсь.

Слушай, я знаю, что это напыщенная речь, но я не просто ломаю волосы. Я чувствую, что большинство программистов этого не делают. Сам язык не имеет никакого отношения к скорости выполнения / производительности. Это компилятор / фреймворк. Вы могли бы лучше поспорить gcc против cl (компилятор Microsoft до 2010 года) или msbuild (текущий компилятор c ++ для 2010 года). Каждый выпуск этих компиляторов становится лучше, поэтому вам также нужно сравнивать их с предыдущими версиями самих себя. Я очень впечатлен .net, и он работает хорошо, но даже если он был немного лучше, я не вижу, чтобы он взял верх, одна из причин: мобильность.

AAA-игры хотят быть на Windows, Linux, Mac, XBox, PS3, Nintendo и т. Д.