Есть у меня мыслишки по поводу изучения

Есть у меня мыслишки по поводу изучения какого-либо ЯП. Но встал вопрос о выборе. Лично у меня есть желание поизучать С++, и лично представил свой маленький путь:

Ноль в программирование ->? -> C++

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

Почему C++? У меня есть кое-какие планы (речь идет о моделировании, анимации и всё, что с ним связано) в обозримом будущем, и они не связаны с геймдевом как таковым, но наличие знаний именно этого языка желательно (по крайней мере это пока лишь планы и нет уверенности в том, что они реализуются, но всё же).

171 комментарий

А почему не питон? Можно было бы теоретически поскриптовать моделирование с анимациями в блендере

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

Блендер сильно изменился.

да, сейчас там прикольный редизайн сделали

Я как-то начинал изучать питон. Бросил как только узнал что там может быть ошибка из-за лишнего пробела.

"Выполнится ли след. строчка?" Нет, она в коментарий попадет.
Больше всего бесит в Си то, что если ты допустил ошибку в одной строчке, то компилятор сообщит тебе об ошибке в другой строчке. Забыл поставить } и все - компилятор тебе ничем не поможет, иди ищи сам где ты ее забыл поставить. Или поставил \ и все, весь последующий код превращается в тыкву.

В Lua (ну или во всяком случае, в Love2D) с этим проще. В этой же ситуации фреймворк всегда говорит в какой строчке находится начало блока, который ему не удалось закрыть. Сразу находишь и закрываешь.
Мне больше всего нравится Lua. В нем тоже есть проблемы, но хотя бы таких как в Си - не возникает. Этот язык менее требователен к аккуратности и там есть словари с ключами из коробки, поэтому он лучше подходит для говнокода быстрой разработки игр, чем Си. Непосредственно для программирования игр Си не предназначен.

да, с подколом промах, я почему-то думал ты на Си пишешь. А луа я вполне одобряю за паскалевский синтаксис (и индексы с 1), но сам конечно на нем писать не буду (за таблицы вместо нормального ООП).

Я и на Си пишу. Но не игры, а прошивки для микроконтроллеров.

за таблицы вместо нормального ООП

Зато так быстрее говнокодить и не надо много лишних слов писать, class, public, override и т. д.

на руби тоже никаких лишних слов и рай для говнокодеров, но ООП настоящий.

Опять еще один ЯП? В игровых движках он хотя бы используется?

Используется в Libgosu и в моем личном. А, стоп, еще в РПГМукере.

Но так-то я его и не рекламирую и понимаю что луа в геймдеве намного популярнее, просто говорю что ООП не означает кучи лишних слов.

И перешёл на луа, в котором индексы начинаются с единицы :)

Так, на самом деле, удобнее. Не приходится всякий раз делать "+-1 элемент" в уме.
Хочешь массив из 10-ти элементов, создаешь список где 10 - номер последнего элемента (а не 9).
Да, в компьютере массивы начинаются с 0, но людям от этого только хуже. Из-за этого размер массива всегда на 1 больше номера последнего элемента.

Это меня немного путает, потому-что в остальных языках с нуля)
но в остальном Луа мне нравится, я даже в своё время искал себе нормальный движок для этого скрипта,
ибо Tic 80 мне уже мало, там мало спрайтов можно добавить, а я хочу хотя бы был атлас на 1024*1024 пикселей, чтобы можно было делать мини игру покемоны, а Love2D мне как-то не зашёл,
очень сложно там простое окно сделать как в Tic80, чтобы было LowPixels, оконный режим и окно как угодно могло изменяться по воле юзера. А ещё с Love2d мой ноут сильно греется, и там говорят какие-то ошибки бывают с шейдерами, короче я пока остерегаюсь сего творения)
Ещё нашёл Defold , но там так мало документации, мало примеров кода, и походу там всё плохо с оффлайн документацией, что я забил пока-что и на тот движок.

А вот такой пробовал? Там вроде ретро, но с возможностью выбора, и луа. По описанию звучит, как будто прям для тебя делали.

И вот ещё почитай список. :)

А ещё с Love2d мой ноут сильно греется, и там говорят какие-то ошибки бывают с шейдерами

Бывают, напишешь не совсем корректно шейдер, на современной видеокарте (драйвере) проглотит, а на старой - ошибка может вылезти.

А ещё с Love2d мой ноут сильно греется, и там говорят какие-то ошибки бывают с шейдерами, короче я пока остерегаюсь сего творения

Так-то да, он не для ноутов. Можно или не писать шейдеры, или взять более древнюю версию движка.
Например 0.9.1, у нее требования ниже (у 0.10.0, например, есть такой пункт "Updated the minimum runtime system requirements of LOVE to require OpenGL 2.1 or OpenGL ES 2 support"). На ссаных ноутбуках игры на 0.10 уже не запускаются. Но, так-то на таких ноутбука игры обычно вообще не запускаются, либо дико тормозят.
Там разница между разными версиями не так велика, в основном это переименования функций и багофиксы. Из нового начиная с 11.0 движок развивается в мобильном направлении. Но 0.11 уже не работает на WinXP.

Я в основном пользуюсь 0.10.1.

Если более по теме, то нет, не начинай с C++. Там много нюансов, архаизмов синтаксиса и устаревших практик в статьях, которые следует игнорировать, а не применять. Тем, кто, как я, учил C++ давно, сложно будет посоветовать, с чего сегодня начать всё это безумие. :D

Если моделирование и анимации, то почему именно С++?

Если интересует именно какой-то ЯП, то можно взять Питон или Го, там порог вхождения пониже. Ещё можно Котлин (и можно было бы Свифт, но тут по сути vendor lock)

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

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

Ты бы погуглил на всякий случай, может, там С++ уже не актуален :)

https://insights.stackoverflow.com/survey/2018#most-popular-technologies

я за до диез. Если его двигает майкрософт, знач ничо плохого с ним не случится. Проще чем плюсы и на 10 лет современнее Жавы

И в каком игровом движке или видеоредакторе он пригодится?

в Юнити. Можно прикрутить в Unreal

Там C# и JavaScript. Причем последний в посл. версиях, кажется, убрали.

Я считаю что Си обязателен потому что после него любой другой язык учить станет намного легче.
А то возьмешь какой-нибудь движок/прогу, а там свой собственный Си-подобный язык или вообще уникальный. И тебе его с нуля придется учить.

я так и сделал, вначале я освоил С без плюсов) а потом уже стал изучать другие языки,
правда минуя С++, я всё равно плох в ООП, как художник - нелюблю эти сложные понятия, и только благодаря
юнити я немного понял, и больше освоил эти сложные вещи как ООП и то только поверхностно,
но уже без С++, походу я так и не осилю этот язык, если только не появится хороший движок, ради которого его стоит осваивать (хз насколько С++ отличается от С#, но С# я освоил в пределах движка юнити и уже могу читать и писать на нём немного, пока не доходит до сложных вещей, но игры писать могу и без сложных вещей :D )

хороший движок, ради которого его стоит осваивать

UE4 :) Но лучше бы они сделали там скриптовый язык из коробки (блюпринты и C++ - это крайности).

Примечание для триггерусов - блюпринты и C++ - это крайности для программирования геймплея, а не для программирования игр вообще.

Я тоже ООП с Юнити изучал, в Си++ слишком сложно и наворочено все.

Конкретно язык шейдеров для видеокарты на 90% совпадает с языком Си.
По сути это и есть Си с небольшими изменениями.

Нас в школе сначала учили писать на QBasic. Потом я сам пересел сразу на Си. Первые две недели было тяжко, ничего непонятно, слишком много всего сразу вываливают на голову чтобы написать простую программу. Даже начал сам себе книгу по языку писать чтобы самому было проще разобраться.
Потом в институте был Паскаль, я его не хотел учить, зачем если я уже знал Си.

Не могу посоветовать с какого языка лучше начать, но не советую сразу начинать с языка Си. Сначала надо выбрать что-то попроще.
Но считаю что после изучения азов программирования и получения навыков до уверенного уровня, правильно будет попробовать другие языки, с разным синтаксисом и парадигмами, чтобы понять чем они отличаются и чем одно лучше и хуже другого.
Но язык Си знать обязательно (или Си++, но без классов). Многие другие языки на него похожи, после Си их будет легче учить. С классами нужно хотя бы поверхностно познакомиться чтобы читать и понимать как использовать уже готовый код. Писать с ООП не всегда нужно и более гемморойно, чем обычными функциями и может пригодиться только если ты игру на своем движке делаешь.
Касательно классов, то тут лучше познакомиться с C#, мне не все в нем нравится, но он хотя бы на себя берет все дела с выделением и освобождением памяти. Ты просто пишешь класс, не думая где и когда тебе сколько памяти надо выделить и когда ее освободить.

Возможно правильно будет начать с паскаля, а потом перейти на Си. Синтаксис и ключевые слова из паскаля тоже во многих других языках используются (Delphi, LUA, python, кажется).

И учи технический английский. Читать документацию на английском по всяким API и движкам придется много, не всегда она есть на русском (это если ты потом хочешь как-то применять свои знания по языкам, а не писать "5+2=7").

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

Все правильно, только чтобы набираться опыта - нужно писать программы. А для этого надо знать хотя бы 1 ЯП.

Парадигмы программирования можно изучать на абстракциях и блок-схемах, не прибегая к ЯП вообще.
1) Вот есть ООП, там объекты которые умеют наследоваться и менять своё поведение, есть ещё события которые дёргают те или иные функции объекта.
2) В таком-то ЯП чтобы сделать объект - делаем вот так, а в другом вот-так. А события вот так выглядят, а вот так их можно задавать и првязывать к объектам.

Зачем двигаться от частного к общему, когда можно и проще и быстрее от общего к частному =)
Это всё равно что сперва учиться писать на английском, а уже потом учиться говорить на нём и понимать его смысл.

нет, это все равно что сначала учить абстрактную грамматику, а потом уже русский или английский.

Неубедительный аргумент, попробуй ещё.

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

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

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

Это никак не поможет выучить английский \ научиться делать плагины анимации на С++. Вот если учить одновременно с практическими примерами из хотя бы одного языка (и соответственно учить этот язык, чтобы примеры не оставались абракадаброй) - другое дело.

Тебе точно не пройти собеседование в гугл XD

Зачем объяснять сложно, когда можно просто? Что такое рекурсия? Это самоповтор до каких-то пор. И показать это на рисунке блок-схемой гораздо прочем чем заставлять человека вдуплять в функцию подсчёта факториала на С++, Lisp и ещё каком угодно другом языке. Когда знаешь смысл, и понятия которые используются в сфере - гораздо проще постигать грамматику и синтаксис. На своём опыте уже много раз убеждался причём не только в сфере программирования.

Ты либо учишься думать, понимать концепции. Либо как робот хуяришь код как в примерах. А зачем последние в IT-сфере? Она не для распиздяев и не для биомасс создавалась. Тем более в сфере игростроя без мозгов никуда.

Тебе точно не пройти собеседование в гугл XD

Что такое рекурсия? Это самоповтор до каких-то пор

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

Уже сколько раз видел вопросы с собесов гугла в духе "объясните ребёнку что такое база данных".
Вот ты как будешь действовать? Будешь читать полный курс по SQL? Или начнёшь вдаваться в теории о реляционных и не реляционных БД? Или скажешь что это место куда можно что-то положить, а потом можно это вытащить?

Даже далеко ходить не нужно - летом мне пришлось изучить шейдеры. Несколько лет я считал что это очень сложная тема с которой хер разберёшься. Я не стал курить примеры, читать спецификацию языка GLSL. Прежде я уяснил что это такое - просто прочитал пару статей про СУТЬ. И всё стало понятно. И примеры сразу стали понятными, и даже свои первые довольно простые шейдеры я относительно легко написал.

Через практику тоже можно, но это гораздо более длительный и более граблистый путь нежели теория->практика.

Уже сколько раз видел вопросы с собесов гугла в духе "объясните ребёнку что такое база данных".

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

SQL - это не база данных, а язык запросов. База данных - это просто информация, которая организована для удобного к ней доступа.

Я не стал курить примеры ... просто прочитал пару статей про СУТЬ ... И примеры сразу стали понятными

То есть ты так же в итоге научился первым вещам на примерах. Суть можно было прочитать и после, связав свой накопленный опыт в единую систему. А до VFX-специалиста тебе очень далеко всё равно (и с сутью, и с переписыванием примеров).

То есть ты так же в итоге научился первым вещам на примерах. Суть можно было прочитать и после, связав свой накопленный опыт в единую систему. А до VFX-специалиста тебе очень далеко всё равно (и с сутью, и с переписыванием примеров).

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

И да, теперь я вспомнил почему ты сидел у меня в игнор-листе. Пожалуй там тебе самое место было =)

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

C# / Python, потому что порог вхождения ниже.

С одной стороны, программисты (даже если они себя так не называют) зная один язык знают (точнее думают что знают) все. Выучив один язык остальные учить намного проще, т.к. базовые концепции почти все совпадают и ты учишь только его особенности. Поэтому для освоения программирования бери любой простой язык по которому тебе понравится туториал. Питон, шарп, js, луа, да тот же гамак или гитхаб Haxe. Циклы, условия и переменные, функции и прочие основы везде одинаковые (ну, не считая экзотики типа функциональных языков), а разобраться проще в новых высокоуровневых языках.

С другой - люди которые по складу ума не программисты освоить программирование могут, но в довольно ограниченном чисто практическом диапазоне. Условно говоря - у них сильно ограничено число скиллпоинтов, которые они готовы в него вложить. Поэтому если ты не собираешься сильно глубоко в него погружаться, изучай только то что тебе конкретно надо. Даже не весь С++, а конкретно ту часть которая используется в пакете который ты планируешь использовать. Иначе все эти сортировки пузырьком, разворачивания односвязного списка и копирования подстроки по указателю тебе надоедят и ты забьешь.

Если потом, после первых результатов, поймешь что нужна более серьезная база - вернешься к пузырькам.

Условно говоря - у них сильно ограничено число скиллпоинтов, которые они готовы в него вложить.

Очень тонко.

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

Правильно поставленная задача это например "писать свои плагины для After Effects". Идёшь сюда и смотришь какие есть варианты, не все из них связаны с C++ вообще: http://www.gutsblow.com/Archive/36/intro-to-after-effects-plugin-development-for-beginners/index.html

Ну так сразу на С++ замахиваться, не имея опыта в программировании, я тебе не рекомендую. Советую начать с чего-нибудь полегче, например Python, C# или Java. Я вот, например, в школе выучил Паскаль, потом самостоятельно выучил C# из-за Unity и теперь хочу тоже выучить C++, но теперь я на него не смотрю как на непонятные иероглифы, даже сейчас могу что-нибудь простое на нем написать. Просто рекомендую тебе сначала понять логику ЯП, в этом тебе помогут более легкие языки, которые я тебе перечислил выше, а потом намного легче будет выучить C++. Так что удачи!)

Кароч, markertat, ты не в том месте вопрос задал. Тут тебе щас объяснят, что на Питоне нельзя писать, потому что там важна индентация, а на луа плохо, ведь там индексы с единицы, и вообще начинать надо с UML и хер на то, что он на практике ни к чему толком и не подходит. Так шо поищи какой-то подходящий курс на, например, курсере, а эту тему лучше снести, пока в очередной раз все друг другу глаза не повыцарапывали.

Чо ты сказал? Луа - плохо?!
Да я тебе за такое глаза выцарапую!

Действительно, форум отсталый, даже нет ни одного Rust-евангелиста!

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

А насчет срачей, ну тут я сижу давно, можно сказать что это норма (соседняя тема - яркий тому пример).

И как ты будешь подводить под общую черту совершенно непохожий опыт разных людей? :-)

Во-первых, понял, что изучать C++, не зная основ, глупо, поэтому надо взять на изучении что-нибудь попроще. Во-вторых, само собой, придётся совмещать теорию и практику, чтобы хоть как-то дело в этом плане двигалось.

markertat, не слушай всех этих упырей милых людей. Рассчитывай на собственную голову.

Собери побольше инфы - пойми какие ЯП бывают и для каких целей они используются. Выбери нужный для ТВОИХ целей. Можешь ещё сориентироваться ещё по сложности усваиваемости. Нелишним будет почитать про парадигму, которую выбранный тобой ЯП реализует - это сэкономит кучу времени на понимании принципов работы с этим ЯП. И ещё желательно ориентироваться на IDE, в которых пишут на выбранном тобой ЯП. От удобства работы с IDE тоже многое зависит.

P.S. Если кто-то упирает на какой-то конкретный язык - значит у него много практики работы именно с ним и глаз замылен, в следствие чего может начать предлагать то что для ТВОИХ задач не предназначено.

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

зачем вообще понимать что-то про парадигмы не собрав калькулятора?

Я смотрю, ты давно не был у Хейзера в игноре.

Кажется полтора года или даже больше!
Можно сказать - рекорд для амнистированных =)

Аналитика и сбор информации - важный этап разработки. Сколько проектов погибло из-за "эхххх нужно переписывать на таком-то ЯП".

И в 90% случаев потому что авторы не потратили несколько дней/недель на то чтобы сделать обзор разных ЯП под свои задачи, убедиться что там есть требуемый функционал. Ясное дело что это могло быть сделано а риск всё равно сработал. Но ведь уменьшать риск - лучше чем не уменьшать.

Если в программировании совсем ни бум бум, то лучше начинать с чего-то простого типа basic или object pascal (он же delphi). Так будет базовое понимание и c++ будет изучить немного проще. В любом случае чтобы изучить надо найти книжку с примерами которые начинаются с азов и заканчиваются чем-то более сложным. Прямо берешь и переписываешь примеры, начиная с hello, world ! Модифицируешь их немного так, чтобы понимать как, что и для чего работает. И так постепенно выполняя все более сложные и сложные примеры - учишься. А еще я сам лично (когда изучал) делал так: сначала ставил себе задачку и алгоритм описывал простым языком - ну например - заставить квадратик перемещаться по клавишам стрелок - далее в документации и мануалах искал нужные функции и методы и постепенно расписывал как решается задача. Т. е. по сути чтобы научиться программированию нужно будет освоить 3 вещи: сам язык, научиться формулировать задачи простым языком, а затем переводить их на язык программирования и 3-я - это научиться работать с документацией и различными мануалами - т. к. львиная доля программирования это именно копание в различных мануалах и доках - чтобы найти нужную функцию или объект и понять как её применить для своих целей. Само по себе программирование не так сложно как кажется. Это циклы, вызовы функций, описание классов, структур данных и различные операторы условий и математические вычисления. Вот собственно и все. Остальная часть - это именно различные вызовы функций и использование API операционной системы или интерфейсов, которые используются вашей программой или игрой (Win API, DirectX API и др.).

Так что изучить сам язык это лишь вершина айсберга. Нельзя изучить просто язык и не научиться его применять в конкретной операционной среде (операционной системе). Просто тогда это будет лишь бесполезная теория без умения создавать рабочие программы.

Я бы посоветовал начать с Basic, возможно Visual Basic, плавно перейти на Pascal, потом на Turbo C, Python и плавно перейти к Lua, параллельно изучая JavaScript, PHP и Ruby. Потом плюнуть на все и изучить C#, C++ и в итоге остановиться на GDScript. *шутка*

Я после изучения QBasic и Turbo C программировал на Visual Basic. Сначала сделал программу для рассчета кулоновских сил и баллистического движения, потом - первую игру "крестики-нолики".
Pascal/Delphi я тогда не знал, а Visual C++ был слишком сложный.
Потом еще несколько раз в институте макросы на VBA для экселя писал. Так что знания QBasic в дальнейшем мне все-таки пригодились.

вспомнив о годоте)
я тут в Godot начал аниматор изучать и кажется тут нет возможности сразу весь кадр двигать, а нужно выбирать абсолютно все ключи, долго скроллингом вниз шурша (особенно плохо с моим маленьким монитором ноута), что не очень удобно по сравнению с юнити(
может я не понял/не заметил и там есть такая вещь как копирование или перемещение сразу всего кадра анимации, через один общий контроллер кадра?

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

Кстати, как я логику юнити изучал. Вначале я начал со Stencyl (хотя до этого уже была практика с другими языками) , где можно конструировать код из блоков, там я много вещей понял, которые потом пригодились при программировании юнити. Ибо местами было похоже. Та же операция "SendMessage" есть.
То есть может стоит изучать вначале более простые варианты, где нужно собирать код из блоков или другим более простым способом, чтоб с логикой программирования ознакомиться.
PS сам я художник и учу программирование методом практики, методом тыка, проб и ошибок) пытался читать умные книги, и я совершенно не понимаю учёный язык и набор сложных заумных понятий, которые отвлекают от сути программирования, мне плевать как это называется, главное чтобы эта фиговина работала) как художнику мне сложно запоминать научные названия) поэтому я стал пробовать практику, хотя в самом начале я начал с С на Ms-DOS и Basic, и просто пытался модифицировать примеры чужого кода, или пытался написать "Hello world!" чтобы хоть что-то на экране появилось, а потом уже усложнял код

По личному опыту могу сказать, что игры - довольно хороший метод выучить принципы ООП. Я более-менее разобрался в основных принципах, занимаясь разработкой на UDK. После изучения парадигм, остальные языки изучать проще, там просто идет специфика нативных типов и синтаксиса.

Создание игры - практически единственный метод, которым я смог понять не только ООП раньше чем нам его вообще преподавали, но ещё и громадную часть математики с абсолютно ненужными мне иначе синусами-косинусами, аппроксимациями функций и прочим задротством.

это точно было создание игры, а не прогармерское движко-делание/обслуживание?

В 2006-2007 единственное, что я мог осилить, был Drag'n'Drop, какие там движки. Это Aliens X и WireNet.

Это было так давно, что я тогда ещё и Кситилоном не подписывался.

хмм. Jazz, аргументируй. Это интересно
(сорь, поправил)

Я человек простой, вижу ссылку на чупахабр, ставлю минус.

Дошёл до SQL и стало уже не смешно. Забавно, но уже не смешно.

Кстати, как вариант, сначала питон, потом гдскрипт, так как похож, а потом уже писать модули к годоту на c++

ну хз реальный ли это рейтинг, ибо юнька от JavaScript отказалась, подгадив мне на мой долгосрочный проект с 100-150+ скриптами, хотя там много мелких скриптов, но есть штук 10-15 по 60000+ символов, и придётся не хило постараться, чтоб перевести всё это на C#, а переводчики языков не помогут, ибо в C# нельзя делать те вещи, которые я делал на JS:
1) частое использование одной оси transform.position.x+=10, на C# нельзя
2) частое использование Array, этого нет в C#
3) и там ещё какие-то пункты по мелочи, придётся менять стиль программирования, а не только строки

прикольно будет, если также подгадит потом в будущем Godot, выучу GDScript, напишу долгострой, а эти тоже перейдут на C# полностью) вот будет весело) поэтому пока особо не учу Godot, мне как не программисту очень тяжко даются переходы на другой язык)

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

GDScript - для новичков, C# - для профи и повышение производительности, GDNative - для любителей других языков. Полностью не перейдут.

Почему "для новичков"? В первую очередь это изначальный DSL для движка, на котором можно делать быстро и красиво. Как GML в гейм мейкере.

Не ну это понятно, я имел ввиду, что вдруг в Годот потом отменят GDScript,
как Unity отменили UnityScript (они даже JavaScript переработали под себя и назвали UnityScript, но это не помогло им потом отказаться от скрипта)

На мой взгляд, раз уж нравилась версия, где была поддержка JS, можно было и не обновлять Unity (или сделать откат версии) и сидеть на ней. Ведь развитие отдельного движка интересуют больше самих создателей движка (и их инвесторов), и как бы они идут скорее за модой.

Я просто не уверен, будет ли стабильно работать эта версия и дальше,
допустим там потом найдут очень жёсткий баг.

"e Maker Language" - идеально. И заметьте - ни одного проекта на Гитхабе на Гамаке. (это заведомо херовая статистика, потому что я точно знаю что на нём лежит нелегально декомпилированный АндерТейл, и целый ряд фан-проектов по нему, тоже на Гамаке, типа такого; так что график - ложь, да в нём намёк, ведь АндерТейл создавался без ГитХаба)

А то что Гамак совершенно не популярен - вполне естественно, ведь это язык частного, а не общего назначения. Чтоб делать игры, а не прошивки микроконтроллеров, сервисы операционки, сервера баз данных, хостинги, и иногда игры.

Ты понимаешь разницу, например, между публичными и приватными репозиториями? :-)

Я понимаю. Хотя на графике не указано, о каких речь, так что непонятно к чему этот вопрос.

На графике 0 - некий коэффициент от 0 до 100. Не число репозиториев и даже не их процент (иначе бы ни у кого не доходило до 100).

Если сделать гитхабовский поиск для репозиториев с >9 звезд, то у "e maker language" их 67, у GDScript 337, у Crystal 592. Совсем без звезд поиск не работает (при слишком большом число репозиториев ищется только первая пара тысяч).

https://github.com/search?q=stars%3A>9+language%3A"Game+maker+language"&type=Repositories

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

Какие звёзды? Наворотили каких-то систем непонятных, непонятно что считают. Офигеть статистика.

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

Вопрос к тому, что ты не знаешь, как создавался Андертейл, потому что, если они использовали ГитХаб, то это точно был приватный репозиторий.

Тоби Фокс и ГитХаб это небо и земля, будь реалистом.

Давай, пробуй программировать уже.
Возьми ту же Turbo Pascal, мы тебе задания можем давать. Тебе понадобится только гугл.

1 задание (знакомство): написать прогу, выводящую на экран "Hello world!", успешно компилирующуюся и запускающуюся.

2 задание (ввод-вывод): нужно сделать сложение двух целых чисел, ввод их с клавиатуры и вывод на экран.

3 задание (ввод-вывод и ветвления): ввести имя, пол и возраст. Вывести сообщение что вы подходите нам на работу если ваше имя не длинее 8 символов, возраст от 18 до 30, пол - мужской.

4 задание (ветвления): ввести 2 вещественных чисел и название функции, которую над ними надо выполнить (+, -, *, /, SIN, COS, TAN, CTN, SQRT, POW), вывести результат. Добавить проверку на допустимые значения и сообщения на ввод недопустимых значений или неизвесного имени функции.

5 задание (математика): Ax^2 + Bx + C = 0. Ввести A, B, C, вывести корни уравнения.

6 задание (цикл): ввести 2 натуральных числа, вывести на экран все простые числа от первого до второго.

7 задание (строки): ввести строку с клавиатуры, подсчитать кол-во букв "а", заменить все буквы "в" на "ф", удалить все буквы "к", если рядом стоит 2 гласные или согласные буквы - поменять их местами. Вывести полученную строку на экран и кол-во найденных букв "а".
Ограничить длину строки размером от 5 до 30 символов.

8 задание (строки и рандом): вывести на экран строку размером 30 символов, состоящую только из 3-х гласных и 3-х согласных случайных маленьких русских или английских символов. Символы должны стоять так, чтобы не было двух гласных подряд и след. символ не совпадал с предыдущим.
При нажатии "пробел" 2 символа на месте курсора и справа от него - меняются местами. Если после этого рядом окажутся 2 гласные или согласные - они удаляются из строки. Курсор показывать как большую букву вместо маленькой, а перемещать нажатиями стрелок "влево" и "вправо". При достижении конца или начала строки - издавать звук.
При нажатии Return - начать заново.

9 задание (текстографика и логика): вывести поле из нулей размером 20x20, нули - белого цвета. Случайным образом разбросать по полю любые 16 цифр и 16 букв. Эти цифры и буквы не должны накладываться друг на друга (их всегда должно быть по 16 штук). Стрелками перемещаем символ !. При перемещении воскл. знака на цифру - он заменяется на "0" и воспроизводится звук, а при перемещении на букву - воспроизводится звук, выводится сообщение что мы проиграли, ждется нажатие любой кнопки игра начинается сначала. После собирания всех цифр игра сообщает что мы выиграли и воспроизводит звук.
После нажатия Return игра начинается сначала. Все звуки должны быть разные.
Цифры рисуются зеленым цветом, буквы - красным, а воскл. знак - синим.

Синус, косинус, тангенс, котангенс и корень квадратный от двух аргументов? Наркоман что ли?

При нажатии Return

Такой кнопки на клавиатуре уже лет 25 не существует.

Синус, косинус, тангенс, котангенс

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

В программировании используются готовые функции, как в математике. Пишешь что-то вроде y = sin(x); и все. Тебе не надо никакие ряды считать.

от двух аргументов?

Нет, вызывать 2 раза для каждой функции.

Такой кнопки не существует.

Есть, она подписана как Enter. А называется Return. Просто для дебилов написали что эта кнопка делает, чтобы было понятнее.
Точно также "пробел" никак не подписан, мне что, его как " " обозначать?

Нет, вызывать 2 раза для каждой функции.

Это из задания не читается. Ну допустим синус от 90 градусов и синус от 180. А тогда с операцией + получается что делать? 90+0 и 180+0? Задача плохо сформулирована, намешано всего в один список.

Есть, она подписана как Enter. А называется Return.

Я знаю что это Enter, я ещё застал старые клавиатуры. Но даёшь-то ты это задание в 2019 году? Именно поэтому я и говорю, что кнопки Return не существует на распространённых клавиатурах на текущий год.

Точно также "пробел" никак не подписан, мне что, его как " " обозначать?

А это ещё что за кнопка такая?

Всё верно, это нераспространённая клавиатура - где-то 5% в мире, если судить по статистике владельцев i-устройств против владельцев нормальных устройств, на которых удобно играть в игры, равно как и делать их.

Среди тех людей, которые знают, что такое carriage return (aka программисты), весьма распространённая. А как эта клавиша влияет на удобство игры вообще загадка: она в играх где-то используется вообще за пределами меню?

Речь была о компьютере - то что у тебя там Boot Camp, не превращает Ябло-Ось в PC Master Race Ось.

Я знаю что такое CR, и даже что такое LF, но это относилось к задаче АндрейМаста19 - что-то не думаю, что он обучает неофитов на новеньких устройствах им. Великого Стива Джобса.

При чём тут bootcamp?

Программисту не проблема запомнить, что enter это return, а визионеру эта кнопка вообще по барабану, потому не могу понять, чо ты прицепился к Эндрю.

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

Markertat где-то писал, что он собирается разрабатывать игру?

По-моему, все про клавишу поняли, кроме тебя. Вернее, ты тоже понял, но ещё и возмутился

Markertat где-то писал, что он собирается разрабатывать игру?

Единственное, что есть смысл разрабатывать - это прошивки микроконтроллеров.

Ну ты пост почитай сначала, потом будешь ёрничать

Ещё мне нравится, как ты предпочитаешь выборочно отвечать на вопросы, когда сам начинаешь утопать в собственных суждениях :-)

Есть вопросы, на которые и ответить-то нечего. Потому что я не знаю компьютера с Виндой, где эта клавиша называется Return, а Маки есть далеко-далеко не у всех.

Было два вопроса:

1) при чём тут буткамп

2) с каких пор клавиша энтер, как ты её не назови, стала основополагающей для удобства играющего

Второго я не утверждал, речь шла о том что у тебя Мак, но у 95% геймеров - не Мак.

А по первому - Бут Камп тут при том, что без него на Маке вообще играть почти не во что.

У меня примерно сотня игр в Стиме под Мак. Я не буду говорить, что ситуация идеальна: в некоторых поддержка макоси чисто для галочки, а основная проблема конечно с ретиной (в том числе, потому что визионеры не думают про hdpi-экраны в принципе), но играл я достаточно, чтобы посмеяться тебе в лицо.

В своём воображении смеяться можно сколько угодно и куда угодно. На Мак попадают только те игры, которые уже и так везде есть, причём бывает что Линукс-версия даже есть, а Мака всё ещё нет. У меня на Винде в Стиме 148 игр при том что я в них в общем-то даже и не играю (ну и где-то 15 из них я релизил сам, смешно). Только что эти цифры решают, непонятно - статистика, которую я приводил на Гамине много раз, остаётся неизменной:

https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam

Ну ок, конечно аноним из интернета лучше знает, во что я играю и на чём. Корона визионерская не жмёт?

Сложно жать объекту, который ты выдумал. Меньше Маков - меньше клавиш Return, и у большинства их нет. Простые факты. Что тут ещё рассуждать, непонятно.

я нелюблю всю математику в целом) так как у меня не математический склад ума,
но потом, через 10 лет после школы, пришлось самому учиться и понять,
что такое синус, косинус и ATan2,
то есть я до сих пор не понимаю эти вещи хорошо, но могу их использовать на практике,
лично для меня практика важнее каких-то теорий)
В общем:
1) синус и косинус я обычно применяю для кручения и качания каких-либо предметов: качели, волны, деревья на ветру, маятники и прочее.
2) а ATan2 - вроде это арктангенс, или нет xD, но мне без разницы если честно, что это в теории, но на практике помогает с поворотами пули или головы до цели)
Хоть не люблю это, но когда понадобилось практическое применение, то немного освоил ту область,
которая была важная при разработке подобных вещей в игре, а если что-то забываю то ищу документацию или примеры) Но в школе вообще не было мотивации даже хоть каплю начать понимать это, потому-что не видел никакого смысла кроме оценок и отчёта перед начальством родителями и учителями, потому-что учителя никогда не объясняли зачем это нужно.

учителя никогда не объясняли зачем это нужно.

Жизненно. Как и в ВУЗе по большей части.

Визионеру игровых механик косинусы не нужны

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

Моя фраза совершенно не противоречит тому, что ты написал.

А должна? Я просто добавляю свой личный исторический контекст, и развенчиваю миф что надо The Хорошо The Учиться. Надо хорошо делать своё дело, а не просто (или сложно, а иногда и вообще) учиться.

Зачем ты тогда отвечал на мой комментарий?

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

Отвечал, чтобы представить более полную картину. Не тебе отвечал, а вообще, всем. Я ж не в ЛС написал.

TAN, CTN, SQRT, POW

Какое практическое применения в играх есть у этих вещей?
Хочу узнать, вдруг пригодится когда-нибудь использовать.)
Просто я уже даже формулы в ролевых играх писал, и до сих пор мне это не особо пригодилось,
а точнее я просто мало что знаю об этим вещах. И чтобы что-то новое попытаться изучить,
мне нужно понять, нужно ли мне это в моей практике или это будет лежать мёртвой теорией в голове.
Ну котангенс и тангенс как-то связаны с углом, но особо пока мне это не пригодилось.

Если есть расстояние по X и Y, то арктангенс(Y/X) = углу на цель. А если есть расстояние до цели и угол, то расстояния по X=R*cos(alpha), Y=R*sin(alpha). Ну и прочая геометрия, например расчет упреждения при стрельбе или движения по окружности потребуют этих функций.

а, ну и учитывая коммент выше - TAN и CTN это просто синус делить на косинус и скорее всего не пригодится, SQRT - квадратный корень и нужен для решения квадратных уравнений и для R = SQRT(X*X+Y*Y), ну а POW - возведение в степень, в формулах для ролевок вполне можно использовать (когда нужен рост значения быстрее или медленнее линейного).

SQRT - квадратный корень и нужен для решения квадратных уравнений

То есть в общем-то не нужен. Часто приходится решать квадратные уравнения, когда делаешь свою игру? Это точно игра, а не движок движка для движка? Баланс ролёвок можно вообще в Экселе считать, у меня знакомый так делал. Правда то мир текстовых и IRL ролевых, а не видеоигр, но принцип-то один и тот же.

R = SQRT(X*X+Y*Y) по теореме Пифагора никто уже давно не считает, конкретно в Гамаке уже 15 лет как есть функция point_distance(x1, y1, x2, y2) которая делает это же, только ещё и более общего назначения - любые координаты подставляешь и сразу считает.

Math.Sqrt() пригодился мне только когда я делал Tekx, но в играх? Нет.

Скорее всего конкретно Алексу каждая такая функция пригодится примерно 1 (один) раз за всю разработку игры длиной в год-два.

> конкретно в Гамаке уже 15 лет как есть функция point_distance(x1, y1, x2, y2)

и более тормозная, ведь часто достаточно проверять квадрат дистанции (x*x+y*y), например для поиска ближайшего объекта или проверки что дистанция в диапазоне, и только потом взять из него корень. Но на фоне остального гамака да, скорее всего прирост производительности будет нулевым.

> Часто приходится решать квадратные уравнения, когда делаешь свою игру?

Нечасто, но в ИИ бывает такое. Вот в движках я не уверен что надо.

> Баланс ролёвок можно вообще в Экселе считать, у меня знакомый так делал.

При чем тут баланс? Я про формулы для ролевок. Если хочешь чтоб урон от силы рос не линейно а чуть быстрее или чуть медленнее (или не чуть) можно сделать dam = pow(str, 1.05) или dam = pow(str, 2.5).

> Скорее всего конкретно Алексу каждая такая функция пригодится примерно 1 (один) раз за всю разработку игры длиной в год-два.

А может и 0 раз. Конечно всё зависит от жанра игр. Я просто отвечал на вопрос "Какое практическое применения в играх есть у этих вещей?" а не пытался убедить изучить школьную программу.

можно сделать dam = pow(str, 1.05) или dam = pow(str, 2.5).

Спасибо! Надо потестить, может интересная вещь.

и более тормозная

А теперь представь себе: делаешь игру полтора года, проходишь ей Гринлайт, выпускаешь её в Стиме, ничего у тебя не тормозит, отзывы получаешь, зарабатываешь пару копеек, всем норм. Приходишь на Гамин, говоришь о своём опыте, а тебе - уууу, расстояние-то надо быстрее считать, а уж остальное-то там какое тормозное небось, ужас.

Это называется "предварительная оптимизация", и не может служить доводом при выборе языка и среды разработки, по крайней мере вне контекста конкретной игры. Сейчас начнётся - а я хочу 1000 объектов, между ними считать все расстояния это уже 10000000 вычислений. Да только не нужно это всё, если речь не о массово-мультиплеерной игре, где опять же мало где это нужно.

Нечасто, но в ИИ бывает такое.

В ИИ бывает нужно решение квадратных уравнений? Это ИИ для чего, точно для игры?

При чем тут баланс? Я про формулы для ролевок. Если хочешь чтоб урон от силы рос не линейно а чуть быстрее или чуть медленнее (или не чуть) можно сделать dam = pow(str, 1.05) или dam = pow(str, 2.5).

А, ну теперь понятно. Действительно, при чём тут баланс к формулам. Формулу ж написал раз - и работает.

Я просто отвечал на вопрос "Какое практическое применения в играх есть у этих вещей?"

Именно этот ответ я сейчас и разбираю с точки зрения инди-девелопера. Естественно за ААА и движки я расписываться не буду.

А только представь себе

Представил. Это никак не отменяет сказанного мной - в каких-то играх нафиг скорость не нужна, а на экране там три объекта, в каких-то - очень даже не помешает.

Это ИИ для чего, точно для игры?

Ну вот пилим Вормс, хотим определить под каким углом стрелять чтоб попасть в цель. Или пилим гонки, хотим узнать в какой момент жать поворот чтоб не проскочить мимо бонуса.

А, ну теперь понятно. Действительно, при чём тут баланс к формулам. Формулу ж написал раз - и работает.

Баланс несомненно связан с формулами, но тот факт что его можно считать в Экселе никак не противоречит тому что в игре в формулах может использоваться pow.

Именно этот ответ я сейчас и разбираю с точки зрения инди-девелопера.

Тогда я не понимаю какой тезис ты пытаешься оспорить. Если "эти функции нужны любому инди-игроделу", то я его и не защищаю. Кто-то вообще без программирования игры делает, разумеется ему не нужны. Если "эти функции нужны некоторым игроделам", то твои аргументы его не опровергают т.к. относятся к частным случаям. Мне то нужны, а я вполне считаю себя "тру" инди. А если "не нужны конкретно Алексу", то.... Может и не нужны, я его игр не играл. Но вопрос же не о применимости конкретно для него, а о применимости в играх.

в каких-то играх нафиг скорость не нужна, а на экране там три объекта

Ты в Андертейл играл? Пересчитай ещё раз, механика боёв там - буллет-хелл, объектов на экране бывает по 100-200.

Ну вот пилим Вормс, хотим определить под каким углом стрелять чтоб попасть в цель. Или пилим гонки, хотим узнать в какой момент жать поворот чтоб не проскочить мимо бонуса.

Это вот это что ли?

https://www.forrestthewoods.com/blog/solving_ballistic_trajectories/

И то, и другое, решается без использования корня.

Мне то нужны, а я вполне считаю себя "тру" инди.

Тру-индёвость не имеет отношения к наличию или отсутствию квадратных корней в коде игр.

100-200 спрайтов в 2KIXX это хоть сколько то значимая величина?

Ты в Андертейл играл? Пересчитай ещё раз, механика боёв там - буллет-хелл, объектов на экране бывает по 100-200.

А вот в дф крепость из ста гномов положат на лопатки даже топовый проц. У игр бывают разные по сложности алгоритмы и потому оценивать ее только по числу объектов на экране некорректно. Я просто привел крайний пример. А как другую крайность - ну, можно взять ту же Noita где "объектом" можно считать каждый пискель.

Это вот это что ли?

https://www.forrestthewoods.com/blog/solving_ballistic_trajectories/

Ты точно открывал ссылку? Там "We’ll be making heavy use of the quadratic formula" (про решение квадратного уравнения) и квадратный корень в еще двух примерах.

Тру-индёвость не имеет отношения к наличию или отсутствию квадратных корней в коде игр.

Да, поэтому я взял термин "тру" в кавычки. Для обоснования моего тезиса мне достаточно быть просто инди и использовать квадратный корень и возведение степень.

в дф крепость из ста гномов положат на лопатки даже топовый проц

Ну значит код так плохо написан. Где обоснование что их алгоритмы оптимизированы (и насчём с того - выбраны, как в случае с этими sqrt или не sqrt) достаточно хорошо?

Noita где "объектом" можно считать каждый пискель

Да вон Powder Toy есть, там их ещё больше. Всё упирается в то, как это реализуется.

Ты точно открывал ссылку? Там "We’ll be making heavy use of the quadratic formula" (про решение квадратного уравнения) и квадратный корень в еще двух примерах.

А ты точно дочитал, что там пишется? К середине статьи квадратные уравнения выкидываются, потому что не нужны. Специально для тебя и таких умников как ты, посидел пару часов за Гамаком, собрал прототип и снял видео:

Вот исходный код выяснения, куда стрелять: //Гит, а как индентацию сохранить, я не догнал. (13gpbdy)

Спасибо Гиту!

theta2=point_direction(x,y,target.x,target.y)+23

minimal_target_distance=999999
most_precise_theta=45

for (i=0; i<45; i+=1)
{
    projectile_x=x
    projectile_y=y

    dx=cos(degtorad(theta2))*fire_speed
    dy=sin(degtorad(theta2))*(-fire_speed)

    for (j=0; j<500; j+=1)
    {
        if instance_place(projectile_x,projectile_y,o_ground)==noone
        if instance_place(projectile_x,projectile_y,o_target)==noone
        {
            projectile_x+=dx
            projectile_y+=dy
            dy+=grav

            if projectile_x<0
            || projectile_x>room_width
            || projectile_y>room_height
            {
                projectile_x=999999
                projectile_y=999999
                break
            }
        }
        else
        {
            break
        }
    }

    target_distance = point_distance(projectile_x,projectile_y,target.x,target.y)
    if target_distance < minimal_target_distance
    {
        minimal_target_distance = target_distance
        most_precise_theta = theta2
    }

    theta2-=1
}
theta2 = most_precise_theta

Найди мне тут квадратный корень? Или возведение в степень? Нет, я знаю что он есть где-то внутри в point_distance, но речь о том что его не имеет смысла вызывать непосредственно через функцию sqrt(), так как это излишнее отвлечение от логики игры. Давайте ещё компьютер инструктировать философскими категориями добра и зла, будет долго и здорово, но неэффективно.

FPS в прототипе проседает по причинам, в реальной игре не имеющим значения:

  1. Я щедро расставляю маркеры каждой точки траектории от 0 до 500 штук на каждый градус от 1 до 45, итого 22500 маркеров может быть, и каждый из них отдельным инстансом. Именно для того чтоб не заниматься оптимизациями, которые не имеют значения для конечной игры по факту;
  2. Причина проседания номер два - я перемещаю объект стреляющего 60 раз в секунду, в реальном геймплее Вормс рассчитываются стационарные цели, один раз за ход;
  3. Наконец, тормозит (а ещё переполняет память) модификация пиксельного ландшафта через сёрфейс в спрайт с пресайз-коллизиями. Естественно, в релизе технология должна быть другая, но до коллизий с землёй мы ещё даже не дошли, речь шла о прицелах.

Кто вообще такой прототип делал, ладно на Гамаке, хоть на чём-то? У тебя есть эти самые Вормс, или это была просто фигура речи?

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

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

В версии с квадратным корнем приведенный тобой код заменился бы на

dx = target.x - x
dy = target.y - y
theta = arctan((speed*speed + sqrt(pow(speed, 4) - gravity*(gravity*dx*dx+2*speed*speed*dy)))/gravity*dx)

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

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

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

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

У твоего подхода есть неминуемые подводные камни:

  1. Моделировался баллистический выстрел по параболе, без учёта влияния ветра. Если нужно его учитывать, я просто буду добавлять dx+=lengthdir_x(wind_direction, wind_force) и то же самое с dy. Это будет работать не только для ветра по одной оси, как в Вормс, но для ветра в любом направлении, на любое количество пикселов за момент времени.

    Как же поменяется твоя формула при этом? А вот сначала понадобится решить систему аналогичную вот этой (всё из той же статьи), чтобы найти новое выражение тета-угла через всё остальное:



    Причём самое интересное будет, если нам известен закон изменения ветра во времени - в этом случае в формуле всегда будет оставаться функция, а значит тебе всё равно придётся её численно интегрировать.

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

    dx+=lengthdir_x(gravity_direction[x, y], gravity_force[x, y])
    (и так же для dy)

    Естественно, гравитацию или её отдельные участки в целях оптимизации можно хранить и не в двухмерных массивах. Я здесь говорю о том, что твоя парабола действует ровно для одного простейшего случая, который не особо геймплейно богат. В Вормс 2, которые я очень в своё время любил, выстрелы зачастую летят по параболе, как будто бы повёрнутой на угол, это уже на голову выше того что ты предлагаешь. А то, что предлагаю я, выше на две головы, просто все такие умные, всем надо C++ сначала прочитать в 10 томах, поорать "зато инде" и поучить меня делать то, что сами толком не делали.

    Все совпадения с реальными головами случайны.

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

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

Не, я буду рад ошибаться. Наверное есть какая-то супер-формула, которая в одну строку считает прям всё что я назвал - ветер, гравитацию, рикошеты. Только кто её способен получить? И обратно к главному, будет ли она в итоге быстрее работать.

Итак, подводные камни заключаются в том, что если ветер меняется во время полета а гравитация в отдельных местах отличается, то мне не получится посчитать одной простой формулой а придется интегрировать?

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

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

Итак, подводные камни заключаются в том, что если ветер меняется во время полета а гравитация в отдельных местах отличается, то мне не получится посчитать одной простой формулой а придется интегрировать?

Да, эта формула работает только для одного математически идеального случая. Причём я не а простреливании препятствий - об этом я как раз вообще не подумал, потому что обход препятствий это задача решаемая уровнем выше, чем алгоритм одного конкретного прицеливания. Решение квадратного уравнения даёт нам два корня - один для стрельбы навесом (сверху вниз), другой для стрельбы прямо по цели (по линии горизонта). Если один не подходит, можно выбрать другой. Если оба не подходят, надо перемещаться. Ну а простреливать - это простейший вариант.

Но что если нет, у меня в игре ветер константа на время выстрела и гравитация всегда постоянна?

Это значит что твоей игре ещё есть чему поучиться. Изначальный тезис-то ты доказал, что можно делать простейшие игры с корнем квадратным. Осталось задуматься, кому это нужно.

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

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

делаю скорее лиеро а не вормс

Лиеро? Удивил, я думал эту игру тут никто не помнит.

твоя как ты говоришь проседает

Я говорю? Ты видео посмотри внимательно, там FPS подписан. И учти, что 60 раз в секунду создавать по 22500 объектов в режиме дебага - это нагрузка, которой в релизе не будет. В релизе ИИ будет просто стрелять куда вычислил.

пусть я хочу определять не только угол, но и силу выстрела

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

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

Я про тебя и не говорил, все совпадения с головами ведь случайны.

Это значит что твоей игре ещё есть чему поучиться. Изначальный тезис-то ты доказал, что можно делать простейшие игры с корнем квадратным. Осталось задуматься, кому это нужно.

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

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

Но для проверки сотен значений скорости счет же пойдет на миллионы маркеров! [sarcasm]

Я про тебя и не говорил, все совпадения с головами ведь случайны.

Один-один, зачёт. XDDDDD

В целом я рад что ты умеешь признавать свою неправоту.

А что толку-то. Игры надо делать, а не вот это вот.

Но для проверки сотен значений скорости счет же пойдет на миллионы маркеров! [sarcasm]

Ну, твою игру-то мы ещё вообще в глаза не видели. Может там 10FPS даже когда прицел не считается. :yak:

🛑 В твоём комментарии обнаружена 1 кситоксическая ошибка.

Ну значит код так плохо написан, где обоснование что алгоритмы оптимизированы (и насчём с того - выбраны, как в случае с этими sqrt или не sqrt) достаточно хорошо?

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

Нужно больше хороших игр, а не проходняка на трёх струнах геометрии из средней школы.

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

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

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

Ты только что назвал Quake 3 нехорошей игрой?

Конечно, ровно так и написал.

#include <irony.h>;

А т.к. квадратный корень является частным случаем степени, то без него можно и обойтись. Если вдруг придется решить квадратное уравнение, всегда можно будет написать pow(x, 1/2)

Ну вот, совсем другое дело! Это уже реально полезно.

Блин, вы сейчас затронули такую тему, над которой я всегда задавался вопросом. Вот я сейчас в школе изучаю косинусы синусы и т.д. (ведь профиль нужно сдавать), для меня это сложная тема, поэтому не совсем понимаю, как это мне может пригодиться в программировании. Читая комментарии, я немного развеял свои вопросы, но все же некоторые остались. Например, обязательно это нужно в программировании, ведь можно же и без косинусов синусов обойтись? Или все же есть моменты, где без них никак в программировании?

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

Научиться учиться это действительно хороший навык. Здесь я даже не подкалываю. А синусы и косинусы нужны, повторюсь, как минимум чтобы заставлять одни объекты вращаться вокруг других. Просто в школе учат как их сокращать в уравнениях, и что будет если синус Пи на два в квадрате сложить с косинусом Пи на четыре. Это как раз так и было для меня загадкой, зачем в школе нужно.

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

Смотря, что ты программируешь. К.О.

Ну, например, при создании игры. Я еще ни разу не пользовался косинусами и синусами.

Просто создай игру где что-то крутится вокруг чего-то. И увидишь.

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

или движется волнообразно... у меня вода через синус слегка поднимается и опускается в Daring Do

вспомнил ещё одно применение, у меня фонари слегка затухают и потом увеличивают яркость
по синусу тоже


а точнее это просто спрайты, которые меняют прозрачность через синус

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

Поворот объекта относительно другого. Например, поворот родительского объекта вместе со всеми дочерними, с сохранением относительного смещения и ориентации.

вообще ничего не пригодится, ни один предмет даже профильный, кроме ОБЖ. но пригодится умение работать, учиться и выполнять таски. Освоение фреймворков посложнее синусов будет

https://natureofcode.com/book/chapter-3-oscillation/

Вот тригонометрия с околоигровыми примерами, как один из вариантов.

спасибо, тоже гляну) мало ли, вдруг я что-то ещё не использую, что могло бы упростить мне жизнь в программировании)

я вот так программирую движение по типу волн

t = t + 1 --t - это время
y = y + Sin(t)*5 --когда время изменяется, то благодаря синусу Y меняет позицию волнообразно


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

Написать комментарий