Эх, сколько я уже проектов в стол похоронил… Тоже хочется сразу и многого, а мотивации не хватает, что бы сделать с таким-то замахом, более менее приятный прототип. А потом интерес угасает, и здравствуй новый проект.
Надеюсь что вам хватит мотивации. ИМХО мотивация это главное, а знания приложатся.
Лишь бы как у меня — хотелки не росли быстрее этих самых знаний.
Просто для меня это была вообще первой игрушкой такого рода, где из деталей можно делать шушпанзеры. Вот и написал сразу, в общий список так сказать. Там мододелы много в свое время понаделали + все подряд из валвоских игрушек было.
А насчет деталей, я сам даже не знаю щас, я в нее лет 8 назад наверное заходил.
Garry's Mod + wiremod жеж… Это для меня была первая игра подобного типа.
Это если что отдельная игра на движке HL2. Но если гуглить то на первых местах будут сценки, а не постройки, но там много чего можно на самом деле.
Я программируемые ракеты делал с wiremod'ом.
И всякая балансировка тяги на аналоговых датчиках была не легка.
Не помню где писали, но помню что большей частью если не все делается чисто математически.
Но это вроде по комментариям и вакансиям, а подробностей они не раскрывали вроде.
В Еве (на тот момент когда я в нее играл) разница была не так сильна. Да присутствуют и заводы пароходы торговля, но игроки все равно завязаны на клона. И в обратную сторону тоже. Так как бои в Еве достаточно аркадные.
Я имел ввиду скорее:
4X с конструктором с одной стороны.
И буквально тактический шутер с другой.
Хотел сделать что-то вроде gratuitous space battles/wayward terrain conflict/crank + heat signature. Но последние время загорелся 3d, что не пошло на пользу, ибо сложность повысилась. (И конечно же я хочу все это в браузере, и конечно же на своем особом движе :[… невнятное бурчание )
Эхх, сам нечто подобное хотел, только с большим уклоном в персональное участие игрока. (Типа кому-то интересно строить, а кому-то летать, так почему бы не объединить эти две игры на одном поле? В том смысле что кто-то играет в построй корабль, а кто-то в грабить караваны, как вариант даже с двумя отдельными клиентами. Ведь это две достаточно разные категории людей, и обоим было бы интереснее если бы не интересную для них часть выполняли тоже люди, а не тупые боты...)
Но сам до сих пор так ничего путного не сделал.
Здравствуйте, снова заинтересовался клеточными автоматами после вашей статьи.
Скажите, а для подготовки всего что выложили, вы реально использовали JS, или у вас есть аппаратно ускоренная реализация?
Я ночью накидал на webGL на компьютере с GT640 реализацию чисто воспроизведения, причем с шейдером в лоб, даже без оптимизаций после 199x199 пробегало 100 поколений за 8ms (отображал только результат прогона ста поколений, остальное работало циклически во фрэйм-буфере и получал 30-50fps).
Upd: GTX1060, 800x800, 1000 поколений во фрэйм-буфере, и рендер каждого последнего = 20fps (для не оптимизированного правила 3x3x2).
При такой скорости можно замахнуться и на 3x3x2 = 2^18 = 512x512 пикселей картинки в качестве правила. Правда, самое интересное, генетику я еще не реализовал.
Вообще, если кому-то интересно поиграться с результатом то пишите, и если я доведу это до нормального вида, могу выложить(риск крови из глаз) на какой нибудь codesandbox для удобства модификации.
Насколько я понимаю, TS не работает с отдельными частями интерфейса, а лишь "дискриминирует" состояние целиком. (Изначально union это как бы квантовое состояние, которое коллапсирует с каждым новым ограничением, но лишь целиком, пока не остается статический тип)
Таким образом, сделать это можно юнионом как в примерах, но это приводит к комбинаторному взрыву состояний… (у IDE обычно ограничения глубины для комфорта работы, а компиляция просто будет все дольше и дольше)
И того нам остается:
Использовать под интерфейсы. Меняя структуру данных.
Делать юнионы, при разумных количествах комбинаций.
Начал писать с такой же логикой, закончил когда понял насколько это усложняет решение, и что в реальных кейсах (с интервалами допустим в пределах года), мы получаем увеличение O сложности в 1-4 раза по сравнению с оптимизированным, за счет сильного увеличения сложности алгоритма и ухудшения читаемости.
А практической необходимости такой оптимизации и вовсе придумать не смог.
Сложность оценивал как O(periods * holidays + periods + periods * holidays_overrides) для оптимального, и O(periods * (holidays + periods_weekdays - holidays_overrides)) для решения с генерацией всех выходных. Исходя из того что нам нужно обрабатывать много периодов, но не столетия с кучей выходных.
От системы зависит, но в бюджетном варианте у многих раньше прокатывала блокировка через iptables. Пример https://habr.com/ru/post/335436/ (редактировал, ссылкой промазал)
Сам в январе захотел сделать что-то подобное, но в случае с трассировкой, производительность слишком сильно зависит от разрешения.
В итоге за ночь накидал 2d ячейки с трассировкой видимости ячеек(лучи до клеток периметра максимального обзора от краев клетки где стоит игрок на 90 градусов в обе стороны, дают полный обзор без провалов по ячейкам), и отрисовкой видимых ячеек(карта в виде Uint8Array(cols*rows)) пола/потолка и стен.
Это решение показало себя очень хорошо даже на компьютере 10+ летней давности. На картах размерами 4096x4096 ячеек, с текстурами 128x128 и дальностью трассировки 20 блоков.
По итогу скажу что это самая простая часть "игры".
Правда я для рендера использовал webgl, с библиотекой regl (удобная stateless обертка).
Считаю webgl очень удобным для такого рода вещей, так как позволяет легко скинуть друзьям. (И уговорить потестить твою игру куда проще когда человеку не нужно ничего ставить)
Не работал с юнити, но рискну предположить, что nav mesh в оригинальном смысле используется для получения следущей точки навигации, а движение к ней происходит примерно так как описано в статье. (Сам не читал подобного статье, и для себя рассматривал все эти операции в другом ключе, что в прочем не меняло их сути)
© opennet
Для клиентов с centos
Эх, сколько я уже проектов в стол похоронил… Тоже хочется сразу и многого, а мотивации не хватает, что бы сделать с таким-то замахом, более менее приятный прототип. А потом интерес угасает, и здравствуй новый проект.
Надеюсь что вам хватит мотивации. ИМХО мотивация это главное, а знания приложатся.
Лишь бы как у меня — хотелки не росли быстрее этих самых знаний.
Роскомнадзор...
Просто для меня это была вообще первой игрушкой такого рода, где из деталей можно делать шушпанзеры. Вот и написал сразу, в общий список так сказать. Там мододелы много в свое время понаделали + все подряд из валвоских игрушек было.
А насчет деталей, я сам даже не знаю щас, я в нее лет 8 назад наверное заходил.
Garry's Mod + wiremod жеж… Это для меня была первая игра подобного типа.
Это если что отдельная игра на движке HL2. Но если гуглить то на первых местах будут сценки, а не постройки, но там много чего можно на самом деле.
Я программируемые ракеты делал с wiremod'ом.
И всякая балансировка тяги на аналоговых датчиках была не легка.
В таком ключе переменный ток не имеет смысла, а лишь дает повышенную сложность и опасность для оборудования.
Не помню где писали, но помню что большей частью если не все делается чисто математически.
Но это вроде по комментариям и вакансиям, а подробностей они не раскрывали вроде.
Для себя в итоге решил, что VPS выходит проще/дешевле/управляемие для экспериментов.
В Еве (на тот момент когда я в нее играл) разница была не так сильна. Да присутствуют и заводы пароходы торговля, но игроки все равно завязаны на клона. И в обратную сторону тоже. Так как бои в Еве достаточно аркадные.
Я имел ввиду скорее:
4X с конструктором с одной стороны.
И буквально тактический шутер с другой.
Хотел сделать что-то вроде gratuitous space battles/wayward terrain conflict/crank + heat signature. Но последние время загорелся 3d, что не пошло на пользу, ибо сложность повысилась. (И конечно же я хочу все это в браузере, и конечно же на своем особом движе :[… невнятное бурчание )
Эхх, сам нечто подобное хотел, только с большим уклоном в персональное участие игрока. (Типа кому-то интересно строить, а кому-то летать, так почему бы не объединить эти две игры на одном поле? В том смысле что кто-то играет в построй корабль, а кто-то в грабить караваны, как вариант даже с двумя отдельными клиентами. Ведь это две достаточно разные категории людей, и обоим было бы интереснее если бы не интересную для них часть выполняли тоже люди, а не тупые боты...)
Но сам до сих пор так ничего путного не сделал.
Желаю удачи! И надеюсь что у вас получится!
Вот пример этой операции из исходников gl-matrix
http://glmatrix.net/docs/vec4.js.html#line478
Т.е. за счет нижнего ряда все w умножаются на 0, кроме последнего компонента.
Для проверки себя, просто умножьте на единичную матрицу, и увидите что все компоненты остаются на своих местах.
Т.е. вы её похоже транспонировали. Строки со столбцами перепутали.
Здравствуйте, снова заинтересовался клеточными автоматами после вашей статьи.
Скажите, а для подготовки всего что выложили, вы реально использовали JS, или у вас есть аппаратно ускоренная реализация?
Я ночью накидал на webGL на компьютере с GT640 реализацию чисто воспроизведения, причем с шейдером в лоб, даже без оптимизаций после 199x199 пробегало 100 поколений за 8ms (отображал только результат прогона ста поколений, остальное работало циклически во фрэйм-буфере и получал 30-50fps).
Upd: GTX1060, 800x800, 1000 поколений во фрэйм-буфере, и рендер каждого последнего = 20fps (для не оптимизированного правила 3x3x2).
При такой скорости можно замахнуться и на 3x3x2 = 2^18 = 512x512 пикселей картинки в качестве правила. Правда, самое интересное, генетику я еще не реализовал.
Вообще, если кому-то интересно поиграться с результатом то пишите, и если я доведу это до нормального вида, могу выложить(риск крови из глаз) на какой нибудь codesandbox для удобства модификации.
Я не автор, но попробую ответить.
Насколько я понимаю, TS не работает с отдельными частями интерфейса, а лишь "дискриминирует" состояние целиком. (Изначально union это как бы квантовое состояние, которое коллапсирует с каждым новым ограничением, но лишь целиком, пока не остается статический тип)
Таким образом, сделать это можно юнионом как в примерах, но это приводит к комбинаторному взрыву состояний… (у IDE обычно ограничения глубины для комфорта работы, а компиляция просто будет все дольше и дольше)
И того нам остается:
Начал писать с такой же логикой, закончил когда понял насколько это усложняет решение, и что в реальных кейсах (с интервалами допустим в пределах года), мы получаем увеличение O сложности в 1-4 раза по сравнению с оптимизированным, за счет сильного увеличения сложности алгоритма и ухудшения читаемости.
А практической необходимости такой оптимизации и вовсе придумать не смог.
Сложность оценивал как
O(periods * holidays + periods + periods * holidays_overrides)для оптимального, иO(periods * (holidays + periods_weekdays - holidays_overrides))для решения с генерацией всех выходных. Исходя из того что нам нужно обрабатывать много периодов, но не столетия с кучей выходных.Предполагаю что речь об этом, но насчет не смогли ли, не уверен.
Сам не использовал, а по картинкам, вроде бы ничего революционного.
От системы зависит, но в бюджетном варианте у многих раньше прокатывала блокировка через iptables. Пример https://habr.com/ru/post/335436/ (редактировал, ссылкой промазал)
Сам в январе захотел сделать что-то подобное, но в случае с трассировкой, производительность слишком сильно зависит от разрешения.
В итоге за ночь накидал 2d ячейки с трассировкой видимости ячеек(лучи до клеток периметра максимального обзора от краев клетки где стоит игрок на 90 градусов в обе стороны, дают полный обзор без провалов по ячейкам), и отрисовкой видимых ячеек(карта в виде Uint8Array(cols*rows)) пола/потолка и стен.
Это решение показало себя очень хорошо даже на компьютере 10+ летней давности. На картах размерами 4096x4096 ячеек, с текстурами 128x128 и дальностью трассировки 20 блоков.
По итогу скажу что это самая простая часть "игры".
Правда я для рендера использовал webgl, с библиотекой regl (удобная stateless обертка).
Считаю webgl очень удобным для такого рода вещей, так как позволяет легко скинуть друзьям. (И уговорить потестить твою игру куда проще когда человеку не нужно ничего ставить)
Вроде это была Elite Dangerous, а не ева и там боты таки читерили…
https://habr.com/post/394895/
1n << 1000000nвот настоящий огонь (консоль виснет).Не работал с юнити, но рискну предположить, что nav mesh в оригинальном смысле используется для получения следущей точки навигации, а движение к ней происходит примерно так как описано в статье. (Сам не читал подобного статье, и для себя рассматривал все эти операции в другом ключе, что в прочем не меняло их сути)