Было бы полезно, если бы вы кратко объяснили, что дало вам эту идею, так как это очень странная идея, если не сказать больше.
Конрад Рудольф
2
Учитывая, что Quake сделано в C .. ;-)
Коммунистическая Утка
Мне самому просто был интересен этот вопрос!
Джефф
2
Похоже, под «индустриальными играми» вы подразумеваете то, что обычно называют «титулы ААА».
хаос
Ответы:
53
В некотором смысле, 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 ++, по крайней мере, до тех пор, пока кто-нибудь не изобрел память с мгновенным доступом без задержки.
+1 Visual Studio - очень хорошая IDE. Даже если это темная сторона ...
Майкл Коулман
1
Бах, по моему опыту, C # недостаточно быстр для симуляции, но это не мешает людям пытаться.
BigSandwich
@Nevermind Что такое "управляемые языки"?
Quazi Irfan
3
@iamcreasy В широком смысле под «управляемыми языками» я подразумеваю языки, которые работают на виртуальной машине, которая включает в себя некоторую форму сбора мусора и / или управления памятью. Точнее говоря, управляемые языки - это языки, предназначенные для (некоторой реализации) Common Language Runtime, но мой ответ применим не только к ним.
Nevermind
По вашему мнению, схемы ГК с подсчетом ссылок попадают в эту категорию по выбору?
weberc2
6
Выбор языка сильно зависит от платформы. В настоящее время кажется маловероятным, чтобы что-либо, кроме платформы Microsoft, фактически требовало .NET в качестве реализации.
Принято считать, что небольшая платформа должна быть близко к металлу, чтобы обеспечить ее производительность, но, с другой стороны, управляемые платформы более безопасны . Это, вероятно, причина, по которой Windows Phone 7 заставляет вас использовать .NET.
Конечно, было бы интересно, если бы новый Xbox требовал управляемой платформы. Если аппаратное обеспечение телефона может справиться с этим (и оно справляется), я, безусловно, смогу увидеть его, используя его на полноразмерной консоли. Это немного расшевелит консольную экосистему, так как будет сложнее писать кроссплатформенные игры без написания всего кода игры на языке сценариев. Если это так, то C # не заменит C ++, но будет идти рука об руку.
Прямо сейчас вы можете использовать Mono в качестве серверной части для сценариев (аналогично тому, что делает Unity), но я бы предположил, что большинство производителей движков либо захотят накатить свои собственные, либо использовать что-то более компактное, например Lua или Python, чем C #.
В любом случае, это все о правильном инструменте для правильной работы. В любом случае вы действительно должны изучать оба языка, поскольку C # облегчает выполнение определенных задач (разработка инструментов, разработка серверов и т. Д.), И в некоторых случаях вы не можете использовать ничего, кроме C ++.
На данный момент, 3 года спустя, состояние C # для разработки игр гораздо более развито. Mono-Project взял XNA Game Studio и переименовал ее в MonoGame. SharpDX, SlimDX и OpenTK - все очень приличные обертки opengl / directx. Еще несколько физических движков в c # появились. Mono / MonoGame позволяет вам создать игру один раз и автоматически перенести ее на Android, Linux, Mac OS, IOS, Xbox 360, PS3, PS4 и Wii.
Райан Манн
3
Это маловероятно. Преимущество C ++ заключается в низком уровне, так что разработчики могут настроить тончайшие детали для достижения максимальной производительности.
С C # и .NET у вас есть сборка мусора, которая очень полезна, но при работе с платформами с ограниченной памятью и ресурсами (портативные консоли и в некоторой степени домашние консоли) вам нужно иметь как можно больше контроля над памятью, чтобы наилучшим образом использовать ресурсов. Разрешение управляемым языкам выделять и освобождать память для вас, скорее всего, вызовет у вас много проблем.
Скорость также является проблемой (хотя, вероятно, не так). Со временем я уверен, что управляемые языки могли бы работать так же, как компиляторы C ++.
В целом, по моему опыту, разработчики игр, как правило, склонны к контролю, когда дело доходит до памяти, процессорного времени и ресурсов (чтобы выжать как можно больше производительности), поэтому C / C ++ - это в основном используемые языки.
AFAIK .NET GC по-прежнему страдает от остановки алгоритма мирового стиля. Хотя это может быть подходящим для широкого спектра приложений - это неприемлемо для приложений реального времени, таких как игры.
На самом деле, очень сложно эффективно использовать управляемые языки для программ реального времени, пока у нас не появятся какие-то прорывы в GC.
Нет. В зависимости от .NET может потребоваться массовая перезапись для платформ без доступной платформы, таких как PS3, и недостатки производительности могут быть вполне приемлемы для ПК или для игр с живой аркадой, но более крупным играм потребуется каждый клочок производительность от своих приставок для запуска достаточно быстрая. Более того, в C ++ существуют огромные базы кода, которые никто не мог позволить себе обновить, даже если бы захотел. C ++ находится в игровой индустрии и будет оставаться там долгое время.
Хотя инерция существует, кодовые базы C ++ сами по себе не так уж стары - возможно, максимум 10 лет. За этот период почти весь код в них подвергся замене - для 3D-ускорителей, программируемых конвейеров, управляемых данными архитектур и поддержки сценариев. Если разработчик AAA хотел бы выполнить полную миграцию на C #, он мог бы, вероятно, выполнить это за минимальные затраты в течение трех игр - сначала использовать его в качестве инструмента и хоста сценариев, затем перенести на него слои игровой логики и третий порт. средство визуализации для использования управляемой оболочки DX / GL.
1
У Mono есть коммерческое решение .NET для PS3.
Дэн Олсон
Во-вторых, если вы строите свою игру на C # против моно или с моногамой (замена XNA), вы можете перенести ее на встроенные PS3 / PS4, Wii, Xbox 360, Android, Max OS и т. Д.
Райан Манн,
0
В периоды, когда вычислительная мощность компьютеров ограничена, все должно быть запрограммировано на C или C ++ просто потому, что языки со сборкой мусора отнимают контроль над памятью у программиста, и, следовательно, производительность может падать.
В настоящее время компьютеры работают быстрее, но, как говорит Кнут и, говоря кратко, оптимизация может быть зла:
очевидно, что низкоуровневые функции ядра должны быть оптимизированы, потому что вычисление трехмерной геометрии, физики, столкновений, освещения может быстро раздуть лучший доступный процессор. Вы можете легко сказать, что повышение визуального качества на машине почти всегда значительно снижает производительность.
Теперь есть и другие функциональные возможности, такие как игровые состояния, ИИ, звук, ввод, сеть, которые все еще важны в игре, но вряд ли когда-нибудь потребуют столько компьютерных ресурсов. Эти функции в большинстве случаев не нужно оптимизировать. Это цель языка сценариев и языков сборки мусора: вам не нужно думать о согласованности памяти и организации вашего приложения, потому что код, который вы будете писать на этих языках, если вы не будете кодировать низкоуровневые вещи, никогда не будет узкое место.
Пример с 2 случаями
Отправьте 500 кг мебели с помощью грузовика.
Отправьте 30 тонн материала на лодке.
оба находятся на расстоянии 500 км.
В обоих случаях имеет значение ускорить процесс погрузки / разгрузки, чтобы сократить все время транспортировки, зная, что вы НЕ МОЖЕТЕ заставить лодку или грузовик двигаться быстрее?
Ответ таков: это имело значение для грузовика, но больше не для лодки, потому что вы уже многое сделали, перемещая запас с лодкой.
Я не знаю, понимаете ли вы эту метафору, но в некотором смысле она может заставить вас представить математическую проблему, которая важнее, чем понимание ответа.
Языки сценариев позволяют делать игры быстрее, если у вас уже есть движок, запрограммированный на C / C ++: движок 3D решает проблемы низкого уровня, теперь вы должны сделать игру со своими скриптами.
Но помните: вы никогда не сможете заменить низкоуровневый скомпилированный язык, НИКОГДА. Статически типизированные, скомпилированные языки являются основой производительности, и вы НЕ МОЖЕТЕ исключать их, будь то ядро, 3D-движок или драйвер графической карты.
Но, конечно, если ваша игра графически проста и не требует большого количества векторных вычислений, вы можете сосредоточиться на игровом процессе и забыть об оптимизации, потому что в этом случае вам никогда не придется иметь дело с оптимизацией, поскольку ваша машина действительно быстра для этого
За исключением случаев, когда вы планируете портировать ir на DS. Но я на этом остановлюсь.
«Оптимизация может быть злом» - безусловно, самая бесполезно видоизмененная версия его заявления, которое я когда-либо читал.
Ну, я объясняю это, поэтому я нашел бесполезным цитировать его все высказывание, которое является довольно длинным предложением и на самом деле не объясняется ... Кроме того, мы говорим об играх, что не одно и то же. более широкий софт, о котором Кнут хотел говорить.
Jokoon
Вы упоминаете, что ввод почти никогда не занимает много компьютерных ресурсов. Я хотел бы отметить, что, поскольку игрок становится более физически связанным с игрой, это становится менее правдивым. Например, кинект. Это форма ввода, но для ее использования требуется много вычислительных ресурсов.
Ponkadoodle
0
Слушай, я знаю, что это напыщенная речь, но я не просто ломаю волосы. Я чувствую, что большинство программистов этого не делают. Сам язык не имеет никакого отношения к скорости выполнения / производительности. Это компилятор / фреймворк. Вы могли бы лучше поспорить gcc против cl (компилятор Microsoft до 2010 года) или msbuild (текущий компилятор c ++ для 2010 года). Каждый выпуск этих компиляторов становится лучше, поэтому вам также нужно сравнивать их с предыдущими версиями самих себя. Я очень впечатлен .net, и он работает хорошо, но даже если он был немного лучше, я не вижу, чтобы он взял верх, одна из причин: мобильность.
AAA-игры хотят быть на Windows, Linux, Mac, XBox, PS3, Nintendo и т. Д.
Конечно, реализация компилятора играет свою роль, но разные языки предоставляют разные возможности для оптимизации, управляемой компилятором, и разные возможности для программистов обходить обычные языковые правила и напрямую общаться с оборудованием. Язык и цель сами по себе имеют много общего с производительностью.
Язык может иметь непосредственное отношение к скорости выполнения / производительности, потому что синтаксис и стандартные библиотеки будут благоприятствовать различным подходам. Например, язык, в котором трудно использовать массивы смежной памяти из-за того, что все их объекты являются указателями, будет стремиться перегружать кэш намного больше, чем тот, где вы можете эффективно использовать массивы или векторы.
Kylotan
+1 очень хороший момент, который вы могли бы сделать, не оскорбляя глупых людей, они не знают, кто они.
Fire Crow
За исключением того, что на сегодняшний день вы можете строить против моно и он портирует практически все. Например, теперь это очень портативный.
Ответы:
В некотором смысле, 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 км.
В обоих случаях имеет значение ускорить процесс погрузки / разгрузки, чтобы сократить все время транспортировки, зная, что вы НЕ МОЖЕТЕ заставить лодку или грузовик двигаться быстрее?
Ответ таков: это имело значение для грузовика, но больше не для лодки, потому что вы уже многое сделали, перемещая запас с лодкой.
Я не знаю, понимаете ли вы эту метафору, но в некотором смысле она может заставить вас представить математическую проблему, которая важнее, чем понимание ответа.
Языки сценариев позволяют делать игры быстрее, если у вас уже есть движок, запрограммированный на C / C ++: движок 3D решает проблемы низкого уровня, теперь вы должны сделать игру со своими скриптами.
Но помните: вы никогда не сможете заменить низкоуровневый скомпилированный язык, НИКОГДА. Статически типизированные, скомпилированные языки являются основой производительности, и вы НЕ МОЖЕТЕ исключать их, будь то ядро, 3D-движок или драйвер графической карты.
Но, конечно, если ваша игра графически проста и не требует большого количества векторных вычислений, вы можете сосредоточиться на игровом процессе и забыть об оптимизации, потому что в этом случае вам никогда не придется иметь дело с оптимизацией, поскольку ваша машина действительно быстра для этого
За исключением случаев, когда вы планируете портировать ir на DS. Но я на этом остановлюсь.
источник
Слушай, я знаю, что это напыщенная речь, но я не просто ломаю волосы. Я чувствую, что большинство программистов этого не делают. Сам язык не имеет никакого отношения к скорости выполнения / производительности. Это компилятор / фреймворк. Вы могли бы лучше поспорить gcc против cl (компилятор Microsoft до 2010 года) или msbuild (текущий компилятор c ++ для 2010 года). Каждый выпуск этих компиляторов становится лучше, поэтому вам также нужно сравнивать их с предыдущими версиями самих себя. Я очень впечатлен .net, и он работает хорошо, но даже если он был немного лучше, я не вижу, чтобы он взял верх, одна из причин: мобильность.
AAA-игры хотят быть на Windows, Linux, Mac, XBox, PS3, Nintendo и т. Д.
источник