Здравствуйте, yxiie, Вы писали:

Y>Здравствуйте, Mika Soukhov, Вы писали:

MS>>Может я не внятно выразился, но я хотел бы увидеть список синтаксических преимуществ языков, использующиеся в скриптах для разработки игр, перед языками, использьзующиеся в разработке ПО.

Y>я же где-то здесь уже упоминал про нестрогую типизацию со товарищи...

Я аккумулирую все недостатки. Итого получилось в отношении к C# следующие минусы:

1) Нужно знать атрибуты.
2) Нужно знать неймспейсы.
3) Нужно знать про стогую типизацию.
4) Потенциально опасный код.

Есть еще? Если нет, то я бы хотел продолжить насчет ЛУА и JS.

+

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

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

Нужно знать атрибуты.

Здесь я не согласен. Во-первых, знать их вовсе не нужно, равно как не нужно их и использовать. Тут выбор ложиться на сторону разработчиков ПО: давать необходимость скриптерам писать их в коде или нет.

Во-вторых. Насколько я помню, в FarCry использовалась Lua. И как я помню, там были выражения такого вида:

BindCommand(MyCommand, MyCommandHandler);

MyCommandHandler()
{
}

Чем это отличается от такого выражения (по сложности понимания)?

[BindCommand(MyCommand)]
MyCommandHandler()
{
}

Думаю, что ничем.

Нужно знать неймспейсы.

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

Нужно знать про стогую типизацию.

Здесь я опять не согласен. Что такого слабая типизация. Это означает, что создается некий тип во время интерпритации, который умеет делать какие то базовые вещи. Если к такому типу привести недопутимое значение, по получается ошибка во время исполнения. Это мое первое не согласие того, что скриптеру намного удобнее увидеть ошибку сразу, чем запускать его код каждый раз на исполнение. Например:

MyCommandHandler()
{
  var муха = ПолучитьМуху();
  ПередатьКотлету(муха);
}

Такой код синтаксически верен, но не будет работать (муха и котлета смешались).

Второе не согласие — в том, что в коде вовсе не нужно использовать никакие приведения (а значит, разница между сильной и слабой типизацией отсутсвует), если использовать высокую абстракцию. Чем отличаются нижеприведенные два кода:

MyCommandHandler()
{
  var муха1 = ПолучитьМуху();
  var муха2 = ПолучитьМуху();
  return муха1 + муха2;
}

Муха MyCommandHandler()
{
  Муха муха1 = ПолучитьМуху();
  Муха муха2 = ПолучитьМуху();
  return муха1 + муха2;
}

Я думаю ничем.

Потенциально опасный код.

Здесь я и согласен, и нет. Да, на C# можно получить доступ к таким сущностям, как Process, Thread и т.д. Но в чем не согласие. Во-первых, часто в обсуждении можно было слышать о квалификации скриптера. Если скриптер не высокого уровня, то вряд ли вообще он узнает о таких вещах. Во-вторых, никто не запрещает разработчику запретить использовать те или иные типы (для тех кто знаком с .NET, я имею ввиду не CAS, а обычное сканирование кода, например, через FxCop).

под Lua написана уже реализация вирутальной машины

Под .NET она есть изначально (вернее, ее подобие).

Далее мне хотелось привести преимущества .NET над всеми Lua и JS, но я понял, что сегоднышнего дня мне вряд ли хватит, чтобы это перечислять, да и выбор собственно идет между LUA.NET и C#

MS>Далее мне хотелось привести преимущества .NET над всеми Lua и JS, но я понял, что сегоднышнего дня мне вряд ли хватит, чтобы это перечислять, да и выбор собственно идет между LUA.NET и C#

Ну ты дал... Выходит уже все игры делают на .NET?
Серьезные игры под .NET появятся только тогда, когда .NET framework будет для всех существующих платформ, и ни часом раньше.

Здравствуйте, Mika Soukhov, Вы писали:

Собственно использовать .net для скриптов можно и даже оптимально, если .net уже используется.

В противном случае использовать для скриптов .net как-то глупо, по крайней мере, пока .net нету везде и всюду гарантированно. Я собственно и JScript microsoft'овский побоялся бы использовать, опасаясь разных версий в разных местах и т.д.

Здравствуйте, Рома Мик, Вы писали:

РМ>Здравствуйте, Mika Soukhov, Вы писали:

РМ>Собственно использовать .net для скриптов можно и даже оптимально, если .net уже используется.

Некоторые вещи я не обяснял, надеясь на профессионализм собеседников.

РМ>В противном случае использовать для скриптов .net как-то глупо, по крайней мере, пока .net нету везде и всюду гарантированно.

Насчет везде и всюда. Можете привести показатели заполненности платформ продуктами от русскоязычного Разработчика? Очень интересно, как такие компании наподобии Нивал распространяют свои продукты.

Здравствуйте, Mika Soukhov, Вы писали:

MS>Здравствуйте, Рома Мик, Вы писали:

РМ>>Здравствуйте, Mika Soukhov, Вы писали:

РМ>>Собственно использовать .net для скриптов можно и даже оптимально, если .net уже используется.

MS>Некоторые вещи я не обяснял, надеясь на профессионализм собеседников.
-1

РМ>>В противном случае использовать для скриптов .net как-то глупо, по крайней мере, пока .net нету везде и всюду гарантированно.

MS>Насчет везде и всюда. Можете привести показатели заполненности платформ продуктами от русскоязычного Разработчика? Очень интересно, как такие компании наподобии Нивал распространяют свои продукты.
Это про что? Ты имеешь в виду стоит ли на targe computer .NET? нет, не PS и XBox не стоит

Здравствуйте, Evgeniy13, Вы писали:

E>Здравствуйте, Mika Soukhov, Вы писали:

MS>>Здравствуйте, Рома Мик, Вы писали:

РМ>>>Здравствуйте, Mika Soukhov, Вы писали:

РМ>>>Собственно использовать .net для скриптов можно и даже оптимально, если .net уже используется.

MS>>Некоторые вещи я не обяснял, надеясь на профессионализм собеседников.
E>-1

Evgeniy13, я вижу что вы активно пытаетесь утвердить свою точку зрения, и повлиять ее на осуждения других людей. Я не буду учавствовать в дискуссии с вами, если вы будете продолжать в том же ключе (это мое право). Но мне бы хотелось услышать слова "зрелых" специалистов по данному вопрос. Пока что я услышал стоящее только от одного человека, yxiie. Надеюсь, что здесь есть еще специалисты.

РМ>>>В противном случае использовать для скриптов .net как-то глупо, по крайней мере, пока .net нету везде и всюду гарантированно.

MS>>Насчет везде и всюда. Можете привести показатели заполненности платформ продуктами от русскоязычного Разработчика? Очень интересно, как такие компании наподобии Нивал распространяют свои продукты.
E>Это про что? Ты имеешь в виду стоит ли на targe computer .NET? нет, не PS и XBox не стоит

Тоесть, ни одна русская компания не портировала свои программы на консольную платформу?

MS>Evgeniy13, я вижу что вы активно пытаетесь утвердить свою точку зрения, и повлиять ее на осуждения других людей. Я не буду учавствовать в дискуссии с вами, если вы будете продолжать в том же ключе (это мое право). Но мне бы хотелось услышать слова "зрелых" специалистов по данному вопрос. Пока что я услышал стоящее только от одного человека, yxiie. Надеюсь, что здесь есть еще специалисты.
Я не переходил на личности — первым это сделал ты!
Как минимум политика этого форума не дает тебе право рассуждать о "зрелости" собеседников. Так что я бы попросил принять это к сведению.

MS>>>Насчет везде и всюда. Можете привести показатели заполненности платформ продуктами от русскоязычного Разработчика? Очень интересно, как такие компании наподобии Нивал распространяют свои продукты.
E>>Это про что? Ты имеешь в виду стоит ли на targe computer .NET? нет, не PS и XBox не стоит
MS>Тоесть, ни одна русская компания не портировала свои программы на консольную платформу?
Портировала, но никто не писал на .NET.

PS
Чем оскорблять, лучше аргументированного обоснуй свою точку зрения.

Здравствуйте, Evgeniy13, Mika Soukhov, Вы писали:

Здравствуйте, Mika Soukhov, Вы писали:

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

MS>Нужно знать про стогую типизацию.

MS>Здесь я опять не согласен. Что такого слабая типизация. Это означает, что создается некий тип во время интерпритации, который умеет делать какие то базовые вещи. Если к такому типу привести недопутимое значение, по получается ошибка во время исполнения. Это мое первое не согласие того, что скриптеру намного удобнее увидеть ошибку сразу, чем запускать его код каждый раз на исполнение. Например:
...
MS>Второе не согласие — в том, что в коде вовсе не нужно использовать никакие приведения (а значит, разница между сильной и слабой типизацией отсутсвует), если использовать высокую абстракцию. Чем отличаются нижеприведенные два кода:

MS>

MS>MyCommandHandler()
MS>{
MS>  var муха1 = ПолучитьМуху();
MS>  var муха2 = ПолучитьМуху();
MS>  return муха1 + муха2;
MS>}
MS>

MS>

MS>Муха MyCommandHandler()
MS>{
MS>  Муха муха1 = ПолучитьМуху();
MS>  Муха муха2 = ПолучитьМуху();
MS>  return муха1 + муха2;
MS>}
MS>

MS>Я думаю ничем.

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

MS>Потенциально опасный код.

MS>Здесь я и согласен, и нет. Да, на C# можно получить доступ к таким сущностям, как Process, Thread и т.д. Но в чем не согласие. Во-первых, часто в обсуждении можно было слышать о квалификации скриптера. Если скриптер не высокого уровня, то вряд ли вообще он узнает о таких вещах. Во-вторых, никто не запрещает разработчику запретить использовать те или иные типы (для тех кто знаком с .NET, я имею ввиду не CAS, а обычное сканирование кода, например, через FxCop).

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

MS>под Lua написана уже реализация вирутальной машины

MS>Под .NET она есть изначально (вернее, ее подобие).

честно говоря не понял, что это за преимущество/недостаток, да и Lua я не особо люблю.

MS>Далее мне хотелось привести преимущества .NET над всеми Lua и JS, но я понял, что сегоднышнего дня мне вряд ли хватит, чтобы это перечислять, да и выбор собственно идет между LUA.NET и C#

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

чтобы вы не подумали, что я только теоретизирую, хочу сказать, что я сейчас как раз открываю фирму, которая будет заниматься разработкой игр под Windows/Mac, и я планирую у себя реализовывать подобную стратегию разработки. не думаю, что буду делать так сразу, но стремиться к такому варианту буду однозначно.

надеюсь высказался не очень сумбурно

Здравствуйте, yxiie, Вы писали:

Y>Эта вся типизация таким людям просто не понятна. Они еще могут немного понять, что в переменную можно заносить и извлекать значения, но все эти типы и преобразования это уже слишком высокий уровень для таких людей.
Y>как неоспоримый плюс — подобные сотрудники *очень* дешево обходились.

Допустим так. А если им не обяснять, что это такое, а просто сказать: "Пишите так и никак по другому"?

Y>но тут в голове всплыло — все эти лишние сущности из шарпа, которые в скрипт-языке не нужны усложняют обучение и понимание новичками. пример обучения JavaScript — купил человеку книжку по JavaScript, он ее прочитал и паралельно используя как справочник может спокойно писать код. тоесть в процессе обучения никто не задействован — человек сам выучит. В случае с шарпом все гораздо сложнее, сам язык тяжелее для понимания, нельзя просто купить книгу и дать человеку для изучения, т.к. в ней много ненужных для такого скриптера вещей. замечу мы говорим не о переучении программиста на шарп, а обучение непрограммиста скрипту.

Как вариант — написать свою документацию. Описать ключевые слова, use cases. Пропустить сложне конструкции.

MS>>под Lua написана уже реализация вирутальной машины

MS>>Под .NET она есть изначально (вернее, ее подобие).

Y>честно говоря не понял, что это за преимущество/недостаток, да и Lua я не особо люблю.

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

Y>чтобы объективно сравнивать предлагаю идти с правильной стороны, тоесть со стороны денег, ведь любая коммерческая деятельность предполагает получение прибыли.

+ выяснить, какого размера будет бизнес.

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

Для маленькой компании использовать .NET в разработке игр (я так понимаю, и игры будут небольшие) не даст преимуществ. Для большой — позволит сократить время разработки самого ядра.

Y>чтобы вы не подумали, что я только теоретизирую, хочу сказать, что я сейчас как раз открываю фирму, которая будет заниматься разработкой игр под Windows/Mac, и я планирую у себя реализовывать подобную стратегию разработки. не думаю, что буду делать так сразу, но стремиться к такому варианту буду однозначно.

Тоесть найм большого количества персонала с низкими знаниями взамен малого количества персонала с высокими?

Здравствуйте, Mika Soukhov, Вы писали:

MS>Здравствуйте, yxiie, Вы писали:

Y>>Эта вся типизация таким людям просто не понятна. Они еще могут немного понять, что в переменную можно заносить и извлекать значения, но все эти типы и преобразования это уже слишком высокий уровень для таких людей.
Y>>как неоспоримый плюс — подобные сотрудники *очень* дешево обходились.

MS>Допустим так. А если им не обяснять, что это такое, а просто сказать: "Пишите так и никак по другому"?

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

Y>>но тут в голове всплыло — все эти лишние сущности из шарпа, которые в скрипт-языке не нужны усложняют обучение и понимание новичками. пример обучения JavaScript — купил человеку книжку по JavaScript, он ее прочитал и паралельно используя как справочник может спокойно писать код. тоесть в процессе обучения никто не задействован — человек сам выучит. В случае с шарпом все гораздо сложнее, сам язык тяжелее для понимания, нельзя просто купить книгу и дать человеку для изучения, т.к. в ней много ненужных для такого скриптера вещей. замечу мы говорим не о переучении программиста на шарп, а обучение непрограммиста скрипту.

MS>Как вариант — написать свою документацию. Описать ключевые слова, use cases. Пропустить сложне конструкции.

боюсь это не как вариант, а как обязательный минимум который придется сделать. но нужно не просто написать документацию, а сделать ее доходчивой и понятной, это уже будет совсем не сухой Tech Doc

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

MS>Для маленькой компании использовать .NET в разработке игр (я так понимаю, и игры будут небольшие) не даст преимуществ. Для большой — позволит сократить время разработки самого ядра.

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

также неизвестно, хорошо ли это нам поможет в разработке ядра, т.к. .нет не для игр рассчитан. да и что подразумевать под ядром? думаю лучшим решением в большинстве случаев будет купить какие-то сторонние технологии и сконцентрироваться на разработке непосредственно игры.
Кроме того есть вещи типа boost, которые позволяют заменить реально нужные вещи из шарпа типа boost::intrusive_ptr, большая же чать .net framework в игре использоваться врядли будет.

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

Y>>чтобы вы не подумали, что я только теоретизирую, хочу сказать, что я сейчас как раз открываю фирму, которая будет заниматься разработкой игр под Windows/Mac, и я планирую у себя реализовывать подобную стратегию разработки. не думаю, что буду делать так сразу, но стремиться к такому варианту буду однозначно.

MS>Тоесть найм большого количества персонала с низкими знаниями взамен малого количества персонала с высокими?

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

Здравствуйте, yxiie, Вы писали:

MS>>Допустим так. А если им не обяснять, что это такое, а просто сказать: "Пишите так и никак по другому"?

Y>эээ... не понял. вспомните как вы только начинали программировать, думаю многие вещи, которые сейчас кажутся смешными вызывали реальные трудности в освоении. в JS этих трудностей *намного* меньше.

В том то и дело, что не говорить, зачем это нужно, а сказать, что мол так надо. Если вызываете этот метод, то переменная должна называться MyType name1.

MS>>Как вариант — написать свою документацию. Описать ключевые слова, use cases. Пропустить сложне конструкции.

Y>боюсь это не как вариант, а как обязательный минимум который придется сделать. но нужно не просто написать документацию, а сделать ее доходчивой и понятной, это уже будет совсем не сухой Tech Doc

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

Y>подытожу какие тут возникают проблемы:
Y>- проблемы с кадрами, об этом я писал в паралельной теме

Лично мне кажется, что профессионал на С++ дороже C#. Хотя я могу ошибаться, но я исхожу из той точки зрения, что на С++ очень сложно вести разработку.

Y>- проблемы с библиотеками, тоже писал паралельно, добавлю, что это могут быть дополнительные затраты на адаптацию С++ библиотек или разработку своих, или же нам придется использовать заведомо неоптимальные библиотеки.

Смотря каких библиотек. Если спрайтовая графика — то на шарпе есть уже реализации.

Y>- невозможность портировать игру.

Да, на Мак вряд ли уйдет.

Y>также неизвестно, хорошо ли это нам поможет в разработке ядра, т.к. .нет не для игр рассчитан.

Я думаю в играх разница между .NET и С++ не большая. Нужно помнить, что лишь .NET — это не ява.

Y>да и что подразумевать под ядром? думаю лучшим решением в большинстве случаев будет купить какие-то сторонние технологии и сконцентрироваться на разработке непосредственно игры.

Видел я сторонние технологии. Частенько попадались аж со своих языком + редактором

Y>Кроме того есть вещи типа boost, которые позволяют заменить реально нужные вещи из шарпа типа boost::intrusive_ptr, большая же чать .net framework в игре использоваться врядли будет.

Тоесть, тут вы согласны, что .NET >> boost

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

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

Y>не думаю что больше взамен меньше, а основной акцент именно на низкоквалифицированный персонал, который позволит создавать приемлемое качество.

Заинтриговало. А как именно?

Y>тоесть снижение кадровых рисков + снижение уровня интелектуализации программирования до уровня конвеера.

=) Количество рисков за счет чего уменьшается?

MS>В том то и дело, что не говорить, зачем это нужно, а сказать, что мол так надо. Если вызываете этот метод, то переменная должна называться MyType name1.
Зачем, если уже есть работающий код и человек, способный писать новый код и поддерживать старый?

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

MS>Лично мне кажется, что профессионал на С++ дороже C#. Хотя я могу ошибаться, но я исхожу из той точки зрения, что на С++ очень сложно вести разработку.
Это зависит от проблем, которые решает программист.

MS>Смотря каких библиотек. Если спрайтовая графика — то на шарпе есть уже реализации.
Существование библиотек и оптимальность — разные вещи.

Y>>также неизвестно, хорошо ли это нам поможет в разработке ядра, т.к. .нет не для игр рассчитан.
MS>Я думаю в играх разница между .NET и С++ не большая. Нужно помнить, что лишь .NET — это не ява.
.NET — платформа, а не язык. И при чем здесь ява?
И разница большая — скорость. (скорость исполнения)

Y>>да и что подразумевать под ядром? думаю лучшим решением в большинстве случаев будет купить какие-то сторонние технологии и сконцентрироваться на разработке непосредственно игры.
Это лишние расходы в бюджете игры, к тому же зачем покупать чужое, если есть свои наработки?

MS>Видел я сторонние технологии. Частенько попадались аж со своих языком + редактором
А что в этом плохого?

MS>Тоесть, тут вы согласны, что .NET >> boost
.NET != boost только и всего.

Y>>тоесть снижение кадровых рисков + снижение уровня интелектуализации программирования до уровня конвеера.
MS>=) Количество рисков за счет чего уменьшается?
Засчет простоты.

Здравствуйте, Mika Soukhov, Вы писали:

Y>>эээ... не понял. вспомните как вы только начинали программировать, думаю многие вещи, которые сейчас кажутся смешными вызывали реальные трудности в освоении. в JS этих трудностей *намного* меньше.

MS>В том то и дело, что не говорить, зачем это нужно, а сказать, что мол так надо. Если вызываете этот метод, то переменная должна называться MyType name1.

я же и говорю, что трудно так, особенно когда начинаются всякие преобразования типов.

MS>>>Как вариант — написать свою документацию. Описать ключевые слова, use cases. Пропустить сложне конструкции.

Y>>боюсь это не как вариант, а как обязательный минимум который придется сделать. но нужно не просто написать документацию, а сделать ее доходчивой и понятной, это уже будет совсем не сухой Tech Doc

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

не нужно, они сами учаться по существующим докам и туториалам.

Y>>подытожу какие тут возникают проблемы:
Y>>- проблемы с кадрами, об этом я писал в паралельной теме

MS>Лично мне кажется, что профессионал на С++ дороже C#. Хотя я могу ошибаться, но я исхожу из той точки зрения, что на С++ очень сложно вести разработку.

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

Y>>- проблемы с библиотеками, тоже писал паралельно, добавлю, что это могут быть дополнительные затраты на адаптацию С++ библиотек или разработку своих, или же нам придется использовать заведомо неоптимальные библиотеки.

MS>Смотря каких библиотек. Если спрайтовая графика — то на шарпе есть уже реализации.

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

Y>>также неизвестно, хорошо ли это нам поможет в разработке ядра, т.к. .нет не для игр рассчитан.

MS>Я думаю в играх разница между .NET и С++ не большая. Нужно помнить, что лишь .NET — это не ява.

если разница не большая, зачем тогда С# для этой цели нужен?

Y>>да и что подразумевать под ядром? думаю лучшим решением в большинстве случаев будет купить какие-то сторонние технологии и сконцентрироваться на разработке непосредственно игры.

MS>Видел я сторонние технологии. Частенько попадались аж со своих языком + редактором

давайте не будем опускатся до уровня каких-то мимолетных субъективных впечатлений, это не добавит полезности дискуссии.

Y>>Кроме того есть вещи типа boost, которые позволяют заменить реально нужные вещи из шарпа типа boost::intrusive_ptr, большая же чать .net framework в игре использоваться врядли будет.

MS>Тоесть, тут вы согласны, что .NET >> boost

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

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

MS>Подождите, так вы хочешь услугами не профессионалов не сами скрипты разрабатывать, но дажи и само ядро писать?

я такого не говорил.

Y>>не думаю что больше взамен меньше, а основной акцент именно на низкоквалифицированный персонал, который позволит создавать приемлемое качество.

MS>Заинтриговало. А как именно?

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

Y>>тоесть снижение кадровых рисков + снижение уровня интелектуализации программирования до уровня конвеера.

MS>=) Количество рисков за счет чего уменьшается?

за счет низкого уровня требований к кадрам.

Здравствуйте, Mika Soukhov, Вы писали:

MS>Тоесть, ни одна русская компания не портировала свои программы на консольную платформу?

Русских разрабочиков под консоли хватает. Вот только с .NET там большие проблемы. Более того, я сильно сомневаюсь, что хоть какие-то подобие .NET появится под PS3.