Математическое руководство по созданию компьютерных игр. 3-я редакция. (3 стр)

Ajshma
> Тоже в шоке )

Прив, Андрюх :) Я считаю, клевый док. Если брать "от противного" -- отличное руководство :D

Rai
> то некоторые начинают писать различные многостраничные руководства, вроде как
> являющиеся аргументом в спорах
С использованием материалов:
«Компьютерные игры. Мимо вечности в забвение.» ― А.
С. Патрашов. 2009.
«О, рандом! Или мракобесию от программирования по-
свящается.» ― А. С. Патрашов. 2010.
«USB-flash или маленький конец большого пиратства» ―
А. С. Патрашов. 2010.
«Последний день пирата, или интернета, интернета…» ―
А. С. Патрашов. 2010.

Тут уже на лениздат многотомный тянет )))
Названия ваще вставляют - тут психиатра давно пора звать )

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

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

В целом разрабатывать игры "от сюжета" - ошибочно, потому что игры надо разрабатывать от возможностей реализаторов. Как бы Вы ни старались, в одиночку игру уровня Fallout 3 Вам не сделать даже за ближайшие 10 лет.
Так же цена и ценность проекта, сильно определяется командой - сильная и способная команда, куда ценнее, миллионов долларов финансирования.

Враждебные персонажи или птичку жалко
Внешний вид персонажа или по одёжке встречают
Единицы измерения расстояний или необъятные просторы
Попросту неуместные для "краткого руководства" главы.
Кроме этого, некоторые места противоречат даже элементарной логике. Например измерение пространства - временем:
"Ранее мы приняли, что расстояния в игре измеряются секундами, минутами или часами. Точно так же площадь игрового мира измеряется в часах или квадратных часах или минутах и квадратных минутах."
Читаю последнюю упомянутую главу дальше.

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

Rai
> Итак, всего две компании в мире могут разрабатывать игры по модели Awasaky и считаться крупными.
Подождите, тут какое-то непонимание возникло. Я утверждал, что модель Awasaky как раз предназначена для мелких компаний, а не крупных. А для крупных то, что написано у меня.
Rai
> Что мы делаем неправильно?
Значит у вас подобрался правильный коллектив. Кстати, я не претендую на единственно верное решение, которых может быть несколько. К тому же я брал простейшую схему по образцу разработки проектов и прикладного ПО, которой пользовались мы.
Rai
> Вы бы, Алексей, не занимались рукоблудием с клавиатурой, а разрабатывали игры, что ли... Желательно -- в составе сложившейся команды. Тогда вы бы поняли, какую сказочную ахинею накатали, и вот не лень же было...
Если дочитаете до самого конца, то увидите пять примеров концептов игр, но делать мне их не с кем. В команду пока просочиться не удалось. Я не программист, а расчётчик программист, а отрасль мою недавно развалили окончательно. А что касается ахинеи, то если бы вы видели, что нам часто присылают из очень корпоративных организаций (5000 только в одном целевом подразделении работают) в техническом задании, то обнаружили бы, что по сравнению с их руководящими требованиями моя писанина разумна как энциклопедия.
Ajshma
> Если дело до этого дойдет, я вас лично на костер потащу за ересь. )))
А вот Касихин руководство написал! правда его матюкали чуть меньше моего.
Вот почему руководства есть почти на все случаи жизни: расчёт редукторов, металлоконструкций, игры на гитаре, закладке фундаментов и всё, что угодно, кроме игр? Единственное, что я нашёл у нас это Касихин и его труд. Чем создание игр провинилось перед прочими областями? Раньше хоть поиграть было во что, а теперь и эта отрасль развалилась.

Алексей Патрашов
> Подождите, тут какое-то непонимание возникло. Я утверждал, что модель Awasaky
> как раз предназначена для мелких компаний, а не крупных. А для крупных то, что
> написано у меня.

Ох, Алексей... Открою вам страшную тайну -- написанное Awasaky действительно для ЛЮБОГО размера компании, поскольку это единственный логичный вариант работы над проектом, который требует относительно много времени и вовлекает больше одного человека в процесс. Когда каждый предыдущий этап создает базу для последующего.
(препродакшн) Концепт > Прототип > (продакшн) Альфа > Бета > Мастер-кандидат > Релиз

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

Отдельно доставило, что среди языков, упомянутых вами, гордо красуется Visual Basic и насквозь отсутствует Action Script 3, применяемый сейчас вообще повсеместно (да, и в "больших" проектах тоже).

Алексей Патрашов
> и всё, что угодно, кроме игр?ссс
> Единственное, что я нашёл у нас это Касихин и его труд
Вы искали у себя на пыльном чердаке?

Алексей Патрашов
> Раньше хоть поиграть было во что, а теперь и эта отрасль развалилась.
Слишком громкое заявление от безработного, озлобленного программиста расчетчика, не знающего ни игр, ни их производства.

Awasaky
> Кроме этого, некоторые места противоречат даже элементарной логике. Например измерение пространства - временем
Awasaky
> Пространство - можно измерять только пространственными эталонами. И наиболее важными являются не абсолютные, а относительные размеры.
А вот тут я должен пояснить свой подход. Вместо массы ядерщики часто используют энергию - электронвольт. Да, при разработке важны относительные размеры потому, что с ними работает среда разработки. А как измерить расстояние в игре? Тут уже несколько тем по этому вопросу расплодилось. И тогда я придумал принимать за единицу расстояния в игре то расстояние, которое определённый объект проходит за определённую единицу времени. Это как световая секунда - инвариант. А чтобы не делить постоянно на скорость и появилось измерение в секундах. размерности у физических величин бывают вообще очень странные.
Awasaky
> Попросту неуместные для "краткого руководства" главы.
Я могу его и переименовать, просто пока я считаю это делать рано.
Rai
> Отдельно доставило, что среди языков, упомянутых вами, гордо красуется Visual Basic и насквозь отсутствует Action Script 3, применяемый сейчас вообще повсеместно (да, и в "больших" проектах тоже).
Как я и говорил, этот раздел будет сильно переделан ибо я его один не потяну.

Алексей Патрашов
> Я могу его и переименовать, просто пока я считаю это делать рано.
Что это будет, тогда?

http://www.arcada.com.ua/infot/free/gost/2.103-68.pdf - это ГОСТ на предмет, а не на программу.

Влияние числа игроков или мало нас
Влияние есть, как описано - нет. Тем более там описано устройство, а не влияние.
Тем более что плотность игроков - технический параметр, а не игровой. Игрок в главе - абстрактная сущность, без свойств и взаимодействий.  В плоских ММОРПГ на одном экране могут быть тысячи игроков - просто потому что сервер это "тянет".
Ну и терминологически -- подавляющее большинство под ММО понимает ММОРПГ близкие по устройству к WoW. То есть все довольно размыто.

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

Rai
> (препродакшн) Концепт > Прототип > (продакшн) Альфа > Бета > Мастер-кандидат >
> Релиз

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

В играх - как описал Awasaky.

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

Не многовато ли? результат то в одну страницу, это чисто "идэя".

2. у меня нет персонажей и мобов в игре, что делать?
3. отрисовка интерфейса на втором этапе - порадовало :)

Интересно еще, а зачем тогда балансирование и геймдизайнеры, кроме как на первом этапе? )

Первые три картинки задумали заставиться об ориентации автора, уж простите

Алексей Патрашов
> Будет уже просто руководство по созданию компьютерных игр и с любым необходимым
> количеством соавторов. Мне нужен пригодный для использования результат, а как
> он будет получен - не имеет значения. У нас в технической литературе чуть ли не
> сотня авторов одну книгу пишут иногда, а ваша отрасль чем хуже?
Тогда вам лучше отталкиваться от этапов описанных мной и рассказывать о каждом отдельно.
Правда всеобъемлющего руководства  создать не удастся, поэтому предлагаю нацелиться например на разработку игр под html5, как наиболее перспективной платформы, признанной даже Adobe, для небольшой команды в 2-5 ключевых разработчиков (код, дизайн, арт).
Опять таки саму игру делят на дизайн, арт и код. Причем кодерам в каждой итерации надо описание того как итерация будет работать, арту - как выглядеть, а дизайнерам игры, кроме задач на итерацию, нужны редакторы уровней и возможности по настройке и влиянию на игровой процесс. Детализация описаний - очень субъективный момент для каждой команды.

Алексей Патрашов
> Если дочитаете до самого конца, то увидите пять примеров концептов игр, но
> делать мне их не с кем. В команду пока просочиться не удалось. Я не
> программист, а расчётчик программист, а отрасль мою недавно развалили
> окончательно.

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

ufna
> Первые три картинки задумали заставиться об ориентации автора, уж простите

Same here :)
Даже не картинки, а подписи к ним... :D

Awasaky
> это ГОСТ на предмет, а не на программу.
Там ГОСТ писали деятели вроде меня - так же косноязычно. Да, он на изделие, но формально программа может считаться изделием. Меня в общем волновала в данном случае методология, которая по моему мнению подходила.
ufna
> Не многовато ли? результат то в одну страницу, это чисто "идэя".
Нет, их привлекают на короткое время, а вот экономят они много времени. Это в общем-то называется мозговой штурм так что много тут не бывает.
ufna
> у меня нет персонажей и мобов в игре, что делать?
Пользоваться тем, что подходит. Я это руководство больше ориентировал на RPG, но оно может и к другим областям подойти.
ufna
> отрисовка интерфейса на втором этапе - порадовало :)
Второй этап это всего лишь концепт, а дизайн и балансировка делаются уже на третьем и позже. А вот интерфейс чем раньше - тем лучше. Подлючесть этой части я на себе проверял.