Посоветуйте методичек по разработке игр

Project Managament нужен? В остальном, я боюсь, каких-то конкретных правил нет. Есть Best Practices, а так, по своему опыту - ГОСТ, но это тебе видимо не поможет.

> ГОСТ, но это тебе видимо не поможет.

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

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

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

> где указано требования в написанию программ в научных целях и т.д.?

Ну, там про науку такого нет явно.
Просто - терминология четкая, и грамотный подход «совковой» закалки.

Вот ссылки:
http://www.rugost.com/index.php?option=com_content&task=view&id=75&Itemid=52 (АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ. ОСНОВНЫЕ ПОЛОЖЕНИЯ) http://www.rugost.com/index.php?option=com_content&task=view&id=86&Itemid=52 (ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТА «ОПИСАНИЕ АЛГОРИТМА»)
и т.д. по ссылкам отсюда: http://www.rugost.com/index.php?option=com_content&task=category&sectionid=6&...

Спасибо! Полезные ссылки, мне вот как раз надо было что-то,
чтобы формально описать результаты работы, которые есть
GPLv2-licensed программы, скоро выложу, когда хоть до альфы доползу.

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

2. из опыта - заведите вики, там проще всего обмениваться идеями

Какие должны быть документы общего характера, описывающие игру «в целом», с чего начинать, если требуется показать применение некоторых современных подходов в построении игры

любая игра раскладывается на 3 принципиальные куска: дизайн, гейм-дизайн, кодирование

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

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

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

как то так

http://www.design3.com/learn

>Просто логи в скайпе за документацию не сойдут - так многое забудется.

Заведите себе вики, где будете описывать что-то. Еще вариант - завалиться к нам на lorcode.org, мы вам выделим раздел форума, там все ваши мысли сохранятся. Да и вики у нас есть, тоже выделить по идее можно.

> из опыта - заведите вики

OK. Что есть простенькое из вики?
MediaWiki поднимать не хочется (тяжеловато, IMHO).

DokuWiki — предельно просто, думаю для вас самое оно.

>в своё время искал - ничего не нашёл

Хреново ты искал, наверное, или лениво: http://tinyurl.com/64xypao, первая ссылка: http://the3fold.free.fr/doc/games.pdf. Что касается документов http://tinyurl.com/5vwtres, например, рыба раз: http://tinyurl.com/6fqxe45, рыба два http://tinyurl.com/5tahrlp, методология в популярном изложении http://www.gamedev.net/blog/7/entry-2200554-how-to-make-a-game-design-document/ (или, для незамутненных: http://www.dummies.com/how-to/content/designing-video-games.html). Еще http://www.dtf.ru/articles/read.php?id=39001 и, если кто не знал, была такая книжка: http://www.ozon.ru/context/detail/id/111274/

Совсем забыл, еще тут: http://www.di.fc.ul.pt/~jpn/design/index.htm

> из опыта - заведите вики

OK. Что есть простенькое из вики? MediaWiki поднимать не хочется (тяжеловато, IMHO).

зарегайте на http://bitbucket.org по аккаунту и создайте репу (можно закрытую) и будем Вам и вики и контроль версий «искаропки»

Хреново ты искал, наверное, или лениво

это, в основном, книги по геймдизайну, а это лишь часть документации, и уж тем более не то что ТС просил

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

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

>уж тем более не то что ТС просил

«Какие должны быть документы общего характера, описывающие игру „в целом“» (с) Не говори за ТС (я так и знал, что ты Ъ) ;)

>Посоветуйте методичек по разработке игр

Эт к вопросу «о чем таки просил ТС» ;)

> Эт к вопросу «о чем таки просил ТС» ;)

Ссылки ты кинул интересные, особенно на dtf.ru.
Уже начал читать.
Времени у меня - почти год на разработку.
Хочется наиболее оптимально распланировать время (взаимодействие в команде).

Я когда-то проектировал простенькие игрушки.
Вначале - без документации, чисто - кодирование в Norton Commander/Internal Editor на асме (это было в школе),
потом - начал писать спецификации на бумаге ручкой (это были курсовые по машграфу),
потом уже начал писать методологии и всякие теории в Вики (когда пытался участвовать в полеоткрытом проекте среднего размера).
Но последнее у меня выглядело очень несистематично - куча заметок (куча идей), разбросанных по вики, документам OpenOffice, всяким эскизам, рисункам.
Хотелось бы объединить это все в одну систему, на основе каких-то существующих методик. И слегка подправить свой подход к разработке.

>Посоветуйте методичек по разработке игр

Эт к вопросу «о чем таки просил ТС» ;)

цитируйте уж всё, чего стыдиться

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

>уж тем более не то что ТС просил

«Какие должны быть документы общего характера, описывающие игру „в целом“»

1. в приведённым Вами ссылках ответа на этот вопрос нет
2. это был второй вопрос

http://www.linux.org.ru/jump-message.jsp?msgid=6276884&cid=6278170 чего тебе еще не ясно про разницу между ТСом и про тобой(в смысле, между вашими интересами)? Особенно умилительно произвольное подчеркивание слов, которые тебе показались ключевыми.

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

мне всё ясно, и разница межу нами в том что я уже нахлебался, а ТС ещё только готовиться прыгнуть

Особенно умилительно произвольное подчеркивание слов, которые тебе показались ключевыми.

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

> В первую очередь - интересует порядок написания тех.документации

Собственно, план разработки за меня никто не напишет.
Но хотелось бы тоже примеров, да.

>1. в приведённым Вами ссылках ответа на этот вопрос нет

Ъ такие Ъ. Я лишь убеждаюсь, что ты по ним не ходил/посетил не все или дальше заголовков не читал. Мэд скилл поиска глазами по диагонали не отменяет вдумчивого чтения. Ищущий да обрящет ;)

>нее стоит тратить время столь неумело отмазываться

Начни уже с себя, что ли.

>мне всё ясно, и разница межу нами в том что я уже нахлебался, а ТС ещё только готовиться прыгнуть

Дорогу осилит идущий. Пиши просто «не осилил». Пусть ТСу повезет, не демотивируй.

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

А не хотите Agile попробовать? Первый пишет инфраструктуру, второй пишет на ее основе высокоуровневую логику. Второй по мере использования инфраструктуры дает тебе фидбек в виде задач на следующую итерацию первому. Итерации вам недели в 2 хватит. Какие-то результаты совещаний, переписок почты фиксируйте в вики.

Итого документация:

1. Беклог фичей в трекере + roadmap.
2. Прикрепленные к задачам в трекере ссылки на документы в вики.
3. Doc, генереный из исходников.

> 1. Беклог фичей в трекере + roadmap

Я медленно пишу программы, поэтому описание фич обычно пишу сразу в итоговом документе (либо - мелкие исправления - в Changelog.txt по версиям).

2. Прикрепленные к задачам в трекере ссылки на документы в вики.

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

3. Doc, генереный из исходников.

Это - явно не для меня.
Мне проде cproto натравить на исходник - и прикинуть что - к чему.

Вообщем, будем промежуточное готовить в Wiki, и собирать результат в ODT/PDF, наверное (для релизов).

Только реши для себя какие документы, схемы и диаграмы кокретно для чего нужны. Главное не следовать принципу «что бы было», помня что документация сама по себе требует затрад на поддержку. Т.е. выгода должна перевесить затраты.

Что касается конкретных типов документации. Я не имею отношения к геймдеву, но я бы начал документирование с эскизов различных игровых сцен. Эскизы потом трансформируют в беклог (список user story). Каждая фича реализуется «как попало», попутно ставятся задачи на следующую итерацию по рефакторингу. Это самый легковесный подход, но увы он часто приводит к плохой внутреней архитектуре, т.к. рефакторинг не всемогущ.

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

> Т.е. нужно на абстрактном уровне понять что есть ваш будущий продукт и из каких абстрактных сущностей она состоит.

Я последнее время перестал решать задачи «сверху вниз».
Обычно собираю систему из «деталек». Чего-то не хватает - иду в гугль и ищу подходящие примеры там.
Хотя, способ, безусловно, хорош для «долгостроев».

Собирать систему из деталек это как раз снизу-вверх не? :)

Вообще при итеративной разработке смысл подходов «снизу-вверх» и «сверху-вниз» теряется, т.к. каждая итерация дает фидбек предыдущему уровню, и все как бы перемешивает. Т.е. при итеративной разработке происходит разработка «низ<->верх». С объектным подходом все еще сложнее становится, т.к. объекты, лежащие выше в иерархи, а следовательно имеющие более абстрактный интерфейс, могут иметь более низкоуровневую реализацию. Т.е. с точки зрения ООП (т.е. публичного API) разработка идет сверху-вниз, а с точки зрения слоев системы снизу-вверх.

> Т.е. с точки зрения ООП (т.е. публичного API) разработка идет

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

Да, на разных уровнях проектирования разработка может идти по-разному.
Например на уровнях:
- Философия
- Методология
- Физика, математика (различные методики)
- Алгоритмы (программирование)
- Код

>мне всё ясно, и разница межу нами в том что я уже нахлебался, а ТС ещё только готовиться прыгнуть

Дорогу осилит идущий. Пиши просто «не осилил». Пусть ТСу повезет, не демотивируй.

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

> В первую очередь - интересует порядок написания тех.документации

Собственно, план разработки за меня никто не напишет. Но хотелось бы тоже примеров, да.

ну, план привести не могу - это немного нереально в рамках здешнего формата

я бы делал так:
1. концепция игры (действующие лица, жанр, вид от какого лица и прочая прочая, всё грубыми мазками)
2. первичное обсуждене геймплея, выявление первичных/основных игровых механизмов подлежащих реализации
3. выбор движков (физика, графика, звук, сеть и т.п.)
4. определение первоочередного инстурментария подлежащего разработке (редакторы уровней и мобов, просмотрщики контента и всякое такое)

до этого момента можно делать вместе, дальше пути расходятся

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

ну и так далее, повторям п. 6 до победного (условно говоря)

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

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

Вам уже предлагали agile, поддерживаю обоими руками - вероятность успеха сильно возрастёт, да и работать будет комфортнее

> у Вас пока не продуман момент, как мне кажется, с графикой, моделями, видео и звуками,

Мы решили упростить.
- Графику сделать 2D (или простейшую 3D, без текстур).
- Звуки я могу сыграть на синтезаторе CASIO SA-76.
- Микрофон для голоса есть.
- Модели напарник умеет делать (в принципе).
- Видео(?) - OpenGL.

Вам уже предлагали agile, поддерживаю обоими руками - вероятность успеха сильно возрастёт, да и работать будет комфортнее

Это? http://en.wikipedia.org/wiki/Agile_software_development

> у Вас пока не продуман момент, как мне кажется, с графикой, моделями, видео и звуками,

Мы решили упростить.

ок, главное что над этим задумывались

- Видео(?) - OpenGL.

ну это я скорее про видеозаставки и видеоанимации всякие, если по упрощённой программе идти можно смело скипать

> Вам уже предлагали agile, поддерживаю обоими руками - вероятность успеха сильно возрастёт, да и работать будет комфортнее

Это? http://en.wikipedia.org/wiki/Agile_software_development

да, и ещё можно посмотреть вот тут

Я так понимаю, тебе нужны примеры диздоков к играм?

[url]http://www.allowe.com/gamedesign/index.htm[/url]

Еще на бухте есть несколько больших торрентов с книгами по геймдеву - в некоторых есть примеры.

>я то как раз осилил

Давай, пруфани.

>ну, план привести не могу - это немного нереально в рамках здешнего формата

Осилил, ага. Еще скажи что «секрет».