следующая тема »

Спорить не буду анимация это сложно, но если делать игру 2д то z-brush и maya сильно ускорят работу над ней и тогда програмная часть выходит на первый план, а если брать готовый движок от какой либо 3д игры то анимация конечно выходит на первый план, как ты сказал опытного аниматора найти сложно а моушн капчур не по карману.


Выделено из ветки Сеттинг "Тень Созвездия Дракона".

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

Проблема только в целостности персонажа. Если, например, в 2D-игре, платформере, будет бегать 3D-персонаж... это будет выглядеть немного неестественно.
Тогда прийдется и все остальное делать тоже 3D, а потом все поймут, что делать _всю_ графику в отрендеренной 3D не очень хорошо, нужно прикручивать GL... В общем, жуть )

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

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

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

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

И да, человеческий фактор - это сурово.

LittleDrakon, техдокументация может быть заменена другими артефактами. В частности, я, как евангелист SCRUM, рекомендовал бы User Stories, ну и концепты-концепты-концепты. Как естественный артефакт разработки.

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

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

[Smiling Killer]

Главное -- это результат, работающий код, хотя бы и техническое демо

Именно. Долой трёхтомные рассуждения, даёшь работу над материальной частью! )
Smiling Killer, когда ты говорил, что есть левел-дизайнер, это ты про меня? Если да, то было бы неплохо как можно скорее получить какие-то указания, что желательно сделать в первую очередь. Даже пока движка нет, я мог бы в 3Д что-нибудь склепать. Наброски уровней, ну а ты бы сразу сказал, что нужно исправить, чтобы я знал в дальнейшем.

было бы неплохо как можно скорее получить какие-то указания

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

Вначале надо иметь план того, что строишь. Чтоб не пришлось сносить спальню, потому что не влазит санузел. А когда добавляешь что-то новое, лучше видеть имеющееся целостным.

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

[LittleDrakon]

LittleDrakon, ты так об этом заботишься. Будто ты умеешь заниматься игростроем. =Р Я не собираюсь делать сразу всё. Сначала делается уровень в крупных подробностях. Потом неточности исправляются. Затем идёт поэтапная детализация с последующими исправлениями и т. д..

человеческий фактор - это сурово.

А менеджер нужен затем, чтобы координировать работу всех участников команды.

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

Если будет что-то связанное с 3Д (предпочтительно, с построением/дизайном уровней), записывай меня в команду, а там разберёмся.

Хм, я с low-poly решительно не дружу, привык все делать под рендер, а не под игровые движки 

[насколько]

LittleDrakon, ты так об этом заботишься. Будто ты умеешь заниматься игростроем.

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

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

Также хочу подчеркнуть, насколько Джеффи прав.

[геймплей]

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

Пока что концепции игры я не вижу. Хотя да, много всяких интересных элементов сеттинга. Но сеттинг вторичен.

[Добавлено спустя 14 мин.]

LittleDrakon, на тему "документации", уточню Я сторонник простоты во всем, поэтому считаю что документация должна быть минимально необходимой для начала работы, и пополняться в процессе.
То есть конечно должно быть то, без чего работать нельзя, но она не является ключевой. Ключевым является код. Работающий код. Точка )

Но вообще мне кажется что это стоит перенести в личку ) И пообсуждать управление проектами в свое удовольствие там )

Добавлено спустя 14 мин.

LittleDrakon, как я понял из описания, то будет что-то вот такое вот:
http://ru.wikipedia.org/wiki/Beat_'em_up

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

[LittleDrakon]

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

Совершенно согласен. Чрезмерная увлечённость мечтаниями на игровую тематику приводит к провалу проекта. Мне достаточно того, что в концептах я увидел "приблизительный вид от первого лица" - я уже мог бы начать что-то делать, и желательно начать сейчас. Чтобы я уже мог приспособиться под стиль выполнения графических работ, требуемых главой проекта. Движок, кстати, лучше взять какой-нибудь готовый, либо полуфабрикат вроде Crystal Engine.

LittleDrakon, ты на самом деле ничего не понимаешь в создании игр. Я лучше знаю, что надо делать, т.к. имею опыт в гейм-дизайне. Особенно в дизайне уровней. Scratch прав. Вопрос закрыт.

Чейсил, судя по описанию -- трехмерный шутер от третьего лица (камера плавающая, как обычно), что-то стиля Kill'em all.
Судя же по картинкам-концептам -- непонятно, то ли 3D, то ли 2D.

Разработка, как подозреваю, планируется исключительно под Win, то есть, скорее всего, под D3D.
Что огорчает, увы...

[конечный продукт]

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

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

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

[LittleDrakon]

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

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

LittleDrakon, ладно, пусть уж помучаются в святом неведении, а там посмотрим 

Он будет видеть, как должен выглядеть конечный продукт

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

Jef-F, вы никогда не сталкивались с XP или SCRUM? Или RUP?
Собственно, многие полномасштабные проекты были сделаны по этим методологиям (объемы проектов -- ну, не на уровне операционной системы, но примерно так...)
Кстати, покажите мне "техническую документацию" на Linux ) А ведь тоже, как никак, операционка.
Просто там есть свои методики обеспечения целостности и качества

покажите мне "техническую документацию" на Linux

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

К тому же, если вопрос закрыт, с чего это целых два Капитана Очевидности ещё его обсуждают? 

Jef-F,
КО очень любят обсуждать.
Так вот, в тему... Какое "вбегает и кричит", какое "собственные фантазии"? Это как раз твои фантазии )

У проекта есть владелец, который рассказывает что и куда. И зачем
А в большинстве случаев, еще и отвечает на вопросы "а вот тут что делать будем?"

К сожалению, иногда у проекта несколько "владельцев", вот тогда это ад...

Так вот, а "техдок" далеко не всегда есть в том виде, в котором есть. Например, CRC-карта,  UserStory -- это артефакты. Которые описывают продукт.
В нашем случае, концепты -- это тоже артефакт. Который описывает.

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

[обсуждению сеттинга]

Ещё несколько дополнений. Во-первых, тема посвящена обсуждению сеттинга, а сами игры (причём несколько игр!) отнесены в некоторое будущее. Видимо, у Чейсела будущее уже наступило.

Во-вторых, я поковырялась в том, что представлено как "концепт игры".

"Ничего кардинально нового только проверенное  старое: больше и вкуснее".
Ок, проверенное старое. У игры есть два способа быть хорошей: быть неожиданной и интересной (тут даже неказистая угловатая графика не помеха) или быть очень качественной, на голову выше конкурентов. Оригинальности не планируется вовсе, оттого, что поменяли мечи на сабли, её не прибавится. Ладно. Высокое качество... для высокого качества нужны мощные производственные ресурсы, специалисты, деньги, грамотная техдокументация и планирование и ВРЕМЯ. От 3 месяцев до года при восьмичасовом рабочем графике группе профессионалов потребуется для реализации движка под нужды такой игры. Я не буду уточнять, что чтобы обогнать в качестве другие игры, нужно вложить немало денег (например, в лицензирование некоторых полезных продуктов или софта). Просто представьте: год работать без отпуска с 8-часовым графиком БЕЗ ЗАРПЛАТЫ, все универы-школы побоку.

Про "есть идея" - это прикручивание дополнительных фишек к уже имеющемуся. Это проще.

ЗЫ. Я знаю, что Chaiseel читается как [чейсил]. Но в моём озвучивании фонетика возвращается к своим корням, так что извиняй.

[LittleDrakon]

LittleDrakon, чтобы сделать игру, которая понравится здешним форумчанам, она должна быть про драконов. И не должна быть полным отстоем. Вот два критерия. =Р
И с чего ты взяла, что я рвусь прямо сейчас делать уровни, которые обязательно войдут в игру? Воспринимай их как своего рода концепт-арт. Может быть и войдут, может, мы их порежем на куски, и в игру войдёт отдельные части. А может, руководитель скажет сделать всё по новой. Так вот, лучше всего будет, если он скажет делать всё по новой пораньше, чем если он скажет делать всё по новой, когда у меня уже готов уровень с детализацией и текстурами. И было бы вообще замечательно, если бы ты тоже в чём-то помогла, а не указывала, что делать. Ты ведь так *кхе-кхе* много знаешь про гейм-дизайн. 

Если не можешь выговорить моё полное имя, то зови меня просто Чейс. 

[нет никакой необходимости]

LittleDrakon, чтобы сделать игру, которая понравится здешним форумчанам, она должна быть про драконов. И не должна быть полным отстоем. Вот два критерия. =Р

При чём здесь форумчане? Я рассматриваю игру в принципе, а не "игру-для-Гнезда". И использую общие критерии. Чтобы получилось действительно вкусно, а не так "тяп-ляп, свои проглотят".

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

Хочешь мастерить в своё удовольствие - мастери. Но когда ты работаешь в команде - будь добр, не задерживай остальных. Если ты наваял уровень со всем, чем надо, а его надо в помойку и всё переделывать, то тут есть две причины: 1) непродуманность проекта (вина геймдизайнера); 2) глупость исполнителя (вина дизайнера уровней). И то, и другое одинаково плохо. А с переделыванием "как можно раньше"... То есть ты уже заранее настроился на провал, срыв всех сроков и почивание проекта в бозе? Ты заранее смирился, что ошибку совершишь либо ты, либо геймдизайнер? Запланированную ошибку, а не те, от которых никто не застрахован?
Руководитель должен сказать делать всё по-новой ещё ДО того, как ты начнёшь делать. Иначе это фэйл.

И было бы вообще замечательно, если бы ты тоже в чём-то помогла, а не указывала, что делать.

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

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

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

Эту игру я хочу какраз вывести на сюжете и красоте.

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

Вдогонку - книжка раскрылась на этом месте.

Часть 3. Разработка архитектуры игр
Глава 17. Подготовка к созданию технического проекта.

Основные темы:
- Значение качественной проработки архитектурного проекта
- Учёт особенностей платформы
- Проблемная область
- Выделение базовых элементов
- Взаимодействие базовых элементов
- Конечные автоматы
- События, автоматы, переходы и свойства

В части I этой книги был рассмотрен процесс проектирования игры, начиная от формулировки идеи до получения проработанного эскизного проекта. При этом мы несколько раз отклонялись от основной темы, чтобы показать, что такое игра с математической точки зрения. В этой главе мы продолжим развивать темы, затронутые в части I. К этому моменту перед вами уже должен лежать проработанный эскизный проект, по которому вполне можно понять, что из себя представляет игра. Эта глава начинается там, где заканчивается часть I. Вы уже достаточно потрудились над эскизным проектом, и теперь настала пора реализовать его в виде задуманной вами потрясающей игры. Ну что ж, приступим к программированию!
Да, именно так обычно и происходит.
Если вы внимательно читали книгу, то заметили, что мы постоянно подчёркиваем тот факт, что в подавляющем большинстве случаев за этапом разработки эскизного проекта игры (если он вообще есть) сразу же начинается этап производства, т.е. написание программного кода. Также вы, наверное, поняли из наших комментариев, что игровая индустрия – единственная отрасль программной индустрии, в которой пока ещё сохраняется подобный любительский подход к производству программных продуктов. Почему? По одной простой причине – игровая индустрия до сих пор не перешла на современные методы производства. Текущее состояние дел в области организации разработки игр соответствует тому состоянию, которое было типичным для программной индустрии пять-семь лет тому назад. Да, сами по себе методы программирования вполне современны, однако методика их использования устарела. Это чем-то напоминает изготовление серийных автомобилей не на конвейере, а вручную, хотя и с помощью самых современных инструментов. Пять-семь лет, учитывая темпы развития программной индустрии, - это целая вечность.
Следует понять, что разработчики пишут проектную документацию (архитектурный проект, технический проект и т.п.) вовсе не для того, чтобы как-то скоротать свободное время. Наличие такой документации – это всё равно, что наличие карты при путешествии по незнакомой местности. Если в руках разработчиков имеется технических проект, они могут лучше понять, где они находятся в каждый момент времени, а их руководство – увидеть, насколько успешно продвигаются работы в целом и насколько они соответствуют планам компании. Нети никакого смысла, закопавшись в руководства по конструкции дисков CD-ROM, разрабатывать в течение месяца модуль для воспроизведения компакт-дисков, если коллеги из соседней группы сделали такой модуль ещё полгода назад или он был заблаговременно куплен компанией и теперь пылится на полке за коробкой от Quake III. С другой стороны, зачем было тратить время и деньги на создание или приобретение модуля, если о его существовании никто не знает?
Технический проект – это нечто вроде рекламы. С его помощью сотрудники, работающие над реализацией других проектов, могут узнать, чем вы занимаетесь, и увязать свои работы с вашими. Это поможет не только избежать никому не нужного дублирования, но и позволит сделать более прозрачным процесс разработки. До тех пор пока технический проект не будет написан (как минимум, в соответствии с правилом 80/20), ни в коем случае нельзя начинать этап производства. Перед тем как приступить к написанию кода игры, следует выполнить ряд подготовительных этапов, цель которых – переход от общей картины, представленной эскизным проектом, к детализации её отдельных составляющих (технических заданий на проектирование каждого модуля). Поэтому отложите пока в сторону «каску» кодировщика, поскольку она вам понадобится несколько позднее, наденьте «фуражку» архитектора и продолжайте чтение.
В этой главе описываются начальные этапы процесса создания технического проекта, цель которого – углубленная проработка эскизного проекта, заканчивающаяся созданием общего архитектурного проекта игры. Архитектурный проект является частью технического проекта, на основе которой и разрабатываются конкретные технические задания на создание отдельных модулей.
Как уже было сказано выше, здесь в дело снова вступает правило 80/20. Оно означает, что получить полностью проработанный архитектурный проект до начала кодирования невозможно. Однако вполне можно выполнить его на 80%, а остальные 20% уточнить уже в ходе реализации проекта. Поэтому следует понимать, что архитектурный проект никогда не бывает «завершённым», поскольку во время производства программного кода в него могут и должны вноситься модификации. В этом нет ничего плохого, более того, - это является признаком того, что проект развивается нормально. Никто не может заранее предсказать на 100%, что нужно будет сделать в проекте через полтора года. Некоторые детали прояснятся только после того, как написан определённый объём программного кода. Однако, если архитектурный проект как следует проработан, количество переделок будет сведено к минимуму. Большинство модификаций будет представляет собой уточнения и некоторое развитие документа. Кстати, здесь мы хотели бы подчеркнуть особую важность, которую имеет поддержание постоянного соответствия документации и программного кода. (Мы уже неоднократно говорили о том, что создание документации должно рассматриваться как необъемлемая часть процесса разработки программного кода. При этом собственно кодирование – лишь небольшая, хотя и важная часть работ, которая должна выполняться в самом конце производственного цикла.)
Классический аргумент против того, чтобы заниматься всей этой «бюрократией», состоит в том, что программный код – это и есть самая лучшая документация. Конечно, это в каком-то смысле соответствует действительности, но это не значит, что подобная аргументация должна рассматриваться как нечто заслуживающее внимания. Если так рассуждать, тогда следует вместо документации просто распечатать исходный код игры и написать сверху «Смотри!», как в случае одного из остроумных доказательств теоремы Пифагора. В компаниях, занимающихся разработкой игр, исходный код считается лучшим видом документации только потому, что никто из сотрудников таких компаний в большинстве случаев не утруждает себя написанием настоящей документации. Однако таким компаниям следует подумать над тем, что документация пишется не только и не столько для себя, а сколько для других людей. Она может понадобиться всем, кто захочет узнать, что происходит в проекте, или для выполнения служебных обязанностей – начиная от рядового участника рабочей группы другого проекта и заканчивая проектировщиком игры или даже президентом компании.
Ещё одним классическим ответом, который приходится слышать в подобных дискуссиях, является утверждение о том, что программный код – это всё равно единственный вид необходимой документации, поскольку все, кто не умеет его читать, в документации не нуждаются. Если вы действительно в это верите, тогда нам остаётся только умыть руки. Возможно, вам стоит подумать о другой карьере, например, смотрителя маяка. В этом случае вам не придётся общаться с другими людьми, поэтому вы сможете вообще не задумываться о каких-либо средствах общения.
Кроме того, попробуйте-ка сказать президенту компании, когда он затребует проектную документацию, чтобы посмотреть, как идут работы, что ему нужно просто научиться читать программный код. Возможно, в таком случае решение о том, что вам следует поменять место работы, будет принято не вами!

[Добавлено спустя 4 мин.]

Я имел ввиду что грызться вы можете и в другом месте.
И добавляю что геймплей я  продумываю для обоих версий.
LittleDrakon спасибо прочитал, но так и не понял к чему ты клонишь, напиши в двух предложения претензии чисто ко мне, я так понял что ты просто пытаешься нас уберечь от необдуманного подхода и ошибок, не надо у тебя не получится, а книгу я  попробую прочитать в ближайшее время.
Чейз я могу тебе дать идеи и общее описание для карт, хоть сейчас, но не возмущайся если будешь делать их не в тех *D, можешь занятся этим чисто на бумаге, представляя общую картину и думая над тем как это реализовать в обоих видах.

Добавлено спустя 4 мин.

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

Угагагага. Я сейчас буду реально умирать. Вот так, сразу, и в программные коды, на опенсорсном движке и в полном 3D. А-а-а-а-а!!!!!

Вспомните, уважаемые игроделы, богатые теорией и намерениями, замечательного ежика Соника, который имел 7 или 9 "action" и воевал с зациклованными противниками, имевшими вообще 3-4 "action". Вспомните и ужаснитесь. Ибо - шедевр. Равно как и прочие его братья.
Если суть игры захватывает - играть можно и кубиком покрытым пятью цветов пикселями. Если суть не захватывает - оно никому не надо.

Что же до разработки... У старого и злого сейчас два проекта. Один РПГ-шка с системой опыта и инвентори чейнджа, второй - тактика с элементами стратегии. И оба - НАСТОЛЬНЫЕ. Дети мое - обеим проектам по году почти. А они ох как далеки от завершения.

Итак, что нужно:
1. Разработать тактический математический движок игры
1.1. Модель персонажа (параметры-свойства)
1.2. Модели противников (параметры-свойства)
1.3. Модель боевого взаимодействия (системы расчета повреждений)
1.4. Модель небоевого взаимодействия (экономика)
1.5. Процесс прогресса/развития моделей (система набора опыта и развития персонажей/противников)
1.6. Модели предметов инвентаря
2. Оттестировать движок
3. По результатам тестов ввести балансирующие коэффициенты.
4. Разработать стратегический математический движок игры
4.1. Определить тип мира (пассивный, активный, интерактивный)
4.2. Модель взаимодействия персонажей с миром.
5. Оттестировать сцепку движков.
6. Ввести поправочные балансировочные коэффициенты
6.1. Адаптировать группы поправочных коэффициентов по уровням сложности
7. Определение сюжетной игровой составляющей (квесты, да. Хотя бы один и простой - убить всех, но мотивация пристутствовать должна, ибо не Постал)
7. Введение общей картины базового мира в сюжет
7.1 Объем вводимых данных
7.2. Метод введения
8. Оттестировать систему в комплексе.
9. Ввести поправки
10. Протестировать систему в окончательном варианте.

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

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

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

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

А на одном программном коде и энтузиазме - далеко не уедешь.

Скальд, а ты почитай что говорю я
"реализация -- около 20% от всей работы" )
то есть, что настольную RPG написать, что компьютерную -- разница в 1/5 от общего времени )
Потому что движки, анимация и прочее -- это "от лукавого"
В тетрисе так вообще никакой анимации не было, зато как в него играли!!!

Насчет комментариев... Я лично склоняюсь к Indi-играм. То есть самоизданных )
От наличия "крупного финансирования" далеко не каждая игра страдает...

Так, на тему креативщиков... Их нет.
Есть "владелец" -- который знает что хочет и говорит это исполнителям. У исполнителя есть свобода в том _как реализовать_, но нет свободы в _что реализовать_
Иначе такой исполнитель никому не нужен.

Навыки "приказывать, орать и пороть" -- ну, тут я с вами не соглашусь. Ибо средневековье это -- орать и пороть. Есть другие, гораздо более гуманные и действенные методы )

Насчет "энтузиазма" -- тоже не совсем соглашусь. Без энтузиазма ничего не сделаешь, ибо будет вломы...
Разработчик должен хотеть _работать_, а не просто хотеть денег / профита...

Вообще, я, как уже говорил, являюсь евангелистом Agile Development. Который предполагает несколько неклассическое управление проектами...

И, конечно, моменты насчет "дружбы", "интереса..." --
1) В интересную игру играть будет интересно. Обязательно.
Даже разработчику. Даже тестеру может быть интересно в нее играть
Так же как вдоль и поперек прочитанную книгу может быть интересно читать снова и снова.
Так же как пройденную тридцать раз игру можно проходить опять и опять.
Это если она хорошая и интересная
2) Дружба. Дружба при разработке -- есть. Дружба, командность, "плечо товарища". Вот когда идет раздел денег -- тогда да, дружбы нет. А во все остальные моменты -- она есть.
3) Идеал. Как известно, он недостижим в принципе...

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

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

Ну, на это можно делать упор когда игра уже готова )
А сеттинг -- это "вводная" к игре Некоторый базовый набор рамок.
Обычно же никакие подробности взаимодействий не описываются...
То есть, выражаясь, другими словами, нет конкретики

Да, кстати, даже на анимацию упор не ставят. Ставят упор на то что "я хочу сделать игру" )
Можно, конечно, взять MaxPayne, например, и поменять ему "шкурки" ) Да, будет прикольно... Но толку-то?

[Scald Havoc]

Scald Havoc, сколько слов, а толку ноль. Сначала написать движок, а уже потом решать, на какую платформу выпускать - вперёд, попробуй написать такой движок, который в итоге можно будет компилировать как для ПС2, так и для ПК. Кстати, кое у кого это всё-таки получается. Rockstar Games, например. ) Выгнать из команды всех креативных - выгоняй, работай в гордом одиночестве. Пускай лучше у нас работают креативные. Почти всё остальное, что ты написал - полная чушь. За исключением того, что модели предметов/персонажей/и т. п. действительно нужны в игре, как и, в прочем, движок и уровни. )

2 Smiling Killer: В общем, правильно ты сделал, что дал мне концепты заранее. Т. к. на днях я очень фейлово заболел и никакого настроения что-либо моделить не было. Сейчас уже лучше, но подвалил напряг с учёбой. Сделать модель экзокостюма (или как там называется та красная антрофигня?..) постараюсь всё-таки как можно скорее, ну а ты определяйся с жанром. Если пару моделей закончу раньше, чем ты определишься, то просто возьму и подставлю их в один уже имеющийся движок и посмотрим, насколько получится приемлемо. )

[Scratch]

Scratch, Scald Havoc, эти ребята умных слов не слушают (по крайней мере Чейсил). Даже если им ярые спецы скажут. Даже Роллингз и Моррис, похоже, тут не помогут... Увы.  То есть их проект можно сразу назвать мёртвым - все симптомы налицо.

-- Давайте построим дом!
-- Ага! Тащите кирпичи и раствор, сейчас начнем строить!

Scald Havoc там стоит "или" и там не написанно, что движок должен быть 3д и мод для какой то другой игры приемлимый вариант, поэтому там и написанно "кто то имевший опыт в модостроительстве". Конкретные цифры и баланс высчитываются подставлением чисел в файлик опций и вдумчивым тестингом. А платформа - конечно ПК, а ты имеешь представление о структуре  игры пля PS2?
Что еще? Ах да! ПРОЕКТ НЕ КОМЕРЧЕСКИЙ и распространять его будем бесплатно.

"-- Давайте построим дом!
-- Ага! Тащите кирпичи и раствор, сейчас начнем строить!"
Нет, я говорю: "давайте сделаем гараж и поставим там мебель, кирпичи есть, кто умеет мешать бетон?"

Чем отговаривать нас от того, чтобы сделать свой первый проект, из-за того, что мы этого не умеем и у нас ничего неполучится, вспомните о статистике, 3\4 игр никогда не выходят в свет и у нашей игры точно такие же шансы.
Что вы предлагаете, просто не делать?

Ааа... да! С прискорбием сообщаю, что у меня неожиданно обьявилась киста или что то похожее, такчто я могу неожиданно исчезнуть (возможно положат на операцию а потом на стационар).
Хнык.. хнык...   Но не парьтесь если я умру, то буду являтся вам во снах.

[Smiling Killer]

Smiling Killer, это чёрный юмор?..

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

[Добавлено спустя 3 ч.]

Chaiseel, дружочек, если ты путаешь математический движок, логическое ядро и графический движок - это еще не диагноз, но уже показатель. Как великий или даже величайший знаток игростроя ты расскажи мне вот например почему же Рокстару удалось портировать игру аж на две платформы, кстати, физические параметры объектов игры - они там в графическом движке (который у ПиСи и боксов разные) или в математической модели (которой суть пофигу на чем работать и сколько полигонов в графике)?
Или вот кстати, такой злоизвестный всем фанатам серии игр Комман унд Конквер файлик rules.ini - кусок графического движка или математической модели?
Про организацию работы... Вот честно - будь я координатором или со-координатором проекта - гнал бы я человека с такими как у тебя убеждениями в пять пинков и три шеи. Хотя бы за одну фразу - "я болел и мне было влом"

Smiling Killer
Хех. Как все просто - "подставлением чисел в файлик опций и вдумчивым тестингом" А сто-сто двадцать запусков игры для выверки соотношения 1-2 параметров не хочешь, при работе таким методом? (Увы, увы даже старые и злые были когда-то молоды и наивны и вместо просчета балансировочных формул и построения координатных систем работали методом научного тыка)

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

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

Что вы предлагаете, просто не делать?

Я предлагаю сначала подумать, потом делать.

Что же до реализации... Чем изобретать велосипед - сделайте мод к тому же Обливиону. Заменить модели, вырубить половину скриптов, "выморозить параметры" поставив опыт за уничтожение и выполнение задач на "0", заменить карту на "коридор" и как бы все. Структура там открытая, руководств по модописательству - вагон, в т.ч. и на русском. Возни, правда будет, не меньше чем работать с нуля, но что поделать?

Что еще? Ах да! ПРОЕКТ НЕ КОМЕРЧЕСКИЙ и распространять его будем бесплатно.

И? Я тебе скажу так - не важно, какой проект. Или в команде дисциплина армейского типа с соблюдением демократических основ (т.е. - мы его выбрали - он имеет право нас дрюкать) или это будет очередной "танчик" неверэндинг постройки. Просто поверь - у меня у самого уже три года волынится проект по изготовлению на базе 35-го масштаба 3-х "хаммеров" из Фаллаут Тактикс. Я материалы добыл, штук 100 шотов оного "хаммера" наделал, полазил по сурсам, надыбал описание, эмблемы Братства Стали на фотобумаге в цвете зафигачил... Пластик нарезал, мастики-грунтовки надыбал и прочее. Свою часть работы сделал, короче. Но поскольку анархия в команде - два других человека режут болты. Но каждую встречу (а это два раза в месяц точно) встает вопрос - когда мы их доделаем? (причем поднимаю его не я) и все хором - доделаем-доделаем. Вот только танчики доклеим и доделаем.


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

Scratch

) В интересную игру играть будет интересно. Обязательно.
Даже разработчику. Даже тестеру может быть интересно в нее играть
Так же как вдоль и поперек прочитанную книгу может быть интересно читать снова и снова.

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

Добавлено спустя 3 ч.

Вот, немножко обобщенного опыта - многа букав читать не надо - там все в приаттаченных файлах в последнем сообщении есть Сцылочка

Но ты так натра.....ся со скриптами, которые за этой красотой стоят, что пошло оно все так далеко...

Не согласен )
Как-то раз я писал ма-а-аленький мод (карту + скрипты) для третьих Героесов.
Писал я ее около недели. Почти неотрывно. Ну, чтобы красиво было, и чтобы там вот так, а там вот так, а там еще так... И каждый раз, при изменении, "доигрывал" до нужного момента, пока оно не обламывалось (и я исправлял немножко карту, чтобы там можно было сделать то что нужно).
В общем, через неделю оно было играбельно и более менее красиво...
И что ты думаешь? Я отложил его на недельку, а потом сел и с удовльствием прошел )
Так что -- бабка надвое сказала )

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

[Chaiseel]

Бардак устраиваете вы, "Я предлагаю сначала подумать, потом делать." ты заметил что мы что-то уже делаем? Я собираюсь набрать команду, собраться а затем подумать.

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

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

Не буду продолжать шараду с метафорами.

Мод к обливиону - нет он не подходит по динамике и я не смогу переделать его графику настолько, чтоб получилось то что нужно.  Суперским вариантом в этом плане был бы Half-life 2.

"дисциплина армейского типа" не вижу смысла кем то жестко руководить пока в команде я и еще один дракон.

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

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

Chaiseel да это он, завтра на МРТ еду.  А насчет Serious Sam то с геймплеем я давно определился это тот самый  beat them up в этом жанре ничего путного давно не выпускали.  Вот только получится ли в Сэме контактный бой?

Я собираюсь набрать команду, собраться а затем подумать.

Смайл, ты в команде кто? Геймдизайнер? Руководитель? Тогда всё должен решить/продумать ты. Остальные - исполнители. Напиши диздок и предъяви вакансии: нужен художник - задание раз, два... семьдесят семь (чётких!). Нужен композитор - задание раз, два... ну и так далее. Нужен программер 1 - будет заниматься заданием раз, два... Нужен программер 2 - у него задания свои, шоб первому не мешал, и дело спорилось. Нужны актёры озвучивания на такие-то роли, текст такой-то, нюансы озвучивания такие-то (по заданиям).

То есть, пока ты не создашь проект твоей игры, команду собирать смысла нет. Боишься работы? За тебя твою работу никто не сделает, не перекладывай её на "команду". Не разводи бардак, а предъяви чёткий архитектурный проект игры - и народ сам потянется, видя, что нужно сделать, и оценивая свои силы адекватно.

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

[Scald Havoc]

Scald Havoc, а как ты собрался тестировать математический движок? Пока не напишешь соответствующую программу, это будет просто поиск ошибок на глаз. Поэтому я понял, что ты имел в виду движок игровой. Но от этого смысла в твоих словах не становится больше. Сто-сто двадцать запусков игры с последующими исправлениями неизбежны, если ты хочешь получить хорошую игру. Это просто доказанный факт, ну никогда ты не сможешь на листе бумаги написать такую игровую систему, чтобы её потом не пришлось исправлять 10^n раз. И лучше уже исправлять столько раз, чем пол-года планировать что-то, что может в итоге выйти провальным в корне. Скажем, придумал ты игру про паркур, описал все малейшие подробности, а на практике оказалось, что тупо бегать по уровню уныло и не интересно. По поводу того, кого надо гнать из команды - сама по себе любительская разработка игр считается занятием довольно увлекательным. Иначе почему столь многие ею занимаются? Да потому что разработка - это тоже творчество, а не тупо рисование по точкам! Сколько говоришь у тебя опыта? Я семь лет делал всевозможный контент к играм. Было время прийти к этим выводам. И будь добр, не разбираешься в игрострое - хотя бы не пытайся "помочь". Тут некоторые уже решили проект похоронить живьём. =Р
И что не ясно по поводу рокстаровского Renderware? Просто сделали такой универсальный движок, который можно компилировать на кучу консолей (ПК, ПС2, ПСП, Геймкуб, ХВОХ первый и т. д.). На это ушло дофигища времени и ресурсов, которых у нас нет.

Smiling Killer, модель сегодня начал делать, но пока показывать рановато. ) Beat em up в Сэме сделать в принципе реально, но давай я сначала попробую набросать что-нибудь и дам тебе посмотреть. Если что-то будет не так, но я смогу это исправить, то в принципе можно оттесать такой мод, который будет нам подходить в плане геймплея, и останется графическая составляющая и сюжет. Сейчас у меня пока что готова более-менее стабильная система управлением движениями персонажа с видом со следящей камеры вверху. Выложу, как только добавлю к ней систему ближнего боя.

Интересно, вот про это:

ну никогда ты не сможешь на листе бумаги написать такую игровую систему, чтобы её потом не пришлось исправлять 10^n раз.

знают создатели GURPS, DnD или SPECIAL ?

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

Ну, можно еще ...чить вприсядку, тоже, говорят, увлекательное занятие )

Да потому что разработка - это тоже творчество

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

Я семь лет делал всевозможный контент к играм

А я лично подписывал ходатайство об увольнении программиста с 20-летним стажем ввиду его профнепригодности. Так что не аргумент.

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

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

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

TO Scratch

Как-то раз я писал ма-а-аленький мод (карту + скрипты) для третьих Героесов.
Писал я ее около недели. Почти неотрывно. Ну, чтобы красиво было, и чтобы там вот так, а там вот так, а там еще так...

Как-то писал я карту к "Противостоянию 3/3", и пытался реализовать там (при помощи скриптов) адекватные действия охраны а) до нападения на объект б) при нападении на объект. При этом патрулирование было реализовано и т.д. Там сцепок trigger-action было - штук 200. Сценарных, предусматривающих действия игрока и комментирующих их - от силы штук 40-50. Как понимаешь, адекватных желаний играть, после того как я знал любое последствие любого действия было мало.

знают создатели GURPS, DnD или SPECIAL

А-а-а-а!!! Не произноси имен сакральных в суе.

TO Chaiseel

а как ты собрался тестировать математический движок?

Есть такая игрулина - Мокрософт Эксцел. Благодаря реализации функций математических более чем достаточна для написания и балансировки математических моделей. Это не беря еще всякие страшноименуемые более специальные.

ну никогда ты не сможешь на листе бумаги написать такую игровую систему, чтобы её потом не пришлось исправлять 10^n раз

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

Я семь лет делал всевозможный контент к играм

У меня все равно больше. И толще. Так что линейку можно спрятать.

TO SmilingKiller

Я собираюсь набрать команду, собраться а затем подумать.

Будет фигня. Знаешь как это со стороны выглядит - Я хочу сделать игру. Какую - не знаю, как - не знаю, но когда соберу людей - вместе порешаем. Танчикостроение в чистом виде.
А делается все по другому - Я хочу сделать: а) игру б) жанр в)поджанр г) с такими и такими способностями игрока д) с сюжетом в определенной канве е) в таком-то сеттинге.
Что мне нужно: а) разработать математическую модель б) разработать графический движок в) разработать логическое ядро - оболочку из которой запускаются все процессы.
Мне нужны: а) гейм-мастер, знакомый с игровыми движками б) программеры в) 3D дисигнеры.
Структура процесса:
1.  идти на "тематичку", искать человека, шарящего в игровых системах с т.з. именно мат. модели, предлагать ему участие на заранее оговоренных условиях.
2. Построить мат.модели, объединить их в игровой движок. Протестировать, отбалансировать
3. идти на "тематичку", искать прогера процессов, прогера 3D графики, прогера ОС, склонить к недобровольному сотрудничеству
4. Разобрать существующий игровой движок, построить систему задач для каждого из прогеров
5. идти на "тематичку", искать моделлеров.
6. По имеющимся данным поставить ТЗ моделлерам на все потребные для игры объекты.
7. наполнить имеющиеся программные блоки 3D моделями.
8. Тестинг.
А по принципу "а давайте кодлой соберемся и чего нибудь такое замутим" хоршо только в соседском огороде яблоки воровать. Серьезно. Просто неоднократно видел как на тему написания адд-она к правилам быстро собирались толпища, но поскольку каждый имел свое мнение и хотел от этого чего-то своего - дальше мертворожденных тем "У меня есть идея новых правил" не шло.

во вторых эти системы пошаговые (чесно, плохо знаком с GURPS), я просто забыл написать оговорку об этом

И Фаллаут Тактикс где был режим реального времени это все очень сильно мешало. S.P.E.C.I.A.L. при этом просто впадал в кому.

, что оттестировать большую часть на бумаге можно только у пошаговых игр.

Берешь шаг в 1/10 секунды и какие проблемы? Ну да, конечно, просчет удара кулаком - циклов 40, этож ужас... Там тестировать надо только конфликты правил. Балансировка - это другое дело, но и она проблемы не представляет.

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

П.С. Удачи в лечении.

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

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

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

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

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



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

[Добавлено спустя 42 мин.]

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

Описание игровой модели взрыва гранаты Ф-1
WHID=HE1  /тип заряда - НЕ1 - уникальный идентификатор для взрыва Ф-1
Type= Explosion1 /Описание анимации/типа взрыва - Еxplosion1 - огненный шарик с вкраплениями темных фрагментов имитирующих осколки, т.е. взрыв осколочной гранаты
Wave=yes / наличие ударной волны взрыва
WavRad=5 / радиус ударной волны в единицах измерения (игровых масштабных метрах)
WavStr=100 / сила ударной волны в эпицентре
Frag=yes / наличие осколков при взрыве
FragAnim=Frag1 / анимация осколка
FragSpher=180 /сфера разлета осколков - полная сфера, считается от вертикальной полуоси направленной вверх из эпицентра, и далее наполняется по 360 градусов горизонтали (для пехотной мины будет допустим 30) (ось привязывается к физической или 3D модели объекта)
FragNum=100 / количество осколочных поражающих элементов
FragRad=50 /полный радиус разлета ОПЭ, при этом действует правило которым определяется что осколок эффективен на 1/2 макс дистанции.
FragStr=25 / сила урона единичного ОПЭ в эпицентре
FragTrac=Ballistic / Определение типа траектории полета осколков

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

Урон отдельных поражающих факторов рассчитывается по формулам где учитывается текущее расстояние цели от эпицентра. Находится процентное соотношение максимального эффективного расстояния и на него умножается урон. т.е. Dam (повреждение) = FragStr - FragStr * (FactDist {фактическое расстояние от эпицентра}/(FragRad/2)). При этом Wound (ранение) определяется следующей формулой
if Dam>=0 (Wound1 = Dam) else (Wound1=0) для того, чтобы за 25 метрами осколки гранаты не приобретали лечебных свойств. Потом аналогично считается урон от взрывной волны Wound2, итоговое ранение наносимое взрывом гранаты со всей совокупностью поражающих факторов - WoundGren = Wound1 + Wound2
WoundM = WoundRifle + WoundGren + Wound + ... + Wound
Ну а дальше параметр Health считается по Health минус WoundM и полученное значение возвращается в Health. т.е. X=X-Y в рамках постоянно действующего цикла, где Y динамически меняется в зависимости от процесса, а начальный X = 100 и не может быть меньше 0 и больше 100.
Можно надобавлять контузионных эффектов, которые будут менять статус игрока или вырубать/портить слух-зрение, но это уже лирика.

Траектории разлета осколков просчитываются разбивкой сферы взрыва на 100 граничных зон, к центральной геометрической оси которых привязывается стартовый участок траектории осколка. Или же - использование готового шаблона осколочного ядра, ячеек на 200-250 из которых случайным образом выбираются ячейки по которым пойдут осколки, с соблюдением правила, запрещающего соседство более 2-х заполненных ячеек. Или осколочный шаблон по умолчанию 100 осколков, тогда к нему прописывается все эффекты из модели гранаты, и модель гранаты будет состоять из 4 строк - идентификатор, анимация, шаблон взрывной волны, шаблон осколков. (но все это имеет смысл, если гранат в игре больше 2-х)

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

Неправильно поставлен вопрос. Тебе нужен не человек который согласится работать над проектом, обладая при этом некоторыми специфическими знаниями "по теме", а специалист, обладающий знаниями в требуемом тебе объеме, который согласится работать над проектом. Да, его нужно найти и уговорить, но другого варианта нет. Т.е. не "я хочу сделать игру, кто умеет моделить - стукнитесь в асю", а "мне нужен человек с опытом работы в программе ХХХХХ и навыком анимации 3D моделей, для работы над некоммерческим проектом, ася такая-то".
За спрос денег не берут, как известно, поэтому на любом тематическом ресурсе можно обратится к тамошнему "гуру" с простым вопросом - я собираюсь делать то-то и то-то, проект некоммерческий, можете подсказать, что из профильного ПО лучше использовать, и кого из обитателей ресурса вы могли бы порекомендовать.

не охвачена работа аниматоров, сюжетников

а "прогера 3D графики" - это что?
Сюжетники? Это хто? Реализовать любой квест в скрипты работающие по принципу "trigger-action" тебе любой мододел к тому же "Противостоянию" реализует, и в сюжетную цепочку сведет.

В процессе разработки мы врятли обнаружим что руки у модели должны гнутся в другую сторону

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

Что же до

Кстати нет ли у тебя знакомых, раз ты так уверено говоришь?

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

Да, и вот что еще - тебе нужно будет на платном или бесплатном хостинге сделать сайтик с закрытым доступом, чтобы использовать его как склад и файлообменник. Просто перекид через "большие" файлообменники - это великий гемор. Я например так сеттинг твой и не скачал. Глючит или у меня или там что-то.
Перекидывать же блоки по 100-150 мб через "мыльники" - файл-лимиты не позволят.

Добавлено спустя 42 мин.

UPD
Ну и вот вопрос собственно: Какие параметры должен иметь игрок?

[Smiling Killer]

Smiling Killer, забей на него. Скальд тут пытается пропихнуть свой бесполезный субъективизм, и таким образом засоряется тема. Лучше не давать никому повода её засорять. То есть, не спорить с остальными, а заняться делом. Я свяжусь с тобой по личке, когда будет готово то, над чем работаю. Выложим здесь. Тебе тоже рекомендую использовать тему только для выкладывания уже готовых материалов (описаний игровых объектов/концептов/скриншотов и т. п.). И если Смайл не против, я попрошу не постить здесь ничего, что на прямую не относится к выложенным материалам. Вообще здорово было бы, если бы ты попросил модератора почистить тему до первых нескольких сообщений.

[там]

Чейсил, а ты случайно не родственник Рейхарда?  А то с одинаковой упёртостью вы фыркаете на тех, кто разбирается в этом лучше вас

У меня есть хорошее предложение, которому советую и Чейсилу, и Смайлинг Киллеру последовать. Зайдите вот сюда в раздел "Алфавит", почитайте, что пишут, а потом расскажите про свою игру там. И посмотрите на реакцию.

LittleDrakon
Там ресурс закрытый, просит регистрации. 
Что же до ситуации - танчикостроение - дело увлекательное, для особого, склада ума. В общем-то на самом деле - дело Smiling Killer'а - что и как делать - задумка то его. Но призыв Chaiseel'а "выкладывать все здесь" после того как я говорил про отдельный ресурс для обмена файлом между разработчиками - он показателен.
Интересно, что скажет по этому поводу Кальтенбруннер Администрация.

Chaiseel
А вот это, молодой человек - уже диагноз. У В Ы.

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

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

Chaiseel
А вот это, молодой человек - уже диагноз. У В Ы.

Увы...

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

Тема разделена, данная ветка перенесена в раздел "Игротека дракона".

[Re: Фильмы, которые хотелось бы]