Nikita Schipilov: объект, это обычная структура данных состоящая из пар ключ-значение, где в роле ключа всегда выступает срока, а в качестве значения может быть все что угодно. Объект ничем не отличается от пакета из магазина в который Вы складываете покупки.
Объект-конструктор можно рассматривать как спортивную сумку с отделением для объектов this и отделением для prototype.
Сергей Протько: я для себя вынес что писать на фраймворке которому хотя бы полтора года не буду, слишком много раз мне авторы отвечали, что было бы прикольно, пока они зарабатывают миллионы на уроках и книгах исправить баг за них.
делается математическая модель стрелки состоящая из векторов, которые только и ожидают нормаль чтобы поскорей принять форму и загипнотизировать своей работой новичков.
Нормаль высчитывается исходя из позиций место клика - курсор + расстояние между ними.
И вот значит после того как предыдущие шаги Вы реализовали создаете объект который при создании сохраняет току начала и реализует метод update в который Вы будите при драге передавать положение курсора. Осталось создать метод getRowPath который будет возвращать массив точек заново рассчитываемый стрелки и передавать его в метод рендера.
Вы не сможете сделать подобную игру на js. Если не верите мне, а верите тем кто посоветовал Вам кривые-убогие движки ниже, то могу посоветовать прежде чем браться поискать ПОДОБНЫЕ игры на этих самых движках. Только не красивый кликер, а именно подобную игру с физикой и тем же fps. Вы не найдете! Те кто советует сами ничего не делают и просто зарабатывают плюсики на тостере не понимая во что втягивают спрашивающего.
Сергей Протько: да, в случаи если цвет или любой другой параметр влияет на заданный моделью исход, то он является логикой самого приложения и место ему в модели. Та же модель ядерного чемоданчика просто обязана знать о самом важном в нем - красной кнопке.
Сергей Протько: и ещё сразу хочется напомнить что будет множества моделей, которые взаимодействуют друг с другом, как например модель трека и модели авто. Но
следует помнить что от мощности двигателя зависит исход игры, а значит мощность,
это в модели. Но в модели не место таким значениям, как например цвет кузова, который
является данными для отображения и которые так сильно хочется получить вместе с данными из модели авто. Но нет, это всего-лишь данные представления.
ну самое простое и самое верное решение, это прочесть хотя бы по одной книге по html, css и конечно же js. И тогда подобные вопросы отпадут сами собой. И я скажу более - потратив на чтение неделю (Вы же в состоянии прочесть три книги за неделю??? ну или за две) Вы сможете создать то, о чем сейчас даже не подозреваете!
Fedor: мне кажется мы с Сергей Протько: не спорим, помогаем друг-другу разобраться. По крайней мере я вступая в дебаты рассчитываю получить то что получил в этом разговоре - возможность подумать о чем-то что ещё не делал, чтобы избежать ошибок в реальных условиях.
Лично я вправду подзабыл что контроллер работает с пользователем и у меня этим часто занимается что-то другое и даже представление. По факту сама вью не слушает ничего, всегда есть объект который слушает представление и дергает представление и это единственно верный способ тестирования и замены пользователя, например ИИ.
Но я всегда считал что это тоже представление, теперь буду приписывать что это ControlController :)
Я не юрист, но могу сказать как разработчик - если продукты которые Вы хотите огородить от копирования это только Ваша разработка которая не выложена в публичный доступ, то я бы не стал использовать её после ухода от Вас в точно таком же виде, как она есть. Но мне никто бы не смог помешать написать тоже самое самому и создать похожий продукт. И я не верю что в мире может существовать закон который бы мне это запретил. Даже если бы я находился в стране с мифическими законами, то всегда есть внешние международные суды.
Ну а если Ваши технологии это взятые из опенсорса или купленные за деньги, то я вообще наклал бы на любой контракт и использовал бы точно так же как Вы меня и научили.
То есть ответ - если Вы даже в контракте прописали весь Ваш параноидальный бред, то наклал бы я на него такууую кучу.
Зачем на сервере? Зачем создавать себе головную боль? Все на клиенте.
Если игра мультиплеерная, то обязательно на сервере так как игроки будут читерит и это единственный способ защитить, а значит не потерять честных игроков. Поэтому даже обсуждать не стоит - проверка на сервере и точка. То есть сервер должен знать о положении каждого авто, его скорости и повреждениях в каждом кадре. И мне кажется что для модели MP игры это максимум.
То есть на клиенте столкновения проверяются все тем же физическим движком что и остальная физика и являются обычным представлением. А на сервер в модель каждый кадр отсылаются данные о позиции в мире и все.
Ну а если сервера нет и бороться с читерами вообще не нужно, то смело можно отказываться от коллизий в модели вообще. Модели авто важно чтобы при нажатии "ускорение" машинка ускорилась на точно отмеренное время и увеличила точно заданную скорость, а то что она с кем-то врезалась...
Если представить гонку на выживание, где машинки врезаются и убивают друг друга, то модели будет важны только жизни всех авто чтобы следовать сценарию.
я вчера почти весь вечер об этом думал и даже рассматривал на примере шутера, но все равно мне кажется что это не модель. Под натиском мыслей о читерах я даже подумал что можно было бы создать серверную вью, которая бы и занималась расчетами положения тел и полета пуль...
Ведь это модель мира, а значит в компетенции физического движка - представления и единственная причина по которой это и может оказаться на сервере - читеры.
В общем пока бы я делал так как написал, но не совсем уверен что прав.
Сергей Протько: и вот mvvm я бы тоже не спешил применять так как это стопудово сотрет грань между "возможно отдаленно напоминает модель" и "вообще ни разу не модель".
Работу с устройствами ввода на себя берут контроллеры.
Давайте вспомним что контроллеры созданы для связи представления и модели, это их первостепенная задача. У нас же умная вьюха, это она слушает события и если её они только и нужны, то контроллер совершенно не причем.
Ну а дальше я согласен, что если гонки мультиплеер, то да, просчет столкновений обязательно на сервере и этот просчет будет являться частью модели. Действия тогда будут вот примерно какие - вью каждый кадр посылает события с координатами машинки и что-то ещё, то нужно. Контроллер ловит и отсылает эти данные на сервер. На сервере все ещё раз проверяет и если столкновение действительно было, то снимаются показатели скорости и положения и рассчитывается урон, который от-сы-ла-ет-ся... на клиент! Похоже и правда mvp опять получается... Ведь в случаи с мультиплеером в моделе на клиенте просто нет смысла, а это означает что серверная модель пошлет событие которое будет ловить контроллер и передавать в представление будет тоже контроллер.
Но вот если прикинуть что узнавать у сервера сколько максимально может развить скорость машинка чтобы не привысить предел на спидометре, это же согласитесь глупо. Ведь предел не изменится и значение по ходу заезда не меняется, а значит нужно эти значения просто захешировать на клиенте. А это данные ни разу не представления, а значит все же нужно завести модель. И это только начало, наверняка наберется маленькая тележка на полноценную модель, которая и установит связь с сервером и все встанет на свое русло.
Но вот только Ваш пример доказал что все же есть mvp, о котором я просто не знал так как никогда не писал сложные мультиплееры и рассуждал с точки зрения простых игр и десктопных приложений.
И тут есть ещё одно но! На клиенте никогда не будет работать мультиплеер исходя только из цифр пришедших с сервера так как пинг никто не отменял. Поэтому на клиенте всегда делают опрамиксацию времени, что на ход игры и на модель влиять никак не будет, а значит на клиенте расчеты положения и столкновения все-таки будут рассчитываться в представлении. Ведь эти значения не будут учитываться и браться в расчет серверной моделью, которая будет только значения получать для своих расчетов.
И спасибо, Ваш пример зажег во мне искру которые как раз и разжигают во мне страсть к коду.
Сергей Протько: моделирование солкновений может и называется, но только в заумных книжках. Я ни разу не слушал из уст геймдевов такие жуткие слова :) Физическая модель, это когда Вы физические движки используете, я же предлагаю делать очень простые игры чтобы разработка принесла радость, а не чтение заумных книг тонну.
Для меня представление === view, оно является всем что не бизнес модель === model, ну и естественно не контроллер. Когда я говорю представление, я подразумеваю все от картинок и текста, то твинов и физических движков, да хоть самого webgl, это все вью. И столкновения проверяет вью, вся физика, это тоже вью. Естественно реализация проверки столкновения будет вынесена в сервис... Но сервис это абстрактное понятие которое на жаргоне программистов означает код которые вынесен откуда-то и его легко заменить. Не более. И главное хочу напомнить, что проверки инициируются вью и происходят во вью. Не в контроллере. умная полноценная вью и активная полноценная модель. Контроллер нужен лишь для ... вью обнаружила столкновение, послало событие, которое поймал контроллер и сказал об этом модели.
И ещё раз - представление включает в себя и презентационную логику и все-все-все.
Вообще в вэб играх существуюет иерархия из MainModel которая получив команду от модели устанавливает LobbyView или GameView, которые в свою очередь собирают экран и являются связующим звеном своей части.
сервер на все запросы должен всегда отдавать index.html в который встроены реакт и Ваше приложение. Все! Все остальное разруливается с помощью реакт-роутера. Это минимум.
Если же Вы хотите создать изоморфное приложение с пререндером на сервере, то на все пути
нужно отдавать тот же самый index.html в котором подключен реакт и приложение, но вот тело страницы нужно вставить строку сгенерированную серверным рендером реакт.
Ну а дальше остается только определится на чем будет написано api, если оно вообще нужно.
авторизация это отдельная и больная тема, так нужно выбирать между удобством и наибольшей защищенностью. Ну и серверные запросы к api тоже как бы дело спорное..
у redux нет жизненного цикла, а думать что вызывается первым из приведенных Вами в качестве примера функций, тоже самое что рассуждать на тему "что раньше будет обрабатываться в a или b в Math.max(a, b) ", то есть бессмысленно.
Сергей Протько: одно из самого простого это морской бой. Вся игра вся логика игры находится на сервере. Как все происходит... К серверу подключается (соккет серверу) игрок и дожидается второго игрока в очереди. Как только есть с кем играть создается комната с инстенсом игры и дальнейшие действия переходят под управление модели. Модель шлет клиентам событие и говорит что нужно расставлять корабли, на что у них есть минута по истечению которой модель сама расставляет корабли.
Дальше все просто - клиент пошел, сервер проверил допустимый ход или нет и если да, то делает ход и делает соответствующие действия.
Эта простая игра покажет Вам что на сервере может быть стандартная реализация mvc и так же докажет что весь клиент, все кнопки и игровое поле и анимации и прочее, это все представление. То есть в морском бое вообще на клиенте нет модели.Хотя если Вы захотите предварительно валидировать ходы на клиенте, то можно создать модель которая будет иметь один метод типа проверитьДопустимостьХода и будет связываться с моделью на сервере и проверять можно пойти или нет.
И вот тут у Вас должен наступить ступор, ведь игровое поле очень сложный компонент, но это всего-навсего представление и те МОДЕЛИ КОМПОНЕНТА о которых Вы говорили всего-лишь выдумка. Модель которая делает препроверку, модель на сервере и все! Если у компонентов и есть модель, то только модель-представления, которая так и называется но по факту сбивает с толку все подряд, так как все думают что говоря о модели представления говорят о модели из mvc о модели приложения. Модель представления это всего-лишь вынесенные данные в виде value object для того чтобы со сложным составным было легче работать, легче его подстраивать и изменять.
Ещё можно создать какие-нибудь простые гонки у которых сервера вообще не будет.
В активной модели должны быть характеристики авто, длина трека, значение собранных бонусов (типа собрал конистру с нитро на несколько секунд, которые естественно отсчитываются и контролируются моделью, происходит ускорение) и т.п.
А вот проверка столкновений с препятствиями на пути это уже дело представления, которое про положительном результате говорит модели автоВрезалось (естественно представление диспатчит событие, которое ловит контроллер, который естественно будет всего один на всю игру).
В этом примере представление вообще наисложнейшее и лучшим образом показывает что представление очень сложное, даже может быть намного сложнее чем модель, но при этом говоря о представлении не нужно упоминать модель.
Объект-конструктор можно рассматривать как спортивную сумку с отделением для объектов this и отделением для prototype.