Георгий Пелагейкин

так и не осознал, что хранится в БД, а что - в RAM ... автоматические системы кеширования/сброса в БД?

В БД хранится вся информация мира, в текущий момент. Представьте, что сервер внезапно "умер", вся инфа в памяти исчезла, и теперь доступна только та инфа, которая сейчас в БД. Но получить инфу довольно долго, поэтому, используются кэши, иногда - многоуровневые. Если бы БД имела бесконечную скорость работы, то кэш был бы не нужен. Но, к сожалению, кэш необходим. В идеале, в кэше находится вся та же инфа, что и в БД. Но сложнейшая задача - инвалидация кэша (в БД инфа уже изменилась, а в кэше - нет, ещё хуже - в одном кэше тоже изменилась, а в другом - нет). Для того, чтобы потом не собирать баги лопатами, то придётся создавать автоматические системы кеширования/сброса.
Почитайте статьи "Архитектура высоконагруженных приложений. Масштабирование распределенных систем" (части 1 2) от Badoo.

Как, собственно, производить синхронизацию клиента и сервера?

Весь мир только на сервере, у клиента нужны только доступные (видимые) игроку объекты, иначе игроки узнают "лишнюю" инфу (например, в World of Tanks есть способы узнать "невидимые" танки). Но, к сожалению, так обычно не получается. Клиенту приходится знать чуть о большем количестве объектов, для того, чтобы прогнозировать их поведение. Но в космических играх попытаться можно сделать видимость объектов. Вы сказали про сенсоры корабля, эта очень хорошая мысль - объект исчез из сенсора, то пусть клиент удаляет этот объект. Если в дальнейшем объект становится в сенсоре, то пусть об этом сервер сообщит клиенту (или не сообщит, например, корабль включил маскировку, тогда клиент вообще не знает, что "кто-то" есть). Это можно добавить в геймдизайн - если объект попадает в зону сенсора, то сенсор увидит не в тот же миг, а через некоторе время, в зависимости от харакетристик сенсора (но не меньше пинга, хе-хе).
Почитайте серию статей "Сетевое программирование для разработчиков игр" (части 1 2 3), а также блог 0fps.net (на английском, нет нормального содержания, но есть сильные статьи). Ещё полезнейшая статья "Борьба с читерами в онлайн-играх: 22 «нужно» и «нельзя»".

создавать на клиенте экземпляр той же симуляции мира, что и на сервере

На клиенте создавать серверный мир не нужно, но и полностью отделяться тоже не стоит. Часть кода между сервером и клиентом будет общим. И чем больше, тем легче потом разрабатывать и клиент, и сервер. Помните про наследование с полиморфизмом, про общие проекты в решении.
Сервер не должен ничего знать про Unity3d, да и клиент игровую логику должен делать без использования инструментов Unity (про это ещё говорит TheShock). Так будет гораздо проще в дальнейшем.

может ли что-нибудь дать использование ASP.NET (возможно core) в качестве основы, или для таких целей его использование бессмысленно?

ASP.NET не нужен, имхо, он мало пользы может дать игровому серверу. Я бы начал делать сервер на .NET Core (можно и .NET Framework, просто сложнее будет деплоить. Подумайте про Azure).

Дмитрий Александров предложил про чанки. Мне кажется, что это хорошая мысль. Почитайте статью "Введение в октодеревья", возможно, это решит проблему с длинными расстояниями. Чанки будут нужны, потому что однажды один сервер не сможет "осилить" весь мир, придётся разделять его.

Вы думаете не в том направлении. Сервер главный, клиенты - рабы его. Захотели куда-то полететь? Спрашивайте разрешения у сервера. Захотели посмотреть данные о планете? Спрашивайте у сервера? Захотели сходить в туалет? Спрашивайте у сервера) Разумеется, всё это для выделенного сервера, который вы хотите написать на C#.

1) Надо отталкиваться от того, что любой клиент можно подделать. Следовательно, всё, что не отвечает за рендеринг, интерфейс и красивые эффекты, должно храниться и обрабатываться сервером. Клиент должен просто показывать ваши нули и единицы в удобной для пользователя формы.
2) Любое действие, совершаемое игроком, должно отправляться на сервер и проверяться им. Естественно, по данным, которые хранятся на сервере. Пользователь нажимает кнопку, посылается запрос на сервер, он симулирует действия. Рассматривайте сервер как единственное место, в котором реально происходит "игра" (симуляция мира). Клиент же рассматривайте как клавиатуру, мышку и монитор в оффлайн играх.
3) Симуляция (которая происходит ТОЛЬКО на сервере) должна быть ни чем иным, как простым кодом. Без всяких переиспользований и прочего. Просто какая-то функция OnClientSendData, которая, грубо говоря, осуществляет покупку от имени приславшего клиента нового корабля, сохраняет id в профиль игрока и возвращает сообщение об успешном выполнении покупки.
4) Связь между клиентом и сервером должна осуществляться через ваш собственный или выбранный протокол. На низком уровне. Обобщая, без использования стандартных юнитовских rpc, т.к. они не работают с выделенным сервером. Если очень хочется, то работают, но тогда сервер придётся писать на самой юнити, и он уже не будет консольным. В таком случае, опять таки надо забыть про рендеринг и прочее, ведь сервер должен быть быстрым, и на него никто не будет пялиться каждый день. Сборки, разумеется, должны быть разные для сервера и для клиента.
5) Интерполяция, экстраполяция, сглаживание и прочие умные словечки будут очень полезны в плане разгрузки сервера. Ведь можно каждую секунду передавать координаты планеты всем клиентам, а можно задать его эфемериду на несколько часов вперёд, ограничившись таким образом одной отправкой. Кстати, именно так сделано в GPS.
6) Некоторые логические действия всё-таки можно производить на клиенте, если их результату сервер сможет доверять. Ну или просто "разрешить" читерство, проводя симуляцию на клиенте, а сервер превратив в "тонкую" базу для синхронизации.
7) Ну и под конец, необходимо использовать всякие спец. приёмчики. Например, зачем каждый раз загружать с сервера всю карту, если можно загрузить только изменившийся кусок. Некоторые действия можно вообще сделать "локальными". Например, зная результат боя, можно сразу загрузить его и симулировать на клиенте, а не получать каждую секунду новые параметры.

1) Разделите мир на "чанки", т.е. просто на квадраты конкретного размера. В случае 2д это будет очень удобно.
2) Сервер обрабатывает только те чанки в которых находятся игроки, в случае отсутсвия игрока в нем то он сейвится на винт\бд. На клиенте чанки так же выгружается из памяти если он ушел в новый чанк.
3) Понадобится система пресказания какой чанк надо подгрузить. Скажем зная направления игрока предполагаем что он попадет в такойто то чанк а значит грузим его заранее.
4) Игроку при приближении к чанку отправляй его полное состояние а уже после только то что в нем изменяется.
5) Часть вычислений для линейных(предсказуемых) объектов можно синхронизировать только периодически. К примеру летящий астероид логически обсчитывается и на клиенте и на сервере но только в случае событий(столкновение к примеру) идет синхронизация между клиент-сервером.

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

воу. а для кого сделали 9SliceSprites

"Составная панель из пяти элементов (четыре стороны обводки и заливка). Жуткий костыль."
тот самый жуткий костыль, только не жуткий, а общепринятый.

Ну, вообще, то что вы ищите, называется Dependency Injection(DI). Передача в конструкторы везде-везде-везде руками - это одна из реализаций, практически самая примитивная. Наверняка в Юнити есть более лучшие реализации, предлагаю погуглить самостоятельно.

Возможно вы немного удивитесь, но использовать события вообще не желательно=)
Поскольку очень легко забыть отписатся от события, а это необходимо чтобы не было утечки. А если вы и не забыли, то очень часто нужны будуть костыли в виде кеширования объекта к которому подписались для дальнейшей отписки... Плюс проблемы с лямбдами. Я стараюсь заменять их на IObservable из Reactive Extensions for .Net.

Аналитический алгоритм всегда один и тот же - отдельно по каждой из координат Х и У :

ускорение - есть производная от скорости по времени
скорость - есть производная местоположения на оси по времени

Значит подставляем в формулу ускорения Вашу формулу, получаем дифф.уравнение второго порядка, решаем его, подставляем значения местоположения и скорости в момент времени t=0 и получаем искомую Вами зависимость местоположения от времени.

Если формула ускорения для одной координаты зависит от местоположения и/или скорости по другой координате, то "развязать" координаты Вам не удастся и мы имеем вместо двух независимых дифф.уравнений второго порядка, систему и пытаемся ее решить аналитически.

Зависит от типа игры. Если это экономическая стратегия, с акцентом на управление ресурсами И электричество один из учитываемых по количеству ресурсов, - то всегда нужно давать пользователю выбор, как им распорядиться, никакой автоматики. Если количество электричества не учитывается - можно устроить полную автоматику, чтобы устройство само им распоряжалось. Как пример, игра PlanetBase - нужно поддерживать колонию на чужой планете и строить в том числе электрогенераторы и электронакопители. Пользователь может отключать потребителей, и это всё, что он может делать - если электричества начнет не хватать, то подключенные потребители сразу обесточиваются, а когда генераторы возобновляют работу - все подключенные потребители автоматически начинают сосать энергию из аккумуляторов. Сделано так, потому что электричество не учитывается как ресурс (учитываются разные продукты, руда, металл, пластик, то есть строй-материалы, но не электричество)

Пользуюсь newtonsoft
Удобная, нареканий не было.

Json.net поддерживает наследование, более того, он корректно умеет даже конвертировать DataA в DataB если до этого было приведение к базовому типу (DataA b = new DataB и b был сохранен в json а потом нужно получить DataB b2 = Json.Deserialize<>(jsonString) ). Вся фишка в сеттинге TypeNameHandling.
stackoverflow.com/questions/8513042/json-net-seria...
www.newtonsoft.com/json/help/html/serializetypenam...

www.nuget.org/packages/ServiceStack.Text/3.9.71