Кажется доделал генератор.
В нём куча мусора, но он всё равно не очень тяжёлый… А ещё почему-то ликает…
Скачивайте, генерируйте, комментируйте.
R следующий сид.
https://www.dropbox.com/s/jqvrybeoxuqzdpe/generator.exe?dl=0
- 08 сентября 2020, 23:11
- 02
___________________________________________
############################################################################################
FATAL ERROR in
action number 1
of Create Event
for object obj_map_generator:
Fatal Error: Can not create vertex buffer of size 393216 bytes
9935 vertex buffers allocated with total size of -379264 KB
at gml_Script_scr_draw_map
############################################################################################
--------------------------------------------------------------------------------------------
stack frame is
gml_Script_scr_draw_map (line -1)
gml_Object_obj_map_generator_Create_0
called from - gml_Object_object16_Alarm_0 (line -1) - <unknown source line>
Я вообще не понимаю, как игра на стадии разработки компилируется, что выдаёт аж критическую ошибку. И вы еще за это платите, господа.
На самом деле много вариантов Runtime-ошибок.
В интерпретируемых языках с нестрогой типизацией и словарями их еще больше.
По моему опыту это чаще случается из-за того что автор не проверяет - успешно выполнилась функция или нет. По-хорошему каждую вызванную функцию надо проверять - не вернула ли она ошибку.
Исключительные ситуации никто не отменял, просто как может попасть в функцию, то что туда попасть не может фактически. На стадии компиляции профилеровщик или там что-то другое должно же осуществлять проверку и подобные мероприятия. Я в Godot такого не замечал (если кто видел ткните пальцем), на GMS сплошь и рядом Fatal error. Как я понимаю GMS строго типизированный движок и как туда может что-то затесаться, немного не ясно...
Если бы разработчики отлавливали все краевые ситуации на стадии имплементации, в этом мире не существовало бы багов. Но это увы нереально. Банальный условный NullReferenceException спокойно может пробраться в логику практически в любом типе приложения, не важно типизированный ли ЯП или нет. Я уже не говорю о ситуациях типа той, что в посте, где это выглядит больше как эксепшен прямиком с графического АПИ.
То, что на одном движке исключения приводят к крашам, а на другом - нет, может говорить о разной политике глобальной обработки исключений.
В современных языках типа свифта и котлина довольно успешно с этим борятся.
Здесь и здесь один из создателей котлина рассказывает о предпосылках того, что в этих языках независимо пришли к явно нуллабельным типам и, в целом, compile-time безопасности от нуллов.
И так это выглядит в бою.
Я верно понимаю что это предложение учить новый движок из-за одной ошибки (пока что на одной машине)? х)
Не, просто к слову, о том, что даже такую вездесущую проблему как NPE, в некоторых языках сейчас почти истребили из рантайма (по крайней мере значительно снизили вероятность).
Ясно =)
Ну, опять таки, NPE - всего лишь один из десятков эксепшенов (пусть и один из самых часто встречающихся), и я говорил в общем об эксепшенах, наводя NPE только как пример. В любом случае, эксепшен - всего лишь побочный эффект некорректной логики кода. Очень сомневаюсь, что когда-то появится ЯП, который будет полностью отсекать все затупы программиста.
Вроде в эрланге при вылете перезагружается модуль программы по-тихому, и программа продолжает работать. Но сложно представляю, как на таком делать игры :)
Нюанс в том, что эксепшен - это в любом случае неправильная или дефектная логика (если конечно эксепшен не ожидается). Если модуль перезагрузится, не факт что это исправит саму проблему. Если в логике игры прописано, скажем, неправильное чтение характеристик персонажа при определенных условиях, какие-либо перезагрузки или воркэраунды во время эксепшена не дадут игроку в итоге посмотреть характеристики персонажа, ведь сама логика для этого не работает правильно.
Да, но баг с последующим вылетом (попытался кастануть заклинание и потерял игровой прогресс) становится просто багом (не могу кастовать заклинания).
Ну а логические ошибки (которые без кидания исключений) вовсе не отловишь и не заметишь автоматически, если не напишешь для них тесты.
Языки с достаточно мощными системами типов (например, Coq, Idris, Agda) позволяют выражать в них произвольные гарантии, и ловить даже логические ошибки в компайл-тайме. Впрочем, писать на них исключительно тяжело, и это не для геймдева в любом случае.
Некоторые элементы вкрапляются в индустриальные языки, и с ними делают прикольные уловки. В котлине с помощью sealed класса можно, сделать, чтобы в компаил тайме ловило, когда ты пытаешься, например, использовать угол в радианах там, где ожидается угол в градусах или наоборот.
А с помощью inline классов ловят ошибки, когда ты например ждёшь строку айдишника, а вместо неё подал имя пользователя или какой-то другой айдишник.
В F# единицы измерения в язык встроены, можно писать
speed = 4.0<pixel/sec>:) Но вообще это частные случаи newtype-идиомы, её и в старых языках применяли (возможно, с некоторым количеством бойлерплейтного кода). Вот хорошая статья про типобезопасные идентификаторы в C++.А зачем ловить логические ошибки в compile-time, если можно написать обычные автоматические тесты? И запускать, если хочется, через скрипт после каждой компиляции - но ведь компиляция будет тогда долгой, так же как и с вашими лабораторными языками.
А если есть какая-то критическая часть кода, где часты изменения и надо что-то гарантировать, то подойдёт использование своего DSL.
Кстати, мне больше по душе подход метапрограммирования, где можно на этапе компиляции запускать произвольный код (хоть с проверками, хоть с чем угодно). Тогда не надо городить "мощные системы типов" и ухищрения на их основе.
Потому что тесты с каким угодно покрытием могут показать только наличие ошибок, но не гарантировать их отсутствие. Я вовсе не утверждаю, что тесты сакс и надо бросаться всё переписывать на зависимых типах – просто хочу заметить, что доказанно надёжный код можно создавать и без тестов. В сверхкритических применениях (геймдев к ним не относится, конечно) это оправдано.
Correct-by-construction (e)DSL – хороший подход, надо только всего лишь не наделать ошибок в выполняторе этого DSL %)
Ну да. Запускаешь тесты перед публикацией билда, и если они не прошли, то не публикуешь билд, пока не исправишь. Вот тебе и гарантии отсутствия.
А если ты про более надёжные гарантии, то их тебе не даст и супермощный язык - потому что в этом языке предлагается "выражать произвольные гарантии" (по сути писать тесты), но нет таких гарантии из коробки (уж точно не для логических ошибок).
Тесты – это в любом случае проверки только частных ситуаций. Если программа работает на данных из тестов, сколько бы их ни было, – никаких гарантий, что она не свалится на каких-либо ещё. Формальная верификация (в т. ч. через супермощные типы) – общее доказательство того, что возможны только корректные ситуации. Тесты на такое в принципе неспособны.
В этих языках любую логику, любое утверждение о программе можно сформулировать в виде типа, и оно будет проверяться компилятором. См. изоморфизм Карри-Говарда.
И вообще, нет чёткой границы между «логическими ошибками» и «ошибками типизации». Второе – частный случай первого.
Ну вот есть игра RPG, в ней много разных абилок, которые ещё и друг с другом взаимодействуют. Перемножив, получается 100500 вариантов игровых взаимодействий. Удачи их сформулировать в виде типа. А если хоть одно не сформулировал (ака не написал тест), то в нём вероятна логическая ошибка.
Мне кажется, Yuuri не имеет в виду, что стоит отказываться от тестов. Тесты и разные уловки с compile safety дополняют друг друга. Ты целыми пластами исключаешь возможность сделать дурацкие ошибки, а что так исключить не можешь, проверяешь юнит или e2e тестами.
Прикол уловок с теми же Radian vs Degree типами в том, что в современных IDE тебе это сразу красным подчеркнёт и пояснит, не после того, как ты запустишь какую-то тяжёлую компиляцию по кнопке.
Да, ключевой момент, что ты сидишь и свои ручками исключаешь ошибки. Не язык за тебя исключает, он только предоставляет очередной инструмент, а ты сам тратишь время на написание сценария для этого инструмента.
Смахивает на обычный маркетинг. Наш язык избавит вас от всех ваших ошибок, совершенных с момента вашего рождения.
Смахивает на зелен виноград и нежелание разбираться в теме. Собственно, никто не заставляет, но не надо тогда заявлять «так не бываит, вы фсё врёти, этот ваш белый – просто очень светлый чёрный».
Я это не заявляю, конечно же, это работает и есть в некотором виде даже в древнем C++. Где-то поможет, где-то - нет.
Так есть же. Нестыковки типизации порождают синтаксическую ошибку. А логическая - это, например, герой должен нанести 300 уровна, а наносит 200. Можно проверить формулу в нескольких точках тестом (или типом - неважно), но забыть учесть какой-то шлем c бонусом урона 50%. Или этого шлема изначально не было в геймдизайне, вот его и в тесте не было.
Если «наносит 300 вместо 200», но игра нормально работает, то это ошибка не программы, а спецификации, и соответственно, не поймается ни одним из средств программной верификации.
Ну и кроме того, ошибки типизации – семантические, а не синтаксические.
Если в ТЗ ошибки нет, а программист её допустил, то это ошибка в программе.
О том и речь.
Ок.
Зависит от семантики языка. Например, в питоне эксепшен — рядовая ситуация и вокруг них много чего построено. Доступ к несуществующему элементу словаря — исключение, конец итератора — исключение.
Для этого после цитаты в скобочках и написано:
Думал, по контексту понятно, что речь идет именно о необработанных эксепшенах.
Имею в виду, что unhandled exception может быть как «дальше работать нельзя, мы все умрём», так и «рядовая ситуация, но кто-то проверку забыл».
Думаю, статистически эксепшены, которые не ожидались, вылетают чаще, чем эксепшены, которые ожидались.
Есть у кого годные статьи про историю развития эксепшенов, всякие checked unchecked и что об этом думают в современности? Почему, например, в котлине вообще нафиг забили и сделали все эксепшены unchecked?
В Java-мире checked exceptions посчитали плохим тоном, потому что они очень замусоривают сигнатуры, и в итоге на обработку все забивают и ставят пустой catch, лишь бы компилятор отвязался.
В современных Go и Rust от исключений (как эдакого замаскированного goto, увеличивающего связность и нарушающего локальность) вообще отказались, функции возвращают результат и/или ошибку, которая либо обрабатывается по месту, либо передаётся на уровень выше. В большинстве других языков такой подход тоже применим.
Никогда не был. В 2006 он мне очень понравился именно тем, что там не надо писать типы переменных, да и вообще объявлять переменные в какой-то бешеной бухгалтерской шапке из:
К счастью, ещё с 70-х придумали, как выводить типы, чтобы и в статических языках аннотации типов не писать.
Тебя послушаешь, почти всё на свете придумали. А вот чтоб оно было широко доступным ещё...
Реальность: ад типизации в Unity (C#) и UE4 (C++).
Даже в C# и C++ есть зайчатки в виде var/auto – не Хиндли-Милнер, но хоть что-то. Ну то есть уже не ад, как был бы с бюрократией из Pascal-семейства. Так, чистилище ;)
Я где-то читал, что auto это очень нехорошая штука в руках новичка и может много чего напортить
Это какое-то очень маргинальное мнение. Конечно, можно насочинять какие-нибудь искусственных ситуаций, где замена явного типа на
autoчто-то ломает после рефакторинга, но в 99,99% это безопасно и лишь увеличивает читаемость. Впрочем, маститые деды-ретрограды такое любят сочинять про любое нововведение в любом языке.Просто у дедов есть практическая оценка - общее время, потраченное на разработку+сопровождение. А хипстеры готовы миллионы строк кода браться переводить с языка на язык ради исправления нескольких ошибок и добавления десятков новых. :)
А кто говорит о переводе с языка на язык, и вообще про переписывание старой кодобазы?
Rust-евангелисты :)
Я бы не сказал, что речь о каких-то конкретных языках, на которые надо переходить, это скорее интересные направления, в которых двигается индустрия в целом. Ну, эти вещи уже не в каких-то коробочных языках где-то в академии, в некоторых областях (как например мобильная разработка с этими свифтами-котлинами) это уже, считай, индустриальный стандарт.
Ну ок, согласен. Есть разные языки, у них разные интересные фичи, они этими фичами постоянно обмениваются. Одну и ту же задачу (в т.ч. задачу тестирования) можно решить разными способами. Нравится всё решать через типы (может, это такой мыслительный челлендж) - решайте через типы. А мне нравится сначала смотреть контекст задачи. :)
Даже есть такая шутка. И объясняется она тем, что код должен быть читаемым, не в угоду скорости написания самого кода. В Godot отказались от PR содержащих в себе auto.
autoв целом повышает и читаемость, и скорость написания. В Godot до совсем недавнего времени вообще не хотели обновляться с C++98, так что при всём уважении к отличному движку и его авторам, они не образец для подражания в этом плане.Ты ничего не путаешь!? 🤣
Вроде нет. Поправь.
98/03😋
Хотя GameFromScratch пишет, что большая часть исходного кода движка написана на C++11 из-за модульной структуры движка.
Это было ожидаемое возражение. Суть в том, что стандарт 03 отличается от 98 только исправлением ошибок и новых языковых фич не содержит (ну, одну мелкую). Технически их можно считать одним стандартом. Если не нравится, замени в том моём комменте 98 на 03 – смысл не изменится.
Что, где?
https://gamefromscratch.com/godot-with-c/
На modern C++ с оговорками стали переползать вот буквально год-два назад, а ещё в 2017 отнекивались. Модульность – это заслуга архитектуры проекта, а не языка и не его новой версии (тем более что у C++ с модульностью до сих пор довольно швахно).
Там смесь стандартов из-за использования огромного количества библиотек.
Да не повышает auto читаемость, успокойся (а понижать может запросто, если лепить его прямо везде). Скорость написания повышает (ранее пользовались typedef для страшных итераторов/темплейтов, его надо было объявлять ещё), но поскольку основная часть работы - это мышление, а не написание, то там не сильно большая экономия.
Забавно эту дискуссию видеть набигающей на исходный микропост инди-художника-пиксельартщика (!) который кодит (!!!) генератор уровней на Гамаке, где тип переменной вообще указывать не надо нигде, и брат жив (если кодилось с умом хотя бы 10% от нужного для недырявого кодинга игры на C++). Нескриптовые языки общего назначения в геймдеве - это всегда бессмысленно и беспощадно.
Дикуссия вроде ни на кого не набигает же, просто прикольные направления развития индустрии.
Я просто хорошо знаком с автором микропоста, и представил как он читает все эти технологические дискуссии, не понимая и не нуждаясь в причине понимать что в них происходит, не говоря уже о том чтоб оно ему было в случае понимания полезно в рамках конкретного, живого разрабатываемого проекта.
Из 85 комментариев, полезных топик-стартеру - может быть 5. А всего-то стоило Антонке сказать свою детсадовскую подколку "и вы ещё за это платите", а Масту на это неиронично отреагировать...
Ну ты будто никогда ползучих оффтопов не видел и сам в них не участвовал :3
=)
[citation needed], как говорится.
Тем временем, Ксит всё ещё не может отличить геймдев от геймдизайна. :) Мол, давайте запретим все игровые движки и интерпретаторы игровых скриптовых языков (в геймдеве же!), которые написаны на языках общего назначения.
Это Скорчед не может отличить произвольные языки общего назначения от просто популярных высокоуровневых языков, вся роль которых в пайплайне - это удобно компилироваться в ассемблер (желательно виртуальной машины для кроссплатформенности), и уже оттуда в опкоды целевой платформы.
Какое-то очень условное разделение. Можно поточнее критерии?
Да просто одно это подмножество другого, как геймдев и геймдизайн.
Любое множество – (нестрогое) подмножество само себя. Короче, как выделять-то?
Произвольные языки общего назначения могут и неудобно компилироваться. Есть много реализаций компиляторов, которые не кроссплатформенны.
Это не цитата. Это сказал я, потому что это правда.
Грядущие Тоби Фоксы не будут кодить (а грядевшие уже не кодили) на C++ или C#, так как накладные расходы на освоение премудростей современных астральных арифмометров не оправдывают медленно достигаемый творческий результат.
Огромные компании делают ААА-проекты на языках общего назначения только потому что когда CTO сказал что нужно 100 программистов, это уже должны быть люди с многолетним опытом с каким-то языком, и на перестраивание этих людей под внутренние специфичные языки проектов или движков рассчитывать не стоит.
Большой геймдев просто паразитирует на большом айти (а также большом кинематографе, но сейчас не об этом), в итоге чего выходят недостаточно хорошие игры за гигантские деньги и сроки, от огромных команд раскиданных по нескольким странам. И именно это - бессмысленно и беспощадно. Причём настолько, что возникло понятие "инди-игры", на сайте по которым мы с вами, уважаемые, и находимся.
"недостаточно хорошие игры" будут всегда и были всегда, потому что это релятивистское и субъективное понятие. Какой бы не была игровая корзина всегда в ней существуют несколько лучших игр - и множество недостаточно хороших. При этом для разных потребителей лучшие будут различаться, а значит и пакет недостаточно хороших никогда не будет одинаковым.
с другой стороны - никакая из топ игр прошлого не способна честно соревноваться по качеству с современными аналогами. Если не отягощаться ретро-воспоминаниями, то ни обожествляемая в ламповые времена колда не лучше современной, ни шедевр игропрома нфс никак не лучше нынешних, ни халфа1 не лучше аликс. и такое относится ко всем игрожанрам буквально: анриал торнамент против гиперскейпа, плейнскейп тормент против дивинитей и пилларсов, резиденция зла против ремейка резинции зла. Даже выйди лютый фейл в виде постала3 одновременно с постал2 - и результат предсказать невозможно. И даже в областях где нет явных подражателей - типа пираты сида мейера нельзя сказать что сейчас эта игра топ.
И все это развитие возможно буквально только из-за огромных команд раскиданных по нескольким странам, из-за сотни программистов на языках общего назначения и прочих современных астральных арифмометров. Большой айти живет и дышит из-за геймдев-подработки.
И инди - это коммерческий миф появившийся задолго до геймдева. Мол ААА торгует качеством, а в нашей поделочке мы дарим "душу"(ну, не бесплатно конечно)
И не всегда умение сделать какие-то впечатляющие технические штуки стоит на противоположной стороне от создания инди игр.
В том же Boneworks, сделать такую сложную физику, думаю, было очень сложно, но это отделяет игру от всех остальных.
В Outer Wilds не уверен, сложное ли это программирование было и матан, или геймдизайнерские трюки, но многие вещи там прям очень впечатляли.
Резиновый мотоцикл в Elastomania, игры со временем в Braid и пространством в FEZ, Hyperrogue и Miegakure, бесконечный разрушаемый мир в Terraria и Minecraft, 10005000 реалтайм-механизмов в Factorio – всё это было бы нереализуемо* без привлечения «унылых многословных языков общего назначения», в «конструкторах игр для компози непрограммистов».
Избыточно мощные и сложные языки не всегда нужны, это факт. Но отметать те случаи, где без них никак – махровый юношеский чёрнобеломаксимализм.
*кто скажет, что «ну технически-то реализуемо», пусть сам в Turing tar pit лезет
Отлично! А теперь пора бы сжечь то чучело которое вы сделали из моих высказываний, и посмотреть наконец, что именно утверждалось исходно:
скриптинг > кодинг.Ну или давайте сразу так:
Lua, Python, GDScript, GML > C, C++, C#, Java в геймдеве, и чем более инди, тем более >.
Непонятно, что значит это «>».
Антибессмысленно и антибеспощадно.
Хорошо, вот тебе citation:
https://undertale.com/deltarune-update-092020/
Так а я-то что. Иди его минусуй. XD
А ты цитаты из контекста не выдирай.
Контекст подходящий - человек искусства использует инструмент, который дальше от науки, и ближе к искусству, для создания предмета искусства (ну или пускай просто медиа-ржаки, если надевать монокли и выпендриваться консерватизмом). И всё же не эти ваши физики-химии геометрий, которые удобно делать на языках общего назначения.
Держи в общем тоже лопату, и ставь мне ещё одну, раз это лучший диалог который у нас выходит. Обсуждать больше нечего.
Как скажешь.
Я, конечно, не особо опытен в инди-геймдеве, но мне показалось, что в делании игр важнее не сам язык, а доступность различных готовых решений для ускорения процесса разработки.
Ну, то есть, если есть достаточно много библиотек и справочных материалов, то среда разработки будет ласкать тебя как весенний ветерок, а если всего этого нет - то она будет карать тебя как здоровенный, жилистый елдак.
Lua и C# нужно поменять местами, я думаю.
Я всё понимаю про суть и удобство скриптовых языков, но для программистов-одиночек, которые не собираются делить код на основной и скриптовый... программирование на Lua это что-то вроде челленджа.
Сам язык хорош, многие вещи там супер-удобны, но страничка с выпущенными играми говорит сама за себя, к сожалению.
Количество игр на Юньке тоже само за себя говорит, как бы кто не относился к Юнити.
Хотя с Юней я знаком всё ещё шапочно, конечно, может ещё что-то другое скажу в будущем.
Специально приглядывался, когда играл. Там практически нечего симулировать - игрок да корабль да разведчик. Остальное - кропотливый труд 3д-аниматоров.
Насколько я понял, тягой своего корабля в игре не подвинешь даже самый маленький камешек в космосе.
И тот же терновник я сначала думал, что сделали системой бесшовных порталов, но иногда видно дергание корабля при залёте, так что это телепорт (возможно, в паре с увеличением-уменьшением).
А эффект чёрной дыры и то, как в неё отваливаются куски планеты?
Чёрная дыра - шейдер, а куски - анимация. Я так понимаю, метеориты падают всегда одинаково. И все ураганы и т.п. работают синхронно и детерминированно. А у тех элементов, которые меняются, вроде луны, нет коллайдеров вовсе - они не влияют на общую физику (которая в игре и так очень упрощённая и мультяшная).
Наконец доиграл до места, после которого можно спокойно смотреть документалку от noclip. Всё-таки у игры жёсткая техническая основа в плане симуляции гравитации и системы жидкостей. Например, на стартовой планете в невесомной пещере невесомость реально из-за того, что она в центре планеты.
Даже планеты в реалтайме считают? Так ведь можно неправильно округлить и запустить планету мимо цели. Или симулируют, а потом запекают в анимацию?
В видео они рассказывают, что в самом тяжёлом случае, им надо просчитывать, что происходит на трёх планетах - если игрок на одной, корабль на другой и зонд на третьей.
Но что именно просчитывать? На что влияет зонд/корабль? Ведь планеты живут сами по себе.
Получается, как будто в лёгком случае игрок в корабле, а зонд - в кармане игрока. А в сложном они по отдельности, поэтому надо просчитать движение каждого из них (по одним и тем же формулам). Типа, вау, у аниматоров лопнул от физики мозг, а Юнити лопнуло от того, что мы двигаем кучу коллайдеров (большинство из которых друг на друга не влияют), и программисты так намучились с Юнити...
Но при чём тут планеты и происходящее на них? Ну сплющило корабль между двух движущихся коллайдеров планеты (изменение которых от времени эквивалентно анимации, если внешние факторы - игрок, корабль, зонд - не меняют их, а они на моей памяти этого не делают), ну отметили это на карте. Но планета разве поменялась от этого?
Из-за квантовых лун? Но они же вроде не влияют на другие тела. Разве что тот синий шаттл в начале летит по направлению луны, кажется. Но от этого всего лишь добавляем к вычислениям 4й объект (шаттл), снова не влияющий на планеты.
Имеется в виду влияние всего происходящего на планете на игрока/корабль/зонд.
Смерч запускает ввысь зонд, обломком brittle hollow сбивает корабль в чёрную дыру, песок на близнецах сбивает на другую планету и т.д.
А, ну понятно тогда. Просто фразу "всё-таки у игры жёсткая техническая основа в плане симуляции гравитации" я прочёл, как будто то, что сказали в ролике, противоречит написанному мной ранее, что симулировать в реалтайме необходимо только несколько объектов в игре, а остальные - предопределены.
По сути луч гравитации внутри пустотной сферы аналогичен и смерчу, и песку. То есть имеем трубку, нахождение в которой применяет на объект силу в направлении трубки.
Насколько я помню, если смерчом подняться вместе с островом, то остров будет цел, но корабль может от него легко отскочить (разница между "симуляцией" других островных объектов и корабля). При этом его можно припарковать в определённых точках острова, и тогда он станет фиксированной частью острова.
Обломок предопределён, поэтому он двигает корабль, а корабль его - нет (даже если это маленький обломок). При этом метеорит нетрудно пролететь насквозь на корабле без последствий, хотя можно было взрывать при этом корабль. :) Но планету метеорит ломает - в предопределённых местах.
Я просто не знал, что у них реальная симуляция притяжения и всего такого. Типа, изначально был университетский проект, где планетки, их орбиты в зависимости друг от друга, притяжение на каждой и т.д.
Думаю, если тебе интересно, стоит посмотреть видео. Пересказ в комменте в своей интерпретации всяко будет хуже объяснения от самого разработчика.
Так я не знаю, дошёл я до какого-то там момента или нет, но, думаю, что нет.
Смотреть стоит, когда ты как минимум примерно представляешь, что надо будет сделать для конца игры. Там в целом без спойлеров, но пару раз роняют
"Лучше" - также релятивистская штука, как и "недостаточно хорошие игры". Это как современное и древнее сознание, актуальное для своего времени и мешающее выживанию не в своё при наличии в обоих случаях сложнейших, свойственных только своему времени паттернов. Старые игры уступают технически, но вот сравнивать по основанию письма тот же плейнскейп и пилларсов в пользу последних можно лишь с уточнением, что мы в письме прежде всего ценим фэнтезийную графоманию эпических масштабов. У меня нет никакой ностальгии по отношению к плейнскейпу, т.к. играл в него примерно в то же время, что и в пилларсов. Или старые ультимы - во многом уступают современным рпг, но уровень отыгрыша в разы выше, тот же парсерный ввод текста в старых частях позволяет легко застрять, не вставив нужное слово, но создает иллюзию мира, в котором мы говорим о чем хотим сами. В противном случае в старые игры бы не играло новое поколение, лишённое ностальгии. Да, увлечение не для всех, но для многих - посмотреть хотя бы на игроков в games done quick, которые часто моложе игр, которые они проходят и людей, которые это смотрят.
Вне зависимости от количества людей, которые продвигают разработку, корпорации это или инди-одиночка, разработчики двигаются по наитию, на ощупь, многие новые фичи не приживутся, редкие - станут стандартом, легким поветрием на ближайшее время и крайне редко - войдут в общепризнанный стандарт. Другое дело, что у корпораций с его множеством специалистов и денежных ресурсов, больше шансов реализовать какое-то техническое новшество, в том числе и на каком-то непривычном или сложном для стандартной разработки языке.
Да вот как раз нет. Когда в последний раз в ААА-сериях было что-то новое? Мы точно говорим об ААА-проектах, цель которых минимизировать риски чтобы максимизировать прибыль? Я ради эксперимента в 2019 году сыграл в Call of Duty: Modern Warfare (того же года), и что я увидел? Какую-то супер-физику? Супер-графику? Обычные казуальные пострелушки с эпизодическими гоночками, поток геймплея уровня чуть выше первой Халвы (а это, напомню, 1998).
Ну да, я понял. Не всем нужен геймплей. Не обязательно игра должна быть игрой. Я не буду наматывать эти круги по десятому разу. Сравнили мнения - они разные - проехали.
А технические новшества не обязательно пишутся на языках общего назначения.
В Shadow of Morder/War была крутая система антагонистов
В Just Cause 3 и 4 физон и разрушаемость
В Dishonored/Prey не то, чтобы что-то новое, но возродили жанр immersive sim'ов
В RDR 2 довольно хорошо построили игровой мир и поток ситуаций/миссий разной степени рельсовости и важности
В следующем Watch Dogs делают довольно интересную систему с рекрутингом и выбором, кем играть
Согласен со списком. Только ни для чего из этого не обязательно было кодить, достаточно было скриптить. Физон можно спокойно аутсорсить из обычного айти и никак не знакомить его создателей ни с игрой, куда он делается, ни даже вообще с геймдевом.
https://80.lv/articles/dishonored-abilities-implementation-level-design/ - скриптинг.
Это же не означает, что нужно было 1400 людей чтобы сделать ту же Зельду, но по-новому?
Прошу прощения, а на каком основании ты выносишь разработку игрового физического движка, системы динамической подгрузки большого открытого мира, или ещё какого-то технически сложного модуля, из процесса геймдева в некое несвязанное с ним «обычное айти»?
И где же игры с техническими новшествами, написанные не на языках общего назначения?
А чем обосновано это якобы существующее понятие - "игровой физический движок"? Звучит примерно как "игровая футболка" или "игровая кепка", для настоящих геймеров.
В играх есть физика потому что это уже когда-то было нужно кому-то в науке и технике, но никак не наоборот. В тренажёрах для военной авиации, всяком таком. Динамические подгрузки не специфичны для разработки игр - в науке это делают десятками лет с тех пор как появились ЭВМ, и если директор или кто-то там решает что нужно изобретать свой особенный велосипед для типовой научной задачи - это его личные тараканы, и никак не обосновано. Есть ведь формализованная цель - для загрузки уровня нужно чтобы N объектов выполняли M вещей за T времени. Нужда в посвящении исполнителей низкого уровня в детали высокого уровня говорит только о плохой иерархии и разделении обязанностей в проекте. Приведу пример разделения обязанностей в стеке разработки игр.
Один нидерландский профессор создал программу, известную теперь как GameMaker. А один сотрудник Blizzard Entertainment создал библиотеку для просчёта физики Box2D, которую встроили в GameMaker. Ни тот, ни другой, не являются разработчиками игр, а являются обычными айтишниками, просто рядом с играми. Где их людография? Участвовать в инженерном обеспечении хоть малых, хоть больших концертов - не означает, что ты музыкант.
Что мы видим на одной из страниц Гитхаба последнего?
https://github.com/erincatto/bullet3
Всё это смежные области, а VR не обязательно игры, и даже в основном не игры.
Я говорил что пишутся технические новшества, а не целые игры. Игры не "пишутся" и не "кодятся" - они создаются как комплексный продукт. На следующем перекривлении моих слов я заканчиваю с этой водой в ступе.
Все вон хайпают на графоне в играх. А языки шейдеров - они не общего назначения. Как насчёт физики на видеокарте?
Да кстати, совсем забыл про божественную Euphoria на которой сделаны rdr и другие игры Rockstar.
Кто с этим спорил? Так и есть. Но раньше это обходилось куда дешевле по деньгам и людям.
Речь об играх, которые уже по задумке должны быть лучшими, ААА-проекты потому так и называются, что у них прогнозирован почти-гарантированный успех, и обломаться с ним можно только реализуя уже известные вещи так, как не нужно реализовывать. Один из частных случаев такой ошибки - это форсирование языков общего назначения там, где намного эффективнее был бы скриптинг.
А в Юнити это везде (нужно решить проблему - в 99% случаев пиши код на C#).
И в УЕ это везде (кроме блюпринтов, но C++ в остальной части проекта ещё хуже).
Не вопиюще ли?
Речь шла именно об инди-играх. Коммерческий? Классическая инди-игра Cave Story, как и многие другие, - бесплатна, have it at you. То, что её подсуетились и продали в Стиме другие инди-издатели - совершенно отдельный факт, никак не делающий понятие инди мифическим. Spelunky, Iji, и так далее.
http://www.homeoftheunderdogs.net/scratch.php - зацени, если не видел раньше. Там вполне доступно объясняется почему это:
Неверно.
какая лютая желтизна, прости оспади. Как можно ретранслировать мнение которое так нагло, бездоказательно и беззастенчиво навязывает эмоции и идеологию, фи.
What do you need to create a game? Two people and a copy of Code Warrior.
NetHack, still one of the best computer games ever created.
Under the dysfunctional business model that rules today... .
Game programs cost too much for most people.
я, конеш, надеюсь что это длинная шутка высмеивающая левацких коммерсов, но наш мир такой непредсказуемый, что прям хз.
Cave Story ты упоминаешь как правило? или как явное отхождение от традиции(исключение) указывающее на то, что обратное правило таки существует? Cave Story+ за невменяемых 350р принадлежит тому же самому Daisuke Amaya из Studio Pixel, что и Cave Story. Какие другие люди ее продают? Его Kero Blaster и NightSky также продаются в стиме
ну, вабще-то наоборот. Ты уже знаком с одним из самых удобных, распространенных, перспективных коммерческих языков? Или хочешь через геймдев войти в IT и по пути изучить то, что непременно пригодится тебе в будущем? Добро пожаловать
а объяснять провалы ААА неиспользованием скриптинга это прям за гранью: mafia iii, duke nukem forever, fast & furious, flatout 3 безусловно провалились из-за выбранного для разработки языка
Да, это она. А истина посередине. Безусловно двух человек в 2020 году будет мало для большой хорошей игры. Но 1000 человек это явно много. Для любой игры вообще в принципе. Нет таких игр в 2020, для которых можно обосновать задействование такого количества рабочей силы. Кроме как если настаивать что нужно забивать гвозди микроскопом.
По-твоему продавать инди-игры это традиция? Инди-игры это любые игры создаваемые по фану и не под внешним продюсерством (возможно под внутренним в малых командах, ну там 5-10 человек). Где написано что инди==коммерция?
Кейв Стори это просто одна классическая игра, которую я когда-то, 13 лет назад, переводил на русский язык, просто так, чтоб люди играли на русском, бесплатно. Нашёл я её на сайте freeware (ни о каком "инди" или "doujin" речь не шла) игр, среди которых была масса других, как ты это сейчас захочешь представить, "исключений из традиций", хотя никакой традиции нет. Просто есть коммерческое инди, а есть некоммерческое.
Посмотри на мой гаминский профиль хотя бы, там все оценённые мной в базе игры (само собой это не все которые я знаю) кроме Ундертале, Айзека и тех что издаю я сам - бесплатные.
https://gamin.me/users/xitilon-hd408/game_votes?rating=0
Не только из-за этого, но всегда в том числе. Переставайте уже играться квадратиком, я говорю не те всеобъемлющие высказывания, с которыми вы спорите.
Например, если разработка на C++ это ад, это не значит что нельзя через адские муки сделать игру. Можно. Потому и нужно столько людей, чтобы всё это одолеть. Всё же логично.
"кроме тех, что издаю я сам"
кек
но кроме того, стим платно:
Undertale, (Super) Hydorah, Elasto Mania, Spelunky, Revenge of Roger Rouge, Pixel Gladiator, Factory Balls, (Super) Dangerous Dungeons, Bombarde, Ninja Senki (DX)
Armor Games:
Upgrade Complete, I saw her standing there
kongregate:
You Have To Burn The Rope, I Left My Heart In The Trenches.
и Айзмейз - спонсоред линки
ад - это все таки вагоны разгружать, ночью, в феврале, голым, в степи, с волками, под надзором, бесплатно. Разработка на С++ и тем более на С# почти блаженство.
Вообще экономия миллионов человекочасов для АААиздателей путем настройки их рабочего процесса может оказаться крайне эффективным способом приобретения начального капитала. Но, боюсь, что частноутвердительные, частноотрицательные суждения предъявленные в качестве закономерностей там будут малоубедительны.
Не считаются, оригиналы бесплатны, это HD-версии. Pixel Gladiator издавал я, просто он передан в админку разработчика теперь, чтоб более инде.
В любом случае, в списке 78 игр, ты привёл ну 15. Остальные бесплатны, и поэтому повторюсь:
А убедительна - только практика. Сравним наши блаженства на финише.
Вот тут я бы поспорил. Нынешние части зачастую попросту безуспешно пытаются повторить формулу и успех Underground 1-2 и Most Wanted 2005, при этом постоянно фейлясь в той или иной области игрового процесса, будь то собственно атмосфера уличных гонок, плохо сбалансированные копы или превращенная в рутину кастомизация.
Мне кажется, если отрескинить mostwanted и положить его в стим, то сразу вылезут все его болячки, непростительные для сегодняшнего В-проекта - деревянная физика, отбитый АИ, полностью отсутствующий баланс и развития транспорта, и требований по очкам престижа(многочасовая однообразная езда от копов по кругу из-за которой игра оказалась непроходимой), отсутствие мультиплеера, практически неразличимые и нечувствуемые по современным меркам авто. Даже графен это важная часть геймплея - он участвует и в балансе целей и угроз, обеспечивает поток игроку.
Самые провальные были прострит, андеркавер и новый МВ? но они проиграли не предыдущим частям, а взлетевшим с тех пор ожиданиям. Авто ощущается много лучше, город разнообразнее, гонки насыщеннее
поэтому мв-2012 за 999 в стиме торгуется, а мв-2005 только в геймпарке за 300. и то в наличии нет
И кстати говоря ещё интересно что сейчас слово "инди" является волшебным словом благодаря которому игроки проявляют периодическое снисхождение к девелоперам. Типо сомневаюсь что например, если какая ни-будь юбисофт выпустит среднего качества пиксельный рогалик, то её не "подымут на вилы", а вот если инди василий петровичь, то всё норм)
Их поднимают на вилы, потому что обещают игру лучше (в том числе, через трейлеры), чем получается на релизе.
ну, так-то тоже верно... но я к тому что было-бы нелепо назвать пиксели ааа.
юбисофт child of light выпускала, ее, кажется, просто решили не заметить
Зато заметили Valiant Hearts. :) Её мне как-то рекомендовал один геймер, который не играет в инди.
Нюанс не только в болячках игры. Такие аспекты как ИИ и физика как бы подразумеваются как обязательные улучшения в наших реалиях. Однако, всё же, при всех технических улучшениях, новые игры редко умудряются предоставить игроку тот опыт, который доставлял удовольствие от игрового процесса в старых играх.
Например, я играл в NFS Heat, и там вроде есть всё, что надо современной НФС - графон вполне современный, ночью игра вполне напоминает осовремененный визуал Underground, физика передает вес машины, но не превращает игру в симулятор, копы предоставляют угрозу, а не цели для битья. Вот только эти все элементы попросту не складываются в хорошую игру. В общем итоге ты не чувствуешь, что тебе стоит играть в эту игру. И ведь тяжело объяснить, в чем проблема, она чисто на уровне восприятия. Лично для меня составляющие игры не сложились в крючок, который был у той же MW 2005.
Блин, а я подумал, что Октопус писал про первую NFS. %) :D
про всю серию, они вроде взрывали чарты непрерывно до самого карбона.
но, кстати, да. интересно раз ЕА ни разу после не сделала хита, значит все улучшения и геймплея и ттх не привели к революционному прорыву после MW при том, что до карбона делали бум в каждой части
и либо я оч.преувеличиваю количество достижений, либо публика сильно изменилась
Ну Type inference это не какая-то далёкая мечта, во всяких котлинах/свифтах он реализован на всю катушку, в остальные языки тоже потихоньку пытаются добавить что-то подобное (auto и т.д), но конечно не в таком масштабе.
Из-за этого же во многих молодых языках типы двигаются направо.
Если быть точным, в большинстве языков (включая Kotlin и Swift, если правильно понимаю) вывод типов только локальный, внутри одного предложения или выражения, это совсем неполная катушка. В Rust, Scala (вроде) и вышеупомянутом Idris вывод в рамках целого определения функции. Наиболее глобальный – в ML-семействе (Standard ML, OCaml, F#) и примкнувшем к нему Haskell.
Type-to-the-right во многом не только из-за инференса, но и чтобы грамматику языка упростить – ещё в древней сишечке
foo * barозначает совсем разное в зависимости от того, является ли foo именем типа или значения.В Crystal тоже глобальный. И без этих ваших хэндлимиллеров, чисто влобный подход.
То что язык движка строго типизирован ещё не значит что он не будет валиться в рантайме. Кривого ввода от пользователя и некорректной работы с памятью и бесконечных циклов никто не отменял так то.
Сборщик при компиляции проверяет только синтаксис и типизацию. Некорректную работу алгоритма он проверить всё равно не может. Если ты обратился к несуществующей ячейке массива, например.
Пусть не сборщик. Отладчик же есть? Трассировка стека, с возможностью пошаговой проверки пользовательских фкнкций?
Конечно есть. Программиста хорошего только вот не выдают автоматически при запуске среды разработки. Приходится самим.
Верно, в минимальном виде типизированный компилятор проверяет только правильность типов. Есть всякие уловки-паттерны, как разные вещи выразить в виде типов, но это именно уловки. :)
Типизация в GML динамическая (типы переменных известны только в момент запуска и могут меняться), но относительно строгая (нет неявных приведений — ну там, нельзя число со строкой сложить), впрочем, типов в принципе полтора землекопа (числа, строки, массивы, структуры в 2.3, и ещё парочка) и приводить особо нечего. Механизм исключений завезли только в свежевышедшем 2.3. В общем, с обеспечением надёжности кода, компайл-тайм гарантиями и обработкой ошибок туго. Впрочем, отладчик с бряками и просмотром переменных таки есть.
В общем случае они неизвестны и в момент запуска:
that это чего такое?
Думаю, тут имеются ввиду условные методы this и that (не думаю, что this в этом контексте упоминается как, скажем, this в шарпах)
Название вызываемого скрипта (или функции), как и this.
Да, конечно, это у меня формулировка кривая. Читать как «во время выполнения».
у меня нет такого... как я это должен отловит?)
А что, есть разница, вылетает платное или вылетает бесплатное? Вам шашечки или ехать? В обоих случаях кодеры могут быть криворукими.
странно... ещё у кого-то есть что-то такое? (мб система не может переварит сюрфейс? а что за система?)
Я не вижу код, но могу предположить одно из следующих:
1) Рисуешь слишком много геометрических примитивов в один такт (прямоугольники и линии) - нужно менять на спрайты, например один пиксель который растягиваешь и рисуешь так примитив.
2) Утечка памяти - создаёшь сурфейсы и не высвобождаешь память когда они уже не нужны.
Для начала не совсем понимаю когда и откуда эта ошибка. 1) вполне возможно, 2) тут странная тема так как всё чищу, но при этом если часто "пересоздавать" (именно кликать на кнопку) то почему-то занимаемая память растёт... Но всё-же это нужно очень постараться чтобы довести её хотя-бы до 1 гига. 3) Думаю что возможно сам сюрфейс не вмещается в ограничения видеокарты.
Возможно где-то не чистишь.
Ещё draw_primitive функции могут память отжирать если объектов слишком много, или если не написал draw_primitive_end.
У меня уже была такая проблема
Это было из-за того что я рисовал много мелких прямоугольников. Порядка 500-800 штук. Я заменил на спрайты и всё стало ОК.
хм... тогда возможно и draw_rec тоже этим страдает... (хотя странно что он накапливается только если жать быстро... а если медленно то вроди и нет...)
Занятно, но не совсем представляю, для какой игры такой генератор может пригодиться. Даже в рогаликах балом правят комнаты, а не коридоры. Тут в результате добрых 80% площади - коридоры.
ну, это можно подкрутить... но сначала нужно встроить и посмотреть как оно будет) спасибо.
В серии GTA тоже много дорог, особенно, в частях, где много загорода. Поэтому перестал играть в эту серию, скукота.
А кто-то играет во всяких дальнобойщиков...
Мне в ГТА норм было покататься по миру, атмосферно...
Не уверен, но вдруг пригодится.
https://www.youtube.com/watch?v=K7sKUuSd8ME&ab_channel=HeartBeast
Немного не то. Скорее это: https://www.youtube.com/playlist?list=PL9FzW-m48fn2gQVYFxDzq4cz2A4uGWusx