программирование больших игр

Здравствуйте!
  Я учусь программировать игры. Написал часть игры на флэше и зашел в тупик. Делал я без серьезного проектирования, методом добавления частей к тому что получается. Сейчас пробую спроектировать всю игру на бумаге, разделить на логические части, и потом уже писать программу. Проблема в том, что большая программа сложнее чем сумма её частей. Как сделать отдельные элементы программы мне понятно. Но в голове не помещается большое количество частей, потому что они все взаимосвязаны сложным образом. Я не знаю, как написать большую программу. Думаю что нужно её разделить на модули, состоящие из функций и данных. Определить способы использования и взаимодействия модулей, и потом собрать всю программу как из кубиков. Это наверное описано в объектно-ориентированном программировании. Читаю книги об этом. Те которые я нашел содержат много  теории и малопонятные примеры, в которых я не вижу практической пользы. В книгах посвященных объектно-ориентированному программированию ничего нет о написании игр. В книгах об написании игр, рассматриваются вопросы о движке, использовании спрайтов и звука, искусственного интеллекта, меню и т.д. Но не описывается объектно-ориентированный подход. И практические примеры в них приводятся как правило небольших программ.
  Сейчас я изучаю game maker. В нём сочетается объектно - ориетированный подход и специализация на разработку игр. Есть хорошие обучающие материалы, но они рассказывают не дальше арканоида. Нашел один исходник серьезной игры, но к нему нету документации. Разбираюсь как могу. Реально объем моего проекта не так уж велик, под силу одному человеку. Есть ли в сети книги посвященные программированию серьезных игр, где используется объектно – ориентированный метод? Написанные понятным языком, чтобы уделялся вопрос построению большой игровой программы. Кто-нибудь сталкивался с такими проблемами или знает как их решить?

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

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

Нарабатывается с опытом.
Советую поизучать паттерны проектирования.

Книжки:

Для начинающих:
Приемы объектно-ориентированного проектирования. Паттерны проектирования.

Для опытных:
Архитектура корпоративных программных приложений.

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

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

Kloun
> я лично использовал второй подход
Да я думаю, большинство программистов тоже написали первую фабрику раньше, чем узнали, что она так называются :D
Для меня все эти паттерны делятся на две категории - "а, вот как эту штуку, оказывается, называют" и "че-то пока не понял, ну ладно, пойму когда-нибудь потом".

Pushkoff
>все сталкивались... никто (кроме Вия естественно) не знает как их решать...
>в общем просто учись делать то чего еще не умеешь и будет тебе счастье...
Согласен. Я и не ожидал, что получу готовое решение. Наверное решать все-таки кто то умеет, но это трудно представить в виде простого рецепта.

MoonStone
>Мне, например, помогают примеры из жизни...
Да, классный метод,  я тоже стараюсь его использовать.
>Но в самом начале весь функционал игры, все её фишки валю в кучу...
Хорошая подсказка. Я так и сделал. Теперь делю на группы и систематизирую.
>необходимость встраивания очередной фичи выльется в переписывание всего
>Это, к сожалению, происходит очень часто даже в опытных конторах
Я в этом убедился. Если эта проблема есть у всех, значит я не одинок и правильно мыслю.

Dufrenite
Спасибо за книги. К сожалению они не про написание игр, но хорошие идеи в них есть.

Kloun
>взять свою волю в кулак и дописать до логического завершения то что начал
В точку. Постараюсь.
BUzer
lexer
Большое спасибо за ответы и внимание к моим вопросам.
Всем
Сейчас я с головой погружен в проектирование, ваша помощь и подсказки мне помогли.

Что-то автор не по тому пути идет и советуют ему не то.
Случай автора явно не является большим проектом и польза от ООП тут сомнительна. В отсутствии ООП и паттерны не нужны.

У меня такое ощущение, что автор элементарно не умеет разбивать программу на функции.
Этого абсолютно достаточно для всех игр на флеше.

vegaconst
главное запомни, никогда не слушай противников чего либо!!! (в данном случае пакимон противник ООП и С++) в их словах больше религии и непонимания, чем истины... попробуй, а потом решай надо оно тебе или нет...

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

Pushkoff
> ( в данном случае пакимон противник ООП и С++)
Со слов кодеров С++  -  это рекурсивный язык и на нем так и надо программировать ВСЕ ( в древнем Pascal-е тоже имеется рекурсия ..хм )
ООП - не что иное как установка const-ант в начале программы ( естественно их нельзя менять впоследствии - их можно расширять при ООП )

vegaconst
> сочетается объектно - ориетированный подход
но никто не говорил делать его "деревянным" ( т.е. тем способом которым его предлагают реализовать )

http://www.gamedev.ru/gamedesign/forum/?id=124719&page=12#m166

Вот - четыре корабля - две канонерки - два Light Fighters - одна планета - одна луна - и того - аж 10-ть " Летающих Аннимированных Конопок " ( аННигилятор ) -  "спецэффекты ++" .

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

Ну перечисли свои модули для начала.
А от Прочтения Книжки Гаммы еще никто программировать не разучился.

vegaconst
> Я учусь программировать игры. Написал часть игры на флэше и зашел в тупик.
> Делал я без серьезного проектирования, методом добавления частей к тому что
> получается. Сейчас пробую спроектировать всю игру на бумаге, разделить на
> логические части, и потом уже писать программу. Проблема в том, что большая
> программа сложнее чем сумма её частей.

Да, это случается, когда не соблюдается принцип композиционности (compositionality principle). На практике очень часто не соблюдается, но к этому следует стремиться.

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

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

> Я не знаю, как написать большую
> программу. Думаю что нужно её разделить на модули, состоящие из функций и
> данных. Определить способы использования и взаимодействия модулей, и потом
> собрать всю программу как из кубиков.

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

Способность находить общие паттерны в коде и абстрагировать их приходит с опытом. Также рекомендую книги, которые специально этому обучают (http://htdp.org/, SICP, Algorithms + Data Structures = Programs). В целом, чем больше разных подходов изучите и сравните -- тем лучше.

> Это наверное описано в
> объектно-ориентированном программировании. Читаю книги об этом. Те которые я
> нашел содержат много  теории и малопонятные примеры, в которых я не вижу
> практической пользы. В книгах посвященных объектно-ориентированному
> программированию ничего нет о написании игр. В книгах об написании игр,
> рассматриваются вопросы о движке, использовании спрайтов и звука,
> искусственного интеллекта, меню и т.д. Но не описывается
> объектно-ориентированный подход. И практические примеры в них приводятся как
> правило небольших программ.

В книгах навроде "Объектно-ориентированный анализ и дизайн" подразумевается, что у читателя присутствует некое интуитивное понимание объектов и ООП, но авторы не прилагают усилий, чтобы такое понимание сформировать. Да и рассчитаны они, как правило, на немного другой контингент (разработчиков корпоративных систем, у них немного другие реалии).

Larik
> лучше делать игру, а не заниматься бестолковыми проектированиями очередного
> фэйло-движка, и фапаньем на новый EXT.

Выговорился, и аж потеплело, правда? Человек задал вполне конкретный вопрос. Если ты подходишь ко всем вопросам со стороны "пощупать ручками", то некоторые также рассматривают и чужой опыт. Прими, что не все делают именно так, как ты, и ничего плохого в этом нет. А теперь -- марш доделывать уроки.

chiaroscuro
я и ответил человеку, что в его ситуации (как и почти во всех 99% остальных) нужно учиться делать сам геймплей, а не проектировать движок.
И да, это мой, увы печальный, почти 8 летний(+) опыт.
Если бы во времена, когда я еще делал уроки, вместо проектирования, сразу бы начал делать геймплейные фишки, сейчас бы наш проект был намного выше уровнем.