Кхм. Не буду спорить, ибо бессмысленно, просто почитайте информацию. Она доступна. Посчитайте - тоже хороший способ.
Отсылка к работе програмисстом ирл - мда, вот уж кого-кого, а программистов в элитку играется, и даже только на русскоязычной ветке (если не в особенности на ней) - как собак нерезаных. С весьма широким расбросом опыта и области применения.
Да читал я, там писалось про этап генерации, все одно гадание на кофейной гуще будет. По ресурсам выгодней хранить, а как у них сделано хз, могут собрать кластер помощней и генерировать на лету
Без обид, но если ты считаешь что названия звезд/планет нужно хранить в utf-8, то ты либо на позиции juniohva либо тебе сильно переплачивают)
Во-первых нафиг нам хранить названия всех звезд для расчета курса- их нужно доставать только когда они нужны. Поэтому обычного GUID (128 бит, 340.282.366.920.938.463.463.374.607.431.768.211.455 уникальных вариантов) для звезды или объекта вполне достаточно. А название из внешней БД запросом получать, при отображении
Во-вторых обрезанной таблицы ASCII вполне достаточно.
Координаты тоже можно хранить не абсолютные, а относительные
1. Я не считаю что нужно хранить, а просто читал упоминание разрабами что они работают с utf-8
2. UTF-8 удачней подходило для "попугать" объемами
))
3. По квалификации я скорее мидл, для сеньера не хватает ширины охвата технологий, но я в этом направлении работаю
(ps мне недоплачивают, во первых я не в дефаульт сити, а во вторых я намерено выбрал сейчас работу поспокойней, что бы отдохнуть без авралов и переработок, пара лет прошедших вымотали чуток
)
4. Объем данных можно посчитать и без пугалок:
4.1 идентификатор звезды (он есть и это не название, иначе бы не было дублей названий) longint (8 байт)
4.2 координаты звезды ennt (4байта * 3) (может и меньше но не думаю, я и так минимум взял)
4.3 тип звезды (1 байт)
4.4 форма правления (2 байта)
4.5 состояние (2 байта)
4.6 экономика (3 байта)
4.7 принадлежность (1 байт)
4.0 (8+12+1+2+2+3+1)*400 000 000 / 1024 / 1024 / 1024 = 10,8 гигов чистой информации (это я еще брал очень скромно, скорее больше места выделено будет для запасу и тд.)
4.r все поля кроме 4.2 должны быть индексами для ускорения поиска (хотя я бы забил и добавил бы доп поля для отсечек, например разделил бы звезды по границам куба с плечом в 1000св лет, что бы отсекать из поиска недоступные звезды и тд.) это заставит бд еще разрастись. Но даже по минимуму крутить бд в 10гигов для поиска маршрута совместно с игрой для многих компов станет смерти подобно
В принципе мне добавить оперативки в комп и мой ком потянет такую работу, но за 90% людей я сомневаюсь
ЗЫ: есть варианты оптимизации поиска (по времени и памяти) за счет занимаемого места на диске, но там будет увеличение места раз в 10-ть, то есть к игре нужно будет хранить примерно 100 гигов файлов с данными. Но это хорошо ускорит локальную работу
Игроки согласятся?
))
- - - Updated - - -
Вообще не понимаю тех кто говорит что вся информация о звездах идёт от сервера - вы прикиньте сколько трафика она будет жрать)) не - я вижу что инфа в локале -- и я вам более скажу Подозреваю Что сам процесс расчёта маршрута делает именно Мой Процессор -- локально(1000св.л за 2-3 сек). Так значит это просто фронтиры -- (как было верно подмечено командором выше) хотят чтоб игрокам жизнь мёдом не казалась.
Ps. Именно не возможность проложить маршрут (эффективный) на дальние расстояния - причина отсутствия тяги к далёким звёздам по серьёзным мискам.(
от же жесть - какой трафик? от сервера тебе придет только маршрут, или в случае просмотра, то придут звезды из сферы примерно 50св. лет. Все равно небольшой это трафик.
А учитывая лаг между выбором звезды и появлением окружающих ее звезд на карте, информация явно подгружается с сервера.