-создаём удалённую базу данных где есть таблица аккаунтов(логин,пароль,количество денег, комплектация авто)
да, правильный ход, теперь ты сможешь восстанавливать состояние своих игроков после падения сервера на профилактику или при крашах
и таблица заездов(номер трассы, флаг что гонка началась, список гонщиков принимающих участие в заезде, и их состояния(кординаты и вектор скорости))
ну тоже конечно можно, но тогда твоя база будет принимать как минимум 3 тысячи запросов в секунду для 10 игроков (10 игроков * хотят знать о 10 игроках * хотя бы 30 раз в секунду для плавного апдейта) на чтение и как минимум 300 запросов на вставку. Можешь поверить на слово, что это довольно большие цифры для современных БД, особенно для 10 пользователей.
-далее каким-нить образом связываем созданный на unity клиент с этой базой,
ну можно сказать, что одна из задач любого сетевого сервера это быть прослойкой между БД и клиентом, тут да, мысль верная
при чём клиент работает в режиме сингл плеера, но поведение "ботов" уже не рассчитываться скриптом с ИИ, а решение берётся из таблицы заездов.
если убрать из этой строки "таблицы заездов", то будет уже правильный ход. Машинами управляют игроки, если игрока нет, то управляет ИИ. Отличный пример применения идеи интерфейсов C#. Имеем интерфейс машины и в зависимости от ситуации подключаем к нему реализацию в виде Сетевого оппонента или компьютерного противника.
Таким образом соревнование ни от кого не зависит, а не так как в игре по локалке(если у игрока, который выступает сервером вдруг виснет комп или другое ч.п., то конец заезду).
Тут смотри. Сервером будет либо твой компьютер (серверный, на удаленной станции, доступ к которому имеешь только ты), либо комп игрока. Первый случай хорош тем, что ты можешь контролировать всю игру, отсекать читеров и т.п. Но теперь прикинь, у тебя 10000 игроков, которые решили устроить 1000 заездов разом. Примерно что запустить 1000 карт quake 3 на твоем домашнем компе. Тяжеловато будет. Придется 2-3 сервера иметь, а потом еще игроки придут, значит 3-4, потом 5 и т.д.
Есть выход, заставить игроков самим быть серверами. Собрались 10 человек, нашли у себя самый мощный комп и сервер запустили на нем (ну естественно это все происходит без участия игроков в автоматическом режиме, в идеале). Придет в твою игру хоть триллион пользователей, а твой сервер будет нагружен только логикой комнат. Профит колоссальный. Но тогда если игрок узнает что он сервер, он может читерить и влиять на ход игры (а кто ему помешает? он же сервер). Можно контролировать и это. Ставить палки в колеса, но на каждый замок находится своя болгарка, так что будешь вместо вложения денег в железные сервера вкладывать их в усилия твоей команды по минимизации возможностей к плохому поведению игроков.
Ну и а почему ты гарантируешь, что твой сервер не зависнет от сонной ошибки прогера (мой например в бесконечный цикл однажды выпал) и точно так же всему заезду конец. Даже 1000 заездов, если у тебя пик популярности.
В очередной раз предупреждаю, что программирование сетевой логики это не просто строчку кода в синглплеер добавить. Попробуй сначала поэкспериментировать с внутренними средствами Unity. Сделай возможность кому-то быть хостером, а остальным подключаться к нему и гонять. Постепенно поймешь принципы работы и начнешь вырабатывать уже свою архитектуру, с комнатами или вообще ММО решишь сделать по мотивам фильма "Тачки".