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

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

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

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

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

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

Давай, пробуй программировать уже.
Возьми ту же 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 для нужных вещей в игре

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