[Sphynx55]

Приветствую всех. Хочу представить мой проект начатый еще в школьные годы ( много-много лет назад ). Когда-то была у меня сонька (еще первая), и была на нее игруха RedAlert. Я был так впечатлен этой игрой, что захотел создать свою с̶ ̶б̶л̶э̶к̶д̶ж̶е̶к̶о̶м̶ ̶и̶. Как только дома появился ПК - я начал творить .
Мелочиться я не стал - карты до 2000х2000 (против 126х126 в оригинале), и соответственно таким картам до 1000000 юнитов, да да я захотел МИЛЛИОН юнитов .
Самое простое и доступное средство для меня было Delphi, и весь проект написан именно на нем. Код писал долго и упорно, периодически терял интерес и забрасывал. Собственно в таком виде он и остался по сей день - давным давно забытый и потерянный.
Что получилось на текущий момент можете оценить скачав архив. Для начала необходимо установить шрифт Visitor. Запускаться программка будет минуты 2 - попиксельно перекрашивая спрайты под разные команды . Как появится окно жмем кнопку Random, пару раз жмякнем ore, и затем MCV. Остальные кнопки не трогаем- на них может висеть все что угодно. На карте появятся 5 MCV которые начнут строить базу и танчики. Все что можно делать - это смотреть. Замес начнется минут через 5-10. Для центрирования карты, жмем по тексту Team1-Team5.
Если кого это заинтересовало, не стесняемся, спрашиваем.
Desktop.zip

[Sphynx55]

Научился выделять и отдавать юнитам команды. Теперь возник вопрос - как работать с группами юнитов ? Может кто занимался подобным, и подскажет способы и подводные камни.
Desktop.zip
Запускается быстро (без перекраски спрайтов). Рабочие кнопки Test и ADDtank.

[M.A.D.M.A.N.]

Хоть бы с исходником выкладывал.
Кстати, ты не пробовал из RA2 рисовать воксельных юнитов?

[Sphynx55]

Было дело, много что пробовал Вопрос исключительно терпения и усидчивости, мне этого не хватило, и решил использовать самый простой вариант со спрайтами.
Так-же пробовал разные "гейм-студии" и прочие свистелки - красиво, удобно, но слишком тормознуто. Загиб начинался уже при 300-400 юнитах, что просто смехотворно при моих масштабах.

[phomm]

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

Что мне не понравилось в демке. Залоченая карта (отображаемая область), сколько она там 20*30 клеток примерно, 500*400 примерно - очень неудобно. Это может быть продиктовано увеличением тормозов, конечно, но чисто графических тормозов, что как раз мог бы снять движок. Имхо было бы хорошо, если увеличение размера окна приводило к увеличению отображаемой области Также не понравилась система скроллинга карты, не всегда работает ожидаемо, скролит лишнее, или наоборот недостаточно отзывчиво.
Невнятно сделана функция нахождения, стоит как-то выделять найденного юнита, а то когда их много , теряешься, или надо дополнительно выделять его.

Насчет исходников, не поддержу Мэда, т.к. считаю, что автор сам это определяет, и имхо даже такой запрос как-то не айс. Но, если Вы, Sphynx55, вдруг надумаете, то было бы очень интересно изучить, т.к. исходников подобного рода очень мало в открытм доступе, и поскольку мне эта тема интересна, каждый проект позволяет чему-то да научиться, сравнить подходы (я тоже работаю по стратегиям и смежным темам).

Ну и вопрос простой, что мешает сделать готовые спрайты под все команды ? ну пусть они идентичны, места занимают всё равно немного, да и модифицировать потом легко будет.

[Sphynx55]

Если вы тоже занимались подобным, то наверняка поняли как это пожирает время. Я с удовольствием прикрутил бы движок (сейчас вся графика рисуется через канвас ImageList'ом ) , но нужно время, которого у меня нет. Сделать все спрайты - нужно время, и тд, ну вы поняли
По поводу количества юнитов, вы меня недооцениваете . В рамке Obj, параметр o: отражает текущее число объектов. Понятие объект и юнит я разделяю, так как, к примеру, танк состоит из корпуса и башни - из 2ух зависимых объектов. Зачем я так делал не помню, возможно хотел собирать "гибриды", поскольку башню можно прикрутить к чему угодно. На моем стареньком Athlon 630@3.6 подтормаживания начинаются при ~500К объектов, но до ~800К еще терпимо. Таким образом можно рассчитывать на 300К танчегов. Это создает куда более интересные трудности: как таким количеством управлять ? Если простенький ИИ без труда сгоняет всех в кучки, то как быть с человеко-кликером ? Собственно на этих проблемах я и завис.

[phomm]

Времени улетает, да, будь здоров.
Просто я пилил как GDI (winapi+canvas) системы , так и на движках, и при должном подходе работа с графикой может быть абстрагирована настолько, что хоть в конфиге меняй одну строчку и рендер с харда на софт перелючается.
Про спрайты я имел ввиду перекрашеные спрайты вложить в поставку демки, чтобы и разноцветные команды были и минуты на старте не съедать, увеличится размер, но вряд ли критично добавление пары мегов.

Насчёт объектов - после своего поста (и до Вашего) ещё запускал и тогда обратил внимание на параметры в боксе с объектами, особенно когда нажал 4tnks кнопку В итоге да, впечатляет, полагаю есть какие-то хитрые оптимизации в коде работы с объектами и аи, что-то может типа автомата плюс динамические списки, возможно даже бинаризация пространства какая-то. Без классов и циклов проверок клеток за каждого юнита. А вот многопоточки нет (насколько говорит диспетчер), загружает одно ядро на полную при большом колве танков, на многоядерниках вынести аи во второй поток дало бы прирост, думаю. В первом оставить пересчёт всяких координат и т.п. по графике.

Как быть с человеком - а что, обычный подход в стратегиях - "выделить всех кого хочешь и отправить на покорение" не подходит ? Есть ещё всякие "найти незанятый задачей юнит" "общий сбор" и т.п. , думаю, не вам рассказывать

[Sphynx55]

Получилось собрать простецкую игрульку. Чем-то напоминает BattleCity
Desktop.zip

[Admin]

Сообщение от Sphynx55

Получилось собрать простецкую игрульку. Чем-то напоминает BattleCity
Вложение 4318

А чего, скриншоты можно выложить в тему, что бы не заморачиваться с исходниками?

[M.A.D.M.A.N.]

Сообщение от Admin

А чего, скриншоты можно выложить в тему, что бы не заморачиваться с исходниками?

Бинарники там.

Неслабо так-то оперативки жрет программа.

[home284]

У меня дурацкий вопрос. Нигде не могу найти информацию про одновременную работу нескольких объектов, например в стратегиях. Каждый танк это отдельный поток? Есть свой класс который отвечает за столкновение объектов (например не больше одного объекта в клетке)?
И может вы подскажите какие-нибудь статьи о принципах построения таких вот игрушек?
В основном интересует как раз несколько юнитов на карте.

[M.A.D.M.A.N.]

Можно и одним потоком разруливать.

[Bargest]

У меня дурацкий вопрос. Нигде не могу найти информацию про одновременную работу нескольких объектов, например в стратегиях. Каждый танк это отдельный поток? Есть свой класс который отвечает за столкновение объектов (например не больше одного объекта в клетке)?
И может вы подскажите какие-нибудь статьи о принципах построения таких вот игрушек?
В основном интересует как раз несколько юнитов на карте.

Много потоков создадут много проблем, потому что потребуют синхронизации. Самый простой (и, думаю, самый применяемый метод) - сделать список динамических объектов, и каждую итерацию главного цикла игры проходить по списку и обрабатывать все действия.
Есть 2 турели. Обе в массиве. Обрабатываться они будут по очереди. Каждая будет анализировать состояние окружающей среды на предмет наличия врагов в зоне досягаемости, поворачиваться и стрелять. Разумеется, важно не делать все действия сразу, а разбить на атомарные. Грубо говоря, поворот на N градусов будет обработан за N проходов цикла, и в каждый проход будет поворот на 1 градус. Выстрел - тоже не мгновенная смерть: нужно создать "пулю" и добавить ее в список обработки. Пуля в свою очередь будет перемещаться на X метров за каждый проход. Если при обработке пули выяснилось, что пуля столкнулась с объектом - наносим повреждения и удаляем пулю.
Разбиение же на много потоков нагрузит систему и при этом не принесет никаких реальных отличий: если у процессора меньше ядер, чем одновременно запущенных потоков, то все равно они будут обрабатываться по очереди.