Онлайновая походовая космическая стратегия.

Пока без названия, так что топик пусть так зовётся

Поскольку наш игровой форум никак процветающим назвать нельзя, предлагаю новый форум под игру не заводить, а считать форумом поддержки этот. Впрочем, обсуждение прочих игр тут по-прежнему разрешено

О! Нашел нужную тему, теперь в ней и будем обсуждать мелочи по созданию оной
Напомню что начало в тут

По поводу карты. Думаю, имеет смысл карту делать генерируемую случайно, с привязкой к координатам и т.п. А уже все отличия от этой карты - запоминать в базе. Будет гораздо компактнее.

На счёт введения планет со спутниками - надо подумать. С одной стороны, у нас стратегия, с другой - есть в очень дальних планах желание прикрутить что-то реалтаймовое типа Элиты, псевдооффлайновое (т.е. скажем, пару раз в день скачиваешь "пакет обновлений", выполняешь задания "стратегических" игроков и т.п. ). Но это ОЧЕНЬ дальняя перспектива

Хотелось бы космос пореалистичнее. То, что звёзды и планеты статические - чёрт с ними, игра всё равно не реалтаймовая, а вот процент звёзд разных типов соответствующий реальным данным, предполагаемое наличие планет соответствующих типов...

Никогда не забуду кайф, полученный во Frontier'е от полётов к планетам, вертящимся вокруг двойных звёзд по охрененным орбитам Когда по неделе внутри системы летать приходилось с постоянным ускорением Мгновенный прыжок на пару десятков светолет и потом долгое и нудное подгребание к станции...

Balancer>По поводу карты. Думаю, имеет смысл карту делать генерируемую случайно, с привязкой к координатам и т.п. А уже все отличия от этой карты - запоминать в базе. Будет гораздо компактнее.

Эээ... не совсем понял как это? То есть первоначальная карта подбирается случайно, а потом к ней относятся как к статичной и уже твердо существующей или каждый раз карта создается заново? Не понимаю...
По моему проще разочек "нарисовать" в базе все параметры расположения звезд (какие они, сколько у них планет, сколько у каждой из планет спутников, какие на них условия и проч) и потом привязываться к крохотному куску кода в базе. Два раза в сутки база приводится в соответствие с выполненными игроками ходами и все нормально.
Я как раз вот подбираю, что и как нужно в такую базу запихать. Пока получается достаточно приличная вещь. Параллельно в Delphi пробую как все получается

Balancer>На счёт введения планет со спутниками - надо подумать. С одной стороны, у нас стратегия, с другой - есть в очень дальних планах желание прикрутить что-то реалтаймовое типа Элиты, псевдооффлайновое (т.е. скажем, пару раз в день скачиваешь "пакет обновлений", выполняешь задания "стратегических" игроков и т.п. ). Но это ОЧЕНЬ дальняя перспектива

Вот вот! Очень дальняя, а пока как бетаверсия пойдет и без Элитоподобных включений...
Ксати правильно замечено, таки это стратегия, причем если следовать принципу МОО то как раз такие вещи как планеты и спутники в сисеме звезды были бы очень даже не лишними.

Balancer>Хотелось бы космос пореалистичнее. То, что звёзды и планеты статические - чёрт с ними, игра всё равно не реалтаймовая, а вот процент звёзд разных типов соответствующий реальным данным, предполагаемое наличие планет соответствующих типов...

Тогда черт его знает сколько надо планет и каким звездам приписывать. Вообще привязываться к реальным данным дело хорошее, но муторное. Проще наверное все таки сочинить свою карту.

Balancer>Никогда не забуду кайф, полученный во Frontier'е от полётов к планетам, вертящимся вокруг двойных звёзд по охрененным орбитам Когда по неделе внутри системы летать приходилось с постоянным ускорением Мгновенный прыжок на пару десятков светолет и потом долгое и нудное подгребание к станции...

Эх, жаль я не пробовал

Не согласен. Это только если гиперканалы фиксированны. Если же нет - то определяющим является либо глубина гравитационной ямы, либо напряженность поля. IMHO скорее глубина ямы. То есть грубо говоря привод может компенсировать 10 км/с разницы скорости. Если ты прыгаешь в систему коричневого карлика - то изволь сначала выйти на переферию стартовой системы, если к сверхгиганту - наоборот зайти в систему поглубже, чтобы потом было меньше лететь.

Ну, и конечно, допустимая величина компенсации зависит от гипердвижка. К примеру, марк1 - это 10 км/c, а марк-5 скажем 320 .

То есть если надо попасть в лабораторию на низкой орбите вокруг нейтронной звезды - то сначала придется прыгнуть на переферию системы, а потом долго и нудно ковылять к звезде сбрасывая скорость. А потом набирать ее обратно, бе иначе гипердвигатель не сможет вытащить тебя из 'ямы' и сгорит. Прыжок внутри системы запрещен. Скажем, какое-то фундаментальное ограничение на прыжки меньше 1 светогода .

piton>Эээ... не совсем понял как это? То есть первоначальная карта подбирается случайно, а потом к ней относятся как к статичной и уже твердо существующей или каждый раз карта создается заново? Не понимаю...

Вот, народ уже фундаментальные принципы забывает Во времена, когда памяти программ была сотня байт, а всей памяти было 15 регистров (ПМК), обычно для генерации использовались функции вида f1(rnd(f2(x), f3(y))). Т.е. в зависимости от координат, которые использовались в качестве инициатора, получали через генератор псевдослучайных чисел некие параметры. Напомню, что все ГПСЧ можно программировать определённым стартовым числом, и последовательность псевдослучайных чисел для каждого стартового числа будет одинаковой.

Впоследствии подобные методы применялись, например, в Элите, где были десятки тысяч звёзд с довольно подробной информацией и вразумительными названиями, при том, что код+данные должны были умещаться в ~42кБ ОЗУ А там ещё и 3D, и всё такое прочее

piton> По моему проще разочек "нарисовать" в базе все параметры расположения звезд (какие они, сколько у них планет, сколько у каждой из планет спутников, какие на них условия и проч) и потом привязываться к крохотному куску кода в базе. Два раза в сутки база приводится в соответствие с выполненными игроками ходами и все нормально.

Для карты в пару сотен звёзд - нормально. Но в перспективе хочется чего-то типа Фронтировской карты

piton>Эх, жаль я не пробовал

Дык, качай EliteII: Frontier ( /Авиабаза =KRoN=/) - оно и на сегодня ещё вполне играбельно. Графика, правда, 320x200 и чтобы запустить придётся немного повозиться (надо много DOS-памяти высвобождать), но оно того стоит, особенно, если ещё ни разу не играл. Всё равно с тех пор достойного продолжения не вышло

hcube>Прыжок внутри системы запрещен. Скажем, какое-то фундаментальное ограничение на прыжки меньше 1 светогода

От технологии зависит. Скажем, джамп - вообще строго по 12 с чем-то там светолет. Фундаментальная константа. Зато - мгновенно.

Balancer>Вот, народ уже фундаментальные принципы забывает Во времена, когда памяти программ была сотня байт, а всей памяти было 15 регистров (ПМК), обычно для генерации использовались функции вида f1(rnd(f2(x), f3(y))). Т.е. в зависимости от координат, которые использовались в качестве инициатора, получали через генератор псевдослучайных чисел некие параметры. Напомню, что все ГПСЧ можно программировать определённым стартовым числом, и последовательность псевдослучайных чисел для каждого стартового числа будет одинаковой.

Аха! То есть другими словами, задаем координаты одной звезды и правила формирования характеристик и параметров остальных?
А вообще я и не говорил что знаю все фундаментальные правила Я и прграмить то начал буквально 5 лет назад, причем сунубо прикладные, одномоментные приложения Так что могу позволить себе ошибаться

Balancer>Для карты в пару сотен звёзд - нормально. Но в перспективе хочется чего-то типа Фронтировской карты

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

Balancer>Дык, качай EliteII: Frontier ( /Авиабаза =KRoN=/) - оно и на сегодня ещё вполне играбельно. Графика, правда, 320x200 и чтобы запустить придётся немного повозиться (надо много DOS-памяти высвобождать), но оно того стоит, особенно, если ещё ни разу не играл. Всё равно с тех пор достойного продолжения не вышло

Вот именно из-за лени и не играл, а так архивчик то есть

hcube>>Прыжок внутри системы запрещен. Скажем, какое-то фундаментальное ограничение на прыжки меньше 1 светогода

Balancer>От технологии зависит. Скажем, джамп - вообще строго по 12 с чем-то там светолет. Фундаментальная константа. Зато - мгновенно.

Что то мне это все Лукьяненко напоминает А кто будет играть за счетчиков?

piton> Аха! То есть другими словами, задаем координаты одной звезды и правила формирования характеристик и параметров остальных?

Ага.

piton> А вообще я и не говорил что знаю все фундаментальные правила

Да это просто бурчание в духе трава была зеленее, вода мокрее, а программисы - программистнее

piton> Что то мне это все Лукьяненко напоминает

Так про него и говорил

piton> А кто будет играть за счетчиков?

Найдём... Главное - ключников по ошибке не завести Хотя... можно и их

Как определитесь с базовым набором правил, могу накатать БД, ходовой процессор и простенький интерфейс.

А кстати, на чем писать то будете, государи програмисты? Я так понимаю все основные операции все равно средствами сервера будут? Значит что нибудь в роде PHP?
А то я уже и книжку по нему себе заказал :):)

piton>А кстати, на чем писать то будете, государи програмисты?

Я так думаю, что серверную часть лучше писать на Perl'е, интерфейсную - на PHP.

На Forth!
Соглашение с Кроном уже достигнуто.

Рома какой перл?
Мы договаривались о форте! Уговор дороже денег.

И разберись со скандалом Бывают войны и в головах... (moderatorials)
ЭТО ТВОЯ ПРЯМАЯ ОБЯЗАННОСТЬ!!

TEvg>Рома какой перл?
TEvg>Мы договаривались о форте! Уговор дороже денег.

Под Linux нет толковых версий Forth'а

TEvg>И разберись со скандалом Бывают войны и в головах... (moderatorials)
TEvg>ЭТО ТВОЯ ПРЯМАЯ ОБЯЗАННОСТЬ!!

Я уже говорил - не хотите мне присылать ссылки на непотребства, давайте выбирать дополнительных модераторов

piton>> Аха! То есть другими словами, задаем координаты одной звезды и правила формирования характеристик и параметров остальных?
Balancer>Ага.

Неее-а. Если в планах коллонизация/модификация планет, то одной только расстановкой звёзд дело не кончится.

КАК расставить звёзды по карте - по большому счёту дело десятое коль скоро карта у нас неизменная во времени. Скачать уже готовую карту или код для картогенератора - это всё мелочи.

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

Это-то и будет основной объём пересылки.

piton>>> Аха! То есть другими словами, задаем координаты одной звезды и правила формирования характеристик и параметров остальных?
Balancer>>Ага.

Да, это я как-то не совсем точно "ага" сказал Просто для заданного сектора пространства имеем одну звезду. По координатам считаем её параметры, параметры её планет и т.п.

yuu2>Неее-а. Если в планах коллонизация/модификация планет, то одной только расстановкой звёзд дело не кончится.

Естественно. Но в "большой Вселенной" только лишь малая часть звёзд реально колонизирована Вот для них уже можно хранить полную информацию. Вообще, всем рекомендую для разнообразия в ту же Элиту полетать, посмотреть какой огромный и подробный космос можно слепить в таких скромных требованиях

Resurrector>Кстати, какие у нас системные ограничения?

Думаю, пару гигабайт диска под это дело не жалко. Оперативки пару раз в сутки и мег по 100-200 не жалко выделить

Resurrector>А, ОС, кажется, Линукс. Что-ж, будем линуксные бинарики крутить, наместо оконных.

Угумс. Можно и так. Хотя я склонен больше не Perl'у, он безопаснее, утечки памяти реже гораздо бывают и т.п. А скорость - нам хватит. Не realtime...

yuu2>Неее-а. Если в планах коллонизация/модификация планет, то одной только расстановкой звёзд дело не кончится.

yuu2>КАК расставить звёзды по карте - по большому счёту дело десятое коль скоро карта у нас неизменная во времени. Скачать уже готовую карту или код для картогенератора - это всё мелочи.

yuu2>Всё дело в том, что по итогам хода для каждой планеты необходимо обновлять данные о её ресурсах/населении/промышленности. Равно как для каждого флота.

yuu2>Это-то и будет основной объём пересылки.

Так может имеет смысл параллельно и тот и другой механизм работать? Всмысле на этапе размышлений и первых созданий. Одна группа реализует статику как я предлагал, другая как Роман, потом тестовый прого и того и другого, обсуждение итогов и выбор?

Динамику IMHO следует делать на уровне миссий - это 'потом' . То есть сохранился, пошел в оффлайновую игрушку, в которой есть все данные о вселенной, относящиеся к квесту (но так, чтобы пользователю было не добраться ), прошел квест с какими-то потерями и приобретениями (из числа возможных), при следующем сеансе оно это взад кинуло.

Что же до механизма реализации хода... хмм... ну, даже не знаю . Можно и на перле, и на форте, и на пхп... главное систему продумать, ход не самое важное, важны правила. Но поскольку система будет работать с онлайновым интерфейсом, то все равно PHP придется использовать. Так зачем умножать сущности сверх необходимого? Я бы еще понял, если бы быстродействия не хватало...

Да, за базу я бы взял vga planets или stars. Это позволит хоть от чего-то оттолкнуться. Единственно - там надо усложнить планетарно-звездную систему. Одна мгновенно достижимая планета на систему провоцирует раши .

hcube>Динамику IMHO следует делать на уровне миссий - это 'потом'

Ты 3D, "Элиту" имеешь в виду? Да, я именно так и предполагал. При чём со взаимодействием "стратегических" игроков с офлайновыми "летателями" - т.е. "стратеги" дают квесты, устанавливают нужное оборудование и т.п.

hcube>Но поскольку система будет работать с онлайновым интерфейсом, то все равно PHP придется использовать. Так зачем умножать сущности сверх необходимого? Я бы еще понял, если бы быстродействия не хватало...

PHP хорош для интерфейсов. Но для обсчёта ходов понадобится запускать скрипты по cron'у. А тут Perl немного удобнее Да и как числодробилка он лучше. Не говорю уже про строки Больше возможностей для управления процессами и т.п.

Кстати, какие у нас системные ограничения?
Винт, память, ОС?
А, ОС, кажется, Линукс. Что-ж, будем линуксные бинарики крутить, наместо оконных.

hcube>Ключевые вопросы :
hcube>- устройство вселенной
hcube>- боевая и экономическая модели
hcube>- дизайн кораблей
hcube>- генерация событий
hcube>- 'внеигровая' деятельность во вселенной.

Давайте с первой разберемся, а потом все остальное приписывать будем.
Кстати, мое мнение такое: боевая часть должна игроку стоить больших усилий. А то только войны во вселенной и будут.
А еще такой вопрос возникает, сколько всреднем потребуется игрокам, чтобы достич огромных успехов и контролировать множество звезд, а может и множество других игроков! Если это будет осуществимо за относительно малое количество ходов, играть будет не интересно...

hcube>Удобнее, когда и интерфейс и ядро могут быть разобраны одним человеком

Удобнее, когда человек знает и PHP и Perl Я считаю, что это дополняющие друг друга языки, и не конкуренты.

hcube>Кстати, то что PHP медленнее перла - НЕ ВЕРЮ.

А проверить трудно?

WinXP, 1200MHz / Linux RH 7.3, 1800MHz:
PHP: for($i=0; $i<100000000; $i++) $sum=+$i; - 149 / 157 сек
Perl: for($i=0; $i<100000000; $i++) { $sum=+$i; } - 83 / 66 сек
Perl: $sum=+$_ for(1 .. 100000000); - 42 / 30 сек

PHP: for($i=0; $i<100000000; $i++) $a[$i%10000]=$i; - 240 / 204 сек
Perl: for($i=0; $i<100000000; $i++) { $a[$i%10000]=$i; } - 107 / 89сек
Perl: $a[$_%10000]=$_ for(1 .. 100000000); - 91 / 57 сек

PHP-Linux: 4.3.1, PHP-Win32: 4.3.1, Perl-Linux: 5.6.1, Perl-Win32: 5.8.0. Под Windows - оригинальные бинарники, под Linux Perl из пакета, PHP - собран.

Ещё вопросы по скорости есть?

hcube>Там же не строковые операции будут, а чисто числовые.

Вообще, под "более удобной числодробилкой" я имел в виду более удобный синтаксис

А строковые операции БУДУТ. И много.

hcube>Тут основная проблема не на чем писать, а что писать



hcube>Ключевые вопросы :
hcube>- устройство вселенной

Плоская статическая модель, основа - звёзды.

hcube>- боевая и экономическая модели

Боевая модель что-то типа AD&D, полагаю
Экономика - что-то незамкнутое, с источниками ресурсов, цепочкой производства и в конце - поглощение (например, гибель ресурсов в звёздных войнах )

hcube>- дизайн кораблей

Собираются из готовых модулей, особенности которых зависят от конкретных рас и их технического уровня.

hcube>- генерация событий

На первых порах, наверное - GM

hcube>- 'внеигровая' деятельность во вселенной.

В смысле - скрытая от нас? - тогда пока никакой. Впоследствии - ИИ. В смысле общения вне игры? У меня есть несколько идей на тему как максимально усложнить взаимное опознавание игроков Начиная с отсутствия доступных игрокам абсолютных координат, кончая трудностями во внутриигровом общении

Тьфу, блин, только сейчас заметил ошибку, что вместо += написал всюду =+. Но соотношение всё равно не изменится

Кстати, ещё один ОГРОМНЫЙ плюс Perl'а в том, что в режиме use strict он ловит все неинициализированные переменные, поэтому намного ниже вероятность допустить ошибку. Кроме того, на Perl'е удобнее работать с массивами и списками и вышеупомянутыми строками.