ЕЗЫГ МОЙ. Брейн-дамп номер 0. Что, кому, на какой платформе.
Геймдев моя самая любимая целевая аудитория. Для рантайма надо быстро писать очень быстро работающий код, с жесткими ограничениями по памяти. Для тулсов надо ещё быстрее писать очень быстро работающий код с несколько менее жесткими ограничениями по памяти. Технические задания мало того что невнятные, они ещё и меняются в процессе реализации.
Итерации важнее производительности, если в итоге производительности можно добиться. Как показывает практика, умеренно быстрый язык, который умеет edit&continue и встроенный ассемблер – решает. Решает куда больше, чем очень быстрый язык с 10-минутным билдом. Итерировать надо хотя-бы код, ресурсы можно итерировать уже на уровне реализации игры.
Итак «быстро итерируем сносный код». Этот сносный код потом придётся оптимизировать, но уже сразу он должен быть разумно работоспособным. Этот сносный код никак не может есть неочевидные количества памяти, т-е оверхед например на garbage collection не может расти экспоненциально, или превращать O(N) алгоритмы в O(N^2).
Этот сносный код надо не только писать, но и читать – хуже того, в нём надо чинить баги. Лучше, впрочем, чтобы они не возникали – для багов уже есть С++. Memory related баги хорошо можно лечить прямо на уровне языка – garbage collection и references нам в помощь. А ещё нам могут как-то помочь контракты, и валидаторы времени компиляции и выполнения – но только совсем простые, потому что сложные писать некогда. Как некогда писать сложные тесты – впрочем continues integration эту проблему частично решает.
Быстро писать – это значит легко пользоваться разными конструкциями языка для лаконичности и читаемости кода. Быстро писать – это быстро писать в комманде, т-е понимать чужие интерфейсы глядя на верх, и уметь внятно форсировать свои вниз. Если синтаксическая конструкция выражает концепцию, то её abuse – это вопрос отсутствия культуры, а не религии – нет смысла лечить такое недостатком фич.
Итак «солидный язык для солидных пацанов». Основной код пишут они, помогать надо им – остальных надо доучивать как-то. Средств разработки для экстенсивного роста уже предостаточно. В геймдеве нет проблем индийского аутсорса, и не будет – тут бы своим руки вправить.
В геймдеве, чтобы убежать от С++ надо бежать в сторону С++ – вот такой парадокс. Сегодня С++ это не язык, это платформа – с кучей готовых проверенных решений, наработок, традиций. С++ есть на всех консолях, все базовые библиотеки на нём. С этим кодом жить в любом случае, хотя-бы и переходный период.
Геймдев всегда в движении; учиться вообщем-то некогда. С-образный синтаксис (С#, Java) – неизбежное зло. Модные синтаксические конструкции можно добавлять сверху, но тривиальный код должен писаться С++ программистом без обучения вообще.
С++ вполне себе ассемблер, хотя и не без проблем. Проблемы, впрочем,
известные – и в моём понимании более чем решаемые. Т-е язык вполне может использовать С++ в качестве «умного» ассемблера, и дружить с С++ типами без интеграции.
Интеграция с ассемблером нужна в обе стороны. Т-е если в «языке» есть классы, то в С++ они представляют собой классы. Если есть garbage collection, то нужны шаблоны strongptr, weakptr, pinptr итд итп. Обратное также верно – если в С++ есть класс, то и в языке он должен быть представлен как unboxed type. Возможность написать boxed type целиком на С++ тоже нужна. Синтаксически интеграция с С++ должна быть минимальной. В идеале никаких специальных деклараций для типов не нужно, итд итп.
Резюмируем
* язык с С-образным синтаксисом
* дружит с С++, компилируется в него-же
* очень короткая итерация, edit&continue
* синтаксические концепции а не синтаксический сахар
«Правильные пацаны быстро итерируют осмысленно сложный сносный код»
