Комментарии 57
Можно Ли Делать Игры На Python?
Краткий ответ: можно, но не нужно.
Игровая логика обычно не содержит сложных вычислений и скорость языка отходит на второй план.
Большая ошибка, за которую впоследствии возможно придётся дорого заплатить.
Кроме того, выскажу личное мнение: как встраиваемый язык Python просто отвратителен (при том что я люблю этот язык, он приятный для ненапряжного программирования). Python был очень модный в этом качестве когда-то давно (где-то в районе нулевых) и его пихали всюду (примерно как XML). Но сама его модель вседозволенности и динамичности (которая и делает его таким интересным) - это просто ужасный яд для встраиваемого языка. Про производительность и аппетиты к ресурсам я даже не говорю. Так что есть веская причина, почему он "не взлетел" в этом качестве.
а где были скрипты на питоне в нулевых? Или вы не про геймдев? Там же луа во все поля была
Например, в Blender. Я тогда начал писать плагин для экспорта моделей и случайно переквалифицировался с Java на Python.
В начале развития Unity3D была поддержка самостоятельной версии языка Boo.
Ну и образцовый пример — это конечно EVE Online.
не, про тулзы понятно. Я думал, речь про игры. Что напомнили про eve - спасибо :)
Ева уже вешается там из-за этого питона. Они сидят на нестандартном несовместимом компиляторе (чтобы избавиться от GIL, который авторы стандартного питона фиксить не собираются видимо), половину бэка утащили на Азуры, мигрировали полностью на gRPC, каждую парочку звездных систем обслуживает отдельный сервер (просто этого глазами не видно), и все равно лагает)
Собственно поэтому им и пришлось много лет назад добавить TiDi, оно же космокисель. Это когда при увеличении нагрузки на сервер (большое сражение) сервер начинает замедлять тики, чтобы успевать все обрабатывать. В итоге абсолютно все процессы в игре происходят дольше (коэффициент замедления), при максимуме "кисельности" битва 6к игроков идет 27 часов)
А съехать с питона они не могут. Другого не умеют, плюс там лютый лапшекод, настаивавшийся с 2003 года. Вот и страдают все. Пять лет уже плотно переписывают все, и лет 15 просто пытаются как-то решить лаги. Но воз и ныне там
TD добавлен для юзеров, чтобы лагало у всех поровну, а не в зависимости от железа.
А лагает-то из-за чего по-вашему? TD вводится на всей ноде, поэтому зачастую можно влететь в такой кисель за 3-4 системы от самого сражения. Потому что лагает сама нода, и таким образом пытается это компенсировать. И именно поэтому при подключении резервных нод TD отключается или сводится к минимуму. Потому что он рассчитывается от нагрузки сервера, а не клиентов
Ну насчёт "каждую парочку" всё же не совсем верно: в некоторых не самых населённых регах (например, в Immensia) целые консты могут на одном сервере находиться. Плюс к тому они явно порой их перераспределяют, вряд ли полностью автоматически. Порой флоты примерно схожих размеров ловят лагалово в том же месте, но просто неделю спустя.
Ну я условно сказал, да. Та же Jita перманентно висит на выделенной ноде, например. Плюс у них есть некоторое количество резервных нод, которые они присовывают заранее куда надо, если знают о предстоящем сражении. Там же есть на сайте кнопочка "рассказать разрабам, что мы хотим крупно подраться". Специально, чтобы они заранее подсуетились и туда нод подкинули
каждую парочку звездных систем обслуживает отдельный сервер
Так вот как они единый мир сделали, а то раньше были статьи, что у них там суперкомпьютер из топ-100 чтобы мир вычислять.
Да не, эта система с нодами у них со времен Царя Гороха. Я в Еву играл 5 лет и с самого старта в 2016 году помню про это узнал. И даже старички с 15-летним стажем говорили, что почти всегда так было
А бэк у них тривиальный. Лютая двадцатилетняя лапша на питоне ("POS code" стал уже грустным мемом), дико лагающая. И сервер представляет собой кластер из кучи нод, между которыми игроки переключаются при проходе в гиперворота, использовании джампдрайва, порталов и тд
Кстати сервер игрового чата один и отдельный от игрового. Поэтому он нередко отваливался, когда сам игровой сервер продолжал работать и играть было можно, но без чата)
Все их проблемы уже вряд ли лишатся, ибо компания и изнутри, и снаружи, на полных парах летит в бездну. А жаль, почти 20 лет такую уникальную игру держали на плаву и с адекватным онлайном
А если бы не питон может и вообще никакой Евы бы не сделали, так что тут двояко)
GIL на питоне и не надо фиксить. Такое в голову может прийти только C++ динозаврам, которые крайне инертны, чтобы принять новые парадигмы программирования (сам таким был).
Blade of Darkness, как один пример.
а где были скрипты на питоне в нулевых?
Ну, например в моей любимой Severance: Blade of Darkness. При этом там игровая логика частично валяется в открытых скриптах, вот прям в исходном виде, благодаря чему фанаты наклепали кучу модов (даже я немного покопался, очень весело). Практически наполовину опен-сорс, хоть и без лицензии.
Кстати, можно за недорого купить ремастер в Steam, если есть желание поковырять.
Civilization IV
Python так или иначе есть в Houdini, Blender, Modo, Rhino, Qgis, Davinci Resolve. А для пользовательских приложений HUD и прочего, внутри симулятора, используется в гонках Assetto Corsa.
А какие есть альтернативы по встраимому языку, помимо Lua давно стагнирующему и полумертвому?
А что в Lua стагнирующего и полумертвого? Новые версии у него периодически выходят. Богатая стандартная библиотека ему и не нужна, как раз потому что он предназначен в первую очередь для встраивания, а это значит что во-первых он должен быть легковесным, а во-вторых специфичный функционал должен пробрасываться из приложения. По сути Lua сейчас в завершенном состоянии, в нем только баги фиксить и производительность улучшать.
Есть такой весёлый язык Squirrel, например. Писал на нём моды для Battle Brothers
Был, когда-то, AngelScript.
С Python можно разрабатывать не сложные игры, но с его скоростью и динамической типизацией легко наступать на грабли. Лучше смотреть в сторону компилируемых статически типизированных языков.
Если хотите создавать масштабные игры смотрите в сторону C++(SDL, Oxygen, SFML, Ogre3D), Java(libGDX, LWJGL, JMonkeyEngine), C#, разных движков Unity(C#), Unreal Engine(C++), или Godot, его GDScript похож на Python.
SDL грубо говоря Сишный аналог плюсового SFML, построенный на структурах, сырых указателях и без ООП, что мало вписывается в концепции современного языка, так что относить его к плюсовым либам считаю неправильным. Перечислены для плюсов в большинстве графические библиотеки для 2д игр.
LWJGL это только биндинги к языку плюсовых апи. С их помощью можно писать игры, но они все лишком уж низкоуровневые, например OpenGL, OpenAL, OpenVR, Vulkan и тд. Хотя сам язык мало подходит для игр и кроме майнкрафта сложно назвать известные проекты.
Java мне кажется тоже не лучший вариант. Да на этом языке можно делать игры, но имхо не нужно. На мой взгляд Java лучше использовать в северной части игры, если такая предполагается.
Я пишу MMO (сервер на Kotlin, клиент браузерный на данный момент, чисто для дебага). И я смотрел что именно предлагает Java в плане рендера и game engine. Все очень плохо. Придется писать все свое а зачем - непонятно.
Я бы рекомендовал брать Unreal Engine если есть хорошее знание C++ и Unity во всех остальных случаях
Unreal Engine 4 используют С++, Blueprint и некоторое подобие JavaScript
Скрипт был только в 3 версии движка, в 4 и 5 его нету, формально к нему можно приписать еще и C# и Python. Первый используется в скриптах сборки, а второй в автоматизации в редакторе.
Получается...Что игры то не на python....питон тут тонкая прослойка для сишных библиотек...
Хотя и существуют специальные игровые движки, написанные на Python, но о них чуть дальше.
И в результате из чисто питоновых приведен
движок RenPy . Это именно то, на что действительно стоит обратить своё внимание
странно, что игры для онанистов визуальные новеллы вообще нуждаются в движке. Их на каком-нибудь VBA писать можно.
странно, что
игры для онанистоввизуальные новеллы вообще нуждаются в движке. Их на каком-нибудь VBA писать можно.
Движок там для того, чтобы писать их можно было одной рукой. Если не заморачиваться с анимациями и интерфейсом, то код может выглядеть как тупо текст новеллы вперемешку с картинками
label start:
#картинки могут находиться сами при определенном нейминге
scene my_scene
#Вообще для людей есть класс Character но для тупого примера пойдет и так
"character name" "text"
return– С-сенпай... твой код такой большой!
Если не заморачиваться с анимациями и интерфейсом, это уже будет не VN, а текстовый квест в лучшем случае, состоящий из пустых экранов с текстом и кнопками "вперед" и "назад". В самом-самом примитивном виде VN делаются так, только вот если вы хотите игру, а не плохо отформатированную книжку в exe-формате, нужен полноценный движок, который будет отрисовывать текст, анимацию спрайтов, переходить по flowchart сюжета, показывая опции, отрисовывать саму эту flowchart, выставлять флаги событий, делать сейвы, выводить озвучку персонажей, менять фоны и CG, поддерживать галерею, меню, мини-игры, видеоролики, и еще с десяток других самых-самых базовых опций. Я посмотрю как вы что-нибудь типа Steins;Gate "одной рукой" напишете, особенно в ELITE версии. Или MLA. Или меметичного School Days. Или ef. И это я еще не упомянул популярного в последнее время Live2D. Если не знакомы с рынком VN дальше того же VNMaker, который как раз предназначен для написания подобных наколеночных поделий "одной рукой", и который, внезапно, и предоставляет пишущему этот самый достаточно примитивный движок, позволяющий это делать именно в описанном виде, лучше сначала хоть немного в предмет углубитесь, прежде чем рассуждать.
согласен. я говорил скорее в том смысле, что в RenPy можно без каких-либо навыков программирования начать делать VN. абсолютно базовый функционал вроде главного меню, сохранения прогресса, проигрывания музыки, self-voicing, отматывания в любую сторону с правильной обработкой переменных, изменяющихся при откатывании назад, и другие вещи уже реализованы в каком-то виде и можно сосредоточиться на написании/отрисовке истории. а мини-играми, анимированными переходами из главного меню в игру и обратно и прочими QoL фичами можно заняться тогда, когда коробочного функционала станет недостаточно.
кстати, а какие есть инструменты для работы с флоучартом сюжета и его отрисовкой?
кстати, а какие есть инструменты для работы с флоучартом сюжета и его отрисовкой?
Для разработчика или для игрока? Для разработчика не скажу, да и игр с явно встроенной flowchart мало, мне навскидку только серия фейта вспоминается. Для игроков я тоже не встречал, хотя было бы удобно перебивать гайды к некоторым обширным играм в них, чтобы видеть, где какие флаги триггерят ветвления, а то списки выборов вида "ответ 1 - ответ 4 - ответ 2 - ответ 2 - ... -> концовка 5" часто трудно понять, и они абсолютно не отражают всех возможных веток диалогов. Я был например очень удивлен, когда спустя 8 лет с первого прочтения Кланнада при перечитывании случайно обнаружил, что рут Котоми в нем имеет два слегка отличающихся good end, и это до сих пор не указано ни в одном гайде по нему.
Всякие блок-схемы бизнес-процессов и подобные вещи я в университетскую юность в старушке Dia рисовал, но мне она казалась очень неудобной. Хотя сейчас заглянул на ее сайт и обнаружил, что у нее даже есть надстройки, позволяющие ее схемы преобразовывать в программный код и наоборот, так что для принципиальной работы с flowchart она очень даже может подойти.
Очень веселит нытьё про динамическую типизацию. А вы сколько лет в информационном вакууме? Или вам просто нравится так оправдывать свой говнокод неприкрытый даже тестами?
про динамическую типизацию обычно ноют не для того, чтоб оправдать свой говнокод, а чтоб поделиться болью от чужого, который видишь в первый раз и в котором хочешь разобраться. А там в функцию иногда прилетает строка, иногда объект, а иногда tuple... И пусть он хоть трижды проходит все тесты, легче не становится
Для этого изобрели аннотации типов.
Аннотации типов решают проблему "видишь в первый раз и в котором хочешь разобраться. А там в функцию иногда прилетает строка, иногда объект, а иногда tuple".
Задачи проверять их согласованность (и тем более делать это во время компиляции, которого в динамически типизированных языках как правило нет) не стояло и не стоит.
Согласованность типов данных, как вам подсказали выше, весьма успешно подтверждается тестами, без которых и в статически типизированных языках сейчас нормально не обойтись.
Причем, динамическая типизация у меня не вызывает отторжения, у нее есть преимущества в определенных ситуациях. Мне весьма импонируют лиспы, например.
Но я искренне не понимаю, зачем защищать динамическую типизацию в ситуациях «без тестов – говнокод, а аннотации можно и написать», когда можно просто взять статически-типизированный язык. И не писать целый класс тестов, связанных с проверками типов. Получается как в анекдоте про суровых сибирских мужиков и японскую бензопилу.
зачем выбирать связку: аннотации, которые не проверяются (и, следовательно, могут врать) + тесты, когда можно просто выбрать статически-типизированный язык
На мой взгляд, потому что:
1) В динамически типизированных языках далеко не всё нужно аннотировать, а что-то можно аннотировать Generic'ами. Т.е. трудозатраты всё равно будут сильно меньше, чем в статических ЯП, без серьёзной потери в безопасности.
2) Никакая типизация не заменит необходимость в тестах. На более-менее большом проекте их всё равно придётся писать даже при статических ЯП.
Но это всё, конечно, извечный холивар :) Сколько людей, столько и мнений. Мой ультимативный аргумент — популярность языков в реальной жизни. Если у нас JS с Питоном хочешь, не хочешь всё-таки вытесняют Джаву с собратьями в конкурентной среде, значит, кто бы что ни говорил, это имеет смысл.
2) Типизация – это не замена тестов. Типизация – это замена тестов, проверяющих соответствие типов и аналогичных им.
3) И про ультимативный аргумент – тоже есть что возразить. Во-первых, с ростом популярности этих языков как раз стали видны подвижки в сторону аннотирования типов, что иллюстрирует неспособность чисто динамической типизации удовлетворить потребности «конкурентной среды». Во-вторых, само утверждение о вытеснении и конкурентной среде мне кажется натянутым, так как у нас нет объективных данных, чтобы констатировать это вытеснение.
Про холиварность – согласен, но я повторюсь. Я не против динамической типизации, я против ее защиты в тех местах, где более уместна статическая. Особенно в грубоватой форме, с которой началась эта ветка дискуссии.
Видимо проблем с ней нет и TypeScript появился от нечего делать.
Можно капельку оффтоп-нытья?
Можно Ли Делать Игры На Python?
Пожалуйста, не Надо Использовать Title Case в Заголовках на Русском Языке, Это Очень Раздражает и в Частности в Длинных Заголовках Делает Их Нечитабельными.
Тем более использовать неправильно, согласно различным гайдлайнам для редакторов прессы, в Title Case не пишутся с заглавными служебные части речи как минимум. Title Case - изобретение, пришедшее в английский язык еще из латыни, и закрепившееся в Новое время, насколько я помню, как стиль газетных заголовков, где его использование было отчасти оправдано для смыслового выделения текста на убористо напечатанной газетной странице и привлечения внимания читателя. В русском языке, да еще на веб-странице с установленным форматированием его использование выглядит просто глупо. В англоязычном вебе его до сих пор используют на новостных сайтах, вместе с также традиционным для этого стиля фраз написанием в Йоды мастера форме... пожалуйста, не надо повторять за ними.
Почему-то никто не упомянул Arcade. На официальном сайте есть отдельная статья-сравнение с Pygame, где Arcade, естественно, выигрывает. Лично мне он зашел больше, чем Pygame.
Вам бы орфографию и пунктуацию поправить. Претендуете на серьезную статью, а ошибки детские...
https://the-tale.org на питоне написана. Исходники
От названия вспомнился 2008, когда МнОгИе ПиСаЛи ВоТ тАк.
Сам текст написан тоже так себе, слишком много всего выделено курсивом абсолютно без причины.
Можно Ли Делать Игры На Python?