Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > разработка игр, графический дизайн и моделирование > Gamedev - cоздание игр: Unity, OpenGL, DirectX
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 04.08.2019, 20:24   #1
rhiroceros
Пользователь
 
Регистрация: 07.05.2016
Сообщений: 23
По умолчанию Создание игры Gauntlet

Добрый день коллеги.

Хотел бы поделиться с вами одной идеей по поводу создания игр.

Сначала несколько сумбурно подведу вас к идее, а потом
на конкретном примере покажу вам о чем идет речь.

Давно заметил, что попытка разных модулей
обращаться к одному и тому же "физическому участку данных"
приводит к сильной связываемости этих модулей.
В некоторых случаях получается лучшие разбиение кода если
для каждого такого модуля сделать свой "физический участок данных"
и синхронизировать эти участки между собой.
Чем более логически независимы такие модули, тем уместнее
может быть такой выход из положения.
Просто как пример, что бы пояснить мысль:
Имеем два модуля, которые ссылаются на один массив,
они сильно связаны через этот массив.
Если мы каждому модулю сделаем свой массив,
модули перестают быть между собой связаны.
Для того что бы эти два модуля работали как положено,
нам необходимо только синхронизировать массивы.
Пояснение с массивом, это только как наглядный пример о чем я говорю,
а не как конкретная идея, пока относитесь к этому как к некой
абстрактной идей.
Чуть позже обратил внимание на то,
что если мне удается именно физически разделить модули
(это то же не всегда уместно) но если удалось,
то дает очень много, т.к. то что физически разделено,
то можно независимо друг от друга разрабатывать и тестировать.
(Конечно для корректной работы этих модулей данные между ними
необходимо синхронизировать)
Например:
Две базы данных, одна выполняя сложный алгоритм
формирует xml сохраняя его на диск,
другая загружает с диска xml и выполняет по нему сложный алгоритм.
Базы никак физически между собой не связаны,
разработка алгоритма формирования xml на одной базе, и разработка
выполнения по xml сложного алгоритма могут одновременно разрабатываться
двумя разными людьми и каждому из них нужна только своя база а
база другого не нужна.
Пояснение с базами и диском это то же как наглядный пример о чем я говорю.
На этом философствовать я закончу, потому что в этих вопросах иду так сказать на ощупь и не смогу с места сказать уместны ли описанные способы разделения в какой либо произвольной
конкретной задаче или не уместны.

Но вот в чем я все более становлюсь уверен, в том то физическое разделение с синхронизацией данных уместно в играх, в разделении графики игры от всей механики
самой игры. Что если механика - это контролер + модель а графика в игре это view, контролер + модель могут разрабатываться одним человеком,
а view другим, при этом кроме некоторых договоренностей (небольшого api) им ничего не
надо знать о коде друг друга.

Более того, можно сделать т.к сказать полностью графический движок игры, в виде "простого" демо, например warcraft2 (или warcraft3), здания горят, мечники махают мечами,
колдуны стоят в сторонке колдуют, вы можете поменять в вашем демо день, на ночь, активировать дождь, можно прокрутить "карту местности", создать/изменить/удалить графический обьекты на карте
при этом механики игры у вас вообще нет, от слова совсем.
А если вы добавите минимальную механику (код которой мал по сравнению с кодом который надо будет написать для полноценного кода игры),
то вы получите "полноценное" демо:
юниты куда то ходят, что то делают, что то типа мультфильма.

В качестве демонстрацией этой идеи предлагаю вашему вниманию реализованный мной
такой "графический движок" написаный на Delphi 7 для известной игры "Gauntlet".

В письме два вложения:
1.Gauntlet.jpg - фото "демо".
2.GauntletForum.rar
в нем
В GauntletForum\Gauntlet\Bin\ - exe файл демо

В GauntletForum\Gauntlet\Gauntlet\Drw State_Game\ - код проекта,
который можно запустить, посмотреть.

Keyboard - вспомогательный модуль для работы с клавиатурой.

drwstate_Game - тот самый view - графический движок игры,
который я вам хотел показать.

app_DrwState_Game_Main - модуль тестовой формы, в котором
пример как пользоваться, возможностями модуля drwstate_Game.

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

Кстати если у вас и у меня хватит сил и желания, то тут нам есть
над чем порезвиться.
Сразу видно 2 направления,
1. Разработка механики.
Можно сравнить разные реализации разработка механики:
Функциональное, ООП, ECS.

2. Усовершенствование графического движка.
Превратить движок в библиотеку на интерфейсах, которую
можно было бы подключить не только в Delphi но и к С++.
Заменить битмапы на DirectX на плоскости,
эта игра подходит так же для того что бы плоскость заменить
на 3d (меняется только графика, механику нам менять не нужно),
OpenGl.

Более того было бы интересно переписать этот код (графику и будущую механику) на другие языки,
C++, C#, Java, javascript + nodejs.

Я сам чуть попозже хочу написать механику на Delphi, на ECS.
Но сперва бы хотелось бы с вашей помощью, переписать
графический движок на lib c интерфейсами но с передачей дельфийского canvas (видимо это можно будет подсоединить только к Delphi),
после этого с на lib c интерфейсами но уже c автономной формой (видимо
это можно будет подсоединить к Delphi и С++).

Что думает по всему этому безобразию?
rhiroceros вне форума Ответить с цитированием
Старый 04.08.2019, 20:26   #2
rhiroceros
Пользователь
 
Регистрация: 07.05.2016
Сообщений: 23
По умолчанию Вот вложения о которых я говорил

Вот вложения о которых я говорил
Изображения
Тип файла: jpg Gauntlet.jpg (105.2 Кб, 121 просмотров)
Вложения
Тип файла: rar GauntletForum.rar (397.0 Кб, 16 просмотров)
rhiroceros вне форума Ответить с цитированием
Старый 05.08.2019, 06:36   #3
rhiroceros
Пользователь
 
Регистрация: 07.05.2016
Сообщений: 23
По умолчанию

Вот так лучше будет.
Изображения
Тип файла: jpg Gauntlet.jpg (106.2 Кб, 106 просмотров)
rhiroceros вне форума Ответить с цитированием
Старый 05.08.2019, 06:56   #4
rhiroceros
Пользователь
 
Регистрация: 07.05.2016
Сообщений: 23
По умолчанию

При этом для вызова отрисовки движка,
вам необходимо вызвать только методы Draw и Tact
обьекта Tdrwstate_Game (если до этого вы уже установили ячейки пола,
установили предметы на ячейстую карту, добавили пули и врагов с героями в графический движок,
количество жизней и другие параметры героев).

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

Кстати еще один бонус такого разделения при сетевой игре,
механика находится на сервере, а графический движок на каждом клиенте,
а по сети идет синхронизация данных между механикой и графикой.
Многие обьекты устанавливаются один раз в этой игре (тип пола, стены)
поэтому они синхронизируются в начале игры и больше их синхронизация не требуется.
Можно обнаружить обьекты которые могут находится только в графическом
движке и синхронизация от механики вообще не нужна,
например в игре про космос, движения звезд могло быть полностью
вынесено в графический движок и по сети не передаваться.
rhiroceros вне форума Ответить с цитированием
Старый 05.08.2019, 07:06   #5
rhiroceros
Пользователь
 
Регистрация: 07.05.2016
Сообщений: 23
По умолчанию

И еще момент.
Карты можно создавать достаточно большие,
отображается только часть мира,
изменять то какая часть мира будет просматриваться
можно с помощью свойств обьекта Tdrwstate_Game_Map
WorldX и WorldY.
rhiroceros вне форума Ответить с цитированием
Старый 05.08.2019, 07:23   #6
rhiroceros
Пользователь
 
Регистрация: 07.05.2016
Сообщений: 23
По умолчанию

Еще раз заострю ваше внимание:

Есть стандартный Mvc там View для отображения получает данные из Model.

В предложенном мною методе View имеет свои данные, Model (механика) будет иметь свои.
Поэтому они полностью разделены друг от друга.
И кто то 3ий синхронизирует данные Model и View, заставляя их работать вместе.
rhiroceros вне форума Ответить с цитированием
Старый 05.08.2019, 13:26   #7
coremission
Форумчанин
 
Аватар для coremission
 
Регистрация: 09.11.2017
Сообщений: 121
По умолчанию

из форматирования стартпоста я ожидал стихи,
а вы какие-то пространные рассуждения...

У меня сложилось ощущение, что у вас какая-то "паника" после прочтения умной книжки или фразы какого-нибудь наблатыканного коллеги. Надо разделять/обращать зависимости, поэтому надо все разделять! Всё, мы все умрем если не будем разделять. Если вы новичок - не надо стремиться все это за неделю всосать и усвоить - все придет с практическим опытом.
Профессионально программирую видео-игры. Пишу бекстейдж-блог о разработке игр CoreMission.net.
Разрабатываю календарь выхода игр.
coremission вне форума Ответить с цитированием
Старый 06.08.2019, 07:10   #8
rhiroceros
Пользователь
 
Регистрация: 07.05.2016
Сообщений: 23
По умолчанию

Добрый день, Coremission.

На этом сайте есть ранее соданная мной тема:
"Ремейк боевика Ikari" там во вложениях есть три 3 игры - Ikari, LodeRunner, Arkanoid.
Не бог весть что, но они имеют законченый вид и программный код написан лично мной от начала до конца. Были и другие поделки разной степени законченности, но я стер все, потому что меня не удовлетворяло какчество кода.

Идею разделения графики от "механики игры" таким образом что у графики свое собственное состояние, которое 3ей стороной синхронизируется от состояния "механики игры" считаю лучшей идеей родившейся у меня на сегодняшний день,
пришел я к такой простой мысли далеко не сразу, поэтапно, сначало графика и механика вообще никак не были разделены все было в одной куче, потом графика была отделена но в первоначальных вариантах у графики не не было своего состояния ей нужна была или в том или ином виде модель от "механики игры",
потом состояние было не явное (можно было вызвать графические методы, состояние как бы не явно оказывалось в нарисованном изображении), потом у части графики было состояние у части было не явное. И послденее озарение было как раз это, сделать у графики свое собственное состояние отделив
таким образом ее полностью от других частей игры (теперь все графику я могу и тестировать и разрабатывать отдельно, причем с разработки графики и начинать игру потому что то уже только разработка графической части, настолько внешне придает видимость вашему труду "закончености" и осязаемости,
что это стимулирет и вдохновляет доделать ее до конца.).
Я абсолютно уверен что вопрос каким образом отделять графику в игре, для меня закрыт,я нашел что хотел и мне в этом направлении абсолютно больше не о чем думать.
Не знаю как в больших (огромных) проектах (почему бы то же ни так? но тут все таки практика нужна для окончательного суждения) но маленькие игры я теперь буду делать только так.

Coremission зашел на ваш сайт, много итересной информации об играх, но правда о разработаных другими людьми.
Наверняка ведь у вас есть разработаные лично вами от начала до конца иеющие законченый вид игры, как их можно посмотреть,
полюбоваться результатами вашего труда?
rhiroceros вне форума Ответить с цитированием
Старый 06.08.2019, 14:30   #9
coremission
Форумчанин
 
Аватар для coremission
 
Регистрация: 09.11.2017
Сообщений: 121
По умолчанию

я не инди, я промышленный разработчик. участвовал в разных проектах. R6, Assassin's creed: Odyssey в качестве геймплей-программиста, сейчас программирую графику
Профессионально программирую видео-игры. Пишу бекстейдж-блог о разработке игр CoreMission.net.
Разрабатываю календарь выхода игр.
coremission вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Создание игры. SerEngine Gamedev - cоздание игр: Unity, OpenGL, DirectX 14 05.04.2018 10:37
Создание игры Юрий04 Помощь студентам 40 28.03.2015 23:01
Создание 3D игры zik1 Свободное общение 13 29.04.2012 18:45
Создание игры Ушастик Фриланс 1 17.11.2010 18:09
Создание игры РПГ (RPG) vzov Qt и кроссплатформенное программирование С/С++ 18 13.05.2009 03:12