Здравствуйте, loknalori, Вы писали: L>В принципе, тоже, вариант. Но только надо отдавать себе отчет, что это путь к игрушке для программистов.
Не согласен, т.к. если всё правильно сделать....
Сразу говорю речь о многопользовательской он-лайн игре, значит идея том, чтобы дать возможность игрокам создавать свои игровые объекты, но при этом люди, далекие от программирования смогут играть в игру пользуясь достижениями (программками) других игроков...
Фактически должен получиться саморазвивающийся мир, в котором администраторам нужно будет только одно — управлять средой (устанавливать ограничения), которые будут влиять на все объекты, созданные игроками.
И потом что мешает обычному игроку попросить своего товарища программиста за N игровых денег, заработанных например на квестах, создать какой-ни-буть "мегазавод по производству мегалазеров", спокойненько получать с него игровую прибыль и пагрейдить свою колонию за чсет покупки технологий у соседей?
Есть ли смысл ограничиваться жанром стратегии? Я бы предложил многопользовтельскую он-лайн role play game, с элементами стратегии, тогда игрок сможет ассоциировать себя с персонажем игры, от лица которого он играет, это повысит интерес от игры, как мне кажеться. К тому же в RPG можно встроить элементы стратегии. Просто игрок сможет выбрать линию игры... либо он качает одного "мегагероя" либо создает армию андроидов и управляет ими от лица своего героя...
Это всё сырые идеи... если реально интересно, то стоит сесть и расписать основные пинципы построения игрового мира, как они будут выглядеть с точки зрения игрока, и уже на основе этого пытаться выстроить архитектуру приложения...
И еще почему меня интересует именно многопользовательская он-лайн игра:
1) Очень интересно играеть с живыми людьми
2) Совершенно другой уровень сложности приложения (для меня это сложно и, поэтому, интересно)
3) Если всё сделать правильно — в это будут играть люди, причем не только программисты.
Здравствуйте, tripolox, Вы писали:
T>Здравствуйте, loknalori, Вы писали: L>>В принципе, тоже, вариант. Но только надо отдавать себе отчет, что это путь к игрушке для программистов. T>Не согласен, т.к. если всё правильно сделать....
T>Сразу говорю речь о многопользовательской он-лайн игре, значит идея том, чтобы дать возможность игрокам
T>И потом что мешает обычному игроку попросить своего товарища программиста за N игровых денег, заработанных например на квестах, создать какой-ни-буть "мегазавод по производству мегалазеров", спокойненько получать с него игровую прибыль и пагрейдить свою колонию за чсет покупки технологий у соседей?
В таком виде этим ни кто заниматься не будет. Зачем мне играть в игру в которую я не могу полноценно играть в силу свой профессиональной направленности???
А выход есть, и очень простой: предоставляем базовый пользовательский интерфейс, которым можно управлять обьектами (сиюминутно) + программный интерфейс, где уже реализовано все-все-все.
T>Есть ли смысл ограничиваться жанром стратегии?
По этому поваду в этой ветке уже писали. Чтоб был RPG — кто-то должен придумывать квесты, чтоб не было скучно играть. Причем придумывание должно носить регулярный характер. А кто это будет делать? Это раз. Два: человек начавший года назад имеет ОГРОМНОЕ преимущество над тем кто начал только что. Значит надо сюжетными мероприятиями сделать так, чтобы не было ни смысла, ни интереса гасить новых игроков. А эти сюжетные мероприятия — ОГОГО какое колличество человеко-ресурсов. Мы это не потянем по любому. Три: чисто техническое. В виду безбюджетности проекта грамотно баланс сил подобрать не удастся + баги всякие вылезут. Это значит что вводить изменения проще после каждой партии нежели в процессе бесконечной игры Четыре: Если очень-очень хочется RPG можно сделать стратегию с элементами RPG, а-ля Warcraft 3
T>Это всё сырые идеи... если реально интересно, то ...
Самое главное, понять сколько нас тут есть, тех, кто желает этим заняться в свободное время...
Здравствуйте, loknalori, Вы писали:
L>А выход есть, и очень простой: предоставляем базовый пользовательский интерфейс, которым можно управлять обьектами (сиюминутно) + программный интерфейс, где уже реализовано все-все-все.
Согласен
T>>Есть ли смысл ограничиваться жанром стратегии? L>Если очень-очень хочется RPG можно сделать стратегию с элементами RPG, а-ля Warcraft 3
Да, про чисто РПГ я не заикаюсь... Согласен.
L>Самое главное, понять сколько нас тут есть, тех, кто желает этим заняться в свободное время...
Мне интересно.
Здравствуйте, loknalori, Вы писали:
T>>Это всё сырые идеи... если реально интересно, то ...
L>Самое главное, понять сколько нас тут есть, тех, кто желает этим заняться в свободное время...
Мне было бы интересно поработать над идеей, описанной в моем предыдущем посте
Здравствуйте, Macedonian, Вы писали:
M>Здравствуйте, loknalori, Вы писали:
T>>>Это всё сырые идеи... если реально интересно, то ...
L>>Самое главное, понять сколько нас тут есть, тех, кто желает этим заняться в свободное время... M>Мне было бы интересно поработать над идеей, описанной в моем предыдущем посте
Итого: Нас уже трое, а это значит порог критического минимума мы перевалили.
Надо: Определиться с постановкой задачи, чтоб было примерно понятно что мы делаем и в какую сторону.
Проблемы: Встретится "под пиво" полным составом как, я понял не получится, ибо 2е в Москве, 1н в Комсомольске-на-Амуре, что далековато. Поэтому, предлага каждому из нас с учетом всего выше сказанного составить мини-ТЗ (без детализации), прочитать их, поругать друг друга и прийти к какой-то начальной позиции, после чего думать на счет обращения к RSDN Team
Здравствуйте, loknalori, Вы писали:
L>Надо: Определиться с постановкой задачи, чтоб было примерно понятно что мы делаем и в какую сторону.
Предлагаю сначал понять что делаем...
Я думаю теперь о стратегии с возможностью программировать своих юнитов (т.е. начиная от их возможностей и заканчивая алгоритмами их поведения)?
L>Проблемы: Встретится "под пиво" полным составом как, я понял не получится, ибо 2е в Москве, 1н в Комсомольске-на-Амуре, что далековато. Поэтому, предлага каждому из нас с учетом всего выше сказанного составить мини-ТЗ (без детализации), прочитать их, поругать друг друга и прийти к какой-то начальной позиции, после чего думать на счет обращения к RSDN Team
Еще из идей:
Предлагаю разделить проект на несколько частей: UI, Core, Environment, где
UI — ну тут ясно, графика, ввод ну и т.п.
Core — это ядро системы, которое отвечает обработку программируемых игроком объектов, т.е. содержит иерархию классов, необходимую для создания юнитов к игре... (возможно на первой итерации можно просто ограничиться алгоритмами поведения готовых юнитов)
Environment — эта часть в которая "содержит" все объекты игровой реальности, т.е. фактически набор параметров которые ограничивают возможности каждого объекта, эта часть и будет отвечать за баланс в игре, т.е. несбалансированный объект просто не сможет существовать в этой среде, или же его возможности будут ограничены средой, как это сделать это задача..., которую предстоит решить...
Ваше мнение?
L>Голосуем. Я —
Я —
Что должно входить в "Мини ТЗ"?
Предлагаю дополнить твою идею программирования поведения юнитов до программирования самих юнитов, только тут придется решать вопрос с балансом...
L>>4) Пути решения L>>Сервер, в котором живет игровой мир. Скорее всего сервер работающий по принципу базы данных, т.е. каждый «тик» идет пересчет сотояний системы с сохранием некоторого предидущего устойчивого состояния.
M>Если сохранять предыдущие состояния, то игрок может "отмотать назад" историю игры до какого-либо интересного ему события (например, сражения) и оценить работу своих и вражеских алгоритмов на практике. Опять же попытка уменьшить значение сиюминутного присутствия игрока.
Еще понравилась идейка: клиент научить работать ка ScreenSaver — отлучился от компютера, вернулся, и видишь как твои подопечные завоёвывают жизненное пространство...
Здравствуйте, tripolox, Вы писали:
T>Здравствуйте, Macedonian, Вы писали:
T>Предлагаю дополнить твою идею программирования поведения юнитов до программирования самих юнитов, только тут придется решать вопрос с балансом...
Есть идея по этому поводу. Можно (в принципе, без этого никак ) ввести набор обязательных характеристик юнита (скорость перемещения, дальность стрельбы, величина урона, хитпоинты, время постройки и т.д.) и каждая единица такой характеристики будет стоить определенных ресурсов. Суть в том, что игрок собирает юнитов с заданными им характеристиками сам. Пример (от лица одного из игроков):
Начало игры, Х ед. ресурса.
Решил создавать юнитов с высокой дальнобойностью и низкими HP. Назначенные характеристики обойдутся в 100 ед. за штуку, попросил главный завод изготовить 5 штук таких (итого 500 ед.). Затем понадобилось несколько юнитов с высокими HP, оказалось, что данные характеристики не вкладываются в бюджет (250 ед. за штуку), решил пожертвовать скоростью перемещения и дальностью стрельбы. В итоге получилось 150 ед. за юнит. И т.д.
В итоге — минимум проблем с балансом, т.к. у каждого игрока изначально одно и то же количество ресурса. Зависимось цены от величины характеристики можно сделать нелинейной, дабы избежать появления юнитов с одной характеристикой, установленной в максимально большое значение, а остальными — в минимальное (дисбаланс ). Проблемы с внешним видом таких конструкторов, думаю, решатся без лишних проблем.
Еще есть идея внести элемент пошаговости, т.е. всю партию (думаю, что игра в виде отдельных партий (1х1, 2х2, NxN) — оптимальный вариант) разбить на отдельные элементы (ходы). После того, как каждый сделал по ходу (если ходы делаются одновременно — снова убиваем дисбаланс), либо после каждого хода (ходы делаются по очереди — тот, кто ходит первым, получает преимущество ) происходят различные события, являющиеся результатом ходов соперников, на которые (на события) уже не повлиять (ход сделан), т.е. кто-то кого-то убил, переместился, выиграл партию и т.д. Следующий ход начинается с анализа произошедших событий и новой сложившейся ситуации. Изначально можно обойтись минимумом графики (важна лишь конечная ситуация после хода), затем уже добавить ролики событий (в том числе ScreenSaver'ы ). Определять продолжительность между ходами можно используя время, плюс можно поставить лимит на использование ресурсов за один ход.
Используя одновременные ходы + юниты-конструкторы добиваемся приблизительного (полного? ) стратегического баланса.
L>>>4) Пути решения L>>>Сервер, в котором живет игровой мир. Скорее всего сервер работающий по принципу базы данных, т.е. каждый «тик» идет пересчет сотояний системы с сохранием некоторого предидущего устойчивого состояния.
M>>Если сохранять предыдущие состояния, то игрок может "отмотать назад" историю игры до какого-либо интересного ему события (например, сражения) и оценить работу своих и вражеских алгоритмов на практике. Опять же попытка уменьшить значение сиюминутного присутствия игрока.
T>Еще понравилась идейка: клиент научить работать ка ScreenSaver — отлучился от компютера, вернулся, и видишь как твои подопечные завоёвывают жизненное пространство...
Либо как своих незаслуженно бьют
Интересная идея
Здравствуйте, loknalori, Вы писали:
L>Итого: Нас уже трое, а это значит порог критического минимума мы перевалили.
L>Надо: Определиться с постановкой задачи, чтоб было примерно понятно что мы делаем и в какую сторону.
L>Проблемы: Встретится "под пиво" полным составом как, я понял не получится, ибо 2е в Москве, 1н в Комсомольске-на-Амуре, что далековато. Поэтому, предлага каждому из нас с учетом всего выше сказанного составить мини-ТЗ (без детализации), прочитать их, поругать друг друга и прийти к какой-то начальной позиции, после чего думать на счет обращения к RSDN Team
L>Голосуем. Я —
Думаю, есть смысл создавать ТЗ совместными усилиями, иначе каждый придумает свою собственную цельную концепцию игры и будет ее яростно защищать
Здравствуйте, tripolox, Вы писали:
T>Здравствуйте, loknalori, Вы писали:
L>>Надо: Определиться с постановкой задачи, чтоб было примерно понятно что мы делаем и в какую сторону. T>Предлагаю сначал понять что делаем... T>Я думаю теперь о стратегии с возможностью программировать своих юнитов (т.е. начиная от их возможностей и заканчивая алгоритмами их поведения)?
Это хорошо, я тоже об этом думаю
L>>Проблемы: Встретится "под пиво" полным составом как, я понял не получится, ибо 2е в Москве, 1н в Комсомольске-на-Амуре, что далековато. Поэтому, предлага каждому из нас с учетом всего выше сказанного составить мини-ТЗ (без детализации), прочитать их, поругать друг друга и прийти к какой-то начальной позиции, после чего думать на счет обращения к RSDN Team
T>Еще из идей: T>Предлагаю разделить проект на несколько частей: UI, Core, Environment, где T>UI — ну тут ясно, графика, ввод ну и т.п. T>Core — это ядро системы, которое отвечает обработку программируемых игроком объектов, т.е. содержит иерархию классов, необходимую для создания юнитов к игре... (возможно на первой итерации можно просто ограничиться алгоритмами поведения готовых юнитов) T>Environment — эта часть в которая "содержит" все объекты игровой реальности, т.е. фактически набор параметров которые ограничивают возможности каждого объекта, эта часть и будет отвечать за баланс в игре, т.е. несбалансированный объект просто не сможет существовать в этой среде, или же его возможности будут ограничены средой, как это сделать это задача..., которую предстоит решить... T>Ваше мнение?
Предлагаю вопросы архитектуры оставить на время, а сначала определиться с требованиями
Здравствуйте, Macedonian, Вы писали:
M>Здравствуйте, tripolox, Вы писали:
T>>Здравствуйте, Macedonian, Вы писали:
M>Есть идея по этому поводу. Можно (в принципе, без этого никак ) ввести набор обязательных характеристик юнита (скорость перемещения, дальность стрельбы, величина урона, хитпоинты, время постройки и т.д.) и каждая единица такой характеристики будет стоить определенных ресурсов.
Без этого никак... M>Суть в том, что игрок собирает юнитов с заданными им характеристиками сам. Пример (от лица одного из игроков):
Я немного не о том говорю — игрок может сам программировать своих юнитов, или, например запчасти, из которые потом использовать при сборе юнитов. Мы предоставляем для этого интерфейсы и иерархию классов...
M>Еще есть идея внести элемент пошаговости
Я против пошаговости, т.к. ИМХО гораздо интереснне наблюдать за реализованным алгоритмом в реальном времени.
Т.е. (например), если говорить о программируемых юнитах, игрок реализовал танк с пушкой и рацией, и в зависимости от ситуации танки могут взаимодействовать по рации (например выстраиваться в боевые построения для атаки или защиты), таким образом можно будет в реальном времени видеть преимущества...
По графике — пусть пока спрайтики простые ползают...
Можно кстати в юнитах реализовать простейший PathFind, а игрок, сможет улучшить алгоритм чтобы юниты двигались более осмысленно (например заранее выбирали траекторию с препятствиями и просили по рации у своих юнитов уступить дорогу), это уже о программировании поведения, т.е. программировать не только атаку, но и например юнит атакует "МЕГА противника" и по рации вызывает подмогу, которая уже либо помогает, либо нет, в этом случае юнит отступает в ремонтный док, например.
Мысли так и скачут, потому и описал всё так сумбурно...
Здравствуйте, tripolox, Вы писали:
M>>Суть в том, что игрок собирает юнитов с заданными им характеристиками сам. Пример (от лица одного из игроков): T>Я немного не о том говорю — игрок может сам программировать своих юнитов, или, например запчасти, из которые потом использовать при сборе юнитов. Мы предоставляем для этого интерфейсы и иерархию классов...
Если процесс программирования юнитов заключается в определении характеристик (урон, хитпоинты и т.п.) и поведения (взаимодействие с другими юнитами, реакция на определенные события и т.п.), то мы думаем об одном и том же, иначе прошу уточнить.
M>>Еще есть идея внести элемент пошаговости T>Я против пошаговости, т.к. ИМХО гораздо интереснне наблюдать за реализованным алгоритмом в реальном времени. T>Т.е. (например), если говорить о программируемых юнитах, игрок реализовал танк с пушкой и рацией, и в зависимости от ситуации танки могут взаимодействовать по рации (например выстраиваться в боевые построения для атаки или защиты), таким образом можно будет в реальном времени видеть преимущества...
Если реализовывать без пошаговости, то получим проблему, которую необходимо избежать: значительно больший шанс на победу у игрока, затрачивающего на игру больше времени. Игровая ситуация постоянно меняется, что требует принятия своевременных решений. Например, идет партия, борьба равная, но на третий день наступила важная битва, а один из игроков, по какой-либо причине, не может играть (работа, учеба, ночь на дворе и т.д.). В итоге победа достается второму игроку. Несправедливо. После пары таких поражений опускаются руки. В случае пошаговости подобные случайности отсутствуют. До каждого принятия решения обе стороны видят одинаковую картину, после чего происходят события, являющиеся результатом совместного принятия очередного решения и вмешаться в эти события до определенного момента (следующего хода) уже нельзя.
По поводу наблюдения за созданным алгоритмом тоже нет проблем, необходимо лишь загрузить ролик от n-го до m-го хода.
T>Можно кстати в юнитах реализовать простейший PathFind, а игрок, сможет улучшить алгоритм чтобы юниты двигались более осмысленно (например заранее выбирали траекторию с препятствиями и просили по рации у своих юнитов уступить дорогу), это уже о программировании поведения, т.е. программировать не только атаку, но и например юнит атакует "МЕГА противника" и по рации вызывает подмогу, которая уже либо помогает, либо нет, в этом случае юнит отступает в ремонтный док, например.
Обобщая эту идею, можно задать разумные алгоритмы по умолчанию для самых распространенных действий. Игрок может задать свои алгоритмы для класса юнитов, группы юнитов, либо для отдельных юнитов. Поведение юнита получаем по следующей цепочке: алгоритм для конкретного юнита, для группы юнитов, для класса юнитов, по умолчанию. Т.е. наибольший приоритет у алгоритма для конкретного юнита, наименьший — у алгоритма по умолчанию.
Здравствуйте, Macedonian, Вы писали:
M>Если процесс программирования юнитов заключается в определении характеристик (урон, хитпоинты и т.п.) и поведения (взаимодействие с другими юнитами, реакция на определенные события и т.п.), то мы думаем об одном и том же, иначе прошу уточнить.
Да, об одном. Просто это именно программирование, когда для реализации сложной логики строится своя иерархия классов, например для взаимодействия юнитов, и о способе такого общения знают только юниты у которых реализованно общение с использованием этой иерархии...
M>Если реализовывать без пошаговости, то получим проблему, которую необходимо избежать: значительно больший шанс на победу у игрока, затрачивающего на игру больше времени. Игровая ситуация постоянно меняется, что требует принятия своевременных решений.
Я думал о том, что юниты живут своей жизнью, без команд игрока, действуя по заранее определенным алгоритмам. Режим управленимя юнитами можно применить в "дуэли", когда юниты в бою наример действуют сами по себе, но под чутким руководством игрока...
M>Например, идет партия, борьба равная, но на третий день наступила важная битва, а один из игроков, по какой-либо причине, не может играть (работа, учеба, ночь на дворе и т.д.). В итоге победа достается второму игроку. Несправедливо. После пары таких поражений опускаются руки. В случае пошаговости подобные случайности отсутствуют. До каждого принятия решения обе стороны видят одинаковую картину, после чего происходят события, являющиеся результатом совместного принятия очередного решения и вмешаться в эти события до определенного момента (следующего хода) уже нельзя.
Да, наверное этот вариант будет предподчительнее...
M>По поводу наблюдения за созданным алгоритмом тоже нет проблем, необходимо лишь загрузить ролик от n-го до m-го хода.
M>Обобщая эту идею, можно задать разумные алгоритмы по умолчанию для самых распространенных действий. Игрок может задать свои алгоритмы для класса юнитов, группы юнитов, либо для отдельных юнитов. Поведение юнита получаем по следующей цепочке: алгоритм для конкретного юнита, для группы юнитов, для класса юнитов, по умолчанию. Т.е. наибольший приоритет у алгоритма для конкретного юнита, наименьший — у алгоритма по умолчанию.
Таким образом игрок сможет отрабатывать алгоритмы на неком "тестовом" подмножестве юнитов например на специальной "площадке", а потом переносить этот алгоритм на воюющих юнитов, кстати можно иметь набор алгоритмов для разных стратегий, например решает игрок атаковать, назначает своим юнитам соответствующие алгоритмы, после чего смотрит как грамотно его боевые тараканы идут в бой выстроившись в каре... Или наоборот занимают круговую оборону вокруг хилой, но дальнобойной турели, которая в это время отстреливает нападающих... ВО!
Цитирую. t>Мысли так и скачут, потому и описал всё так сумбурно...
Именно по этому я и предлагаю, пусть каждый сам для себя напишет о чем он думает, запостит, а там обсудим.
m>Думаю, есть смысл создавать ТЗ совместными усилиями,
Я это и предлагаю. Просто разбрасывать все по форуму — потом замучиемся собирать, да и мысли надо четко изложить. Я, кстати, сейчас как раз такую маляву и пишу.
На счет ваших предложений — принципиально согласен, а детали в моей бумаге. Единственно 3 очень важных но (прошу откоментировать): 1) Игра — стратегия. Ни каких RPG. Иначе утонем. Если очень-очень хочется RPG — вводим понятие героев, которые могут хапать левел, но лучше не надо, иначе значительная часть игры будет уходить на контроль гроя (вспомним варкрафт)
2) Игра — реалтайм стратегия. Просто очень долгий риалтайм. В партии растянутой на несколько недель НЕОЖИДАННЫХ битв быть не может (сам проверял, факт), это раз, два — умеешь писать программы -пиши AI и наблюдай, не умеешь, контроль руками. Игра слишком медленая? Запусти сервер чтоб состояние там считалось не раз в минуту а раз в 2 секунды, вот и будет полный реалтайм.
3) Игра ориентирована на партии. Запустили партию, в процессе партии поигрались, пообкатывали скрипты (или отработали навыки руками), разработчики поняли что им надо проапдейтить и т.д. Запустили новую партию, и снова все равны (на старте) и начинается мясо с учетом предидущих игр. "Ты у меня выиграл? Ну, ужо погоди, у меня!"
Выношу на обсуждение Игровой Мир
ЗЫ Это не описание игры, это в двух словах о мире, чтоб упорядочить фантазии.
Стратегию можно делать и про Ген с Чебурашками, но надо нарисовать границы фантазии. Вначале хотел придложить про космос, но слишком избито, надо что-то оригинальнее.
Островные государства. Есть поверхность моря, которая занимает БОЛЬШУЮ часть пространства. Не менее 95 %. Суша делится на 2 части — острова-для-жизни, где есть заводы, бараки, фермы, верфи и т.п. И острова-для-ресурсов, на которых можно только добывать ресурсы или, например, строить форты. Ресурсы, также, добываются из моря (рыба, удобрения и тп). Люди размножаются, заселяют новые острова, занимаются наукой и тп. Цунами, состояние моря на момент битвы, видимость (тумааная часть окена), ну и море факторов влияющих на игру. В результате мы получаем мир, который
1) Оригинальный (таких стратегий на слуху что-то не помню)
2) требует серьезного экономического AI (или будте любезны, руками в цикле), туда сюда рыбу, воду и тп. возить
3) С достаточно локализоваными битвами Битва — точка в море, ни каких расползаний по квадрату
4) С возможностью варировать наземные битвы (будет у нас время — сделаем чтоб можно контролировать часть острова, нет — остров имеет единое состояние, либо твой, либо нет)
5) С огромным пространством для маневра. Эх, какое море. Да и острова можно размещать по разному — сферами альянсами — случайно и тп.
L>3) С достаточно локализоваными битвами Битва — точка в море, ни каких расползаний по квадрату
Можите не правильно понять. Я имел в виду, битва — одна точка глобального пространства. А уже внутри битвы есть квадраты для маневра и тп.
Здравствуйте, tripolox, Вы писали: M>>Например, идет партия, борьба равная, но на третий день наступила важная битва, а один из игроков, по какой-либо причине, не может играть (работа, учеба, ночь на дворе и т.д.). В итоге победа достается второму игроку. Несправедливо. После пары таких поражений опускаются руки. В случае пошаговости подобные случайности отсутствуют. До каждого принятия решения обе стороны видят одинаковую картину, после чего происходят события, являющиеся результатом совместного принятия очередного решения и вмешаться в эти события до определенного момента (следующего хода) уже нельзя. T>Да, наверное этот вариант будет предподчительнее...
Нихт-нихт. Для этого играющие должны сидеть онлайн. А о чем речь, если мы даже тут (при обсуждении) находимся в разное время??? Категорически нихт.
T>Таким образом игрок сможет отрабатывать алгоритмы на неком "тестовом" подмножестве юнитов например на специальной "площадке", а потом переносить этот алгоритм на воюющих юнитов, кстати можно иметь набор алгоритмов для разных стратегий, ВО!
Да, оно. Кстати, если игра удастся, то будет класной площадкой для отработки AI.
L>Самое главное, понять сколько нас тут есть, тех, кто желает этим заняться в свободное время...
Я бы очень хотел поочавствовать, но у меня опыта никакого .
... << RSDN@Home 1.1.4 @wamp>>
It’s never too late to take a fucked up life to a beautiful state.
(c) Crazy Town
Здравствуйте, loknalori, Вы писали:
L>>3) С достаточно локализоваными битвами Битва — точка в море, ни каких расползаний по квадрату L>Можите не правильно понять. Я имел в виду, битва — одна точка глобального пространства. А уже внутри битвы есть квадраты для маневра и тп.
Зачем? Почему не ограничиться одним пространством (картой), зачем вводить дополнительные "экраны", ИМХО нуно делать всё максимально просто...
это задача..., которую предстоит решить... 
) ввести набор обязательных характеристик юнита (скорость перемещения, дальность стрельбы, величина урона, хитпоинты, время постройки и т.д.) и каждая единица такой характеристики будет стоить определенных ресурсов. Суть в том, что игрок собирает юнитов с заданными им характеристиками сам. Пример (от лица одного из игроков):
). Проблемы с внешним видом таких конструкторов, думаю, решатся без лишних проблем.
) происходят различные события, являющиеся результатом ходов соперников, на которые (на события) уже не повлиять (ход сделан), т.е. кто-то кого-то убил, переместился, выиграл партию и т.д. Следующий ход начинается с анализа произошедших событий и новой сложившейся ситуации. Изначально можно обойтись минимумом графики (важна лишь конечная ситуация после хода), затем уже добавить ролики событий (в том числе ScreenSaver'ы 
) стратегического баланса.
Цитирую.
