И как раз с++)

Да, выглядит многообещающе, попробую на днях

Что-то я не подумал на русском гуглить когда искал :)

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

Я сам наткнулся на этот сайт случайно. Тут и поиск пути и генерации карт (ландшафта), всё с исходниками и демонстрациями
http://theory.stanford.edu/~amitp/GameProgramming/index.html

утащил в закладки, спасибо

voronoi-map-goal-16000-shaded.png

Polygonal Map Generation for Games
http://www-cs-students.stanford.edu/~amitp/game-programming/polygon-map-generation/#references

Тред не читал. Загугли steering behaviors. Не совсем по навмешу. хотя может и с ним использоваться, но это прям pathfinding-porn. Никогда сам не юзал, но мой тайный фетиш и всегда хотел. Может тоже зайдёт.

@alprog я читал про ваши кастомные редакторы и свою систему компонентов для работы дизайнеров над настройками игровых объектов. все понятно и логично, но вот по мелочи возник вопрос.
у вас в Encased же довольно много данных, над которыми обычно удобно работать в экселе и аналогах. например боевые характеристики оружия и персонажей. как ваши дизайнеры работают над подобной балансировкой? балансируют в своих спредшитах и потом перебивают в формочки редактора компонентов? [полу]автоматический импорт/экспорт в спредшиты? запилили свой табличный редактор на базе гуя юньки?

Планирую окунуться в воксельное движкописательство.
Меня очень вдохновляет работа вот этого парня: https://youtu.be/BoPZIojpbmw
Teardown тоже крут, но у этого малоизвестного автора все выглядит в разы технологичнее и прогрессивнее

Тоже хочу свои воксели. Но такие, чтобы каждая частица симулировалась физикой (когда не в состоянии покоя).
Что-то наподобие старой powder toy. Убийца майнкрафта, одним словом.
Главное - физику сделать на целых числах. Звучит вроде осуществимо, ведь все взаимодействия между кубиками происходят исключительно на объемной сетке.

Отдельный вопрос с вращением. У индивидуальных кубиков нет вращения, но группа кубиков должна уметь вращаться за счёт смещения индивидуальных кубиков с разной скоростью.
Насколько я вижу, в teardown и неназванной демке по моей ссылке группы кубиков вращаются, как единое целое. То есть, группа кубиков, отделившись от основной сетки вокселей, начинает жить в своем пространстве и перемещаться/крутиться  без привязки к сетке. В этом подходе есть что-то ненатуральное. Я бы хотел, чтобы все симуляции происходили в одной среде, в общей сетке. И отделившаяся группа вокселей перемещалась бы за счёт движения всех вокселей в группе. Это позволяет сохранить целочисленную физику, и в целом как-то более естественно для воксельной физики.
Но вот как вращать группу вокселей (перемещать каждый воксель в группе вокруг условного центрального вокселя) так, чтобы сохранять структуру группы?  
Сомневаюсь, что есть готовый ответ, буду изучать. Я ещё ни строчки кода не написал, в общем-то. В отпуске размышляю.

Сначала думал на дотсе попробовать, но понял, что не прокатит. Burst и jobs выглядят круто, но ecs сырой до невозможности. И я думаю, что можно значительно ускорить рендеринг, если знать, что в моей игре будут исключительно кубы. Например, куллинг получится сделать быстрее юнитовского (если у меня достаточно прямые руки)
Жалко, что burst нельзя без юнити использовать. Никаких плюсов бы не нужно было.

У меня мало опыта работы вне юнити. Я искал что-нибудь об архитектуре игровых движков, но нашел только очень общие сведения. В единственной прочитанной мной статье для общения между системами (инпут, логика, физика, рендер) предлагалось использовать некий общий message bus, куда кто угодно может отправлять сообщения, и кто угодно может на них реагировать. Говно идея, как по мне, но мб я чего-то не понял.
Ещё есть книжка с названием как раз по моему запросу: архитектура игровых движков. Пролистав содержание, про архитектуру я там ничего не увидел, но мб вернусь к ней позже
Собсно хотелось бы знать, как у гордых авторов собственных движков это сделано. Как передаются данные между системами, и как выглядит архитектура в целом.

Между какими системами? Компонентами внутри приложения? Message это прям вообще извращенцы

я примеры систем перечислил в скобках

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

так-то вот статья
местами толково, но концепт странный
https://www.gamasutra.com/blogs/MichaelKissner/20151027/257369/Writing_a_Game_Engine_from_Scratch__Part_1_Messaging.php

о, тоже убийца майнкрафта. круто

Кстати сделан на Юнити и на Урхо. Хотел сравнить скорость и прочее. Первый скриншот на rbfx c#, а видео снято на телефоне с запущенной игрой (Unity). И как мы видим, результат лучше чем можно было себе представить