Даже хуй знает, бот это или настоящий кирилл.
Не баньте меня. Я настоящий.
STAGE 0 299 дней, 20 часов, 59 минут
в качестве игрового движка я выбрал среду разработки интерактивных мультиплатформенных мультимедийных аппликаций YNUTI.
как человек не относящий себя к классу глупых, я решил начать с networking'а. будет неприятно через полгода насилия над кубами осознать, что я не осилю создание мультиплеера, или существющая АРХИТЕКТУРА не годится для сетевой игры.
на выбор 3 (три) варианта:
1. использовать high level api
2. использовать low level api
3. использовать велосипед
поразительно, какого объема задачи я запланировал на эту неделю.
в качестве игрового движка я выбрал среду разработки интерактивных мультиплатформенных мультимедийных аппликаций YNUTI.
как человек не относящий себя к классу глупых, я решил начать с networking'а. будет неприятно через полгода насилия над кубами осознать, что я не осилю создание мультиплеера, или существющая АРХИТЕКТУРА не годится для сетевой игры.
на выбор 3 (три) варианта:
1. использовать high level api
2. использовать low level api
3. использовать велосипед
поразительно, какого объема задачи я запланировал на эту неделю.
Годый тред, поддвачну. Значит смотри, сначала изучи хай левел апи чтоб понять вообще какие крутые словца в коде можно использовать. Потом попробуй повторить его поведение (ес-но урезано и глючно) на лоу-левеле, а затеп переходи к написанию своего велосипеда, иначе это будет не трух, сам понимаешь.
Поехали!
>YNUTI
тралеш, сцука, но тхреад годный
>тхреад годный
Анимедаун сольется через 2 дня не осилив юнити, годнота так годнота.
>ко-ко-ко
> весь день
Давай на чистоту. Ты можешь то, что можешь написать за 4 часа. Засекай. напишишь игру - значит можешь сделать игру.
что?
Оп,на чем кодить собрался?
ты чё сказать хотел?
Человеческие возможности программирования можно оценить за 4 часа. Дать конкретную задачку закодить.
profit?
пожалуй так и поступлю
в основном unity и C#
STAGE 0 299 дней, 10 часов, 44 минут by vylezatorstvo calculator v0.1-a
проанализировав объем информации, я пришел к нижеследующим умозаключениям:
1. чтобы использовать high level api нужно платить unity деньги.
в своей сущности high level api просто обеспечивает простое p2p соединение и обменивается сообщениями 3 типов: выполнить функцию на host'е, выполнить функцию на всех peer'ах и репликация обозначенных переменных. при этом он использует для своих целей рефлексию, наверняка нещадно серит под себя "мусором" и вообще ведет себя по свински, разбазаривая драгоценные FPS. является большим вопросом целесообразность использования этого high level api. не в последнюю очередь из-за того, что я нищеброд что единственным его способом отладки является сборка игры и каждый раз запуск ее копии. это во времена, когда то же самое делается в UE4 одним нажатием кнопки.
2. low level api по сути является оболочкой над udp socket'ами, в которой уже сделано reliable/unreliable udp-соединение и всякое такое. это твой бро. из чего следует, что
3. написание "велосипеда" для работы с сетью не имеет смысла, потому все это уже есть в low level api.
поправьте, если я где-то ошибаюсь.
из всего вышеописанного я разработал план для STAGE 1: теоретическая разработка архитектуры p2p клиент/сервера и отправку сообщений между peer'ами на основе low level api.
хорошая годная тема, хороший годный срыв покров. очень интерестно, сам невероятно фапаю на п2п но использовать пока не доводилось. где прочитать про эти апи у юнити, можно ли ссылку? хочу запилить такое на другом языке (писюне), наверняка аналог лоу-левела там уже есть искаропки, а может и более высокоуровневые поделия.
а почему выбран именно п2п а не 2ентрализированный сепрвер? типа 2К17 да? технолгие? или что-то вдохновило?йй
Заверешнные и выпущенные проекты.
>хороший годный срыв покров
>обеспечивает простое p2p соединение
Какой нахуй срыв покровов, когда нет никакого peer-to-peer у юнити? Вообще заведомо хуёвый подход для игры. HLAPI же предоставляет возможность пересылки трафа на сервера юнити, а оттуда уже всем клиентам. И нечего дрочить на p2p, это гарантированные тормоза, лаги и читы.
Это все здорово конечно, но если ты думаешь, что вся эта мультиплеерная-поебень позволит тебе закончить игру - ты крупно ошибаешься. Оглянись вокруг - здесь у каждого третьего в кармане лежит парочка незаконченных проектов, в которые наверняка можно поиграть, но при этом они не являются законченной игрой как таковой.
Советую тебе умерить амбиции и для начала просто сделать полноценную игру.
С продуманными и (по крайней мере) симпатичными интерфейсами, их анимациями, окнами, воспроизведением звуков/музыки, оптимизацией интерфейсов играфики под разные разрешения. Обычно это все оставляют за бортом. Как будто достаточно запилить основные геймплейные механики и все - игра готова. А вот нет. Даже близко к завершению не стоит. Так что заранее пройди через все эти скучные, но необходимые этапы, которые начинающие кириллы обычно оставляют за бортом и в итоге имеют кривой прототип с кубами и дебажными интерфейсами, вместо полноценной игры.
Пройди этот путь хоть раз - и потом уже усложняй основную часть игры, если твои знания тебе это позволяют.
что завершить, надо начать
ОП, послушайся хоть ты этого мудрого анона. Не повторяй ошибок /gd.
>где прочитать про эти апи у юнити, можно ли ссылку?
на официальном сайте же
https://docs.unity3d.com/Manual/UNet.html
>почему выбран именно п2п а не 2ентрализированный сепрвер?
на самом деле очень просто. сначала нужно понимать, чем выделенный сервер отличается от p2p. грубо говоря, все состояние игры вычисляется один раз только на централизованном сервере, а все клиенты являются терминалами, просто отображающими это одно единственное состояние игроку и отправляющими на сервер его команды.
в p2p-игре игровое состояние вычисляется у каждого игрока самостоятельно, а игроки только посредством обмена сообщениями друг с другом синхронизируют свои состояния. при этом игроки могут как рассылать сообщения сразу всем пирам, или только одному т.н. "хосту", который уже пересылает их другим игрокам. это тоже считается p2p. так сделано в unity. в любом случае должен быть какой-то один пир, который бы обновлял состояние объектов, которые не принадлежат ни одному игроку (ну например, крипы в мобе. кто их должен контроллировать?), поэтому архитектура с хостом предпочтительнее.
у p2p есть 2 проблемы: рассинхронизация и читерство. можно решить проблему синхронизации радикально, синхронизируя не состояние геймобжектов, а инпут игроков, как это делали в старых стратегиях. но тут как ты понимаешь малейшего пука достаточно, чтобы распидорасить состояние игры. поэтому в основном синхронизируются объекты (как в юнити).
про читерство я пока даже не хочу думать. это проблема актуальна только для игор уровня CS. будет уже хорошо, если моя поделка вообще заработает.
из всего этого следует только то, что для создания централизованного сервера мне нужно велосипедить всю игру и ее логику с нуля, а юнити просто использовать для отображения состояния, потом еще платить за сервер в каких-нибудь ебенях с пингом 500мс. а в случае p2p мне нужно сделать игру на unity как обычно и просто синхрозировать состояние отдельных объектов по сети. выбор думаю очевиден.
но у юнити p2p. ты наверное имеешь в виду их relay-серверы. они просто обеспечивают подключение через себя всех пиров за НАТ и прочим дерьмом, которые сами к друг другу просто так не смогут подключиться.
ты предлагаешь оставить ПРОЕКТ МЕЧТЫ, чтобы сделать какую-то скучную и неинтересную игру? сомневаюсь что предложенный тобой метод будет эффективнее для обучения. может у меня и не стоит такой цели закончить игру.
а если ты говоришь что надо начтаь сначала с игры, а потом доделать все остальное. то такой способ чреват проблемами и полной переделкой потом всего с нуля.
двачую, да, но знаете, всю эту скукоту я прошел еще в шараге когда делал курсачом арканоида, у меня и звуки были и редактор и разрешения, даже ридми написал, весь графоний сам дрочил, вот это все, а теперь планка поднялась, годы макакинга, короче я к чему
мечтать тоже не вредно, мечтать необходимо, в серости суровых будней художника спасут только мечты
так что опчик, слушай. продолжай мечтать и пилить мультиплей, но и рутину не забывай, баланс нужен
про п2п прийдется согласиться с более опытным коллегой, видать централизированный сервер для риалтайма больше подходит, все-же не скайп пишешь и не пошаговую хуергу. так или иначе, любому п2п нужны координационные узлы, не стоит упрощать себе жизнь, возьми любой пимер с бродкастом всего всем и продолжай
оп, насчет нетворкинга и состояния ты заблуждаешься. даже с централизированным состояния у всех вычисляется свое, иначе это было бы отрывчатое кино с рейтом 1 фрейм в минуту, сервера лишь контролируют сихнорнность и валидность состояния, короче зеленый ты еще, учись дальше. отписываюсь.
твой очевидный выбор не очевиден, удачи тебе и да, переписывать все с нуля каждую неделю как не крути прийдется. еще раз, к сожалнию отписываюсь. удачи, оп. плак плак, гд опять без годнотреда. наверное свой создам. выклади хоть калькулятор на гитхаб, чтоб я свой не писал.
upd: тут говорят, что можно использовать HLAPI бесплатно, не пользуясь NetworkManager и их matchmaking'ом, а только используя как-то классы NetworkSever и NetworkClient. но я уже собрался делать свою глючную версию HLAPI и меня ничто не остановит.
хотя если кто-то знает хороший туториал как это сделать, то может и остановит.
>даже с централизированным состояния у всех вычисляется свое, иначе это было бы отрывчатое кино с рейтом 1 фрейм в минуту
ну естественно на клиенте есть интерполяция, client-side prediction и всякое такое. суть в том, что состояние игры ЕСТЬ ТОЛЬКО ОДНО и оно ТОЛЬКО У ЦЕНТРЛАЗИОВАННОГО СЕРВЕРА. как сервер решит, так и будет. нет никаких проблем с рассинхроном и т.п.
>отписываюсь
>к сожалнию отписываюсь
ОТ МЕНЯ ОТПИСЫВАЮТСЯ!!!1
>может у меня и не стоит такой цели >закончить игру.
Если не стоит, то тогда конечно окей, пили проект мечты сколько влезет, косяки тебе не страшны. Но в первом же посте ты написал, что решил
>НАПИСАТЬ ИГРУ ЗА 300 ДНЕЙ
, что как бы подразумевает.
>сомневаюсь что предложенный тобой метод >будет эффективнее для обучения.
Это нормально, что ты сомневаешься, но учти вот что.
Ты не уникален, ты обычный рядовой человек. Через этот этап так или иначе проходят все создатели игр и тебе тоже придется пройти.
Лично я за последние два года сделал три полноценные игры, а не прототипы, и сейчас делаю четвертую, так что некоторый опыт у меня есть. И я тебя просто предупреждаю, что бы ты мог сэкономить свое время и силы, потому что в будущем будет вот как:
Если ты не бросишь свою затею через неделю, то пройдет два или три месяца, или даже полгода, в зависимости от размаха и силы воли, и ты поймешь, что игра-то как бы готова. И ты такой подумаешь "заебись у меня игра получилось, осталось доделать всякие интерфейсы". И ты начнешь их пилить. Попилишь день, два. Но это крайне скучно. Ты устанешь и сделаешь небольшой перерыв. Пилить интерфейсы - это тебе не реализовывать крутые механики глобальной 4Х стратегии, это тупо закрыть окно, открыть окно, запустить анимацию, затемнить экран и т.д. В этой работе практически нет никакого творчества, это скучная рутина. И самое главное - это даже никак не отражается на геймплее. То есть тебе нужно много-много работать, но сама твоя игра при этом ни капли не становиться интереснее - замечательно, не правда ли? Это ОЧЕНЬ влияет на мотивированность и работоспособность. Ты ведь не реализовываешь никаких новых фич, ничего подобного. Со временем промежутки между работой увеличатся. В какой-то момент ты осознаешь истину - процесс написания кор геймплея занимает от силы половину или даже треть времени нужного на разработку полноценной игры. Все остальное время - это та скучная рутина, которая на непосредственно процесс геймплея не влияет вообще никак. И когда это произойдет, ты скорее всего отложишь свой прототип с кубами и инновационным геймплеей в ящик, а сам начнешь реализовывать свои новые охуительные идеи, уже в другом прототипе. Ведь прототипировать - это так интересно, это тебе не скучной рутиной заниматься. И в итоге у тебя не будет ни одной законченной игры.
Можешь сомневаться дальше, а можешь прислушаться к совету того, кто через все это уже прошел и испытал на себе. Не делай свой первый проект охуительно большим и громоздким, иначе твоя карьера геймдевелопера на этом скорее всего и закончиться. Умерь свой пыл и амбиции, не торопись. Ты можешь начать пилить проект мечты и через полгода, и даже через год, он от тебя никуда не убежит. Наоборот, шансы на его успешное создание возрастут десятикратно.
придумал как тестировать мультиплеер в юнити. трюк заключается в использовании функции multidisplay. не знаю что это за функция и зачем она нужна, но знаю только что можно назначить разные дисплеи на камеры и выбрать какой дисплей (камеру) показывать в каждом game window.
я не понимаю как у одной игры может не быть одного состояния. если только это разные чанки и все киленты не обязаны знать о состоянии всего мира, но где-то все равно это одно состояние. слишком много фантазий слишком мало ПоКов
ебать ты гений, что еще спизданешь? две игры рядом запускать не пробовал, унтерок?й
ну я неправильно написал. суть в том, что состояние одно в том смысле, что только сервер запускает игровую логику которая обновляет состояние игры. а клиенты просто получают изменения этого состояния и показывают их.
ну это как в классических играх, как в CS, дотке. ничто не мешает сделать комбинированный вариант.
именно этого я и хочу избежать
>как у одной игры может не быть одного состояния
у одной мультплеерной игры должно быть одно состояние. и задача мультиплеера как-раз показывать это одно состояние разным игрокам. разница в том, как p2p и центральный сервер решают эту задачу
STAGE 1 EARLY DRAFT 298 дней, 18 часов, 26 минут by vylezatorstvo calculator v0.1-a
моя ARCHITECTURE как и все гениальное проста: ни сервер, ни клиент не нужны. у меня есть компонент с незатейливым названием PeerComponent. это будет просто обертка над NetworkTransport (это low level api). в этом компоненте есть список peer'ов. сам этот компонент никак этим списком не управляет, а предоставляет интерфейс для этого другим компонентам. так-же этот компонент может рассылать исходящие сообщения (просто байтовый массив) всем peer'ам из своего списка и пересылать входящие сообщения всем peer'ам из своего списка (репликация данных и функций у host'а) или не пересылать, в зависимости от заданного флага в сообщении (чтобы отправлять сообщения только одному host'у, например).
нарисовал UML диаграмму.
вот и все. все остальное уже будет делаться как простые обработчики этих сообщений.
вот такой план родился у меня в голове. наверняка я обосрался и это все неправильно.
моя ARCHITECTURE как и все гениальное проста: ни сервер, ни клиент не нужны. у меня есть компонент с незатейливым названием PeerComponent. это будет просто обертка над NetworkTransport (это low level api). в этом компоненте есть список peer'ов. сам этот компонент никак этим списком не управляет, а предоставляет интерфейс для этого другим компонентам. так-же этот компонент может рассылать исходящие сообщения (просто байтовый массив) всем peer'ам из своего списка и пересылать входящие сообщения всем peer'ам из своего списка (репликация данных и функций у host'а) или не пересылать, в зависимости от заданного флага в сообщении (чтобы отправлять сообщения только одному host'у, например).
нарисовал UML диаграмму.
вот и все. все остальное уже будет делаться как простые обработчики этих сообщений.
вот такой план родился у меня в голове. наверняка я обосрался и это все неправильно.
>>НАПИСАТЬ ИГРУ ЗА 300 ДНЕЙ
да, попытаться написать за 300 дней. но у меня нет цели закончить игру и заработать миллион. получится закончить, значит получится. не получится, значит не получится. просто чтобы не деградировать.
>процесс написания кор геймплея занимает от силы половину или даже треть времени нужного на разработку полноценной игры. Все остальное время - это та скучная рутина, которая на непосредственно процесс геймплея не влияет вообще никак.
я понял тебя. ты имеешь ввиду, что люди не допиливают свои прототипы и дропают.
только я думаю что тут несколько другая причина, а именно неопределенность. люди дропают не потому, что им скучно пилить интерфейс, а потому что не могут решить какой интерфейс им нужно запилить. игра делается легко, пока разработка идет по рельсам, пока ты точно знаешь что тебе нужно сделать: сделать персонажа, добавить ему движение, функции стрельбы и т.д. когда все по туториалам сделано то начинается затык, потому что разработчики просто не знают что им делать дальше.
это я к тому, что в общем-то я делаю можно сказать клон. и у меня таких проблем не должно быть в больших количествах.
>Не делай свой первый проект охуительно большим и громоздким
Но у меня не громоздкий проект. Сделать сеть это уже почти весь проект. Все остальное элементарно.
Это как-раз такой маленький проект. Сделать его и забросить. Безо всяких амбиций и гринлайтов.
>второй пик
Это тот самый тест на аутизм?
upd: вся логика PeerComponent вынесена из него в КАНАЛЫ. теперь сообщение имеет вид "id канала, тело сообщения". каждый КАНАЛ имеет свою какую угодно логику. пересылать сообщения или нет уже решает КАНАЛ
эти каналы связаны с каналами NetworkTransport. так что тип связи и т.д. настраивается там-же
Это твоя вебмка? Как сделана сеть?
Разве это не постили ещё во времена твг8?
на legacy
STAGE 1 EARLY DRAFT 298 дней, 1 часов, 34 минут by vylezatorstvo calculator v0.1-a
в результате напряженного дня работы и бессоной ночи я разработал сетевую архитектуру ЖОПА.
данная архитектура состоит из следующих компонентов:
1. глобальный онлайн-провайдер (кодовое имя ЖОПА). жопа является просто тонким слоем абстракциии над NetworkTransport и обеспечивает обмен сетевыми сообщениями в виде массива байтов. TODO: именно этот компонент во время разработки можно подменить на симулятор, который будет отправлять сообщения не через NetworkTransport, а просто другому указанному компоненту, например.
2. автоматическая онлайн-управляющая система (кодовое имя АНУС). анус является привратником жопы. в задачи ануса входит быть посредником между жопой и калом. когда анус получает массив данных из жопы, он отправляет его в ассоциированный с ним канал. когда анус получает массив данных из канала, он посылает его в жопу.
3. каналы передачи данных (кодовое имя КАЛ). про каналы уже писал. в кале сообщения от GameObject'ов пакуются и распаковываются из массивов байтов, обеспечивая возможность для кала задать свой особый протокол, скорость с которой нужно отправлять сообщения и многое другое.
а теперь спать.
в результате напряженного дня работы и бессоной ночи я разработал сетевую архитектуру ЖОПА.
данная архитектура состоит из следующих компонентов:
1. глобальный онлайн-провайдер (кодовое имя ЖОПА). жопа является просто тонким слоем абстракциии над NetworkTransport и обеспечивает обмен сетевыми сообщениями в виде массива байтов. TODO: именно этот компонент во время разработки можно подменить на симулятор, который будет отправлять сообщения не через NetworkTransport, а просто другому указанному компоненту, например.
2. автоматическая онлайн-управляющая система (кодовое имя АНУС). анус является привратником жопы. в задачи ануса входит быть посредником между жопой и калом. когда анус получает массив данных из жопы, он отправляет его в ассоциированный с ним канал. когда анус получает массив данных из канала, он посылает его в жопу.
3. каналы передачи данных (кодовое имя КАЛ). про каналы уже писал. в кале сообщения от GameObject'ов пакуются и распаковываются из массивов байтов, обеспечивая возможность для кала задать свой особый протокол, скорость с которой нужно отправлять сообщения и многое другое.
а теперь спать.
Вот до этого момента всё было относительно неплохо
есть замечания по архитектуре?
STAGE 1-1 297 дней, 16 часов, 12 минуты by vylezatorstvo calculator v0.2
сегодня обновил vylezatorstvo calculator до версии 0.2. теперь у слов правильные падежы в зависимости от числа.
уморился.
сегодня обновил vylezatorstvo calculator до версии 0.2. теперь у слов правильные падежы в зависимости от числа.
уморился.
>vyrastiderevo calculator
Архитектура - ГОВНО.
лол как же тебя разорвало от Лейна и его треда =3
STAGE 1-1 ПОЧАЛОСЯ 297 дней, 11 час, 57 минут by vylezatorstvo calculator v0.2
https://github.com/qril/moba
2 files changed, 140 insertions(+)
в этом деле главное - начать. ну и не останавливаться. еще неплохо бы закончить. как-то так, всё просто.
что касается архитектуры, я решил ее пересмотреть. кажется можно обойтись без симулятора, напрямую подключившись двум NetworkTransport-компонентам локально. это делает и без того избыточный компонент ЖОПА ненужным. можно обойтись одним анусом.
понятия не имею о чем ты. если есть вопросы, я готов к дискуссии.
только не говори загадками.
https://github.com/qril/moba
2 files changed, 140 insertions(+)
в этом деле главное - начать. ну и не останавливаться. еще неплохо бы закончить. как-то так, всё просто.
что касается архитектуры, я решил ее пересмотреть. кажется можно обойтись без симулятора, напрямую подключившись двум NetworkTransport-компонентам локально. это делает и без того избыточный компонент ЖОПА ненужным. можно обойтись одним анусом.
понятия не имею о чем ты. если есть вопросы, я готов к дискуссии.
только не говори загадками.
Я очень скептичеси отношусь к таким вот вылезаторам. Скорее всего у тебя нихуя не выйдет.
> vylezatorstvo
Прочитал как высераторство, перечитал, и не понял что поменялось.
"у гого что болит - тот о том и говорит"
Бомбануло от создателя тредом ниже?
ОП не говорит о своих проблемах с головой. Твоя теория не работает
я ж про тебя а не опа
выложи калькулятор в опсорц, чтою все могли себе завести. а лучше сделай его саас.
Спасибо! Ваше мнение очень важно для нас.
>12 минуты
непонятно как задавать ID сетевым объектам в p2p. очевидно, что нельзя это просто делать локально, потому что, например, А пошлет сообщение, а потом Б пошлет сообщение. сообщение А затеряется и придет позже Б. тогда у объектов будут поменяны местами ID.
из этого следует, что ID должен содаваться только тем, кто создает объект. но простой counter увеличивающийся на 1 тоже сделать не получится, по тем-же самым причинам.
единственный вариант это генерировать для каждого объекта GUID. но тогда сразу намного увеличится размер сообщений.
еще вариант, это все объекты создаются только host'ом. но это уже какой-то авторитарный сервер/клиент.
непонятно.
из этого следует, что ID должен содаваться только тем, кто создает объект. но простой counter увеличивающийся на 1 тоже сделать не получится, по тем-же самым причинам.
единственный вариант это генерировать для каждого объекта GUID. но тогда сразу намного увеличится размер сообщений.
еще вариант, это все объекты создаются только host'ом. но это уже какой-то авторитарный сервер/клиент.
непонятно.
решил передавать данные в JSON.
без интернета не сможешь даже прокалькулировать степень твоего вылезаторства. нахуй так жить.
без интернета не сможешь даже прокалькулировать степень твоего вылезаторства. нахуй так жить.
> 2K17
Ты хотел сказать MMXVII?
в общем-то мне не нужы все 128 бит guid'а. все, что мне нужно - это уникальные номера только на время одного матча. поэтому я сделал просто счетчик в последний байт которого записывается ID пира (его еще надо как-то назначить). я назвал это NUID
ОП, а я хочу создать своего зловреда, который коннектится через ТОР к управляющему серверу (может менять адрес щоб не банили) и ебошил управление ВК-ботами
ну и конечно на сладкое: прокси
К чему я это? ПО ФАНУ, ХЕР ЯСЕН[/o}
Ебани какую-нибудь дарк-нет игру. Чтоб через тор
>который коннектится через ТОР
чтобы коннектиться через ТОР, нужно всего лишь коннектиться через его socks-прокси.
по техническим причинам обновлений временно не будет всем похуй
лох. пидр.
Какн ачал код писать, а не на дваче пиздеть - абасрался.
Ожидаемый финал.
STAGE 1-2 ТАДАИМА 295 дней, 13 часов, 25 минут by vylezatorstvo calculator v0.3
https://github.com/qril/moba
4 files changed, 187 insertions(+), 4 deletions(-)
АЗАЗАЗА Я ВСЕХ ЗАТРАЛЛЕЛ ЛОООООЛ!!!!!!!!!
вид человека занятого делом удручает бездельника. тут, как говорится, ничего не поделаешь. придется терпеть присутствие меня в /gd/ и кусать локти.
удалось проделать немалое, а именно пока простую рабочую обертку над NetworkTransport.
обновил vylezatorstvo calculator до версии 0.3. теперь-то надеюсь ошибок точно не будет.
добавлять его на github я не буду, потому что он не является частью прожекта. а я не знаю как удалять файлы с github (никак).
вот только на выходных в самом деле не будет обновлений. командировка.
такие дела.
https://github.com/qril/moba
4 files changed, 187 insertions(+), 4 deletions(-)
АЗАЗАЗА Я ВСЕХ ЗАТРАЛЛЕЛ ЛОООООЛ!!!!!!!!!
вид человека занятого делом удручает бездельника. тут, как говорится, ничего не поделаешь. придется терпеть присутствие меня в /gd/ и кусать локти.
удалось проделать немалое, а именно пока простую рабочую обертку над NetworkTransport.
обновил vylezatorstvo calculator до версии 0.3. теперь-то надеюсь ошибок точно не будет.
добавлять его на github я не буду, потому что он не является частью прожекта. а я не знаю как удалять файлы с github (никак).
вот только на выходных в самом деле не будет обновлений. командировка.
такие дела.
>придется терпеть присутствие меня в /gd/ и кусать локти
Единственное, что меня бесит в тебе, это сраная Томо. Обычно, люди которые носят эту аватарку это гондоны ебучие.
>Единственное, что меня бесит в тебе, это сраная Томо. Обычно, люди которые носят эту аватарку это гондоны ебучие.
Кто ж по твоему самая няшная аниме-аватарка тогда?
распидорас, ты чтоли?
Все противные. Никогда не встречал приятного персонажа в аниме. Всё наполнено какими-то извращугами, цундурами, дурами, говном, гробом, кладбищем, пидором.
Просто ты смотрел мало аниме. Вангую в тебе сериалодауна.
Какая няшечка. Ей сейчас под 30?
я в КОМ-АНД-ИРОВКЕ, но мое дело живет.
разработал простую модель передачи сообщения, которую попробую сделать на следующей недели.
в общем-то я еще тут подумал, и решил что в принципе сделать АВТОРИТЕТНЫЙ (по терминологии epic games, то есть такой, который принимает все решения по игре) сервер не так и сложно. в принципе нужно просто для каждого объекта разделить логику на ту, которая выполняется на сервере и на ту, которая выполняется на клиенте. а потом с помощью сообщений как-либо вызывать на сервере у этого объекта серверную логику (например, просто указывать координаты движения для юнита в стратегии, и уже только на серверной части происходит перемещение этого юнита). потом сервер просто в сообщениии все рассылает состояния всех объектов и все клиенты обновляют состояния своих объектов и клиентская логика потом перемещает объект/итерполирует и все такое.
это кажется даже проще, или как минимум не сложнее того, что я хотел сделать как p2p.
я уже обосрался один раз (как обычно) с терминологией. да и вообще какой-то единственной терминологии толком не существует. поэтому чтобы не путаться, вот к каким 3 типам мультиплеера я пришел:
1. DEDICATED AUTHORITATIVE SERVER - это сервер запущенный на известном публичном IP адресе и постоянно доступный (как dota 2, overwatch и т.д.). в данном конкретном случае отношения клиент/сервер означают то, что клиент отправляет свои игровые команды серверу и просит у сервера обновленное состояние игрового мира, которое сервер вычисляет применяя в игре команды клиента.
2. P2P LISTEN AUTHORITATIVE SERVER - это сервер (из пред. пункта) создаванный только в игре самим игроком, в тот момент когда он "хостит" игру (это как в старых играх). такие сервера тоже часто называют p2p, но вообще говоря они p2p не являются. мультиплеер FOR HONOR например называют p2p, хотя он им не является.
3. ПРОСТО P2P - это игра без АВТОРИТЕТНОГО сервера, где каждый пир сам приниамет все решения и сам обновляет свои объекты и синхронизируют их состояние. не обязательно в p2p-игре чтобы все ПИРЫ БЫЛИ ПОДКЛЮЧЕНЫ КО ВСЕМ ПИРАМ КАК В ТОРРЕНТЕ ИНАЧЕ НИЩИТОВА. суть p2p применительно к играм скорее в том, что между пирами распределено вычисление игрового состояния. p2p-игра может использовать relay server. причем это может быть как отдельный сервер, так и один из пиров может сам выступать в роли такого сервера.
4. RELAY SERVER - это клиент/сервер который в данном конкретном случае грубо значит следующее: клиент отправляет сообщение серверу и просит его переслать каким-то другим подключенным к этому серверу клиентам. такие серверы часто применяются (чтобы игроки могли всегда подключаться к серверу без ОТКРЫТЫХ ПОРТОВ) вместе с серверами матчмейкинга для LISTEN SERVER'ов.
такие дела.
разработал простую модель передачи сообщения, которую попробую сделать на следующей недели.
в общем-то я еще тут подумал, и решил что в принципе сделать АВТОРИТЕТНЫЙ (по терминологии epic games, то есть такой, который принимает все решения по игре) сервер не так и сложно. в принципе нужно просто для каждого объекта разделить логику на ту, которая выполняется на сервере и на ту, которая выполняется на клиенте. а потом с помощью сообщений как-либо вызывать на сервере у этого объекта серверную логику (например, просто указывать координаты движения для юнита в стратегии, и уже только на серверной части происходит перемещение этого юнита). потом сервер просто в сообщениии все рассылает состояния всех объектов и все клиенты обновляют состояния своих объектов и клиентская логика потом перемещает объект/итерполирует и все такое.
это кажется даже проще, или как минимум не сложнее того, что я хотел сделать как p2p.
я уже обосрался один раз (как обычно) с терминологией. да и вообще какой-то единственной терминологии толком не существует. поэтому чтобы не путаться, вот к каким 3 типам мультиплеера я пришел:
1. DEDICATED AUTHORITATIVE SERVER - это сервер запущенный на известном публичном IP адресе и постоянно доступный (как dota 2, overwatch и т.д.). в данном конкретном случае отношения клиент/сервер означают то, что клиент отправляет свои игровые команды серверу и просит у сервера обновленное состояние игрового мира, которое сервер вычисляет применяя в игре команды клиента.
2. P2P LISTEN AUTHORITATIVE SERVER - это сервер (из пред. пункта) создаванный только в игре самим игроком, в тот момент когда он "хостит" игру (это как в старых играх). такие сервера тоже часто называют p2p, но вообще говоря они p2p не являются. мультиплеер FOR HONOR например называют p2p, хотя он им не является.
3. ПРОСТО P2P - это игра без АВТОРИТЕТНОГО сервера, где каждый пир сам приниамет все решения и сам обновляет свои объекты и синхронизируют их состояние. не обязательно в p2p-игре чтобы все ПИРЫ БЫЛИ ПОДКЛЮЧЕНЫ КО ВСЕМ ПИРАМ КАК В ТОРРЕНТЕ ИНАЧЕ НИЩИТОВА. суть p2p применительно к играм скорее в том, что между пирами распределено вычисление игрового состояния. p2p-игра может использовать relay server. причем это может быть как отдельный сервер, так и один из пиров может сам выступать в роли такого сервера.
4. RELAY SERVER - это клиент/сервер который в данном конкретном случае грубо значит следующее: клиент отправляет сообщение серверу и просит его переслать каким-то другим подключенным к этому серверу клиентам. такие серверы часто применяются (чтобы игроки могли всегда подключаться к серверу без ОТКРЫТЫХ ПОРТОВ) вместе с серверами матчмейкинга для LISTEN SERVER'ов.
такие дела.
план работы:
STAGE 1 NETWORKING (2 мес.)
STAGE 2 PROTOTYPING (2 мес.)
STAGE 3 GAMEPLAYING (2 мес.)
STAGE 4 CONTENTING (2 мес.)
STAGE 4 RELEASING (2 мес.)
STAGE 1 NETWORKING (2 мес.)
STAGE 2 PROTOTYPING (2 мес.)
STAGE 3 GAMEPLAYING (2 мес.)
STAGE 4 CONTENTING (2 мес.)
STAGE 4 RELEASING (2 мес.)
я совсем забыл рассказать что за игру я делаю.
хочу сделать игру в жанре RETRO MOBA, где чемпионами являются персонажи из культовых 8-битных игор.
хочу сделать игру в жанре RETRO MOBA, где чемпионами являются персонажи из культовых 8-битных игор.
Пиздец ты наворотил.
На одной стороне:
socket.connect();
socket.send();
socket.receive();
На другой стороне:
socket.accept();
socket.receive();
socket.send();
И все, клиент-сервер готов.
живой человек в тренде!
это все вообще-то делает NetworkTransport. и даже больше.
условно говоря "каналы" являются обработчиками полученных сырых данных и просто передают эти данные в уже более понятном виде игровым объектам на сцене.
на самом деле все просто.
>клиент-сервер готов
если ты думаешь что просто передачи массива байтов достаточно чтобы сделать игру, то ты, мягко говоря, заблуждаешься.
>если ты думаешь что просто передачи массива байтов достаточно чтобы сделать игру, то ты, мягко говоря, заблуждаешься
у татрикса же получилось
из бинарных данных достаточно парсить объек-события, навроде {type: "spawn", data: {type: "char1", position: [0, 0, 0]}} - событийно-ориентрованная архитектура и сеть созданы друг для друга
>из бинарных данных достаточно парсить объек-события, навроде {type: "spawn", data: {type: "char1", position: [0, 0, 0]}} - событийно-ориентрованная архитектура и сеть созданы друг для друга
STAGE 1-2 ТАДАИМА прошло 0 месяцев 1 неделя 0 дней 0 часов 21 минута, a осталось 292 дня, 23 часа, 38 минут by vylezatorstvo calculator v0.4
обновил vylezatorstvo calculator до версии 0.4. теперь он показывает не только оставшееся, но и прошедшее с момента начала время.
сделал модель как объекты обмениваются сообщениями друг с другом.
я хочу сделать в PeerComponent не просто захардкоженную обработку сообщения от NetworkTransport, а что-то вроде стека обработчиков сообщений. то есть любой компонент может добавить свой обработчик (можно указать номер сортировки, чем меньше номер, тем первее будет вызываться этот обработчик) и делать с сообщением что угодно, даже отменить его!
отменять их нужно для матчмейкинга больше всего, чтобы, например, не разрешать подключения пиров которых нет в списке матча. сейчас подключиться может вообще кто угодно. даже небо, даже аллах.
ну это понятно. тут подводные камни другого рода и они не связаны с технической стороной сетевого соединения.
например, как реализовать ИГРОВОЙ ПРОТОКОЛ: создать матч, а потом отслеживать состояние матча, а потом начинать игру и отслеживать ее состояния и т.д.
обновил vylezatorstvo calculator до версии 0.4. теперь он показывает не только оставшееся, но и прошедшее с момента начала время.
сделал модель как объекты обмениваются сообщениями друг с другом.
я хочу сделать в PeerComponent не просто захардкоженную обработку сообщения от NetworkTransport, а что-то вроде стека обработчиков сообщений. то есть любой компонент может добавить свой обработчик (можно указать номер сортировки, чем меньше номер, тем первее будет вызываться этот обработчик) и делать с сообщением что угодно, даже отменить его!
отменять их нужно для матчмейкинга больше всего, чтобы, например, не разрешать подключения пиров которых нет в списке матча. сейчас подключиться может вообще кто угодно. даже небо, даже аллах.
ну это понятно. тут подводные камни другого рода и они не связаны с технической стороной сетевого соединения.
например, как реализовать ИГРОВОЙ ПРОТОКОЛ: создать матч, а потом отслеживать состояние матча, а потом начинать игру и отслеживать ее состояния и т.д.
upd: FindObject может работать не правильно во время тестов, потому что можно найти не свой MessageChannel. придется объявлять ссылку в самом компоненте
> sendMessage
> unity
Ты открыл ящик пандоры
>YNUTI
Велосипед. Тебе не нужно ничего допиливать. Сурсы костылей лежат в открытых источниках.
Юнити, господи, ну зачем так пердолиться из-за юнити?
Еще и делать сессионную дрочильню на ней.
Еще и делать сессионную дрочильню на ней.
Да он видимо не в курсе что мультиплеер давно за него написали. Вот и сидит тут, аутирует.
возникли НЕПРЕДВИДЕННЫЕ ОСЛОЖНЕНИЯ. совсем вылетело из головы, что на объекте может быть несколько компоненетов. пришлось в цепочку PeerComponent - MessageChannel - компонент добавить еще одно звено - MessageHandler!
на самом деле это будет моя функция, просто она так называется (совпадение? не думаю)
>ну зачем так пердолиться из-за юнити?
в смысле из-за юнити? лол
я уже писал про UNET. да, на нем можно сделать бесплатно, но информации нет даже в официальной документации. не говоря уже о кирилльских туториалах. чем рабираться в юнитивском говнокоде проще написать свой.
на самом деле это будет моя функция, просто она так называется (совпадение? не думаю)
>ну зачем так пердолиться из-за юнити?
в смысле из-за юнити? лол
я уже писал про UNET. да, на нем можно сделать бесплатно, но информации нет даже в официальной документации. не говоря уже о кирилльских туториалах. чем рабираться в юнитивском говнокоде проще написать свой.
unity выгодно чтобы им платили деньги за мультиплеер, поэтому в своей документации и уроках они только рассказывают как сделать платный мультиплеер
алсо, я уже почти сделал всю функциональность UNET'а (в уме). не вижу смысла возвращаться к нему.
игровой протокол и прочую специальную игровую сетевую логику в любом случае что там, что там надо делать всю самому.
игровой протокол и прочую специальную игровую сетевую логику в любом случае что там, что там надо делать всю самому.
Долбоеб, на сетевые движки тратятся года, если не десятки.
Бери готовое решение и не выебывайся.
Год. В соло. Где твой путин теперь?
STAGE 1-2 ТАДАИМА прошло 0 месяцев 1 неделя 0 дней 13 часов 22 минуты, a осталось 292 дня, 10 часов, 37 минут by vylezatorstvo calculator v0.4
сегодня ровно в час ночи по московскому времени впервые в истории была осуществлена успешная передача сообщения между peer 1 и peer 2! данное событие транслировалось по всему /gd/ и все не могли нарадоваться этому успеху.
сегодня ровно в час ночи по московскому времени впервые в истории была осуществлена успешная передача сообщения между peer 1 и peer 2! данное событие транслировалось по всему /gd/ и все не могли нарадоваться этому успеху.
>на сетевые движки тратятся года, если не десятки
настало время охуительных историй.жпг
как видно компонент почти не отличается от прототипа
теперь допили десериализацию и dispatch(event.data) с on(event.data.type, callable) и движок готов
хуевая задумка с какими-то ид скриптов, лучше делай типы сообщений на которые отдельно любые скрипты могут подписываться. очевидны й пример, когда сообщение должны обработать несолько скриптов или объектов и т.п. не с той стороны аритектируешь, очевидный ньюфаг без опыта очевиден
>хуевая задумка с какими-то ид скриптов
ну вообще у меня изначально была идея как-раз не использовать ID, а просто рассылать сообщения сразу всем компонентам на объекте, и в каждом уже проверяется для него это сообщение или нет.
ну мне это показалось как-то неудобно с моим текущим видом сообщением (просто голый массив с данными и сорт оф BinaryReader). т.е. в каждом компоненте нужно будет вставлять одну и ту же проверку (if (message.ReadInt() == MESSAGE_FROM_MYSCRIPT1)), заводить кучу констант с типом сообщения и т.д.
не хочу ничего усложнять и придумывать еще протоколы сообщений
хотя в принципе я для этого MessageChannel и делал. что-то я запутался.
>любые скрипты могут подписываться. очевидны й пример, когда сообщение должны обработать несолько скриптов или объектов
сообщения тут значат не event'ы в обычном понимании, а скорее репликацию данных. компоненты ни на что не могут подписаться, потому что они, грубо говоря, просто отправляют сообщения (реплицируют какие-то произвольные данные) самим себе, только у других пиров.
это можно использовать для репликации данных, для RPC и всего остального.
>очевидный ньюфаг без опыта очевиден
так я и не говорил, что я гуру сетевого программирования. я вообще первый раз хочу сделать.
только в 100 раз хуже. я вообще хотел просто спиздить спрайты из старых игор.
можно сделать обычный диспетчер сообщений состояние которого реплицируются. только не понимаю зачем это нужно.
ну или я если вообще что-то делаю не правильно, то расскажите как это делается в нормальных игорях
потому и нужен event.type, ты ничего лучшего уже существующего не изобретешь, можно и респонсибилити чейны делать (рассылать сразу всем), просто парсить бинарь в структуру перед доставкой, ну же
а для ифов можно свой сахар изобрести, обертки высшего порядка
only = function (type, handler) { return function (event) { if event.type == type { return handler(event) } }
only("spawn", function (event) { <proceed-spawn-mesage> })
пиздец открываешь любой eventemitter eventdispatcher и т.п. на гитхабе, к dispatch(fire/trigger) биндишь socker.receive |> JSON.parse |> dispatch(event.type, event)
ты поймиу тебя не с тем проблема чтоб сообщение обрабатывать, ос-но если игра рилтаймовая, ты прототип хоть прямыми вызовами функций запили, похуй, ты потом увидишь
STAGE 1-3 BLASTER KALOBOK ONLINE прошло 0 месяцев 1 неделя 1 день 6 часов 58 минут, a остался 291 день, 17 часов, 1 минута by vylezatorstvo calculator v0.4
трудно делать непонятно что без задач. лучше на очень простом прототипе, столкнувшись с настоящими задачи, их решить и все допилить.
поэтому я решил сделать очень простой джва де сетевой прототип игры BLASTER KALOBOK ONLINE. вот ее правила:
1. вначале на выбор 2 опции: быть хостом и подключиться
2. если ты хост, то ты сразу попадаешь в игру. все остальные сразу подключаются в игру.
3. все пули создает и управляет ими игрок который стреляет. он также определяет убил он кого-то или нет.
4. если игрока убили, он просто перемещается в начальную точку.
5. выводятся сообщения о подключении/отключении и убийстве.
трудно делать непонятно что без задач. лучше на очень простом прототипе, столкнувшись с настоящими задачи, их решить и все допилить.
поэтому я решил сделать очень простой джва де сетевой прототип игры BLASTER KALOBOK ONLINE. вот ее правила:
1. вначале на выбор 2 опции: быть хостом и подключиться
2. если ты хост, то ты сразу попадаешь в игру. все остальные сразу подключаются в игру.
3. все пули создает и управляет ими игрок который стреляет. он также определяет убил он кого-то или нет.
4. если игрока убили, он просто перемещается в начальную точку.
5. выводятся сообщения о подключении/отключении и убийстве.
в этом смысле у меня каналы выполняют роль как-раз таких диспатчеров. просто у меня нет сразу же сериализации/десериализации сообщений, а передается просто BinaryReader.
может и можно сделать серализацию. только не все так просто как жс мирке. C# это поле боя.
ебать ты далбаеб, посмотри диспатчер событий из zope писюна, там пакет event это, цитирую (мощнейшая система событий в описании):
events = []
listen = events.append
def dispatch(event): for h in events: h(event)
в жс мирок все пришло из крестов, поле боя ты ане кресты, просто далбаеб и не можешь смириться что все до тебя спроектировано. хватай камни и костыли имбицил, отпишусь пожалуй
да ты надоел. ды даже не понял что мне нужно. я уже сто раз написал, что СЕТЕВОЕ сообщение получает ТОЛЬКО компонент, который его отправил. у меня не event'ы.
у меня простоый dictionary по сетевому ID. мне не надо, чтобы сообщение получали вася, петя или хуй. мне надо чтобы сообщение получал только объект с таким-же ID, как ID объекта который его отправил.
ты меня обвиняешь в том, что я СПРОЕКТИРОВАЛ словарь. ну охуеть теперь.
короче идите нахуй. ничего лучше SendMessage еще не придумали. в самом деле, зачем изобретать велосипеды, если есть замечательный SendMessage
STAGE 1-3 BLASTER KALOBOK ONLINE прошло 0 месяцев 1 неделя 2 дня 9 часов 46 минут, a осталось 290 дней, 14 часов, 13 минут by vylezatorstvo calculator v0.4
итак, начнем же разработку BLASTER KALOBOK ONLINE. начнем с самого начала: игрок выбирает быть хостом и попадает в игру. на самом деле в этот момент происходит создание сетевого объекта игрока. как это сделать.
к сожалению уже существующие компоненты не способны сами справится с этой задачей. они являются базисом, корнями на которых должно вырасти дерево будущей игры. для этого нам нужная серия brand new компонентов.
и начнется это серия с компонента NetworkInstantiate. как видно из названия, это instantiate (создание объекта) по network (net = work рабочяя сеть). логично.
сначала попытаемся проанализировать, как-же создаются объекты в UNET https://bitbucket.org/Unity-Technologies/networking/src/78ca8544bbf4e87c310ce2a9a3fc33cdad2f9bb1/Runtime/NetworkServer.cs?at=5.3&fileviewer=file-view-default#NetworkServer.cs-1314:
1. сначала нужно создать объект обычными средствами и иницилиазировать его, если к этому лежит душа.
2. потом нужно вызвать фунецию spawn.
3. эта функция сериализует все компоненты объекта и отправит эти данные вместе с сообщением о создании предмета
4. где-то там еще нужно указать массив создаваемых по сети предметов, и по сети передается 128-битный hash этого предмета, этот предмет находится и затем создается, и все данные десериализуются обратно.
очевидно, что с текущей децентрализованной системой каналов обработчиков сообщений от каналов не все так просто. нельзя просто так взять и сериализовать все данные, потому что мы не знаем, какие есть вообще данные.
я пошутил. достаточно просто создать ReplicationHandler компонент (все эти компоненты имеют приставку handler, потому что они являются обработчиками сообщений от каналов) и сериализовать/обратно через него все что должно реплицироваться не только через канал, но и через публичный интерфейс.
spawn'ить буду просто заполнив массив объектов в NetworkInstantiate и указывая индекс объекта в массиве в сообщении. все просто.
итак, начнем же разработку BLASTER KALOBOK ONLINE. начнем с самого начала: игрок выбирает быть хостом и попадает в игру. на самом деле в этот момент происходит создание сетевого объекта игрока. как это сделать.
к сожалению уже существующие компоненты не способны сами справится с этой задачей. они являются базисом, корнями на которых должно вырасти дерево будущей игры. для этого нам нужная серия brand new компонентов.
и начнется это серия с компонента NetworkInstantiate. как видно из названия, это instantiate (создание объекта) по network (net = work рабочяя сеть). логично.
сначала попытаемся проанализировать, как-же создаются объекты в UNET https://bitbucket.org/Unity-Technologies/networking/src/78ca8544bbf4e87c310ce2a9a3fc33cdad2f9bb1/Runtime/NetworkServer.cs?at=5.3&fileviewer=file-view-default#NetworkServer.cs-1314:
1. сначала нужно создать объект обычными средствами и иницилиазировать его, если к этому лежит душа.
2. потом нужно вызвать фунецию spawn.
3. эта функция сериализует все компоненты объекта и отправит эти данные вместе с сообщением о создании предмета
4. где-то там еще нужно указать массив создаваемых по сети предметов, и по сети передается 128-битный hash этого предмета, этот предмет находится и затем создается, и все данные десериализуются обратно.
очевидно, что с текущей децентрализованной системой каналов обработчиков сообщений от каналов не все так просто. нельзя просто так взять и сериализовать все данные, потому что мы не знаем, какие есть вообще данные.
я пошутил. достаточно просто создать ReplicationHandler компонент (все эти компоненты имеют приставку handler, потому что они являются обработчиками сообщений от каналов) и сериализовать/обратно через него все что должно реплицироваться не только через канал, но и через публичный интерфейс.
spawn'ить буду просто заполнив массив объектов в NetworkInstantiate и указывая индекс объекта в массиве в сообщении. все просто.
бамп во имя опа
блин, найти бы почему у меня вебмки не сохраняются полностью бы
блять оп какой-то ебанутый, что он городит нахуй
пиздец ты даун, ты просто малолетний далбаб который не постиг еще дзен. нет никаких сетевых сообщений и никаких ид компонента, сложно сделать просто, и ты не можешь этого сделать, это тебя выдает, твой взгляд замылен а чсв задрано как у любого ламера, и когда ты видишь праведный правильный код у тебя бомбит, потому ЧТО НЕ МОЖЕТ ВСЕ ТАК БЫТЬ АЗАЗАЗ ПОЛЕ БИТВЫ Я ВЕЛИКЕ ОНоТОЛЕ и типа такого, какие-то блять объекты приплел, какие-то словари. ты не можешь нормально через элементарные структуры выразить свою архитектуру, плодишь сущности 9кал анус жопа) и прочую хуйню тут пишешь. исправляйся либо отпис и рефанд донатов. исправляйся мудило.
ладно бы ты еще свои термины придумывал, но ты берешь паттерны и перекраиваешь, вырываешь кусочки функциональности и сшиваешь между собой, нарушая все догмы СОЛИДа и проч и подобн
НАНИ
да ты никак не поймешь. вот смотри, когда ты отправляешь сообщение в /gd/, у него нет адресата. это событие, которое может прочитать кто угодно. а когда ты пишешь письмо, его должен получить только один, поэтому ты указываешь АДРЕС. это не является событием.
> у него нет адресата. это событие
>поэтому ты указываешь АДРЕС. это не является событием
А почему не BLASTER KALOBOK JOURNEY(TRAVEL)?
никогда, слышите, НИКОГДА не сохраняйте ссылки на юнити-объекты в статических переменных.
upd: это кажется не из-за этого unity у меня весь день крашится. суть в том, что в NetworkMessage есть инициализированный IntPtr. и все нормально, пока использовать ссылки на NetworkMessage только в локальных переменных. но если ее объявить в классе наследованном от MonoBehaviour, то юнити начинает пидорасить.
Как видно, сериализация отличается такой же лаконичностью как и отправка сообщений. Всего-лишь нужно релизовать интерфейс.
Такой гибкости нет даже в unity. Этот тот случай, когда ученик превзошел мастера!
Такой гибкости нет даже в unity. Этот тот случай, когда ученик превзошел мастера!
пиздец ты ебанутый. отписка и рефаунд.
ебать ты дебил, я тебе пол треба уже пидорашу что с АДРЕСОМ архитектура ХУЕВАЯ ты пока мечтаешь какой ты кудах пиздатый леер тут хуяришь, но ты начни сверху проектировать и убедишься что чейновая архитектура для сообщений лучше всех а случай с адресом это просто рПЦ какой-то блять но никак не события, короче, жаль дальше время тратить на этого уебка, он испекся. пойду своим проектом займусь, скоро тред запилю котаны, держитесь там
>у тебя плохие события
>но у меня нет никаких событий
>нет, у тебя плохие плохие события. я тебе пол треба уже пидорашу что с АДРЕСОМ архитектура ХУЕВАЯ
ты вообще читаешь что я пишу?
ну вот я сериализовал данные компонента, и куда мне их ОПУБЛИКОВАТЬ теперь: в анус тебе штоле, или на двач?
"слушайте все, вот тут от пира 1 пришли какие-то данные. забирайте кому нужно"
как вообще объект поймет что эти данные предназначены ему? и зачем эти данные кому-то еще?!
>пойду своим проектом займусь, скоро тред запилю котаны, держитесь там
иди займись. может хоть тогда поймешь, что адреса нужны
STAGE 1-3 BLASTER KALOBOK ONLINE прошло 0 месяцев 1 неделя 4 дня 3 часа 12 минут, a осталось 288 дней, 20 часов, 47 минут by vylezatorstvo calculator v0.4
запилил создание объектов по сети.
всплыла неожиданная проблема: непонятно как определять ID объектов изначально находящихся на сцене. невозможно предсказать порядок в котором unity будет вызывать функции старта на компонентах.
единственное пока решение: это начинать считать ID с большого числа (чтобы не было коллизии), а объектам на сцене указать все ID вручную.
по настойчивым просьбам поклонников моего творчества я запилил EventChannel. в отличие от MessageChannel, который посылает сообщения по адресу, первый рассылает сообщение вообще всем подписчикам.
зачем это нужно, спросите вы: а хуй его знает ну так можно посылать все сообщения, которые не требуют адресата. это может быть полезно на стадии ИГРОВОГО ПРОТОКОЛА.
а вот и наконец-то наступила эта стадия! я пытался спиздить посмотреть как сделано в unity, но там такой лютый говнокод, что проще все сделать самому. чем мы сейчас и займемся.
очевидно, нужен какой-то компонент, который должен вести состояния подключения всех игроков. нельзя просто так взять и начать посылать сообщения сразу после подключения как ни в чем не бывало.
так, например, не нужно, чтобы игрок только подключившийся к игре и еще не получивший ID и состояния сцены, получал сообщения от объектов, которых у него просто нет.
но как не передавать сообщения. сейчас передача сообщения устроена очень просто: сообщение из канала просто рассылается всем подключениям из списка. но если не добавлять подключение в список, то вся система не будет "видеть" это подключение и просто не будут работать все каналы. а я как-раз использовать каналы для протокола.
лучше всего блокировать сообщения от отдельных каналов и сделать ПРОТОКОЛЬНЫЙ КАНАЛ. то есть подключение с состоянием CONNECT будут отправлять только сообщения из протокольного канала. все просто.
какие состояния могут быть у игрока вообще:
1. CONNECT - игрок только что подключился. нужно блокировать все кроме ПРОТОКОЛЬНЫХ СООБЩЕНИЙ. хост в этот момент посылает ID пира и ID текущей сцены. игрок загружает эту сцену.
2. READY - игрок загрузил сцену. теперь он должен получать все сообщения. ему просто отправляются сообщения SPAWN для всех сетевых объектов на сцене в настоящее время. игрок сам создает свой объект и уже само отправляет SPAWN.
очевидно, что такая сеть мало подходит для ПРОДАКШЕНА, потому что любой игрок может подделать сообщения и отправлять их от имени другого игрока, или начать спамить сообщение SPAWN создавая тысячи объектов, или отправлять сообщение что он всех убил.
а даже если делать клиент/сервер с сервером создаваемым игроком, то эта проблема не решается полностью. только вместо любого игрока, подделывать сообщения может только сервер.
такие дела.
запилил создание объектов по сети.
всплыла неожиданная проблема: непонятно как определять ID объектов изначально находящихся на сцене. невозможно предсказать порядок в котором unity будет вызывать функции старта на компонентах.
единственное пока решение: это начинать считать ID с большого числа (чтобы не было коллизии), а объектам на сцене указать все ID вручную.
по настойчивым просьбам поклонников моего творчества я запилил EventChannel. в отличие от MessageChannel, который посылает сообщения по адресу, первый рассылает сообщение вообще всем подписчикам.
зачем это нужно, спросите вы: а хуй его знает ну так можно посылать все сообщения, которые не требуют адресата. это может быть полезно на стадии ИГРОВОГО ПРОТОКОЛА.
а вот и наконец-то наступила эта стадия! я пытался спиздить посмотреть как сделано в unity, но там такой лютый говнокод, что проще все сделать самому. чем мы сейчас и займемся.
очевидно, нужен какой-то компонент, который должен вести состояния подключения всех игроков. нельзя просто так взять и начать посылать сообщения сразу после подключения как ни в чем не бывало.
так, например, не нужно, чтобы игрок только подключившийся к игре и еще не получивший ID и состояния сцены, получал сообщения от объектов, которых у него просто нет.
но как не передавать сообщения. сейчас передача сообщения устроена очень просто: сообщение из канала просто рассылается всем подключениям из списка. но если не добавлять подключение в список, то вся система не будет "видеть" это подключение и просто не будут работать все каналы. а я как-раз использовать каналы для протокола.
лучше всего блокировать сообщения от отдельных каналов и сделать ПРОТОКОЛЬНЫЙ КАНАЛ. то есть подключение с состоянием CONNECT будут отправлять только сообщения из протокольного канала. все просто.
какие состояния могут быть у игрока вообще:
1. CONNECT - игрок только что подключился. нужно блокировать все кроме ПРОТОКОЛЬНЫХ СООБЩЕНИЙ. хост в этот момент посылает ID пира и ID текущей сцены. игрок загружает эту сцену.
2. READY - игрок загрузил сцену. теперь он должен получать все сообщения. ему просто отправляются сообщения SPAWN для всех сетевых объектов на сцене в настоящее время. игрок сам создает свой объект и уже само отправляет SPAWN.
очевидно, что такая сеть мало подходит для ПРОДАКШЕНА, потому что любой игрок может подделать сообщения и отправлять их от имени другого игрока, или начать спамить сообщение SPAWN создавая тысячи объектов, или отправлять сообщение что он всех убил.
а даже если делать клиент/сервер с сервером создаваемым игроком, то эта проблема не решается полностью. только вместо любого игрока, подделывать сообщения может только сервер.
такие дела.
upd: я решил не использовать назначемый хостом ID для пира. так как это противоречит принципам P2P. вместо этого я буду использовать MAC-адрес. а чтобы размер сообщений намного не увеличился из-за большого адреса, я буду отправлять адрес отдельно, а счетчик отдельно (суть в том, что сообщения в канале на самом деле слаживаются и отправляются пачками в определенные промежутки времени). а у получившего пира уже соответственно слаживать их вместе и получать ID (адрес) объекта.
таким образом каждое сообщение увеличится всего на 6 байт.
>то чувство, когда у твоего треда больше не осталось подписчиков
А кому может быть интересно смотреть на вертящиеся красные кубы?
Остался ебучий школодаун ничего не понимающей в кодинге
Я
>А кому может быть интересно смотреть на вертящиеся красные кубы?
Тебе нужно игру пилить или вниманиеблядствовать? Ты то простыни шьешь, то велосипеды крутишь, то блевотные картинки из анимэ постишь. Пили уже игоря, доебал.
STAGE 1-3 BLASTER KALOBOK ONLINE прошло 0 месяцев 1 неделя 6 дней 5 часов 33 минуты, a осталось 286 дней, 18 часов, 26 минут by vylezatorstvo calculator v0.4
чет я обосрался от того, что несколько вращаюхся кубов высирают слишком много килобайт траффика, а я еще даже не начинал делать игру. поэтому я решил использовать сжатие.
естественно, я не идиот и не хочу использовать что-то написаное на C# (вроде Ionic.Zlib), потому что это все будет работать в древнем как говно мамонта mono, который в свою очередь работает в unity. что приведет к низкой производительности.
единственным верным решением в этом случае является использование PInvoke (то есть вызывать функции из DLL). поэтому я решил использовать простую обертку над zlib. не нашел ни одной хорошей обертки, поэтому решил сделать свою.
надеюсь все это будет работать в unity.
такие дела.
чет я обосрался от того, что несколько вращаюхся кубов высирают слишком много килобайт траффика, а я еще даже не начинал делать игру. поэтому я решил использовать сжатие.
естественно, я не идиот и не хочу использовать что-то написаное на C# (вроде Ionic.Zlib), потому что это все будет работать в древнем как говно мамонта mono, который в свою очередь работает в unity. что приведет к низкой производительности.
единственным верным решением в этом случае является использование PInvoke (то есть вызывать функции из DLL). поэтому я решил использовать простую обертку над zlib. не нашел ни одной хорошей обертки, поэтому решил сделать свою.
надеюсь все это будет работать в unity.
такие дела.
upd: кажется я обосрался. не нужно слаживать сообщения в пачки в каналах, потому что эта функциональность уже есть в NetworkTransport. а еще unity просто крашится, если превысить размер их пакета. проблема в том, что по NetworkTransport документации кот наплакал.
продолжаю разбираться дальше.
STAGE 1-3 BLASTER KALOBOK ONLINE[/s/ OUT прошло 0 месяцев 2 недели 1 день 3 часа 15 минут, a осталось 284 дня, 20 часов, 44 минуты by vylezatorstvo calculator v0.4
разработал и запантетовал самый компактный алгоритм сжатия кватерниона в мире. 16 байт сохраняются в 4 байта. правда у градусов теряются дробные части. но кому они нужны, точности в один градус более чем достаточно для любой сетевой игры.
всего лишь 100 вращающихся кубов (vector3 + вращение) со скоростью 5 сообщений в секунду занимаются 11 КИЛОБАЙТ В СЕКУНДУ. это 40 МЕГАБАЙТ В ЧАС
если использовать сжатие, то 8 КИЛОБАЙТ В СЕКУНДУ, это 28 МЕГАБАЙТ В ЧАС
маленькие сообщения которые отправляются мгновенно (например, сообщения о попадании) я сжимать не буду естественно.
проблема в том, что я даже не знаю нужно ли мне делать сжатие, или оно уже есть в NetworkTransport. а если его нет, то мне придется оставить буферизацию сообщений, чтобы сделать более эффективное сжатие.
короче, пока оставлю все как есть.
осталось сделать FRONTEND
разработал и запантетовал самый компактный алгоритм сжатия кватерниона в мире. 16 байт сохраняются в 4 байта. правда у градусов теряются дробные части. но кому они нужны, точности в один градус более чем достаточно для любой сетевой игры.
всего лишь 100 вращающихся кубов (vector3 + вращение) со скоростью 5 сообщений в секунду занимаются 11 КИЛОБАЙТ В СЕКУНДУ. это 40 МЕГАБАЙТ В ЧАС
если использовать сжатие, то 8 КИЛОБАЙТ В СЕКУНДУ, это 28 МЕГАБАЙТ В ЧАС
маленькие сообщения которые отправляются мгновенно (например, сообщения о попадании) я сжимать не буду естественно.
проблема в том, что я даже не знаю нужно ли мне делать сжатие, или оно уже есть в NetworkTransport. а если его нет, то мне придется оставить буферизацию сообщений, чтобы сделать более эффективное сжатие.
короче, пока оставлю все как есть.
осталось сделать FRONTEND
рядовой йоба получил свой первый автомат!
STAGE 1-3 BLASTER KALOBOK ONLINE / OUT прошло 0 месяцев 2 недели 2 дня 10 часов 33 минуты, a осталось 283 дня, 13 часов, 26 минут by vylezatorstvo calculator v0.4
пш-ш. это рядовой йоба.
с наивной ИНТЕРПОЛЯЦИЕЙ возникли проблемы (в конце). а именно йоба опаздывает и из-за опоздания может застрять.
пш-ш.
пш-ш. это рядовой йоба.
с наивной ИНТЕРПОЛЯЦИЕЙ возникли проблемы (в конце). а именно йоба опаздывает и из-за опоздания может застрять.
пш-ш.
вообще-то у меня даже не интерполяция, а просто функция движения, которая принимает точку куда идти.
> прошло 2 недели
Думал я один так долго прототипы пилю
ну я можно сказать еще ничего не пилил, а просто разбирался в теории, так сказать.
>Думал я один так долго прототипы пилю
весь /gd/ - её прототип
upd: сделал самую простую интерполяцию за фиксированное время, которое сбрасывается при получении нового сообщения. а застревания решил кардинальным способом - двигая объекты через transform.position
STAGE 1-3 BLASTER KALOBOK ONLINE / OUT прошло 0 месяцев 2 недели 3 дня 5 часов 10 минут, a осталось 282 дня, 18 часов, 49 минут by vylezatorstvo calculator v0.4
сегодня впервые в истории моей разработки между хостом и пиром произошел HANDSHAKE.
слева хост, а справа пир. как видно, сначала справа ничего нету. но пир отправляет SYN сообщение. хост его добавляет в список и отправляет SYN-ACK со всеми сетевыми объектами. пир их воссоздает и отправляет ACK.
сегодня впервые в истории моей разработки между хостом и пиром произошел HANDSHAKE.
слева хост, а справа пир. как видно, сначала справа ничего нету. но пир отправляет SYN сообщение. хост его добавляет в список и отправляет SYN-ACK со всеми сетевыми объектами. пир их воссоздает и отправляет ACK.
Мне не нравится. Безвкусно.
что не нравитяс
деревья трясутся посколько боятся того что их выебут
Кто рисовал?
OverCute-кун
Лолд
Где ещё можно посмотреть его творчество?
STAGE 1-3 BLASTER KALOBOK ONLINE / OUT прошло 0 месяцев 3 недели 2 дня 5 часов 24 минуты, a осталось 276 дней, 18 часов, 35 минут by vylezatorstvo calculator v0.4
бамп мертвому треду.
нечего показывать, а мою писанину все равно никто не читает.
сейчас экспериментирую с разными всякими вещами. вот, запилил свои промисы для сообщений типа запросов-ответов. только я знаю, что лямбды в C# это просто синтаксический сахар, и на самом деле они сделаны через костыли с созданием новых объектов. вряд ли буду их использовать.
да и вообще что-то пропало желание писать на мертвой доске. даже мой великолепный трхеад не смог оживить ее. есть ли нужда пинать труп.
бамп мертвому треду.
нечего показывать, а мою писанину все равно никто не читает.
сейчас экспериментирую с разными всякими вещами. вот, запилил свои промисы для сообщений типа запросов-ответов. только я знаю, что лямбды в C# это просто синтаксический сахар, и на самом деле они сделаны через костыли с созданием новых объектов. вряд ли буду их использовать.
да и вообще что-то пропало желание писать на мертвой доске. даже мой великолепный трхеад не смог оживить ее. есть ли нужда пинать труп.
да, уеюывай скорее, здесь люди делом занимаются а не велосипеды вроде СОВИХ ПРОМИСОВ хуярят
у тебя есть лучше предложения как сделать асинхронные операции в unity.
ты вообще знаешь что это такое, людь
Через корутины же, ну.
получится абсолютно то же самое, только с пердополлингом вместо каллбэков.
алсо, промисы превращаются в корутины реализацией интерфейса IEnumerator и одной строчкой в MoveNext() { return !resolved; }
вообще я сеньер-архитект по стеку на торнадо (асинхронный пистон) года с 12-го, мань
>вообще я сеньер-архитект по стеку на торнадо (асинхронный пистон) года с 12-го, мань
как всегда самые большие подводные камни в самых неожиданных местах.
нипанятна как сделать менджмент сцен. мало того, что это самая неразвитая сторона unity, так еще нет никаких гайдлайнов или best practices. приходится каждый раз заново делать какие-то костыли.
например, надо из сцены входа в игру загрузить уровень игры. но тогда уже на уровне игры не получится просто взять и перетащить компонент в инспекторе, потому что его на этой сцене нет. приходится городить всякие синглтоны и прочие костыли
нипанятна как сделать менджмент сцен. мало того, что это самая неразвитая сторона unity, так еще нет никаких гайдлайнов или best practices. приходится каждый раз заново делать какие-то костыли.
например, надо из сцены входа в игру загрузить уровень игры. но тогда уже на уровне игры не получится просто взять и перетащить компонент в инспекторе, потому что его на этой сцене нет. приходится городить всякие синглтоны и прочие костыли
Нет. Ты просто нихуя не понимаешь.
lolol();
yeld recv();
lololo();
вместо
lolol();
Promise(recv).then( () => { lololo(); } );
Почувствуй разницу.
вот только promise по определению возвращает значение.
будет костыльно как сейчас с юнитивскими корутновыми классами
IEnumerator Start() {
// надо сначала присвоить переменной
WWW www = new WWW(url);
// потом вернуть ее
yield return www;
Renderer renderer = GetComponent<Renderer>();
// и потом уже получить значение через .texture
renderer.material.mainTexture = www.texture;
}
алсо, я же говорю что с моими промисами делается все абсолютно так-же
оказывается от туториалов на youtube есть польза. только смотреть их нужно на офффициальном канале, а не на vasyan tv или level gd лол.
https://www.youtube.com/watch?v=aq8Myv1fxBU
взял отсюда общую идею. сначала загружается контрольная сцена (game), которая уже загружает дочерние сцены (разные игровые режимы), которые уже загружают синглпеел карты или мультиплеер карты.
но и тут не все просто. нужно как-то сначала загружать сцену с интерфейсом, которая управляет игровым режимом, которые ее потом выгружает и загружает сцену игры. а потом выгружает сцену игры и загружает сцену интерфейса. причем на этой сцены надо показать результат игры!
https://www.youtube.com/watch?v=aq8Myv1fxBU
взял отсюда общую идею. сначала загружается контрольная сцена (game), которая уже загружает дочерние сцены (разные игровые режимы), которые уже загружают синглпеел карты или мультиплеер карты.
но и тут не все просто. нужно как-то сначала загружать сцену с интерфейсом, которая управляет игровым режимом, которые ее потом выгружает и загружает сцену игры. а потом выгружает сцену игры и загружает сцену интерфейса. причем на этой сцены надо показать результат игры!
Ну епта, в том то и фишка что коллбэков нет. А пердолинг у тебя в Update все равно идет с NetworkTransport.
мамкин хацкер что-ли?))
Осталось 131 дней, 15 часов, 17 минут
В общем, вдохновился я тредами двух других вниманиеблядей анонов и решил сделать свой, чтобы он меня мотивировал.
Мне надоело стоять на месте и деградировать, поэтому я решил НАПИСАТЬ ИГРУ ЗА 300 ДНЕЙ. В этом уютном бложике я буду рассказывать сам себе как проходит работа над игрой. Бампать буду фоточками Томоко.
Опыта игродела у меня по-факту нет. В погроммировании умею всего понемножку ну вы понели.