Движок Для Игры На Delphi

  1. Игры Для Двоих
  2. Игры Для Девочек Играть На 2
  1. Oct 27, 2004 - Движок любой игры складывается из многих и часто. Будут написаны на Delphi с применением GLScene, они будут полезны и тем, кто.
  2. DirectX-движок на Delphi. Written on 08 Января 2009. Posted in Delphi. 'Движок' - это перевод от английского 'engine' - т. На данный момент термин является общепризнанным, поэтому далее я буду придерживаться именно его (хотя само слово не очень стыкуется с правилами русского языка). Сначала небольшой экскурс в историю. Если планируется писать какую-то игру или мультимедийное приложение, лучше написать сначала движок для неё. Разработка более-менее крупной программы после маленьких развязывает руки, позволяет 'развернуться' программисту, реализовать некоторы свои амбиции. Вместе с тем работа по ловле ошибок довольно хлопотна и иногда раздражает.
  3. Подходят для создания игр. Пишеться движок для mmorpg за 2-3 дня. Софта на делфи.

Вторая версия открытого графического движка на Delphi, предназначенного для разработки 2D-игр.

Приветствую всех. Хочу представить мой проект начатый еще в школьные годы ( много-много лет назад ). Когда-то была у меня сонька (еще первая), и была на нее игруха RedAlert. Я был так впечатлен этой игрой, что захотел создать свою с̶ ̶б̶л̶э̶к̶д̶ж̶е̶к̶о̶м̶ ̶и̶.

Скачать гонки need for speed. Как только дома появился ПК - я начал творить. Мелочиться я не стал - карты до 2000х2000 (против 126х126 в оригинале), и соответственно таким картам до 1000000 юнитов, да да я захотел МИЛЛИОН юнитов.

Самое простое и доступное средство для меня было Delphi, и весь проект написан именно на нем. Код писал долго и упорно, периодически терял интерес и забрасывал. Собственно в таком виде он и остался по сей день - давным давно забытый и потерянный.

Что получилось на текущий момент можете оценить скачав архив. Для начала необходимо установить шрифт Visitor. Запускаться программка будет минуты 2 - попиксельно перекрашивая спрайты под разные команды. Как появится окно жмем кнопку Random, пару раз жмякнем ore, и затем MCV. Остальные кнопки не трогаем- на них может висеть все что угодно. На карте появятся 5 MCV которые начнут строить базу и танчики. Все что можно делать - это смотреть.

Замес начнется минут через 5-10. Для центрирования карты, жмем по тексту Team1-Team5. Если кого это заинтересовало, не стесняемся, спрашиваем. Всё круто, мои респекты автору. Билдеры строят, харвестеры собирают, танки месятся, игра живёт по известным законам. Сам удивляюсь как оно работает на такой массе юнитов, чисто по прикидкам, при тестах было порядка пары тысяч, притормозов каких-то не заметно.

Насчёт геймстудий воможно Вы правы, но есть всё-таки разница, конструктор какой и нормальный движок для стандартных операций типа управление окном, рендеринг, звук. Логика в движке будет Ваша, а системщина - уйдёт на плечи движка, и тут не должно быть никаких тормозов. Что мне не понравилось в демке. Залоченая карта (отображаемая область), сколько она там 20.30 клеток примерно, 500.400 примерно - очень неудобно. Это может быть продиктовано увеличением тормозов, конечно, но чисто графических тормозов, что как раз мог бы снять движок.

Игры Для Двоих

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

Насчет исходников, не поддержу Мэда, т.к. Считаю, что автор сам это определяет, и имхо даже такой запрос как-то не айс.

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

Ну и вопрос простой, что мешает сделать готовые спрайты под все команды? Ну пусть они идентичны, места занимают всё равно немного, да и модифицировать потом легко будет. Если вы тоже занимались подобным, то наверняка поняли как это пожирает время. Я с удовольствием прикрутил бы движок (сейчас вся графика рисуется через канвас ImageList'ом ), но нужно время, которого у меня нет. Сделать все спрайты - нужно время, и тд, ну вы поняли По поводу количества юнитов, вы меня недооцениваете.

Девочек

В рамке Obj, параметр o: отражает текущее число объектов. Понятие объект и юнит я разделяю, так как, к примеру, танк состоит из корпуса и башни - из 2ух зависимых объектов. Зачем я так делал не помню, возможно хотел собирать 'гибриды', поскольку башню можно прикрутить к чему угодно. На моем стареньком Athlon 630@3.6 подтормаживания начинаются при 500К объектов, но до 800К еще терпимо. Таким образом можно рассчитывать на 300К танчегов.

Для

Это создает куда более интересные трудности: как таким количеством управлять? Если простенький ИИ без труда сгоняет всех в кучки, то как быть с человеко-кликером?

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

Delphi

Игры Для Девочек Играть На 2

В первом оставить пересчёт всяких координат и т.п. Как быть с человеком - а что, обычный подход в стратегиях - 'выделить всех кого хочешь и отправить на покорение' не подходит?

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

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

Есть 2 турели. Обе в массиве. Обрабатываться они будут по очереди. Каждая будет анализировать состояние окружающей среды на предмет наличия врагов в зоне досягаемости, поворачиваться и стрелять. Условные обозначения табеля учета рабочего времени.

Разумеется, важно не делать все действия сразу, а разбить на атомарные. Грубо говоря, поворот на N градусов будет обработан за N проходов цикла, и в каждый проход будет поворот на 1 градус. Выстрел - тоже не мгновенная смерть: нужно создать 'пулю' и добавить ее в список обработки. Пуля в свою очередь будет перемещаться на X метров за каждый проход. Если при обработке пули выяснилось, что пуля столкнулась с объектом - наносим повреждения и удаляем пулю.

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

Posted on