Їх дуже багато різних, кожні зі своїми характеристиками і властивостями. «Сайлент» це просто тип свічів (вони «гасять» удар), але їх теж дуже багато різних. Як там нижче написали, то краще їх ще й змастити, але на тому ж funkeys є платна опція змащування свічів.
Якщо вам треба якнайбільше готовий варіант, але щоб тихо і приємно, беріть якусь хорошу barebone основу (наприклад ту, що я вище вказав) і ставте туди сайлент свічі та кейкапи довподоби.
Якщо є складнощі з вибором, то рекомендую долучитись до чату funkeys (лінка є в їх телеграм каналі), там можут підказати, якщо пощастить) головне не вестись на пропозиції «зібрати корне» і т. п. :D

Це ще не хардкор)
З приводу питання: взяти клаву з шумкою (наприклад, Keychron Q1 Pro) та сайлент свічі.

Потрібно щоб виконувались обидві умови, тобто і кількість встановлень, і доходи за останні 12 місяців

Поки Unreal рухається на зустріч розробникам, заохочує усілякими MegaGrants, надає безкоштовні ресурси, Unity в той час все більше відштовхує залишки лояльних користувачів

Дякую за сайт!
Неівеличкий фідбек: не вистачає хочаб якихось описів, з однієї назви не завжди зрозуміло про що конкретно канал/чат.

Порекомендую ще сайт interfaceingame.com
Часто ходжу туди за референсами, коли працюю над дизайном UI.
Там менша база ігор ніж на сайті, зазначенному в статті, але із плюсів там окрім скріншотів є міні-відео з анімаціями інтерфейсу, а також кнопка завантаження у кожного скріншота.

Ніяк. Як показала практика з PayPal, Samsung Pay, криптовалютами тощо, для НБУ це все не цікаво і не потрібно.

Спробував Logseq нещодавно, намагаючись знайти достойну заміну Joplin. Але виявилось що це більше як журнал чи планувальник, аніж база знань як Obsidian. Тому не думаю, що його можна розглядати як пряму альтернативу.
Із схожого можу ще назвати Notesnook, наткнувся на нього також, коли шукав щось на зразок Joplin. Можливо комусь буде до вподоби.

Насправді фізика на сервері також реалізується. Це просто залежить від проекту, вимог. архітектурних рішень і т.п. Іноді нема інших варіантів, крім як реалізувати ії на сервері. Та і є випадки, коли гра має дуже примітивну фізику. У такому разі буває швидше та дешевше використати фізичний рушій на сервері, ніж реалізовувати перевірку колізій та синхронізацію положень між клієнтами. Якщо я правильно памʼятаю, agar io дуже непоганий приклад.
Є також випадки, коли сервер дублює частину фізики клієнта і на основі цього коригує чи перевіряж клієнтську. Як я казав вище, скільки ММО, стільки и різних підходів)

То ви сильно замахнулись якщо тільки но почали вивчати UE. Розробка ігр це складно, а розробка ММО на порядок складніше. Універсальних рецептів немає: скільки ММО, стільки і підходів до організації системи. Але у будь-якому разі, якщо у вас є бажання вивчати цю тему (а також для всіх інших зацікавленних), спробую підкинути трохи матеріалу.

По мережевому коду рекомендую почитати блог Gaffer On Games. Автор також торкається теми синхронізації фізики. Також серію «Fast-Paced Multiplayer» у блозі Gabriel Gambetta.
По архітектурі ММО рекомендую ознайомитись з наступними статтями:
— «Building a Balanced Universe» у блозі EVE
— «A Distributed Architecture for MMORPG» (Marios Assiotis and Velin Tzanov) — як раз відповідь на запитання щодо безшовного світу.
— «Survey of State Melding in Virtual Worlds»
По геймдев шаблонам і т. п. книга «Game Programming Patterns» (Robert Nystrom).

По серіалізації — використовуйте вбудовану у обране мережеве рішення, або protobuf.

З готових мережевих рішень, на думку приходить тільки Photon, але мені він не подобається. Можливо э щось спеціально для UE, але я не з ним не працюю.

Щодо решти питань, це все залежить від концепту гри та масштабу проекта. Наприклад, колізії на сервері можут бути занадто дорогими і часто не мають сенсу без серверної фізики.