AndreyKI
Если же говорить о хранении непосредственно в ходе игры, БД - намнго легче/проще (особенно поиск),
но менее производительно чем некий собственный класс/массив.
я не уверен что поиск нам там вообще будет нужен... после генерации галактики скорее всего сразу будут создаваться все звезды (gameObject) на галактической карте.... я так то проверю ещё, но мне кажется даже несколько тысяч звезд занимать памяти много не будут (тут скорее вопросы к юнити, как она будет хранить и обрабатывать эти объекты и сколько будет на это тратить памяти)...
я так вообще пока склоняюсь в сторону массивов... те более, что проблем с указанием размера в коде при создании нет ни каких...
тем более на галактической карте вроде как данные для всех звезд будут одинаковые....
а вот как хранить в игре данные звездных систем (какие в них планеты, параметры планет и т.п.).... я пока как то не могу определиться... но как то массивы тут не сильно вписываются.... возможно классами.... но мне надо бы почитать про классы в си шарп.... что они могут и как с ними работать... ну или может тут кто выскажет по этому поводу соображения...
как то так....
Vasaka
Она проясняет самую тёмную область для меня на данный момент.
да... только при чем тут "ТЗ: галактическая карта"?
кто там у нас ещё админ.... режьте тему на части... создайте "обсуждение проблем баз данных" (или хранения данных в игре).... и переносите туда сообщения не по теме...
krupennikov
Мое предложение следующее.
Использовать только по одному классу на каждую сущность (корабль, звезда, планета, ну и т.д.). А так же использовать виртуальную БД, очень мне понравившуюся в шарпе, - DataTable. Эта база данных находится в ОЗУ (памяти). В любой момент можно легко сохранить, загрузить, обратиться к любой ячейке данных.
Как все это будет происходить.
предложение отличное... и расписано хорошо...
теперь осталось написать пример.... при чём в юнити... и тогда так и сделаем... если конечно оно всё заработает....
хотя... если у нас уже есть классы... почему бы нам прям в них данные не хранить то?
krupennikov
(например, зачем в сохранке таблица, с расположением файлов звуковых эффектов; прикрепленные к типу кораблей расположения путей к файлам графики и др.)
вы давайте без кивков в сторону структуры игры.... там как бы есть ещё юнити с её проектами.... и там ещё разбираться и разбираться как её научить это всё использовать...
да и вообще... по поводу МОДОВ.... вы коней то не гоните... тут и так работы до фига и больше, а если ещё и на моды всё время оглядываться.... я предлогаю пока если и думать про моды, то только минимальные.... изменеия каких то характеристик (в основном кораблей) в xml.... что игроки делают довольно часто... об остальном думаю не стоит пока заикаться....
есть большие сомнения что игра сможет по популярности быть сравнимой хотя бы с цивой.... а взять циву... если брать рунет.... для 4-ки и десятки полноценных модов не набереться.... для МОСКа оптимистично 10 часть от поклонников цивы.... один мод что ли?
получится игра, будет популярной, тогда можно сделать, а пока не стоит....
в конце концов для желающих будут доступны исходники.... с ними при желании можно полностью игру переделать, ни какие возможности той же цивы с SDK и рядом валяться не будут...
AndreyKI
Просто мое предложение: некий класс SpaceObject
тоже хорошо звучит... но теорию я вам и сам рассказать могу... нужны примеры в юнити...
AndreyKI
На мой взгляд достаточно написать некий класс SpaceShip, сделать массив/список/словарь с использованием этого класса, далее любая выборка делается очень просто.
вот дальше с примером хорошо.... а слабо также расписать как работать с планетами...
есть класс звезд, с заполнеными данными (данные по звезде и по планетам).... я так понимаю для данных планет свой класс (ну и что-то там с наследованием))...
мы выбрали звезду, как сделать выборку данных по планетам в её системе...
пример нужен (если всё таки будут классы)...
AndreyKI
Так же для пошаговых стратегий для мультика придется переделывать всю систему, дабы предотвратить сейв/лоад (пока само правильное решение в серии Space empires) - но графический движек всеравно останется тот же.
какую систему переделывать... на фига.... какой save/load... разверни свою мысль...
AndreyKI
Просто пример:
делаем выборку из домашней системы и кидаем в неё игрока, а подгрузку всех остальных систем ставим отделным потоком по одной (приоритет с тех, где колоний игрока больше), если игрок попытается перейти в систему, которая еще не подгрузилась - загружаем её с приоритетом. когда всё загрузится - закрываем подключение к БД. Открываем в будующем только для глобальной записи всего сейва.
как оно будет в реальности (скорее всего)))....
у нас будут отдельные сцены:
1. галактика
2. звездная система (то что реализовано в 0.1.2.04)
3. планетная система
4. экран битв
5. экран просмотра корабля (возможно он же будет использоваться для конструктора)
да и то как сцены... по понятиям юнити это будет одна и та же сцена... просто объекты будут далеко друг от друга и будут переключаться камеры...
1. при создании игры генерируем данных всей галактики (каждую звезду, планету, поля астероидов, кометы)... все данные из файлов (про генерацию планет там, например, считываются в момент генерации)...
2. Открываем сцену галактики и даем команду юнити создать объекты типа звезда (ну и там туманности)
ИЛИ возможно всё таки сначала стартовую систему игрока... но в любом случае галактика будет создаваться при создании игры и меняться практически не будет (ну там если только какое оружие для "создания" новых/сверхновых звезд)....
в любом случае данные галактики после старта передаются объектам юнити и не загружаются / удаляются....
3. при выборе звездной системы, мы обнуляем сцену звездная система и по данным хранящимся в памяти генерируем сцену (создаем объекты в юнити, даем им координаты и т.д.)...
4. при выборе планеты такое же делаем со сценой планетная система...
то есть данные будут в памяти, всё что надо грузиться при создании / загрузке игры... и при изменении сцены считываться (использоваться)...
в принципе, по большому счету ни что не мешает часть данных грузить позже отдельным потоком... те же данные других звездных систем...
по крайней мере те в которых ни кого нет.... т.е. эти данные не понадабятся при расчете передвижений кораблей игрока в конце хода...
хотя.... а если игрок наведет мышку на карте галактике на звезду... ему надо написать что там (ну что известно).... ну тут потом подумать можно...
дык вот... вот примерно исходя из этого мне надо знать... где/как/в чем мне лучше хранить данные...
массивы, классы, БД...
вот вы тут и определитесь.... решите что больше подходит... сделайте примитивные примеры, проверьте работоспособность в юнити...
думаю при желании код может кто-нибудь написать, а вон Васяка проверит будет ли оно в юнити работать... если вам религия не позволяет юнити установить...
потом...возможно лучше несколько вариантов... с их плюсами и минусами...
и примеры...
решили там например классами, написали - заполнение данных (вообще инициализация), изменение, считывание (и как мне получить / передать именно нужный мне объект.... я как то не ожидал, что для этого понадобиться отдельный массив... сюрприз))), загрузка/сохранение (в том числе отдельным потоком).... думаю мне для начала хватит...ну и это всё проверить на работоспособность в юнити.... мне читать портянки на три страницы про БД которых из-за НЕТ 4.0 я скорее всего и использовать то не смогу.... не когда... (вы как бы ещё учитывайте.... я 1-го ноября начал делать протоип... до этого я про си шарп бегло читал с год назад про переменные.... т.е. шарп для меня темный лес... хотя счас уже посветлело конечно)))... вообще больше пишу на делфи, но там с базами данных я не работал и классы даже там не являются моей сильной стороной)...
а вообще.... оно как бы движок удобный... и потом на том что мы наваяем можно при желании сделать что-то другое... поэтому я думаю не стоит при выборе сильно ориентироваться на пошаговость....
Оффтопвозможно в перерывах между МОСКами я таки сделаю что-то вот такое вот:
думаю может быть даже во вселенной МОСК.... и мне контент искать не прийдется и для МОСКа раскрутка...
соответственно движок юнити, риалтайм... куча врагов, надо завалить как можно больше...
в принципе это пока только прикидки во время перекуров... конкретнее разбираться буду, когда подойду к тем местам, где это будет нужно....
Васяка
Я не знаю точно на чём работает Юнити. Витя сказал, что использует .NET 2.0, а Диман проверял работу готовой сборки на ХР без фреймворка. Всё работало.
пусть юнити ставит на чистую систему.... и что там юнити запоет....
и можете чего-нить ему прописать... что например появилось в НЕТ 4 или 3.5...
как юнити на это реагировать будет... что там у игрока будет, дело десятое, счас надо определиться что юнити использует для сборки...
и энто... как он запускал.... через launcher? и он запустился? может чистая система уже была с нет 2.0 ?
AndreyKI
Уточни необходимую БД - методы доступа могут немного различатся.
Васяка
Ждём Витю, что он скажет.
когда я буду знать, что необходимо, то я вряд ли буду задавать вопросы...
вот вам кстати....
Код: Выделить всё
using UnityEngine;
using System.Collections;
public class StarDiameter : MonoBehaviour {
private Transform[] starPointTmp;
//////////////////////////////////////////////////////////////////////////////////
void AObj_Diameter (int Obj_Diameter){
float BObj_Diameter = Obj_Diameter / 5.0F;
transform.localScale += new Vector3(BObj_Diameter, BObj_Diameter, BObj_Diameter);
if (Obj_Diameter == 0) {
renderer.enabled = false;}
starPointTmp = new Transform[GlobalData.StarCnt];
int tmp = 0;
if (GlobalData.StarCnt > 0){
foreach(Transform Star in GlobalData.starPoint){
starPointTmp[tmp] = Star;
tmp++;}}
GlobalData.starPoint = new Transform[GlobalData.StarCnt + 1];
GlobalData.starPoint[GlobalData.StarCnt] = transform;
tmp = 0;
if (GlobalData.StarCnt > 0){
foreach(Transform Star in starPointTmp){
GlobalData.starPoint[tmp] = Star;
tmp++;}}
GlobalData.StarCnt = GlobalData.StarCnt + 1;
}
}
это скрипт установки размеров звезды при создани.... в нем же в массиве сохраняются координаты звезды (Transform)... для добавления в массив создается временный, в него переписываются данные из основного... потом основной переобъявляется.... и заполняется... так как количество звезд я заранее не знаю...
координаты записываются для расчета хвостов комет...
вот может будут какие идеи как это дело можно упростить... да и вообще гляньте.... )
и такой вот вариант
Transform[] starPointTmp = new Transform[GlobalData.StarCnt];
или объявление как private
я так понимаю по большому счету без разницы как его объявлять? ну и другие переменные...
по планам на прототип...
сейчас планирую сделать вывод информации о планете при наведении... примерно как на скриншоте:
я думаю многие узнали от куда скриншот.... ?
старкрафт... главное меню... у кого стоит, можете посмотреть как эта информация появляется... хочу сделать как то так же...
оттуда же и зеленые сетки планет при наведении на них мыши... которые уже сделаны... близзарды всё таки молодцы... атмосфернее (имхо) только герои 3.... но они нам не подходят ))
да да Васяка.... ты многое упустил :-p
потом выбор объекта... вывод о выбранном информации на панель "описание выбранного объекта" И на панель "дополнительной информации" (которая выезжает по пробелу)....
потом открытие планетной системы... планета, спутники, ползунки и 2D вид поверхности для баз (последние два меняются от выбранного объекта, для планеты свои, для спутников свои, но выглядеть примерно одинаково будут, ну как то так)....
следующей будет карта галактики.... генерация, отображение, всё такое.... законы для генерирования спиральной галактики я уже на бумажке прикинул:
1. RND (0 -360), через sin/cos - получаем круг из звезд....
2. RND (0 - диаметр галактики) - распределяем их равномерно по площади круга... тут возможно через параболу (y = x*x) распределение не равномерное... в центре больше, к краям меньше... но тут надо подумать... посмотреть картинки галактик.... как там оно вообще должно быть.... да и насчет центра галактики определиться... что там... звезды или массивная черная дыра (говорят так бывает))), если ЧД, тогда генерировать звезды не от 0...
3. приведение к осям веток спирали.... от количества веток рассчитываем линии веток... и по расстоянию от ближайшей ветки считаем оставить звезду на месте или сдвинуть ближе к оси.... тут тоже через рандом (точнее через несколько))....
4. искривление веток спирали... проходимся по всем звездам и по удалению от центра галактики сдвигаем их в обратную сторону от вращения галактики (ну как то так).... при чем значения сдвига увеличивается от центра не линейно... наверно ))
это пока так... на бумажке... как делать буду посмотрю ещё...
ну и ваши предложения по доработкам... внеочереди...
делаю, что успею до нового года... потом минимум до лета у меня будут другие проекты... но думаю это не страшно.... как раз ребята контент подсобирают... а то за полтора месяца несколько рисунков для интерфейса как то не радуют....
