Разработка игр

10. Игра с полной или не полной информацией

2011-10-05T17:00:00.000+04:00

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

Примеры: С полной информацией: шахматы, шашки, футбол, тетрис, PacMan, Kingdom Rush, Plants vs Zombies.

С не полной информацией: Любые FPS, покер, дурак, Warcraft III, DotA, Plants vs Zombies.

Основной жанр: покрывает все жанры на 2 доли.

Использование: Не полная информация (или "туман войны") предлагает игроку дополнительную интригу и доп. разминку для памяти и аналитических способностей. "Туман войны" добавляет несколько ошибок и действий к игроку чего не было бы при открытой карте. В начале игры, обычно есть несколько путей развития. Какой именно выбрать зависит от такого какой вариант выбрал противник. В случае с "туманом войны" игроки могут рискнуть и выбрать случайно, могут развивать чуть медленне и в универсальном ключе и т.д. Т.е. уже нет заранее готового решения, есть только несколько вариантов из которых нужно выбрать. В любую игру можно добавить "туман войны". Возьмём за пример тетрис. Изначально мы видим весь стакан. Но что если попробовать уменьшать видимость стакана сверху на одну линию вместо того чтобы ускорять игру? Это пища для ума и для экспериментов с разработками игры. Или другие варианты: возьмём аркаду Alien Shooter или Ancient Ants Adventure, изначально там видно всё поле вокруг игрока. Но что если попробовать сделать что-то вроде фонарика и оставить видной только ту часть что входит в луч этого фонарика? Игра станет более динамичной и резвой, т.к. игроку придётся чаще вертется чтобы посмотреть что творится по бокам и за спиной. Игра Plants vs Zombies демонстрируется в обоих частях. Почему? А вы посмотрите как там это выполнено, причём в разных вариантах. Изначально игрок видит всю карту. Потом добавляется туман, который загораживает зомби. С этим туманом можно работать различными инструментами (поставить лампочку и будет видно вокруг или сдуть его вентилятором). Также там есть невидимые зомби, где приходится гадать где они находятся по дополнительным признакам. Есть ещё миссия, где не видно вообще ничего и только когда молния сверкнет видно территорию на небольшой промежуток времени. Видите? Одна и та же игра, но со многими подходами к одной и той же проблеме. Естественно, игроку интересно поучаствовать в разных ситуациях, по разному себя почувствовать да и геймплей разный.

9. Игра с нулевой суммой и наоборот

2011-10-04T15:00:00.000+04:00

Описание: Игры с нулевой суммой — особая разновидность игр с постоянной суммой, то есть таких, где игроки не могут увеличить или уменьшить имеющиеся ресурсы, или фонд игры. В этом случае сумма всех выигрышей равна сумме всех проигрышей при любом ходе. Естественно, речь идёт о многопользовательских играх (игроках с равными правами, хотя они могут и управлятся компьютером. Хороший пример здесь - Counter-Strike. Это многопользовательская игра, но есть возможность добавить ботов. И хотя они не являются живыми игроками, они обладают всеми теми же правами, что и человек), а не о сингле. Примерами таких игр может служить покер, где один выигрывает все ставки других; реверси, где захватываются фишки противника; либо банальное воровство - один выгрывает, другой обязательно проигрывает; большинство стратегий (Starcraft, C&C, Warcraft), где сколько юнитов уничтожает один, столько теряет второй, сколько зон захвачено одним, столько потеряно другим и т.д. Почему с нулевой суммой?

	Стратегия 1	Стратегия 2
Стратегия 1	(-2; 2)	(3;-3)
Стратегия 2	(0; 0)	(-1; 1)

Как видите из таблицы, сложив результаты игроков мы получим ноль, поэтому и называется, игра с нулевой суммой. Хочу сразу заметить, слово "стратегия" обозначает набор действий, а не жанр игры, а в скобках очки двух игроков. В Starcraft может кто-то не проиграть в игре? Нет. Сколько выйгрывает один игрок, столько проигрывает другой.

	Стратегия 1	Стратегия 2
Стратегия 1	(4; 2)	(0;-3)
Стратегия 2	(1; 0)	(-1; 5)

Игрой с отличной от нуля суммой является игра где сумма всех игроков не будет равна нулю (из таблицы, первая клетка - оба игрока могут выйграть; потом один проиграть, а другой остаться при своём; один выйграть, а другой остатся при своём. Оставшиеся варианты: оба остаются при своём и оба проигрывают). Пример, торговля, где каждый участник извлекает выгоду (один получает деньги, другой товар). Здесь оба выйгрывают, т.е. положительный для обоих результат. Война - это действо где оба проигрывают. Возьмём Civilization, когда 2 стороны воюют между собой, они уменьшают "стоимость" друг друга, но тем самым будут являтся лакомым кусочком для третей стороны.
Сюда также относятся го, шашки и шахматы; в двух последних игрок может превратить свою рядовую фигуру в более сильную, получив преимущество. В шахматах есть такой вариант, когда оба не проигрывают? Есть, ничья - пат. Во всех этих случаях сумма игры увеличивается. В игре Civilization это хороший пример игры с ненулевой суммой. В конце игры вы видите счёт, да - кто-то лучше, кто-то хуже, но явно проигравших может и не быть. Есть лидер, получивший больше всех очков, его можно считать выйгравшим, а всех остальных проигравшими, но явного выйгрыша нет (если он не победил всех игроков войной). В Warcraft III такого быть не может, в конце игры один из игроков (если 1:1), одна из команд (если команда на команду) или все кроме одного (в игре против всех) проигрывают до подсчёта очков.
Примеры: С нулевой суммой - Starcraft, Warcraft, C&C, Sins of a Solar Empire, Quake III, Counter-Strike и все игры где целью является уничтожить противника.
С не нулевой - серия Civilization, Galactic Civilization 2, серия Master of Orion и все где целью не является уничтожить противников, а вырасти до определённого уровня.
Основной жанр: С нулевой суммой - FPS, RTS.
С не нулевой - 4X Стратегий, различные MMO.
Использование: Выбор за вами, что именно вы хотите выбрать. Это может быть игра, где действия одного всегда отрицательно сказываются на результатах другого или наоборот с возможностью действовать вместе, сообща ради одной цели (при этом не являться кооперативной игрой). Именно поэтому Sins of a Solar Empire не является 4Х стратегией, т.к. действия одного всегда оканчивается плачевно для другого (противника). Игры с нулевой суммой подходят больше для соревновательных действий, тогда как с не нулевой - для развивающих и расслабляющих игр.

8. Дипломатия

2011-10-03T12:00:00.000+04:00

Описание: Если игра подразумевает несколько игроков, «дипломатия» одна из тех технологий, которая очень сильно расширяет возможности геймплея. Естественно, она сильнее работает между игроками, нежели между игроком и компьютером. Но это, скорее всего, недостаток технологий программирования ИИ. Дипломатия помогает распределять между игроками их отношения, а также их менять. При разных значений дипломатий появляются разнообразные действия. При положительных отношениях, положительные действия (Альянс, помочь, подарить и т.д.); при отрицательных отношениях, отрицательные действия (Объявить войну, навредить, подраться и др.).

Примеры: серия Civilization, The Sims, Аллоды, Gothic, The Elder Scrolls, Master of Orion, GTA II, Hitman.

Основной жанр: Стратегий, РПГ.

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

В каждой игре дипломатия реализована по разному, но чаще всего под "дипломатией" подразумевают действа как в играх Civilization, Master of Orion. Это не то чтобы не правильно, но ограничивает ваше виденье. Например, Hitman: изначально все люди на карте относятся к вам нейтрально, т.к. не знают что вы из себя представляете, но меняют отношение к вам если вы делаете те или иные действия. Если вы достаете пистолет, то к вас боятся, если стреляете, то все начинают к вам относится враждебно (но делают это по разному, гражданские - бегают, орут, а военные - стреляют по вам), если вы зашли не в положенную зону, то вас просят её покинуть и т.д. Фракций в GTA II, вы можете с ними дружить убивая членов враждебных фракций и получать за это бонусы и доп. мисиий. Примерно та же ситуация в РПГшках - Gothic и Elder Scrolls, налаживая отношения (выполняя миссия, воюя с врагами фракций и т.д.) вы получаете различные бонусы (доп. миссий, доступ к более сильным вещам, к новым возможностям).

Этот приём может сделать вашу игру более гибкой, а главное, более адекватной к действиям игрока. Он позволит дать обратную связь игроку.

7. Прятанье в тени

2011-10-02T01:00:00.000+04:00

Описание: Одна из способностей персонажа. Есть специальные места в которых этого персонажа не видно, в специальном месте (за спиной противника; в тени; в паутине, если это паук;), со специальной способностью, специальным объектом или другим способом (типа магий и др.). Иногда расширяет геймплей (как в стратегиях, Warcraft III, C&C), а иногда и держит его полностью (Thief, Hitman, NOLF).

Примеры: Trilby, Thief, Hitman, No one lives forever, Warcraft III: DotA, Bioshock.

Основной жанр: FPS, Аркады.

Использование: Для этого делаются некие области видимости нахождение в которых делает невидимым для остальных (пассивное) или под использованием заклинания/технического приспособления (активное). Вы можете сделать этот приём как для игрока (Trilby, Thief), помогая ему избежать конфликтов из которых он может не выбраться. Также вы можете применить этот приём для монстра, который будет уходить в невидимость и неожиданно нападать на игрока (как это сделано в F.E.A.R.).

6. Игра с целью или без неё

2011-10-01T14:57:00.001+04:00

Описание: В большинстве своём, игры все заканчиваются логическим концом – заключительным роликом, счётом, титрами - при выполнений особых условий, прохождений всех имеющихся уровней (Kyrandia, Half-Life, Warcraft). А есть игры бесконечные, которые не имеют конца ни при каких обстоятельствах, кроме выхода из игры (The Sims, Sim City, Tetris), таких существенно меньше, но они есть. Честно говоря, я бы отказался от последних, потому что человек всегда делает всё для чего-то, он всегда стремится к чему-то или от чего-то. Пока в Sims и Sim City есть мелкие, локальные задания, поставленные самим игроком, играть в них интересно, как таких заданий не остаётся – всё, капут. Лично я, не играю для того чтобы поиграть, а играю для того чтобы достигнуть цели. Эта цель может быть создана искуствнно мною, а может быть уже встроенна в игру.

Примеры: относится ко всем играм без исключения.

Основной жанр: в различных аркадах как правило цель отсутствует, в остальных обычно цель присутствует.

Использование: Если вы хотите сделать игру бесконечной придумайте т.н. локальные цели. Чтобы нашёл ради чего играть, например, ради высокого счёта, любопытных бонусов, новой концовки и т.д. Обычно при этом каждый этап происходит усложнение, чтобы игра не была в прямом смысле бесконечной. В играх с огромным геймплейным запасом (таких как, The Sims) игру можно делать бесконечной, игрок всегда найдёт чем заняться, а вот в играх с более простым геймплеем это делать неразумно.

Если вы чувствуете что геймплей ограничен, то имеет смысл сделать цели, чтобы игрок, используя локальные возможности, добивался её. Или, например, если глобальная цель (выйти с уровня) известна и она одна, то можно разбавить несколькими дополнительными целями (уничтожить некое количество монстров, собрать все бонусы, пройти уровень менее чем за N минут, чтобы ни один монстр не заметил вас и др.).

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

5. Самостроящаяся игра

2011-09-30T13:00:00.000+04:00

Описание: Одни из хороших примеров, игры от Сида Мейра. Свободные, бесконечные, самостроящиеся. Pirates, Civilization. Игра Pirates очень гибкая и подстраивается под игрока, хотите идите туда, а хотите туда, хотите быстрее и сложнее, пожалуйста, хотите медленнее и проще, не вопрос. Вы сами влияете на весь процесс от начала и до конца.

Примеры: Pirates!, серия Civilization, серия The Sims (кроме квестовых), Imperium Galactica II, Master of Orion, серия Fallout, Космические рейнджеры II, Elite, серия Gothic, серия The Elder Scrolls, серия Europa Universalis, серия Hitman, Spore.

Основной жанр: Как вы видит из примеров, приём достаточно общий и применим к игре любого жанра, но чаще бывает в стратегиях (4X в частности), квестах, аркадах.

Использование: Этот приём очень мощный и может подойти к игре любого жанра и направления. Суть приёма заключается в том чтобы игроку самостоятельно строить всю цепочку геймплея. Это не аналог "нелинейности" с альтернативными концовками, это нечто боле качественно. Ближе всего, конечно, игра Pirates!, которая не имеет предсозданной структуры вообще! Т.е. изначально только сам игрок и цель - стать самым самым. Всё. Остальное строится на ходу, на лету, как вам удобнее. Справляетесь с заданием хорошо, чувствуете что слишком просто? В конце "отчётного" периода, выбираете ответ, что слишко легко и вот игра уже строится на несколько других правилах. Задание более сложные, разнообразные, другие условия игры и т.д. В стратегиях вы определяете ход развития своей империй, как и куда она будет расти и как вы будете влиять на окружающий мир. В РПГшках вы тоже уже более простая схема, просто выбирается их нескольких возможных вариантов и на основе этого строится последующий геймплей. Ограбили магазин? Вас будут меньше любить в этом месте, меньше квестов (или альтернативные), выше цены в магазинах (или вообще закроются), обьявят вас вне закона и будут охотиться и т.д.

Но в конечном счёте, вы должны не только строить геймплей (не на стадий проетирования игры, а в ходе самой игры) исходя из выбора игрока, но так чтобы ему было комфортно, удобно, интересно играть. Например, в миссий N врагов. Обычно их количество фиксировано и оно не меняется. Число N расчитано на определенный тип игроков, но игроки бывают разными. Кто-то лучше играет, кто-то хуже, а кому-то нужен этот жанр, но немного другая комбинация врагов (такое тоже бывает). И если мы последуем нашему правилу, то теперь N будет "плавать" (строится) исходя из предпочтений, предыдущих показаний игрока и т.д. Сыграл хуже или лучше? (N * насколько_по_норме) Коэффициент насколько_по_норме - строго положительный. Конечно, это в данном контексте, допустим, не будь это количество юнитов, а например ещё что-то, то коэффициент (и даже формула) может быть другой. Теперь игрок, сыграв хуже или лучше по норме, получить нужную порцию врагов соответственно своей потребности. Хотя именно этот пример касается непосредственно сложности (эта правило будет в будущем), но данное правило можно применять (к чему я вас и склоняю) к любому параметру. Хочет взять напарника? Пускай. Хочет воевать? На боевую ситуацию. Не хочет? Ну на мирную. За примером далеко ходить не надо: Hitman. Там можно пройти "тихо" и "громко", можно выбирать любой тип исходя из предпочтений игрока. И игра, и геймплей выстроятся так как этого хотел игрок. В какой мере это будет уже зависит от разработчика. Я настоятельно рекомендую этот приём, т.к. это серьёзно разнообразить геймплей, а также подстроит его под игрока (что в большинстве случаев и требуется).

4. Выделение рамкой

2011-09-29T13:00:00.000+04:00

Описание: Одним из самых выдающихся достижений в области интерфейса было управление несколькими юнитами. А как выделить нескольких? Можно щёлкать по ним и добавлять в кучу, но инженеры из Westwood сделали более изящно: в C&C появилось выделение рамочкой, те что были в рамке становились активны и приказы можно было отдавать выделенной группе. Это быстро, это удобно, но чем больше видов юнитов, чем их больше по количеству и если они все расформированы, выделить таким способом очень трудно.

Примеры: Подавляющее большинство стратегий.

Основной жанр: Стратегий. Может есть ещё какие-то жанры, но так ничего не приходит на память.

Использование: Можете использовать в своей игре, где вам необходимо выбрать некое количество юнитов. Хотя я рекомендую переходить на более новые виды интерфейса, например, объединять юниты в группы и управлять группой как единым юнитом. Это проще и интереснее для игрока. Как альтернативу, можно рассмотреть иные виды выделения. Не прямоугольником, как это обычно бывает, а, например, кругом, эллипсом или вообще произвольный выбор (нарисовали область и в ней выделились юниты, как при "Лассо" в фотошопе или более новый и передовой вариант "Быстрое выделение" кисточкой. Эти типы выделения помогут выбрать похожие юниты быстро и просто, когда прямоугольная рамка не сможет справится с этим).

3. Управление группой как единым юнитом

2011-09-28T13:00:00.000+04:00

Описание: Часть интерфейса, позволяет более удобно управлять большим количеством юнитов. Хороший примеры, Ground Control, Company of Heroes. Пехота (а для Ground Control, все юниты) объединена в группу и управляется как один юнит, но действует как группа. Это полезное свойство интерфейса, когда юнитов слишком много, а управлять ими приходиться быстро. Ещё пример, Казаки 2, где юниты были объединены в отряды и ими было легко управлять или серия Total War, где просто огромное количество войнов в отрядах.

Примеры: серия Total War, серия Казаки, Ground Control, тёзка World in Conflict, Company oh Heroes, Ancient Ants, стратегические серий Warhammer.

Основной жанр: Стратегий. Но также появляется в других жанрах, Ancient Ant относится к аркадам или серия Cannon Fodder. Там есть возможность управлять своим отрядом как одни юнитом.

Исключения: Последние версий Civilization. Несмотря на то что там юнит отображается как несколько юнитов в отряде, это только отображение. Сам юнит всё равно в единственном числе и нет индивидуального разделения урона между юнитами, т.е. это не группа, а просто отображение.

Использование: Вы можете использовать там где у вас куча юнитов и вам нужно чтобы они действовали как единый организм. Допустим, аркада где кучка юнитов, вместо того чтобы оставить так как есть, лучше объединить в одну группу. Чтобы была возможность построить в строй, раздать бонусы в группе, распределить урон, удобно и быстро выделить эту группу и т.д. Проще нажать одной кнопкой на группе, чем выделять её мышкой - это факт. Реализация может быть также разной. Вы можете сделать группу только выделяемой как один юнит, но при этом бонусы не вносить в реализацию. Или наоборот добавить бонусы, например, по отношению к разным группам. Допустим, выделили "Усилить" и выбрали эту группу. Также можно ввести внутриигровые отношения групп. Допустим, если одна группа нападает на другую с боку, то все юниты в этой группе получают дополнительный урон. Особняком хочу пройтись по фентези серий Warhammer (в частности, Mark of Chaos). Это хороший пример того как может использоваться этот приём. Юниты там не просто наносят и получают урон как это обычно бывает: юнит нанес N урона, у врага снялось (N - Броня) жизней, а в том порядке в котором это бывает обычно в аркадах (ведь там у начальных юнитов урон 1-3, а жизней по 1). А примерно по такой системе: юнит атакует другой, если шанс попасть успешен, то тогда снимаем урон, иначе противник успешно отразил удар (проигрывая при этом анимацию отражения удара). При этом часто бывает так что как будто отряд действительно борется и защищается, а не просто отнимает часть жизней у противника.

2. Разделение игрового поля на зоны

2011-09-27T23:00:00.000+04:00

Описание: Есть возможность разделить поле на куски, как физически, так и виртуально. Физически: как в Europe Universalis, т.е. каждый кусок отражает как физическое расположение юнитов, так и их характеристики – добывание ресурсов, базы и т.д. Виртуально: В Company Of Heroes поле разделено на виртуальные куски, которые вы можете захватить с помощью флагов и получать ресурсы с захваченных территорий и получать на них подкрепления, на перемещение юнитов они никак не влияют.

Примеры: Космические Рейнджеры II (карта звёзд), Ascendancy, серия Master of Orion, GTA 3: San Andreas (захват территорий), серия Europe Universalis, Company of Heroes, Command&Conquer (карта выбора миссий), Dune (карта планеты), Kingdom Rush (карта)

Основной жанр: также в основном стратегий, хотя те же Космические Рейнджеры не относятся к "чистым" стратегиям. Также и GTA3 не относится к стратегиям, но придает некую вовлечённость в борьбу за свою территорию.

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

События (Events)

2011-09-26T00:00:00.002+04:00

Сегодня я хочу поговорить о событиях (Events). Но не о событиях встроенных в ГМ, а в более общем контексте, позволяющим увидеть всю структуру этого интересного приёма программирования.

Но сначала, конечно же, поговорим о событиях в ГМ. Все они происходят в определённый момент - по достижению неких условий, событий. Создаем объект - выполняется событие Create и вместе с ним весь код определённый в этом событий, наступил момент обновления вызываем событие Step, наступил момент рисования - Draw, нажали кнопку Keyboard_press и т.д. Т.е. мы не постоянно выполняем код и не постоянно опрашиваем объект:

Игра: Ты обновился?
Интерфейс: Нет.
Игра: Ты обновился?
Интерфейс: Нет!
Игра: Ты обновился?
Интерфейс: Да нет ещё! Я скажу когда я обновлюсь.

С этого момента, программистам пришла идея ввести так называемые Callback-функций. Мы не будем смотреть как они конкретно работают, т.к. нам потребуются знания не входящие в ГМ, но рассмотрим просто схему работы.

Когда наступают некие условия или необходимость, то вызывается функция по указателю. Происходит callback вызов: мы говорим что нам нужно это, т.с. заказываем и нам это присылают. Заказываем на то что указал наш палец в меню. Где палец - указатель, а выбор в меню это функций. Теперь переговоры выглядят так:

Игра: Интерфейсу необходимо обновление.
Интерфейс: Есть обновление!

Выявляются 2 действующих лица. Первый (в списке, верхний) - раздающий событие, второй (нижний) - слушающий. Раздающий всегда один, точнее одно событие раздает один слушающий. В то время как слушающих может быть сколько угодно. Это как вечеринка в клубе: DJ - один, слушающих много. Т.е. теперь список может выглядеть так:

Событие Draw: Необходимо обновление.
Карта: Есть обновление!
Инвентарь: Есть обновление!
Персонаж: Есть обновление!
...
Враг №N: Есть обновление!

В ГМ уже есть много событий, но некоторые не подходят и нам необходимо определить свои и тут-то приятно осознавать что мы умеем это делать. Как именно, рассмотрим далее. А пока затронем тему, когда это нужно? Это нужно тогда, когда вы хотите уменьшить кол-во вызовов. Некоторые из вас уже наверняка пробовали имитировать создание событий. Например, обновление пути для персонажа. Если использовать этот код в событий Step, то код может выполняться чаще чем нужно. Вы подумали, а что если код выполнять не так часто? И вы старательно запихивали этот код в событие alarm и выполняли код каждые N step'ов. Этот приём и есть эмулирование работы событий. Но по сути, в чем минус этого события? В том что обновление пути может быть чаще, а может быть реже чем нужно. Т.е. вы выполняете код тогда когда прошли N игровых циклов, а не тогда когда путь нуждается в обновлений.

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

Чтобы вызвать код обновления пути необходимо написать след. конструкцию (в Create кубика):

with(object)
onChangePath();

Где object - объекты в которых нужно обновить пути. Помнить нужно одно, что событие onChangePath принадлежит только одному объекту - object, выполнив этот код в object2, все может закончится плачевно. Т.к. в ГМ такие конструкций не безопасны, безопасность ложится на ваши плечи.

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

Перейдем к примером, где этот прием может понадобится:

UI (User Interface, пользовательский интерфейс) - здесь эта техника используется очень часто. Т.е. интерфейс "работает" только тогда когда пользователь с ним взаимодействует, иначе трата сил впустую. Пользователь нажал кнопку мышки, вызываем событие нажатие мышки и обработку. Если курсор находился над кнопкой открытия инвентаря - выполняем onInventoryOn, в нем рисуем инвентарь. Нажали кнопку в инвентаре, то выполняем событие onChange и снова рисуем. Заметьте, инвентарь отрисуется за 150 степов только сколько раз он изменился + 1 на создание, а не 150 раз.
Обмен данными по сети. Нет смысла передавать одни и те же данные.
Искусственный Интеллект - передаем сообщения между объектами, обновляем ИИ только по событию изменения, если обстоятельства не изменились, то нечего заново решать ту же задачу.
Поиск пути
др. области

Сам приём достаточно прост, но в то же время и мощен. С его помощью вы можете вызывать действия с такой частотой насколько это требуется, а не каждый шаг. Это упростит разработку и ускорит выполнение программы.

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

1. Глобальная \ локальная карта

2011-05-19T12:00:00.002+04:00

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

Примеры: Серия Total War, Warhammer 40,000: Dawn of War — Dark Crusade, Infectonator World Dominator, Негоциант, Master of Orion II, Sid Meier's Pirates!, Ka-52 Team Alligator, серия Heroes, Казаки II, Need for Speed Underground 2, серия Jagged Alliance, серия Fallout, X-Com, Castles 2, Star Wars: Empire at War.

Dark Crusade

Основной жанр: Из названии видно что в основном это правило участвует в стратегиях, но как видно, не только в них. Pirates! - приключенческая игра, а Ка-52 и NFS симуляторы.

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

Использование: Обычно делаются 2 масштаба: глобальный и локальный.
В глобальном режиме: можно менять время, которое влияет на всю игру, строить/перемещать свои юниты, добывать ресурсы. Если 2 юнита разных игроков будут находится на одной клетке на глобальном уровне, то происходит бой и игра перемещается на локальный уровень. Причём отражение юнита в глобальном уровне полностью отражается в локальном.
В локальном уровне: здесь, как правило, разрешается локальный конфликт, т.е. решается кто из 2 персонажей может остаться в этой клетке. Почти все что приобретено на локальном уровне остается на нем. Обычно переносится только опыт и некоторое кол-во золота с учётом баланса, реже войска приобретенные в ходе локального конфликта.

Правила геймдизайна

2011-05-18T12:00:00.002+04:00

Здесь будет общий план всех правил:

Глобальная \ локальная карта - Разделение мира на несколько уровней, несколько разных масштабов с, возможно, различным геймплеем. Обычно на 2: на глобальный и локальный. На глобальном обычно время идет быстро, возможна стройка, различные повышения, переход на локации и т.д. На локальном обычно идет бой, глобальное время замедляется или вовсе останавливается, невозможна стройка и т.д.

Общие вопросы геймдизайна

2011-05-17T07:26:00.001+04:00

Теперь я плавно перехожу к циклу постов о геймдизайне. Я считаю что сказано достаточно непосредственно об общем программировании игр и теперь необходимо поговорить об наполнении игр. Пару ссылок по теме:

Геймдизайнеры уже работают давно и у них выработались некоторые методы работы. И вам желательно ознакомится с ними. В общем их можно выразить как набор карт. Каждая игра составляет некоторый набор этих карт. Автор сего блога, то бишь я, тоже начал собирать такие карты/правила. Книжечку о геймдизе я уже выкладывал, и все идеи которые я буду выкладывать здесь, есть там. С маленькой поправкой, здесь будет обновленный, дополненный вариант, а затем и обновится книга. В конце планируется собрать целую книгу этих правил и также выложить её здесь, после того как все правила соберутся и отсортируются в нужном порядке.

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

Первое что надо знать, что каждое правило это один ингредиент. И что из этого вытекает? Что смешав все вместе мы не получим идеал, а в лучшем случае какую-нибудь бяку. Это касается всего: механических деталей, пищевых ингредиентов, красок, кусков кода, любой других ингредиентов. Смешав все цвета радуги мы получим цвет грязи. Вам нравится сладкий чай? И вам нравится соль? Но это ещё не значит что вам понравится сладкий чай с солью. Но. Не добавив соли, либо сахара в блинное тесто, мы получим не очень вкусные блины. Т.о. связки ингредиентов в одном случае дают положительный эффект, в другом - отрицательный. Мы постараемся поискать такие связки и в геймдизайне, те что уже нашли опытным путём и апробировали до нас.

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

Игра с точки зрения Wiki. С моей точки зрения, игра это фильм в котором мы участвуем и на который мы можем влиять теми возможностями которые дал нам разработчик. Чтобы активировать эти возможности нам предоставляют некий интерфейс - интерфейс игрока. Классический и самый контрастный примеры это Dune II и C&C. С точки зрения механики, эти 2 игры практически идентичный, но интерфейс настолько различный, что такое ощущение что это 2 разные игры. Главное то что в C&C интерфейс игрока стал гораздо удобнее, эргономичнее, тем самым серьёзно повысив играбельность. В принципе, интерфейс C&C можно было бы оставить и из Dune II и игра бы совсем не изменилась (т.е. C&C осталась бы той же C&C, та же графика, звуки и т.д.), но изменился бы геймплей. Он бы заставлял игрока делать кучу лишних движении и вместо взаимодействия непосредственно с игрой он бы боролся с интерфейсом. Из этого следует вывод: интерфейс нужно продумать так чтобы игрок не боролся с ним, а полностью задействовал все возможности игры. Об этом мы ещё поговорим в будущем. Что можете взять на ус сейчас это то что интерфейс должен удовлетворять как минимум 2 вещам:

Обратная связь. Если с элементом можно взаимодействовать, то это нужно показать (допустим подсветить), если нет, то дать подсказку почему именно нельзя.
Подсказка. Описание что это за элемент, что ему требуется и т.д.

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

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

Инкапсуляция

2011-05-06T19:04:00.002+04:00

Конечно, я описал схемку инкапсуляции уже в предыдущем посте, но на всякий случай сделаю отдельный пост по теме. Итак, поехали:

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

Обратимся все к тому же методу - Ходьба. Мы сделали этот метод в коде (допустим в секций Step), который двигает наш объект к цели (см. левую часть картинки). Вроде все работает правильно и решили его использовать в других объектах. Copy + Paste и вот тебе код размноженный по некоторым объектам. Затем выяснилось что в этом куске кода закралась маленькая, но досадная и нервирующая, ошибка. Теперь вам предстоит потратить некоторое время, чтобы вспомнить в каких объектах содержится эта ошибка и не дай бог в каком-то объекте напортачить и сделать новую ошибку. В связи с этой неразберихой решили сделать так: весь код вычленить в отдельную функцию и везде где нужно её использовать, а изменение этой функций оставить только тому кто её создал. Назвали этот метод - Инкапсуляцией.
В ГМ нельзя запретить изменение отдельно скрипта, но есть возможность использовать этот метод. См. правую часть картинки. У нас есть скрипт Идти(), мы знаем что он делает (делает шаг в сторону цели), но не знаем как именно (закрашено чёрненьким). Хотя мы и не знаем, но оно делает все верно, а посему используем её. Теперь везде в коде, вместо строчек кода и нас скрипт Идти(), который ясно говорит что он делает, в отличий от тех же строк (в которых ещё надо разобраться что они делают). Если вдруг что-то не так с алгоритмом, неверный, ошибочный, не до конца сделанный или ещё что-то, мы знаем где его искать и что изменять (а изменить нужно только 1 место).

Левая и правая части иллюстраций(части кода) идентичны. Делают одну и ту же работу. Но используются по разному.

Примеры из кода ГМ:
Каждая функция в ГМ инкапсулирована. Тем или иным способом. Допустим метод mp_potential_step, кто знает его устройство? Никто кроме создателя, потому что нигде этого нет. А кто его использовал? Ага, таких набралось гораздо больше. Или допустим функция которую знают все кто маломальски использовал ГМ код: draw_sprite(); Знаете как именно она работает? Нет. А она много чего делает, плюс строк в ней не мало. Но все знают что именно она производит, тем и пользуются.

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

Абстракция

2011-05-06T18:00:00.198+04:00

На текущий момент я доделываю поиск пути и хождение по нему. Так вот, возникла следующая проблема:

Нужна функция хождения с обходом препятствий, но встроенная mp_potential_step() уже не устраивает. К счастью, я заранее сделал функцию-обёртку СделатьШаг() и засунул туда одну единственную строчку mp_potential_step() с параметрами и использовал этот СделатьШаг() где мне надо было. Это может показаться глупо, зачем делать функцию из одной строчки? Но тут мы подходим к одному из столпов ООП: Парадигма абстракция.

Определение в Wiki:

Абстрагирование – это способ выделить набор значимых характеристик объекта, исключая из рассмотрения незначимые. Соответственно, абстракция – это набор всех таких характеристик.

См. иллюстрацию:

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

Так зачем же нужная эта Абстракция? Теперь, если мне надо будет изменить действие СделатьШаг() со встроенной функций на какую-то свою, мне необходимо будет изменить лишь один скрипт в одном месте. И вся программа будет работать по новому с минимальными затратами. Удобно? Ещё бы. Минус то что мы теряем в производительности программы на вызов скрипта. Но здесь вы уже решаете самостоятельно данный вопрос что вам важнее.
Если мне захочется изменить поиск пути с волнового на А*, то пожалуйста! Меняйте реализацию скрипта НайтиПуть() и задача будет решена. Также с реализацией функций Пришли(), мы можем сделать вхождение в радиус, в прямоугольник, стоим ли мы в клетке цели или ещё какие варианты - это не важно, все будет работать отлично и так как вы хотите.

Абстракция - это что-то такое виртуальное, не существующее, но представляемое в своим воображении. Мы примерно знаем что с ней можно сделать и как использовать, но только примерно. Классический пример: фигура. Это слово обозначает абстрактный объект. Физически фигура не существует, потому что мы не знаем что такое, знаем только что любую фигуру можно вращать, перемещать, рисовать, конечно, только примерно, но знаем что можно. Как например, можно нарисовать фигуру? Что вы будете рисовать? И здесь вы будете спускаться к конкретике, т.к. вы знаете какие фигуры существуют. Допустим окружность, прямоугольник, треугольник и др. Это уже конкретные объекты с конкретными действиями, мы знаем конкретно и точно как переместить, вращать и рисовать треугольник и др. фигуры. Суть абстракций выделить общее из всех этих объектов.

Следующий пример, автомобили. Это абстракция. Автомобиль - это некий объект который может передвигаться с помощью человека. Что можно делать со всеми автомобилями? Крутить баранку, давить на газ/тормоз, ключ зажигания для включения двигателя. Это интерфейс. Зная его вы можете управлять абсолютно любым автомобилем! Не важно что у одно руль круглый, у другого эллипсный, у третьего он меховой, у четвёртого он справа и т.д. у каждого автомобиля есть руль и его можно вращать в стороны (если его нет, то это уже не автомобиль, а нечто другое, похожее, но другое). Допустим вы пересели с 9-ки на совершенно другой автомобиль, допустим, лексус. Вы также сможете им управлять, т.к. вы знаете интерфейс автомобилей. Это также может быть тойота, ламборгини и какая-нибудь китайская подделка, которая никому неизвестна. У всех них есть ключ зажигания, газ/тормоз и руль.

Теперь перейдем от машин к нашему коду (взгляните ещё раз на иллюстрацию в начале). См. скрипт СделатьШаг(), это некая абстракция. Что-то сделает шаг. Как оно это сделает? Это не важно, важно то что этот скрипт передвинет объект его вызвавший на шаг вперёд к цели. Реализация может быть любой: скрипт просто пустой (т.е. абсолютно ничего не делает), просто двигает, двигает к цели не учитывая препятствии, учитывая их или по методу потенциальных путей и т.д. Все эти скрипты как рули в машинах, они разные, но делают одно и то же дело, хоть и по разному. Это и есть абстракция. И смысл в нем такой как и писалось ранее:

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

Чтобы сохранить общую работоспособность программы, нужно чтобы этот скрипт был работоспособным. Один вариант, если этот скрипт не содержит синтаксических ошибок, как и программа, тогда не будет фатальной ошибки. Второй вариант, если скрипт рабочий в логическом плане (т.е. выполняет свою функцию полностью) и остальные части программы, то все будет работать логически правильно. Вроде бы, все просто и логично, но делая простую схемку можно наткнуться на несколько непростых проблем. Синтаксические проблемы оставим, эти легко решаются, остановимся на логических. Опять см. иллюстрацию. Допустим, СделатьШаг() двигает объект вперёд объект на шаг, если нет препятствий на пути. Если препятствий по пути не встретится, то все будет рабочее и все будет хорошо. Но. Встреться препятствие как скрипт будет пропускаться, т.к. объект двигается, если нет препятствия, и тогда этот скрипт будет вечен (объект просто встанет как вкопанный до его конца). А раз он вечен, то и вся конструкция вечна, другими словами не добирается до выполнения, т.е. не то что нужно, либо не рабочая. Решение здесь, либо не учитывать препятствия, либо найти альтернативную свободную точку. Другой пример, более интересный. Скрипт СделатьШаг() рабочий, обходит препятствия, а функция Пришли выдает правду только тогда когда мы очень близко к цели, ближе чем длина шага. Т.о. если вдруг юнит немного смещен, то когда он будет подходить к цели близко, то скрипт Пришли не выдает правду, т.к. мы ещё далеко по его мнению, но шаг настолько велик, что мы перескакиваем цель и вновь оказываемся слишком далеко (типа как в сказке про кузнечика, который прыгал всегда очень далеко, но прыгнуть чуть-чуть он не умел. Тогда он смог попасть домой. И здесь точно также). Допустим мы стоим в 0, шаг 1, точка назначения 2, считается что мы пришли, если разница между целью и объектом меньше 0.5. Дойдем отлично через 2 шага (разница будет 0, что меньше 0.5). А вот если мы будем находится в 0.5, а не в 0, то мы никогда не дойдем (через один шаг будет 1.5, а на второй 2.5 и разница не меньше чем 0.5). Решений здесь тоже несколько: учитывать что мы пришли по ширине шага. Либо делать шаг минимум(расстояния до цели, длина шага). Обе проблемы реальны, взяты с моего проекта. Этот код находится в нескольких местах, но т.к. он абстрагирован в скриптах (т.н. функций-обёртки), то мне нужно поменять код только в одном месте и проблема решена. Или если мне нужно сделать новый тип хождения, то тоже нужно поменять только 1 место. Удобно, быстро.

Следующее. Интерфейс скриптов необходимо сделать ДО того как написан реальный код. У нас могут быть скрипты с названиями интерфейсов, но совершенно пустые. С синтаксической точки зрения, всё правильно, с логической нет, поэтому проект запуститься и будет работать, но будет работать не так как мы хотим. Пример, снова смотрим иллюстрацию. Каждый квадрат это скрипт. Вы их можете накидать чисто теоретически, как заглушки. В этом случае мы создаем интерфейс, но без реализаций, мы смотрим как скрипты подходят друг к другу (если вы читали мою книжечку о геймдизе про кабели, то имеете понятие.). На самом деле, создание интерфейса гораздо важнее, чем реализация. Но 99% новичков этого не видят, а потом у них возникают серьёзные проблемы и так же в 99% случаев просто забрасывают проект или в лучшем начинают сначала. Так вот, чтобы не начинать проект сначала, нужно заранее продумать проект и в частности интерфейс. На иллюстраций есть почти готовый интерфейс, но реализаций 0. Т.е. вы видите, что юнит должен совершать шаг, если он от цели далеко, но как он совершает шаг вы не знаете (обходит он препятствия или нет, прямо он идёт или по синусу и т.д.). Также вы не знаете как я нахожу путь, по волновому алгоритму или по А*. И это не важно, важно то что здесь у меня ищется путь, а тут юнит делает шаг. Такую схемку вы должны себе рисовать всегда, так вы будете лучше видеть вашу программу, а так же будете лучше видеть слабые места в программе.

Теперь вернемся к теме. Важно ещё то, что эти функций должны быть связанны, а ещё лучше полностью инкапсулированы. Ясно что волновой алгоритм и А* работают по разному и что если связать ходьбу непосредственно с алгоритмом поиска, то он будет чересчур привязан и при подмене с одного на другой возникнут проблемы. Просто: функции поиска пути выдают некий список точек. Всё. Они ни с чем не взаимодействуют, они выдают готовый список точек. Не важно, правильный он или нет, он должен соответствовать списку точек. Далее, сама ходьба берёт этот список и идёт по нему. Ходьба и поиск пути не взаимодействуют с друг другом на прямую. Как и вы не идёте на завод за чипсами, а идёте к посреднику - в магазин. Здесь точно также:

Скрипт ходьбы смотрит пуст ли список точек, если нет, то СделаемШаг(). Принимаем список точек
Нужно идти в точку, поиск пути строит список точек. Выводим список точек

Эти 2 алгоритма не взаимодействую друг с другом, они работают через посредника. Теперь нам не важно какой алгоритм в поиске пути (волновой или А*), главное чтоб он выдавал список и неважно какой алгоритм в СделатьШаг(), главное чтоб он принимал список точек. Они делают своё дело, как именно не важно.

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

Возьмем сортир.

Абстракция: все туалеты имеют ручку слива.

Инкапсуляция: нажимаем на ручку слива, туалет сливает воду, как он это делает не важно (механизм закрыт крышкой).

Скрипт поиска пути.

Абстракция: при использовании, все поиски пути возвращают список точек. Волновой или А* или ещё какой, они все вернут этот список.

Инкапсуляция: используем алгоритм и он возвращает список точек, как он это сделает не важно. Все алгоритмы используются через скрипт НайтиПуть(). Но А* делает это так, а Волновой вот так.

Update: Хочу ещё немного подробнее рассказать про разницу между инкапсуляцией и абстракцией.
Инкапсуляция: Возьмем известную функцию mp_potential_step(), допустим она занимает десяток строк, все из которых необходимы для работы. Представьте что у вас есть 5 объектов: во всех из которых где-то нужно использовать, а в некоторых нужно несколько раз. Если бы мы решили просто пихнуть в эти места, то изменять все это было бы очень трудно. Да? 5 объектов да минимум по 10 строк уже 50строк кода. Причём одинакового. Это хорошо что вы не забудете куда либо написать все 10 строчек из этого алгоритма! А если забудете? Для этого придумали штуку - инкапсуляция. Теперь вы, везде где нужно, используете функцию mp_potential_step(); Вы знаете что оно делает, но не знаете как именно. Да и это не важно, если все работает по вашему.

Абстракция: А теперь возьмем 2 скрипта mp_potential_step() и mp_linear_step(). Как мы видим обе эти функций выполняют одну и ту же работу - идут к точке. Но выполняют это по-разному. Поэтому мы можем объединить их в одну функцию - Идти(). И в эту функцию подставлять одну из тех что выполняют шаг. И мы выбираем, хотим ли мы чтобы шаг делался с обходом препятствии, либо без них, а может ещё как-то по нашему.

Вот и вся разница! Одно скрывает реализацию и выставляет открытый интерфейс как с mp_potential_step, а другое находит в них общее и использует это.

Это мощный инструмент ООП и очень рекомендуется его использовать, чтобы получить все плюшки. Вы можете его использовать в других местах, кроме ходьбы. Допустим стрельба, прыжок, ИИ и др. места. найдите общее в них и вынесите это отдельно. Затем вы их можете менять как хотите. Например, я нашёл что скрипт СделатьШаг делает одно и то же, несмотря на то что будет ли там mp_potential_step() или похожий алгоритм, поэтому я решил его абстрагировать. Почему? Потому что я знал что буду менять его на свой аналог и если бы я не абстрагировал этот скрипт, то пришлось бы его менять его в нескольких десятках местах, причём очень часто. А это мне совсем не хочется.

Отображение игровых переменных

2011-01-27T02:52:00.002+03:00

На форуме я уже писал про отображение игровых переменных, но тогда меня не поняли или поняли, но не до конца. Т.к. это одна из самых важных вещей в разработке игр, то я ещё неоднократно буду возвращаться к этой теме. В той теме я описал в более общем виде, здесь же пройдемся по более насущным и простым вещам.

Одной из интересных игровых идей является изменением величины не сразу такая как она есть, а постепенно. Ну например, допустим у вас 75 жизней из 100. Вам наносит урон враг в 25 единиц. И мы не сразу отображаем 50 жизней, а постепенно убавляем 75 до 50. Это может быть как обычная цифра, так и какая-то полоска, где полоска от 50 до 75 жизней отображается красным, т.о. показываем что жизни отбавляются. Пьём лечащую бутылку, показываем зелёный отрезок от 50 до 100.

При этом игрок знает в какую стороны изменилось значение. Если это деньги, то он видит как изменилось значение, а вот если отобразить значение сразу, то сложно понять отбавилось или прибавилось. Либо игроку надо будет вычесть предыдущее значение от текущего чтобы узнать разницу, а ведь вы не хотите загружать не интересной и не нужной работой?

Сама идея проста. Выбираем то значение, которое должно быть "мягким".
1) Создаем под нее 2 переменные: реальное, текущее значение (real_value) и отображаемое (draw_value). Вместо var поставьте своё название.
2) Теперь необходимо придумать функцию "перемещения". Сначала, по русски: Если разница между отображаемой величиной и реальной больше, то отображаемая величина стремится к реальной, а иначе делаем их одинаковыми, если они ещё не таковые. Как стремится? Вы можете выбрать по своему разумению. Я вам предложу 1 вариант сейчас и несколько позже. А сейчас код:

if(abs(real_value - draw_value) > 0.009)
draw_value += (real_value - draw_value) / 8;
else
if(value != draw_value)
draw_value = value;

Всё. Теперь осталось рисовать переменную draw_value вместо real_value. Или можете попробовать их вместе, чтобы узнать разницу.

Функция "перемещения" - (real_value - draw_value) / 8; Перемещается гладко.
Можно линейную функцию для небольших величин - sign(real_value - draw_value);

Также вы можете применять разные спец. эффекты. Допустим как вращающийся счётчик, для денег или ещё чего-нибудь. Цветные полоски, как я описал выше. Придумайте своё.

Сам пример (в формате GM8, 10кб). Отображает координату мышки по Y.

Игровой цикл - Практическая часть

2011-01-13T03:33:00.003+03:00

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

Обычно игра начинается с вступления. В этом вступлений показывают фирмы производящие игру, издающие, да и просто спонсоры, видео показывающее вступление к сюжету. Всё это может быть интерактивным, если есть необходимость. Что важно, это начало игры и если вы предполагаете что игра очень интересна, то вам необходимо сделать пропуск вступления иначе игроки будут злится пока смотрят начало в сотый раз. Далее попадаем в меню из которого мы можем выйти или перейти непосредственно к игре, а из неё обратно. Пока получается:

Вступление → Меню ↔ Игра

Каждый такой «пункт» состоит из 3 частей: инициализация, выполнение, деинициализация.

Инициализация. Здесь мы создаём нужные объекты, загружаем нужные файлы и проделываем остальную подготовительную работу.
Выполнение. Тут мы выполняем все подготовленные ресурсы по написанным нами правилам. Показываем видео, обрабатываем клавиши/мышку, играем в игру и т.д.
Деинициализация. А вот здесь мы уничтожаем всё что насоздавали. Но не думайте что здесь можно только уничтожать. Этот блок можно использовать и для создания какого-то нового элемента, для перехода из одного состояние в другое.

И «Меню», и «Вступление», и все остальные элементы состояний будут иметь все эти 3 события. Получилось что?

Вступление
1. Инициализация: Загружаем нужные файлы, допустим видео.
2. Выполнение: Показываем видео. Если (нажата любая клавиша на клавиатуре или мышке) или (видео закончилось) то переходим к состоянию Меню.
3. Деинициализация: Удаляем загруженные видео.
Меню
1. Инициализация: Загружаем нужные файлы, нужные изображения.
2. Выполнение: Показываем меню. Если (нажата левая кнопка мыши на кнопке «Новая игра») то переходим к состоянию Игра. Если (нажата левая кнопка мыши на кнопке «Выход») то переходим к состоянию Выход.
3. Деинициализация: Удаляем загруженные изображения.
Игра
1. Инициализация: Загружаем нужные файлы, создаём карту, расставляем юнитов, игрока, настраиваем состояния.
2. Выполнение: Выполняем все правила игры. Если (нажата левая кнопка мыши на кнопке «Выход» и включено игровое меню) то переходим к состоянию Меню.
3. Деинициализация: Удаляем загруженные изображения, сохраняем состояние игры в файл (автосохранение).

Состояние Выход можно добавить видео, что-то интерактивно, либо просто выкинуть игрока в Windows. Это основная схема всей игры в целом, во многих играх она одинакова, хотя может и различаться, экспериментируйте. Например, меню может быть частью игры, допустим магазином или, допустим, между «Меню» и «Новой игрой» можем настраивать саму игру или персонажа. Вступление может быть какой-то мини-игрой и т.д. Изменяйте как хотите.

Подробнее о структуре я описывал тут с примером.

Теперь поговорим о части состояния «Игра» Выполнение. Часть эта самая сложная, но и самая главная во всей игре. Именно ради неё игрок поставил игру и запустил её. Создание этой части очень обширно. Создаётся он из разных элементов. Описание всех этих элементов (приёмов) мы рассмотрим позднее. Их очень много, поэтому буду публиковать их постепенно. Ждите.

Игра = График + Звук + …

2011-01-13T01:53:00.004+03:00

Сегодня хочется рассказать вам о том чем занимаемся, что такое компоненты, как с ними работать и т.д. Приступим к разбору «Что же такое игра». Можете для примера взять любую игру и попробовать разобрать её вместе со мной. Только берите более ли менее стандартный вариант, не надо жаловаться типа: «А вот в моей игре такого нет!», «А вот здесь не так» и т.д. Мы рассматриваем большинство, а не исключения.

Игра есть некоторый чёрный ящик (типа телевизора), который что-то делает, но что и как не показывает. Мы видим только результат этой работы. Обозначим игру как нулевой уровень:

Это что-то такое красивенькое, имеющее какую-то форму. Очевидно что любая игра состоит из визуальной составляющей, звукового сопровождения и правил по которому это всё работает. Смотрим:

Эти элементы отображают готовые элементы, т.е. графика - это полностью все спрайты, эффекты, все функций отвечающие за отрисовку (графический движок); Звук - все звуковые эффекты, музыка, все функций отвечающие за вывод звука (звуковой движок); Правила - всё что относится к тому как надо играть.
А где «Уровень 1»? Мы пропустили очень важный шаг, ведь эти элементы не могут быть сами по себе, верно? Значит их надо объединить по каким-то правилам. Добавим «промежуточный» уровень который всё это объединяет в игру:

Теперь у нас есть основа. То что нужно понимать вам как разработчику игры, т.к. эти слои скрыты от игрока. Как всё это работает? Когда мы запускаем исполняемый файл загружается игровой движок (т.е. основа). Движок смотрит на правила, ага, только загружаемся? Значит игроку нужно показать заставку. Загружаем нужную графику и звуки и показываем их. Что дальше? По правилам, меню. Загружаем графику и звуки для меню, т.к. по правилам в меню должно быть взаимодействие игрока с игрой, то вводим обработку мыши/клавиатуры. Нажимаем на область изображения «Новая игра», по правилам начинается сама игра. Загружаются нужные файлы, создаются новые объекты и начинаем само действо. Как это создать и с чего начать конкретно расскажу и покажу в следующей теме, а пока просто представьте себе что и как устроено.

Если глянуть глубже, то графику строит специальная библиотека - графический движок. Это готовый набор функций, который позволяет вам построить графику сразу (допустим OGRE, Unreal Engine и т.д.). Движок - это станок - состоит из деталей связанного набора функций API, например, DirectX, интерфейс вывода трёхмерных примитивов. Сам DirectX состоит из чего ещё, но это последний «рубеж» который необходимо вам знать и понимать, хотя бы поверхностно (чтобы понимать как строится изображение на экране). Со звуками, как и с другими частями игры, та же история, что и с графикой, кроме правил.

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

Конечный вариант нашей структуры (кол-во уровней вложенности зависит от конкретной реализаций, здесь изображена примерная схема):

Иерархия объектов

2010-12-22T05:47:00.007+03:00

Сейчас тема посложнее и гораздо объёмнее. В моем текущем проекте необходима иерархическое, наследственное поведение объектов. А что это такое?

Допустим у нас есть юниты. Есть войны, а есть работники. У них есть что-то похожее, оба они ходят, у обоих есть параметры «Здоровье», «Команда», «Опыт». Смотрите:

И нам приходится писать код и там, и там. Причём на половину он идентичен. Как же этого можно избежать этого бессмысленного повторения? А для этого в конце 60-х придумали такую штуку как Объектно-ориентированное программирование (в дальнейшем ООП). Саму суть я сейчас расскажу, но если вы хотите углубиться вам придется почитать информацию по ссылочке. Так вот, плюшки этого ООП реализованы в ГМ (не полностью, конечно, но есть). Смотрим:

Заметьте как оба объекта «похудели». Использовать этот способ несложно, просто нужно в свойствах объекта выбрать объект в свойство Parent (Родитель), в нашем случае выбираем объект «Существо» (а сам объект в этом случае будет «Потомком» «Существа»). Но это ещё не всё. Не менее важное действие: теперь надо определить какие события, в каких частях, и в какой последовательности будет вызываться родительский код. Делается это функцией event_inherited(); (вы также можете найти это действие кнопкой, рядом с кнопкой скрипта, там будет надпись «CALL EVENT», советую пользоваться именно этим способом). Грубо говоря, это тоже такой же скрипт как и другие (ничего не возвращает), но вызывает весь код родителя в таком же событий (если было вызвано в Create «Война», то будет исполнено Create «Существа»). Всё, теперь оба объекта и «Войн», и «Рабочий» имеют все параметры и действия своего родителя «Существо», но и отличаются друг от друга. Важно отметить, это происходит не автоматически, а по вызову event_inherited();, это важно. Если у родителя есть Create и в нём есть переменные нужные для потомка, то в Create потомка нужно вызвать event_inherited();. Причём, если в Create потомка используются переменные родителя, то нужно сначала вызвать event_inherited();, а потом исполнять Create, иначе будет ошибка, переменных-то ещё нет. И тут возникают, иногда, забавные случаи, но об этом позже.

Далее допустим нам понадобился маг и новые параметры для боевых существ:

Но стойте! Мы же работаем методом ООП! Выделим общие свойства в новый объект «Боевой» и вуаля:

Вот такая у нас получилась структурка. Кстати, вы можете заметить как направлены стрелки - это показательно. Потомок вызывает событие родителя. Здесь важно понять, что если Войн вызывает событие Create родителя это ещё не значит что «Боевой» вызовет Create Существа (если вы так запрограммировали или если забыли поставить этот чудесный скрипт) и у Война может не оказаться переменных «Существа» - «Здоровье», «Команда», «Опыт». Будьте внимательны, либо тщательно продумывайте иерархию (желательно с подобными зарисовками, если иерархия сложна). Зачем же это надо? Всё просто, мы получаем несколько плюшек в следующих вещах:

Уменьшается объём кода. Причём тем сильнее, чем больше объектов одного родителя
Теперь чтобы изменить поведение всех объектов определённого родителя, то достаточно изменить всего 1 объект. Если потомков, допустим 10, то ваша работа ускоряется в 10 раз! Да и вы получаете прекрасный инструмент для гибкого изменения поведения потомка.

О плюшках поговорили, а теперь заикнусь о проблемах (а как же без них? ;) ).

При наследовании все данные нужно инкапсулировать по максимуму.

Что такое инкапсуляция? Вкратце, это возможность взаимодействия с объектом через его открытый интерфейс. Например, самый банальный пример, вы пользуетесь туалетом? Наверняка. А знаете как оно устроено? Наверняка, нет. Но даже не зная устройства унитаза вы им пользуетесь через открытый интерфейс - ручку слива воды. Нажали, дёрнули и вуаля! Объект используется, работает на нас. Или вот про компьютер: вы знаете что происходит в компьютере просто при нажатий кнопки? А происходит много чего, но вам это не важно и не нужно, вы знаете как работать клавиатурой и знаете что она делает и это ваш открытый интерфейс, через него вы работаете.

Т.е. всё что используется в родительском объекте должно оставаться там и только там. Чем меньше связей, тем лучше (тем безопаснее интерфейс), в идеале 0 связей. Но так не получается, мы используем свойства и функций родителя в потомке. Допустим опыт. У каждого объекта своё понятие «набирания опыта». Рабочий получает опыт за работу, Войн за махание мечом на тренировках и поле боя, а маг ещё и за учёбу в библиотеке. Принцип инкапсуляции предлагает нам сделать общий интерфейс. Что это такое на языке GML? Нам необходимо ввести скрипт получение_опыта(кол-во опыта); (настоятельно рекомендую запихнуть в папку с названием того родителя к которому относится) В скрипте строка начисления опыта поставим банально exp += argument0; Теперь в потомках этого родителя ставим этот скрипт.

если(войн ударил противника)
получение_опыта(50);
если(войн ударил своего ИЛИ получил урон)
получение_опыта(-5);

В этом случае, если вы решите отключить опыт или изменить его действие (по каким-то причинам), вам необходимо изменить 1 скрипт (просто удалить оттуда код или изменить его). Если же вы делаете просто кодом, не через скрипт, то тут возникнут проблемы. Во-первых, нельзя будет просто так отключить «Опыт», иначе вся игра будет падать под ошибками отсутствующих переменных. Во-вторых, нужно будет пройти все места и изменить действие набора опыта, что может оказаться довольно сложной задачей. Если игра готова, а производительность со скриптами не устраивает, то все скрипты можно развернуть, а вот обратное будет сделать тяжелее.

Проблема вторая, гораздо сложней. Она уже касается действий. Допустим вам надо чтобы рабочий, маг и войн находили путь к проблеме. Добавим остроты, уровень содержит не выпуклые многоугольники, поэтому необходим сложный алгоритм типа А*. Плюс нам необходимо находить путь достаточно быстро чтобы не подвешивать игру, но и чтобы быстро находить путь до быстро передвигающейся цели. Нетривиальная задача, да? Да-да, так и есть. Решение на текущий момент ищется, но наметки на решение есть.
Сделать что-то вроде шлюза. Объект потомок даёт команду «Нужно переместится в точку (x; y)», объект родитель (в нашем случае, «Существо», смотрим на схему, ходьба именно в этом объекте) проверяя каждый шаг точку назначения, если она оказывается не пустой, то идёт проверка на видимость. Если объект в прямой видимости, то идём методом потенциальных полей (mp_potential_step(_x, _y, _speed);), иначе строим А* путь и идём по нему. Можно устроить дополнительные проверки: если впервый раз строим путь А*, иначе если нужный объект сместился на большое расстояние. Если объект сменился, все настройки поиска сбрасываются.

А проблема заключается в следующем, как сделать так чтобы весь код отвечающий за ходьбу был в родительском объекте? В принципе, попробую поискать решение проблемы в первой проблеме через инкапсуляцию. Т.е. если мы используем шлюз, мы используем в потомках простой скрипт установки места назначения или объекта. Такой скрипт мы можем запихнуть в любой потомок, а весь код останется только родителе. Если же я решу использовать вместо А* другой алгоритм, усовершенствовать его или написать полностью свой мне надо будет изменить код в родителе и всё! Потомки ничего не знают про А* и алгоритмы движения, они говорят родителю «Шеф, трогай туда», а родитель уже думает как туда доставить. Инкапсуляция!

Заключение:
Наследственность в ГМ реализована не полностью, но то что есть даёт огромный простор для творчества, ускоряет и упрощает разработку в несколько раз! Пользуйтесь этой интересной фичей. Тем более что наследственность можно реализовать в каждой игре. В каждой из них есть базовый объект (Родитель), например, монстр, твёрдый объект, оружие, и есть множество различных потомков.

Инструменты отладки

2010-12-22T02:18:00.003+03:00

Итак, после очень долгого перерыва, я снова возвращаюсь сюда, чтобы задокументировать свои идеи и держать себя всегда в струе. Сегодня будет несколько тем о которых я хочу рассказать. Первая из них это про инструменты, которые нам очень понадобятся. В дополнение к вот этой теме. Все инструменты которые будут перечислены задействуют встроенный отладочный режим (Run → Run in Debug Mode (F6))

Теперь вместо своей переменной debug, можно использовать переменную debug_mode.

if(debug_mode)
{
/*В этом случае код будет выполнятся только в этом условий*/

switch(debug_modes)
{/*А вот этот блок придётся оставить, чтобы отделять отладочные данные, если их будет слишком много*/}
}

Второй инструмент который вам может понадобится это show_debug_message();, почти что show_message(); но не останавливает саму работу, похоже больше на лог, но не в файл, а в список сообщений.

if(debug_mode)
{
if(error_occured)
show_debug_message("Произошла ошибка, примите меры.");
}

В этом случае ошибки будут появляться в списке сообщений Tools → Show Messages. Это не будет останавливать игру, если это действительно не необходимо, но и даст понять об ошибках которые происходят. А если что вы всегда можете сделать паузу и спокойно вникнуть в эти сообщения.
Какие от этого плюсы? Плюсов, в принципе, два:

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

Конечно, это не отменяет предыдущего варианта. Так что используйте то что больше нравится вам. Одно скажу точно, использовать вы их точно будете если проект будет больше чем "Hello, World!!!" В моём нынешнем проект иногда возникают такие ошибки что просто так их не найти, но всё же эти инструменты помогают ускорить процесс отладки.

P.S.: В конечно варианте (т.е. для пользователей, для игроков) весь код что отвечает за отладочную информацию необходимо удалить, дабы ускорить процесс и просто не загромождать игру тем что не будет использоваться. Не забудьте перед этим сделать копию!

Перерыв

2010-12-20T23:05:00.002+03:00

После долгого перерыва я снова возвращаюсь сюда.

Разбор хвостов я планирую сделать чуть позже, после обработки всей информации что я здесь написал. Сейчас же я веду свой маленький проект, который планирую завершить (хотя бы привести в играбельный вид) к Новому Году. О нём узнаете чуть-чуть позже. А теперь же, после некоторых тёрок, я решил немного переквалифицировать свою работу. Перенести её из чисто теоретической в практическую плоскость. Теперь работа будет происходить следующим образом:

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

Теперь все проблемы разработки будут всплывать наружу и все [почти] подводные камни будут видны и известны вам.

P.S.: Никогда не подумал что тема с опросом пройдёт так быстро, но он закончился. Проголосовало двое, я и WfalconW. :D Ну... Главное, что были комментарий по которым я могу ориентироваться в дальнейшем.

Форумная игра. Идея.

2009-09-12T02:00:00.009+04:00

Этот пост будет редактироваться.

Над ошибками мы по колдуем попозже. Сейчас я поразмышляю о конкурсе. А именно: есть тема «Форум» и надо сделать по этой теме игру. А теперь, что именно будем делать, как и зачем...

Update (20.12.2010): На текущий момент не предполагается вести эту тему дальше. Остаются только идеи для дальнейшего использования. Сам конкурс давным-давно закрыт. Результаты можете видеть выше в теме.

Есть тема, но что же с ней делать-то? Жёстких и чётких рамок у нас нет, поэтому поле для экспериментов к нас огромное, несмотря на то что есть заданная тема. Сначала определимся с жанром. Я люблю стратегий значит делать будем стратегию. Стратегию хочу сделать казуальной. Вы когда-нибудь видели стратегию в которую может играть кто-угодно, несмотря на навыки? Вот сейчас постараемся придумать такую.

Что есть жанр стратегия? Это нечто такое, где вы можете принимать различные решения для достижения поставленной задачи. Что нам нужно? Что-то такое в роли проблемы, в которой можно поставить задачи, а затем решить их возможными решениями. Как происходит это обычно: есть враг, ставим задачу его уничтожить, строим юниты и шлём на него. В основном действуют только моторно-двигательные рефлексы, т.е. кто быстрее тот и победил, а не тот кто умнее. Сейчас мы ликвидируем все инструменты отвечающие за моторно-двигательные функций человека и поставим инструменты для размышления.

Я использую инструменты текстовых квестов: заготовленные предложения. Но с маленьким дополнением, с вариативной возможностью, т.е. возможностью настроить предложение. Предложение может понять каждый кто умеет читать. Выбрать из имеющихся предложений может любой кто обладает хоть толикой логики.

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

Продолжение. От 14.09.09

Игровой цикл. Я опущу пока меню, т.е. сейчас мы будем рассматривать всё что непосредственно касается самого игрового процесса.

Нажали «Новая игра» и после этого нам выдают условия. Условия могут быть разными, так и выбранными. В зависимости от условий будут наши действия. Наша задача разместить задачи для подчинённых так чтобы превратить нынешние условия к нужным. Задачи составляются в виде предложений. Предложения относятся к какому-то объекту и от типа объекта зависят «Действия». Выбрали объект с которым мы хотим взаимодействовать, у нас появляются все нужные действия возможные с этим объектом. У действий есть свойства (например, действие — «атаковать», свойства: кого, чем(сколько), доп. условия (с фланга и др.) и др.).

Это иллюстрация как строится предложение. Прежде всего, выбирается объект с которым будем взаимодействовать. Появляется список возможных действий с этим объектом. Выбираем действие и появляются возможные свойства. Свойства можно стекать, т.е. сделать целую цепочку свойств. У свойства действий есть параметры, которые также можно изменять. Из всех этих инструментов можно строить предложения, они же действия. Кол-во инструментов по строительству предложения можно ограничить сложностью. Чем больше сложность, тем больше инструментов. Пример, на среднем уровне появляются свойства, а на сложном ещё и их параметры (чтобы не нагружать новичка не нужными параметрами).

Построение предложений должно быть безопасным. Некоторые свойства обязательные, такие как, свойство «Кого» в действий «Атаковать». Некоторые свойства взаимоисключающие, т.е. должно быть либо то, либо другое, например, нельзя совместить два свойства «Штурм» и «Тихо» в действий «Атаковать».

Какие есть свойства? Есть свойства исключающие, т.е. имеющие отрицательный эффект или приставка «Не» (пример, «Атаковать» «Армия», но «не» «Самолёты»). Есть обычное свойство, т.е. настраивающее действие. Есть свойство условия, т.е. приставка «Если …, то …» (пример, «Если» на базе противника нет «ПВО», то «Атаковать» «Самолётами»).

Временная информация. Для расшифровки предложения будет использоваться парсер. Также будет кодирование предложения в польскую запись для удобной транспортировки. Именно в этом будет состоят ожидаемая сложность.

Предложение введённое пользователем (по методу конструктора, а не буквенно, естественно, т.е. сделанное из готовых «кубиков») будет расшифровываться и обращаться в действия.

Кол-во действий будет уравновешено по бухгалтерскому методу, т.е. если Кредит больше Дебета, то выдаётся информация о том что нужны доп. действия со стороны пользователя и предложится либо отменить Действи(-е/-я), либо дополнить их. Например, сказано «Атаковать» группой самолётов, но таких сейчас нет, то предлагается либо отменить приказ, либо отдать приказ о доукомплектации приказа. т.е. реализация «умного» менеджмента.

Сейчас нужно определиться с набором действий и их свойствами:

Атаковать
Что (Основное)
Чем
Как
Безшумно
Штурм
С фланга
Оборонять
Что (Основное)
Чем
Как
Круговая
Фронтальная
Захватить
Что (Основное)
Чем
Построить
Что (Основное)
Пусто

Набор условий:

Имеющиеся ресурсы
Местность
Погодные условия
Ресурсы на местности

Списки будут дополняться.

Основные ошибки современных разработчиков (Часть Первая)

2009-09-11T13:59:00.002+04:00

Разработчики, будь то новички, среднего уровня или даже профи, совершают ошибки. А человек имеет такое свойство, учиться не только на своих ошибках, но и на чужих. Начнём их разбирать.

Начнём мы с профи. Почему? Да потому что они совершают их меньше всего, а если и есть то это, как правило, силы свыше. Итак, ошибка номер раз:

1) Игра не технология, это набор интересных действий или событий для игрока.

Это самая главная ошибка, которую сейчас делают каждый первый разработчик ААА проектов. Скорее всего они это понимают, но законы бизнеса трактуют им другую дорожку развития проекта, а именно: красивая картинка залог хороших продаж. Да, это так. Чем лучше картинка, лучше реклама, тем больше продаж. Но это не значит что проект становится лучше. И вот тут вам нужно решить что вам надо: либо вы делаете проект продаваемым, либо играбельным. К сожалению, я ещё не видел проектов совмещаемых эти два свойства, они практически взаимоисключаемы. Кстати, под технологией я подразумеваю не только графику, но и часть геймплея.

Смотрим Assasin's Creed. Красивая графика и очень сложная технология паркура, мощная рекламная компания, естественно высокие продажи. Но что мы видим в каждой рецензий на эту игру? Через несколько часов игры, восхищение плавно перетекает в скуку. Действия игрока одни и те же, естественно, что это всё надоедает. Те огромные мощности которые были потрачены на графику, на паркур, делают хорошим только первое впечатление. А что надо чтобы сделать хорошим впечатление два, три и другие? Нужно в эту игру вместит ещё несколько суперных технологий. Но это невозможно сделать в короткий промежуток времени и за те (немаленькие) суммы денег что были потрачены на Assasin's Creed. Есть конечно выход… Сделать несколько технологий по-меньше. Знаете такую игру? Она называется Spore. Несколько этапов игры (пять) по одной технологий на этап. Разбавили? Ещё как! Но получилась разведённая бодяга. О чём на и толкуют нам десятки рецензий, о том что лучше поиграть в аналоги этих технологий. Этап бактерий не имеет аналогов или почти не имеет, поэтому он наиболее интересен. Этап развития существа есть аналоги в виде Wolf и Lion. Этап стратегий, ну тут всё ясно, есть огромная куча стратегий превосходящих на несколько голов стратегию из Spore. Но! Здесь они все вместе, а это играет несколько другую роль. Пример GTA. Две технологий - шутер и гонки. Обе они слабее аналогов, но вместе они дают потрясающий эффект. Главное найти баланс между своими возможностями и технологией. Сейчас покажу:

Один прямоугольник — одна технология. Чем он шире, тем больше времени потрачено. Чем больше буквы, тем проработаннее технология. В случае с профи, правило «Чем больше времени, тем лучше технология» работает почти всегда.
Как видите, геймплей «чистокровных» игр (Civilization, Need for Speed) более глубок чем в смешанных (GTA, Spore),т.к. на них потрачено больше времени на одну технологию. А геймплей Assasin's Creed расчитан на продажу, а не на удовольствие игрока, т.е. чтобы удивить и чтобы игрок купил. Ну это законы бизнеса, если хотите остаться на плаву, то надо делать так как делают старшИе дяди. А что надо сделать, чтобы разнообразить геймплей Assasin's Creed? Если вставить в неё технологий размером менее пол года они будут блёкло смотреться на фоне старших технологий, если же добавлять технологий такого же уровня, то на доработку игры потребуется ещё столько же времени и денег сколько уже потратили. Делайте выводы. Сначало решаете вопрос: «Что вы хотите получить?». На что потратить время больше, на что меньше. Что добавить, а что выкинуть.

А сейчас я вам предложу технологию по настройке игры в стиле РПГ. Очень интересно что у вас получится. Итак, представьте что игра это персонаж. У «персонажа» есть навыки (это части игры). Навыки имеют стоимость: время и деньги (что-то стоит денег, что-то времени, а что-то и того и другого). У вас есть определённое кол-во этих ресурсов (сколько, определите сами) и вы можете на них «купить» «навыки». Навыки:

Графика (1 ед. время)
Геймплей (1 ед. время)
Звук (1 ед. время, 1 ед. денег)
Интерфейс (1 ед. время)
Реклама (1 ед. денег)

Примерные цены. На что бы вы потратили? Предположим что 1 ед. время стоит 1 ед. неделю, а 1 ед. денег 1000р и в запасе есть 2 месяца (8 ед. времени) и 3000р. (3 ед. денег). Я бы потратил так:

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

Профессиональную ошибку мы рассмотрели, больше ошибок они не делают. Смотрите топ последних лет и вы поймёте (GTA IV, Fallout III, Mirror's Edge, Empire: Total War, Left4Dead, Mass Effect, Race Driver: GRID и др.). Переходим к касте по ниже, к разработчикам ещё не шароварок, но уже не шедевров.

Маленькое дополнение (и тоже от профессионалов). Был спор про ботов из Q3, про то как они были круты и почему таких не делают в остальных играх. Выяснилось что человек работал над диссертацией к ИИ (зовут его Пол). Джон Кармак завербовал этого человека. В последующем Пол работал по 12 часов в сутки чтобы сделать невозможное и он это сделал (что именно вы можете прочитать тут (pdf, 2.18 mb)). Если у вас есть желание работать над особой технологией по 12 часов в сутки около года, то пожалуйста, иначе лучше просто отложите Наполеоновские амбиций и сделайте что-то попроще, но сделайте это до конца.

Обработка ошибок

2009-09-11T13:58:00.001+04:00

Об этой вещи я уже писал, но хотел бы ещё раз вернуться к этой теме, тем более что она важна. Итак, тема — Обработка ошибок.

Абсолютно все новички этим инструментом не пользуются до тех пор пока программа работает отлично, и до тех пор пока они не потратят достаточно времени на отладку программы. Как мы знаем, насколько не был бы гениален программист ему не избежать ни синтаксических, ни логических ошибок. Но! Опытный программист может ограничить их влияние на программу, и не только ускорить процесс отлова ошибки, но и избежать фатальных сбоев. Рассмотрим одну из самых частых и опасных ошибок — «деление на ноль».

draw_text(32, 32, string(2 / (mouse_x - 256));

При mouse_x = 256 произойдёт чудо! Ошибка деления на ноль. В данном случае, мы отдаём на откуп программе ошибку, т.е. отдаём ей права на обработку ошибки. Она справится по своему, со всей ответственностью: закончит сообщением о фатальной ошибке (ну в Game maker можно проигнорировать). Что же может сделать программист для того чтобы программа работала даже при mouse_x = 256? А вот что, обработать ошибку вручную:

if(mouse_x == 256)
draw_text(32, 32, 'Недопустимое значение.');
else
draw_text(32, 32, string(2 / (mouse_x - 256));

Видите как всё просто! Теперь программа будет работать стабильно при любых значениях, а при неправильных значениях нас предупредят что такое значение недопустимо. То есть, что мы делаем? Мы то значение которое может повести себя странно, вылезти за границы и т.д. обрамляем условием и обрабатываем в отдельности. Естественно, не при каждом условий программа будет вести себя гладко, например, если потеряны важные данные, то всё равно придётся аварийно остановить программу:

var file;

if(file_exists('\data\hero.txt'))
file = file_text_open('\data\hero.txt');
else
{
if(debug)
show_message('Файл hero.txt не существует.');

game_end();
}

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

Главное найти ту грань которая определяет, что важно в программе (без чего она не сможет функционировать правильно), а чем можно пожертвовать. Особенно это важно в функциях. Что можно пихать в функцию, а что нет. Важно сунуть функций не только нужный тип данных, но и нужную информацию. У меня был такой случай что программа выходила с фатальной ошибкой. В чём проблема, я не мог понять, ведь данные правильные (как мне казалось) подаются. Функций нужны были строки, вот и я подавал строки (и приходили строки). Но! Приходили строки такие, при обработке которых возникала фатальная ошибка. Её я искал несколько часов.

Проверяйте не только сопоставление типов данных, но и на валидность, правильность. Проверяйте всё. Работает с объектами? Проверяйте существует ли объект с которым вы работаете. Работает с текстом? Проверяйте его на валидность, и вообще, существует ли он. Работаете с данными? То проверяйте существуют ли они, правильны ли они и т.д. Лишняя проверка замедлит код, но упростит дальнейшую его отладку.

Попробуйте правильно обработать ситуацию:

draw_text(32, 32, string(1 - sqrt(128 - mouse_x)));

var file;
file = file_text_open('\data.bin');

grid = ds_grid_create(ceil(random(100)), ceil(random(100)));
draw_text(32, 32, string(ds_grid_get(grid, (mouse_x - 64) div 4, (mouse_y - 64) div 4)));

Придумайте сами, или загляните в свой код.

Описание примера к предыдущему посту

2009-09-11T13:57:00.002+04:00

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

Итак, начинаем обзор. Вспоминаем картиночку из предыдущего поста. Структура исходника примерно схожа с ней. Т.е. начальное состояние "intro", из него мы попадаем в "menu", из меню мы можем попасть в остальные места. Конечное состояние "quit" после которого следует выход из программы. В принципе, это стандартная схема и она используется в 99% игр.

А теперь мы, используя методы ООП, создаём Главный объект oGame. Объект oGame будет иметь доступ в любое место нашей программы (т.с. глобальный объект, синглтон и подобие функций main в одном лице). Это очень важно понять, особенно если вы занимаетесь ООП программированием. У этого объекта будет 3 части, как и у любого другого: Инициализация, Тело и Уничтожение. Запоминаем, 3 части.

Объект oGame обрабатывает все состояния, в нём инициализируется состояние начальным состоянием. Чтобы не корпеть с рисованием, занимаем цикл Draw. В нём делаем свитч на состояния. Опять так же, у каждого состояния 3 части, но не всем они нужны все 3. Здесь выбираем по обстоятельствам.

Главное, нужно запомнить: из каждого состояния должен быть выход, т.е. есть возможность перейти в конечное состояние (иначе программа будет вечной). Также нужно сделать обработчик ошибок (по этому следующий пост), строка default. Если вдруг перешли в несуществующее состояние, чтобы нам сообщили из какого состояния мы перешли, из какого именно места и куда пытались. Также можно сделать безопасный выход, т.е. не выкидывать из программы, а сделать переход в точно существующее состояние.

Теперь мы можем безопасно переходить от состояния к состоянию. Соответственно, разберём нужность 3 частей состояний (а именно 2 из них, инициализации и уничтожения). Входим мы в состояние "menu", нам же нужно меню? Нужно. Делаем его через список или любой другой вариант, но его нужно создать. Также нужно создать начальное положение игры, всё это происходит в инициализации. Но вот такая ситуация, вы хотите выйти из игры в меню, не теряя при этом саму игру, чтобы вернуться обратно. В данной ситуаций, ни инициализация, ни уничтожение не нужна в игре (чтобы при возврате в игру всё оставалось на своих местах). Вот такой момент нужно будет контролировать, когда нужна инициализация, а когда нет (соответственно, когда нужно удалять данные из памяти, а когда нет).

Идём далее. Проблема - пухнущий код. С этой проблемой вы столкнётесь при растущем проекте (уже где-то несколько сот строк кода). Решение позаимствуем у профи: запихиваем похожие по смыслу части кода в функций (в Game Maker - скрипты). Это действительно вам поможет структурировать программу. Всё что связано с вводом данных в input, инициализация и уничтожение, в init и destroy, соответственно и т.д. Хочу заметить, пока кода немного, это кажется детской забавой, но когда его будет очень много (>10000 строк) вот тогда вы действительно оцените по достоинству этот приём. Группировать функций можно по состоянию, если состояние game, то названия всех функций может начинаться с "game_".

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

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

Подведём итог:

Используем общий объект для общего управления.
У кода есть 3 части: инициализация, тело и уничтожение. Используем их по мере надобности.
Если кода слишком много, засуньте его в ... функцию.
Если структура программы слишком сложная, постройте вспомогательное ПО.

Остов игры

2009-09-11T13:56:00.003+04:00

Теперь перейдём к более конкретным действиям по созданию игры. Из поста про Игровой Цикл вы знаете что нужно сделать переходы между состояниями (см. пример Druce). Как вы знаете, этими переходами могут быть: заставка → меню ↔ игра, и другие их комбинаций. Т.е. пока состояние "заставка" мы проигрываем весь код связанный с заставкой, состояние "меню", весь код связанный с меню и т.д. Многие выполняют этот приём неосознанно, но мы сейчас углубимся в этот процесс... Процесс создания Конечного Автомата (сокр. КА).

Хочу сразу сказать, что делать будем недетерминированный КА. Что это такое? Это когда от состояния существует несколько переходов, т.е. например, вы можете выйти из состояния "игра" как в "выход", так и "меню". Что входит в КА? Во-первых состояния. В нашем случае КА будет сам игровой цикл, а его состояния это его части (меню, заставка, игра, игровое меню и т.д.). Ещё есть начальное состояние и конечное. Смотрим:

state = 'intro'; //начальное состояние
game = true;
…
while(game)
switch(state)
{
case 'intro': /*показываем вступление*/; if(вступление_кончилось) state = 'menu'; break;
case 'menu': /*обрабатываем меню*/; if(новая_игра) state = 'game'; break;
case 'game': /*здесь всё что касается игры, внутренний КА, инвентарь и меню*/; if(выход) state = 'quit';break;
case 'quit': /*показываем титры*/ if(титры_кончились) game = false; break; /*конечное состояние*/
default: show_message('Incorrect state. / ' + string(state)); state = 'intro'; break;
}

Несмотря на то что в Game Maker некоторые из этих действий можно реализовать немного другими способами, способ создания Игрового Цикла через КА является главенствующим. Например, состояния могут быть выражены не состояниями в коде, а комнатами. Закончился вступительный ролик, перешли в комнату-меню. Выбрали "Новая игра" перешли в комнату с игрой и т.д. Если проект простой, типа Пак-мана или Тетриса, то такой метод пойдёт, если игра сложнее, жанра РПГ, то метод КА будет предпочтительнее. Главное продумать структуру игры до мельчайших подробностей, иначе можно попасть в такой момент, что добавить или изменить что-то в игре будет невозможно и тогда придётся переделывать, если не весь проект, то большую его часть (у меня уже был такой момент).

Идём далее. Остов игры есть, это наш Игровой Цикл, наш основной КА. Внутри каждого состояния можно вписать любой код, т.е. можно вставить ещё КА, например, по обработке внутренних сообщений в состояний "game". Например, состояние "начало_игры", "инвентарь", "меню" и др. В каждом этом, так скажем, подсостояний игра ведёт себя поразному, хотя и находится в основном состояний "игра".Советы:

Структуру игры надо продумывать с самого начала. Иначе можно попасть в тупик. Прорабатывать структуру вам поможет график (как на рис. выше), т.е. визуальное виденье вашей структуры вам сильно поможет.
Ваши возможности в созданий игры ограничены только вашей фантазией. Вы можете делать со структурой всё что угодно! Вложенный КА только верхушка айсберга. И кстати, технология КА применяется во многих областях, например, в ИИ или в ракетостроений.
Подписывайте ваши состояния. Это чтобы не забыть. В Game Maker есть такая возможность как по-быстрому сравнивать строки, в других языках это несколько осложнено, поэтому составьте таблицу и подпишите, или нарисуйте график КА.

Теперь у вас есть остов, на которой уже можно делать игру, добавлять и редактировать связи. Редактировать и добавлять состояния теперь просто и легко, главное не забыть сделать между ними переходы. Не забываем что в разных состояних мы по разному обрабатываем события. Например, в самой игре мы обрабатываем события клавиатуры так (перемещаем главного героя), а в меню по другому (перемещаемся по пунктам меню). Зная всё это можно делать очень хорошую и крепкую основу. Единственное что ещё надо продумать, сохранение\загрузку данных и перемещение данных из состояния в состояние (переход уровней), т.е. чтобы была готова та часть которая будет отвечать за загрузку данных в данное состояние и перекидывать их в другое.

Не забываем ещё про один пунктик. У состояния есть несколько состояний (пардон за каламбур), а именно: инициализация (подобное Create), тело состояния (подобное Step) и очистка (подобное событию Destroy). Инициализация и очистка, единичные события и вызываются при необходимости, например, повторить состояние или загрузка всех нужных объектов(спрайтов, звуков и др. данных) для игры и последующее их стирание (если вы не подчистите за собою данные, то они будут здесь при следующем заходе в это состояние, т.н. Persistent). Тело состояния работает всегда.

Пример. Хочу отметить что в примере нет цикла while(game). Почему? Да потому что для Game Maker он уже реализован, ввиде блока Step или Draw.

Идеальная РПГ

2009-09-11T13:55:00.002+04:00

Сегодня зашёл разговор об идеальной РПГ. Какая же она должна быть?

У меня в памяти всплыла такая история:

Когда я был маленький, лет 5-6, мне отец предложил поиграть в игральный автомат (это где-то 1991-1992гг.). Игра состояла в том чтобы попасть в кружки на экране, давалось ружье, типа пневматики, прикрученное к автомату и стреляй. Так вот, отец мне помогал держать это ружье, я ж маленький. Я нажимал на какой-то выступ (я незнал что есть курок) и цели начали выбиваться. Но я чувствую что когда я нажимаю ничего происходит. Оказывается, и целился, и стрелял отец, а я как зритель (и вроде как игрок).

Вот такая же сейчас история с РПГ. Вы вроде нажимаете, а ничего не происходит. Игра как бы живёт по своим правилам, без вашего участия. Обратимся к Wiki \ Ролевая игра:
"Ролевая игра — (англ. Role-playing game - RPG) — игра развлекательного назначения, вид драматического действия, участники которого действуют в рамках выбранных ими ролей, руководствуясь характером своей роли и внутренней логикой среды действия вместе создают или следуют уже созданному сюжету. Действия участников игры считаются успешными или нет в соответствии с принятыми правилами. Игроки могут свободно импровизировать в рамках выбранных правил, определяя направление и исход игры."
Как видно, по определению можно, и даже нужно, влиять на ход игры. Когда вы в последний раз влияли на ход игры? Думаю что это было редко, а некоторых играх, случайностью. Давайте посмотрим на схему событий:

Вы видите примерную структуру 3 игр. Под одним шариком имеется в виду одно поворотное событие в сюжете, в игре. Gothic 2, The Fable и обычной текстовой игры. У Gothic 2 есть три концовки, одна из которых заканчивается досрочно (за наёмника, вроде). У Fable структура погуще, вы можете отыграть роль хорошего/плохого плюс детство, молодость, старость, но не намного. Структура этих двух игр меркнет посравнению с обычной текстовой игрой (за образец я возьму текстовые игры из Космических Ренджеров 2. Текстовые игры - сокращённо ТИ). В ТИ ходы могут быть любыми, и вперёд по течению, и назад, и в бок, т.е. развитие гораздо сложнее и интереснее. В Gothic 2 и Fable переход между основными состояниями "разбавлен" квестами, боёвкой и беготнёй. И что у нас получилось? Бодяга. Я скептик по сюжетам (об этом знают на форуме), но ТИ действительно заставляют вникать в сюжет и в игру, не потому что заставляют, а потому что действительно интересно. Из этого мира даже уходить не хочется. Он действительно подвластен игроку, он действительно живёт, отыгрывает роль. А что мы видим в обычных РПГ? В начале рассказывают интересную историю. Потом мы бегаем, прокачиваемся, выполняем ненужные квесты в стиле принеси это, замочи того. Ради чего? Ради того чтобы получить новый виток глобального развития. В ТИ этого нет, т.е. каждое событие идёт одно за другим, вы не отвлекаетесь от основного действия. Никогда. В обычных РПГ обычно так набегаешься, и так напрокачиваешься, что напрочь забываешь про что игра-то была. Вот посчитайте, сколько времени вы тратите на беготню за всю игру, а сколько на бои. И вы увидите, что на основную ветку тратится очень мало времени, ну вы это можете увидеть на картинке. Кружков мало, а игру надо расстянуть на сутки.

Вот именно поэтому меня бесят хвалённые РПГ, и так приглянулись ТИ. Хочу заметить что я раньше очень скептически относился к ним, но сейчас отношения поменялись, потому что я увидел на что они способны. Хочу заметить, ТИ в КР 2 придаточное явление, т.е. что-то вроде мини-игр (на них уходит не более 2 часов, а некоторые, вообще по 15 минут), следовательно не развиты. А теперь представьте что вся игра это огромная ТИ. Это будет такое явление за которым интересно следить и ещё интереснее потому что можно влиять. Каждое ваше действие будет уникальным.

Именно о такой Fable со структурой ТИ мечтал Питер Муленье, но даже ему не хватило сил, времени и средств (а у него всё было). Так что хорошенько призадумайтесь о созданий РПГ, а по силам ли вам? Если нет, то вам на выход.

Вы можете ознакомиться с ТИ для их изучения. Они вам помогут в развитий вашего проекта, т.к. по сути являются концентрированными РПГ. Посмотрите их структуру, она намного сложнее чем в обычной компьютерной РПГ. Придумайте переходы между основными поворотами сюжета. Какие сейчас переходы? Качь и количество выполненых квестов. Не густо? Придумайте что-нибудь другое. Сюжет... С сюжетом вы разберётесь сами, т.к. это основа игры. Чем разветвлёнее и дольше он будет, тем интереснее. И не забывайте, игрок влияет на ход игры, а не игра на игрока. Это главное правило.

Смысл программирования

2009-09-11T13:54:00.001+04:00

Многие его не понимают. Они думают, что написав несколько строк на С++, Pascal, Basic, это уже программирование. Но к сожалению, это только пол дела (если не меньше). Из за этого возникает множество проблем у вновь прибывших. Множество проблем логических. Как будто мозг отключили. Ещё есть интересный парадокс: люди не знают английского языка (т.е. языка на котором работают 99% языков программирования) и других тоже, но от языка программирования на русском разбегаются во все стороны. Главное чтоб на модном иностранном языке, а не на своём. В том числе и этот парадокс сильно мешает.

Думайте на том языке, на котором говорите. Думайте на родном языке.

Чтобы хорошо программировать, нужно хорошо мыслить логически на своём родном языке. А потом уже переводить на язык программирования. Многие этого не понимают и гуляют в строках кода как ёжик в тумане. Вот некоторые задают вопрос в котором уже есть ответ! Ну странно...

Вопрос:
"А как мне сделать то-то, если это?"

Вместо "то-то" и "это" подставьте что-нибудь своё. Вот как такому человеку помочь, а? Надо было всего лишь поменять местами части предложения и перевест на английский. Всё!

Ответ:
если(это) то
сделать то-то.

что на GML будет(т.е. переводим на англ. и соответствуем всем правилам языка):

if(это)
сделать то-то;

Логический код, который показывает как надо написать, но не пишеться точь в точь в соответствий с правилами, называется псевдокодом. Пример был выше, ответ на русском языке, или вот ещё:

цикл(пройтись по всем образцам)
{
обр = возратить текущий образец();
если(объектом образца(обр) является (враг)) то
рисуем на карте красным;
}

Это образец псевдокода. Иногда, при переводе на англ., т.е. на язык программирования, вы обнаружете что некоторых данных не хватает. Например:

рисуем на карте красным;

А что есть карта? И где она находится? Что рисуем? Это уже логическая ошибка, здесь точнее - недоработка. Решение её лежит на плечах программиста, т.е. спрашивать решение у других бесмысленно. А они-то откуда знают где у вас карта находится, или что вы там собираетесь рисовать??? Вот вроде бы, вопросы глупые, а совершают их очень многие. Решение данного вопроса будет в уточнений всех нужных данных:

рисуем красную окружность с радиусом 3 в точке (32; 64);

переводим в GML:

draw_circle_color(32, 64, 3, c_red, c_red, true);

Всё просто! Если вы не можете сходу написать код, не надо. Пишите по-русский, не стебайтесь своего родного языка. А потом переведёте его (и не надо звать других программистов! Перевод дело переводчиков, а лучше возьмите словарик и переводите. Там немного слов, около 100 вам хватит за глаза).

Ну а если не думает даже на родном, то вам не стоит соваться в данную область, она не для вас.

Внешность и душа

2009-09-11T13:53:00.001+04:00

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

А потому что основной механизм движение кузова - двигатель, а кузов нужен для "красоты". Порядок сборки автомобиля: сначало шасси, на него двигатель и потом кузов (оставим остальные утилитарные вещи типа подстаканников и сидений). Шасси это основная крепёжная система, как фундамент. Двигатель приводит в действие всю систему. Кузов улучшает аэродинамические условия и делает готовую машину красивой. Заметьте, что единственное что можно выкинуть из этой системы это кузов. Без всего остального машина не поедет.

Вот также и в играх. У многих нет опыта и первое что они хотят сделать это кузов, в надежде что он поедет, забывая, что нужно ещё и шасси, и двигатель. В роли двигателя у нас "Игровой цикл". В роли шасси - интерфейс к графическому, пользовательскому интерфейсу. И вот уже последнее - графика. Если вы идёт в обратном порядке, вы не геймдевелопер. Вот хорошие примеры: крестики/нолики, тетрис. Это такие игры, графика в которых минимальна. Попробуйте их создать и вы увидите всю поднаготную создания игр. Это вам не ТДС, с арканойдом создавать. Даже с такими маленькими играми, скорее всего, возникнуть неразрешимые трудности. А если вас пересадить на С++? Вообще в калошу сядете. Ещё можете попробовать более сложные варианты: шашки, шахматы. Поэтому перед созданием игр, хорошенько подумайте, обдумайте, продумайте.

Интерфейс (шасси) -> Игровой цикл (двигатель) -> Графика (кузов)

Именно в таком порядке. Про игровой цикл я уже рассказал здесь. Про интерфейс вы можете прочитать в статье "Азбука геймдизайнера" здесь. Там есть всё, чтобы узнать как строиться программа, в нашем случае, игра.

Прикладные программы

2009-09-11T13:52:00.001+04:00

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

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

Одним из таких видов этого ПО являются редактор уровней. Знакомо? Но оно им не ограничивается. Есть редакторы юнитов, тайлов, частиц, диалогов и др. Все эти инструменты помогают: ускорить и упростить работу.

Первое что надо понять, это то что сама игра и его дополнительное ПО(типа редакторов) - совершенно независимы. Они не влияют друг на друга. Никак. Но! У них есть общая точка соприкосновения, которую вам необходимо сделать. Эта точка является, какой-либо внешний файл. Давайте разберём на примере редактора юнитов.

Что у нас есть? У нас есть игра с кучей юнитов. Чего у нас нет? Программы для работы с этой кучей. Делаем редактор, главное удобный интерфейс для рабочего. т.е. программу которая нам предоставляет возможности по изменению параметров юнитов, их внешнего облика и других нужных вам параметров. Когда такая программа будет готова, нужно будет сделать "точку соприкосновения", т.е. переход от редактора к игре. В этом вам поможет раздел про интерфейсы в статье "Азбука Геймдизайнера". Эта "точка" будет файл с общим алгоритмом сохранения\загрузки, как для редактора, так и для игры. Смотрите:

Делаем юнита в редакторе (слева): Атака = 10, Защита = 4, Скорость = 5, выбираем спрайт и способность. Сохраняем. Стрелочка между игрой и редактором - переходник, точка соприкосновения, интерфейс, в данном случае, файл. В файле хранится следующая информация: первый байт - номер спрайта, второй, третий, четвёртый байты атака, защита, скорость и последний байт способность. Над стрелочкой показано в каком порядке сохранён файл. Загрузка в редакторе и в игре идентичны. Идём в том же порядке: спрайт, атака, защита, скорость, способность. Единственное в чём они различаются это в использований информаций: в редакторе все данные записываются в текстовые боксы для редактирования, а в игре создаётся объект(юнит) с данными параметрами. Это единственное и глобальное отличие.

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

Сейчас поговорим о тех параметрах которые не укладываются в простые числа, как записать спрайт? или сложную способность? Здесь будут подводные камни и вам придётся хорошенько продумать всё. Сохранить спрайт можно несколькими способами. Например, сохранить весь спрайт в этом файле. Объём файла увеличиться намного, да и доступ к спрайту извне будет осложнён, зато вы его не потеряете. А можно сохранить только ссылку в том или ином виде. Ссылку на файл, вы тратите несколько байт на строку такого вида: data\sprite.png . Т.е. вы указываете где находится сам файл. Ссылка должна быть локальной, чтобы переместив игру, ссылка осталась рабочей. Минус - файла может не оказаться. Есть ссылка в другом виде, допустим у вас есть некое хранилище спрайтов в игре, тогда вы оставляете в файле номер спрайта в этом хранилище(как и сделано в примере на картинке, наш спрайт находится в хранилище под номером 1).

Со способностью можно сделать также как в последнем примере со спрайтом, т.е. сделать ссылку в хранилище(на рисунке, номер способности 2). В созданий объекта(юнита) проверяете загрузку той или иной способности. Есть такая способность? Если да, то открываем её, если нет, то нет. А если есть способность, а у ней ещё параметры, то применяем их. Способ хранения сложных переменных смотрите на форуме.

Смысл в том, что надо преобразовать в число, так или иначе. Если вы забываете под каким числом что храниться, то записывайте:

1) Регенерация.
2) Невидимость.
3) Летающий.
4) ...

т.е. вы преобразуете что-то(допустим текст способности) в число в файле, а в игре преобразовыаете обратно (в текст). Кодируете(в файл, наружу), декодируете(из файла, внутрь).

И последнее что я хочу затронуть это изменение файла(интерфейса). Вещь не однозначная, но порою необходимая. Здесь вам поможет пост о версий файла. Старайтесь продумать структуру полностью изначально, это поможет вам избежать изменений в дальнейшем. Но если всё же есть необходимость дорабатывать интерфейс, то готовьтесь к несовместимости с предыдущими версиями файла (подробнее в "Азбуке Геймдизайнера").

Кстати, это хороший пример! Допустим вы поменяли структуру файла, но не критически, т.е. совместимо. Файлов целая куча, вручную слишком долго. Тогда проще написать программу, которая ищет файл в директорий и поддиректорий и пересохраняет в новую версию, если версия файла старая. Это пример прикладного ПО без участия рабочего, запустил и программа сама всё сделает. Быстро и удобно.

P.S.: Хочу объяснить почему именно файл выбран в виде общего интерфейса. В Game Maker нет иного интерфейса передачи информаций, кроме файла. В принципе, этот вид интерфейса должна предоставить Ось, что она и делает в виде интерфейса OLE, через который вы можете передавать информацию прямо налету, но я ею пользоваться не умею, поэтому вам придётся самим извчать этот способ передачи информаций. Вполне возможно, что есть и другие способы передачи информаций на лету кроме OLE. Ищите, если нужно. Но это уже будет через более совершенные языки программирования типа Delphi, а лучше C++.

Единый контроль

2009-09-11T13:51:00.001+04:00

У одного(а наверняка и не одного) была такая проблема: создал объект(допустим игрок) во встроенном редакторе, в этом объекте были данные, которые брались следующими объектами. Затем "игрока" удалили и вновь создали. Процесс создания объектов в игре соответствует созданию объектов в редакторе. т.е. объекты обращались к несуществующему ещё "игроку". И получилось, что приходится вновь переделывать уровень ради того чтобы работало. Вот такая проблема, проблема порядка создания объектов. В Game Maker сообществе нашли решение и даже назвали его - контроллер. Профи называют объект такого класса - Синглтон.

т.е. объект класса в единственном экземпляре. На языке Game Maker это значит - образец объекта в единственном экземпляре. Что даёт нам такой объект? Он даёт нам централизованный контроль над <чем-то>(обычно какой-то частью программы, но может и всей программой). Этот объект может недопустить создание дубликатов, некорретную работу и т.д. Так же в синглтоне можно задать порядок создания. Минус этого объекта, что это внешнее управление проектом, т.е. внутренний редактор уже отпадает, вы не сможете создавать объекты визуализированно, только создав свой редактор.
При созданий этого объекта, у вас появляется централизованная(чёткая и вертикальная) власть. Она и так была, но теперь это сделано в явном виде. В этом объекте можно сделать игровой цикл, а возможно игровой цикл будете делать через внутренний объект(чтобы, например, сделать несколько геймплеев в нескольких объектах). Иерархию связей вы продумываете сами. Главное: объект(образец) класса(объекта) должен быть в единственном экземпляре. Его вы размещаете во встроенном редакторе. В созданий синглотона вы прописываете все нужные вам действия, например:

////
keys = instance_create(-1, -1, oKeyboard); //здесь управление клавиатурой
mouse = instance_create(-1, -1, oMouse); //здесь управление мышкой

pause = false; //переменная паузы

gameplay = instance_create(-1, -1, oGameplay); //здесь игровой цикл
LoadLevel(gameplay.status); //Загружаем комнату соответственно с геймплеем
////

Если объект oMouse должен стоять перед oKeyboard, т.к. берёт данные оттуда, то это не трудно сделать.

Абсолютно все объекты должны создаваться в синглтоне. Как бы быть под его началом. Синглтон как босс, остальные его подчинённые. Иерархия может быть настолько сложной, насколько это понадобится.

Плюсы:
+Правильно раставленные приоритеты.
+Явный контроль.
+Чётко отлаженная работа.

Минусы:
-Встроенный редактор вам уже не поможет.

Каталогизация объектов

2009-09-11T13:49:00.001+04:00

При созданий множества объектов(в Game Maker они называются образцы) встаёт вопрос об их обращений друг к другу. В Game Maker этот вопрос частично решён(через номера. От 100 000 и далее), в каких-то системах этого нет. Так как же решить этот вопрос? Через каталогизацию объектов.

Вы создаёте список с которым будете работать. Эти списки будут служить как каталоги. Общий(корневой) список - для всех объектов, обычный список(он же вложенный) - для части объектов. Вот в Game Maker есть один корневой список, в нём расположены объекты(образцы) по возрастающей с номерами от 100 000 и далее. Так же есть по списку на каждый тип объекта(один на спрайты, на объекты, на частицы, даже, на списки, и т.д.). Расположены они также по возрастающей, но на этот раз, начиная от 0.

a = ds_list_create(); //в a хранится 0.

Сначала пройдёмся по вопросу: "А почему их хранят в каких-то списках?". Да чтобы не потерять. В реальном языке при созданий объекта вы должны его куда-то поместить. Если это один объект, то в переменную, а если несколько, то в список. Если вы не поместите объект при созданий, то потеряете объект и память под этот объект, до конца программы (это называется утечка памяти). И хотя Game Maker уже предоставляет вам эти инструменты, их может оказаться не достаточно для вас. Например, как выделить из всех объектов-образцов нужную группу нам? Некоторые из вам предложат пройти весь список из всех объектов-образцов и проверить их хотя бы по одному из условий(принадлежность к определённому объекту или содержащие определённую переменную, например). Можно! Можно сделать и так. Но сколько времени уйдёт на это? Проверка всего списка(а сколько у нас объектов-образцов? 1000!? О господи!), проверка на условие и т.д. А если это ещё делать каждый шаг программы... Ммм...
Со списком же все эти задачи отпадают. Просто внести в список эти объекты-образцы и пройти их. Без всяких проверок. Но у вас появляется плюс. Возможность контроллировать этот список(список Game Maker вы не можете трогать). Зачем? Это уже вопрос другой. Появляется гибкость. Нужна ли она вам? Решение оставляю на ваши плечи.
Вы можете создавать разные списки, с разным содержанием. Например, список танков или самолётов, контроллеров, юнитов, монстров, объектов ландшафта, выделенных объектов, вражеских юнитов и др. Список юнитов является вложенным в отношений ко всем объектам-образцам, а список вражеских юнитов для определённого объекта-образца является вложенным списком в отношений списка всех юнитов. Вы всегда можете с лёгкостью найти нужную вам группу. т.е. теперь вы работаете не со всем списком, а только той частью, которая вам нужна. Отсекаете лишнее. Отсекаете?

Визуализация игровых значений

2009-09-11T13:48:00.002+04:00

В Game Maker есть режим отладки, но не очень показателен. Цифры это конечно хорошо, но иногда они не достаточно понятны. И здесь выручает след. инструмент - визуализация игровых значений.

Смотрите:

Слева скриншот для игроков, справа для разработчиков. И конечно, он нагромождён, по нему можно узнать множество параметров (и поэтому режим отладки тормозит, потому что в нём работает множество параметров для разработчика). Очень наглядно и понятно. Заметьте, данные можно(и нужно) отображать не только с помощью текста, но и графики. Используйте встроенные функций рисования примитивов, сделайте красивую графику визуализаций значение, это очень поможет при отладке. На скриншоте плохо видно, но присмотревшись, вы можете заметить полупрозрачную сетку(это сетка А*, смотреть какие клетки непроходимые). Полупрозрачность помогает смотреть сквозь сетку. Режим отладки лучше сделать выключаемым в процессе игры:

if(debug)
{
//здесь рисуем нашу информацию
...
}

debug - переключается(debug = !debug;) посредством клавиши (выберите удобную, у меня "D").
Также, вы можете сделать информацию раздельной, если её очень много или она накладывается друг на друга, с помощью переключателя.

switch(debug)
{
case 0: /*здесь рисуем одну нашу информацию; ... */ break;
case 1: /*здесь рисуем другую информацию; ... */ break;
case 2: /*здесь рисуем третью информацию; ... */ break;
...
case n: /*здесь рисуем последнюю нашу информацию; ... */ break;
default: show_message('Такого значения debug не может быть.'); debug = 0; break;
}

debug - последовательно увеличиваем/уменьшаем при этом зацикливая его, не забывая, что залазить за границы не хорошо.

Теперь вы знаете как отображать, осталось узнать что можно отображать. А отображать можно всё что угодно, всё что вам нужно. Мерять скорость, показывать место игрока в которым он будет через n шагов, угол обзора, скрытые места, что думает ИИ и куда, что сейчас будет, какое событие, когда, какое, зачем, почему и т.д. Любую переменную которая вам расскажет о том или ином моменте игры.

P.S.: Был совет профессионала, что надо не только отобразить информацию, но и отобразить её правильно (т.е. чтобы понять её с пол пинка). Понять линию от А до Б определённого цвета можно проще и быстрее, чем текст «Бот идёт от А до Б».

Игровой цикл - Теоретическая часть

2009-09-11T13:43:00.006+04:00

Что же это такое и с чем его едят? Если вы когда нибудь программировали на серьёзном языке(типа с++, паскале или бейсике, например) и хотели сделать какую-нибудь игру, то знаете как не просто это сделать. Почему? Да потому что нет нужных инструментов для этого. Возможно вы даже нарыли какой-нибудь графический движок(не важно 2д или 3д), но игры как не было так и нет. Это всё потому что игра(как программа) нуждается в собственной архитектуре, коде. Настоящая игра-программа начинается с инициализаций всех вспомогательных инструментов(графика, сеть, звук и др. нужные вещи). Затем программа входит в бесконечный цикл, разорвать который может специальное событие задаваемое программистом (это может быть кнопка эскейп, а может выход в меню). Вот этот кусок кода называют — игровой цикл. (Продолжение темы)

Здесь хочу заметить, что в готовых системах разработки игр (типа Game Maker) уже есть не только графический движок, но и звуковой, сетевой, игровой и даже игровой цикл. Они могут быть не очень развиты, но они уже есть. Всё что вы можете сделать в таких системах, это развить их настолько, насколько можно.

Именно здесь начинается процесс создания игры, а не с рисования спрайтов или вывода звука. Для его создания нужно знать, а что же такое игра? Вот что говорит Wiki:

"Игра — вид деятельности, направленной на удовлетворение потребностей в развлечении, удовольствии, снятия напряжения, а также на развитие определенных навыков и умений."

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

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

Инструменты подобраны? Продвигаемся далее, в цикл. Теперь вам надо указать программе, где будет вход\выход и основные переходы в цикле. Т.е. с точки зрения программиста, программа выполняет весь код в цикле, а вам как геймдизайнеру, надо указать какую часть вы хотите выполнять. Продемонстрирую это на иллюстраций:

Большой квадрат — игровой цикл. Он постоянно повторяется, в Game Maker он повторяется каждый step, а вообще он повторяется с такой частотой насколько позволяет вычислительная мощность вашего компьютера. Поэтому очень важно синхронизировать игру и игровой цикл, чтобы всё было плавно, но не быстро (но это выходит за рамки данного поста). У него есть вход и выход. Перед входом обычно инициализируют все нужные системы(как было сказано в начале поста) и после этого входят в цикл. После выхода из цикла, очищаем память, выключаем все системы (это надо сделать даже в Game Maker, не говоря уж о чём-то серьёзном). Так-с, сейчас нам интересно устройство большого белого квадрата. В нём маленькие кубики - это куски кода отвечающие за ту или иную деятельность. Заштрихованные куски не выполняются в данный момент (т.е. начальное меню не работает, когда мы в игре и это правильно). Но можно сделать, чтобы какие-то куски работали вместе с другими (например, уровень работает, пока включён инвентарь). Здесь вы уже смотрите, какая часть вам нужна в данный момент, а какую надо выключить. На уровне работает объект "персонаж". Как это будет реализовываться уже зависит от вас и от ваших инструментов(т.е. будет ли это C++ или GML). Как правило, это делают через объекты и через операторы условия(if или switch).

Хочу ещё заметить, что игровой цикл это часть игры (в ней не хватает правил, наполнения и баланса). Это фундамент и он первичен. Сами понимаете, что на фундамент поставить стены проще, чем подложить фундамент под стены, так? После того как фундамент готов, вы приступаете к "стенам",т.е. объектам отвечающим за саму игру, за правила игры.

Те люди которые кроме Game Maker ничего не видели, прошу посмотреть на пример Druce. Он написал игровую программу игровым циклом так, как она бывает во "взрослых" языках. Это хороший пример, который заставит вас переосмыслить и понять структуру настоящей игры (хотя всё же с готовыми примесями). Что ещё хотелось бы добавить, это то что несмотря на то что структура кода кажется большой и сложной, это не так. В связке HGE + C++ вам придётся написать в 10 раз больше чтобы добится приблизительно такого же результата. Подумайте, осмыслите какой хороший инструмент Game Maker (несмотря на тормоза) и решите, а нужно ли вам создание игр.

Plants vs Zombies

2009-09-11T13:40:00.002+04:00

Итак, сегодня установил игру Plants vs Zombies (86/100 по версий AG). В двух словах: казуалка красивая. Простенькая, но очень интересная игра. "Стратегия класса Tower Defense". Рецензию игрока вы можете прочитать на AG, а я напишу рецензию геймдизайнера.

То что меня подвигло написать данную рецензию - это простота игры. Никаких А*, огромных комнат, сложных алгоритмов, огромных количеств объектов и т.д. Ничего того что делают новички. И? 86/100. Неплохо? Сделать такую игру мог любой начинающий, а она обогнала даже GTA IV с The Sims 3 (Ну и смотрите все игры с рейтингом >80). И какой вывод?

>>Чтобы сделать хорошую игру не нужно миллионого бюджета, тысячи профессионалов сотрудников и гениальных алгоритмов<<
Каждый новичок это хочет опровергнуть, ну и зря. Флаг им в руки.

**А здесь маленькая приписка: The Sims 3 и GTA IV - бизнес, а не игры. Поэтому правила хорошей игры(товара) не работают.**

**Вторая приписка: я не до конца прошёл, и поэтому знаю про игру немного, но достаточно для основы, которую можно развивать.**

Итак, игра выполняет все условия хорошего интерфейса: подсветка, подсказка, обратная связь (это можете прочитать у меня в азбуке геймдизайна). Далее, игра. Основная тема: защита дома от зомби. т.е. враги зомби(с точки зрения профессионала, какие именно - не важно), основная роль которых - дойти до дома. И есть огород (дискретный 5х9), который можно засадить "защищающими" растениями (набор которых нам тоже не важен, кроме главного условия: хотя бы одно растение должно "убивать" зомби).
Растения не бесплатны, их можно "покупать" в обмен на ресурс (солнце). При успешной покупке, растение нужно посадить на одной из 45 клетки(здесь действует привязка, т.е. посадить растение можно только в одной из клетки и только по середине). После этого растение успешно функционирует. Ресурс солнце можно "ловить", как с неба, так и с растения "подсолнух". Ловить его можно с помощью ЛКМ (каждый начинающий это свободно может сделать).
Зомби появляется справа (за экраном) и идёт влево(к дому). Он может идти по одной из 5 горизонтальных грядок. В начале игры, игроку даётся фора (какое-то время зомби не нападают). После этого атакуют зомби(при этом, внизу отображается шкала "пройденности" уровня). В конце даётся последний, мощный "залп" зомбей. Цель зомби: зайти в дом. Если зомби встаёт на клетку с растением, то пожирает его.
Здесь набор монстров\растений(играйте в игру или пробуйте придумать своих). Его можно расширять сколь угодно много. От этого геймплей будет только шире.

Какой минимум нужен для создания игры? 1 объект зомби, который идёт влево и жрёт растения на клетке на которой он находится. Панель инструментов на несколько растений. Один контроллер для управления игровым циклом(создание монстров, определение условий победы\поражения, переход в меню). Один объект под растения. Один под ресурс. Усё.

P.S.: Мне понравилась идея с карточными играми. Потому что в них отброшено всё лишнее. Только геймплей (ну карточки только нарисовать. C этим не обязательно карпеть, даже с наспех нарисоваными картами игра хуже не становится, наоборот приобретает уникальный стиль(если он есть)). Почему-то новички этого не видят, зачем коптить над А*, если его никто не оценит, кроме программистов?

Совместимость с предыдущими версиями файла

2009-09-11T13:39:00.002+04:00

Одной из фишек подсмотренной у профи было: версия файла.

Мелочь, но поможет вам выстроить какую-никакую совместимость. Смысл в том, чтобы оставить в сигнатуре файла его версию. Это позволит использовать скрипты загрузки соответственно с версией файла. Допустим, версия файла 1.2, тогда вы выбираете скрипт load_file_1_2, а для версий файла 1.1, выбираете load_file_1_1. Номер версий лучше использовать целочисленное не менее 2 байт(т.е. 65535), вам хватит за глаза. Реализовать такую систему просто - через switch.

switch(version_file())
{
case 1: load_file_1(); break;
case 2: load_file_2(); break;
default: show_message('Ошибка. Неправильная версия.'); break;
}

Естественно, абсолютную совместимость вам не видать, но сделать программу намного стабильнее, возможно. Если вы читали "Азбуку геймдизайна" и помните часть про разъёмы, то вы поймёте как улучшить совместимость. Например, если в программе появилось важное, новое значение, а в файле его нет, то единственный вариант, сделать заглушку(если значения нет, то возвращается число заданное программистом). Сами понимаете, что при таком раскладе результат может быть непредсказуемый, но может всё пройти более ли менее гладко. Если в программе убралось значение, которое есть в файле, то здесь это значение читается из файла и сразу же выкидывается(т.е. пропускается). Этот вариант проще, ошибок никаких не должно быть.

Конечно, если у вас версий будет много, придётся делать много переходных функций. Если файл версий 1.1 загрузился в программе 1.2, то не факт, что он загрузиться в 1.3. Здесь уже, как говорится, везение и гемор на совести программиста.

Таким образом, что мы имеем? Мы имеем неплохую систему совместимости. Например, у вас есть огромная карта сделанная в редакторе для игры версий 1.0, потрачено много сил и времени. Но вот вы добавили кучу фичей в игру(версия 1.2) и, соответственно, скрипт загрузки карты изменился, но за счёт умнопродуманной системы совместимости, вам не надо переделывать карту с нуля, достаточно пересохранить в новый формат(что и предлагают вам многие современные программы, видя старый формат файла).

2009-09-07T17:38:00.002+04:00

Вопрос Aimar'а: "имеем в изометрии объект, движущийся в любом направлении. Игру фоткать не хочу, на картинке вроде по блокам и границе ясно, какова изометрия. Проблема с реализацией зависимости скорости от направления: одинаковая скороть смотрится не очень реалистично; функцию пока не подобрал оптимальную; можно, в принципе, интервалам значения давать. В любом случае скорости нужно сравнивать, какая самая большая должна быть? Самая маленькая? Зависимость нужна, в общем."

Вопрос очень интересный, тем более, что он часто встречается в программирований и ещё чаще в математике. Зависимость, автор вопроса, уже знает - direction. А вот функцию он не придумал и в этом его ошибка. Какие могут быть функций? И тут самое интересное, да какие угодно! В данном случае, его интересует приплюснутый по вертикали эллипс, т.е. вверх и вниз медленне, а вправо и влево быстрее. Вертикальные значения direction? 90 и 270. А боковые? 0 и 180. В данном случае, функия (abs(cos(direction)) + 1) подходит больше всего. Влево(abs(cos(180)) + 1) и вправо(abs(cos(0)) + 1): = 2 . А вверх и вниз: = 1. т.е. если перс идёт вправо или влево, то скорость в 2 раза выше, а если вверх или вниз, то обычной. Причём, значение скорости будет плавно меняться. Вот вам графическое оформление:

Как вы знаете из школьного курса, горизонтальная координата - абсцисса - независимая координата, а ордината - вертикальная координата - зависимая. А что у нас зависит? Скорость (speed). Поэтому ложим её на ординату, а на абсциссу - направление(direction). Что значит зависимая? Это значит, какое будет направление, такая и будет скорость, но не наоборот. На картинке вы видите саму функцию, в виде 2 горок. При направление направо(direction = 0), скорость = 1, вверх (direction = 90) - скорость = 2 и т.д. Вы можете подставить в уравнение функций (abs(cos(direction)) + 1) и узнать значение скорости от направления. Заметьте, что функция цикличная и симметричная (это говорит о том что, если direction вырвется за пределы (0-360), то ничего страшного не случиться, а это очень важно). Графически эту функцию можно получить по правилам переноса(или проще, через специальную программу по построению графиков).

А конечный код будет выглядеть так:
speed = _speed * (abs(cos(direction)) + 1);
где - _speed коэффициент скорости(т.е. _speed = 3; или другому числу).
Можно преобразовать эту функцию(раскрыть скобки), возможно повлияет на производительность игры, читабельность кода:
speed = _speed + abs(cos(direction)) * _speed;

Результирующую скорость (speed) можно подправить в соответствий с вашими реалиями(запросами баланса, удобство визуальной части) просто умножив на число(оно должно быть около 1, может быть 0.8 или 1.2, это так, замер на глазок).

Как узнать какие есть функций? Это я отсылаю вас к математикам. Но есть стандартный набор который вы должны были узнать, это:
Cos(), Sin(), Tg(), обратные их варианты, log() и его варианты, abs() - модуль(симметрия относительно ординаты), округление (лесенка), корень от числа, степень, 1/x (обратная зависимость), x (прямая зависимость) и многие другие. Их графические варианты должны были показать вам, а свойства рассказать.

Функций очень важны, они играют большую роль. Им есть разные применения, вот у меня в Space Freedom, скорость корабля зависима от расстояния до цели. Вот так это происходит у меня:
speed += speed_acc * min(max(0, point_distance(x, y, vFinishDot.x, vFinishDot.y) / (max(1, speed * 4) * room_speed)) , 1);

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

Начало мачал

2009-07-23T22:59:00.000+04:00

Тест. Проверка, проверка... Лопух не догадался? (с) Разработка игр