Кратко о содержании сегодняшнего поста:

Плавное освещение.
Первый тест мультиплеера.

Плавное освещение.

Решил начать с обновления освещения, но оказалось всё не так просто.
Задумка была использовать регулярную сетку, где каждая вершина совпадала бы с игровым полем и её цвет был равен сумме цветов соседей / 4.

Получалось что каждая точка усредняет значение света вокруг себя.
А дальше мы просто интерполируем между вершинами и получаем плавное освещение.
Но не всё так просто.
В основе нашей сетки лежат треугольники.
И...
мы получаем вот такую вот штуку:

А всё из-за того что интерполяция идет внутри треугольника, а нам нужно чтобы это было внутри квадрата.

В итоге я решил вернуться обратно к цветному квадрату, но немножко переделать его шейдер.
И в итоге получил правильную интерполяцию:

И вот собственно результат.

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

Как по мне получилось очень годно, но есть небольшой нюанс.
Я освещаю стены максимальной яркостью вокруг них, и всё вроде бы хорошо, да?

но в сглаженном варианте получается вот такая штука:

И в качестве борьбы в этим, я сделал так чтобы стены пропускали свет, но очень слабо.

Если у вас есть идеи как это исправить пишите.
Может чего вместе сможем придумать.

Еще парочка интересных скринов с разработки освещения:

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

Первый тест мультиплеера.
Провёл закрытый тест мультиплеера.
Это было классно. Немножко покрафтили, позанимались пиксельартом, исследовали местные горы, и даже поиграли в салочки :D

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

А также:
- Я исправил баг прилипания к стенкам по Y, это была ошибка в движке коллизии, из-за чего игрок медленнее двигался по X если касался стены.
- Добавил вывод DrawCall'ов.
- Подключил гит, да я знаю что я слоупок.
Ну и так по мелочи, разные улучшение, исправления и оптимизации.

А на этом всё, спасибо, что дочитали.

Также не пропустите прошлые посты:

https://pikabu.ru/profile/GooDCrafter

Ссылка на группу в вк(есть играбельная демка):

https://vk.com/terrapath

Кратко о содержании сегодняшнего поста:
Улучшение графики.
Еще немножко про мультиплеер.
Новая демка.

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

Добавил анимацию покачивания предметов:

Улучшение в сервере:
- Теперь сервер обновляет состояние всех объектов 40 раз в секунду.
- Синхронизация анимации разрушения.
- Удаление объектов.

- Синхронизация времени.
- Обработка дисконнекта. C выводом причины дисконнекта(выключение сервера/выход/ошибка и тд).

- Проверка версии протокола.

- Консольное управление сервером:

1)Выключение сервера(stop).

2)Установка времени из консоли(time <время в формате 0-24>, можно задавать дробью например 9:30 это 9.5).

- Рабочий пинг.
- Синхронизация предметов как дроп.
- Синхронизация инвентаря.
- и многое другое.
Также я немного ускорил кирку и сделал мини оптимизация рендера в чанках.

Новую версию с мультиплеером можно скачать в группе.
Контента в ней чуток меньше чем в прошлых(нету врагов), но уже есть мультиплеер.
Порт для сервера пока жестко всшит.

А на этом всё, спасибо, что дочитали.

Также не пропустите прошлые посты:

https://pikabu.ru/profile/GooDCrafter

Ссылка на группу в вк(есть играбельная демка):

https://vk.com/terrapath

Кратко о содержании сегодняшнего поста:

Неблокирующий сервер
Протокол
Полезные ссылки

В прошлый раз мы остановились на многопоточном блокирующем сервером.
Сегодня же мы рассмотрим неблокирующий однопоточный сервер.
В этой статье мы уйдем больше в сторону Java, хотя реализация такого сервера возможна и на других языках.
Мы будем использовать Java.NIO;

К сожалению, информации о написании неблокирующего однопоточного сервера не так много как хотелось бы, но в итоге я собрал несколько полезных ссылок, где рассказывается о сервере на NIO. Ссылки будут ниже.
Сбор информации и планирование архитектуры сервера заняло у меня около 1 недели. Само же ядро сервера было написано за 4 дня.

Начнём.
Первым изменением у нас будет указать сокету, чтобы он не блокировался:

socket.cofigureBlocking(false);

теперь операции accept/write и read не будут останавливать программу.
Но теперь нет гарантии что мы что-то прочитали или что-то записали, мы сами должны за этим следить, а accept возвращает null если подключения нет.

В целом всё хорошо, но есть одно НО. Наш сервер безостановочно крутит это цикл раз за разом нагружая систему. Мы можем увести поток в сон на короткое время 4-16 мс, но есть решения намного круче.
Это селектор. Что же это такое?
Эта такая классная штука которая просыпается только тогда когда есть данные которое нужно обработать, а если их нет, то он просто блокирует выполнение.

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

Selector selector = Selector.open();
selector.register(socket, OP_READ | OP_WRITE);

Есть 4 ключа:
OP_READ - чтение
OP_WRITE - записать
OP_CONNECT - если сокет подключился к удалённому сокету(только клиент)
OP_ACCEPT - если удалённый сокет подключился к нашему(только сервер)

Ключи можно комбинировать записывая их через '|'.
Работает эта фишка за счёт битовых операции.

Код сервера теперь выглядит так:

Очень важно: client.socket().setTcpNoDelay(true);
отключает алгоримт Нейгла, чтобы уменьшить задержку передачи данных.

Код клиента выглядит примерно также, за исключением создания сокета и ключа в селекторе.

Написав такие реализации я стал думать как их грамотно объединить.
Я не хотел дублировать код в игре 2 раза: один раз для синглплеера, второй для мультиплеера.
Поэтому решил сделать такой хитрый ход конём.
Синглплеером будет локальный сервер запущенный в этой же программе.
В чём же его особенность? А в том что к нему нельзя будет подключится из вне, только если игрок сам этого не захочет.

Я стал думать как это сделать и родилась такая концепция.
Класс SocketBase - основа работы с селектором
от него наследуются:
SocketClient
SocketServer

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

Тогда я разделил это вот так:
ServerBase
---ServerLocal
---ServerNetwork

ClientBase
---ClientLocal
---ClientNetwork
И тут тоже оказалось всё не так гладко, код также дублировался, хотя и было исправлена проблема с локальной игрой(без настоящего подключения к сети).

Я внимательно обдумал концепцию того что я хочу сделать и тут меня осенило
А ведь серверу вообще не обязательно знать работает он с подключением из сети или локально.
Так родилась идея каналов:
Channel
---ChannelLocal
---ChannelNetwork

Суть в том что все каналы могут принимать и отправлять данные, а как они это делают уже скрыто реализацией.
Но чтобы сетевые каналы работали я создал специальный класс Network, именно он занимается ChannelNetwork. Создается он в отдельном потоке и работает через селектор.
Network
---NetworkClient
---NetworkServer

Что позволяет создавать сервер локально, а если нужно чтобы к нему могли подключится из вне, то я просто пишу server.bind(порт), в этот момент создается NetworkServer внутри сервера и начинает обрабатывать сетевые подключения.
Это всё позволяет играть в синглплеер, а в любом удобный момент открыть сервер для сети.
Хоть такая возможность и есть, но я не уверен что буду её делать.
Но хостить сервер из игры точно можно будет, только через меню.

ChannelLocal работает достаточно просто, он просто связывает память клиента и сервера, через буферы пакетов.
Поэтому когда сервер что-то записывает в локальный канал, эти данные сразу попадают клиенту игнорируя сокеты и прочие вещи, то же самое и с клиентом.
Следовательно пинг равен нулю, так как передача данных моментальна.

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

Финальная структура выглядит так:

Протокол

Чтобы как-то обмениваться данными между клиентом и сервером нам нужны правила.

Так как отправляет и принимаем мы байты, нам нужно как-то их разделять.

Есть в целом 3 популярных метода:

1)Фиксированный размер данных.

2)Специальный маркер конца сообщения(пакета).

3)Запись длинны в начало сообщения.

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

2 способ, такой маркер случайно можно отправить передавая обычные данные.
Такой способ отлично подходит под текст, но мы будем передавать кучу разных данных поэтому нам он не подходит.

3 способ нам подходит больше всего.

Структура пакетов и игре выглядит так.
Длинна пакеты - 2 байта
ID пакета - 2 байта
Данные - N байт

Длинна записывается в байтах и равна 2 байта(ID пакета) + N байт(данные).
Следовательно максимальный размер пакета 65 535(т.к. 2 байта = 16 бит = 65 535).
Тоже самое и для ID пакета 65 535 различных вариантов пакетов.

Примеры пакетов:
<id> <название>
<данные>

1 Login
int protocol;
String username;

3 ConnectionApproved
int playerID;

33 TileSet
int x, y, id;

На момент написания статьи в игре уже 29 пакетов, нумерация идет не по порядку, и представлены они в виде такой структуры:

А на этом всё, спасибо, что дочитали.
Код в статье близок к Java, но упрощен для лучшего понимания концепции.

Также не пропустите прошлые посты:

https://pikabu.ru/profile/GooDCrafter

Ссылка на группу в вк(есть играбельная демка):

https://vk.com/terrapath

Полезные ссылки по сокетам:
1)https://www.youtube.com/watch?v=DEVaahWFY9s - очень полезное видео по написание сервера/клиента по NIO, на русском.
2)http://www.baeldung.com/java-nio-selector
3)https://www.cordinc.com/blog/2010/08/java-nio-server-example.html
4)http://www.javaportal.ru/java/articles/useselectfast.html
5)http://www.studytrails.com/java-io/non-blocking-io-multiplexing/
6)http://tutorials.jenkov.com/java-nio/index.html - целый учебник по NIO.
7)http://www.quizful.net/post/java-socket-programming - полезная статья для новичков о сокетах в целом.
8)http://adblogcat.com/asynchronous-java-nio-for-dummies/

Полезные ссылки по написанию своего сервера:
1)https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
2)https://habrahabr.ru/post/328702/
3)https://habrahabr.ru/post/211202/
4)http://wiki.vg/Protocol - протокол майнкрафта.
5)https://seancode.com/terrafirma/net.html - протокол террарии.

PS: Вот это я разогнался, наверное надо было разбить эту статью на две или даже три.
Если кто-то дочитал до сюда скажите мне :D

Кратко о содержании сегодняшнего поста:
Сеть

Товарищ @Kopnu попросил более технические посты. Раз это интересно, то почему бы не попробовать расписать подробнее.

Начнём мы с простого сервера, а дальше перейдем к более сложному. Я начал кодить сразу с сложного, но чтобы было понятно как развивалась идея я начну с простого. Хочу передать ход своих мыслей, не знаю насколько это получится, но будет вот такой подблог.
Надеюсь вам понравится, приятного чтения.

Начнём мы с основных понятий:
Для сервера мы будем использовать протокол TCP через сокеты.
Что такое TCP вы можете почитать тут:
https://ru.wikipedia.org/wiki/TCP/IP

Почему я выбрал TCP, а не UDP?
TCP гарантирует доставку, а также порядок.
Это значит если я шлю: 1 2 3 4 5, то другой сокет увидит: 1 2 3 4 5.
А в случае с UDP может оказаться так: 4 1 3 2 5 или так 3 4 1 2 5.
Вы спросите а зачем же тогда вообще нужен UDP? Ну он работает чуток быстрее чем TCP, но мы теряем гарантию доставки и порядок.
UDP в основном используют в шутерах, где важны последние данные, чем старые.
А вот в нашем случае потеря пакетов может быть большой проблемой, игрок ставит тайл, а до сервера эти данные не доходят.

Что же такое Сокет? Это такое подключение между разными программами, которые могут даже находится на другой машине.
Можно представить это так: Каждая машина в сети имеет 65535 возможных портов. И любая программа может занять любой из них, если это разрешит ОС.
Когда мы подключаемся к какой-то машине мы указываем IP и порт (порт не всегда указывается так как может быть всшит в программу).
Есть два вида сокетов: Socket и ServerSocket.
В чём различие:
Обычный сокет способен подключится к IP адресу + порт, и передавать и принимать оттуда данные.
ServerSocket же подключается к некоторому порту который мы укажем и ждёт подключения, если же кто-то подключился то он нам возвращает Socket который связан с другой машиной.

В сам же сокет мы можем писать/читать байты. Можно провести аналогию с файлом. Но есть небольшой подвох изначально сокеты блокирующие.
Это значит что подключение/чтение и запись останавливают программу.
Яркий пример:

Socket client = server.accept();//Остановит программу до тех пор пока не появится подключение.

Тоже самое с чтением и записью. Из этого вытекает такая проблема, что мы не можем это делать в одном потоке, и нам нужно иметь несколько потоков, либо же использовать не блокирующие сокеты, об них я расскажу позже.

Почему не можем?
Вот такой код:

Как легко заметить в (1, 2, 3) программа просто останавливается пока не будет завершено действие.
Она будет работать так:
Примет подключение (1).
Прочитает данные если они есть, либо же будет ждать их (2).
Напишет ответ если он есть, либо же остановится навсегда (3).
И снова вернется ждать подключения (1).

Что-то эта схема не похожа на постоянные обмены сообщениями.

Поэтому мы переходим на многопоточный сервер.

Что же такое поток?
Его можно представить как отдельно запущенную программу которая имеет доступ к памяти первой программы. Потоки работают на ядрах процессора, что дает очень большой выигрыш по скорости, но если их будет слишком много это только замедлит работу программы. С потоками есть еще одна сложность, данные между ними нужно сихнронизировать, а иначе может получится такая вот фигня:

int value = 0;

поток А пишет в value = 10;
поток B читает из value и видит 0.

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

Теперь же архитектура сервера будет такой:
У нас будет один поток который принимает подключения:

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

Все же новые потоки будут работать так:

Архитектура потоков выглядит так:

Клиент:
1)Основной поток на основную логику игры и рендер.
2)Поток на сеть.

Сервер:
1)Основной поток на обновление сервера.
2)Поток который ждет подключения.
3..N)Новые потоки для каждого подключения.

В итоге получаем простенький сервер, который способен обрабатывать одновременно несколько соединений.
Если будет какие-то вопросы с радостью на них отвечу.
Код представленный в статье близко к Java, но является псевдокодом, для упрощения понимания концепции.

А на этом всё, спасибо, что дочитали.

Также не пропустите прошлые посты:

https://pikabu.ru/profile/GooDCrafter

Ссылка на группу в вк(есть играбельная демка):

https://vk.com/terrapath

Спасибо всем кто подписывается лично на меня, и на паблик в вк.

Приятно осознавать что людям интересно что я делаю.

Количество людей в паблике стало больше 100 :D

В следующий раз расскажу про пакеты и неблокирующие сокеты.
PS: Перечитал сам пост и мне кажется что всё равно получилось слишком сложно D:
Стоит ли вообще продолжать писать об сервере?