Этого мало, нужно стать доктором всяческих наук и стать профессионалом во всех областях, от гончарного дела до ракетной науки. Иначе, всё что ты будешь делать, будет фигнёй по умолчанию: ты ведь не учёл физику огонька с гончарной точки зрения.
… Вместо того чтобы изучать математику необходимую для понимания докуметнации
Ну чтоб прям в боевых нет. А в условиях промышленного производства так вертелся от запуска и до включения электропитания (сбои по питанию там иногда бывают. Примерно раз в 5 лет.).
Я всё понял, вы никогда не разрабатывали ничего сложного. Мелкие штуки очень легко натянуть на матмодель.
Советую заняться разработкой игр. Попробуйте, вдруг понравится. Заодно, расскажете о впечатлениях появления чего-то реального. И с наводящимися ракетами, и с углами видимости, и с процедурно генерируемым огнём, и со всем остальным. В вашей жизни не хватает практики, подавляет теоретизирование без ощутимого результата.
Почему это глупость? Где тут глупости? Обоснование есть? А что вы делаете, в случае если какая-то система ведёт себя не так как задокументировано? У вас бывали такие случаи? Вы когда-нибудь писали что-то, что потом работало в «боевых условиях»? А что вы делали когда это что-то вдруг переставало работать, особенно по неизвестным причинам, хотя математически всё верно?
Я как раз занимаюсь обучением в т.ч. школьников и студентов, в том числе математике, и в курсе о том, что кажется им самим собой разумеющимся, а что нет. По этой же причине, я так много пишу про бумажку. Как только школьник или студент начинает черкать происходящее, всё встаёт на свои места, и становится само собой разумеющимся, «наитие» начинает работать в нужную сторону, проверено практикой, над многими школьниками и многими студентами.
Будучи на втором курсе вуза, я отдельно самостоятельно перепроходил те же самые векторы (которые аккуратно пропустил в школе), прочитал всего-то несколько статей, включая ту что на хабре, для разминки написал и протестировал векторную библиотеку, и… Всё, я знаю векторы, умею их применять, и опа, игрушки получаются ничо так с математической точки зрения. И восьмиклассники, которые учатся у меня, читают те же статейки на том же самом хабре (или mathprofi, или ещё что-то), и нормально вкуривают в происходящее, даже если они этого ещё не проходили.
Потому что сама тема простая, это то, что изучается автоматически при практике. Ты не понимаешь векторы, ищешь материал и уже начинаешь понимать. Смотришь на чужой код, видишь то что там происходит и начинаешь понимать. Получать вышку чтобы изучить векторы не нужно, поиска информации достаточно.
Для написания простого двухмерного спейс-шутера «на фреймворке», более чем хватает простеньких векторов, на уровне сложения-вычитания скоростей, и вычисления длин по теореме Пифагора. Это всё. Больше ничего не нужно, это можно изучить за неделю практики. Неделю, особенно если восьмой класс уже пройден, и мы даже знаем тригонометрию.
Прочитайте мою публикацию по данной теме. Всё очень просто, никакой математики сложнее Пифагора. habr.com/ru/post/346136
И даже для отскоков шариков-кубиков, никакой высшей математики аналогично не нужно.
Для создания эффекта не нужно высчитывать, в какой точке на сумме текстур огонь получает такой-то цвет и с какой частотой. Это просто графический эффект, и им занимаются дизайнеры а не программисты, на глазочек и по опыту, смешивают текстурки и смотрят что получается. Вы выкатили пушку для стрельбы по воробушкам.
В играх это не нужно. Когда будете расчитывать конвекцию и температуру во всех областях пламени — будете выкатывать.
Смотрите. Довольно успешный скролл-шутер. Тут есть графика, и даже коллизия. youtu.be/9gAI1WJy9lo
Но где тут пропорциональные навигации, где тут системы «избежания столкновений»? И, как так получилось, что без всех этих достижений науки и техники, в эту игру всё ещё интересно играть большому количеству людей? А ведь тут ещё и уровни не случайно генерируемые, вообще ужас.
Вы опять взяли частный кейс, необходимый менее чем в одном проценте случаев, и начали его раскручивать.
Ну вот это для игры можно то и не делать.
В том-то и дело, что мы решаем, что можно делать, а чего можно не делать. Вы понимаете, что ваши кейсы настолько частные, что шанс на такое напороться мизерен?
Ох, вам сейчас ответит множество программистов, которые стали таковыми без окончания «прикладной математики и вычислительной техники». Я сам окончил матобеспечение и администрирование информационных систем, и прекрасно знаю, что из этого реально используется в играх, а что нет, и с какой частотой. И от ваших слов слышится лёгкий запах программистского снобизма, если в ваших условиях это так — пожалуйста, но не надо экстраполировать это на всех вокруг. Лишний раз напоминаю, что вы — всего лишь один человек, ваш опыт ограничен вашей жизнью, и в мире много всего такого, чего вы ещё не видели, например существуют Настоящие Программисты, не проходившие вузовский курс ТАУ, а то и вовсе без высшего образования, притом в их компетенции и способности реализовать разные сложные штуки не приходится сомневаться. Ссылаться на опыт друзей и коллег бесполезно, вы несознательно подобрали себе тот круг общения, который имеет схожий опыт, выборка нерепрезентативна.
У меня одногруппник всего-то лет пять назад писал курсовую про преследование ракетами в облёт препятствий и дружественных целей, а потом оно разрослось до дипломной работы, и там всё равно далеко не самые оптимальные решения, потому что предсказание возможных траекторий цели и дружественных объектов занимает слишком много вычислительного времени для ракетных мозгов.
Угол визирования — есть даже в статьях на хабре, вроде этой, это простейшие штуки которые изучаются автоматически, в процессе обучения кодингу.
Преследование? В 99% случаев достаточно обычного изменения угла поворота на цель. Можно постоянно нацеливаться, можно доворачивать угол. Это простая задача, сложное преследование как в боевых ракетах, в подавляющем числе случаев, не нужно и даже вредно, игроку от этих ракет ещё надо как-то уклоняться. Можно построить треугольник, продолжив вектор движения объекта, и примерно прикинуть где он будет через примерное время долёта, это легко делается в цикле, а если всё таки нужно прям крутое «преследование с перехватом», то можно найти методики и алгоритмы, хотя бы википедию. Вы многократно усложняете простые задачи, с игровой формы до «реальной».
Навигация — это отдельная тема, и без сложной навигации в подавляющем числе случаев можно обойтись, за исключением удержания курса на цель. А ещё можно руками натыкать навигационных точек, и ходить по ним, это вообще очень просто. Наша задача не написать ИИ, который будет уделывать игрока по всем фронтам, а написать ИИ который сможет красиво отдаваться, создавать неудобства и просто быть частью геймплея.
Не надо переусложнять. Тому кто собрался делать платформер или астероидс, это принесёт только лишнюю кашу в голову. Вы в очередной раз доказываете мне что-то, но у меня есть подозрение что вы сами не пробовали чего-то подобного, или у вас в голове засел страшный перфекционизм, который требует чтобы всё было математически точно, а всё что не предельно оптимально — отметается. Не надо так, мы же тут игры пишем, а не теоремы доказываем.
Разработчик игр — это не тот кто «готов ко всем на свете ситуациям», а тот кто может достаточно быстро научиться этому, если понадобилось.
Точно так же, программист — это не тот, кто уже умеет всё на свете, а тот, кто может достаточно быстро найти недостающую информацию и реализовать. Это тоже баланс, на этот раз — баланс знаний и потраченного времени. И судя по вашим словам, у вас огромный перекос, пользуясь вашими методиками, человек не то что ничего не закончит, но и не начнёт ни один проект, потому что у его голова уже до краёв заполнена алгоритмами и теорией, этого всё равно недостаточно (потому что постоянно выходит что-то новое), а ему уже сто лет и пора идти в гроб. А он всего-то хотел кликер написать :)
Простите пожалуйста, расстояния не посчитать? vdist = (v2 — v1), и теорема Пифагора на получившийся вектор. Это всё есть в учебнике за восьмой класс, и в типичной статье «математика для разработчиков игр», которую начинающий разработчик загуглит одной из первых.
Взаимное расположение? Так же легко, берётся бумажка, на ней координаты объектов, вычитаем координаты положения/центра по одной из осей и смотрим, где циферка получилась больше. Очень наглядно и выводится «по наитию» и переводится в код. Для этого не нужна ни высшая математика, ни законченное среднее образование, только арифметика, чуть-чуть логики и воображения.
Где на самом деле может пригодиться именно высшая математика, так это, например, в построении математической гравитационной модели солнечной системы, там простенькое дифференцирование (простое смещение объектов «каждый кадр» недостаточно точное и несёт критичное накопление ошибок). Или в волновом анализе: мы хотим сделать визуализатор/ритм-игру которая адаптируется под трек, который в данный момент играет, тут уже всякие beat-detect'ы и fft.
Только вот ведь незадача: в простом платформере это не нужно. И в сложном, зачастую, тоже. Для совсем сложного платформера может понадобиться continious-collision, это уже сложнее чем AABB, но далеко не высшая математика. Мы не строим самолёт или прибор, от которого зависят жизни, нам достаточно сильно упрощённых моделей, которые могут подглюкивать в граничных случаях, но в основном ведут себя хорошо. При управлении станком с множеством степеней свободы, нам может понадобиться разбираться в многомерных пространствах, где вектор положения в пространстве состоит не из двух-трёх компонентов, а из пятнадцати, например. Но это не станок, если начинающий разработчик начнёт строить станки, ему разумеется придётся углубляться.
Ну, а если интерес заканчивается после запроса «как создать ААА-игру», то у нас, увы, клинический случай. А вам могу посоветовать не проецировать свой негативный опыт на всех окружающих, окружающие — разные, «клинические» просто самые громкие и заметные, так что может показаться, будто из них состоит весь мир.
При изучении математики через написание игрушек, есть одна маленькая фича: ты видишь что ты считаешь не так. Банальным научным тыком, легко вывести всё что необходимо, поправить (пусть даже десять раз), и всё таки написать более-менее правильно. Векторная алгебра изучается сама собой, наитием или чтением статей, плюс в статье я описал основные разделы математики, на которые стоит посмотреть.
Другое дело что начинать с этого — не нужно, этим нужно продолжать, но начинать не стоит, если нет любви к математике.
Брать деньги на этапе обучения — это подвергание риску заказчика, можно легко напороться на скандал/потерю репутации по причине срыва сроков, или того что навыков под задачу внезапно не хватает. А проблема «актуальных инструментов» в том, что на рынке сейчас востребованы те инструменты, которые позволяют «быстро-быстро наполнять игрушку контентом, пока солнце ещё высоко», то есть движки. Но движки могут оказаться очень вредными для обучения, потому что они затягивают в свою экосистему, и, самое плохое — они не дают нормальных навыков программирования: человек после них может только заполнять обработчики, но не может самостоятельно сделать систему обработчиков. А умея делать системы обработчиков, можно смело пользоваться движками, потому что если вдруг вылезет что-то непонятное и недокументированное — навыков чтобы в этом разобраться уже достаточно.
Во фреймворках или движках без прямого управления OpenGL/DirectX, нет никакой сложной математики. Для простого платформера не нужно ничего сложнее AABB-коллизии, для которой достаточно математики уровня восьмого класса, и небольшого рисования на бумажке. Под что-то не очень сложное, математику довольно просто натянуть по ходу дела, а под змейки и тетрисы математика и вовсе не нужна. Ваше предложение это замечательный способ потерять всякий интерес к области. Впрочем, если есть прям любовь к математике, то можно начать и с неё, разумеется.
Под линукс — есть инструкции на официальной вики, в основном — AppImages.
С хтмл очень сложно, есть Emscripten, но лично у меня так и не получилось его нормально завести, плюс если есть какие-то ffi-расширения — с ними всё очень плохо, браузер плохо предназначен для запуска нативных приложений. И такие проблемы не только у Love2d, но и у короны, у дефолда и практически у каждого движка/фреймворка. Юнити-плагин вон тоже теперь запрещён в браузерах.
Я работаю не в IPONWEB, но тоже пишу на луа в команде довольно приличные штуки, и в случае коллектива до 50 человек, вполне хватает гита. Есть протокол общения между подсистемами, есть модули верификации, мол «входные данные и выходные соответствуют стандарту», поэтому если кто-то от кого-то зависит — пока всё соответствует протоколу, оно будет нормально работать. А если зависимость именно от данных, то тут уже, как правило, договариваемся с человеком, занимающимся разработкой и поддержкой соседней подсистемы, мол «данные изменились, адаптируем», далее стыкуем обе части (опционально в git-flow фиче) и тестируем. Если обе части под твоей юрисдикцией, то всё проще: сам стыкуешь и тестируешь.
Отдельные модули сервисов или систем, как правило, являются наследниками абстрактного «класса сервиса», которые запускаются в таск-менеджере, который оперирует именно такими классами, соответственно для миграции модуля/сервиса обычно достаточно перенести класс и всю его вспомогательную требуху на другой кластер, и запустить, опционально указав в глобальной системной конфигурации, мол «а у нас вот тут появился новый сервис, и к нему можно обращаться по таким-то вопросам».
В общем-то ничем не отличается от разработки произвольной распределённой системы, всё примерно то же самое.
Да, возможна, OpenResty в помощь. Фреймворков не очень много, но есть, например Lapis (он на мунскрипте, это как тайпскрипт для жаваскрипта, только транслируется в луа перед исполнением), можно писать веб-часть на луа или мунскрипте на выбор, шаблонизаторы с драйверами до бд присутствуют.
Лично я предпочитаю катать полностью самописные велосипеды на OpenResty, но это уже мой персональный выбор для пет-проектов.
Удобство — понятие относительное. Луа изначально придумывалась как встраиваемый язык, поэтому делать любые сишные/плюсовые биндинги оказывается проще чем (почти) в чём угодно. Интеграция с уже существующей системой производится малой кровью, вплоть до выгрузки плюсовых объектов и использование их со скриптовой стороны практически аналогично плюсам. Такой глубины интеграции нет практически нигде. А инструментарий для бизнес-логики — или уже существует, или пишется за обозримые сроки. Ну и очень лёгкие корутины, приятный синтаксис (спорно, да) и всё такое. Скорость работы, для динамического языка (да ещё и с ffi/luajit) — очень хорошая, и не так много абстракций, чтобы они сильно протекали на разных платформах. Тут совокупность плюшек, а не какая-то конкретная киллер-фича.
Я всё понял, вы никогда не разрабатывали ничего сложного. Мелкие штуки очень легко натянуть на матмодель.
Советую заняться разработкой игр. Попробуйте, вдруг понравится. Заодно, расскажете о впечатлениях появления чего-то реального. И с наводящимися ракетами, и с углами видимости, и с процедурно генерируемым огнём, и со всем остальным. В вашей жизни не хватает практики, подавляет теоретизирование без ощутимого результата.
Будучи на втором курсе вуза, я отдельно самостоятельно перепроходил те же самые векторы (которые аккуратно пропустил в школе), прочитал всего-то несколько статей, включая ту что на хабре, для разминки написал и протестировал векторную библиотеку, и… Всё, я знаю векторы, умею их применять, и опа, игрушки получаются ничо так с математической точки зрения. И восьмиклассники, которые учатся у меня, читают те же статейки на том же самом хабре (или mathprofi, или ещё что-то), и нормально вкуривают в происходящее, даже если они этого ещё не проходили.
Потому что сама тема простая, это то, что изучается автоматически при практике. Ты не понимаешь векторы, ищешь материал и уже начинаешь понимать. Смотришь на чужой код, видишь то что там происходит и начинаешь понимать. Получать вышку чтобы изучить векторы не нужно, поиска информации достаточно.
Для написания простого двухмерного спейс-шутера «на фреймворке», более чем хватает простеньких векторов, на уровне сложения-вычитания скоростей, и вычисления длин по теореме Пифагора. Это всё. Больше ничего не нужно, это можно изучить за неделю практики. Неделю, особенно если восьмой класс уже пройден, и мы даже знаем тригонометрию.
Прочитайте мою публикацию по данной теме. Всё очень просто, никакой математики сложнее Пифагора.
habr.com/ru/post/346136
И даже для отскоков шариков-кубиков, никакой высшей математики аналогично не нужно.
В играх это не нужно. Когда будете расчитывать конвекцию и температуру во всех областях пламени — будете выкатывать.
youtu.be/9gAI1WJy9lo
Но где тут пропорциональные навигации, где тут системы «избежания столкновений»? И, как так получилось, что без всех этих достижений науки и техники, в эту игру всё ещё интересно играть большому количеству людей? А ведь тут ещё и уровни не случайно генерируемые, вообще ужас.
Вы опять взяли частный кейс, необходимый менее чем в одном проценте случаев, и начали его раскручивать.
В том-то и дело, что мы решаем, что можно делать, а чего можно не делать. Вы понимаете, что ваши кейсы настолько частные, что шанс на такое напороться мизерен?
Спасибо, я уже всё понял, можете не продолжать :)
Преследование? В 99% случаев достаточно обычного изменения угла поворота на цель. Можно постоянно нацеливаться, можно доворачивать угол. Это простая задача, сложное преследование как в боевых ракетах, в подавляющем числе случаев, не нужно и даже вредно, игроку от этих ракет ещё надо как-то уклоняться. Можно построить треугольник, продолжив вектор движения объекта, и примерно прикинуть где он будет через примерное время долёта, это легко делается в цикле, а если всё таки нужно прям крутое «преследование с перехватом», то можно найти методики и алгоритмы, хотя бы википедию. Вы многократно усложняете простые задачи, с игровой формы до «реальной».
Навигация — это отдельная тема, и без сложной навигации в подавляющем числе случаев можно обойтись, за исключением удержания курса на цель. А ещё можно руками натыкать навигационных точек, и ходить по ним, это вообще очень просто. Наша задача не написать ИИ, который будет уделывать игрока по всем фронтам, а написать ИИ который сможет красиво отдаваться, создавать неудобства и просто быть частью геймплея.
Не надо переусложнять. Тому кто собрался делать платформер или астероидс, это принесёт только лишнюю кашу в голову. Вы в очередной раз доказываете мне что-то, но у меня есть подозрение что вы сами не пробовали чего-то подобного, или у вас в голове засел страшный перфекционизм, который требует чтобы всё было математически точно, а всё что не предельно оптимально — отметается. Не надо так, мы же тут игры пишем, а не теоремы доказываем.
Разработчик игр — это не тот кто «готов ко всем на свете ситуациям», а тот кто может достаточно быстро научиться этому, если понадобилось.
Точно так же, программист — это не тот, кто уже умеет всё на свете, а тот, кто может достаточно быстро найти недостающую информацию и реализовать. Это тоже баланс, на этот раз — баланс знаний и потраченного времени. И судя по вашим словам, у вас огромный перекос, пользуясь вашими методиками, человек не то что ничего не закончит, но и не начнёт ни один проект, потому что у его голова уже до краёв заполнена алгоритмами и теорией, этого всё равно недостаточно (потому что постоянно выходит что-то новое), а ему уже сто лет и пора идти в гроб. А он всего-то хотел кликер написать :)
Взаимное расположение? Так же легко, берётся бумажка, на ней координаты объектов, вычитаем координаты положения/центра по одной из осей и смотрим, где циферка получилась больше. Очень наглядно и выводится «по наитию» и переводится в код. Для этого не нужна ни высшая математика, ни законченное среднее образование, только арифметика, чуть-чуть логики и воображения.
Где на самом деле может пригодиться именно высшая математика, так это, например, в построении математической гравитационной модели солнечной системы, там простенькое дифференцирование (простое смещение объектов «каждый кадр» недостаточно точное и несёт критичное накопление ошибок). Или в волновом анализе: мы хотим сделать визуализатор/ритм-игру которая адаптируется под трек, который в данный момент играет, тут уже всякие beat-detect'ы и fft.
Только вот ведь незадача: в простом платформере это не нужно. И в сложном, зачастую, тоже. Для совсем сложного платформера может понадобиться continious-collision, это уже сложнее чем AABB, но далеко не высшая математика. Мы не строим самолёт или прибор, от которого зависят жизни, нам достаточно сильно упрощённых моделей, которые могут подглюкивать в граничных случаях, но в основном ведут себя хорошо. При управлении станком с множеством степеней свободы, нам может понадобиться разбираться в многомерных пространствах, где вектор положения в пространстве состоит не из двух-трёх компонентов, а из пятнадцати, например. Но это не станок, если начинающий разработчик начнёт строить станки, ему разумеется придётся углубляться.
Ну, а если интерес заканчивается после запроса «как создать ААА-игру», то у нас, увы, клинический случай. А вам могу посоветовать не проецировать свой негативный опыт на всех окружающих, окружающие — разные, «клинические» просто самые громкие и заметные, так что может показаться, будто из них состоит весь мир.
Другое дело что начинать с этого — не нужно, этим нужно продолжать, но начинать не стоит, если нет любви к математике.
С хтмл очень сложно, есть Emscripten, но лично у меня так и не получилось его нормально завести, плюс если есть какие-то ffi-расширения — с ними всё очень плохо, браузер плохо предназначен для запуска нативных приложений. И такие проблемы не только у Love2d, но и у короны, у дефолда и практически у каждого движка/фреймворка. Юнити-плагин вон тоже теперь запрещён в браузерах.
Отдельные модули сервисов или систем, как правило, являются наследниками абстрактного «класса сервиса», которые запускаются в таск-менеджере, который оперирует именно такими классами, соответственно для миграции модуля/сервиса обычно достаточно перенести класс и всю его вспомогательную требуху на другой кластер, и запустить, опционально указав в глобальной системной конфигурации, мол «а у нас вот тут появился новый сервис, и к нему можно обращаться по таким-то вопросам».
В общем-то ничем не отличается от разработки произвольной распределённой системы, всё примерно то же самое.
Лично я предпочитаю катать полностью самописные велосипеды на OpenResty, но это уже мой персональный выбор для пет-проектов.