Механика игры и логика игры :: Создание игр :: Форум

ObelardO, спасибо. Но я бы хотел услышать описание с точки зрения программиста. Сейчас пытаюсь реализовать игровой цикл, где происходит взаимодействие игрок-ИИ, игрок-игрок(на одном ПК или через сеть). Опыта в gamedev нет, поэтому сложно представить игровую архитектуру.

Опубликовано 09.05.2013 15:58 (11 лет назад) #

clazz написал:
ObelardO, спасибо. Но я бы хотел услышать описание с точки зрения программиста. Сейчас пытаюсь реализовать игровой цикл, где происходит взаимодействие игрок-ИИ, игрок-игрок(на одном ПК или через сеть). Опыта в gamedev нет, поэтому сложно представить игровую архитектуру.

Я бы организовал примерно так... Представим каждый юнит в виде конечного автомата, опишем все его состояния, реализуем все его действия, далее пропишем несколько уровней интеллекта, которые будут управлять изменением состояний юнитов. На примере стратегий, базовый - инстинкт самосохранения допустим, если подвергся атаке, то отбежать, если воевать не умеешь, если умеешь то атаковать в ответ, если жизней мало, то убежать. Если рядом союзники есть, то позвать на помощь либо предупредить об опасности. Далее идет другой уровень, на котором более конкретизируются условия для разных типов юнитов. Если работнику нечего делать, то он идет добывает ближайшие ресурсы, охранник соответственно патрулирует, разведчик - разведывает. Дальше более глобальный уровень, который определяет общую стратегию развития: если не хватает таких то ресурсов, то добыть их, если их нет, то найти новые, наклепать небольшую армию - послать в такую то точку на карте(к врагу), воевать будут сами. Ну а игрок по сути это просто устройство ввода, когда некоторые базовые уровни интеллекта реализованы, юниты становятся более самостоятельны, и игрок выполняет роль остальных уровней интеллекта. Т.е. у юнитов подконтрольных игроку включены только базовые, такие как самосохранение. Вообще на эту тему давненько читал статью где всё хорошо расписывалось, точно не помню, но вроде на примере отечественной стратежки тень ворона или ворон. Ну как то так... Может я совсем не про то говорю, но и вопрос достаточно размытый)

Опубликовано 09.05.2013 16:48 (11 лет назад) #

clazz написал:
Как бы Вы описали своими словами эти два термина?

Логика игры, это система логических связей, ответственная за поведение игры (взаимосвязи событий в игре). Это очень высокий, абстрактный уровень.
Игромех - имплементация предыдущего определения в виде свода правил . (высокий уровень)
Есть еще низкий уровень - это реализация игромеха непосредственно "в корпусе". В зависимости от "платформы" может быть как програмным кодом, так и сводом действий по бросанию кубика или еще чего.

Опубликовано 09.05.2013 19:37 (11 лет назад) #

CoderInTank написал:
... вопрос достаточно размытый)

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

Shirson, т.е. если у меня есть юнит и у него метод "перемещаться в точку" - низкий уровень? А уровень выше определяет правила: куда переместить, можно ли переместить, где обойти, что стало с юнитом в точке?

Опубликовано 09.05.2013 21:07 (11 лет назад) #

clazz написал:
Shirson, т.е. если у меня есть юнит и у него метод "перемещаться в точку" - низкий уровень?

*Бьёт тапком в глаз за смешивание мух и котлет*
Раз взялся приводить мысли в порядок, делать это надо вдумчиво :)

Абисьняю:
Юнит это высокий уровень. У него не может быть никаких методов. Методы есть у объекта (низкий уровень), который реализует поведение юнита.

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

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

Опубликовано 13.05.2013 17:24 (11 лет назад) #

Shirson написал:
*Бьёт тапком в глаз за смешивание мух и котлет*

Не помогло( Придется снова засесть за чтение ООП.

Опубликовано 13.05.2013 18:13 (11 лет назад) #

clazz написал:Не помогло( Придется снова засесть за чтение ООП.

ООП-то тут причём? Логика, механика и их реализация никак не связаны, ни с ООП, ни с программированием вообще (настолки, карточные, воргеймы и пр)

Опубликовано 14.05.2013 09:44 (11 лет назад) #

Shirson написал:

clazz написал:Не помогло( Придется снова засесть за чтение ООП.

Я позволю себе вмешаться, потому что, с одной стороны, сталкиваюсь с теми же проблемами, что и clazz, а с другой, имею довольно большой опыт игры в различные настолки, карточные и варгеймы))

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

Опубликовано 14.05.2013 15:21 (11 лет назад) #

ООП это одна из многих возможных технологий реализации игромеха. Сам ООП тут никак не роляет, потому, что игромех может быть реализован и без объёктной модели.
И если проблема в том, что ты упомянул, про сложность понимания того, что нужно отдельные сущности для визуализации, тут надо не ООП перечитывать, а постигать дао MVC :) И делать это вдумчиво и усердно, ибо MVC, особенно для игростроя, это одна из самых важных и самых малопонимаемых девелоперами вещей.

редакция от Shirson, 14.05.2013 15:27

Опубликовано 14.05.2013 16:43 (11 лет назад) #

clazz написал:
Сейчас пытаюсь реализовать игровой цикл, где происходит взаимодействие игрок-ИИ, игрок-игрок(на одном ПК или через сеть). Опыта в gamedev нет, поэтому сложно представить игровую архитектуру.

Не важно ООП или не ООП, но хорошим стартом будет написание некой структуры Actor, которая может принимать параметры действия и совершать его. И которой будет все равно откуда пришли эти параметры - от игрока за монитором, ии, или игрока из сети.

Перед этим, конечно, необходимо написать на бумажку список игровых объектов и для каждого построить дерево действий.

Опубликовано 14.05.2013 20:11 (11 лет назад) #

2Shirson
Согласен) Дао MVC постигать нужно. Просто во многом ООП стал неким стандартом разработки, который сильно облегчает жизнь.
Просто я хотел акцентировать внимание на то, что вещи, которые с точки зрения некой "механики" игры достаточно простые (к примеру, как в шашках, нельзя выходить за доску или вставать одной шашкой на другую) в компьютерной реализации уже не так очевидны.

Опубликовано 14.05.2013 20:21 (11 лет назад) #

Xneg написал:
2Shirson
Согласен) Дао MVC постигать нужно. Просто во многом ООП стал неким стандартом разработки, который сильно облегчает жизнь.

ООП это одно из средств реализации низкого уровня. У топикстартера серьёзные проблемы с пониманием архитекрутры в целом. Перечитыванием ООП его проблема не решится никак.

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

Это понятно по дефолту. Поэтому низкоуровневая имплеменация занимает в сто раз больше места, чем её хидеры :)
Но к сути темы отношения это особого не имеет ;)

Опубликовано 14.05.2013 20:40 (11 лет назад) #

Shirson написал:
ООП это одно из средств реализации низкого уровня. У топикстартера серьёзные проблемы с пониманием архитекрутры в целом. Перечитыванием ООП его проблема не решится никак.

Ну так может и расписать тогда чуть подробнее эту архитектуру, не вдаваясь пока в конечные автоматы? Мне тоже было бы очень интересно)