leha78: "нашей в стране без веской причины в сша не пускают)) а я слышал что программистам визу дают) "
1. Визу дают тем, в ком США сам заинтересован.
2. Приглашение с той стороны могут дать кандидату, который успешно прошел интервью и его берут на работу с релокацией. Обычно это специалист уровня не менее чем MID, потому что джуниоров своих полно, мидов много, но есть шансы. Сеньоры востребованы всегда.
3. Идея стартапа - вообще пустое место, там такие не нужны в принципе. Реализация стартапа - это уже конкретная работа. Рабочую визу получить - в 10 раз сложнее, чем туристическую.
В чем проблема пойти в посольство, попробовать сделать себе краткосрочную визу для посещения конференции или учебы на месяц-два? Многие так делают. Одним из главных условий успешного прохождения - это подтверждение платежеспособности.
Underline: Факт может заключаться в обычном взрослении.
Многие проходят этап, когда "перегорел", когда внезапно понял, что программирование - это не чудо, а просто работа.
Ну не знаю. Отпуск, отдых, регулярное хобби, спорт и снова работать.
Если у вас есть возможность переквалифицироваться без потери в ЗП - вы должны лучше знать ваши возможности.
Фаербол тоже может быть объектом, который куда-то летит. Не нужно передавать, если известно в кого он летит. Но есть же вещи которые взаимодействуют с площадью.
Всегда вся карта делится по квадратикам. С радиусом взаимодействия объектов нужно работать.
Нужно же отправлять не только про игроков, но и про NPC/MOB/items - все объекты.
Создаете для каждого клиента список объектов и поддерживаете его актуальным. Когда доходит время до отправки информации клиенту, по этому списку и пробегаетесь, смотрите что критично отправлять, что можно в следующий раз.
Выбираете какие действия могут обновлять список (например передвижение должно проверять что можно добавить/выкинуть).
К сожалению, у меня реального опыта разработки такого уровня не было. Я в детстве MUD писал, и чуть позже участвовал в разработке одного из java-серверов линейки, но больше как админ а не дев.
Просто был немного в курсе основных проблем и нагрузки.
Padaboo: Какой-то игрок подключился с удаленного сервера, в некий момент или пакеты могли пойти по другому, более медленному маршруту, или просто пару пакетов потерялось, вот и мелкий лаг.
20 игроков в шутерах, при требовании апдейта по 10 раз в секунду - все же трафик.
"Все параметры тогда должны хранится на сервере а на клиенте только графика и отправка пакетов."
КОНЕЧНО,
иначе я влезу в пакет, подправлю параметры и поубиваю всех на сервере с одного удара.
На клиенте никакой деструктирующей логики быть не должно. Он может что-то предполагать для плавности отрисовки, но он не должен считать и отправлять результаты на сервер как истину, только команды игрока.
Вы еще не встречались с дупами (кучи багов в играх от самых крутых производителей), где из-за ошибок во время синхронизации можно сдублировать предметы, ресурсы, действия. Это тот еще океан для дебагов.
Но вы как-то еще пишете "игроки дерутся", хотя надо смотреть с другой стороны.
Игроки не дерутся, они отправляют команды на сервер.
Сервер вычисляет все взаимодействующие между собой объекты, и отправляет каждому игроку с каждым тиком результат.
Игроки могут и не драться, а например общаться.
Игрок может драться с мобом, а может покупать в магазине предмет - суть не меняется. Игрок отправляет команды, сервер отправляет результат ТИКА, а не именно этого действия игрока, поскольку действие должно быть просчитано с учетом всех остальных действий (например удар заблокирован, или игрок был уже заморожен).
Как-то так.
Padaboo:
Клавиша зажатая в квейк отправляется как команда "вперед". К ней можно добавлять синхронизаци в виде направления. Клик мышкой "бежать сюда" также команда, просто ее нужно дольше просчитать - зато гораздо меньше инфы передавать.
Но игры типа квейк, большой онлайн не поддерживают (20 игроков уже напряг), пинг свыше 30 - уже плохо, свыше 50 - играть уже невозможно.
Поэтому вам нужно определиться с типом игры, которую вы делаете.
Тики есть в любой игре. Не может же пулемет стрелять со скоростью клика мышки - он будет стрелять с установленной скоростью.
Клиент-серверу по TCP (каждое действие должно быть отправлено и отресолвлено)
Сервер-клиенту по UDP (не все пакеты должны дойти, но среди пакетов будут или каждый с синхронизаций действий, или например каждый 5-й или 10й или по времени с более детализированной информацией. Вы же видели, что в квейке бывают лаги, после которых вроде ты вроде как "телепортируешься" на пару шагов после лага - это показатель, что сервер команды просчитывает.
Волшебства в любом случае не будет, все упирается в онлайн, поэтому в квейке и подобных играх на карту стоит ограничение максимального онлайна, обычно до 20-30 игроков.
Написано только что
Вам нужно продумать пакет, который будет отправляться для игрока.
Например объект игрока будет содержать ссылки на объекты, связанные с этим игроком.
Подошел на расстояние - добавляем.
Игроки в группе - добавляем.
Сражение с врагом - добавляем.
Везде таймстампы от последнего действия и тип.
Некоторое время нет действия и тип позволяет - удаляем.
Подошло время отправить нужному игроку пакет - у нас уже есть готовый список объектов про которые нужно отправлять информацию.
Все состояния кодируются.
Все действия сглаживаются анимацией. Время сервера и клиента не обязательно должно совпадать, но вы можете сверять номер "тика" который сейчас резолвится на сервере и на клиенте, и отталкиваться от него.
"Нет, хочу сделать один раз что то серьезное - локации это не очень хорошо, единый мир лучше всего. "
Суть в том, что вы мыслите стереотипами.
Локация не обязательно смена места, это еще и location - местоположение.
Вычисляете РАССТОЯНИЕ между игроками, и конкретному клиенту высылать то, что касается его текущего местоположения и интерактивных объектов на определенном расстоянии X от него. Можно даже сделать так, чтобы это расстояние X было не статичным, а например уменьшалось автоматически, если рядом много объектов. То есть "в городе" например 20 метров, за городом 100 метров. Добавить исключения для тех объектов, которые контактируют непосредственно с ним или контактировали последние xx секунд
А вообще, IMHO вы беретесь за крупный проект вообще без опыта подобной работы.
В результате есть вероятность около 95%, что проект останется недоделанным, так как получить хотя бы первоначальную рабочую версию у вас получиться очень нескоро, а без заметных успехов, мотивация падает и все останется на бумажке.
Padaboo: неважно как выглядить сеть.
Все действия просчитываются сервером.
Действия просчитываются не в порядке получения пакетов от клиента, а согласно внутренннему таймингу сервера - у каждого действия игрока есть продолжительность. На сервере в цикле идут "тики", каждый тик - что-то в мире происходит (кто-то колданул, где-то заспавнился моб, что-то передвинулось, что-то скрафтилось, какое-то кол-во здоровья восстановилось). Все крутится вокруг тиков.
Сервер принимает от игроков команды, которые скапливаются в очереди каждого игрока. Но сервер знает (рассчитывает) что будет выполняться каждый тик. Следовательно, он может эти очереди проанализировать и отправлять каждому игроку очередь на ближайшие несколько тиков про всех игроков, которые находятся достаточно близко от него.
Если какой-то игрокA решил выполнить команду, которая выполняет противоположное действие - значит со следующим пакетом игрокБ об этом узнает и его клиент начнет отрисовывать другое действие.
В зависимости от количества народу, пропускной способности, и насколько у вас оптимизирован и продуман трафик, это будет практически мгновенно.
Мне кажется вы взялись за слишком сложную задачу в лоб.
Сервер в любом случае тут является главным оптимизатором.
Он должен решать какому игроку про что слать. Ограничивать запросы по расстоянию. Если игрок А ничего не может сделать игроку Б, то высылать им информацию друг про друга или не обязательно или можно в 10 раз реже. Подойдут поближе - будет больше деталей.
Периодически должны приходить синхронизирующие пакеты с более полной информацией, но в основном - дельта между прошлым и текущим.
Часто используется UDP
В общем нюансов много. Вы действительно сразу хотите делать именно такое решение?
100 игроков вполне можно и в синхронизации передавать, серьезные лаги начинаются в районе от 500 и выше в одной локации.
Если же что-то вроде квейка, где критичны миллисекунды, там пару десятков и КАК бы не оптимизировать критичен пинг от игрока к серверу, а со всеми <30ms не сделать.
chcp 65001
и затем ваш скрипт, который будет выводить в UTF-8
Если поможет, пропишите chcp 65001 каждый раз при запуске консоли. Это наследие консоли винды к сожалению..