Еслии не секрет - в чем фича?

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

ну то есть профит можно было бы получить на проектах где группа людей работает интенсивно в краткий период времени с одними и теми же данными

и где логика какая-то присутствует.

но если мне даведется такие проекты делать - я лучше просто не буду писать это на php)

а возьму какой элексир хотя бы

Хейтер )))

а акторы по отдельности компилируются?

если их можно заменит?

это вы имели ввиду под отдельными комьпьютерами?

зависит от имплементации, но идея в отсутствии main рутины, точки входа в программу, есть просто сеть экторов. В erlang ты можешь поднимать новые треды в рантайме - в akka + scala вроде как нет

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

а все остальные варианты будут обладать ограничениями тех языков на которых ты систему пилишь (либо будет медленно из-за IPC)

если тебе не нужно поддерживать аптайм системы близкой к 100%, или ты будешь разруливать вопрос обновления кода своими силами (как все сейчас делают с контейнерами и кубернетисами), если тебя интересует только модель конкурентности поудобнее чем треды - то экторы можно реализовать на чем хочешь

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

так, а как скинуть то

так, а как скинуть то

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

а то тут затеряется ведь

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

я не буду обсуждать, это на несколько дней растянется, у меня есть другие дела)

я просто это оставлю тут

потому что что бы на 100% точно это описать, надо кучу усилий, которые нет смысла на это тратить

ну хоть так давай)

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

Для выстрела надо: ( ИМЕННО ДЛЯ ОГНЕСТРЕЛЬНОГО ОРУЖИЯ, у оружия ближнего боя другие параметры, типа угол размаха, растояние на каком достает, соответственно без полета пули но с траекторией размаха) Вектор в котором происходит выстрел конец дула(грубоговоря) Текущий разброс от поворота при смене направления прицеливания (если целишься в одну сторону - плавно снижается) Текущий разброс от бега (Если не бегишь то постепенно снижается) Множитель для конкретной пушки для разброса поворота (не оптимально каждый тик умножать это высчитывая разброс при повороте, поэтому домножается только при выстреле) Для бега так же множетель Дальше кидается кубик что бы понять в каком направлении полетит пуля Когда пуля встречает какую-то преграду идет просчет попала она в неё или нет на основе высоты преграды и диапазона высот в которых летит пуля(то есть у нас четко определено направление пули только в горизонтальных осях, то есть если с верху смотреть, вертикальное положение во время нахождения пули в области преграды расчитывается) Если рандом выкидывает что пуля выше преграды, то нижний предел диапазона пересчитывается на основании преодоленной преграды и дальше все повторяется. Если пуля все же достигает какого-нибудь другого игрока или моба, то дальше в ход идет расчет урона и шанса попадания именно рпгшного для этого нам надо: Растояние которое прошла пуля, что бы снизить урон если далеко жертва Шанс жертвы что в неё сложнее попасть, то есть типа уворота. Величина у атакующего которая снижает шанс жертвы что по ней не попадут Урон конкретного типа Шанс поглощения какого-то количества данного урона жертвой Величина поглощения при поглощении Шанс атакующего пробить поглощение Криты там всякие ну это понятно, но может понадобиться добавить уменьшение урона жертвой именно от крита как в ВОВе ресайленс Применение какого-то эффекта при нанесении урона (поломка костей - пока не реализовано, оглушение, кровотечение (пока не реализовано)) Запись информации о попадании в фиговину для локации, что бы в конце тика всем разослать инфу о попаданиях Сразу скажу на счет подписок: локация на персонажа не должна подписываться, иначе это будет трешак, персонаж тоже на локацию не подписывается, на локации может быть много кого, и будет генериться не нужный мусор когда игроки будут входить и выходить с локации и весь список делегата будет заново формироваться, это же сервак И это только выстрел, может я что-то упустил, ну примерно так, ну а теперь интересно посмотреть кто бы как это реализовал))))

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

смотри, предположим у тебя есть исходники программы. Ты скомпилил ее и запустил. Теперь ты скомпилил измененные исходники и запустил но не потушил старую программу. И так несколько раз. У тебя будет исходник программы и запущено N экземпляров этой же программы каждый новой ревизии. Я это к тому что это организационные проблемы нежели проблемы рантайма. Он тебе просто позволяет тушить/запускать любого эктора не стопая всю систему.

https://youtu.be/ohoziTneUIA?list=PLIDnqr06TjPEaCkJuZlvl6J8KEqBuZrMI&t=15

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

это не по таргету когда скиллы летят

детский сад. визитер,и графы

трасировка лучей, векторная алгебра

трасировка лучей, векторная алгебра

почитай, там не совсем трасировка

это вы игру делали?

я

ваще круть!

трасировка лучей, векторная алгебра

напомню: мы этот разговор начинали в контексте спора на тему геттеров, необходимости доступа к стэйту и что классическое ооп там не катит и потому все юзают ecs, pure data entity и т.д. и т.п.

ваще круть!

графику и уи тож я, в ообщем все я, сервак, клиент

геттеры не нужны

там жалко бекенда не вино, редакторы на каждый пук есть

я паблики люблю

пушка в игру оч быстро добавляется

я паблики люблю

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

тик сервера 40мс, за это время все все все надо просчитать по всем игрокам и мобам, вижн, попадания, перемещения, ну и так далее

я понимаю, не такие крутые, но я писал подобные

а вы физику сами писали? какаой яп на сервере?

все я с малым на улицу

а вы физику сами писали? какаой яп на сервере?

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

так как есть рпг составляющая

а вы физику сами писали? какаой яп на сервере?

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

потом спрошу еще раз

https://www.youtube.com/watch?v=lQQ_CahFVzw

это пояснение идеи Data-Context-Interaction (тот видос выше от тургве который чуть тяжело воспринимать, а тут попроще)...

может так же заинтересовать тех кто говорит что анемичные модели это плохо)

Вопрос такой. В симфонии формы нарушают или нет SRP? они ж там вроде как занимаются изменением стейта объекта + валидация входящих данных

имею в виду этот пример: https://symfony.com/doc/current/forms.html#handling-form-submissions

Вопрос такой. В симфонии формы нарушают или нет SRP? они ж там вроде как занимаются изменением стейта объекта + валидация входящих данных

а что в твоем понимании SRP ?

а что в твоем понимании SRP ?

именно то, как расшифровывается эта аббревиатура.

а что в твоем понимании SRP ?

звучит как "а с какого ты района"

т.е. форма должно тока валидировать входяшие данные

именно то, как расшифровывается эта аббревиатура.

ну а как ты ее понимаешь?

на мой взгляд

т.е. форма должно тока валидировать входяшие данные

почему ?

почему нет?

весомый аргумент, так мы услышим то, что ты подразумеваешь под SRP или нет?

я уже ответил

Вопрос такой. В симфонии формы нарушают или нет SRP? они ж там вроде как занимаются изменением стейта объекта + валидация входящих данных

валидация делигируется - все хорошо

формы выступают фасадом ко всему воркфлоу работы с данными

именно то, как расшифровывается эта аббревиатура.

понимаешь, сложность как раз состоит в том что бы выделить ту самую зону ответственности. Это очень скользский принцип который сильно привязан к контексту задачи. То есть ты берешь код, в одном контексте он типа SRP и все такое, а в другом контексте (например прошло время и часть требований поменялась) - уже не очень то соблюдается эта штука.

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

Я тут тестовое одно делал сегодня простое. Хотел бы услышать критику по некоторым вопросом. Задание - есть собаки - пара настоящих и игрушечные. Они могут охотиться и издавать звуки, причем каждая собака может не все. Нужно было сделать консольное приложение, чтобы вызвать по идентификатору у собаки лай или начать охоту. Я сделал пару интерфейсов - для охоты и для звуков, и один просто для собаки пустой (на всякий случай). Лучше ли это, чем использовать наследование? Хотя от контекста зависит. Т.е. поведение собаки можно узнать по тому, реализует ли она нужный интерфейс. В клиенском коде я как-раз это делаю и возвращаю ответ, что собака не может издавать звуки/охотиться. Также нужно было тесты написать. Я делал assert на существующее поведение. Но что-то не нашел проверку на отсутствие метода у объекта, поэтому делал также проверку на отсутвие интерфейса. Нужно ли вообще делать ее? Или достаточно проверить работоспособность существующих методов. Могут же требования измениться в системе, что плюшевая собака должна начать издавать звуки, добавится интерфейс, а в тестах это пройдет незаметно. Также, если просто метод добавят, даже проверка на отсутствие интерфейса не прокатит.

Я тут тестовое одно делал сегодня простое. Хотел бы услышать критику по некоторым вопросом. Задание - есть собаки - пара настоящих и игрушечные. Они могут охотиться и издавать звуки, причем каждая собака может не все. Нужно было сделать консольное приложение, чтобы вызвать по идентификатору у собаки лай или начать охоту. Я сделал пару интерфейсов - для охоты и для звуков, и один просто для собаки пустой (на всякий случай). Лучше ли это, чем использовать наследование? Хотя от контекста зависит. Т.е. поведение собаки можно узнать по тому, реализует ли она нужный интерфейс. В клиенском коде я как-раз это делаю и возвращаю ответ, что собака не может издавать звуки/охотиться. Также нужно было тесты написать. Я делал assert на существующее поведение. Но что-то не нашел проверку на отсутствие метода у объекта, поэтому делал также проверку на отсутвие интерфейса. Нужно ли вообще делать ее? Или достаточно проверить работоспособность существующих методов. Могут же требования измениться в системе, что плюшевая собака должна начать издавать звуки, добавится интерфейс, а в тестах это пройдет незаметно. Также, если просто метод добавят, даже проверка на отсутствие интерфейса не прокатит.

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

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

Я тут тестовое одно делал сегодня простое. Хотел бы услышать критику по некоторым вопросом. Задание - есть собаки - пара настоящих и игрушечные. Они могут охотиться и издавать звуки, причем каждая собака может не все. Нужно было сделать консольное приложение, чтобы вызвать по идентификатору у собаки лай или начать охоту. Я сделал пару интерфейсов - для охоты и для звуков, и один просто для собаки пустой (на всякий случай). Лучше ли это, чем использовать наследование? Хотя от контекста зависит. Т.е. поведение собаки можно узнать по тому, реализует ли она нужный интерфейс. В клиенском коде я как-раз это делаю и возвращаю ответ, что собака не может издавать звуки/охотиться. Также нужно было тесты написать. Я делал assert на существующее поведение. Но что-то не нашел проверку на отсутствие метода у объекта, поэтому делал также проверку на отсутвие интерфейса. Нужно ли вообще делать ее? Или достаточно проверить работоспособность существующих методов. Могут же требования измениться в системе, что плюшевая собака должна начать издавать звуки, добавится интерфейс, а в тестах это пройдет незаметно. Также, если просто метод добавят, даже проверка на отсутствие интерфейса не прокатит.

абстрактная фабрика + стратегия

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

тут про другое вопрос

лучше ли текущая архитектура наследования

или как это тестировать правильно

часто слышу, что наследование не нужно

в моем представлении это так должно выглядеть

как описал

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

часто слышу, что наследование не нужно

либо наследование либо декорация, по другому никак, есть конечно вариант индусского кода на switch, но это тебе не интересно будет)

либо наследование либо декорация, по другому никак, есть конечно вариант индусского кода на switch, но это тебе не интересно будет)

А ты, я смотрю, нарушитель :)

А ты, я смотрю, нарушитель :)

а ты кто?

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

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

Читать книжки, доки ?

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

А что за проект?

И почему не по зубам? По времени или по компетенции

слишком простой. я его усложнил в сотню раз, пилил два месяца и сдался

только что

проект сейчас работает на 10-ти буквально php файликах по 1000 строк

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

и закопался нахуй в этом дерьме

и оно все равно не работает то через командную строку, то через курл, то еще через какой-то пиздец

в общем так чтобы включил и поехало - я всё

Есть три пути: 1) начать все с нуля 2) рефакторинг 3) оставить как есть, исправить ошибки, чтобы хоть работало

Может начать писать тесты?

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