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

Спорить не буду анимация это сложно, но если делать игру 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 -- это артефакты. Которые описывают продукт.
В нашем случае, концепты -- это тоже артефакт. Который описывает.

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

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