Языки программирования для разработки игр (1/3)
Что ж, недавно писал, что обучаться линейной алгебре надо на примере работы с компьютерной графикой.
Пойдём дальше и почти всерьёз обсудим, на чём стоит писать компьютерные игры. Решил для себя сделать краткий обзор полянок, думаю, будет интересен не только мне.
Обычно берут готовый движок, из которых три явно выделяются (перечисление от более хардкорного к более лояльному пользователю): Unreal, Unity, Godot.
На фоне этих трёх мейнстримных вариантов есть плеяда ушедших на второй план и почти забытых AAA-движков (Source, Cryengine, Serious Engine, etc.), которыми пользуются те кто давно в них вложился, и россыпь indie-вариантов. Из последних произвольно выделю Game Maker, использовал его ещё в школьные годы: одна из моих поделок даже случайно попала в какой-то болгарский компьютерный журнал. Примерно ту же нишу, насколько можно понять со стороны, занимают Construct, Cocos Creator и мн. др.
Для тех, кто хочет написать что-то более-менее с нуля или не хочет бороться с типовыми конвенциями движков, остаётся использование "графических библиотек" (ну или "игровых библиотек", т.е. графика + ввод-вывод + звуки) – кода, который поверх вызовов API операционной системы и низкоуровневых библиотек создаёт весьма тонкую абстракцию, чтобы вещи типа инициализации окна или создания камеры делались в одну строку (вместо череды API-вызовов операционной системы и перемножения трёх матриц соответственно).
Библиотек этих десятки на любой вкус и цвет, среди энтузиастов последнее время популярна Raylib. Так и пишут: создана для любителей программировать и желающих на практике разобраться, как работают видеоигры. Чуть более тонкие абстракции дают библиотеки SDL, GLFW и др.
На самом низком уровне находятся графические API. Долгое время их по сути было два: OpenGL (всеплатформенный) и DirectX (Windows + XBox). Консорциум, отвечающий за разработку OpenGL, объявил, что дальше его развивать не будет и все усилия направит на развитие Vulcan. На устройствах Apple свой Metal. В целом на будущее стоит осваивать Vulcan (а на настоящее и в качестве ностальгии – OpenGL).
Все основные вспомогательные библиотеки и сами графические API имеют C-интерфейсы. Все распространённые языки программирования так или иначе могут его использовать (называется FFI, foreign function invocation). Если использовать полновесный движок, то к нему уже прилагается и свой язык (C++ для Unreal, C# для Unity, собственный GDScript для Godot). Если спускаться на уровень ниже, то выбор пошире.
Языки программирования как художественная литература: кому-то нравится, кому-то нет, но в целом между творчеством бездарных писателей и произведениями искусства разница есть. Предыдущее предложение это такой беззастенчивый дисклеймер, что сейчас пойдут категорические суждения в отношении вещей, сложно поддающихся объективной оценке.
Заранее всё же отвечу на один из типовых контр-аргументов к подобным оценкам: говорят, мол, "настоящий программист" (что-то из серии "настоящий мужик", т.е. виртуальная концепция для манипуляций наивными людьми) должен уметь пользоваться любым инструментом, и относиться к нему стоически. Кто подобное утверждает попросту лишён чувства вкуса (в данной предметной области), поэтому слушать их и вовсе не надо. В использовании хорошего языка есть и очевидные прагматические выгоды, на перечислении которых останавливаться не будем.
#programming
Что ж, недавно писал, что обучаться линейной алгебре надо на примере работы с компьютерной графикой.
Пойдём дальше и почти всерьёз обсудим, на чём стоит писать компьютерные игры. Решил для себя сделать краткий обзор полянок, думаю, будет интересен не только мне.
Обычно берут готовый движок, из которых три явно выделяются (перечисление от более хардкорного к более лояльному пользователю): Unreal, Unity, Godot.
На фоне этих трёх мейнстримных вариантов есть плеяда ушедших на второй план и почти забытых AAA-движков (Source, Cryengine, Serious Engine, etc.), которыми пользуются те кто давно в них вложился, и россыпь indie-вариантов. Из последних произвольно выделю Game Maker, использовал его ещё в школьные годы: одна из моих поделок даже случайно попала в какой-то болгарский компьютерный журнал. Примерно ту же нишу, насколько можно понять со стороны, занимают Construct, Cocos Creator и мн. др.
Для тех, кто хочет написать что-то более-менее с нуля или не хочет бороться с типовыми конвенциями движков, остаётся использование "графических библиотек" (ну или "игровых библиотек", т.е. графика + ввод-вывод + звуки) – кода, который поверх вызовов API операционной системы и низкоуровневых библиотек создаёт весьма тонкую абстракцию, чтобы вещи типа инициализации окна или создания камеры делались в одну строку (вместо череды API-вызовов операционной системы и перемножения трёх матриц соответственно).
Библиотек этих десятки на любой вкус и цвет, среди энтузиастов последнее время популярна Raylib. Так и пишут: создана для любителей программировать и желающих на практике разобраться, как работают видеоигры. Чуть более тонкие абстракции дают библиотеки SDL, GLFW и др.
На самом низком уровне находятся графические API. Долгое время их по сути было два: OpenGL (всеплатформенный) и DirectX (Windows + XBox). Консорциум, отвечающий за разработку OpenGL, объявил, что дальше его развивать не будет и все усилия направит на развитие Vulcan. На устройствах Apple свой Metal. В целом на будущее стоит осваивать Vulcan (а на настоящее и в качестве ностальгии – OpenGL).
Все основные вспомогательные библиотеки и сами графические API имеют C-интерфейсы. Все распространённые языки программирования так или иначе могут его использовать (называется FFI, foreign function invocation). Если использовать полновесный движок, то к нему уже прилагается и свой язык (C++ для Unreal, C# для Unity, собственный GDScript для Godot). Если спускаться на уровень ниже, то выбор пошире.
Языки программирования как художественная литература: кому-то нравится, кому-то нет, но в целом между творчеством бездарных писателей и произведениями искусства разница есть. Предыдущее предложение это такой беззастенчивый дисклеймер, что сейчас пойдут категорические суждения в отношении вещей, сложно поддающихся объективной оценке.
Заранее всё же отвечу на один из типовых контр-аргументов к подобным оценкам: говорят, мол, "настоящий программист" (что-то из серии "настоящий мужик", т.е. виртуальная концепция для манипуляций наивными людьми) должен уметь пользоваться любым инструментом, и относиться к нему стоически. Кто подобное утверждает попросту лишён чувства вкуса (в данной предметной области), поэтому слушать их и вовсе не надо. В использовании хорошего языка есть и очевидные прагматические выгоды, на перечислении которых останавливаться не будем.
#programming
Языки программирования для разработки игр (2/3)
Кстати, спрашивали, зачем я посты разбиваю на несколько эпизодов. Потому что Телеграм не пропускает длинный текст, а на какой-нибудь Медиум я кросс-постить не хочу, мне кажется это будет менее удобно для читателей.
Переходим к списку языков.
1. Ruby (Python, etc.). Знакомо, просто, есть удобные библиотеки (Gosu для Ruby, pygame и множество других для Python). Есть библиотеки общего назначения на любой вкус и под любую задачу. Неудобно компилировать всё в один файл, чтобы можно было легко распространять.
2. Go. Хороший язык для 1985-го года. Использует передовую новинку – сборку мусора – в остальном использует хорошо знакомый набор конструкций школьного Pascal. Примерно так, например, можно из массива выбрать все положительные числа и умножить каждое на два, получив новый массив:
3. C. Вечная классика, которая, вероятно, никогда не умрёт. "Лингва франка", который определил, например, конвенцию вызова функций, используемую повсеместно до сих пор (и нет оснований считать, что она будет в обозримой перспективе заменена чем-то радикально новым). Говорить на универсальном языке дело хорошее, вам без проблем доступен весь набор библиотек. Сам язык архаичный: полностью ручное управление памятью, отсутствие удобных функций в стандартной библиотеке и т.д.
4. C++. Крайне широко применяется в геймдеве и позволяет совместить работу и на низком уровне (ну, к примеру перекладывать вручную биты и байты) и на высоком (классы, ООП). Путь его развития был тяжёлым и тернистым, только к концу двухтысячных комитет разработчиков вдруг очнулся и осознал, что на дворе не 1985-й год, а уже 21-й век. Современных подходов и концепций туда с тех времён напихали под завязку и горшочек продолжает варить: в некотором смысле язык-антипод Go. Для иллюстрации подходит известный анекдот с панчлайном "фонарь, фонарь мне на лоб ещё прилепите!".
5. Zig, Odin. В одну кучу, т.к. без содержательной оценки. Стильно, модно, молодёжно, ориентированно в числе прочего на геймдев. Мне кажется, создатели этих языков просто не справляются с взятыми на себя задачами и какие-то базовые вещи делают ошибочно. Впрочем, не боги горшки обжигают, может быть что-нибудь и выйдет интересное из одного из них или обоих через 3-5 лет.
6. Crystal. Ruby-подобный синтаксис и отношение к пользователю ("программирование должно приносить удовольствие"), помноженный на статическую типизацию, компилирование, высокую производительность. Язык достаточно зрелый, но нет полноценной поддержки Windows.
7. Rust. Создатели языка верно поняли проблематику ручного управления памятью (вкратце: люди ошибаются), но вместо того, чтобы подойти к задаче путём разработки особо умного алгоритма, помогающего программисту не совершать ошибки, они выстроили систему костылей, которая заставляет разработчика с помощью нескольких эзотерических приёмов постоянно доказывать по-прежнему тупому компилятору, что он нигде не ошибся.
Перейдём к шорт-листу победителей.
#programming
Кстати, спрашивали, зачем я посты разбиваю на несколько эпизодов. Потому что Телеграм не пропускает длинный текст, а на какой-нибудь Медиум я кросс-постить не хочу, мне кажется это будет менее удобно для читателей.
Переходим к списку языков.
1. Ruby (Python, etc.). Знакомо, просто, есть удобные библиотеки (Gosu для Ruby, pygame и множество других для Python). Есть библиотеки общего назначения на любой вкус и под любую задачу. Неудобно компилировать всё в один файл, чтобы можно было легко распространять.
2. Go. Хороший язык для 1985-го года. Использует передовую новинку – сборку мусора – в остальном использует хорошо знакомый набор конструкций школьного Pascal. Примерно так, например, можно из массива выбрать все положительные числа и умножить каждое на два, получив новый массив:
numbers := []int{-1, 1, 2, -3, 5}
result := make([]int, 0, len(numbers))
for _, x := range numbers {
if x > 0 {
result = append(result, x*2)
}
}
Что ж, неплохо было бы для языка сорокалетней давности. В языках двадцатилетней давности уже было что-то такое:numbers = [-1, 1, 2, -3, 5]Зачем намеренно нужно пользоваться новым языком, который в момент рождения устарел на 2 поколения, я не знаю. Разработан и поддерживается Google, которому, по мнению создателя языка, этот инструмент помогает заставить не обременённых избыточными талантами выпускников вузов писать хоть как-то работающий код.
numbers.filter { |x| x > 0 }.map { |x| x * 2 }
3. C. Вечная классика, которая, вероятно, никогда не умрёт. "Лингва франка", который определил, например, конвенцию вызова функций, используемую повсеместно до сих пор (и нет оснований считать, что она будет в обозримой перспективе заменена чем-то радикально новым). Говорить на универсальном языке дело хорошее, вам без проблем доступен весь набор библиотек. Сам язык архаичный: полностью ручное управление памятью, отсутствие удобных функций в стандартной библиотеке и т.д.
4. C++. Крайне широко применяется в геймдеве и позволяет совместить работу и на низком уровне (ну, к примеру перекладывать вручную биты и байты) и на высоком (классы, ООП). Путь его развития был тяжёлым и тернистым, только к концу двухтысячных комитет разработчиков вдруг очнулся и осознал, что на дворе не 1985-й год, а уже 21-й век. Современных подходов и концепций туда с тех времён напихали под завязку и горшочек продолжает варить: в некотором смысле язык-антипод Go. Для иллюстрации подходит известный анекдот с панчлайном "фонарь, фонарь мне на лоб ещё прилепите!".
5. Zig, Odin. В одну кучу, т.к. без содержательной оценки. Стильно, модно, молодёжно, ориентированно в числе прочего на геймдев. Мне кажется, создатели этих языков просто не справляются с взятыми на себя задачами и какие-то базовые вещи делают ошибочно. Впрочем, не боги горшки обжигают, может быть что-нибудь и выйдет интересное из одного из них или обоих через 3-5 лет.
6. Crystal. Ruby-подобный синтаксис и отношение к пользователю ("программирование должно приносить удовольствие"), помноженный на статическую типизацию, компилирование, высокую производительность. Язык достаточно зрелый, но нет полноценной поддержки Windows.
7. Rust. Создатели языка верно поняли проблематику ручного управления памятью (вкратце: люди ошибаются), но вместо того, чтобы подойти к задаче путём разработки особо умного алгоритма, помогающего программисту не совершать ошибки, они выстроили систему костылей, которая заставляет разработчика с помощью нескольких эзотерических приёмов постоянно доказывать по-прежнему тупому компилятору, что он нигде не ошибся.
Перейдём к шорт-листу победителей.
#programming
Языки программирования для разработки игр (3/3)
Итак, шорт-лист победителей
A. D. Из названия ясно, что люди хотели сделать "как C/С++, только всё чтобы было лучше". У них это получилось. Доступ к низкоуровневым операциям, более-менее беспроблемная интеграция C (и даже C++) кода, в то же время человеческий синтаксис, хорошая стандартная библиотека, автоматическое управление памятью (отключаемое).
B. Nim. На что был бы похож язык, сделанный без оглядки на внешний вид всех предыдущих, но с использованием наработанного человечеством опыта разработки компиляторов? Да вот на Nim. Есть некоторые очевидные сомнительные моменты в синтаксисе, на тему которых идут вечные холивары, но не буду их даже перечислять из-за ничтожной значимости. В целом взято лучшее из всех миров: управление памятью на гибридной модели (подсчёт ссылок + сборка мусора для циклически связанных объектов; обещают вскоре что-то ещё более интересное выкатить), богатый синтаксис (с адекватным метапрограммированием), хорошая стандартная библиотека. Программисты на современных языках быстро освоятся.
Выбор между двумя вариантами сложный и вот какими соображениями определяется.
– С одной стороны, синтаксис D ограниченно совместим с синтаксисом C (некоторые фрагменты кода можно по сути копи-пастить). Дополнительно, режим ImportC позволяет напрямую использовать сишные хедеры (ну, почти напрямую, поковырять немного придётся, но писать полноценные биндинги, как во всех других языках кроме собственно C и C++, не обязательно).
– С другой стороны, Nim в целом более передовой и перспективный. На нём код получается более лаконичный, выразительный и легко поддерживаемый (на D в целом-то тоже норм, но всё же не дотягивает). Идеология "структур с методами, принимающими структуру или указатель на неё" вместо "классов" (хорошее место в Go, кстати) здесь вполне работает, удобней в обращении чем классический ООП D.
– В установке под Windows проще D. Компилятор Nim работает без нареканий, но процесс развёртывания неприятный.
И там, и там довольно развитое сообщество: форумы, чаты, энтузиасты выкладывающие библиотеки на GitHub и всё такое. У меня сложилось (может быть ошибочное, т.к. знакомство было коротким) впечатление, что в D расклад менее перспективный: пожилого создателя языка уже в каком-то неочевидном направлении начинает тянуть, а среди молодёжи повышенная концентрация, как бы сказать, странных людей.
В Nim создателем-руководителем является молодой рациональный мужик, люди вокруг без особенностей, развито русскоязычное коммьюнити (вплоть до того, что пишут плагины для компиляции под Эльбрус).
В целом фактор сообщества малозначимый, но, пожалуй, на фоне общего паритета добавляет гирьку, склоняющую чашу весов в сторону Nim.
А вообще лучше забыть про все подобные списки и писать на том, что нравится – это первейшее и главнейшее соображение.
#programming
Итак, шорт-лист победителей
A. D. Из названия ясно, что люди хотели сделать "как C/С++, только всё чтобы было лучше". У них это получилось. Доступ к низкоуровневым операциям, более-менее беспроблемная интеграция C (и даже C++) кода, в то же время человеческий синтаксис, хорошая стандартная библиотека, автоматическое управление памятью (отключаемое).
B. Nim. На что был бы похож язык, сделанный без оглядки на внешний вид всех предыдущих, но с использованием наработанного человечеством опыта разработки компиляторов? Да вот на Nim. Есть некоторые очевидные сомнительные моменты в синтаксисе, на тему которых идут вечные холивары, но не буду их даже перечислять из-за ничтожной значимости. В целом взято лучшее из всех миров: управление памятью на гибридной модели (подсчёт ссылок + сборка мусора для циклически связанных объектов; обещают вскоре что-то ещё более интересное выкатить), богатый синтаксис (с адекватным метапрограммированием), хорошая стандартная библиотека. Программисты на современных языках быстро освоятся.
Выбор между двумя вариантами сложный и вот какими соображениями определяется.
– С одной стороны, синтаксис D ограниченно совместим с синтаксисом C (некоторые фрагменты кода можно по сути копи-пастить). Дополнительно, режим ImportC позволяет напрямую использовать сишные хедеры (ну, почти напрямую, поковырять немного придётся, но писать полноценные биндинги, как во всех других языках кроме собственно C и C++, не обязательно).
– С другой стороны, Nim в целом более передовой и перспективный. На нём код получается более лаконичный, выразительный и легко поддерживаемый (на D в целом-то тоже норм, но всё же не дотягивает). Идеология "структур с методами, принимающими структуру или указатель на неё" вместо "классов" (хорошее место в Go, кстати) здесь вполне работает, удобней в обращении чем классический ООП D.
– В установке под Windows проще D. Компилятор Nim работает без нареканий, но процесс развёртывания неприятный.
И там, и там довольно развитое сообщество: форумы, чаты, энтузиасты выкладывающие библиотеки на GitHub и всё такое. У меня сложилось (может быть ошибочное, т.к. знакомство было коротким) впечатление, что в D расклад менее перспективный: пожилого создателя языка уже в каком-то неочевидном направлении начинает тянуть, а среди молодёжи повышенная концентрация, как бы сказать, странных людей.
В Nim создателем-руководителем является молодой рациональный мужик, люди вокруг без особенностей, развито русскоязычное коммьюнити (вплоть до того, что пишут плагины для компиляции под Эльбрус).
В целом фактор сообщества малозначимый, но, пожалуй, на фоне общего паритета добавляет гирьку, склоняющую чашу весов в сторону Nim.
А вообще лучше забыть про все подобные списки и писать на том, что нравится – это первейшее и главнейшее соображение.
#programming
Антирейтинг редакторов Markdown
1. Slack. Пользуясь их интерфейсом ты каждый раз представляешь, как разработчики держали в голове образ тупого менджера (скорее всего, какого-то конкретного человека среди своих инвесторов), который тем лучше себя чувствует, чем меньше видит пунктов в списке каналов и адресатов, равно кнопочек в окне редактирования. Абсолютный лидер по нелепым компромиссам интерфейса в целом и убогости markdown-редактора в частности.
2. Jira. Редактор худо-бедно работает и содержит, вроде бы, все необходимые функции, но примерно в половине случаев как-то подленько вставляет тебе палки в колёса. Отдельно, отсутствие простого и примитивного lock-а при совместном редактировании текста тикета на фоне общей всеобъятной монструозности продукта иначе как специальным издевательством сложно объяснить.
3. Telegram. Продукт, конечно, перерос сам себя, и видно что он это понимает по факту создания Telegraph. То, что функции Telegraph не интегрировали в основное приложение, а вынесли куда подальше, чтобы ими пользовалось как можно меньше людей (но формальный повод для упрёка становился при том менее обоснованным), показывает, что команда разработки с чего-то твёрдо уверена, что деньги будут делать не писатели интеллектуальных пабликов, а твиттерная масса черни с постами "вот моя новая тачка", "Байден оговорился" и "биткоин снова упал ниже $100500". На фоне развития всех этих Sponsor-ов, Boosty-ей и Patreon-ов это выглядит как "не надо денег", что, впрочем, не удивительно для организации, руководимой человеком, потратившим $150k на покупку паспорта мусорного оффшора.
К другой стороне рейтинга: самый лучший редактор Markdown, к которому даже при желании едва ли найдёшь по какому поводу придраться, конечно, в Obsidian.
#programming
1. Slack. Пользуясь их интерфейсом ты каждый раз представляешь, как разработчики держали в голове образ тупого менджера (скорее всего, какого-то конкретного человека среди своих инвесторов), который тем лучше себя чувствует, чем меньше видит пунктов в списке каналов и адресатов, равно кнопочек в окне редактирования. Абсолютный лидер по нелепым компромиссам интерфейса в целом и убогости markdown-редактора в частности.
2. Jira. Редактор худо-бедно работает и содержит, вроде бы, все необходимые функции, но примерно в половине случаев как-то подленько вставляет тебе палки в колёса. Отдельно, отсутствие простого и примитивного lock-а при совместном редактировании текста тикета на фоне общей всеобъятной монструозности продукта иначе как специальным издевательством сложно объяснить.
3. Telegram. Продукт, конечно, перерос сам себя, и видно что он это понимает по факту создания Telegraph. То, что функции Telegraph не интегрировали в основное приложение, а вынесли куда подальше, чтобы ими пользовалось как можно меньше людей (но формальный повод для упрёка становился при том менее обоснованным), показывает, что команда разработки с чего-то твёрдо уверена, что деньги будут делать не писатели интеллектуальных пабликов, а твиттерная масса черни с постами "вот моя новая тачка", "Байден оговорился" и "биткоин снова упал ниже $100500". На фоне развития всех этих Sponsor-ов, Boosty-ей и Patreon-ов это выглядит как "не надо денег", что, впрочем, не удивительно для организации, руководимой человеком, потратившим $150k на покупку паспорта мусорного оффшора.
К другой стороне рейтинга: самый лучший редактор Markdown, к которому даже при желании едва ли найдёшь по какому поводу придраться, конечно, в Obsidian.
#programming